| 02:57:50 | * | tcsh joined #nimrod |
| 04:29:26 | * | tcsh quit (Quit: Leaving) |
| 05:27:46 | * | ccssnet quit (Ping timeout: 244 seconds) |
| 07:02:52 | * | Araq_ joined #nimrod |
| 07:03:18 | * | Araq_ quit (Client Quit) |
| 07:15:42 | * | ccssnet joined #nimrod |
| 08:13:53 | * | Trix[a]r_za is now known as Trixar_za |
| 08:41:02 | * | Trixar_za is now known as Trix[a]r_za |
| 13:48:26 | * | Araq_ joined #nimrod |
| 13:49:37 | * | Araq_ quit (Client Quit) |
| 14:41:53 | * | JStoker quit (Excess Flood) |
| 14:47:27 | * | JStoker joined #nimrod |
| 14:52:09 | * | shevy quit (Ping timeout: 276 seconds) |
| 15:06:02 | * | shevy joined #nimrod |
| 16:44:37 | Araq | argh |
| 16:45:03 | Araq | zahary: do want to mess with the DLL stuff? |
| 16:46:20 | zahary | well, I implemented the other idea from yesterday - there is no longer nimdat, but rather each module store its own type infos and there is a datInit procs that are called before the regular init procs |
| 16:46:45 | Araq | yeah already skimming your patch |
| 16:47:18 | Araq | but nimdat ain't the reason for the DLLs failing |
| 16:47:33 | zahary | I didn't quite understand the code for pending modules and mergeRequired. can you explain what is supposed to happen there? |
| 16:48:29 | Araq | pending modules are necessary for global dead code elimination |
| 16:48:35 | zahary | well, dynamic symbols are supposed to go in the dat section so the DLL problem will be solved |
| 16:49:12 | Araq | I also noticed that DLLs are stupid as the memory manager is not really shared anymore |
| 16:49:25 | zahary | yeah, but when will we close (e.g. with writeModule) some module and then reopen it for merging? |
| 16:49:28 | Araq | it requires lots of {.rtl.} annotations in the memory manager I think |
| 16:49:35 | zahary | is this going to happen only with symbol files? |
| 16:49:45 | Araq | merging only happens with symbol files, yes |
| 16:51:12 | zahary | what's the advantage of closing modules early? it seems to me that keeping them open till the end of the compilation only simplifies the code there |
| 16:53:07 | zahary | and why isn't dead code elimination based on sfUsed? if the semantic pass runs to end before the next pass begins sfUsed will be enough for dead code elimination. dead code elimination for JS will be a no-brainer then |
| 16:53:36 | Araq | DCE for JS is already implemented ;-) |
| 16:54:51 | dom96 | damn. I can't believe I haven't tried it yet |
| 16:55:02 | Araq | and I suppose I didn't trust sfUsed enough when I wrote it |
| 16:55:13 | Araq | btw it's not as easy anyway |
| 16:55:28 | Araq | for inline procs you need to pull them into the current module + all its dependencies |
| 16:58:03 | Araq | oh and the semantic pass doesn't run to end before the next pass begins either ... |
| 16:58:28 | Araq | it's a pipeline based on top level statements/declarations |
| 16:58:36 | zahary | yes, I know - I said "if the semantic pass ..." |
| 16:58:59 | zahary | I've tried to run to end once and it doesn't break anything |
| 16:59:11 | Araq | good :-) |
| 16:59:45 | Araq | I have various changes in mind for "Nimrod 2" |
| 16:59:55 | Araq | (as I call it to myself) |
| 17:01:12 | Araq | but I don't really plan on implementing it for now, I instead may write a proper spec |
| 17:01:31 | Araq | for example, the overloading handling is already splitted up |
| 17:01:49 | Araq | we create a nkSymChoice ("superposition" you called it) |
| 17:02:01 | Araq | and then select the proper symbol based on context |
| 17:02:22 | Araq | but the old overloading code does not necessarily do it this way |
| 17:02:26 | zahary | I've seen the code - it seems to be integrated in quite a lot of places |
| 17:02:37 | Araq | it's patchwork |
| 17:04:39 | Araq | well I'd like to formalize these things better |
| 17:04:44 | Araq | symbol lookup |
| 17:04:46 | Araq | type inference |
| 17:05:01 | Araq | getting rid of forward declarations |
| 17:05:08 | Araq | merging templates and macros |
| 17:05:15 | Araq | making templates hygienic |
| 17:05:34 | Araq | the syntax could be a bit better |
| 17:05:47 | Araq | i.e. more modern |
| 17:07:32 | Araq | I'm not sure if we really should do all this incrementally |
| 17:08:20 | zahary | btw I was feeling adventurous lately and implemented some parts of my hypolang :) |
| 17:08:22 | * | Trix[a]r_za is now known as Trixar_za |
| 17:08:27 | Araq | on the other hand, I won't ever write it from scratch |
| 17:08:33 | Araq | *re-write |
| 17:08:44 | Araq | like which parts? |
| 17:10:58 | zahary | well, the grammar is very simple and it mostly works now (I can compile some simple mixed programs using both languages) - I also want to experiment with a DLL for the compiler for some of the IDE oriented ideas I want to pursue |
| 17:15:01 | Araq | how does a DLL help for that? |
| 17:15:30 | Araq | oh well never mind |
| 17:16:01 | Araq | btw how do you think we should deal with the generic caching? |
| 17:16:15 | Araq | currently we cache instantiations based on types: |
| 17:16:41 | Araq | hashset[string] is cached even though 'hash' and '==' could have been overwritten in a local scope |
| 17:16:50 | Araq | for 'string' |
| 17:17:15 | zahary | well, it's the old resident compiler idea |
| 17:17:15 | zahary | I think generics should be compiled in their owner module - it may be beneficial to add support for module "part" files - i.e. system.part1.cpp, system.part2.cpp |
| 17:17:45 | zahary | simple heuristic could decide that such a part file has become too big and a new one should be created |
| 17:17:55 | Araq | that doesn't answer my question |
| 17:18:05 | Araq | ;-) |
| 17:18:10 | zahary | ah, sorry |
| 17:19:05 | zahary | well, I agree with qx that this is not good - I personally lean more towards distinct key type with the borrowAll pragma we discussed once as a method for such local overrides |
| 17:19:56 | zahary | but I have identified several examples where the compare function have state (e.g. sorting by distance from some point in space) |
| 17:21:52 | Araq | true but there should be simply a way to say 're-instantiate here' for these cases |
| 17:22:04 | Araq | default has to be caching |
| 17:22:21 | Araq | on the other hand the cache could also request the symbol table |
| 17:22:30 | Araq | to ensure no definitions have changed |
| 17:22:55 | zahary | in C++, you'll pass a Cmp functor that has additional fields - since generics are different types with the "type reopening" we've discussed you can solve this problem and also for hypolang I planned to allow the user to supply additional code to be evaluated as part of the definition (every definition there is an executable code if you remember) |
| 17:48:34 | Araq | zahary: are you sure module.position isn't already used for rod-file generation? |
| 17:53:01 | zahary | there are some assignments to position is rodreead/decodeSym, but isn't this limited to symbols inside modules (i.e. procs, types, etc)? |
| 17:53:39 | Araq | I don't think so |
| 17:53:59 | Araq | let me check |
| 17:54:28 | zahary | I needed this as an optimization in the codegen - I want to have a fast way of getting the BModule of a PSym - any other way to achieve the same will suffice |
| 17:55:13 | Araq | use the pending modules? |
| 17:55:34 | Araq | gPendingModules is an array |
| 17:55:51 | Araq | but you could make it a table[PSym, Bmodule] I think? |
| 17:56:16 | Araq | in fact, findPendingModule uses a slowish linear search |
| 17:56:31 | Araq | it's from the time before we got proper generics |
| 17:56:34 | zahary | well, currently is just a random access in an array - gPendingModules is usually linearly searched and hash table could work, but it will be slower |
| 17:57:34 | Araq | did you measure the speed? |
| 17:57:49 | Araq | the code as is doesn't care and uses findPendingModule |
| 17:57:51 | Araq | ... |
| 17:58:00 | Araq | I have to go, see you later |
| 18:00:04 | * | XAMPP joined #nimrod |
| 18:00:06 | zahary | well, check this position thing - I'd rather add a general purpose backendData fields to the ast types instead of keeping the linear searches |
| 18:00:16 | * | JStoker quit (Excess Flood) |
| 18:01:10 | zahary | also, TSym could be shrunk a bit if we introduce a separate TModule type |
| 18:07:27 | * | JStoker joined #nimrod |
| 18:12:24 | Araq | back already |
| 18:12:36 | Araq | yeah I know about TSym |
| 18:13:24 | Araq | rodread contains: |
| 18:13:27 | Araq | elif result.kind notin routineKinds: |
| 18:13:28 | Araq | result.position = 0 |
| 18:13:37 | Araq | I'm quite sure this affects modules too |
| 18:14:11 | Araq | Introducing a TModule = object of TSym is fine with me though |
| 18:14:30 | Araq | but ugh |
| 18:14:43 | Araq | this has consequences for the rodfile stuff too ... |
| 18:19:28 | zahary | I'll look at the rodfiles code, but it surprises me that module symbols are read from rod files - isn't there a 1:1 mapping between module symbols and rodfiles? are only module contents serialized? |
| 18:19:29 | Araq | you could split position: int into position: int32, backendID: int32 or something though |
| 18:20:39 | zahary | * aren't only … * |
| 18:21:07 | Araq | I'm not use what I do with the back pointers |
| 18:21:26 | Araq | I think I serialize imported.owner in the importing module |
| 18:21:38 | Araq | *not sure |
| 18:22:44 | Araq | but |
| 18:23:06 | Araq | the usage of 'position' should be non overlapping really |
| 18:34:40 | Araq | and indeed |
| 18:34:46 | Araq | your changes broke rodfiles :P |
| 18:34:53 | Araq | http://build.nimrod-code.org/commits/linux-x86/e394a642e986/testresults.html |
| 18:36:52 | zahary | what's the relevant test? |
| 18:37:21 | Araq | tgeneric2.nim |
| 18:37:32 | Araq | deada2.nim |
| 18:38:26 | zahary | ok, I'll try to fix them |
| 18:38:52 | Araq | I'm quite sure it's due to your usage of 'position' |
| 18:39:54 | Araq | but apart from that I like the idea of splitting type information and getting rid of nimdat |
| 18:42:27 | Araq | oh btw check tests/specials.nim for how to invoke the rodfile tests |
| 18:42:49 | Araq | you can't just do 'nimrod c --symbolFiles:on -r deada2.nim' |
| 18:42:56 | Araq | that wouldn't reproduce it |
| 18:45:22 | zahary | yeah, yeah, I know - I have to recompile it twice |
| 18:46:09 | zahary | can you clarify what you mean by "back pointers" in one of the previous messages/ |
| 18:48:53 | Araq | the 'owner' field |
| 18:51:18 | zahary | but woudn't this be linked to existing module in memory (after searching for it)? |
| 18:52:54 | Araq | yes it will be resolved to it in the loading code |
| 18:53:40 | Araq | but I don't remember the details ;-) |
| 18:56:30 | Araq | if module A imports B I think in A.rod there is an entry for 'B' |
| 18:57:11 | Araq | not sure if it's only an "import entry" or a "full entry" |
| 18:59:00 | Araq | for all other symbols it's an "import entry" only but I don't remember how it's for module symbols |
| 19:01:32 | zahary | it doesn't make sense to be full entry - storing the entire AST of a module in other modules' rod files |
| 19:01:51 | Araq | oh that's not what I mean by "full entry" |
| 19:03:44 | Araq | a module doesn't contain its AST anyway |
| 19:08:51 | Araq | oh I always wanted to ask |
| 19:09:03 | Araq | how stable is the implicit generics stuff? |
| 19:13:57 | zahary | it's equivalent to normal generics as I've explained before |
| 19:14:10 | zahary | so it's just as stable |
| 19:14:29 | Araq | so it just works like clay? :-) |
| 19:14:50 | Araq | in fact, I meant what kind of code have you thrown against it |
| 19:16:49 | zahary | well, there are some tests using it - the type constraints code is less mature - I know some current bugs with it actually and I want to refactor the type kinds a little bit, because right now it's not possible to say const myTypeList = @[int, float, string] |
| 19:17:08 | zahary | the reasons for this are rather long, but I want to make it possible |
| 19:21:03 | Araq | what about giving macros access to the types instead? |
| 19:22:12 | Araq | give macros a type API and access to the symbol table and see if that can't implement the missing features |
| 19:22:29 | Araq | this has to be done anyway |
| 19:23:59 | zahary | this is partly done already: https://github.com/Araq/Nimrod/blob/master/tests/run/ttypetraits.nim |
| 19:24:18 | zahary | adding new type traits is very easy - you have to modify a single function in evals.nim |
| 19:25:05 | Araq | I noticed but I'm unsure how you infer the return type |
| 19:25:24 | Araq | 'type.name' returns a string |
| 19:25:58 | Araq | 'type.isGeneric' should return a bool |
| 19:27:31 | zahary | but this is unrelated to the problem I mentioned - it's about treating the typedesc type as a single type - right now each typedesc ends up being a separate type |
| 19:27:34 | zahary | https://github.com/Araq/Nimrod/blob/master/lib/pure/typetraits.nim |
| 19:27:48 | zahary | here name is defined as returning string |
| 19:28:22 | Araq | lol somehow I missed that whole file |
| 19:28:42 | zahary | I'm being overly clever and recognize the actual type trait proc later (they all share the same magic) |
| 19:28:55 | Araq | no, I like it |
| 19:29:06 | Araq | the proliferation of magics has to be fighted somehow |
| 19:29:52 | zahary | type traits are special because you can use them outside eval contexts too |
| 19:30:23 | zahary | it's perfectly fine to say |
| 19:30:23 | zahary | var x = T.name; … in some regular proc |
| 19:48:28 | Araq | zahary: they figured the type state feature in rust is not really useful |
| 19:48:39 | Araq | and now they plan to get rid of it again |
| 19:52:19 | * | Trixar_za is now known as Trix[a]r_za |
| 19:56:49 | zahary | well, I like the idea behind it, but their implementation is somewhat limited to me - they care about compilation speed and the halting problem so they don't allow free-form programming when managing the type state - instead they reduce it to another problem of managing set of integers where each integer corresponds to a "truth for a predicate" in the program |
| 19:57:57 | Araq | I now think it's misguided to have that as part of the compilation step |
| 19:57:58 | zahary | I don't quite like such limitations - other language try to limit the dependent typing code to more programmable language, but still guaranteed to halt |
| 19:58:03 | zahary | http://en.wikipedia.org/wiki/Total_functional_programming - see this for example |
| 19:58:24 | zahary | I don't like that approach either - I think the halting problem should be addressed with time bounds |
| 19:58:41 | Araq | yeah me too |
| 19:58:51 | Araq | not really 'time' but some counters |
| 19:59:02 | Araq | you don't want it to depend on your CPU speed |
| 19:59:13 | Araq | well ok, sometimes that would be nice too :-) |
| 19:59:33 | zahary | yeah, sure |
| 20:00:12 | Araq | I think the --threadAnalysis:on way ain't bad |
| 20:00:34 | Araq | so you just turn it off for quick turn around times |
| 20:00:35 | zahary | but what do you mean by "it's misguided"? what in particular? |
| 20:00:51 | zahary | user-defined tanalysis? |
| 20:01:08 | Araq | no I mean: treat it like a 'release' mode |
| 20:01:25 | Araq | so you have 'debug', 'intensive_checking' and 'release' modes |
| 20:01:45 | Araq | this way it's like an external proof tool |
| 20:01:53 | zahary | well, surely there is a value in controlling the amount of analysis to speed up development, but this could be left for the user too |
| 20:02:10 | zahary | if defined(debug): do this with the type state, else: .... |
| 20:02:54 | Araq | however, the ATS people noticed variable length strings are hard to deal with their dependent typing |
| 20:03:27 | Araq | and IMHO D's const system is even more broken then C++'s ... |
| 20:04:12 | Araq | apart from 'nil', Nimrod's type system perhaps hits some local maximum |
| 20:04:30 | zahary | good libraries may expose several layers of control for what is analysed |
| 20:04:30 | zahary | |
| 20:14:01 | Araq | alright next topic: |
| 20:14:07 | Araq | the language allows: |
| 20:14:22 | Araq | template t(): expr = |
| 20:14:24 | Araq | block |
| 20:14:29 | Araq | let x = 56 |
| 20:14:34 | Araq | x |
| 20:14:49 | Araq | but the C code generator can't handle this anymore |
| 20:14:59 | Araq | as it puts 'x' into {} |
| 20:15:11 | Araq | how to fix? |
| 20:27:19 | zahary | well, you dont use block here. instead it's just |
| 20:27:19 | zahary | let x {.gensym.} = 56 |
| 20:27:19 | zahary | x |
| 20:28:05 | zahary | if you ask for block you get block - I think this is reasonable |
| 20:34:20 | Araq | well the compiler then needs to forbid the expression block |
| 20:34:49 | Araq | I thought we could simply not generate a {} for an nkBlockExpr instead |
| 20:35:04 | Araq | but this doesn't fly with the stmt/expr merge ... |
| 20:35:19 | zahary | if you remember, I argued that the user may want to have the variable destructor executed at the end of the block |
| 20:36:13 | zahary | so explicitly requesting a block may be meaningful for the user |
| 20:37:00 | zahary | I dont think {} are generated for the nkBlockExpr itself |
| 20:37:17 | zahary | this here is a nkBlockExpr with a nested nkBlock, right? |
| 20:38:47 | zahary | about the stmt/expr merge, I argued that single-expr vs multiple-expr will always remain useful distinction in the template return type |
| 20:39:07 | zahary | expr vs exprlist if you like |
| 20:48:08 | Araq | expr vs exprlist -- sure |
| 20:52:58 | zahary | btw the rodfiles crash turned out to be happening because of a double popFrame in one of the init functions |
| 20:59:45 | Araq | hrm |
| 20:59:47 | Araq | I see |
| 21:07:16 | Araq | zahary: any idea why the DLLs fail? |
| 21:08:03 | Araq | the error I get is: 'cannot load 'nimrtl_newObj' |
| 21:08:09 | Araq | which doesn't make sense |
| 21:09:04 | zahary | this is when you execute the program? |
| 21:09:10 | Araq | yes |
| 21:09:55 | zahary | why don't you step in through the code to the point where nimrtl has to be loaded? |
| 21:10:17 | Araq | well it loads quite a lot of symbols correctly |
| 21:10:34 | Araq | and nimrtl does contain nimrtl_newObj too |
| 21:10:40 | zahary | you can see the exported symbols with something like: nm nimrtl.so |
| 21:10:49 | Araq | ok |
| 21:13:22 | Araq | contains nimrtl_newObj ... hm |
| 21:14:01 | zahary | and you are certain that other symbols are loaded? it's not a path problem or something like that |
| 21:14:21 | zahary | I had issues with calling conventions too, but I guess all of the symbols use the rtl pragma here |
| 21:14:26 | Araq | the code does not load nimrtl_newObj as the first symbol so yeah |
| 21:14:43 | Araq | however it may be a duplicate |
| 21:15:03 | Araq | as I figured the memory manager is not properly left out for server.so |
| 21:18:24 | Tasser | what's a symbol btw? a mapping name => function position? |
| 21:18:45 | Araq | for lib.so and DLLs yes |
| 21:19:20 | Tasser | in nimrod it includes the signature? |
| 21:21:20 | Araq | in nimrod a symbol is a name for an entity :P |
| 21:21:56 | Tasser | proc/method/object ? |
| 21:22:02 | Araq | yes |
| 21:22:29 | Araq | in the compiler we distinguish between "identifier" and "symbol" |
| 21:22:45 | Araq | identifiers are turned into symbols by symbol lookup |
| 21:22:46 | zahary | so what is supposed to prevent this duplication of init code when merging? we merge if there is anything new in the new proc, but we merge all old sections with the complete contents of all new sections? |
| 21:23:47 | Araq | ugh that's a very good question |
| 21:23:58 | Araq | my thought was like: |
| 21:24:25 | Araq | it generates new type information for a whole type graph with new IDs |
| 21:24:43 | Araq | even though it surely could share quite a lot if IDs were stabler |
| 21:25:00 | Araq | and IDs are stabler if they are not global, but local to the C file |
| 21:25:40 | Araq | the 'merge' actually considers already generated IDs |
| 21:26:08 | Araq | however, it's possible that I was mistaken ... |
| 21:28:10 | Araq | but it should already help if we don't have to recompile a huge .c file every time |
| 21:28:36 | Araq | as nimdat.c was essentially always recompiled I think |
| 21:30:10 | Araq | btw 'runRodFiles' does not only recompile twice |
| 21:30:22 | Araq | it also models an edit operation |
| 21:30:38 | Araq | test "aconv" |
| 21:30:39 | Araq | test "bconv" |
| 21:31:06 | zahary | I added some support in the tester to run just the rodfiles tests |
| 21:36:47 | Araq | good |
| 22:33:46 | * | dom96 quit (Ping timeout: 250 seconds) |
| 22:36:34 | * | dom96 joined #nimrod |
| 23:05:21 | * | Amrykid quit (Read error: Operation timed out) |
| 23:08:34 | * | Amrykid joined #nimrod |