| 00:15:43 | fowl | it works somewhat :> https://gist.github.com/fowlmouth/5466040 |
| 00:20:49 | * | ack006 joined #nimrod |
| 00:22:14 | * | miki_ joined #nimrod |
| 00:22:26 | * | miki_ quit (Client Quit) |
| 00:22:39 | * | ack006 quit (Client Quit) |
| 00:22:53 | * | ack006 joined #nimrod |
| 00:27:50 | * | Trixar_za is now known as Trix[a]r_za |
| 00:32:02 | * | fowl quit (Ping timeout: 258 seconds) |
| 00:32:56 | * | ack006 quit (Quit: Leaving) |
| 03:47:48 | * | fowl joined #nimrod |
| 04:49:46 | * | OrionPK quit (Quit: Leaving) |
| 05:29:34 | * | r0bglees0n quit (Read error: Connection reset by peer) |
| 06:23:03 | * | Trix[a]r_za is now known as Trixar_za |
| 07:40:16 | * | Trixar_za is now known as Trix[a]r_za |
| 07:48:39 | * | Trix[a]r_za is now known as Trixar_za |
| 08:13:38 | * | Trixar_za is now known as Trix[a]r_za |
| 09:16:51 | * | gradha joined #nimrod |
| 09:22:47 | * | Trix[a]r_za is now known as Trixar_za |
| 09:29:15 | * | Trixar_za is now known as Trix[a]r_za |
| 09:33:17 | Araq | fowl: can you make a simple test for: table[field].needsRef = true is silently failing |
| 09:33:20 | Araq | I think I already know how to fix it :-) |
| 09:33:22 | Araq | but please make that a separate bug report |
| 09:34:04 | fowl | Araq: sure |
| 09:34:50 | Araq | and please have a look at #405 |
| 09:35:14 | Araq | I'm not sure what's wrong there, there is no comment node skipping afaik |
| 09:35:33 | Araq | most comments are AST attributes though and not a separate nkCommentStmt |
| 09:36:51 | fowl | i did try with dumptree and dumptree_imm a simple `proc foo = \n ## test \n stmt` and it worked fine |
| 09:37:47 | Araq | alright, I'll simply answer him |
| 09:47:13 | fowl | Araq: my components module is a beast now :) |
| 09:47:43 | Araq | so it works? |
| 09:48:00 | fowl | yes |
| 09:49:03 | fowl | https://github.com/fowlmouth/nimlibs/blob/master/examples/sdl_components.nim |
| 09:49:17 | Araq | now write a blog post about it and reddit it :-) |
| 09:50:11 | Araq | you should compare it to the Ruby version |
| 09:50:32 | Araq | and how you got to that Nimrod design |
| 09:50:44 | Araq | which I'm sure differs quite a lot from Ruby's |
| 09:52:41 | fowl | im not much of a writer >_____________> |
| 09:53:23 | Araq | me neither :-/ |
| 09:54:51 | fowl | when can i use `do` |
| 09:55:06 | Araq | it works with the new parser |
| 09:55:28 | Araq | I need to fix docgen with it and then I may merge it to master |
| 09:56:15 | Araq | hmm I guess it was a mistake to not create a new branch for the new JS codegen :-) |
| 09:56:31 | fowl | it would look like this right componentInterface(CVelocity, update) do (dt: float): |
| 09:56:43 | Araq | right |
| 09:57:05 | fowl | sweet |
| 10:05:13 | fowl | is there anyway to force a type for method dispatch, i want to call `foo` for PA on a PB is the only way around this to use a proc |
| 10:07:34 | Araq | yes, type conversions don't work for this |
| 10:09:13 | fowl | an explicit one should imo |
| 10:10:35 | fowl | i tried to run buildIndex in compiler/ and it built empty :/ |
| 10:14:37 | Araq | I don't know what that means |
| 10:15:19 | Araq | "explicit conversions should pretend dynamic dispatch" |
| 10:15:38 | Araq | I like that, it's a special case but many people think it should work this way |
| 10:15:43 | Araq | --> feature request ;-) |
| 10:15:57 | fowl | `nimrod buildIndex` |
| 10:16:08 | fowl | it says build an index for the whole documentation |
| 10:16:24 | Araq | yeah well check how koch.nim invokes it |
| 10:16:36 | Araq | you need to build the docs so that there .idx files |
| 10:16:51 | Araq | these .idx files are then collected via "buildIndex" |
| 10:16:57 | Araq | bbl |
| 10:17:08 | fowl | ah ok |
| 10:35:59 | * | q66 joined #nimrod |
| 10:36:55 | fowl | cool because then python-style super is possible |
| 10:45:09 | gradha | fixed a problem and added timings, it takes 30 minutes to generate http://dl.dropboxusercontent.com/u/145894/t/the_hyperlink_vs_nimrod.html |
| 10:48:57 | Araq | gradha: idetools is supposed to be invoked for '.' presses and the like, not for every single key press |
| 10:49:15 | Araq | so I'm not sure there is a performance problem |
| 10:49:56 | Araq | well I know there is one, that's why zahary started the "nimrod serve" mode |
| 11:02:24 | gradha | yes, I should have named this nimrod_raytracer |
| 11:17:38 | gradha | another reason for doing this brute force is that the output seems wrong for certain lines/columns, so displaying it in an easy way highlights bugs |
| 11:19:01 | gradha | for instance, if you hover over one of the constants, line 6, column 10, it spits out the file but points to line 6 column 14 |
| 11:19:18 | gradha | if 14 is a column number, shouldn't it point to the beginning of the word? |
| 11:19:30 | gradha | or maybe 14 is something else? |
| 11:43:47 | * | xcombelle joined #nimrod |
| 11:55:29 | gradha | of course it could be that I'm passing wrong line/cols to idetools |
| 11:57:07 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 11:58:50 | * | zahary joined #nimrod |
| 12:36:33 | * | gradha joined #nimrod |
| 12:37:29 | gradha | zahary: shouldn't nimrod serve have some sort of EOL concept when answering commands? |
| 12:41:58 | gradha | for instance, running idetools on a line/col with import won't return anything for --def or --usages, but I would expect the server to be chatty and say "nothing here, move along" as a kind of ack |
| 13:09:02 | Araq | I don't get asm.js ... how are you supposed to annotate non scalar types like "array of int"? |
| 13:09:35 | Araq | all you can do is |0 for ints and + for floats and crap like that |
| 13:09:57 | Araq | things that any JIT most likely knows already |
| 13:24:16 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 13:51:38 | * | xcombelle quit (Remote host closed the connection) |
| 14:27:00 | reactormonk | Araq, yeah, that's about it |
| 14:28:00 | Araq | well the spec is not finished yet |
| 14:28:23 | Araq | however I have no idea how the Unreal Engine could have been ported to that |
| 14:30:44 | zahary | it takes into considerations the typed javascript arrays AFAIK |
| 14:31:35 | dom96 | hello |
| 14:31:57 | zahary | but sure, they are not really equivalent to C arrays on the stack or as object data members |
| 14:34:34 | Araq | indeed https://developer.mozilla.org/en-US/docs/JavaScript/Typed_arrays is way more useful |
| 14:35:48 | Araq | well this means Nimrod's object can either be a "blob" or mapped to a JS object ... |
| 14:36:31 | Araq | and obj.x can compile to 2 vastly different things ... |
| 14:36:36 | dom96 | Araq: You're adding asm.js support? |
| 14:36:51 | Araq | planning it |
| 14:37:57 | Araq | I'm rewriting the JS backend to see how it works with an expr/stmt unification and it turns out it's much easier to do than I thought |
| 14:38:29 | dom96 | That's good news. |
| 14:39:26 | zahary | theoretically, the blob vs object choice can be applied on a per-type level |
| 14:39:52 | Araq | zahary: yeah it should be a blob unless the type is importc'ed or exportc'ed |
| 14:40:21 | Araq | but this still means the codegen needs to support both modes |
| 14:40:44 | zahary | well, there are some trade-offs in ease of debugging, etc. some pragmas that control the choice can be useful |
| 14:41:02 | Araq | hmm good point |
| 14:41:10 | Araq | I have no experience with JS debuggers though |
| 14:41:20 | zahary | they are pretty good |
| 14:48:59 | Araq | maybe only some types should become for blobs then for debugging experience, I don't know |
| 14:51:36 | zahary | well, one can easily use pragma push to have different setups for debug/release buidls |
| 14:57:59 | Araq | yeah except 'push' doesn't affect type pragmas, for better or worse |
| 15:00:03 | * | OrionPK joined #nimrod |
| 15:02:10 | zahary | hmm, is this on purpose? |
| 15:02:36 | Araq | yeah because unfortunately I re-used pragma names |
| 15:02:54 | Araq | "pure" for types means something different than for procs |
| 15:02:57 | zahary | there could be pushTypePragma or something |
| 15:03:03 | Araq | yeah |
| 15:03:33 | Araq | but then I find push/pop quite ugly, maybe there is a better way |
| 15:06:35 | dom96 | maybe you should allow macros to edit this "global pragma list", you could then have different lists for procs, templates, types and whatever else is needed. |
| 15:09:52 | zahary | well, top-level macros can edit the list right now by outputting pragmas |
| 15:10:59 | zahary | I don't thing push/pop is "ugly" semantically? do you dislike it in general or just the way it looks? |
| 15:11:23 | Araq | you can also easily do: {.pragma debug: exportc.} for a release build and {.pragma debug.} for a debug build |
| 15:11:42 | Araq | and annotate your types with that |
| 15:12:53 | zahary | exactly, I'll do {.pragma myjslib .} containing all the proper debug/release flags, but then I want to be lazy and just apply it to the whole file |
| 15:13:10 | reactormonk | $ |
| 15:15:22 | Araq | you could also pass all your code to a macro myjslib |
| 15:16:00 | Araq | I dunno, lets make a push type pragmas pragma then |
| 15:26:46 | Araq | ugh ... why can't NaCl simply win instead? |
| 15:29:21 | OrionPK | let me call up ballmer and ask him to add it to IE12 |
| 15:30:06 | Araq | IE's JS support is not on par with firefox's / chrome's either afaik |
| 15:30:13 | OrionPK | actually |
| 15:30:17 | OrionPK | it's faster from my tests |
| 15:30:20 | OrionPK | (surprisingly) |
| 15:30:28 | Araq | interesting |
| 15:30:40 | OrionPK | check out some jsperfs |
| 15:30:48 | Araq | what VM do they use now? |
| 15:30:57 | OrionPK | chakra? |
| 15:31:39 | OrionPK | http://jsperf.com/testingfloatarrays |
| 15:33:42 | OrionPK | IE10 doesnt get enough credit for how solid it really is, IE11 will be even better with WebGL support |
| 15:33:52 | OrionPK | (I'm still going to be using Chrome though xD) |
| 15:46:30 | dom96 | indeed. IE performance is becoming quite impressive. |
| 15:46:41 | dom96 | But i am a devoted Firefox fanboy :P |
| 15:47:50 | OrionPK | I was, up until chrome came out |
| 15:48:04 | OrionPK | it was too leaky, memorywise |
| 15:49:19 | dom96 | Have you tried it recently? |
| 15:49:28 | OrionPK | of course |
| 15:49:37 | OrionPK | im primarily a web developer |
| 15:49:45 | OrionPK | I dont use it for casual browsing though |
| 15:49:55 | dom96 | I think they have done a very good job addressing memory issues. |
| 15:50:04 | OrionPK | yeah, it's definitely a lot better now |
| 15:50:09 | OrionPK | than it was around the time chrome came out |
| 15:50:52 | dom96 | I especially love that it doesn't load all tabs at once now when it's launched. |
| 15:51:14 | dom96 | I am a major tab hoarder so I love that. |
| 15:51:42 | OrionPK | what ever happened to their crazy tab idea |
| 15:52:34 | dom96 | what was that? |
| 15:52:42 | OrionPK | trying to remember the details.. |
| 15:52:44 | OrionPK | tab groups? |
| 15:52:53 | OrionPK | http://www8.pcmag.com/media/images/252130-firefox-s-tab-groups.jpg |
| 15:53:23 | dom96 | oh yeah |
| 15:53:26 | dom96 | That's still there. |
| 15:53:30 | dom96 | It's a great feature also. |
| 15:53:37 | OrionPK | nice |
| 15:53:52 | dom96 | I actually forgot it exists heh |
| 15:55:04 | dom96 | I haven't used it when it was introduced because it encouraged me to have even more tabs open at once (at the time when it was introduced all tabs were loaded at once IIRC). |
| 15:56:14 | OrionPK | lol |
| 15:56:31 | OrionPK | u reminded me, I used to run IRC through firefox. |
| 17:02:59 | NimBot | nimrod-code/Aporia 1e944df Dominik Picheta [+0 ±3 -0]: Fixes highlight not being reset when typing. |
| 17:02:59 | NimBot | nimrod-code/Aporia 29de364 Dominik Picheta [+0 ±1 -0]: Bugfix: Highlighted words are now preserved across tabs. |
| 17:02:59 | NimBot | nimrod-code/Aporia 114e0c9 Dominik Picheta [+0 ±2 -0]: Bugfix: Files saved in /tmp get a special label again. |
| 17:02:59 | NimBot | nimrod-code/Aporia 2566116 Dominik Picheta [+0 ±2 -0]: Bugfix: Unsaved tabs are no longer added to the recently closed list. |
| 17:47:55 | * | zahary quit (Quit: Leaving.) |
| 20:53:51 | * | zahary joined #nimrod |
| 20:56:19 | Araq | zahary: people here long for 'nimrod serve' to work if you haven't noticed already ... ;-) |
| 21:04:38 | zahary | yeah, me too, but my new job is still mostly killing me |
| 21:04:51 | zahary | it should get better with time |
| 21:06:18 | Araq | alright so you have nothing in the pipeline and I can fix it should I feel like it :-) |
| 21:08:10 | zahary | I have plans for next tasks there, but feel free to work on it |
| 21:08:48 | zahary | in particular, I'm more interested in continuous compilation. it seems most people here care about the suggest feature that I haven't though through yet |
| 21:09:33 | zahary | there are certain problems, because suggest is just another compiler run and it must be isolated somehow (to not produce side effects) |
| 21:09:45 | Araq | indeed 'suggest' is what they want |
| 21:10:49 | Araq | btw I noticed the compiler now lists instantiations in its output |
| 21:11:06 | Araq | is that a new bug caused by your changes how generics are handled? |
| 21:11:14 | Araq | or it I simply miss that bug befores? |
| 21:11:17 | Araq | *before |
| 21:11:47 | zahary | what do you mean by "lists"? |
| 21:11:50 | zahary | in error messages? |
| 21:12:06 | Araq | yes; this means that an instantiation is put persistently into the symbol table |
| 21:12:16 | Araq | well I think it means that |
| 21:13:56 | zahary | hmm, but it always listed instantiations (similar to templates)? I'm still not sure whether we are talking about the same thing |
| 21:15:16 | Araq | type mismatch: got foo(int, int) but expected: foo(float, float); foo(T, T) # where foo(float, float) only exists as an instantiation |
| 21:16:15 | zahary | I see. |
| 21:17:17 | zahary | could be a bug of mine, but I can't think of any particular change that may be suspicious. the most significant thing I changed is where the instantiation cache is stored |
| 21:18:46 | Araq | it can happen if you changed scopes I think |
| 21:19:20 | Araq | for recursive generic procs it is added to the symbol table I think |
| 21:19:32 | Araq | but to an inner scope |
| 21:19:49 | Araq | oh well, I'll look into it |
| 21:21:23 | zahary | there is an addDecl call in instantiateBody |
| 21:22:07 | zahary | but maybe it always was there. there seems to be an openScope in generateInstance before calling instantiateBody |
| 21:26:16 | Araq | actually the addDecl shouldn't be necessary at all |
| 21:26:45 | Araq | instead the "merging" of instantiations should prevent recursive instantiations |
| 21:27:21 | fowl | is there a way to stringify T here for the warning: https://github.com/fowlmouth/nimlibs/blob/master/fowltek/tmaybe.nim#L12 |
| 21:28:41 | zahary | there is name(T: typedesc) in the typetraits module |
| 21:29:29 | Araq | yeah and thanks to that I mustn't change types.TypeToString :P |
| 21:30:24 | Araq | but it's fine, better than code duplication |
| 21:30:45 | fowl | cool |
| 21:36:01 | Araq | fowl: do you want to fix the 'tab[x].flag = true' bug? |
| 21:36:13 | Araq | you need to do: |
| 21:36:26 | fowl | im having trouble replicating it |
| 21:38:38 | Araq | proc copyValue(n: PNode): PNode = if n.kind == nkRefTy: n else: n.copyTree |
| 21:38:56 | Araq | and then replace the right copyTree calls by calls to copyValue in evals.nim |
| 21:41:32 | Araq | where "right calls" means almost everywhere except for mNCopyNimTree |
| 21:41:38 | Araq | and perhaps a few others :P |
| 22:59:38 | * | zahary quit (Quit: Leaving.) |
| 23:02:50 | * | fowl quit (Ping timeout: 258 seconds) |
| 23:20:13 | * | fowl joined #nimrod |