| 00:12:15 | Araq | good night everyone |
| 00:12:30 | dom96 | I'm heading to bed as well. Bye. |
| 00:14:11 | * | q66 quit (Quit: Leaving..) |
| 08:52:41 | * | Trix[a]r_za is now known as Trixar_za |
| 09:45:39 | * | jyyou joined #nimrod |
| 09:47:30 | Araq | hi jyyou |
| 09:47:46 | jyyou | Araq: hi |
| 09:50:28 | dom96 | good morning |
| 09:55:05 | * | zahary joined #nimrod |
| 09:58:53 | Araq | good morning, dom96, zahary |
| 09:58:54 | Trixar_za | Good morning all |
| 09:59:56 | * | q66 joined #nimrod |
| 10:00:10 | Trixar_za | Wait. emacs has a Nimrod plugin? |
| 10:01:36 | Araq | Trixar_za: I think so, yeah; somebody put something on github ... |
| 10:02:01 | dom96 | I would guess it's more of a slightly modified python plugin |
| 10:02:29 | Trixar_za | Probably. That's how I wrote my geany syntax highlighter file |
| 10:02:40 | Trixar_za | Ironically, now I use Aporia instead |
| 10:02:52 | dom96 | yay :D |
| 10:05:26 | Trixar_za | I even packaged it for SliTaz: http://www.trixarian.net/downloads/aporia-0.1.2.tazpkg |
| 10:05:37 | Trixar_za | Which is funny since I haven't package Nimrod yet |
| 10:05:37 | Trixar_za | :P |
| 10:06:21 | dom96 | I'm hoping to release a new version of Aporia soon. |
| 10:06:34 | dom96 | I have too many features planned though. |
| 10:06:45 | dom96 | :P |
| 10:07:17 | Trixar_za | Well, one feature people have asked for was a Exit/Quit under the file menu :P |
| 10:07:45 | dom96 | Seriously? lol |
| 10:07:56 | Trixar_za | Yeah - lol |
| 10:08:28 | Araq | dom96: should be easy to add, right? |
| 10:08:33 | Trixar_za | I've compiled Aporia too. But my Aporia frequently hangs, have no 'Close' or 'Exit' entry in 'File' menu, and sometimes don't close own window by pressing on cross. Killall helps. I want to test your pkg. |
| 10:08:33 | dom96 | Araq: Sure |
| 10:08:43 | Trixar_za | That's a quote |
| 10:08:44 | Trixar_za | :P |
| 10:08:57 | Trixar_za | But he compiled Aporia without -d:release |
| 10:09:08 | dom96 | It should still work without -d:release |
| 10:09:22 | Araq | this is really frightening ... |
| 10:09:49 | dom96 | Araq: Are you thinking it's a Nimrod bug? |
| 10:10:11 | Trixar_za | It doesn't. It outputs key numerics in the terminal if you don't strip the debugger :/ |
| 10:10:18 | Trixar_za | And none of the keys work in it |
| 10:10:32 | dom96 | Well it should work. |
| 10:10:55 | dom96 | Some echos should have no affect on it. |
| 10:11:16 | dom96 | It works perfectly for me in debug mode. |
| 10:11:21 | Trixar_za | Also --opt:size and --opt:speed have similar issues with some keys not working. So with SliTaz atleast using -d:release gives a working copy |
| 10:11:54 | dom96 | What version of gtk do you have? |
| 10:12:17 | dom96 | I have actually found that on Arch Ctrl + F keys do not work. |
| 10:12:18 | Trixar_za | 2.24.10 |
| 10:12:55 | Araq | dom96: could be a subtle bug in the gtk wrapper |
| 10:12:58 | dom96 | Yeah, same as Arch's version. |
| 10:12:59 | Araq | or in your code |
| 10:13:15 | dom96 | or in Gtk :P |
| 10:13:52 | Araq | sure but I doubt it as that is not recompiled with different settings :P |
| 10:13:54 | dom96 | However it does seem to be something in my code. I have KeyRelease and KeyPress signals connected |
| 10:14:26 | dom96 | So that's a big risk factor, because those functions can stop keys from being pressed. |
| 10:14:45 | Araq | maybet these handlers are executed in some other thread ... |
| 10:15:53 | dom96 | Lets hope not... |
| 10:26:14 | zahary | yay, system.compiles :) |
| 10:26:47 | zahary | I want to add block version too (that tests semStmt on a nkStmtList) |
| 10:27:16 | Araq | feel free to do so |
| 10:27:55 | zahary | we'll need to improve the exception safety of the compiler to do that |
| 10:27:55 | zahary | for example, if the error is raised after a openScope, the matching closeScope won't be called |
| 10:28:17 | Araq | ? |
| 10:28:30 | Araq | it should work |
| 10:28:55 | Araq | but I suppose I should do an openScope/closeScope pair in semCompiles |
| 10:29:29 | Araq | so no symbol table manipulation is possible |
| 10:29:43 | Araq | on the other hand, I thought it could be useful |
| 10:29:54 | zahary | er, no? the context will be left in invalid state? the same goes for matching inc/dec calls for things like in*Context |
| 10:29:54 | Araq | when compiles(x): # introduces 'y' |
| 10:30:25 | Araq | there is only ERecoverable error that can be raised |
| 10:30:46 | Araq | any other exception indicates a bug I think |
| 10:31:01 | Araq | and the code takes care of ERecoverableError |
| 10:32:01 | zahary | hmm, let me look at some code, but I don't think I've seen any handling of ERecoverableError in the places I refer to |
| 10:33:26 | Araq | it's only handled on top level |
| 10:34:25 | Araq | in general so that no annoying following errors are generated |
| 10:34:49 | dom96 | What's this system.compiles? What does it do? |
| 10:34:53 | Trixar_za | And more reasons emailed to use Nimrod to code apps |
| 10:35:10 | Trixar_za | It always surprises me how resilient developers are to change |
| 10:36:48 | zahary | aha, I see the RecoverContext proc, but it doesn't handle the inc/dec pairs of calls |
| 10:38:50 | zahary | and you need something like "local" RecoverContext in semCompiles |
| 10:38:50 | Araq | which pairs do you mean? |
| 10:39:21 | dom96 | Does it check whether something compiles? |
| 10:39:27 | zahary | InGenericContext / InUnrolledContext |
| 10:39:30 | Araq | dom96: exactly |
| 10:39:59 | dom96 | But what is that something? Templates/macros? |
| 10:40:01 | Araq | zahary: ah yeah I forgot about those :-) |
| 10:40:15 | Araq | surely there are bugs left, but it's a good start |
| 10:40:42 | zahary | what I propose is to just start using the exception handling mechanisims |
| 10:40:42 | zahary | inc InGenericContext |
| 10:40:42 | zahary | finally: dec inGenericContext |
| 10:40:54 | Araq | I know |
| 10:41:00 | Araq | but I fear the overhead :P |
| 10:41:08 | zahary | it would be smarter to switch to C++ :) |
| 10:41:26 | Araq | not before I got 0.9.0 out :P |
| 10:42:19 | Araq | dom96: see http://forum.nimrod-code.org/t/56 |
| 10:42:44 | dom96 | thank you |
| 10:43:00 | Araq | however we know that c.inGenericContext == 0 in semCompiles (I think...) |
| 10:43:36 | Araq | though semExpr could increment that propably somehow |
| 10:44:58 | zahary | and if I add a block version, all bets are off |
| 10:45:59 | Araq | yep. |
| 10:46:08 | Araq | how would that be invoked btw? |
| 10:46:22 | Araq | let c = compiles: |
| 10:46:41 | Araq | block: |
| 10:46:45 | Araq | x == x |
| 10:46:47 | Araq | ? |
| 10:49:03 | zahary | yes, I think - maybe a string version too, because it's would be easier to combine with a when statement |
| 10:50:46 | dom96 | Araq: What should I call this more efficient acceptAddr? |
| 10:50:57 | Araq | 'acceptAddr' |
| 10:51:08 | Araq | no need for a new name, make an overload |
| 10:51:19 | dom96 | ok |
| 10:51:42 | Araq | zahary: I played with the idea to restrict 'compiles' much more |
| 10:51:59 | Araq | like only allowing nkCall and running the overloading resolution stuff |
| 10:52:20 | Araq | as I think it otherwise ties 'compiles' very heavily to the implementation |
| 10:52:45 | Araq | but it'd have been more work |
| 10:52:52 | Araq | and I know you wouldn't like it ;-) |
| 10:53:44 | zahary | the heavier version of compiles will be the major workhorse in the type constraints |
| 10:54:21 | Araq | fyi there is now a 'booting' define that I hope should help with changes in system.nim |
| 10:54:30 | Araq | and bootstrapping |
| 10:54:46 | Araq | I don't feel like always rebuilding the C code ... |
| 10:54:53 | zahary | in theory exception safe C++ compiler should perform just as good as now |
| 10:55:05 | Araq | I know |
| 10:55:15 | Araq | but I appreciate C's faster compile times |
| 10:56:17 | Araq | plus it's better for marketing reasons I guess |
| 10:57:03 | zahary | well, you can rightfully claim that nimrod can generate C code (the fact that C++ is supported as well is just a bonus) |
| 10:57:30 | zahary | but I don't see reason (marketing or otherwise) to avoid using C++ in the compiler itself |
| 10:58:09 | zahary | I'm not sure about the compilation speed - have to test this |
| 11:07:11 | Araq | btw if I have: int x[40] = {1, 2, ..} in C will it be put into a data section of the exe? |
| 11:07:26 | Araq | will 'const int' do it instead? |
| 11:08:26 | zahary | you mean if you have this inside a function? |
| 11:09:00 | Araq | no top level |
| 11:09:22 | zahary | then both int and const int will be in the data section |
| 11:12:42 | Araq | good |
| 11:12:51 | Araq | as we can't generate the 'const' for C++ ;-) |
| 11:13:01 | Araq | it's too strict with const ... |
| 11:19:07 | dom96 | hrm, I really like this Error list :D |
| 11:19:30 | dom96 | It would be cool if we could get some nice icons though :) |
| 11:27:26 | dom96 | "Error: unhandled exception: value 16 out of range [EOutOfRange]" |
| 11:27:30 | dom96 | I gotta say I'm puzzled |
| 11:29:35 | Araq | ugh that's exactly what I feared with the new integer promotion rules ... |
| 11:29:46 | Araq | if you do: |
| 11:30:03 | Araq | var x = y and 15 |
| 11:30:15 | Araq | x's type is not 'int' but range[0..15] |
| 11:30:39 | Araq | so if you update 'x' like 'x = 16' it will produce this error |
| 11:30:53 | dom96 | Yeah, the error should at least be more clear |
| 11:31:19 | dom96 | And it still doesn't make sense |
| 11:31:21 | Araq | ok will add it to my todo.txt |
| 12:10:57 | * | Trixar_za is now known as Trix[a]r_za |
| 12:16:29 | Araq | zahary: how does the type info stuff deal with types that span multiple modules? |
| 12:16:47 | Araq | that's why I put it all into a single C file in the first place |
| 12:30:11 | zahary | what kind of types are these? generic types? |
| 12:31:10 | Araq | moduleA.X = seq[moduleB.Y] ? |
| 12:31:10 | zahary | I always put the type info in the owner module |
| 12:31:18 | Araq | ok |
| 12:31:28 | Araq | and never close any C file? |
| 12:31:33 | zahary | yes |
| 12:31:48 | Araq | hrm, didn't affect anything, right? |
| 12:32:02 | Araq | well I did that for DCE already I guess |
| 12:32:12 | zahary | well, I asked you about the merging business that was not clear to me |
| 12:34:19 | zahary | you may want to take a look here |
| 12:34:20 | zahary | https://github.com/Araq/Nimrod/blob/e394a642e98663a784f42329e45d8082ba5a2536/compiler/cgen.nim#L1113 |
| 12:35:05 | zahary | how was pending=true used to be related to symbol files and merging? |
| 12:35:37 | zahary | the code there used to loop over the pending modules only |
| 12:38:25 | Araq | there is a comment that says: |
| 12:38:29 | Araq | # We need 2 different logics here: pending modules (including |
| 12:38:31 | Araq | # 'nim__dat') may require file merging for the combination of dead code |
| 12:38:32 | Araq | # elimination and incremental compilation! Non pending modules need no |
| 12:38:34 | Araq | # such logic and in fact the logic hurts for the main module at least; |
| 12:38:35 | Araq | # it would generate multiple 'main' procs, for instance. |
| 12:40:27 | Araq | I read it as: |
| 12:40:35 | Araq | the merge process fails for the main C file |
| 12:40:49 | Araq | and for other C files it's redundant and slow |
| 12:40:56 | Araq | if it's not a pending module |
| 12:45:14 | zahary | and pending used to mean "dead code elimination enabled"? (plus nimdat) |
| 12:45:17 | zahary | nothing more? |
| 12:46:48 | Araq | yeah I think so |
| 12:47:04 | Araq | there is no other feature that would require module pending |
| 12:47:34 | Araq | 'mergeRequired' looks pretty good though |
| 12:47:42 | Araq | so I think your change did no harm |
| 12:48:25 | zahary | ok, I can improve the code there some more - gPendingModule could be removed too because the new gModules is sufficient |
| 12:48:27 | * | Boscop joined #nimrod |
| 12:51:36 | Araq | so is it clear how C file merging is implemented? |
| 12:54:34 | zahary | i understand the mechanics of the merging itself (I think) - it's less clear to me what happens earlier in the compilation that leads to the fact that only the "new parts" of the module are present in memory |
| 12:55:17 | zahary | although not that unclear really - I guess the module is not compiled at all and only side-effects from generating other modules populate it (i.e. like inserting a typeinfo inside it) |
| 12:56:17 | Araq | exactly |
| 12:57:05 | zahary | and these ID sets like typeInfoMarker, etc are read from the rod files at some point? |
| 12:57:32 | zahary | to know what's already present in the previous compilation |
| 12:58:41 | Araq | they part of the C file :D |
| 12:58:52 | Araq | encoded in a comment |
| 12:58:55 | Araq | XD |
| 12:59:17 | Araq | couldn't be bothered to have backend info in the rodfile |
| 12:59:33 | zahary | yeah, I actually saw this binary comments :) but though they could be suplementary only |
| 13:01:33 | Araq | if rodfiles would know about backend stuff we wouldn't need a merge operation in the first place |
| 13:02:10 | Araq | I also considered to get rid of the 1-1 mapping from Nimrod module to .c file |
| 13:02:30 | Araq | but I think it's horrible for debugging |
| 13:02:38 | zahary | hmm, why so? |
| 13:02:56 | Araq | moduleA.1.c, moduleA.2.c, etc. |
| 13:03:05 | zahary | what's wrong with that? |
| 13:03:35 | Araq | well you know, sometimes even I do look at the generated C code ;-) |
| 13:03:36 | zahary | which file has my function? |
| 13:03:39 | Araq | yeah |
| 13:06:52 | zahary | it's a little inconvenience, but I think the possible benefits outweight it - we'll be able to split files is such chunks that you are more or less guaranteed that incremental compilation will always be very fast and once this is present we can do continuous compilation on the fly while the user edits the code |
| 13:08:20 | zahary | and it will be an option anyway so if you plan to spend a lot of time C debugging land you can turn it off for a while |
| 13:10:07 | Araq | if you make it happen, I may accept it |
| 13:10:21 | Araq | but "turn off" for debugging the compiler itself often does not work |
| 13:10:33 | Araq | as that could turn off the bug too |
| 13:11:22 | Araq | however I think we need this "compiler as a service" feature first |
| 13:11:34 | Araq | that listens to a socket |
| 13:11:58 | Araq | (yeah I know you told me and I said it's unnecessary...) |
| 13:12:21 | zahary | I will work on a DLL for now as it is much easier (no IPC layer) |
| 13:13:04 | zahary | if this works ok, adding socket interface will be easy |
| 13:14:25 | Araq | what's the gain of the DLL? |
| 13:14:35 | Araq | compiler part of stdlib? |
| 13:15:26 | dom96 | "compiler as a service" yes please. |
| 13:17:09 | zahary | the DLL is just another build of the compiler - instead of MainCommand that parses the command line, it exports all necessary functions to compile projects from another programs (like Aporia) |
| 13:17:53 | dom96 | That sounds nice. |
| 13:19:12 | zahary | and what's crucial is that I want to be able to keep the PContexts in memory to support various queries coming from the IDE |
| 13:30:49 | Araq | the hard part is not to keep everything in memory, but the incremental updates |
| 13:31:06 | Araq | but symbol files require that same logic |
| 13:31:31 | Araq | but we talked enough about this already :-) |
| 13:34:39 | zahary | yes |
| 14:52:54 | * | shevy quit (Ping timeout: 260 seconds) |
| 15:06:11 | * | shevy joined #nimrod |
| 19:00:46 | Araq | ping Boscop |
| 19:04:56 | Boscop | Araq, pong |
| 19:05:44 | Araq | am I correct that a coroutine is just a closure with all locals in the enviroment + some control flow modifications? |
| 19:06:51 | Boscop | yeah, coroutines and closures are isomorphic conceptually |
| 19:08:01 | Boscop | hm, but it seems to depend on the definition that people use |
| 19:08:56 | Boscop | e.g. http://blogs.igalia.com/vjaquez/2008/10/09/coroutines-closures-and-continuations/ |
| 19:09:43 | Araq | Lua's coroutines are "first shot" continuations iirc |
| 19:09:53 | Araq | but there was a paper that they are just as powerful |
| 19:11:49 | Boscop | one-shot continuations? |
| 19:12:04 | Araq | er, yeah |
| 19:12:14 | Araq | one-shot it was |
| 19:15:56 | Boscop | for simple generator/yield stuff it may be enough to use inversion of control and convert the generator function to a state-machine object, like C# does |
| 19:16:26 | Araq | but nimrod already supports simple generator/yield stuff |
| 19:16:31 | Boscop | ah |
| 19:16:52 | Araq | so I'm enhancing that to make iterators first class |
| 19:18:21 | Araq | the example on http://blogs.igalia.com/vjaquez/2008/10/09/coroutines-closures-and-continuations/ is confusing |
| 19:18:38 | Araq | the coroutine 'foo' restarts itself ... is that common? |
| 19:20:27 | Boscop | you can decide how you want it to behave. if it doesn't restart, some kind of end symbol (null/None etc) has to be returned |
| 19:20:59 | Araq | I'll let the implementation decide ;-) |
| 19:58:34 | Araq | hrm this seems to be ridiculously easy |
| 19:59:16 | Araq | it transforms every 'yield' into a 'return', adds a state field in the closure |
| 19:59:33 | Araq | and introduces some labels and gotos |
| 19:59:55 | dom96 | Awesome. After reading that article Boscop posted I'm very glad that Nimrod is getting coroutines :D |
| 20:06:12 | Araq | it seems to be aweful for exception handling |
| 20:06:25 | Araq | as it introduces jumps into a 'try' block |
| 20:07:10 | dom96 | Is there no way to make it play nice with exception handling? |
| 20:07:25 | Araq | dunno yet |
| 20:08:46 | Araq | I may simply disallow 'try' in a coroutine for the first version |
| 20:10:11 | dom96 | As long as it doesn't cause strange bugs then I'm fine with it :P |
| 20:14:13 | Araq | I'm thinking about keeping iterators as they are and instead allow 'yield' in procs |
| 20:14:29 | Araq | and if a proc contains a 'yield' it's translated to a coroutine |
| 20:14:33 | Araq | like in Python |
| 20:14:50 | shevy | hmm |
| 20:14:54 | Araq | for greenthreads the keyword 'iterator' would only be confusing |
| 20:15:01 | shevy | imagine if learning nimrod would be more fun than learning python |
| 20:16:08 | Araq | but it already is :P |
| 20:16:24 | Araq | if you value compiler error messages ;-) |
| 20:16:39 | shevy | well newcomers always struggle with errors in all languages |
| 20:16:47 | shevy | what annoys me in python is the python2 vs python3 transition |
| 20:16:49 | Araq | true |
| 20:16:52 | shevy | this kills all the fun in wanting to learn it for me |
| 20:16:53 | dom96 | How about a coroutine keyword? |
| 20:17:33 | Araq | dunno |
| 20:18:04 | Araq | for types it makes no difference: |
| 20:18:19 | Araq | type MyCoroutine = proc () {.closure.} |
| 20:18:46 | Araq | so 'proc' is justified |
| 20:20:06 | Araq | shevy: just ignore python 3 and use 2 as all the libraries do ;-) |
| 20:20:26 | Araq | and python 3's new unicode handling is worse than the old one IMHO |
| 20:21:02 | Araq | the other stuff isn't good either: I like '%' for string formating and 'print' without () |
| 20:21:38 | Araq | it's insane to change these things for a widespread scripting language |
| 20:21:45 | Nafai | I plan on never writing Python 3 code |
| 20:22:03 | Araq | and then they don't even name the exe 'python3' ... |
| 20:22:06 | Nafai | and I'm really trying not to write Python 2 code, but it seems the libraries I need are always available for it |
| 20:23:37 | Araq | Nafai: which libraries for example? |
| 20:24:47 | Nafai | hmm. an example I can think of for a project I wanted to recently do in Haskell was GDATA libraries and bindings for the Google APIs |
| 20:25:07 | Nafai | I would have started a particular project already in Haskell if they would have been around |
| 20:25:20 | Nafai | And writing Python isn't that exciting to me any more |
| 20:26:37 | Araq | yay another haskell programmer in #nimrod :-) |
| 20:28:22 | shevy | hehe |
| 20:29:00 | Nafai | as the years go on, I've become more and more an advocate of static typing :) |
| 20:29:50 | Araq | I never liked dynamic typing in the first place ;-) |
| 20:31:13 | Nafai | I realize I only like Python because it was the lesser of evils. It's not hard to beat C++ and Java though |
| 20:36:37 | Araq | I only like python's syntax, its semantics are stupid |
| 20:36:58 | Araq | except its collections like dicts, lists, tuples and their interactions |
| 20:37:14 | Araq | which work quite nicely |
| 20:37:29 | * | Nafai nods |
| 20:46:44 | zahary | one cool feature of the lua coroutines is that they allow for 2-way communication |
| 20:46:44 | zahary | for room in labyrinth(): |
| 20:46:44 | zahary | if room.hasDoor(Left): continue Left |
| 20:48:04 | Araq | continue left? |
| 20:48:31 | zahary | on the other side it looks like this |
| 20:48:31 | zahary | choice = yield room |
| 20:49:27 | Araq | just noticed that my way is broken btw as it can't yield in an arbitrary nested call chain |
| 20:49:42 | Araq | but that's a feature too as it simplifies the implementation |
| 20:49:57 | Araq | otherwise it would really need to take a snapshot of the stack |
| 20:50:30 | zahary | I linked a paper some time ago that provided some optimizations for nested iterators |
| 20:51:24 | zahary | also, the third way to implement recursive iterators is to transform the outer loop body into a closure and to pass that closure as an implicit argument to the iterator proc |
| 20:51:35 | zahary | but this doesn't allow you to treat iterators as first class values |
| 20:52:15 | Araq | yeah indeed |
| 20:52:39 | Araq | I also don't like it at all as it's a visitor |
| 20:52:54 | Araq | with its associated problems |
| 20:53:00 | Araq | (like inability to 'break' easily) |
| 20:53:23 | zahary | well, you cheat with special treatment of the return value, etc |
| 20:53:37 | Araq | sure |
| 20:54:22 | zahary | another viable compilation strategy IMO is to use the OS provided primitives such as fibers (activated by some pragma for example) |
| 20:55:30 | Araq | we've talked about this before but |
| 20:55:57 | Araq | it's natural to map a "unit" in a game to a coroutine, right? |
| 20:56:17 | zahary | haven't tried it myself, but some people are using it, yeah |
| 20:56:23 | Araq | and then stack snapshotting becomes too expensive anyway |
| 20:56:30 | Araq | I guess |
| 20:56:36 | zahary | I made a point then that most of the game code is trigger-based, which doesn't map nicely to coroutine |
| 20:57:55 | Araq | I remember, yes |
| 20:59:17 | Araq | there is a way to implement stack snapshotting in C |
| 20:59:33 | zahary | http://code.google.com/p/libconcurrency/ |
| 21:00:24 | zahary | but I guess the state machine approach will be nicer |
| 21:00:58 | zahary | why are you saying that it doesn't work? |
| 21:01:21 | Araq | it does work, but it's more limited |
| 21:01:27 | Nafai | So is nimrod's compilation strategy compiling via C? |
| 21:02:27 | Araq | Nafai: yes and I've frozen the plans to use LLVM instead |
| 21:03:03 | Araq | we need the stack copying too as it's just too cool, but it requires GC support |
| 21:03:39 | Araq | so I think I'll implement python's restriction (yield as keyword only in the co-routine itself) |
| 21:04:58 | Araq | but for the stack copying I'd prefer assembler code tbh |
| 21:05:08 | Araq | you never know what modern optimizers do ... |
| 21:05:47 | zahary | the C libraries use setjmp and stack switching, copying is a portable fallback (or something) |
| 21:06:39 | zahary | yeild only in the coroutine makes sense to me (the only way you can compile them to state machine) |
| 21:06:57 | Araq | oh yeah good point they often don't copy |
| 21:07:40 | Araq | the state machine is hard to do without 'goto'; will be a challenge to get that to work for the JS backend |
| 21:08:04 | Araq | fortunately iterators work and cover most common use cases :-) |
| 21:15:43 | Araq | see you later |
| 21:23:00 | zahary | I guess you can use continuation-passing style in javascript to emulate the jumping to the last line with goto |
| 21:24:28 | zahary | yeild is transformed into return [value, function() { rest of proc }] |
| 21:24:53 | zahary | pretty hacky and probably slow too - loops have to be transformed into recursive functions too |
| 22:45:11 | Araq | back |
| 22:45:18 | Araq | zahary: it seems better to transform any control flow into: |
| 22:45:22 | Araq | while (true) { |
| 22:45:30 | Araq | switch (state) { ... } } |
| 22:45:43 | Araq | for the JS backend |
| 22:50:31 | Araq | you can then implement 'goto Label' as 'state = labelNo; continue;' |
| 22:52:19 | zahary | I though about this, but it doesn't work for jumping inside a loop, doesn't it? |
| 22:52:36 | Araq | which loop? |
| 22:52:46 | Araq | any control structure is transformed to 'goto' |
| 22:52:55 | Araq | there is only one while loop left |
| 22:53:11 | Araq | forgot the name, it's kleeney's theorem or something |
| 22:53:48 | zahary | I see |
| 22:56:56 | dom96 | It's nice to see that you guys still take the JS backend into consideration :) |
| 22:57:45 | zahary | it adds cost to all control flow, but the coroutine related control flow is less expensive - probably it depends whether the function have a lot of yields or a lot of normal loops, ifs, etc |
| 23:03:42 | Araq | it's easy to do both: ordinary while loops and then in coroutines the other translation |
| 23:04:01 | Araq | however, I think it doesn't work with JS's exceptions |
| 23:04:29 | Araq | you need to map 'try' to JS's 'try' and you can't do that with the while/switch solutioon |
| 23:09:08 | Araq | speaking of which; try-except-finally is complete broken in the JS codegen |
| 23:09:33 | Araq | the other features that I tested work suprisingly well though |
| 23:10:27 | Araq | however, I thought more about this and ugh I really want the stack capturing for coroutines |
| 23:10:52 | Araq | Python styled is not good enough for parsers |
| 23:11:08 | Araq | or tree traversal |
| 23:11:24 | zahary | but stack capturing is easily delivered as library |
| 23:11:39 | zahary | so I don't see much need for compiler support there |
| 23:14:45 | Araq | matters little to me if it's in a library or in the compiler ;-) |
| 23:14:56 | zahary | about try finally and goto based couroutines… isn't it possible to statically determine what exceptions will be handled from error occurring on any line (respectfully any state)? case State_X: try { } catch (PossibleErrorsForX) |
| 23:15:25 | zahary | well, nimrod already supports interfacing with C and there are C libraries, so one can argue that it's already supported? |
| 23:23:41 | Araq | yeah but not really |
| 23:23:56 | Araq | it needs 'registerStack' and 'unregisterStack' for the GC |
| 23:24:08 | Araq | it's very easy to add these though |
| 23:25:02 | Araq | about the try finally: I don't know; however I think the state machine approach is taken by Google's Java to JS compiler |
| 23:25:43 | Araq | so there has to be a way to do it; unless of course they re-implement the exception handling stuff completely with 'goto' |
| 23:26:22 | Araq | I'd assume that V8 has some crazy optimizations to for their Java to JS compiler ... |
| 23:26:23 | zahary | you need the same kind of code for C/C++ too |
| 23:28:41 | Araq | hu? what do you mean? |
| 23:38:02 | zahary | you can not jump inside a try block from a duff's device |
| 23:38:08 | zahary | just tested it |
| 23:38:25 | Araq | yeah that's true |
| 23:41:06 | Araq | I'll simply disallow 'yield' within a 'try' ... |
| 23:41:17 | Araq | any better ideas |
| 23:41:19 | Araq | ? |
| 23:45:09 | zahary | well, this could be a start, but I think it's possible to determine which exceptions are to be expected in each state |
| 23:45:59 | Araq | how does that really help? |
| 23:46:10 | Araq | exception tracking is planned for other reasons |
| 23:46:21 | Araq | but I don't see how it solves the problem |
| 23:46:37 | Araq | rethrow? |
| 23:46:51 | Araq | so that you can sink the 'try' section? |
| 23:46:59 | zahary | it's interesting semantically what is supposed to happen if exception is thrown in the outer loop |
| 23:47:04 | zahary | why rethrow? |
| 23:47:29 | zahary | the way I see it the single try statements will be broken in multiple try statements just as it is broken in multiple states |
| 23:48:10 | Araq | that's the 'sinking' part yes |
| 23:50:00 | Araq | you need 'rethrow' to preserve the semantics |
| 23:52:15 | zahary | I don't follow - I imagine if the exception is handled, it will be followed by a normal "goto" to a next state |
| 23:53:57 | Araq | try {a;b} catch (e) |
| 23:54:07 | Araq | cannot be transformed into: |
| 23:54:17 | Araq | try {a} catch (e); try {b} catch (e); |
| 23:54:55 | Araq | and that's the easiest case (sequential execution), right? |
| 23:55:24 | Araq | in fact, I'm still thinking about how to transform that properly |
| 23:55:25 | zahary | I must be sleepy :) why isn't this equivalent? |
| 23:55:47 | zahary | aha, I got it |
| 23:56:12 | zahary | but try {a} catch(e) { goto end; } try {b} catch (e) ; end: .. |
| 23:56:16 | zahary | is this the same? |
| 23:56:52 | Araq | yeah true |
| 23:57:01 | Araq | right, we got the 'goto' command |
| 23:58:16 | Araq | now do: |
| 23:58:27 | Araq | try {a;b} finally {} :P |
| 23:58:53 | Araq | I think you need to rethrow here |
| 23:59:24 | * | Bosc0p joined #nimrod |
| 23:59:56 | zahary | well, sure - but the rethrow here is just a part of the regular catch block - user inserted reraise will do the same |