00:19:25 | NimBot | Araq/Nimrod 587806e Araq [+0 ±5 -0]: FFI at compiletime improvements |
08:30:21 | * | zahary joined #nimrod |
13:00:19 | * | q66 joined #nimrod |
14:50:46 | * | zahary joined #nimrod |
15:00:18 | * | Araq_ joined #nimrod |
15:18:46 | * | reactormonk joined #nimrod |
19:05:10 | Araq | yay new nimbuild fails ... or github |
19:05:50 | Araq | dom96: have a look please |
19:05:58 | AlexLibman | Weight lifters consider muscle "failure" a good thing. |
19:07:49 | dom96 | ugh |
19:08:13 | dom96 | Araq: click test hook |
19:09:38 | NimBot | Araq/Nimrod 163113c Grzegorz Adam Hankiewicz [+0 ±1 -0]: Fixes tutorial pdf generation due to hierarchy depth.... 3 more lines |
19:09:38 | NimBot | Araq/Nimrod 9c91e9b Araq [+0 ±1 -0]: Merge pull request #294 from gradha/pr_fixes_pdf_generation... 3 more lines |
19:09:55 | Araq | I applied a pull request instead :P |
19:10:23 | Araq | oh btw |
19:10:26 | dom96 | Github decided to connect from a non-github hostname for some stupid reason |
19:10:35 | dom96 | 50-57-231-61.static.cloud-ips.com |
19:10:44 | Araq | I've implemented #295 |
19:10:57 | Araq | please add it to aporia so that I can see the results :P |
19:11:04 | * | Araq didn't test it ;-) |
19:11:16 | dom96 | lol |
19:28:19 | dom96 | These compiler diffs inspire me. |
19:31:44 | Araq | how so? |
19:32:16 | dom96 | they make me want to fix compiler bugs :P |
19:33:42 | Araq | the small diffs doesn't mean it way easy to *find* the bug :P |
19:33:46 | Araq | *it was |
19:34:38 | dom96 | well I was referring to your implementation of #295 to be honest. |
19:35:12 | Araq | alright, well I'll happily give the 'suggest' stuff to you ;-) |
19:35:42 | dom96 | sure. I can attempt it :P |
19:35:47 | dom96 | I already have a feature in mind. |
19:35:58 | dom96 | I'm still waiting on those patches from zahary though... |
19:36:14 | Araq | we all do ... |
21:31:29 | * | _ponce joined #nimrod |
21:31:35 | _ponce | hi |
21:31:39 | Araq | wb |
21:31:46 | _ponce | I'm trying to compile Aporia dom96 |
21:31:55 | dom96 | hello _ponce. |
21:32:00 | _ponce | hello |
21:32:01 | dom96 | _ponce: Having trouble? |
21:32:03 | _ponce | I get "utils.nim(59, 22) Error: undeclared identifier: 'PInfoBar'" |
21:32:14 | dom96 | You need to get the latest compiler from git. |
21:32:18 | _ponce | with Nimrod & Aporia git-head |
21:32:28 | dom96 | You need Nimrod git-head also. |
21:32:42 | _ponce | ok, I probably got this wrong :| |
21:32:58 | Araq | or maybe I broke it today ;-) |
21:33:39 | Araq | pushing triggers the auto tester so I push to run the tests ;-) |
21:33:41 | _ponce | I like being in trunk anyway |
21:34:05 | Araq | but I can change that workflow now that nimbuild supports branches :-) |
21:34:12 | _ponce | can we talk about the Javascript backend? |
21:34:48 | Araq | sure |
21:34:50 | _ponce | If I ever does a roguelike using libtcod-nim, would it be possible to port to Javascript? |
21:35:07 | _ponce | does it support DOM operation like createElement |
21:35:53 | Araq | possible to port ... I think so. easy? no ... |
21:36:31 | _ponce | well I would not do any call to libtcod in this js case |
21:36:55 | Araq | well tbh I'm not up to date with JS's capabilities |
21:37:13 | dom96 | certainly possible with HTML5's new fancy features |
21:37:37 | dom96 | Perhaps a port of the graphics module to the JS backend would be a good start. |
21:38:13 | Araq | I consider the JS platform different enough to not even try to share most libraries |
21:39:13 | _ponce | if we can output js with a pragma that should be good enough? |
21:39:25 | Araq | you can do that with today's compiler |
21:39:26 | _ponce | to create builtin objects like Audio |
21:39:31 | _ponce | fine! |
21:39:35 | Araq | the 'asm' statement is mapped to it :D |
21:40:54 | Araq | I know there is work going on to give JS unboxed datatypes and more low level features for porting C(++) code over |
21:41:36 | Araq | the current JS codegen doesn't use these fancy things ;-) |
21:41:47 | Araq | my target was IE6 or something :D |
21:42:18 | _ponce | I don't need that much performance, just a small game for tasting the language |
21:43:42 | * | gradha joined #nimrod |
21:44:11 | Araq | alright, well you can try if you can live with broken exception support for JS for now |
21:45:28 | _ponce | I simply can't live with JS :) |
21:45:41 | Araq | and expect to run into codegen bugs, though it was suprisingly stable for the examples that I tested |
21:49:15 | Araq | reactormonk: I implemented #295, please test it |
21:55:23 | NimBot | Araq/Nimrod 05d8aac Araq [+0 ±1 -0]: make some tests green |
21:55:23 | NimBot | Araq/Nimrod fa809d0 Araq [+0 ±3 -0]: Merge branch 'master' of github.com:Araq/Nimrod |
22:01:08 | Araq | btw dom96, nimbot again missed a push |
22:02:08 | dom96 | ugh, ok. I'll fix it. |
22:02:41 | Araq | it's nice that github keeps her API stable |
22:08:48 | dom96 | Fixed. |
22:08:57 | dom96 | Lets hope github doesn't use other hostnames... |
22:10:34 | NimBot | nimrod-code/nimbuild 2c56992 Dominik Picheta [+0 ±1 -0]: Whitelisted another hostname for the github module. |
22:11:37 | dom96 | whoa that was a bit slow |
22:11:57 | Araq | 7 minutes to fix it ain't slow |
22:12:20 | dom96 | I mean the lag between my push and the announce here. |
22:26:15 | gradha | cool, so now "files = json_params["files"].elems.each do (x: PJSonNode) -> string: x.str" compiles and wors, reducing about five lines to one |
22:27:01 | gradha | question: is it possible to get rid of the param type in the do notation? It's going to come from the each first param type anyway |
22:27:43 | Araq | gradha: not yet, it's planned though |
22:28:06 | gradha | amazing |
22:28:30 | Araq | I think you can leave it out already and it may work |
22:28:41 | Araq | but the semantics are different ;-) |
22:28:50 | dom96 | gradha: whoa. That looks pretty cool :D |
22:29:25 | * | Araq still thinks 'each' should be a template |
22:30:01 | Araq | and it should be called 'map' ;-) |
22:38:53 | Araq | dom96: 'findDefinition' calls 'quit' |
22:39:06 | Araq | can't see how that can loop endlessly ... |
22:39:54 | dom96 | it goes into a infinite recursion |
22:40:21 | Araq | maybe you use 'usages' instead? |
22:40:52 | dom96 | nope |
22:41:03 | dom96 | please test it in aporia |
22:41:25 | Araq | crashes my aporia :P |
22:41:45 | dom96 | do you have the latest? |
22:41:53 | Araq | on it |
22:42:03 | _ponce | Araq: I'm stuck in my Javascript experiments, I create a <canvas> node and append it to body, but I would need to call the getContext() function on it |
22:42:32 | Araq | _ponce: found the example? it's either in examples/ or tests/ ... |
22:42:35 | _ponce | and then this context would have a lot of 2D draw functions |
22:47:08 | Araq | sounds like you need to write some wrapper then, take a look at lib/ecmas/dom.nim |
22:48:20 | _ponce | does the DOM wrapper need compiler support or is fully in dom.nim? |
22:48:32 | Araq | fully in dom.nim |
22:48:35 | Araq | iirc |
22:48:48 | _ponce | yay |
22:49:31 | Araq | have a look at tests/js/test1.nim too |
22:50:15 | Araq | you need the 'exportc' pragma to export the stuff you call from within your html |
22:50:38 | Araq | otherwise the compiler optimizes it away :P |
23:10:17 | Araq | dom96: same with latest version, aporia crashes when I do 'find' ... argh |
23:10:28 | Araq | Error: unhandled exception: len(s) == 7 [EAssertionFailed] |
23:13:19 | Araq | dom96: fix that please so I can investigate the endless recursion |
23:16:42 | dom96 | yeah yeah. I'm fixing it now. |
23:18:52 | gradha | how do you use the do notation in a for loop? |
23:18:56 | gradha | I have the line "for even_number in filter(numbers, proc (x: int): bool = x mod 2 == 0):" |
23:18:59 | gradha | this works |
23:19:08 | gradha | but "for even_number in numbers.filter do (x: int) -> bool : x mod 2 == 0:" doesn't |
23:19:14 | gradha | Error: ':' expected |
23:19:22 | Araq | well yes |
23:19:44 | Araq | the 'do' notation is handicapped ... haven't looked at the underlying problem |
23:20:38 | gradha | will the do notation improve over time or will it be discarded? |
23:20:56 | Araq | the grammar is almost at its breaking point :-) |
23:21:02 | Araq | so it's hard to say |
23:21:30 | Araq | I want to rethink it from ground up |
23:22:05 | Araq | and change the spec accordingly while preserving as much compatibility with the old parser as possible |
23:22:22 | Araq | quite a challenge ;-) |
23:23:23 | Araq | but the 'do' notation provides a unique feature, so it'll stay |
23:23:44 | Araq | however the current restrictions may stay too |
23:32:56 | _ponce | ok got <canvas> drawing working https://dl.dropbox.com/u/541786/test.htm |
23:33:36 | _ponce | but lack of cast in the JS target made me merge TNode and the node specific to Canvas element |
23:34:13 | Araq | well what should 'cast' produce in JS? |
23:34:28 | Araq | no-op since it's dynamically typed? |
23:34:33 | _ponce | I guess a regular assignment |
23:34:38 | _ponce | yea no-op |
23:34:47 | _ponce | var a = b; // always work in js |
23:34:55 | Araq | ok, wait a sec |
23:38:32 | _ponce | maybe it's more complicated |
23:38:48 | Araq | why? |
23:39:07 | _ponce | since in js non-primitive types have reference semantics |
23:39:31 | _ponce | I don't know enough Nimrod semantics to say |
23:40:00 | Araq | well 'cast' is all about providing a loophole in the type system |
23:40:15 | Araq | so mapping it to a no-op for JS sounds very reasonable |
23:40:29 | _ponce | 'cast' should also work identical regardless of the target though |
23:40:49 | Araq | but that's unrealistic |
23:41:01 | _ponce | works for me then :) |
23:41:06 | Araq | it doesn't even work regardless of pointer bitwidths |
23:41:19 | Araq | for obvious reasons |
23:43:54 | _ponce | if I understand correctly, Nimrod's cast is C++'s reinterpret_cast? |
23:44:20 | _ponce | in this case, no problem |
23:44:39 | Araq | I think so, tbh I can't recall the details about C++'s cast operators |
23:45:06 | Araq | but usually you don't use 'cast' but a proper type conversion in Nimrod |
23:45:37 | Araq | 'cast' is inherently unchecked and unsafe (and easy to grep ;-) ) |
23:45:45 | _ponce | I always hated the conflation of bitwise-cast and type conversions in C and C++ |
23:45:53 | _ponce | gotta love the Pascal inspiration |
23:46:23 | Araq | actually it's my own invention, pascal copied C here |
23:46:42 | Araq | or maybe I copied it from Ada ... |
23:46:49 | _ponce | uh ok, I had different memories from Turbo Pascal |
23:47:23 | Araq | Turbo Pascal only has T(x) |
23:50:19 | Araq | _ponce: 'cast' should work for the JS target now |
23:51:13 | _ponce | that was pretty fast :) |
23:53:06 | Araq | I'm bored ;-) |
23:53:18 | Araq | waiting for dom96's bugfix so I can improve idetools |
23:53:36 | dom96 | You cannot rush a master. |
23:54:41 | Araq | I could answer on the D forum again but then ... ugh |
23:55:38 | Araq | nobody will understand me anyway |
23:57:47 | gradha | you are asking for trouble in D forums? |
23:58:42 | Araq | I don't ask for trouble, I sometimes post something |
23:59:15 | gradha | do they have a web interface or it's nntp? |
23:59:34 | Araq | I use the web interface |