| 00:00:19 | * | flaviu joined #nimrod |
| 00:07:57 | * | nande joined #nimrod |
| 00:21:46 | * | superfunc quit (Ping timeout: 272 seconds) |
| 00:36:06 | NimBot | Araq/Nimrod devel 057b53e Araq [+0 ±6 -0]: 'lambda' is no keyword anymore |
| 00:36:06 | NimBot | Araq/Nimrod devel 68accb5 Araq [+0 ±1 -0]: setMaxPoolSize improvements |
| 00:36:06 | NimBot | Araq/Nimrod devel 32197b7 Araq [+0 ±1 -0]: fixes #1456 |
| 00:36:06 | NimBot | Araq/Nimrod devel 0914b48 Araq [+0 ±4 -0]: 'parallel' statement works again |
| 00:36:06 | NimBot | 1 more commits. |
| 00:56:22 | Skrylar | http://superuser.com/questions/792607/why-does-windows-think-that-my-wireless-keyboard-is-a-toaster bahaha |
| 01:09:49 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 01:21:16 | * | Jehan_ quit (Quit: Leaving) |
| 01:37:15 | * | q66 quit (Quit: Leaving) |
| 01:38:38 | * | adoniscik quit (Ping timeout: 250 seconds) |
| 01:53:44 | bogen | Araq: c_alloca does not exist. Is it ok if I add it to ansi_c.nim ? c_memcpy and c_fwrite are there. those are the only c functions I need for nimecho. (I assume a .compilerProc. generates the appropiate looping so that I get the size to allocate, and then to do the copies) |
| 01:55:00 | bogen | hmmm.... alloca is not in the ansi standard.... it is on Linux, BSDs, and Windows |
| 01:58:18 | bogen | I guess I could just use malloc/free which is safer and typically fast if there is not an interruption so that the malloc/free are back to back. I'll go with c_malloc and c_free for now, in lieu of adding c_alloca |
| 02:27:49 | OrionPK | i vote for adding alloca |
| 02:29:09 | def- | bogen: why not alloca from system.nim? |
| 02:30:51 | def- | Or did I imagine that proc being there |
| 02:32:21 | * | bogen thinks def- did imagine that... |
| 02:32:34 | def- | Yeah, can't find it anymore, strange |
| 02:33:44 | def- | Ah, I saw it used here and didn't notice the declaration at the top: http://forum.nimrod-lang.org/t/499 |
| 02:36:12 | bogen | yeah, there should be directive to say "if the is variable is returned from this proc (or placed in a global, or placed into an object that is returned), then have the complier puke it back to the programmer and stop" |
| 02:36:29 | bogen | if this variable... |
| 02:48:11 | bogen | lib/nimrod/system/sysio.nim(68, 2) Error: undeclared identifier: 'sysFatal' ? |
| 02:48:32 | bogen | Hint: sysio [Processing] lib/nimrod/system/sysio.nim(68, 2) Error: undeclared identifier: 'sysFatal' |
| 02:52:08 | def- | bogen: strange, devel branch? |
| 02:52:32 | bogen | yeah, on an " |
| 02:52:35 | bogen | system/sysio |
| 02:52:43 | bogen | import system/sysio |
| 02:52:57 | def- | i don't think you're supposed to import it directly |
| 02:53:07 | bogen | actually, no |
| 02:53:11 | def- | since it's included in system.nim already |
| 02:53:22 | def- | and system.nim defines the sysFatal template |
| 02:55:20 | bogen | I'm using the release compiler, on code outside the nimrod source |
| 02:55:21 | bogen | maybe I should use the devel branch |
| 02:57:14 | def- | but still you shouldn't import system/sysio at all I think |
| 02:58:13 | bogen | yeah, I commented out and it is fine |
| 03:02:52 | bogen | my laptop would likely take 10 or 20 minutes (maybe hours build to gcc)... This builds in a very decent time :) |
| 03:10:20 | * | govg_ quit (Quit: leaving) |
| 03:12:13 | bogen | how can I do pointer arithmetic? Or address of a cstring index? (After all, my code is unsafe already, as I'm using c_alloca and c_memcpy...) |
| 03:12:14 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 03:14:07 | OrionPK | bogen https://github.com/fowlmouth/nimlibs/blob/master/fowltek/pointer_arithm.nim |
| 03:14:42 | * | superfunc joined #nimrod |
| 03:14:44 | bogen | thanks, offset is what I need... |
| 03:16:48 | bogen | hmmm... that code makes the assumption that pointers and ints are the same size |
| 03:18:04 | * | flaviu quit (Ping timeout: 240 seconds) |
| 03:18:19 | def- | pointers and ints are the same size in nimrod |
| 03:19:10 | bogen | as they should be... |
| 03:19:29 | * | superfunc quit (Client Quit) |
| 03:19:54 | def- | good night |
| 03:19:59 | bogen | night |
| 03:37:50 | * | adoniscik joined #nimrod |
| 04:03:16 | * | brson quit (Quit: leaving) |
| 04:07:59 | * | kshlm joined #nimrod |
| 04:10:40 | * | saml_ joined #nimrod |
| 04:30:59 | * | Fx00F quit (Quit: leaving) |
| 04:52:02 | * | adoniscik quit (Ping timeout: 255 seconds) |
| 05:07:47 | * | johnsoft quit (Ping timeout: 255 seconds) |
| 05:50:30 | * | adoniscik joined #nimrod |
| 06:03:40 | * | saml_ quit (Quit: Leaving) |
| 06:12:36 | * | nande quit (Read error: Connection reset by peer) |
| 06:16:56 | * | ome joined #nimrod |
| 06:20:39 | * | Demos quit (Read error: Connection reset by peer) |
| 06:26:22 | bogen | https://gist.github.com/bogen/e41e2ca5e197279659bc echo that will handle embedded nuls |
| 06:48:04 | * | adoniscik quit (Ping timeout: 240 seconds) |
| 07:01:20 | * | gkoller joined #nimrod |
| 07:06:01 | * | kunev joined #nimrod |
| 07:28:33 | * | gkoller quit (Quit: Textual IRC Client: www.textualapp.com) |
| 07:29:32 | * | gkoller joined #nimrod |
| 07:30:20 | * | gkoller quit (Client Quit) |
| 07:31:23 | * | gkoller joined #nimrod |
| 07:32:30 | * | gkoller quit (Client Quit) |
| 07:32:59 | * | gkoller joined #nimrod |
| 07:33:34 | * | gkoller quit (Client Quit) |
| 07:34:04 | * | gkoller joined #nimrod |
| 07:34:11 | * | gkoller quit (Client Quit) |
| 07:34:43 | * | gkoller joined #nimrod |
| 07:34:54 | * | gkoller quit (Client Quit) |
| 07:35:17 | * | gkoller joined #nimrod |
| 07:35:43 | * | gkoller quit (Client Quit) |
| 07:36:03 | * | gkoller joined #nimrod |
| 07:36:14 | * | PavelVozenilek joined #nimrod |
| 07:39:26 | * | PavelVozenilek quit (Client Quit) |
| 07:46:51 | Araq | bogen: I don't think a .compilerProc can have varargs[string, `$`] |
| 07:48:03 | Araq | and I already said, I'll change the spec, I don't like these hidden concatenations, no matter if you do them with join/alloca/malloc |
| 07:56:11 | NimBot | Araq/Nimrod devel abf5112 Araq [+0 ±1 -0]: nice error message |
| 07:56:11 | NimBot | Araq/Nimrod devel fd086ab Araq [+0 ±1 -0]: fixes #1456 |
| 08:34:41 | * | zahary joined #nimrod |
| 08:50:21 | bogen | yeah, no problem. I'm learning either way. printf ("%s%s%s\n", a, b, c); is still a concatenation, just pushed off to the C libary :) |
| 08:52:33 | bogen | library,.. |
| 08:55:05 | bogen | I like the not having to use ( ) for proc calls |
| 09:12:40 | bogen | printf ("%s%s%s\n", a, b, c); on the backend to me has to do with C not having the equivalent of Pascal's writeln, and it stops on nuls because C uses nul-terminated strings not counted strings |
| 09:24:04 | bogen | a pascal backend would be less alien than a c backend |
| 09:41:17 | bogen | but fpc's writeln does not look thread safe |
| 09:41:58 | * | Araq_ joined #nimrod |
| 09:43:43 | Araq_ | bogen: feel free, most new features are implemented as AST to AST transformations so that new backends can be smaller |
| 09:44:13 | bogen | I'd be more interested in VM backend if I were to do a backend |
| 09:44:32 | Araq_ | we have a VM backend |
| 09:44:55 | bogen | for internal, can that be the final executable? |
| 09:45:17 | bogen | (I know the interactive mode and macros uses the VM) |
| 09:48:26 | Araq_ | I have enhancements in some branch ... (as usual) |
| 09:48:50 | Araq_ | with these the VM can be exposed as a module |
| 09:49:07 | Araq_ | which you can import in your program |
| 09:55:03 | bogen | in going through the issues I found a couple where the vm did the correct thing and the compiled code did not ( #1137 and #916) |
| 09:56:12 | Araq_ | there are many more where it's the other way round |
| 09:57:37 | bogen | yeah, especially since the c imports are not working (and other stuff). heh, on arch nimrod 0.9.4-2 reports itself as Version 0.9.5 (2014-05-02) |
| 10:02:20 | Araq_ | that is fine, there is no version 0.9.5 |
| 10:02:43 | Araq_ | odd number means development build |
| 10:05:57 | * | EXetoC joined #nimrod |
| 10:06:02 | bogen | yeah, that is what I'm getting at, on Arch Linux the nimrod 0.9.4-2 package contains a development build, not the released version |
| 10:10:09 | * | EXetoC quit (Client Quit) |
| 10:10:55 | * | Araq_ quit (Read error: Connection reset by peer) |
| 10:10:59 | * | Mat3 joined #nimrod |
| 10:11:16 | * | Araq_ joined #nimrod |
| 10:11:34 | * | Mat3 quit (Client Quit) |
| 10:12:23 | Araq_ | well there is no official 0.9.4-2 either |
| 10:12:37 | bogen | well, -2 is the package version |
| 10:12:59 | bogen | if they had to repackage |
| 10:14:51 | bogen | I'm going to start looking into the Codegen tagged issues, since I'm likely not going to get anywhere now with #1137 |
| 10:16:22 | Araq_ | nice |
| 10:16:38 | Araq_ | I guess this means the tagging was a really good idea |
| 10:17:29 | * | Trustable joined #nimrod |
| 10:19:39 | Araq_ | did you figure out appf etc by now? |
| 10:21:03 | * | kaushal_ joined #nimrod |
| 10:22:35 | * | milosn joined #nimrod |
| 10:23:26 | * | milosn_ quit (Ping timeout: 240 seconds) |
| 10:23:27 | * | kshlm quit (Ping timeout: 240 seconds) |
| 10:29:32 | bogen | I can coerce appf/linefmt into giving me the output I'm looking for (though I'm not completely comfortable with them yet). just need more practice with them. I'll need to dig more into PNode as well. |
| 10:30:21 | bogen | and BProc, but I'll get the hang of it |
| 10:30:33 | * | kaushal_ quit (Quit: Konversation terminated!) |
| 10:39:08 | Araq_ | ok |
| 10:40:57 | bogen | so you are going to change the spec for echo to say embedded nuls are not supported? |
| 10:41:20 | Araq_ | no, that it is not thread safe |
| 10:41:36 | Araq_ | for thread safety you should use & instead of , |
| 10:44:02 | bogen | oh, then I could address #1137 with by laying down as many fwrites as needed (no concatenation) followed by the trailing newline, but & would not guarantee thread safety, because the trailing newline would have to be part of a single fwrite |
| 10:44:52 | bogen | the current implmentation is thread safe, print is doing the concatenation, adding the final newline, then writing it |
| 10:45:28 | bogen | oh, it sitll might be thread safe |
| 10:46:42 | bogen | no, it might not be, I've seen stuff where without the new line (not in nimrod, elsewhere) two lines get joined |
| 10:46:54 | bogen | and you get an extra newline |
| 10:47:12 | bogen | (when multiple threads are writing to stodout) |
| 10:47:31 | bogen | stdout |
| 10:48:22 | Araq_ | damn, this is a good point |
| 10:50:01 | Araq_ | I missed the implicit \n |
| 10:51:31 | bogen | yeah, printf ("%s%s%s\n",a,b,c) is thread safe, echo a&b&c with some other implemenation (not a single frwite) is not guaranteed to be safe (without a lock) |
| 10:52:40 | bogen | puts and print are the only way to get implicit\n, and both stop at nul |
| 10:52:44 | bogen | printf |
| 10:53:57 | Araq_ | well then people need to use a lock for thread safety... hrmpf |
| 10:56:43 | bogen | well, that is only if #1137 is adressed (and not just closed with a "won't fix"), because the current implementation is thread safe from my experience. |
| 10:58:18 | Araq_ | well the "won't fix" is growing on me too |
| 10:59:22 | bogen | yeah, and change the spec to say nuls are not supported |
| 11:06:56 | Araq_ | yeah, let's do that |
| 11:09:46 | * | johnsoft joined #nimrod |
| 11:11:33 | * | zahary quit (Quit: Leaving.) |
| 11:12:34 | * | zahary joined #nimrod |
| 11:20:04 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 29.0/20140421221237]) |
| 11:50:03 | * | zahary quit (Quit: Leaving.) |
| 12:35:37 | * | untitaker quit (Ping timeout: 245 seconds) |
| 12:42:11 | * | untitaker joined #nimrod |
| 13:15:09 | * | zahary joined #nimrod |
| 13:19:38 | * | darkf quit (Quit: Leaving) |
| 13:34:52 | * | EXetoC joined #nimrod |
| 13:37:31 | * | ome quit (Quit: Connection closed for inactivity) |
| 13:42:05 | * | zahary quit (Quit: Leaving.) |
| 13:45:46 | * | zahary joined #nimrod |
| 13:56:26 | * | ics joined #nimrod |
| 14:45:11 | * | Demos joined #nimrod |
| 15:38:22 | * | gkoller quit (Ping timeout: 255 seconds) |
| 15:42:12 | * | kunev quit (Quit: leaving) |
| 15:59:16 | * | io2 joined #nimrod |
| 16:29:02 | * | adoniscik joined #nimrod |
| 16:29:31 | * | bogen1 joined #nimrod |
| 16:46:07 | * | gkoller joined #nimrod |
| 16:46:57 | * | gkoller quit (Client Quit) |
| 16:47:52 | * | gkoller joined #nimrod |
| 16:47:54 | * | gkoller quit (Client Quit) |
| 16:49:21 | * | Joe_knock joined #nimrod |
| 16:49:46 | * | Joe_knock quit (Max SendQ exceeded) |
| 16:50:14 | * | Joe_knock joined #nimrod |
| 16:51:12 | * | Joe_knock quit (Max SendQ exceeded) |
| 16:51:48 | * | Joe_knock joined #nimrod |
| 16:52:12 | * | Joe_knock quit (Max SendQ exceeded) |
| 16:52:27 | * | shodan45 joined #nimrod |
| 16:52:41 | * | Joe_knock joined #nimrod |
| 16:53:39 | * | Joe_knock quit (Max SendQ exceeded) |
| 16:54:07 | * | Joe_knock joined #nimrod |
| 16:54:58 | * | Joe_knock quit (Max SendQ exceeded) |
| 16:55:24 | * | Joe_knock joined #nimrod |
| 16:55:55 | * | Joe_knock quit (Read error: Connection reset by peer) |
| 17:05:33 | * | zahary quit (Quit: Leaving.) |
| 17:12:23 | * | adoniscik quit (Ping timeout: 240 seconds) |
| 17:16:07 | * | q66 joined #nimrod |
| 17:18:13 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 17:23:32 | * | EXetoC joined #nimrod |
| 17:37:51 | * | Joe_knock joined #nimrod |
| 17:38:14 | * | Joe_knock quit (Max SendQ exceeded) |
| 17:38:29 | * | BlameStross joined #nimrod |
| 17:38:40 | * | Joe_knock joined #nimrod |
| 17:38:50 | * | BlameStross left #nimrod (#nimrod) |
| 17:39:32 | * | Joe_knock quit (Max SendQ exceeded) |
| 17:40:03 | * | Joe_knock joined #nimrod |
| 17:40:57 | * | Joe_knock quit (Max SendQ exceeded) |
| 17:41:24 | * | Joe_knock joined #nimrod |
| 17:42:16 | * | Joe_knock quit (Max SendQ exceeded) |
| 17:42:45 | * | Joe_knock joined #nimrod |
| 17:42:52 | * | Joe_knock quit (Read error: Connection reset by peer) |
| 17:47:16 | * | brson joined #nimrod |
| 17:51:53 | * | julienaubert joined #nimrod |
| 17:52:17 | julienaubert | Araq - saw the commit! cool! |
| 17:56:20 | * | adoniscik joined #nimrod |
| 18:02:01 | def- | Araq: you wrote about VM as a module earlier today. Would that allow using Nimrod as a scripting language inside a Nimrod program? |
| 18:06:38 | * | silven quit (Remote host closed the connection) |
| 18:17:37 | * | Joe_knock joined #nimrod |
| 18:18:00 | * | Joe_knock quit (Max SendQ exceeded) |
| 18:18:27 | * | Joe_knock joined #nimrod |
| 18:19:10 | * | Joe_knock quit (Max SendQ exceeded) |
| 18:19:35 | * | Joe_knock joined #nimrod |
| 18:20:19 | * | Joe_knock quit (Max SendQ exceeded) |
| 18:20:45 | * | Joe_knock joined #nimrod |
| 18:21:38 | * | Joe_knock quit (Max SendQ exceeded) |
| 18:22:04 | * | Joe_knock joined #nimrod |
| 18:22:56 | * | Joe_knock quit (Max SendQ exceeded) |
| 18:23:23 | * | Joe_knock joined #nimrod |
| 18:24:17 | * | Joe_knock quit (Max SendQ exceeded) |
| 18:25:34 | * | client_ joined #nimrod |
| 18:25:58 | * | client_ quit (Read error: Connection reset by peer) |
| 18:26:29 | * | lint_obscura joined #nimrod |
| 18:26:53 | * | lint_obscura quit (Max SendQ exceeded) |
| 18:27:18 | * | lint_obscura joined #nimrod |
| 18:27:44 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 18:28:15 | * | lint_obscura quit (Max SendQ exceeded) |
| 18:55:35 | * | lint_obscura joined #nimrod |
| 18:56:00 | * | lint_obscura quit (Max SendQ exceeded) |
| 18:56:26 | * | lint_obscura joined #nimrod |
| 18:57:18 | * | lint_obscura quit (Max SendQ exceeded) |
| 19:00:51 | * | lint_obscura joined #nimrod |
| 19:01:15 | * | lint_obscura quit (Max SendQ exceeded) |
| 19:01:42 | * | lint_obscura joined #nimrod |
| 19:02:26 | * | lint_obscura quit (Max SendQ exceeded) |
| 19:03:28 | * | silven joined #nimrod |
| 19:14:48 | * | Fr4n quit (Ping timeout: 272 seconds) |
| 19:15:54 | Araq | def-: yes. |
| 19:16:58 | def- | Araq: amazing |
| 19:26:30 | * | Fr4n joined #nimrod |
| 19:52:22 | * | Fr4n quit (Ping timeout: 250 seconds) |
| 19:56:08 | * | julienaubert quit (Remote host closed the connection) |
| 20:03:04 | * | flaviu joined #nimrod |
| 20:05:06 | * | Matthias247 joined #nimrod |
| 20:12:35 | Matthias247 | hmm, after reviewing some supplier code today I was reminded why Garbage Collectors might be a good idea: return *(new std::vector< uint8_t >); |
| 20:15:25 | * | Jehan_ joined #nimrod |
| 20:17:07 | Araq | Matthias247: lol, that is so unusual it takes a while to understand |
| 20:17:57 | Matthias247 | he used that pattern for every non-primitive return value of the interface that he should implement |
| 20:19:38 | * | Joe_knock joined #nimrod |
| 20:20:03 | * | Joe_knock quit (Max SendQ exceeded) |
| 20:20:29 | * | Joe_knock joined #nimrod |
| 20:21:22 | * | Joe_knock quit (Max SendQ exceeded) |
| 20:21:25 | Matthias247 | and the return type was of course defined as by-value and not by-ref |
| 20:21:50 | * | Joe_knock joined #nimrod |
| 20:22:01 | Araq | how can you free a new'ed pointer that you deref? |
| 20:22:25 | Matthias247 | you can't |
| 20:22:34 | Matthias247 | memleaks all over the place |
| 20:22:43 | * | Joe_knock quit (Max SendQ exceeded) |
| 20:23:14 | Matthias247 | the objects are created on the heap, copied for the return value, and the thing on the heap will stay there forever :'( |
| 20:23:54 | Araq | yeah |
| 20:24:57 | Matthias247 | but maybe it doesn't matter. As there were absolutely no synchronization primitives in a heavily multithreaded environment it might crash because of that before it gets out of memory |
| 20:25:39 | Jehan_ | Ouch. |
| 20:26:00 | * | Joe_knock joined #nimrod |
| 20:26:12 | Jehan_ | Yeah, my opinion is that automatic memory management should be the default and that not using it needs to be rare and justified. |
| 20:26:24 | * | Joe_knock quit (Max SendQ exceeded) |
| 20:26:54 | * | Joe_knock joined #nimrod |
| 20:27:02 | Jehan_ | I'm not particularly picky about the form of automatic memory management, though. |
| 20:27:45 | * | Joe_knock quit (Max SendQ exceeded) |
| 20:28:10 | * | Joe_knock joined #nimrod |
| 20:28:21 | Araq | dunno, I think GC is also a big "bad code" enabler |
| 20:29:02 | * | Joe_knock quit (Max SendQ exceeded) |
| 20:29:08 | Matthias247 | the funny thing is that for this task it wouldn't even have been required. |
| 20:29:16 | Matthias247 | smply returning an object by-value |
| 20:29:31 | * | Joe_knock joined #nimrod |
| 20:29:52 | Matthias247 | guess the problem was next to zero understanding of C++ |
| 20:30:47 | Jehan_ | Araq: At this point, it's about code not crashing. |
| 20:32:39 | Matthias247 | the scary thing is that I'm running at such things and that level of experience all over the place. And that's from companies that claim to be embedded experts with world class reputation |
| 20:34:57 | Joe_knock | Hello folks. Is there a decent GUI application I can use to try to build a couple of demos? |
| 20:35:36 | Joe_knock | Linux of course ;-) |
| 20:35:38 | Araq | hi Joe_knock we have gtk examples somewhere and aporia |
| 20:36:07 | Demos | Joe_knock, there are no GUI "wizards" for nimrod if that is what you are asking. |
| 20:37:24 | Joe_knock | Demos: Don't worry, I'll try writing code for most of the stuff. I just want like a yardstick I can aim for. Would be cool if we had a NimQT library. QT works on all desktops (I think) |
| 20:38:16 | Demos | GTK should work everywhere, but yeah a QT wrapper would be great. QT is much harder to wrap than GTK though because of moc and the fact that it is c++ |
| 20:38:41 | Araq | Demos: btw there is a forum post for ya |
| 20:39:29 | Joe_knock | I don't mind GTK personally, but I've read up on the issues its been having recently. |
| 20:39:32 | * | ics quit (Ping timeout: 240 seconds) |
| 20:39:56 | Joe_knock | I did actually manage to write a simple application so far. An "average" calculator. |
| 20:41:34 | * | ics joined #nimrod |
| 20:44:55 | bogen1 | QT is harder to wrap I agree. I've used http://www.fox-toolkit.org/ (c++) and fltk (c) but since nimrod already has gtk and iup, I personally don't see need (for myself at least) to wrap another one. |
| 20:45:50 | Demos | fltk is c++ |
| 20:46:02 | Joe_knock | bogen1: Which 1 would you say is the "leader" of the pack? I'd like to build demo apps so that they can be displayed for others to see nimrod in action. |
| 20:46:19 | bogen1 | ok on fltk, it has been a while since I used it |
| 20:46:22 | Demos | GTK is the biggest GUI library we have |
| 20:46:34 | Matthias247 | It might be possible to wrap only QTs QML part in the same way that the Go wrapper has done it |
| 20:46:59 | Demos | Matthias247, but most of us would want to write all the code in nimrod I think |
| 20:47:14 | Joe_knock | I can write up a decent tutorial or 2, but first I need to understand what is happening myself :P |
| 20:47:32 | Demos | Joe_knock, , there is a GTK 3 wrapper on the forums someplace as well, someone should prod the author to release it on github |
| 20:47:41 | Joe_knock | How big do these GUI wrappers get? Are we talking thousands of lines? |
| 20:47:48 | bogen1 | Joe_knock: GTK has a lot of momentum. Alot of non nimrod GTK examples would be usable without much effort as well. |
| 20:48:05 | Joe_knock | GTK 3 :O Don't use such foul language :P |
| 20:48:17 | Matthias247 | Demos: I agree. While I think declarative UI (like XAML or MXML) is really useful I absolute dislike the need for another language (JS in QMLs case) |
| 20:48:32 | Demos | XAML is a total clusterfuck |
| 20:48:32 | bogen1 | With GTK you get glib which has a lot things that can be useful |
| 20:48:59 | Demos | bogen, and a lot of stupid |
| 20:49:03 | Joe_knock | Can you guys give examples of what you've built so far in Nimrod? It kind of helps to see what people are using the language for. |
| 20:49:10 | Demos | yes! |
| 20:49:11 | Matthias247 | translating c++ objects manually to Javascript and back is even more clusterfuck ;) |
| 20:49:22 | bogen1 | agreed. I like FOX, but the apps I write are not typical GUI apps. |
| 20:49:46 | Demos | Matthias247, XAML dependency properties are injected via runtime IL modification and are inherated by composition (which is very VERY strange) |
| 20:50:29 | Varriount | Araq: Generics seem to allow openarray types to bypass whatever check is done for variables and return types, which leads to cgen errors. |
| 20:50:36 | Varriount | Any idea how I would go about fixing that? |
| 20:50:38 | Demos | Joe_knock, right now I am working on a visual studio plugin for nimrod (written in c#) and an Easy to use graphics library called Phosphor |
| 20:50:53 | Matthias247 | Demos: ok, that sounds really strange. But I didn't use it that deeply |
| 20:51:03 | bogen1 | Demos: (Agreed on the alot of stupid that glib brings along, especially since most is not needed with nimrod). For C app the extra stuff "can" in some circumstances be useful... |
| 20:51:38 | Demos | Matthias247, yeah. XAML looks really good at first, really easy to get rolling. But things interact in totally non-obvious ways and you end up having to debug the implied behaviors of your XML |
| 20:52:01 | Demos | bogen, well if I am in C I like to keep in lean, that is kinda the point. But yeah |
| 20:52:04 | Joe_knock | Demos: Based on the Windows thing ... I've been wondering why you guys are leaning more towards Windows than Linux ( I stand to be corrected on this). |
| 20:52:19 | Demos | also I think vala is a really funny idea |
| 20:52:24 | Demos | Joe_knock, what windows thing> |
| 20:52:51 | Matthias247 | Hmm. Pretty strange that after so many years there are still only few GUI libraries and even fewer good ones |
| 20:52:56 | Joe_knock | Demos: The strong(er) support that Windows seems to have. Again, I stand to be corrected. |
| 20:53:54 | Demos | Joe_knock, we support both equally, which is really nice |
| 20:54:15 | Demos | things tend to be a tad eaiser on unix, but the whole ecosystem can be compiled/bootstraped with MSVC |
| 20:54:23 | Joe_knock | Demos: That's great news! |
| 20:54:46 | Demos | a lot of projects just assume unix and then only support windows using stuff like cygwin and mingw, whcih I find annoying |
| 20:55:04 | Demos | I think Araq does a lot of development on a windows box as well |
| 20:58:17 | Demos | I am pretty sure nimrod also works just fine on Haiku and BSD |
| 20:58:19 | Joe_knock | I need to now see if I have GTK installed. My lightweight-version of Ubuntu was meant to avoid the heavy-duty KDE and GTK. |
| 20:58:25 | Demos | although not plan 9 :( |
| 20:59:00 | * | adoniscik quit (Remote host closed the connection) |
| 20:59:13 | * | io2 joined #nimrod |
| 20:59:46 | Demos | Joe_knock, if you are uninterested in xplatform GUIs it may not be too hard to wrap Elementary and friends |
| 21:00:44 | Joe_knock | Demos: I'm going to check which GUI toolkit comes standard with this OS and try to see if I can wrap nimrod for it :P |
| 21:02:25 | * | Stefan__ joined #nimrod |
| 21:03:00 | Matthias247 | enlightenment should also be wrappable |
| 21:03:21 | Demos | yeah, C GUI libs tend to be a little messy though |
| 21:03:48 | Demos | Java style OOP seems to be pretty decent for GUIs, and not having inbuilt support seems to cause some problems |
| 21:04:37 | Matthias247 | as it is also programmable in Javascript it might map in a proper way to objects |
| 21:05:05 | Varriount | But at the same time, OOP tends to not be the most portable of paradigms/ |
| 21:05:21 | Demos | yeah, I guess |
| 21:05:35 | Demos | although you can define an ABI |
| 21:05:38 | Matthias247 | portable between programming languages? |
| 21:05:40 | Jehan_ | Varriount: I don't understand what you mean by that? Can you explain? |
| 21:05:47 | Araq | Joe_knock: I think linux is still better supported than windows. the missing OpenSSL or SDL.dlls come to mind |
| 21:06:05 | Stefan__ | Would be fine when someone could test the GTK3 wrapper, and maybe tell me how to improve it. |
| 21:06:10 | Demos | Araq, well neither of those DLLs are required to run linux |
| 21:07:05 | Demos | Really the lack of package management is the issue there |
| 21:07:27 | Varriount | Jehan_: Look at C++ and the different compiler layouts of classes and objects. It makes it difficult to interface with objects. |
| 21:07:54 | Joe_knock | Perhaps we're thinking too deeply on the GUI issue. Maybe just using something a little less complicated and cross-platform, like a hybrid HTML desktop application, might be an option to consider? |
| 21:08:12 | Matthias247 | Varriount: that's solved by both Java and C# |
| 21:08:27 | Jehan_ | Varriount: That seems to be a very C++-specific issue? |
| 21:08:27 | Stefan__ | Interest seems to be not great for GTK3 -- I myself consider porting my schematic tool from Ruby-Gtk3 to Nimrod-Gtk3 -- maybe next year. First I have to finish the Ruby version. |
| 21:08:45 | Demos | Joe_knock, HTML is not less complex than a GUI library though |
| 21:09:02 | Matthias247 | but yes, the package management problem is everywhere |
| 21:09:20 | Joe_knock | Demos: Really? A tool like -webkit seems to have simplified it somewhat. |
| 21:09:34 | Demos | there is a version of OpenSSL in chocolatey, although it is not that new (heartbleed is fixed in it though) |
| 21:09:53 | Demos | Joe_knock, yeah, HTML renderers are hugely complex |
| 21:10:21 | Stefan__ | I am willing to work on GTK3 again, and maybe do that Git port, but only when there is real interest, or when I need it myself. But for me it would be OK when someone wraps Qt... |
| 21:10:25 | Stefan__ | quit |
| 21:10:52 | * | Stefan__ quit (Quit: Page closed) |
| 21:10:54 | Araq | hi Stefan__ |
| 21:11:00 | Demos | too late |
| 21:11:27 | Jehan_ | Joe_knock: You mean something like node-webkit? |
| 21:11:29 | Joe_knock | Demos: Interesting. I'm still waiting to read from you guys what you are actually using nimrod for :P |
| 21:11:46 | Demos | hey I said already! |
| 21:11:49 | Jehan_ | Joe_knock: Tools for my research, primarily. |
| 21:11:59 | Joe_knock | Jehan_: I was going to initially suggest that. But I see that node-webkit is the node.js version of webkit. |
| 21:12:19 | Matthias247 | you can of course use some HTML renderer like webkit for GUIs. But those things are resource-eating monsters |
| 21:12:21 | Jehan_ | Joe_knock: Yeah, that's why I said "something like". |
| 21:13:06 | Jehan_ | Well, Tk is still an option if you want something that's quick and easy. |
| 21:13:15 | Matthias247 | I think there was already an untested wrapper for chromium embedding framework around here |
| 21:14:45 | Demos | it would be interesting to see a document centered GUI framework for the desktop |
| 21:15:32 | Joe_knock | My goal was to attempt to use some type of light-weight GUI to flesh out these really trivial applications so that when someone tries it out, they're like "wow, that wasn't too difficult" and then I show them a C++/Java version. |
| 21:15:50 | Varriount | Matthias247: Yes. I did the libCef wrapper, but no-one has been able to succesfully compile libCef |
| 21:16:41 | Matthias247 | Varriount: i can imagine that. The codebases of those HTML engines are horrible monsters :-) |
| 21:17:37 | Joe_knock | Some interesting stuff here: http://trac.webkit.org/wiki/Applications%20using%20WebKit |
| 21:18:09 | Araq | Varriount: what's the problem with compiling libCef? |
| 21:18:22 | Varriount | Araq: Ask dom96 |
| 21:23:13 | Varriount | Araq: Pushed an update to that cast[openarray[int]] fix |
| 21:25:30 | Varriount | Araq: Are generics semantically checked again after they're 'filled in' with concrete types? |
| 21:28:27 | Araq | yes |
| 21:29:10 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 21:33:43 | * | shodan45 quit (Quit: Konversation terminated!) |
| 21:38:10 | * | q66_ joined #nimrod |
| 21:40:38 | * | q66 quit (Ping timeout: 260 seconds) |
| 21:44:45 | * | saml quit (Quit: Leaving) |
| 21:48:04 | * | bogen1 left #nimrod (#nimrod) |
| 21:51:08 | * | untitaker quit (Ping timeout: 240 seconds) |
| 22:05:41 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 22:22:36 | * | q66_ is now known as q66 |
| 22:27:06 | * | nande joined #nimrod |
| 22:32:19 | dom96 | hi |
| 22:42:12 | * | Trustable quit (Quit: Leaving) |
| 22:43:58 | Joe_knock | Hi there dom96 |
| 22:44:08 | dom96 | hi Joe_knock |
| 22:45:36 | * | Jesin quit (Quit: Leaving) |
| 22:45:40 | Joe_knock | dom96: Did you build Aporia using the gtk2 gui? |
| 22:45:52 | Joe_knock | okay it says its using it. |
| 22:45:54 | dom96 | I did indeed. |
| 22:47:38 | Joe_knock | dom96: What was the complexity like building out a GUI app? |
| 22:47:52 | * | Jesin joined #nimrod |
| 22:48:20 | dom96 | Joe_knock: I wouldn't call it complex, I would call it annoying though. |
| 22:48:31 | dom96 | GTK is simply not flexible enough. |
| 22:49:04 | Joe_knock | dom96: aah I see. I'm attempting to look over your code to understand what you did to build it. |
| 22:49:05 | dom96 | Although GtkSourceView is to blame also. |
| 22:49:22 | dom96 | I must admit: the code is a bit messy. |
| 22:50:23 | Joe_knock | and huge too. touching on 16MBs |
| 22:51:45 | dom96 | Are you measuring the whole git repo? |
| 22:51:55 | dom96 | Most of that is likely binaries in the history. |
| 22:52:56 | Joe_knock | dom96: The code is a bit confusing, as I see that you've built it for both windows/nix. |
| 22:53:45 | dom96 | I can certainly help you understand. Go ahead and ask questions if you wish. |
| 22:56:36 | Joe_knock | dom96: Firstly, did you code everything by hand/memory, or is there some type of reference you used? |
| 22:57:12 | dom96 | The GTK docs of course: https://developer.gnome.org/gtk2/stable/ |
| 22:57:32 | dom96 | Perhaps I am misunderstanding your question |
| 22:59:42 | Joe_knock | dom96: After seeing that document, I think I understand where the code is coming from. aporia.nim is the main document, correct? |
| 23:00:04 | Joe_knock | **After seeing that web page... |
| 23:00:37 | dom96 | yes |
| 23:01:02 | dom96 | There is no reference for how Aporia is implemented. |
| 23:01:56 | Joe_knock | Perhaps I need to find a decent starting point. Maybe I'll look into the "buttons" and "dropdowns" first. |
| 23:02:55 | dom96 | Joe_knock: What kind of application are you thinking of writing that requires GUIs? |
| 23:03:55 | Joe_knock | dom96: Anything really. I want to contribute to nimrod by building out these really basic GUI apps. |
| 23:04:30 | Joe_knock | I was thinking of starting simple: Text editor (like LeafPad) |
| 23:04:34 | dom96 | THe current GTK2 wrapper is very low-level, so you can essentially look at C GTK2 examples and translate them to Nimrod. |
| 23:05:08 | dom96 | What would be cool is if you could write a high-level module on top of that. |
| 23:05:37 | Joe_knock | You mean: Remove some of the boilerplate from the current wrapper? |
| 23:05:50 | dom96 | yes |
| 23:05:58 | dom96 | but keep the wrapper as-is |
| 23:10:14 | Joe_knock | dom96: Do you have suggestions for any other type of application that might be suitable for building with Nimrod? |
| 23:11:29 | dom96 | web apps |
| 23:11:38 | dom96 | games |
| 23:12:39 | EXetoC | most things imo |
| 23:12:46 | Joe_knock | games require a deep and long commitment. I was trying to find a use-case to highlight nimrods performance. |
| 23:13:07 | Joe_knock | perhaps a "break my web app" type of app might work. |
| 23:13:12 | dom96 | a quick 3D openGL demo? |
| 23:13:46 | dom96 | Nimrod's real-time GC should keep the FPS nice and steady |
| 23:14:06 | Joe_knock | that's not a bad idea. |
| 23:14:36 | dom96 | Current problem with anything related to networking is that I am still working on the new async stuff. |
| 23:14:51 | dom96 | and if you want an awesome webapp you will likely wanna use it |
| 23:16:50 | Joe_knock | dom96: I see that most of the big projects are being managed by a core group of devs, if not just 1 dev alone. Is that a cause for concern? |
| 23:17:21 | dom96 | That we will disappear? |
| 23:18:02 | Joe_knock | haha. That could happen, but more so about longevity. |
| 23:18:34 | * | nande quit (Ping timeout: 240 seconds) |
| 23:18:48 | dom96 | Perhaps. But we've been alive, well, and working on this stuff for the past 6 or so years. We ain't going nowhere. |
| 23:18:52 | EXetoC | progress is slow but steady I guess |
| 23:19:37 | Demos | it is pretty typical for a programming language to go for years and years without anyone careing unless a big company is backing it |
| 23:22:20 | * | nande joined #nimrod |
| 23:32:23 | dom96 | good night |
| 23:32:41 | bogen | 'night |
| 23:34:34 | * | Jehan_ quit (Quit: Leaving) |
| 23:34:59 | * | darkf joined #nimrod |
| 23:35:04 | * | darkf quit (Changing host) |
| 23:35:04 | * | darkf joined #nimrod |
| 23:48:02 | Varriount | Joe_knock: If it's of any worth, I plan to stay around as long as possible. There might be times where I'm too busy to talk or develop, but Nimrod will always be something to me. |
| 23:48:13 | Varriount | (Not that I develop much) |
| 23:54:06 | Joe_knock | Varriount: If I recall, you use nimrod for scripting? |
| 23:54:20 | * | ARCADIVS joined #nimrod |
| 23:54:23 | Varriount | Joe_knock: When I can. |
| 23:55:08 | Joe_knock | It'd be interesting to see nimrod performance next to something like numpy. |