| 21:58:21 | * | NimBot joined #nimrod |
| 21:58:58 | reactormonk | zahary, what sould nimrod.nim be? the main project file? Or start a serve per file? |
| 21:59:44 | zahary | the main project file |
| 22:00:09 | reactormonk | Does it need to require all files? What of test files that are not included by the main file? |
| 22:00:17 | reactormonk | s/require/import/ |
| 22:01:14 | zahary | the compiler will do exactly what it does when compiling the project. if a module is directly on indirectly imported, then it's a part of the project |
| 22:01:44 | reactormonk | I have found that namespaces are not transitive |
| 22:01:57 | zahary | it should work with a directories featuring a nimrod.cfg file too (having a mainmodule: X directive) |
| 22:02:08 | Araq | nor should they be transitive o.O |
| 22:02:21 | reactormonk | Araq, I agree |
| 22:02:26 | Araq | you can use 'export' for that btw |
| 22:02:36 | reactormonk | Araq, haven't seen that |
| 22:03:02 | dom96 | zahary: why does it exit when a command is processed? |
| 22:03:25 | zahary | it shouldn't do that :) does it? |
| 22:04:24 | gradha | dom96: first nimbot and now the compiler? |
| 22:04:37 | dom96 | gradha: I'm on a killing spree. |
| 22:05:03 | dom96 | zahary: yeah, it does :( |
| 22:05:04 | reactormonk | dom96, hey! that's my task. |
| 22:06:17 | zahary | dom96, what do you do exactly? |
| 22:06:26 | zahary | I just tried in on the compiler itself |
| 22:06:32 | dom96 | nimrod serve --server.type:stdin aporia.nim |
| 22:06:51 | dom96 | idetools --track:aporia.nim,2184,6 --suggest aporia.nim |
| 22:07:01 | dom96 | Note that I added 'win.' on that line |
| 22:08:30 | zahary | hmm, I'm getting a C compilation error on Aporia (clang on mac os) |
| 22:09:22 | dom96 | what's the error? |
| 22:11:21 | zahary | looks like a marked for a global variable which is generated, but the global variable itself isn't (I'm using the mark and sweep GC now by default) |
| 22:11:33 | zahary | * marker * |
| 22:11:57 | zahary | use of undeclared identifier 'currexception_13224' |
| 22:12:08 | dom96 | I think gradha might have had a similar problem. |
| 22:14:43 | reactormonk | Araq, it works for objects but not for refs :-( |
| 22:15:10 | Araq | == for refs already exists |
| 22:15:20 | gradha | dom96: haven't touch Aporia for a long time, but yes, it crashes now on me too with the default gc |
| 22:15:45 | Araq | and you need to define 'ref' for $ |
| 22:15:47 | gradha | apparently a checkout from San Valentine day, lovely |
| 22:16:13 | Araq | dom96: you got the memory management wrong :P |
| 22:17:21 | gradha | I'll update the compiler and try again |
| 22:17:47 | reactormonk | Araq, should I mark ref in $ ? |
| 22:18:14 | dom96 | Araq: Care to be a bit more specific? |
| 22:18:37 | Araq | reactormonk: ugh, no |
| 22:18:51 | Araq | we have 'repr' for these things |
| 22:18:55 | reactormonk | Araq, ok |
| 22:19:03 | reactormonk | so let's implement repr for JS :-) |
| 22:19:23 | Araq | in fact, I don't really like $ for objects either but hrm |
| 22:19:41 | reactormonk | it's good to have a basic notion for those |
| 22:20:08 | Araq | yeah I guess |
| 22:20:18 | Araq | you can olways override it |
| 22:20:25 | reactormonk | That's the idea |
| 22:20:37 | reactormonk | hmm, reference equality should test the reference? |
| 22:20:57 | Araq | dom96: I remember you playing around with GC_ref and passing GC'ed memory to GTK |
| 22:21:39 | dom96 | yes, that could be it. |
| 22:22:11 | reactormonk | Because for now obj == obj is true for value and false for refs |
| 22:22:27 | gradha | hey, this error is new, on San Valentine day it was internal error: genStmts(nkNone), now it is genStmts(nkYieldStmt) |
| 22:22:56 | reactormonk | Should == for refs use the derefed ==? |
| 22:23:04 | gradha | will put this on github |
| 22:23:10 | Araq | reactormonk: don't mess with == for refs |
| 22:23:20 | reactormonk | Araq, guessed so :-/ |
| 22:23:25 | Araq | it obviously should *not* deref |
| 22:23:49 | reactormonk | Araq, so you have to overwrite ref and value for custom objects - good old equal vs. same |
| 22:25:52 | reactormonk | any motivation to resolve this? |
| 22:26:38 | Araq | x[] == y[] vs x == y |
| 22:26:48 | Araq | where x, y are refs |
| 22:27:43 | reactormonk | no shortcut for x[] == y[] that is transparent for refs? |
| 22:28:00 | Araq | you can introduce x === y for x[] == y[] and jump for joy |
| 22:28:19 | reactormonk | ... well, JS has reference semantics anywhere. |
| 22:28:41 | reactormonk | wait, they only have == anyway. Would be nice to have it though |
| 22:29:14 | Araq | what's the problem? the compiler does not have to produce JS's == for Nimrod's == |
| 22:30:06 | reactormonk | My problem is that you have to care about refs and non-refs in JS, or for code that works both in C and JS and that's I'd like the equal to be different on C and JS to take care of the different default semantics value vs. ref |
| 22:30:29 | Araq | o.o |
| 22:30:46 | reactormonk | given your reaction, you should care? |
| 22:31:45 | Araq | don't change Nimrod's semantics unnecessarily just because you happen to target JS |
| 22:32:21 | Araq | it's bad enough JS doesn't support 64bit integers etc. |
| 22:32:30 | reactormonk | My idea is to use a convention of 'equal' which changes depending on platform - not sure if that adds too much complexity that breaks |
| 22:32:59 | Araq | can't think of any use case where 'equal' is necessary or desired |
| 22:33:10 | dom96 | zahary: any ideas what the problem is? |
| 22:33:25 | reactormonk | Araq, ok. |
| 22:33:41 | reactormonk | Araq, pushed and tested. |
| 22:35:47 | Araq | proc `$`*[T: ref](x: T): string = $x[] # remove that again please |
| 22:36:13 | reactormonk | aww |
| 22:39:53 | Araq | when every type supports every operation there is not much type safety left :P |
| 22:40:17 | Araq | we used to support 'len' for everything for instance |
| 22:40:30 | Araq | it would transform len(x) into len([x]) into 1 |
| 22:41:05 | Araq | was very error prone |
| 22:41:29 | reactormonk | Referential transparency would help a bit imo |
| 22:43:18 | Araq | what has that to do with it? |
| 22:43:58 | reactormonk | let's see if it means what I think it means |
| 22:50:14 | gradha | reading on use of # as len synonim I made http://pastebin.com/bDG3LXLz to abuse unicode characters |
| 22:50:38 | gradha | doesn't work that well with the dot sugar syntax |
| 22:54:40 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 22:55:18 | * | zahary quit (Quit: Leaving.) |
| 23:00:38 | reactormonk | Araq, anyway, pull. |
| 23:00:43 | gour | Araq: what do you think about using wxC (part of wxhaskell project) to provide wx bindings for nimrod? |
| 23:02:55 | Araq | gour: I think it's a good idea if they are up to date and maintained |
| 23:05:13 | NimBot | Araq/Nimrod 5bf71d1 Simon Hafner [+1 ±0 -0]: added tests for == and $ |
| 23:05:13 | NimBot | Araq/Nimrod 1daa424 Simon Hafner [+0 ±2 -0]: added tests, actually implemented $ and == |
| 23:05:13 | NimBot | Araq/Nimrod 4186c1c Simon Hafner [+0 ±2 -0]: added $ for refs and removed == for ref test... 3 more lines |
| 23:05:13 | NimBot | Araq/Nimrod cc8a656 Simon Hafner [+0 ±2 -0]: removed `$` for refs upon request |
| 23:05:13 | NimBot | Araq/Nimrod 5862a9c Araq [+1 ±1 -0]: Merge pull request #341 from Tass/master... 3 more lines |
| 23:05:21 | gour | latest version of wxhaskell supports >= 2.9.x (https://github.com/jodonoghue/wxHaskell) not much recent work, but it seems everyone is waiting for 3.0 which was supposed to happen years ago :-/ |
| 23:08:38 | Araq | gour: the problem is that then you have to build and install libwxc.so |
| 23:08:45 | Araq | or whatever it's called |
| 23:09:12 | Araq | and I find these things so painful on linux that I avoid it like the plague :P |
| 23:09:16 | gour | what about claro? it would be ported to nimrod or still bindings via C? |
| 23:09:52 | Araq | ported to Nimrod, but gradually |
| 23:10:18 | gour | yeah that makes sense and it would be long-term solution for writing GUI apps |
| 23:12:18 | gour | it actually sounds as the best option if claro is, in the present state, capable-enough (aka rich-enough) gui toolkit |
| 23:12:58 | Araq | it has a canvas that you can draw onto with cairo |
| 23:13:13 | Araq | which is supposed to be used for custom widgets I think |
| 23:13:34 | Araq | apart from that it has a layout engine, buttons and the usual widgets |
| 23:13:59 | Araq | though their text editor widgets sucks iirc |
| 23:14:04 | * | fowl quit (Ping timeout: 256 seconds) |
| 23:14:06 | gour | what about 'general' widgets like buttons, menus, different dialogs etc.? |
| 23:15:21 | Araq | look at its include/widgets directory please |
| 23:16:44 | gour | looks as solid list |
| 23:17:34 | Araq | a table widget is missing though |
| 23:23:45 | reactormonk | I like the tk ones :-) |
| 23:25:23 | gour | i remember talks in haskell about reactive fp gui programming, D also wanted to have some 'native' toolkit, DWT was done for the purpose, so having native toolkit in nimrod would be extraordinary feature :-) |
| 23:29:40 | * | fowl joined #nimrod |
| 23:31:59 | Araq | looking at it again, it's still quite some work to give a native Nimrod interface |
| 23:34:15 | gour | what is the right solution for GUI in Nimrod then? writing cli apps? |
| 23:34:41 | * | Anaphaxeton quit (Quit: Αποχώρησε) |
| 23:35:00 | Araq | I'm just saying Claro still needs some love |
| 23:35:15 | Araq | but we should give it a try |
| 23:36:16 | * | fowl quit (Read error: Connection reset by peer) |
| 23:36:24 | dom96 | A native toolkit sounds like a fun project, but I already have too many projects :\ |
| 23:36:33 | gour | ok, that sounds better :-) |
| 23:37:02 | gour | dom96: step by step, as Araq wrote |
| 23:40:28 | Araq | NimBot didn't get the push |
| 23:40:43 | Araq | is there a way to trigger it manually from here? |
| 23:40:57 | dom96 | test hook |
| 23:42:12 | Araq | nah |
| 23:43:15 | Araq | I'll push again soon anyway |
| 23:43:34 | dom96 | hopefully I'll have NimBot fixed by tomorrow |
| 23:43:42 | dom96 | good night |
| 23:44:07 | Araq | good night |
| 23:45:04 | gour | if i understand properly, Claro does something like wx but for C instead of C++? |
| 23:45:08 | gour | night dom96 |
| 23:46:01 | Araq | gour: yes it has 3 backends, one for windows, one for gtk and one for cocoa |
| 23:46:25 | Araq | it's quite a thin layer over each of these |
| 23:48:16 | gour | how does it avoid 'install libwxc.so' problem pertinent to wx bindings? |
| 23:49:27 | Araq | we can add lots of {.compile: "file.c".} to the nimrod wrapper and embed it ;-) |
| 23:49:30 | Araq | but ok |
| 23:49:37 | Araq | we could do the same for wxC |
| 23:49:45 | * | gour nods |
| 23:50:09 | Araq | but libwxwidgets.so is not common on Linux either I think |
| 23:50:31 | Araq | and it's too bit to embed in the nimrod app |
| 23:50:59 | gour | considering the limited man power, it might be smart to save time and just use wx via wxC...there is not QtC, afaik |
| 23:51:42 | gour | at least as temporary solution until nimrod becomes (more) popular |
| 23:51:50 | Araq | but wxWidgets is much more bloated |
| 23:52:02 | Araq | and the API sucks |
| 23:52:13 | gour | right, but not complete wx has to be used |
| 23:52:21 | gour | API is another story |
| 23:52:23 | NimBot | Araq/Nimrod 4ed60c2 Araq [+0 ±1 -0]: added gradha's improvements for the times module (issue #231) |
| 23:52:23 | NimBot | Araq/Nimrod 8b48792 Araq [+1 ±2 -0]: Merge branch 'master' of github.com:Araq/Nimrod |
| 23:53:12 | gour | anyway, i believe asking about decent bindings/toolkit to write multi-platform apps in nimrod is not too much offtopic :-) |
| 23:54:01 | gour | i wonder if wx's API improved from 2.8 --> 2.9/3.0? |
| 23:54:40 | * | fowl joined #nimrod |
| 23:54:48 | Araq | it did, it now uses utf-8 everywhere I think |
| 23:54:55 | Araq | which is nice for nimrod |
| 23:55:48 | gour | but there was some hot discussion about wxString, iirc, Vadim was changing his mind about some stuff |
| 23:56:33 | gour | IP has two paid devs, but it looks as wx has one part-time dev |
| 23:56:38 | gour | *IUP |
| 23:57:54 | Araq | I'm not worried about that |
| 23:57:58 | gour | Qt is also big, nicely supported, but it would require support for C++ |
| 23:58:06 | gour | about wx? |
| 23:58:15 | Araq | wxWidgets is used widely enough that somebody would take over |
| 23:58:19 | fowl | Araq: i think some things have to change for c++ code generation |
| 23:58:38 | Araq | fowl: I'm listening |
| 23:59:11 | gour | otoh, i like ex concept and it's native on every platform (if we accept gtk on linux as native) |
| 23:59:28 | gour | *wx concept |
| 23:59:52 | fowl | Araq: ive read on stackoverflow that in c++ its convention to declare variables when you need them, opposed to in c declaring things at the beginning of the function |