| 00:07:58 | gradha | argh, can't find where include is done |
| 00:08:00 | gradha | good night |
| 00:08:05 | EXetoC | I'm making progress here. Soon it won't matter if Araq gets hit by a bus ;) |
| 00:08:11 | * | gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=fS9CcTpA9i0 again) |
| 00:15:06 | EXetoC | Araq: but this affects literals as well, and that's not good |
| 00:33:53 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 01:05:50 | * | DAddYE quit (Remote host closed the connection) |
| 01:06:43 | * | DAddYE joined #nimrod |
| 01:11:42 | * | DAddYE quit (Ping timeout: 256 seconds) |
| 01:16:46 | * | q66 quit (Quit: Leaving) |
| 01:16:48 | * | DAddYE joined #nimrod |
| 01:19:47 | * | ltbarcly joined #nimrod |
| 01:20:58 | * | DAddYE quit (Ping timeout: 246 seconds) |
| 01:44:14 | * | the_hoser left #nimrod ("Leaving") |
| 02:04:21 | * | ltbarcly quit (Quit: Computer has gone to sleep.) |
| 02:11:18 | * | ehaliewicz left #nimrod ("ERC Version 5.3 (IRC client for Emacs)") |
| 02:17:14 | * | DAddYE joined #nimrod |
| 02:24:15 | * | DAddYE quit (Ping timeout: 276 seconds) |
| 02:56:53 | sinistersnare | why did you guys decide to fully write the compiler in nimrod instead of bootstrapping with a small amount of C so you dont have to depend on a past release? |
| 03:04:15 | * | sinistersnare quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 03:20:28 | * | DAddYE joined #nimrod |
| 03:27:02 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 03:34:24 | * | OrionPK quit (Read error: Connection reset by peer) |
| 04:10:23 | * | JStoker quit (Quit: JStoker is gone :() |
| 04:23:39 | * | DAddYE joined #nimrod |
| 04:25:43 | * | JStoker joined #nimrod |
| 04:29:50 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 04:59:38 | * | _Bravado_ joined #nimrod |
| 05:13:06 | * | zahary quit (Read error: Connection reset by peer) |
| 05:13:18 | * | zahary joined #nimrod |
| 05:13:21 | * | Associ8or joined #nimrod |
| 05:13:21 | * | Associ8or quit (Changing host) |
| 05:13:21 | * | Associ8or joined #nimrod |
| 05:13:43 | * | ltbarcly_ joined #nimrod |
| 05:15:02 | * | Associat0r quit (Ping timeout: 240 seconds) |
| 05:26:43 | * | DAddYE joined #nimrod |
| 05:27:36 | * | Associ8or quit (Quit: Associ8or) |
| 05:31:02 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 06:21:04 | * | DAddYE joined #nimrod |
| 06:54:25 | * | brson quit (Quit: leaving) |
| 07:36:17 | * | Araq_ joined #nimrod |
| 07:50:37 | * | DAddYE quit (Remote host closed the connection) |
| 07:51:06 | * | DAddYE joined #nimrod |
| 07:55:27 | * | DAddYE quit (Ping timeout: 260 seconds) |
| 08:23:28 | * | EXetoC joined #nimrod |
| 08:30:56 | * | _Bravado_ quit (Quit: _Bravado_) |
| 08:51:34 | * | DAddYE joined #nimrod |
| 08:57:55 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 09:10:31 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]) |
| 09:32:42 | * | screen-dsuch joined #nimrod |
| 09:33:22 | * | rndbit quit (Read error: Operation timed out) |
| 09:37:54 | * | ltbarcly joined #nimrod |
| 09:41:56 | * | rndbit joined #nimrod |
| 09:42:05 | * | ltbarcly quit (Ping timeout: 245 seconds) |
| 09:54:44 | * | DAddYE joined #nimrod |
| 10:00:55 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 10:01:40 | * | q66 joined #nimrod |
| 10:50:13 | * | Araq_ joined #nimrod |
| 10:58:06 | * | DAddYE joined #nimrod |
| 11:04:43 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 11:41:31 | * | ltbarcly__ joined #nimrod |
| 11:42:31 | * | ltbarcly_ quit (Ping timeout: 245 seconds) |
| 11:48:37 | * | ltbarcly joined #nimrod |
| 11:53:02 | * | ltbarcly quit (Ping timeout: 264 seconds) |
| 12:01:01 | * | DAddYE joined #nimrod |
| 12:07:26 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 12:49:27 | screen-dsuch | hey friends, I'm looking into learning a new language with a python-like syntax (python is what I mostly use) and I'm wondering if nimrod could be a good choice if I were also interested in creating python extensions? |
| 12:49:45 | profmakx | why should it not be? |
| 12:49:48 | screen-dsuch | I can see it has its own VM so I'm not sure if that would plau nicely with python's own? |
| 12:49:48 | profmakx | how could we tell? |
| 12:50:14 | screen-dsuch | well profmakx because you are members of this channel, possibly long-time users of nimrod |
| 12:50:34 | profmakx | hah. |
| 12:50:38 | screen-dsuch | don't really feel compelled to reply, there's nothing wrong with not saying anything |
| 12:50:41 | profmakx | i have just been told about nimrod 2 weeks ago :P |
| 12:50:49 | profmakx | i like it so far |
| 12:52:42 | Trixar_za | Er, nimrod compiles to binaries, it's not interpertive like python |
| 12:52:58 | Trixar_za | It can be, but generally it's discouraged |
| 12:53:02 | screen-dsuch | yes, I know Trixar_za, all good on tha front :) |
| 12:53:18 | screen-dsuch | I was thinking of python extensions, which are like shared libraries |
| 12:53:45 | screen-dsuch | but nimrod has its own VM, Python has its VM too - hence the question if python extensions can be easily written in nimrod |
| 12:54:02 | Araq_ | should be a piece of cake |
| 12:54:19 | screen-dsuch | ah, cool Araq_ |
| 12:54:34 | profmakx | did anyone make cross compilation for arm work already? |
| 12:54:49 | Trixar_za | Really? You can write Cython code in Nimrod? |
| 12:55:02 | Trixar_za | I know you can use python code within Nimrod, but this is new |
| 12:55:02 | Araq_ | it runs on the rasperry so yeah, profmakx |
| 12:55:15 | profmakx | Araq_ does it cross-compile though? |
| 12:55:26 | profmakx | btw, it was a breeze making nimrod work on dragonflybsd |
| 12:55:30 | profmakx | which I found awesome |
| 12:55:34 | Araq_ | dom96 bootstrapped on it |
| 12:55:48 | Araq_ | and yeah we have people here using cross-compilation |
| 12:56:27 | profmakx | cool |
| 12:59:04 | Trixar_za | I still think the kernel he wrote is the coolest thing he's done with nimrod |
| 13:00:45 | profmakx | the kernel on his git? |
| 13:04:27 | * | DAddYE joined #nimrod |
| 13:07:17 | Araq_ | screen-dsuch: easiest start might be --os:standalone and to not use any GC'ed memory as you need to use python's memory management anyway |
| 13:07:24 | Trixar_za | http://forum.nimrod-code.org/t/172 |
| 13:07:29 | Araq_ | for a python extension module |
| 13:09:40 | screen-dsuch | thanks Araq_ I'm going through the tutorial now, everything will be clearer with time I guess, wanted only to quickly check if there were possibly any fundamental differences an no-nos |
| 13:10:07 | zahary_ | why the os:standalone part? I've considered similar usage scenarios before and my conclusion was that even the GC will be usable with the guideline that the user should call setStackBottom in the entry symbols of the library |
| 13:11:39 | * | DAddYE quit (Ping timeout: 276 seconds) |
| 13:12:53 | EXetoC | Araq_: "got (int literal(1), float) but expected one of: f(a: float32, b: float32)". will this be hard to deal with? |
| 13:13:26 | EXetoC | actually, the float is also a literal.. |
| 13:13:33 | zahary_ | nimrod doesn't have implicit int to float conversion |
| 13:13:34 | EXetoC | f(1, 0.3) |
| 13:13:40 | zahary_ | you shoul do f(1.0, 0.3) |
| 13:13:52 | profmakx | a correct design decision. |
| 13:14:14 | EXetoC | but these are literals. the rules shouldn't be as strict in that case IMO, and it has worked for me |
| 13:14:39 | EXetoC | before I started messing with this float32 stuff in the compiler, which is what I'm testing with now |
| 13:16:58 | EXetoC | many people are forced to use either f32 or f64 literals in OpenGL applications for example, so having to include the suffix all over the place is pretty annoying |
| 13:17:37 | profmakx | and correct. |
| 13:19:43 | EXetoC | it's possible to deal with that though; I just need to make the parameters generic |
| 13:23:48 | EXetoC | zahary_: so float literal to some other float type should be allowed? I'm fine with that then, but the rules are very relaxed atm |
| 13:24:19 | Araq_ | EXetoC: indeed integer literals are special cased and can be converted to float iirc |
| 13:24:59 | zahary_ | I don't remember if there was a special rule for literal values. there was something about int literals being compatible with all int types as long as the value fits |
| 13:25:14 | zahary_ | ah, Araq beat me to it |
| 13:25:44 | Araq_ | zahary_ yeah you're right with stackbottom stuff of course but I think --os:standalone might be easier to start with |
| 13:26:06 | zahary_ | but that would cut off all of the OS APIs? not something I would like to have in my python module |
| 13:27:51 | Araq_ | OS APIs are fine, nimrod's stdlib is not |
| 13:28:18 | zahary_ | it doesn't affect when defined(posix): ... etc |
| 13:28:20 | zahary_ | ? |
| 13:28:35 | Araq_ | oh you're right it does |
| 13:28:56 | Araq_ | good point then |
| 13:29:55 | zahary_ | so just go for DLL builds builds and use malloc for any memory that will be given to python (that will also have a proper finalizer) |
| 13:30:17 | Araq_ | in fact, use py_malloc or whatever it's called |
| 13:30:38 | * | circ-user-c7L9O joined #nimrod |
| 13:33:11 | EXetoC | so the current rules should stay? ok, well I don't know how to treat literals in a special way |
| 13:34:47 | EXetoC | Also, I couldn't figure out how binArithTab should be modified, but that's a different issue surely |
| 13:34:52 | screen-dsuch | ok, see you! |
| 13:34:55 | * | screen-dsuch left #nimrod (#nimrod) |
| 13:35:36 | Araq_ | EXetoC: I'll help you tonight |
| 13:35:40 | zahary_ | EXetoC, one technique that helped me get started with the compiler is to pick short patches in the commit history and to study what they are chaning. I think there is such a patch for these universal int literal |
| 13:35:55 | zahary_ | * they are changing * |
| 13:44:35 | EXetoC | I've only done it via github, but I'll do that locally some time, because the diff view sucks |
| 13:55:44 | NimBot | nimrod-code/babel master eeea3fc Dominik Picheta [+1 ±0 -0]: Added .babel file. |
| 13:57:18 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]) |
| 14:07:17 | * | DAddYE joined #nimrod |
| 14:13:04 | * | Associat0r joined #nimrod |
| 14:13:04 | * | Associat0r quit (Changing host) |
| 14:13:04 | * | Associat0r joined #nimrod |
| 14:13:09 | * | faassen joined #nimrod |
| 14:13:50 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 14:19:05 | EXetoC | dom96: it technically requires babel as well :> |
| 15:10:27 | * | DAddYE joined #nimrod |
| 15:17:30 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 15:25:48 | dom96 | EXetoC: Yep, babel now requires babel :P |
| 15:46:21 | * | sinistersnare joined #nimrod |
| 15:57:19 | * | BitPuffin joined #nimrod |
| 16:01:44 | * | SliceMeNice_ joined #nimrod |
| 16:03:50 | * | SliceMeNice quit (Ping timeout: 264 seconds) |
| 16:03:54 | * | SliceMeNice_ is now known as SliceMeNice |
| 16:30:10 | * | sinistersnare quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 16:45:35 | * | DAddYE joined #nimrod |
| 17:09:30 | * | guaqua quit (Write error: Broken pipe) |
| 17:12:08 | * | Mat2 joined #nimrod |
| 17:12:13 | Mat2 | hello |
| 17:14:16 | dom96 | hi Mat2 |
| 17:18:59 | Mat2 | hi dom96 |
| 17:23:51 | Mat2 | are there any examples beside the one in the documentation about usage of procedural variables ? |
| 17:51:24 | * | brson joined #nimrod |
| 17:52:04 | dom96 | Mat2: procedural variables? |
| 17:54:27 | Mat2 | http://www.nimrod-code.org/manual.html#procedural-type |
| 17:55:20 | Mat2 | like: |
| 17:55:34 | Mat2 | type tProc = proc (x: int) |
| 17:55:49 | Mat2 | var vProc: tProc |
| 17:55:59 | dom96 | ahh, well what other examples would you like? |
| 17:58:03 | Mat2 | I can compile procedures with procedural parameters, but it seem imposible to pass type equivalent procedures to it |
| 17:58:15 | Mat2 | ^them |
| 17:58:42 | dom96 | can you show me what you are trying to do? |
| 17:58:52 | dom96 | (pastebin please) |
| 18:01:37 | Mat2 | one moment please |
| 18:06:23 | Mat2 | https://gist.github.com/anonymous/6369218 |
| 18:06:48 | * | faassen left #nimrod (#nimrod) |
| 18:07:12 | Mat2 | I have some backend procedures, like add (ob: tNavmBackend,fDisAsm: bool) |
| 18:07:32 | Mat2 | but I can't pass them to compCond in this example |
| 18:08:59 | dom96 | and how are you trying to pass them to compCond? |
| 18:09:11 | dom96 | why does your code use 'val' instead of 'var'? typo? |
| 18:09:54 | Mat2 | that's a typo |
| 18:11:19 | Mat2 | https://gist.github.com/anonymous/6369288 |
| 18:11:26 | Mat2 | (more correctly) |
| 18:11:56 | dom96 | hrm? all that changed is the indentation? |
| 18:13:19 | * | _Bravado_ joined #nimrod |
| 18:13:20 | Mat2 | I try to pass this way: compCode (ob,ob.sVmMem[ob.oVmMem],addImm,add,cfNavmImmInstLenADD,ob.fDisAsm) |
| 18:14:02 | dom96 | what's the error? |
| 18:14:08 | Mat2 | https://gist.github.com/anonymous/6369322 |
| 18:14:26 | Mat2 | add can not pass to a procvar |
| 18:16:42 | dom96 | oh, mark the 'add' proc with {.procvar.} |
| 18:17:07 | dom96 | hello _Bravado_ |
| 18:17:25 | Mat2 | dom96: thanks |
| 18:20:01 | dom96 | np |
| 18:25:37 | Mat2 | bbl |
| 18:25:40 | * | Mat2 quit (Quit: Verlassend) |
| 18:27:01 | zahary | gradha, ouroboros is an interesting library, but what kind of support do you want to add to the compiler? |
| 18:27:36 | zahary | staticRead and staticExec offer one way to embed arbitrary readable data in your executable |
| 18:28:41 | * | filwit joined #nimrod |
| 18:28:46 | * | Mat2 joined #nimrod |
| 18:28:49 | filwit | hey folks |
| 18:28:56 | Mat2 | hi filwit |
| 18:29:04 | dom96 | hi filwit! |
| 18:29:29 | filwit | i saw this on the D twitter feed, just wanted ot know if you guys had seen it since it's comparing language performance and includes Nimrod |
| 18:29:31 | filwit | http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/ |
| 18:29:50 | * | dom96 wrote the nimrod benchmark :P |
| 18:29:59 | filwit | ahh, cool |
| 18:30:35 | filwit | that's cool that Nimrod is so close to C's performance and memory usage :) |
| 18:31:06 | dom96 | It's actually way ahead of C lol. |
| 18:31:38 | dom96 | Disappointing that it lost to D though. |
| 18:31:39 | filwit | C++** |
| 18:31:53 | filwit | it only lost to D by a very small margin |
| 18:32:00 | filwit | and it won in terms of memory usage |
| 18:32:16 | filwit | again, only by a small margin though |
| 18:32:22 | filwit | would be interesting to see Rust up there |
| 18:32:25 | dom96 | Yeah, and i'm sure there are plenty of other optimisations I could have done. |
| 18:32:48 | dom96 | And the optimisations I did make are probably very CPU-specific. |
| 18:33:30 | EXetoC | again, it wasn't dmd :p |
| 18:33:31 | zahary | considering that the benchmark doesn't do any allocations, I'm actually surprised that we came 4% behind. that probably comes from the OpenMP runt-time |
| 18:33:37 | filwit | well either way i'm sure it' virtually impossible to make Nimrod run faster than it's C/C++ equivalent |
| 18:33:53 | dom96 | zahary: The clang version doesn't use OpenMP. |
| 18:34:08 | zahary | but it still has parallel for? |
| 18:34:11 | filwit | (btw, the C code was only slower because of some algorithm differences in the array or something) |
| 18:34:12 | Mat2 | dom96: Such tests depend more on factors as os workload and others if cpu performance not the limiting factor |
| 18:34:21 | dom96 | zahary: It uses Nimrod's native threads. |
| 18:35:02 | zahary | I see, and which one was tested? |
| 18:35:57 | dom96 | zahary: For clang it was the native threads version, for gcc it was the OpenMP version AFAIK |
| 18:37:14 | filwit | i was a bit supprised that the LLVM/Clang version of all the languages seem to out-perform their GCC versions |
| 18:37:26 | filwit | surprised* |
| 18:37:46 | dom96 | it was the other way around on my computer. |
| 18:37:58 | dom96 | Although I have a more recent version of GCC and Clang than the author |
| 18:38:22 | filwit | yeah, plus its probably very dependent on the CPU |
| 18:43:37 | filwit | oh wait, rust is there... |
| 18:43:40 | filwit | how did i miss that.. |
| 18:44:45 | * | ltbarcly joined #nimrod |
| 18:45:12 | BitPuffin | the benchmark does say something about how it would be kind of nice to also have an LLVM backend for the nimrod compiler |
| 18:45:58 | zahary | clang is effectively an LLVM back-end |
| 18:46:05 | BitPuffin | well yeah I know |
| 18:46:15 | BitPuffin | but I mean a direct layer to LLVM |
| 18:46:21 | Araq | zahary: the test is pretty much useless; I had a version that would sometimes run faster on my machine. But variance was too high to decide anything |
| 18:46:37 | BitPuffin | if you go from nimrod, to C, to LLVM, to machine code that's just one more layer where something could be lost |
| 18:47:06 | zahary | compiling to LLVM is overrated. the tools will take years to mature and you will always miss other opportunities like a tight integration with existing C/C++ code bases |
| 18:47:20 | zahary | * like having a tight * |
| 18:47:36 | Araq | it's also CPU dependent so it's just some game of luck what CPU the guy uses who posts the results |
| 18:48:12 | zahary | there are no such layers really. it's all writes to variables in the end |
| 18:49:58 | Mat2 | Araq: it may be a useless micro benchmark, but a spectacular one |
| 18:50:17 | BitPuffin | zahary: ldmd didn't take all that much time. Sure it takes a lot of time. But it might be worthwhile to have the option. I actually LOVE that nimrod can be compiled to other languages, I hope that is never ever ever ever ever removed |
| 18:50:57 | BitPuffin | zahary: it would also make compilation times faster |
| 18:52:29 | BitPuffin | The nimrod can only be as fast as the C compiler |
| 18:52:35 | BitPuffin | the nimrod compiler* |
| 18:52:56 | Araq | BitPuffin: actually it's not easy to make compilation times faster via LLVM without making the compiler multithreaded. We call the C compiler in parallel |
| 18:53:00 | zahary | the only point of supporting LLVM is to gain access to stuff that's not expressible in C. like the ability to ask "where did these ref stack varialbes end up?" so you can write a precise garbage collector for example |
| 18:53:54 | Mat2 | BitPuffin: An option for straight native-code compilation have the advantage of better control over cpu-specific details and limitations which resulted from language design (C) |
| 18:54:05 | BitPuffin | Araq: Hmm, well it doesn't have to be an LLVM backend. That was just an example, but doesn't LLVM give you some nice things for free? I am not very well informed when it comes to LLVM |
| 18:54:23 | Mat2 | I mean can avoid C specific limitations |
| 18:54:44 | BitPuffin | yeah for sure |
| 18:54:49 | BitPuffin | (Mat2) |
| 18:55:52 | BitPuffin | Also (this is kind of a ridiculous example), if C goes away (I know..) forever, and we are dependent on it, it is kind of like getting a rug pulled away below our feet or what ever you say |
| 18:57:26 | Araq | BitPuffin: well don't worry, we'll have an LLVM backend before that happens :P |
| 18:57:47 | BitPuffin | Araq: Kind of what I thought too haha :) |
| 18:59:14 | filwit | really the biggest point of an LLVM backend in Nimrod, IMO, would not be so much technical as it would be political |
| 18:59:33 | filwit | people like to hear LLVM cause it's the hot new things in compiler tech |
| 18:59:43 | filwit | so advertising it is a plus |
| 18:59:45 | Mat2 | Araq: LLVM itself is somewhat restricted in the same level as C because of its design |
| 19:00:25 | BitPuffin | filwit: well then I guess it isn't even political, then it's just business |
| 19:00:35 | filwit | yeah |
| 19:01:01 | BitPuffin | Mat2: Yeah, so maybe it would be better to just have a nice portable native backend. I mean that's the true "limitless" way to do it |
| 19:01:21 | filwit | actually, I should rephrase that.. the biggest business reason to support LLVM is because people are afraid of Compile-to-C |
| 19:01:28 | Mat2 | BitPuffin: I agree |
| 19:01:52 | zahary | that's precisely why being laud about LLVM. it's annoying how many people have this irrational argument against compiling to C/C++ |
| 19:02:15 | filwit | but I have to agree with Araq about LLVM here. Really, it's a lot of work for not much technical gain |
| 19:02:27 | filwit | (at least i think that's his position, correct me if i'm wrong) |
| 19:02:28 | zahary | I for one, found nimrod specifically looking for a language that a) has compile-time code execution, b) compiles to C++ |
| 19:02:30 | BitPuffin | zahary: Yeah well I guess the argument is really all against compiling to another system rather than the raw native stuffies |
| 19:02:39 | Mat2 | LLVM is supported from Apple and other, larger companies. It's also a requirement for OpenCL |
| 19:02:56 | Araq | actually what speaks for LLVM is its type system, I'm tired of C's never ending type system PITA (is (***fn) is the same as (*fn)? who knows ...) |
| 19:03:10 | filwit | zahary: sure you where looking for a compile-to-c, but most people look at that (i'm guessing) and think.. "kinda un-pro" |
| 19:03:21 | zahary | LLVM has many downsides. The binaries produced on Windows are not compatible with the Microsoft's development tools (debuggers, profilers, etc) don't work yet |
| 19:03:32 | zahary | LLVM is still lagging behind in code generation quolity |
| 19:03:34 | BitPuffin | zahary: let me also point out once again that I love that nimrod compiles to C, just in case you forgot :P |
| 19:03:45 | filwit | zahary: again, just my guess, but I be more people are put off by "compile-to-c" than are turned on by it |
| 19:03:51 | filwit | I bet** |
| 19:04:27 | Mat2 | the main downside of LLVM is that its IL representation is a modelled after a canonical RISC ISA and restricted to SSA representation |
| 19:05:35 | Mat2 | it's really not well suited for dynamic compilation techniques |
| 19:05:35 | BitPuffin | filwit: Sure it kind of makes you think about languages like coffeescript in a way. Not that nimrod is nearly on that level but it's easy to draw a parralell with languages that compiles to languages |
| 19:05:40 | zahary | compiling to "another system" actually has benefits. it will never be possible with native code generation to interface with C++ at the level "inherit this C++ class and implement this virtual function, instantiate this generic type, etc", which is possible in Nimrod in theory |
| 19:06:47 | BitPuffin | zahary: well that's why we shouldn't ditch the compile to blabla language. Just that it is nice to have the option to go native immediately |
| 19:07:01 | Mat2 | why ? C++ compiles to native-code so these features must have static behaviour |
| 19:07:15 | dom96 | Hasn't C++ started out this way? It compiled to C initially before getting a native backend. |
| 19:07:20 | dom96 | Of course that was before LLVM I guess. |
| 19:07:23 | EXetoC | ot's not like you lose a lot of control by compiling to C |
| 19:07:33 | BitPuffin | dom96: indeed |
| 19:07:35 | zahary | Mat2: they are not defined in the standard as ABI - all of these are implementation details for the C++ compilers |
| 19:07:37 | EXetoC | s/o/i |
| 19:08:00 | Mat2 | zahary: Then C++ sucks |
| 19:08:00 | dom96 | Compiling to C to me is cool, so I don't believe other people would look down on Nimrod because of it. |
| 19:08:15 | EXetoC | it would either way :p |
| 19:08:16 | BitPuffin | EXetoC: "it's nit like yoi lise a lit if cintril by cimpiling ti C"? |
| 19:08:25 | Mat2 | compile to Pascal instead |
| 19:08:27 | zahary | that's true and another story, but there is plenty of useful code that I would like to use :) |
| 19:08:30 | Mat2 | :-> |
| 19:08:50 | BitPuffin | dom96: To me it is positive to have the option because it enables nimrod to run on platforms that don't support nimrod without extra porting work |
| 19:09:25 | zahary | most people seem to be whining about the perceived longer compilations |
| 19:09:52 | EXetoC | BitPuffin: I never included the 'g' flag :> |
| 19:10:04 | zahary | they are missing an important point: nimrod doesn't really produce your grandpa's C (headers including other headers, ad infinum) |
| 19:10:25 | BitPuffin | EXetoC: Well does it only change the first instance if you don't pass g? I thought it was like the first line or something |
| 19:10:55 | BitPuffin | no it produces monkey space ship C |
| 19:10:58 | zahary | and long compilations should be attached in another way - the IDEs shoud perform background compilation while your are typing the code |
| 19:11:34 | zahary | that's what I aim for with the caas system |
| 19:11:48 | EXetoC | as if using headers would be feasible; especially since it's just a copy/paste system :> |
| 19:13:22 | EXetoC | BitPuffin: yeah, if the substitute command isn't preceded by a range |
| 19:13:37 | dom96 | zahary: That sounds very taxing. |
| 19:14:11 | zahary | for your battery? |
| 19:14:47 | dom96 | yes, for my CPU. |
| 19:15:25 | EXetoC | I still want it to be fast, because I often just want to change one little thing and then have it run as soon as possible |
| 19:17:54 | zahary | most projects I've worked on have a typical compilation time of 1 to 5 minutes if you touch some popular header. reducing such compilation times should be taken very seriously, but the problem here is isolation - if you touch just one function this should lead to the regeneration of just one C file and to a quick incremental link |
| 19:19:02 | zahary | the code generator should ensure that there are no gigantic C files, so this compilation steps always take a short amount of time |
| 19:20:19 | zahary | dom96, if you find yourself in some of the projects I'm describing here, you'll want to plug yourself in the wall and won't worry if your multi-core CPU is not completely idling |
| 19:20:51 | zahary | your time is more important than few watts of electric power |
| 19:21:18 | dom96 | I'm more worried about my CPU's life. Also fan noise. |
| 19:22:57 | EXetoC | they almost never die |
| 19:23:47 | EXetoC | I hate fan noise too, but there are ways to deal with that |
| 19:25:38 | BitPuffin | EXetoC: well then it would become what I wrote! |
| 19:28:07 | EXetoC | :%s/x/y would process every line, but it'd still only substitute the first occurrence on each line without the 'g' flag |
| 19:28:35 | EXetoC | in vim anyway with nocompatible set, if it even makes a difference |
| 19:30:24 | zahary | there is algo set gdefault, which actually reverses the meaning of the gflag |
| 19:30:35 | zahary | there is also ... |
| 19:31:46 | BitPuffin | EXetoC: Well I mean it would go the entire first line, not just the first occurence |
| 19:34:43 | filwit | yo dom, 43 ppl! |
| 19:35:14 | filwit | the record has already been broken |
| 19:35:43 | dom96 | The new record is 49 :P |
| 19:36:31 | filwit | oh damn |
| 19:36:38 | filwit | so we celebrate at 50 then? |
| 19:36:58 | filwit | half a hundred sounds nice :) |
| 19:36:59 | BitPuffin | yes |
| 19:37:03 | BitPuffin | we'll get free bitcoins |
| 19:37:07 | BitPuffin | from the NSA |
| 19:37:10 | filwit | lol |
| 19:37:13 | BitPuffin | they are currently mining to reward us |
| 19:41:45 | BitPuffin | HAHA WHAT |
| 19:41:49 | BitPuffin | Nintendo 2DS |
| 19:41:51 | BitPuffin | It's real |
| 19:42:37 | filwit | so basically the 3DS, only without the flip out screen? |
| 19:43:54 | filwit | the one thing i can't wait for is the Oculus Rift :) |
| 19:45:37 | BitPuffin | Yeah it's 3ds without the 3d |
| 19:45:38 | BitPuffin | ... |
| 19:45:54 | filwit | ohhh... that makes sense |
| 19:46:09 | dom96 | whaat, it doesn't fold? |
| 19:46:13 | BitPuffin | no it folds |
| 19:46:20 | BitPuffin | it just doesn't have the 3d effect |
| 19:46:29 | dom96 | doesn't look like it from the picture |
| 19:46:31 | filwit | and it's cheaper |
| 19:48:18 | EXetoC | BitPuffin: yeah with 'g' |
| 19:49:18 | BitPuffin | EXetoC: no g goes through the entire document |
| 19:49:31 | BitPuffin | dom96: maybe it doesn't I dunno, I just think it is hilarious |
| 19:49:35 | BitPuffin | filwit: sure, but wtf |
| 19:50:09 | EXetoC | no not for me |
| 19:50:53 | BitPuffin | EXetoC: what vim are you running lol, mine changes the whole document with g |
| 19:51:39 | EXetoC | ok |
| 19:51:47 | EXetoC | the latest one. I've used other versions in the past |
| 19:51:55 | EXetoC | "[g] Replace all occurrences in the line. Without this argument, replacement occurs only for the first occurrence in each line" |
| 19:53:02 | BitPuffin | wtf |
| 19:53:08 | BitPuffin | OOOOH |
| 19:53:10 | BitPuffin | Wait |
| 19:53:14 | BitPuffin | it's % that is the whole document |
| 19:53:16 | BitPuffin | %s |
| 19:53:23 | BitPuffin | right |
| 19:53:29 | BitPuffin | so just :s would be the line yes |
| 19:53:31 | BitPuffin | sawri |
| 19:53:33 | BitPuffin | NOW DIE!! |
| 19:53:35 | BitPuffin | lol |
| 20:04:08 | * | _Bravado_ quit (Quit: _Bravado_) |
| 20:06:33 | * | _Bravado_ joined #nimrod |
| 20:15:40 | * | BitPuffin quit (Quit: WeeChat 0.4.1) |
| 20:16:03 | * | BitPuffin joined #nimrod |
| 20:20:43 | * | filwit quit (Quit: Leaving) |
| 20:33:24 | * | gradha joined #nimrod |
| 20:34:49 | BitPuffin | too bad the compiler can't generate nimrod from C++ for interfacing intsead of only the other way around |
| 20:34:54 | BitPuffin | I understand why to |
| 20:34:59 | BitPuffin | cpp is a biatch |
| 20:35:03 | BitPuffin | though* |
| 20:37:10 | gradha | zahary: ouroboros is just a nicer interface for static reads, plus you can change stuff after the binary is made |
| 20:37:29 | gradha | one of the ideas I have is to "expand" the appended data on macosx when using niminst to create a bundle |
| 20:37:55 | gradha | since a bundle already provides the abstraction of "everything in an exe" niminst could unpack the appended data, and ouroboros could detect this and read the files from the bundle |
| 20:38:25 | gradha | other than that there's nothing special about ouroboros |
| 20:41:59 | gradha | now when I'm hacking the compiler when I mess up and nothing compiles I use the external tool to remove the appended data and the compiler works again |
| 20:42:34 | gradha | avoids a recompile, though you can get the same by saving a compiler somewhere and replacing it later |
| 20:46:04 | zahary | the interesting feature indeed seems to be that you can add stuff after the binary is made. |
| 20:46:05 | zahary | otherwise I see some shortcomings compared to staticRead, staticExec: |
| 20:46:05 | zahary | 1) it has a run-time component |
| 20:46:05 | zahary | 2) it can read just one "record". I can easily have in the code multiple constant populated by staticRead |
| 20:46:05 | zahary | 3) I wouldn't call anything "a nicer interface" than the simple const foo = staticRead"bar.txt"; const bar = staticExec("zip *.data") |
| 20:46:28 | * | darithorn joined #nimrod |
| 20:46:32 | zahary | I probably don't quite understand how you're using ouroboros to produce portable executables on the other hand |
| 20:47:12 | gradha | you are missing the part where you need to access those consts later |
| 20:47:30 | gradha | how many variables are you going to store for each of all the nim modules of the compiler? |
| 20:47:33 | zahary | you mean "extract them from the executable"? |
| 20:47:49 | gradha | more like the code you use to "use" them |
| 20:49:03 | gradha | unless your code is prepared in advance to know all the consts, you are going to write yourself a layer on top of it, maybe a table like access |
| 20:49:24 | zahary | the goal is to embed the nim modules (these are the library nim files?) in a virtual file system stored inside the executable? |
| 20:49:38 | Araq | yes. exactly |
| 20:49:40 | gradha | yes, that part is done |
| 20:49:48 | gradha | now I only need to read them back! |
| 20:49:54 | Araq | so system.nim and the config files can become part of the exe |
| 20:49:54 | zahary | well, I described how that works with staticExec |
| 20:49:57 | gradha | also, I want to embed babel modules |
| 20:50:10 | zahary | const fs = staticExec("zip *.nim") |
| 20:50:18 | zahary | then use zlib to access the data |
| 20:50:32 | gradha | sure, that's the part ouroboros takes care off |
| 20:51:53 | zahary | if I have a point here is that these problems are orthogonal |
| 20:52:09 | zahary | the first component is a virtual zip file-system library |
| 20:52:20 | zahary | this should work with zips in the regular file system too |
| 20:52:38 | zahary | you give it an input stream and then you get a file system |
| 20:53:04 | zahary | then if you want to embed zip files in your executable, you use staticRead or staticExec, depending on your build procedure |
| 20:53:34 | gradha | unfortunately the current zip library doesn't support reading zips from the end of binaries, I talked with the author about it, it's on their TODO though |
| 20:53:54 | gradha | you are left with zlib for single files |
| 20:53:56 | zahary | zlib support reading streams as zip archives |
| 20:54:30 | zahary | memory streams |
| 20:54:46 | gradha | yes, that's why I'll use it for that |
| 20:55:34 | Araq | hmm if zlib already supports all this why does libzip exist? and why did I use that instead? |
| 20:56:13 | gradha | AFAIK zlib supports stream reading, not filesystems, and libzip supports filesystems, but not stream reading |
| 21:03:16 | gradha | zahary: did check again and can't see a way of using zlib to access that "const fs", how do you do that? |
| 21:04:31 | gradha | meaning: how do you extract just the contents of file "/data/background.png" from fs |
| 21:14:03 | zahary | I'm no expert on zlib, but here is what google suggests: http://users.telenet.be/tfautre/softdev/zfs/ |
| 21:14:43 | gradha | nice way of dodging the question, there are plenty libraries doing virtual file systems |
| 21:15:43 | zahary | anyway, my point was something else - you should be creating a general purpose zip-as-filesystem library that is separate from ouroborous; then the actual embedding approach in ouroboros is interesting, but the more natural way to solve the problem in nimrod is to use a slurped constant |
| 21:16:33 | zahary | zfs is based on zlib, that's what I meant |
| 21:40:36 | * | _Bravado_ quit (Quit: _Bravado_) |
| 21:50:13 | Araq | ping EXetoC |
| 21:54:00 | EXetoC | Araq: hi |
| 21:54:54 | Araq | in handleFloatRange there is: |
| 21:54:56 | Araq | elif isIntLit(ab): result = isConvertible |
| 21:55:07 | Araq | so integer literals are convertible to any float type |
| 21:55:25 | Araq | what you need to do is: |
| 21:55:44 | Araq | elif k == tyFloat32: result = isNone |
| 21:55:50 | Araq | before the line: |
| 21:55:56 | Araq | elif k >= tyFloat and k <= tyFloat128: result = isConvertible |
| 21:59:27 | * | OrionPK joined #nimrod |
| 22:02:07 | Araq | also the format strings should be changed like this: |
| 22:02:09 | Araq | "($1 + $2)", # AddF64 |
| 22:02:11 | Araq | becomes |
| 22:02:28 | Araq | "(($4))$1) + ($4)($2))", # AddF64 |
| 22:02:48 | Araq | sorry I mean |
| 22:03:01 | Araq | "(($4)($1) + ($4)($2))", # AddF64 |
| 22:07:41 | gradha | good night |
| 22:07:47 | * | gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=fS9CcTpA9i0 again) |
| 22:07:53 | Mat2 | ciao |
| 22:08:14 | Araq | same here, good night |
| 22:08:28 | Mat2 | ciao |
| 22:10:56 | darithorn | How do I get the size of a sequence? I'm trying sizeof but it gives me the wrong size. |
| 22:11:36 | Araq | s.len * sizeof(a[0]) + 2*sizeof(pointer) perhaps |
| 22:11:59 | Araq | 2*sizeof(pointer) should be the header you can't access directly |
| 22:12:26 | Araq | er, sizeof(s[0]) of course |
| 22:13:32 | darithorn | Doing s.len * sizeof(s[0]) works |
| 22:15:35 | EXetoC | yeah, sizeof is a compile-time construct |
| 22:16:02 | darithorn | ah, makes sense |
| 22:16:28 | EXetoC | Araq: Don't I need another literal check? I'll try to find out |
| 22:18:44 | Araq | yeah I'm sleeping |
| 22:18:51 | EXetoC | I'm no good at keeping track of these short identifiers |
| 22:19:26 | Araq | f is the formal parameter, a the argument |
| 22:20:02 | Araq | it's asymmetric of course, a might be convertible to f but not the other way round |
| 22:20:19 | Araq | but I'm sleeping, good night |
| 22:26:14 | EXetoC | yeah but there's f, a, ab, and k :> |
| 22:30:00 | Mat2 | time for some sleep, ciao |
| 22:30:10 | * | Mat2 quit (Quit: Verlassend) |
| 22:31:33 | * | oal quit (Ping timeout: 246 seconds) |
| 22:31:56 | * | oal joined #nimrod |
| 22:57:35 | * | Associat0r quit (Quit: Associat0r) |
| 23:04:19 | * | darithorn quit (Quit: Leaving) |
| 23:42:32 | NimBot | nimrod-code/Aporia master e933663 Dominik Picheta [+0 ±4 -0]: Implemented 'wrapMode' setting. |
| 23:47:43 | BitPuffin | dom96: I read that as warpMode I was ike woa! |
| 23:47:51 | dom96 | haha |
| 23:49:35 | * | SliceMeNice quit (Ping timeout: 245 seconds) |
| 23:59:43 | EXetoC | 0.3 is not being recognized as a literal according to the error message |