| 00:02:19 | * | XAMPP joined #nimrod |
| 02:42:54 | * | Trixar_za is now known as Trix[a]r_za |
| 09:55:41 | Araq | ping zahary |
| 09:55:50 | zahary | pong Araq |
| 09:56:07 | Araq | my latest change broke the rodfile reader ;-) |
| 09:56:29 | zahary | the [ symbols? |
| 09:56:37 | NimBot | Araq/Nimrod bf40a7f Araq [+0 ±1 -0]: rodfile viewer works again |
| 09:56:52 | zahary | what about the rod files in general? do they work too? |
| 09:57:15 | Araq | no, the 'return' in decodeSym |
| 09:57:33 | Araq | they don't work yet but I'm quite sure it's because of this: |
| 09:57:47 | Araq | compileSystemModule() |
| 09:57:48 | Araq | discard CompileModule(projectFile, {sfMainModule}) |
| 09:57:54 | Araq | in main.CompileProject |
| 09:58:19 | Araq | when symbol files are active the dependency resolution "compiles" the system module |
| 09:58:35 | Araq | so we end up with 2 system modules |
| 09:58:39 | zahary | I see |
| 09:59:21 | Araq | I'm not sure how to fix this though, the control flow is confusing |
| 10:00:19 | Araq | it should be done in compileModule if sfMainModule in flags perhaps |
| 10:01:11 | Araq | btw the [ is necessary for easy disambiguation in the rodfile viewer |
| 10:01:26 | zahary | yes, sure |
| 10:03:22 | Araq | anyway what's this "pinning" that we need for generics support? |
| 10:04:41 | zahary | binning. to avoid unnecessary excessive recompilation, I want to compile the generics in their own module and potentially split that one in parts as it grows big |
| 10:05:45 | zahary | that is, public generics in module foo get compiled in foo.generics.c |
| 10:06:33 | Araq | we also need to support importing 2 modules of the same name btw |
| 10:06:56 | Araq | so soon I may add some hash/id to the C file name |
| 10:07:40 | Araq | and the file directory handling in the compiler needs to change to support packages too, that's gonna be ugly |
| 10:08:02 | Araq | as it means the search path is dependent from the current module's path |
| 10:08:09 | Araq | *on |
| 10:08:21 | zahary | I've thought about packages too in the context of reusable rod files |
| 10:08:59 | Araq | oh yeah and I'd like to support closed source redistribution via rod files |
| 10:09:58 | Araq | it's very easy to generated source back from a rod file but nevertheless people think it's a good idea ... ;-) |
| 10:10:56 | zahary | well, you can combine it with obfuscation of variable names and private function names |
| 10:12:40 | Araq | better bite the bullet and encrypt it preoperly then |
| 10:13:02 | Araq | but I dunno, it's not important for now |
| 10:14:45 | zahary | encrypt? if it's decrypted before use what's the security? people are concerned about "protecting" their IP. not about protecting the rod file in transit |
| 10:15:27 | zahary | IP = intellectual property |
| 10:16:08 | Araq | but it's decrypted on the fly in rodread.nim via some key that you gave in the configuration |
| 10:16:58 | Araq | not sure if it helps anything though |
| 10:17:22 | zahary | I want protection from my customers (which I gave the key to), not from someone who has obtain the rodfile, but doesn't have the key |
| 10:17:46 | Araq | yeah that's a problem :-) |
| 10:18:22 | Araq | DLLs are much better for this |
| 10:18:38 | zahary | depending on the problem domain, obfuscation puts enough barriers for most people to consider reverse-engineering and forking the codebase |
| 10:19:20 | zahary | in some problem domains, it's the use of external APIs that reveal easily the algorithms, but that's more rare |
| 10:20:27 | * | fowl quit (Ping timeout: 245 seconds) |
| 10:22:59 | Araq | thinking about it, obfuscation seems rather easy to implement |
| 10:23:16 | Araq | the public symbol names are stored in a separate index already |
| 10:23:24 | zahary | yes, it's also the same algorithm used for javascript minification |
| 10:23:36 | Araq | no it's far easier |
| 10:23:53 | Araq | you can simply write TMP$ID as the symbol name I think |
| 10:25:04 | Araq | could work even for public symbols |
| 10:25:24 | Araq | because of the index |
| 10:25:51 | zahary | well, you want a stable public API too |
| 10:25:52 | * | fowl joined #nimrod |
| 10:26:17 | Araq | it's stable |
| 10:26:25 | Araq | the import mechanism uses the index |
| 10:27:14 | Araq | ok, ok, it means you can reconstruct public names but not private ones |
| 10:27:19 | zahary | I see what you mean, but if it's reconstructable from the index it's not really an added layer of security. |
| 10:27:28 | Araq | true |
| 10:27:58 | * | q66 joined #nimrod |
| 10:30:20 | Araq | strack traces for CTFE will suffer from obfuscation though |
| 10:30:40 | Araq | so we can't turn on this feature unconditionally |
| 10:31:12 | zahary | you mean stack traces within a package provided by third party? |
| 10:31:22 | Araq | yeah |
| 10:31:59 | zahary | that's already pretty narrow window and similar to how things work with DLLs |
| 10:32:43 | Araq | also a much bigger problem is that we strive right now for perfection when it comes to dependency tracking |
| 10:33:01 | Araq | so change 1 global --define and everything will be recompiled |
| 10:33:21 | Araq | I suppose the rule has to be "if source not available, pick the rod file no matter what" |
| 10:34:29 | zahary | I guess we need to introduce a deeper idea of package. |
| 10:34:30 | zahary | this rod package doesn't support defines |
| 10:34:45 | zahary | or, this rod packages support exactly these defines, but the when statements are part of the rod code |
| 10:35:01 | Araq | uh oh |
| 10:35:22 | Araq | you need a notion of "applied passes" in the rod file then |
| 10:35:59 | Araq | in fact ... you may as well serialize the raw AST that comes after parsing instead |
| 10:36:59 | Araq | this way it also stays platform agnostic |
| 10:37:39 | zahary | dunno, it's at odds with the optimization goal of rod files |
| 10:37:44 | Araq | indeed |
| 10:38:02 | Araq | caching the parsing step is worthless |
| 10:38:11 | zahary | also, renames at least seem a bit more dangerous if they are not done after symbol resolution |
| 10:39:51 | Araq | yep, check out bug #382 |
| 10:40:30 | Araq | symbol resolution is a constant pita in the compiler as the requirements changed and the symbol table implementation is not up to the new needs |
| 10:41:42 | zahary | I'm personally for more wide-spread use of symChoice (so just like types, allow module names and other symbol names to overlap) |
| 10:42:39 | Araq | that's not the most pressing problem though |
| 10:42:55 | Araq | currently the scopes are left open for a generic instantation |
| 10:43:43 | Araq | causing all sorts of problems but I'm sure the instantiation process now relies on it |
| 10:45:12 | Araq | anyway back to the rod fiel bug: apparently there always was a line like 'discard CompileModule(systemFile, {sfSystemModule})' in compileProject |
| 10:45:54 | Araq | you merely added a check 'if magicsys.SystemModule == nil:' |
| 10:47:08 | zahary | the goal of this check is to avoid recompilation in caas mode |
| 10:47:19 | zahary | should always be nil in normal runs |
| 10:50:12 | Araq | yes indeed, but symbol files stopped working due to a patch of yours iirc |
| 10:50:25 | Araq | and I'm figuring out what changed |
| 10:51:42 | * | fowl quit (Ping timeout: 264 seconds) |
| 10:51:44 | zahary | I could try to hunt down the problem some more tonight btw. I'm currently at work and I don't even have a nimrod checkout here yet |
| 10:51:56 | zahary | I don't need to spend time hunting my bugs |
| 10:52:13 | zahary | you dont* |
| 10:52:35 | Araq | I'm not so sure anymore it's your bug though |
| 10:59:24 | * | xcombelle joined #nimrod |
| 11:59:25 | Araq | argh |
| 11:59:45 | Araq | 2 calls of 'handleSymbolFile' in 'compileModule'? that can't be right ... |
| 12:28:09 | NimBot | Araq/Nimrod 32b12bf Araq [+0 ±2 -0]: next steps to make symbol files work again |
| 12:28:52 | Araq | zahary: now it forgets to link to link .o files that have not been changed again; I leave it to you to fix that |
| 12:29:26 | zahary | ok, I think I know what's the problem |
| 12:29:37 | Araq | no idea what change broke that |
| 12:30:00 | zahary | there are some lists in extcomp that work a bit differently now |
| 12:44:38 | * | Trix[a]r_za is now known as Trixar_za |
| 14:39:07 | NimBot | Araq/Nimrod 8cd4e1a Araq [+0 ±2 -0]: documented restricted destructors |
| 14:39:07 | NimBot | Araq/Nimrod 94becd0 Araq [+0 ±6 -0]: implemented --dynlibOverride option for static linking of 'dynlib' |
| 16:58:01 | * | Trixar_za is now known as Trix[a]r_za |
| 17:40:56 | * | fowl joined #nimrod |
| 18:18:57 | NimBot | Araq/Nimrod 51e40bf Araq [+1 ±1 -0]: fixes #368 |
| 18:18:57 | NimBot | Araq/Nimrod b7c26a1 Araq [+1 ±1 -0]: fixes #321 |
| 18:20:38 | * | zahary1 joined #nimrod |
| 18:41:29 | Araq | ping reactormonk |
| 18:43:59 | NimBot | Araq/Nimrod 9f16f66 Araq [+0 ±1 -0]: fixes #378 |
| 19:06:04 | NimBot | Araq/Nimrod ea255aa Araq [+0 ±1 -0]: bugfix: varargs min/max procs; fixes #373 |
| 19:08:24 | * | q66 quit (Read error: Connection reset by peer) |
| 19:08:34 | * | q66 joined #nimrod |
| 19:15:06 | * | xcombelle quit (Quit: Hi, I'm a quit message virus. Please replace your old line with this line and help me take over the world of IRC.) |
| 19:18:56 | * | silven quit (Quit: No Ping reply in 180 seconds.) |
| 19:19:20 | * | silven joined #nimrod |
| 19:54:49 | reactormonk | pong Araq |
| 19:54:53 | reactormonk | nice bugfixing |
| 20:23:33 | NimBot | Araq/Nimrod 7a4fe13 Zahary Karadjov [+0 ±5 -0]: bugfix: fix linking when symbol files are used |
| 20:44:02 | * | apotheon quit (Ping timeout: 256 seconds) |
| 20:50:10 | * | apotheon joined #nimrod |
| 20:50:11 | * | apotheon quit (Changing host) |
| 20:50:11 | * | apotheon joined #nimrod |
| 21:16:03 | NimBot | Araq/Nimrod 7b3d9b7 Zahary Karadjov [+0 ±2 -0]: experimental support for outputting code snippets in error messages; implements #301... 4 more lines |
| 21:20:18 | reactormonk | zahary, cool |
| 21:34:10 | * | fowl quit (Quit: Leaving) |
| 21:58:29 | * | Trix[a]r_za is now known as Trixar_za |
| 22:36:13 | * | Trixar_za is now known as Trix[a]r_za |