00:02:36 | * | milosn joined #nimrod |
00:10:15 | * | Varriount quit (Read error: Connection reset by peer) |
00:17:58 | reactormonk | boydgreenfield, any use in actually passing the permissions to open itself? |
00:18:42 | boydgreenfield | Mm sorry – what do you mean? Yes it works fine if you pass to the varargs open call and I’ve patched it locally and in a fork on GH. |
00:23:39 | boydgreenfield | reactormonk: On a separate note: Any good examples of using pointers in Nimrod? Trying to figure out right syntax for actually accessing the darn mmap region I have now… (I was also a bit hung up on the whole ptr vs pointer disctinction, but think I’ve got that figured out) |
00:27:31 | EXetoC | either cast to a pointer to array, or use something like this https://github.com/fowlmouth/nimlibs/blob/master/fowltek/pointer_arithm.nim |
00:28:01 | boydgreenfield | EXetoC: Does casting do an implicit copy? |
00:29:16 | EXetoC | the cast itself just re-interprets the memory, and in this case your casting to a pointer |
00:29:27 | EXetoC | *you're |
00:29:55 | EXetoC | omit 'ptr' and it'll copy |
00:30:17 | * | Skrylar quit (Ping timeout: 264 seconds) |
00:32:25 | EXetoC | var p = cast[ptr array[n, T]](mm.mem) |
00:33:53 | EXetoC | and if it's a value type then you'd take the address with addr, but the argument to addr needs to be a var |
00:34:01 | * | BitPuffin joined #nimrod |
00:35:10 | * | DAddYE quit (Remote host closed the connection) |
00:36:07 | boydgreenfield | EXetoC: Got it. That’s very helpful. Thanks. |
00:38:57 | * | BitPuffin quit (Ping timeout: 252 seconds) |
00:40:39 | EXetoC | np have fun |
00:52:21 | njoejoe | question on using "for elem in somearray:": https://gist.github.com/11550953 why does it not work the same as "for x in 0..somearray.high" ? |
00:52:58 | Jehan_ | Because buck isn't an lvalue. |
00:54:51 | njoejoe | well buckity buck buck. it would be nice if it was :-) |
00:56:21 | boydgreenfield | ExetoC: One last question (and thanks again!). So I think I have the syntax for casting to an array down, including assignment. But what’s the best approach if the size of the mmap file is only known at runtime vs. compile time? It seems wasteful to cast to the array every time I want to update a portion of the file. Specifically, I’d like to just cast my pointer to the arary when I open the file, as opposed |
00:56:22 | boydgreenfield | to every time I do an insert or lookup. Gist here if it’s unclear what I’m asking: https://gist.github.com/boydgreenfield/9a46dbde20f28b5dbcfc |
00:57:02 | Jehan_ | njoejoe: Interestingly enough, there's an iterator in the hash tables implementation for it. |
00:57:16 | Jehan_ | Not sure why there isn't a corresponding iterator for arrays. |
00:58:47 | Jehan_ | iterator mitems[T](a: var openarray[T]): var T = |
00:58:47 | Jehan_ | for i in a.low..a.high: |
00:58:47 | Jehan_ | yield a[i] |
00:59:19 | Jehan_ | You can then do: for el in somearray.mitems: el = whatever |
00:59:39 | Jehan_ | Mind you, it may be in the standard lib and I just haven't been able to find it. :) |
01:04:28 | EXetoC | boydgreenfield: wasteful how? if you want to treat is as different types then you have to cast |
01:05:01 | EXetoC | you can of course write some convenience procs, in addition to just creating an aliases for that field access |
01:05:14 | boydgreenfield | EXetoC: Sorry – I guess basically my question is that since i don’t know the size of the mmap array at compile time, am I forced to do a cast for every bitwise access? |
01:05:35 | njoejoe | thanks Jehan_ works great! |
01:05:55 | boydgreenfield | E.g., does my `[]` proc need to do something like – var var p = cast[ptr array[1024, int8]](bitarray.bitarray_mmap.mem); return p[index] << offset |
01:06:28 | boydgreenfield | or is there an idiomatic way to put `p` somewhere at runtime |
01:06:36 | Jehan_ | boydgreenfield: I'm not sure I understand the problem? |
01:07:18 | EXetoC | there are simply no index operators for pointers in the official distribution |
01:07:28 | boydgreenfield | Ok – that was my question I guess. |
01:07:33 | Jehan_ | Is it that you have to recompute the length each time? |
01:07:37 | fowl | boydgreenfield, cast to cstring (char *) |
01:07:51 | boydgreenfield | No — length will be known at object creation time. |
01:08:00 | boydgreenfield | fowl: Ahh. |
01:08:07 | Jehan_ | You can use the unchecked pragma to simulate indexable pointers. |
01:08:20 | fowl | boydgreenfield, are you writing unserialize functions with mmap? |
01:08:34 | boydgreenfield | I guess it’s less of a question of how to make it work, and more of a question of how to do it in an idiomatic fashion. |
01:08:36 | Jehan_ | http://nimrod-lang.org/manual.html#unchecked-pragma |
01:08:55 | Jehan_ | If it's just a lot of boilerplate, you can hide it in an inline proc or a template. |
01:08:57 | * | Demos_ joined #nimrod |
01:09:20 | fowl | er |
01:09:30 | fowl | what are you doing O.o |
01:09:33 | boydgreenfield | fowl: Not really – I’m simply writing a bitarray data structure I’d like to have optionally backed with mmap (as opposed to a seq of data). Maybe just using char* is the best way to go. |
01:09:39 | fowl | <)< fishy |
01:10:17 | boydgreenfield | I’d like to just have a data structure for bit-level access across several GBs of memory – backed by mmap. And I want minimal overhead for those accesses, that’s all. |
01:11:03 | fowl | boydgreenfield, interesting |
01:11:29 | * | Demos quit (Ping timeout: 258 seconds) |
01:11:35 | Jehan_ | I'd try something like: type flexbytearray {.unchecked.} = array[0..0, int8] and cast the mmap result to a ptr flexbytearray, which you then store in a variable. |
01:11:44 | EXetoC | cast is a compile-time construct. it just adds some line noise in some cases |
01:12:30 | boydgreenfield | flexbytearray? |
01:12:42 | Jehan_ | boydgreenfield: That's just a typename that I made up. |
01:12:54 | boydgreenfield | Ah. |
01:12:55 | EXetoC | isn't that more for when you want the size to vary? |
01:12:55 | Jehan_ | You can call it whatever. |
01:13:02 | fowl | i suggested cstring because its easy to index |
01:13:08 | EXetoC | otherwise you can just choose a really large max index |
01:13:12 | Jehan_ | fowl: I thought that was the problem? |
01:13:14 | EXetoC | int.high or something like that |
01:13:22 | Jehan_ | Oops, meant for EXetoC. |
01:13:32 | Jehan_ | EXetoC: That's what {.unchecked.} is for now. |
01:13:42 | Jehan_ | So that you don't have to deal with real large values. |
01:14:34 | EXetoC | I don't know how it's different |
01:16:34 | Jehan_ | That you don't have to figure out a sane max value? |
01:17:26 | * | vendethiel quit (Quit: q+) |
01:19:12 | EXetoC | it seems pretty similar to just 0..int.max |
01:20:31 | fowl | Jehan_, boydgreenfield, i have written a pointer arithmetic that you can use, if you have enough hair on your head (the license isnt mentioned, but it excludes bald people) https://github.com/fowlmouth/nimlibs/blob/master/fowltek/pointer_arithm.nim |
01:20:42 | * | bjz joined #nimrod |
01:20:52 | EXetoC | I linked to that |
01:20:57 | fowl | oh |
01:21:05 | Jehan_ | EXetoC: 0..int.max has had the occasional problems with overflow. |
01:21:19 | Jehan_ | More importantly, {.unchecked.} documents intent. |
01:21:29 | fowl | EXetoC, i owe you $5 when my empire's income allows it |
01:21:55 | EXetoC | Jehan_: right |
01:21:57 | EXetoC | fowl: yay |
01:39:07 | * | Jesin joined #nimrod |
01:40:10 | * | q66 quit (Quit: Leaving) |
01:43:54 | * | Skrylar joined #nimrod |
02:01:19 | Skrylar | boydgreenfield: 'pointer' is a type, which id basically a void* |
02:01:26 | Skrylar | 'ptr X' is a pointer to an X |
02:04:13 | * | brson joined #nimrod |
02:16:43 | * | Varriount joined #nimrod |
02:37:21 | * | brson quit (Ping timeout: 258 seconds) |
02:38:55 | * | brson joined #nimrod |
03:05:09 | * | brson quit (Quit: leaving) |
03:08:42 | * | ehaliewicz quit (Read error: Connection reset by peer) |
03:25:59 | * | boydgreenfield quit (Quit: boydgreenfield) |
03:35:18 | * | boydgreenfield joined #nimrod |
03:40:08 | * | boydgreenfield quit (Client Quit) |
03:57:42 | * | DAddYE joined #nimrod |
03:59:18 | * | milieu quit (Ping timeout: 240 seconds) |
04:04:33 | * | xenagi quit (Quit: Leaving) |
04:21:04 | * | superfunc joined #nimrod |
04:21:29 | superfunc | hey guys, does anybody know of a doxygen style program that supports nimrod for doc generation? |
04:23:36 | reactormonk | superfunc, nope, there's only nimdoc :-/ |
04:24:06 | reactormonk | superfunc, I think I should write a docgen that produces json |
04:24:18 | superfunc | ah, ok |
04:24:54 | superfunc | It doesn't bother me that much, just that my professor wants some docs. |
04:26:41 | superfunc | What does nimdoc provide? |
04:29:44 | reactormonk | html |
04:30:07 | reactormonk | superfunc, http://nimrod-lang.org/system.html |
04:30:10 | reactormonk | e.g. |
04:30:27 | superfunc | |
04:30:59 | superfunc | thanks |
04:31:03 | * | boydgreenfield joined #nimrod |
04:31:14 | superfunc | totally sufficient |
04:35:58 | * | Demos_ quit (Read error: Connection reset by peer) |
04:37:48 | * | superfunc quit (Ping timeout: 240 seconds) |
04:40:22 | fowl | interesting, widestrs is shown there but i dont have access to it |
04:40:36 | fowl | when (defined(windows) and not defined(useWinAnsi)) or defined(nimdoc): |
04:40:36 | fowl | include "system/widestrs" |
04:42:41 | * | DAddYE quit (Remote host closed the connection) |
04:43:08 | * | DAddYE joined #nimrod |
04:47:33 | * | DAddYE quit (Ping timeout: 252 seconds) |
04:53:09 | * | milieu joined #nimrod |
05:01:26 | NimBot | Araq/Nimrod devel 1df344d Araq [+0 ±1 -0]: attempt to fix the bootstrapping |
05:03:36 | * | DAddYE joined #nimrod |
05:03:45 | * | boydgreenfield quit (Quit: boydgreenfield) |
05:44:15 | * | superfunc joined #nimrod |
05:44:45 | superfunc | is there a way to get an int from a Json object? I have been using .fnum for floats, but .num returns a BiggestInt |
05:51:01 | Jehan_ | import json, typetraits |
05:51:01 | Jehan_ | let x = parseJson("1").num.int |
05:51:01 | Jehan_ | echo x, " ", x.type.name |
05:51:06 | Jehan_ | Is that what you need? |
06:00:52 | * | milieu_ joined #nimrod |
06:04:48 | * | milieu_ quit (Ping timeout: 240 seconds) |
06:08:59 | superfunc | I ended up using that |
06:09:03 | superfunc | thank you |
06:09:23 | superfunc | well, I used int( ... ), just because its more clearly a type change to me |
06:13:44 | * | BitPuffin joined #nimrod |
06:24:00 | * | vendethiel joined #nimrod |
06:39:55 | fowl | now this is sexy https://gist.github.com/fowlmouth/d926a6df3036d7ea1c74#file-pv3-nim-L388 |
06:52:02 | * | BitPuffin quit (Ping timeout: 255 seconds) |
06:56:55 | * | BitPuffin joined #nimrod |
06:57:07 | NimBot | Araq/Nimrod devel 1549bed Araq [+0 ±1 -0]: 2nd attempt to fix bootstrapping |
06:58:49 | * | Jesin quit (Ping timeout: 252 seconds) |
06:59:48 | * | milieu quit (Ping timeout: 240 seconds) |
07:15:30 | * | Jesin joined #nimrod |
07:17:20 | * | nande quit (Remote host closed the connection) |
07:28:18 | * | DAddYE quit (Remote host closed the connection) |
07:28:45 | * | DAddYE joined #nimrod |
07:33:06 | * | DAddYE quit (Ping timeout: 240 seconds) |
07:35:48 | * | Jesin quit (Quit: Leaving) |
07:55:14 | Araq | Skrylar: if 'len' cannot be unsigned (and it can't), that surely speaks for itself against unsigned |
07:57:51 | Araq | negative numbers are a blessing and I'm glad math invented them ;-) |
07:59:17 | * | DAddYE joined #nimrod |
07:59:53 | Jehan_ | Araq: https://gist.github.com/rbehrends/2783e808550b1f11ae19 |
08:00:07 | * | flaviu quit (Remote host closed the connection) |
08:10:21 | njoejoe | Jehan_: Araq this might be of interest to you: http://research.microsoft.com/pubs/211297/managedtime.pdf found on hackernews: https://news.ycombinator.com/item?id=7654686 |
08:10:51 | Jehan_ | njoejoe: Yeah, I'm familiar with that research. |
08:12:42 | * | DAddYE quit (Ping timeout: 240 seconds) |
08:17:10 | Araq | Jehan_: I've seen your gist, but i need a barrier that's not initilaized with the N |
08:17:29 | Araq | and thinking about it, there is some entirely different solution for my thread pool |
08:17:37 | Jehan_ | Can you explain what you need? |
08:17:48 | Araq | enter() and leave() |
08:17:49 | Jehan_ | I was figuring you were looking for the standard semantics. |
08:18:12 | Araq | and waitForAll() in the parent thread |
08:18:58 | Araq | but I think it's better when spawn simply generates a unique "task ID" |
08:19:00 | Jehan_ | Hmm, that's not really enough to understand what you want/need? |
08:19:17 | Araq | and the workers then set their task-ID to this value |
08:20:40 | Araq | and then ... hmm |
08:21:05 | Araq | Jehan_: well the N is not known, think about how the current spawn+sync work |
08:22:38 | Jehan_ | Okay, so you want to be able to add more after it started? |
08:25:24 | Araq | right |
08:26:15 | Jehan_ | Shouldn't be too difficult. What's the application? Spawn + sync? |
08:26:27 | Jehan_ | Or a general library mechanism? |
08:29:04 | Araq | spawn+sync, compiler generates the calls, so convenience is not important |
08:29:56 | Jehan_ | I see. |
08:30:19 | Jehan_ | Let me think about it. Once I'm done with work tonight. |
08:30:33 | Jehan_ | Speaking of which, I should probably head out. |
08:30:51 | Jehan_ | See you. :) |
08:30:53 | * | Jehan_ quit (Quit: Leaving) |
08:40:18 | * | chemist69 joined #nimrod |
08:40:20 | Araq | njoejoe: thanks for the link, it's definitely interesting but too immature to be useful for nimrod |
08:40:25 | Araq | hi chemist69 welcome |
08:42:11 | chemist69 | Thanks. I got interested in nimrod by a shoutout in Linux Outlaws, and am just starting to look into it. I am a medicinal chemist and do my "normal" coding in Python and PyQt |
08:44:22 | Araq | ok, so you're the guy who will give us a Qt wrapper ;-) |
08:46:48 | chemist69 | actually, I was hoping my hint would trigger you... |
08:47:37 | chemist69 | But seriously, it would be really nice to have a Qt wrapper. I heard about the GSoC initiative for it, but could not if was accepted ? |
08:48:11 | Araq | well it's not only wrapping it, it has to be maintained as well |
08:49:16 | Araq | the GSoC would have helped but it's no showstopper we haven't got accepted |
08:57:02 | superfunc | Is Qt4 still maintained by Digia? |
09:05:36 | Skrylar | I don't think dom ever mentioned why they rejected nimrod |
09:06:22 | Araq | Skrylar: Google decided Julia has more buzzwords in its description |
09:06:46 | Skrylar | a.k.a. "julia is more easily stolen for our internal interests" probs |
09:07:06 | Araq | they got all the math and scientific computing buzzwords, yes |
09:08:06 | Skrylar | whee last file and webp support is doable |
09:08:46 | Araq | Skrylar: please wrap Qt :-) |
09:08:51 | Skrylar | lolno |
09:09:25 | Skrylar | i think trying to get Qt's weirdness to interop with nimrod would be in total more effort than what i'm already doing O_o |
09:09:44 | * | DAddYE joined #nimrod |
09:09:58 | Skrylar | whatwith the whole MOC thing |
09:10:18 | Araq | MOC is only a preprocessor, I think you can avoid it for bindings |
09:10:43 | Araq | recent versions of Qt don't use it aynmorre anyway afaik |
09:10:57 | Skrylar | did digia decide to turn Qt in to template hell instead |
09:12:27 | Araq | you're never pleased, are you? |
09:12:53 | Araq | looking though our options I think re-activating pas2nim to translate the pascal bindings might be feasiable |
09:14:30 | fowl | does qt have a c interface |
09:14:57 | * | DAddYE quit (Ping timeout: 276 seconds) |
09:18:21 | Araq | of course not, that would be too useful |
09:20:20 | Araq | fowl: the pascal wrapper includes a C wrapper and then wraps that |
09:21:24 | Araq | it also comes with prebuilt DLLs |
09:21:30 | Araq | pretty nice |
09:21:42 | fowl | oo |
09:21:56 | fowl | what license is it? |
09:22:58 | Araq | LGPL |
09:33:49 | superfunc | Qt5 is a damn mess |
09:34:05 | superfunc | and I think Qt4 has to use MOC |
09:38:11 | Araq | what do you mean "it is a mess"? |
09:47:26 | Skrylar | also i remember araq saying he hates sigslots |
09:47:47 | Araq | argh |
09:48:10 | Araq | there is not a single Araq |
09:48:17 | Araq | there are 2 of us |
09:48:32 | Araq | one is concerned with proving code correct |
09:48:50 | Araq | the other doesn't give a shit |
09:48:54 | Skrylar | lol |
09:49:04 | njoejoe | LOL |
09:49:17 | Skrylar | well i already wrote that one callback map thing |
09:49:32 | Skrylar | the one where you register an event type and handlers wx-style |
09:49:43 | fowl | Skrylar, gtk has signals too |
09:49:55 | Skrylar | fowl: yeah, we both had signal libs in nimrod too |
09:50:02 | Skrylar | but there was the whole thing with backrefs and finalizers |
09:50:13 | fowl | Skrylar, still waiting on that demo |
09:50:45 | Skrylar | i have the dynemap since its the closest thing aside from straight-up passing closures around |
09:51:25 | fowl | please write a gc test for my signals, i wrote one but maybe it sucks |
09:51:39 | Skrylar | i don't know more than you would about it |
09:51:49 | fowl | i believe that if you disconnect them properly there is no problem |
09:51:51 | Skrylar | i did it by having it inc/dec a global counter and spitting it out to gnuplot |
09:52:09 | fowl | what does gnuplot have to do with gc references or signals |
09:52:09 | Skrylar | fowl: the whole point to Qt signals is if they are disconnected 'improperly' there is no crash |
09:52:23 | Skrylar | i used it to visualize the amount of references |
09:52:30 | Skrylar | over time |
09:52:50 | Araq | you can use weak references in nimrod |
09:53:26 | Skrylar | i had a module that did all of that; i just wasn't comfortable with it because dead objects could receive callbacks before their finalizers ran |
09:53:45 | Skrylar | which "shouldn't" cause crashes, but doesn't feel very awesome |
09:54:01 | fowl | Skrylar, ive also allowed for the object to be nil and the signal hooked to a global function |
09:54:07 | fowl | havent tested it much though |
09:55:48 | * | superfunc quit (Ping timeout: 240 seconds) |
09:56:25 | fowl | er |
09:57:06 | fowl | how do you fix this accum_repeat is private to the module (in a generic function) Error: undeclared identifier: 'accum_repeat' |
09:57:29 | Skrylar | uh huh, i had that problem earlier fowl |
09:58:03 | Skrylar | generics aren't obeying module scope rules so i had to change my maxrect implementation so private functions had "Internal" in the name but were public :\ |
09:58:25 | fowl | oh so they need new names |
09:58:33 | fowl | how about kill_all_humans |
09:58:42 | Skrylar | i think the generic is being instantiated in the scope where it gets used, which can't see the private symbols |
09:58:51 | Skrylar | instead of instantiated in the scope where it was defined and imported |
09:59:06 | Skrylar | because i had a module import 'rectangle' and use it in a generic |
09:59:21 | Skrylar | this import had to be manually brought to the module which used THAT module, because it didn't take rectangle from the module's scope |
09:59:22 | fowl | im sure this is a regression |
10:02:27 | Skrylar | is something still state of the art if all you did was implement whitepapers ;f |
10:03:07 | fowl | only if you sell your art to the state |
10:10:17 | * | DAddYE joined #nimrod |
10:14:18 | * | DAddYE quit (Ping timeout: 240 seconds) |
10:32:17 | * | BitPuffin quit (Quit: WeeChat 0.4.3) |
10:32:41 | * | vendethiel quit (Ping timeout: 252 seconds) |
10:33:07 | * | vendethiel joined #nimrod |
10:33:56 | * | BitPuffin joined #nimrod |
10:40:34 | Skrylar | okay, webp stuff is jiggled |
10:40:44 | Skrylar | i'll beautify it after a break |
10:40:48 | Araq | generics ARE obeying module scope |
10:41:05 | Araq | there is a serious bug with foo.bar in generics though that I need to fix |
11:11:01 | * | DAddYE joined #nimrod |
11:15:06 | * | DAddYE quit (Ping timeout: 240 seconds) |
11:49:42 | * | Kelet quit (Ping timeout: 258 seconds) |
11:53:12 | * | Kelet joined #nimrod |
11:53:29 | * | menscrem joined #nimrod |
12:11:45 | * | DAddYE joined #nimrod |
12:16:09 | * | DAddYE quit (Ping timeout: 250 seconds) |
12:30:54 | * | Kelet quit (Ping timeout: 258 seconds) |
12:32:48 | * | menscrem quit (Ping timeout: 240 seconds) |
12:46:44 | * | noam__ joined #nimrod |
12:50:11 | * | noam_ quit (Ping timeout: 265 seconds) |
12:55:17 | * | Kelet joined #nimrod |
13:12:30 | * | DAddYE joined #nimrod |
13:13:45 | * | darkf quit (Quit: Leaving) |
13:16:49 | * | DAddYE quit (Ping timeout: 250 seconds) |
13:22:01 | EXetoC | I haven't defined ssl but mongod claims that I've sent an SSL handshake |
13:30:34 | Araq | maybe the error enum changed and it's in fact complaining about something else |
13:32:26 | EXetoC | I just remembered that I got it to work with the legacy protocol, so SSL is being used by accident. besides, the socket code seems pretty well-guarded against these kinds of mistakes |
13:33:33 | EXetoC | well, this is an error message that is printed by the mongod process itself, so it's not sending any information via sockets. could be a server bug though |
13:38:49 | EXetoC | probably neither of those. asking in #mongodb now |
13:47:37 | * | menscrem joined #nimrod |
13:54:40 | EXetoC | what's wrong with allowing SSL support to be set at run time? |
13:57:09 | * | OrionPK quit (Remote host closed the connection) |
14:02:32 | * | wan joined #nimrod |
14:02:36 | * | OrionPK joined #nimrod |
14:09:18 | * | menscrem quit (Ping timeout: 240 seconds) |
14:13:20 | * | DAddYE joined #nimrod |
14:17:30 | * | DAddYE quit (Ping timeout: 240 seconds) |
14:24:21 | * | Skrylar quit (Ping timeout: 276 seconds) |
14:25:58 | * | dymk joined #nimrod |
14:26:19 | dymk | Hi, could someone explain what the purpose of the VM is in nimrod, if it compiles down to C? |
14:36:31 | OrionPK | dymk the VM runs at compile-time, before it hits the C compiler |
14:36:53 | OrionPK | you can use the VM to generate code which then gets compiled |
15:04:10 | * | noam__ is now known as noam |
15:06:47 | dom96 | dymk: It allows for procedural macros to be written using Nimrod code. |
15:10:21 | * | wan quit (Ping timeout: 240 seconds) |
15:14:10 | * | DAddYE joined #nimrod |
15:15:14 | EXetoC | when did he ask something? my client did experience some lag, but that should only caues a delay |
15:15:57 | EXetoC | or maybe there's like a 60 second threshold |
15:18:53 | * | DAddYE quit (Ping timeout: 264 seconds) |
15:19:29 | EXetoC | fowl: neat. will you release that soon? maybe I'll try to implement a BSON parser |
15:21:17 | EXetoC | and will it end up in that monolithic package of yours? :> |
15:25:48 | * | kunev joined #nimrod |
15:33:57 | * | angus quit (Quit: Leaving) |
15:43:44 | fowl | EXetoC, nah, its mainly waiting on a name lol >_> |
15:53:51 | * | wan joined #nimrod |
15:54:35 | * | Puffin joined #nimrod |
15:55:04 | * | BitPuffin quit (Ping timeout: 245 seconds) |
15:55:43 | * | bjz quit (Ping timeout: 252 seconds) |
15:59:54 | * | wan quit (Ping timeout: 276 seconds) |
16:01:56 | * | untitaker quit (Ping timeout: 255 seconds) |
16:07:53 | * | icebattle joined #nimrod |
16:08:49 | * | untitaker joined #nimrod |
16:14:04 | * | Johz joined #nimrod |
16:14:50 | * | DAddYE joined #nimrod |
16:19:06 | * | DAddYE quit (Ping timeout: 240 seconds) |
16:22:06 | * | erlnoob joined #nimrod |
16:23:18 | erlnoob | hi guys, i'm building 0.9.4 from master branch on os x 10.6.8 and got "SIGSEGV: Illegal storage access. (Attempt to read from nil?)" when doing "bin/nimrod c koch" as instructed. help? |
16:25:33 | * | skyfex quit (Ping timeout: 240 seconds) |
16:31:21 | * | chemist69 quit (Quit: leaving) |
16:37:45 | OrionPK | erlnoob bootstrapping might be broken still.. |
16:37:57 | OrionPK | I'll try on my mac in a bit |
16:38:07 | OrionPK | (it was broken last night) |
16:38:16 | erlnoob | oh bummer |
16:39:25 | erlnoob | the binary 0.9.4 version gives out an "Illegal instruction" error on os x 10.6.8 |
16:39:36 | erlnoob | i guess i'm out of luck :( |
16:41:05 | * | Jehan_ joined #nimrod |
16:45:39 | * | flaviu joined #nimrod |
16:51:48 | Araq | erlnoob: afaict 0.9.4 works on mac |
16:53:04 | Araq | OrionPK: bootstrapping should work again now |
16:53:17 | Araq | but erlnoob talked about the master branch anyway |
16:54:16 | OrionPK | im working off master as well |
16:54:25 | OrionPK | afaik |
16:54:50 | Araq | huh? |
16:55:13 | * | DAddYE joined #nimrod |
16:55:44 | Araq | Jehan_: if you run a mac, can you please check bootstrapping works for the master branch? |
16:55:59 | Jehan_ | Araq: Sure, just a second. |
16:56:13 | Araq | thank you |
16:56:34 | Jehan_ | Well, many seconds, actually, but ASAP. :) |
16:56:45 | OrionPK | araq nevermind |
16:56:50 | OrionPK | Im on my mac now araq, checking |
16:57:51 | OrionPK | araq my templates tests get further |
16:57:53 | OrionPK | but still fail |
16:58:09 | Araq | and that is why reduced test cases suck |
16:58:52 | EXetoC | lost issues? |
16:59:27 | EXetoC | you really need to reduce things if you plan on making a bug report for dmd :> |
16:59:55 | OrionPK | well, you could test out the whole templates module |
17:00:10 | OrionPK | https://github.com/onionhammer/onion-nimrod/tree/master/templates |
17:00:12 | Jehan_ | Araq: It works, other than the "executables still not equal" issue with clang. |
17:00:24 | OrionPK | bootstrapping on OSX worked fine though |
17:00:38 | OrionPK | other than what Jehan_ just mentioned about executables still not equal warning |
17:00:54 | Jehan_ | Yeah, but you've got clang to blame for that. :) |
17:01:11 | Jehan_ | I checked it with gcc a few weeks ago and the warning went away. |
17:01:40 | Jehan_ | It's definitely the linker stage, too, so no code that Nimrod generates for clang specifically. |
17:02:01 | Araq | I guess it's simply some timestamp in the exe |
17:06:11 | Jehan_ | Not quite, the hex diffs are more different than that. |
17:06:31 | Jehan_ | Unless it's a variable length timestamp. :) |
17:06:40 | Araq | lol |
17:06:50 | Jehan_ | Can't be code signing, that's a different step. |
17:07:18 | Araq | clang is not deterministic |
17:07:30 | Araq | it's super duper multi threaded :P |
17:13:28 | * | Demos joined #nimrod |
17:16:34 | * | q66 joined #nimrod |
17:16:34 | * | q66 quit (Changing host) |
17:16:35 | * | q66 joined #nimrod |
17:20:12 | * | Matthias247 joined #nimrod |
17:29:27 | * | boydgreenfield joined #nimrod |
17:31:29 | * | q66 left #nimrod ("Leaving") |
17:47:40 | * | erlnoob left #nimrod (#nimrod) |
18:01:28 | * | brechtm joined #nimrod |
18:02:55 | brechtm | hey |
18:02:56 | Araq | hi brechtm |
18:03:07 | Araq | how's c2nim progressing? |
18:03:14 | brechtm | Araq: slowly :) |
18:03:34 | brechtm | haven't had much time last couple of days, but I started documenting the procs |
18:04:03 | brechtm | to get a better overview of the parser |
18:04:19 | Araq | ok, good |
18:15:22 | boydgreenfield | Hi all — sorry for all the questions… but i have another one. If I have an object variant that includes, for example either a seq[int] or a pointer to an array, is there a way to either: 1) declare the same field twice inside of a case statement w/o raising a “redefinition” error; or 2) use a template to check which type of variant the object is to that I can write my array getter/setter code once rather than |
18:15:23 | boydgreenfield | duplicating it? Here’s a gist, https://gist.github.com/boydgreenfield/9a46dbde20f28b5dbcfc. The relevant object members definition is on lines 24 and 26, which the code I’d like to avoid the if/else object variant check for is, e.g., in 79-88. |
18:16:08 | Araq | just pull it outside the variant part then |
18:17:19 | * | nande joined #nimrod |
18:18:37 | Araq | boydgreenfield: make the bitarray_mmap alias the managed bitarray |
18:18:52 | Araq | if the managed bitarray is active |
18:20:11 | Araq | you could hide the access in a template that has an 'if' on the in_memory, but this might slow down every access and produces code bloat |
18:20:41 | boydgreenfield | Araq: The former sounds better – but I must have missed the ability to do aliasing. Is that in the docs? |
18:21:06 | Araq | sure, it's called "addr" |
18:21:34 | Jehan_ | Just be careful not to resize the seq. |
18:22:10 | * | askatasuna joined #nimrod |
18:23:42 | boydgreenfield | Araq: Is there no way to declare the field as some union type, e.g., it’s pointer TFlexibleArray | seq[int]? |
18:24:04 | Araq | the compiler likely eats that and then crashes |
18:24:17 | Jehan_ | That would not be safe, anyway. seq has additional internal fields. |
18:25:09 | Araq | there is object {.union} but this is only for interfacing with C and should not be used with Gc'ed memory as the GC doesn't know about the 'union' |
18:25:24 | boydgreenfield | Then would a template be the best solution? |
18:25:45 | Jehan_ | There's another approach. |
18:26:02 | boydgreenfield | Sytactically, I’d like to be able to just assign bitarray[x], regardless of it’s a seq[int] or a pointer under the covers. |
18:26:09 | Jehan_ | Use alloc0() to allocate memory for the bit pattern in the same format. Then free that in the finalizer. |
18:26:29 | Jehan_ | This way, it's a ptr FlexArray in either case. |
18:26:52 | Jehan_ | To use finalizers, pass a proc as the second argument to new. |
18:27:23 | Araq | he doesn't use new though |
18:27:43 | Jehan_ | E.g., new(foo, finalizerFoo). |
18:27:52 | boydgreenfield | No, I’m not — but I’m more than open to being told I’m doing it the wrong way. |
18:28:00 | Jehan_ | Yeah, but that's just a bit more typing in the creation part. |
18:28:23 | boydgreenfield | I was trying to write a macro with_correct_memory_backing |
18:28:27 | Jehan_ | Basically, if you allocate something with new, you then have to do a lot of result.field = ... |
18:28:54 | Jehan_ | It's a bit more tedious than an object constructor, but allows you to use a finalizer. |
18:29:27 | boydgreenfield | that would basically allow me to write all the bitarray[x] code and substitute in bitarray or bitarray_mmap depending on the value of in_memory, but I haven’t gotten that working yet (can’t seem to figure out how to declare an expression as either seq[int] or ptr FlexArray) |
18:29:28 | Jehan_ | It's not more or less correct, but it allows you to trade off some complexity during object creation for unified access to the bitarray later. |
18:29:57 | Jehan_ | If you do what I suggest, it'd be a ptr FlexArray in both cases. |
18:30:12 | Jehan_ | The variant part would only contain the filehandle. |
18:30:47 | Jehan_ | In one case, you'd use mmap() to allocate the bitarray, in the other you'd use alloc0(). |
18:31:40 | Jehan_ | Basically, rather than having bitarray and bitarray_mmap, you'd only have one bitarray in both cases. |
18:32:50 | boydgreenfield | Jehan_: Ok I’ll explore that. Is it possible to do something like this via templates (the if check should be really cheap anyhow)? I have a non-working sketch in the updated gist, but am not sure how one can properly declare the expressions. |
18:34:06 | Jehan_ | Yes, it's also possible to do that via templates. |
18:34:18 | Jehan_ | Not sure what you mean by "properly declare the expressions", though. |
18:34:40 | Jehan_ | Hmm, let me grab the code and show you what I mean. That may take a few minutes, though. |
18:36:28 | boydgreenfield | Jehan_: Appreciate it. My gist has an example, of the (clearly incorrect) approach I tried. Basically I get an instantiation error or a type error depending on how I try to declare the alias for the bitarray/bitarray_mmap |
18:47:57 | * | boydgreenfield quit (Quit: boydgreenfield) |
18:49:08 | Jehan_ | Hmm, now he's gone just as I'm finished. :) |
18:49:25 | EXetoC | Araq: speaking of allocating with new, wasn't it possible to invoke it implicitly when using the construction syntax? |
18:49:53 | Araq | yeah but that does not support finalizers |
18:50:26 | * | boydgreenfield joined #nimrod |
18:50:37 | Jehan_ | Welcome back. :) |
18:50:42 | Jehan_ | boydgreenfield: https://gist.github.com/rbehrends/087c1edcf90cb590b660 |
18:50:46 | EXetoC | I thought it was in the manual, but can't find it right now |
18:50:57 | EXetoC | is it used anywhere? because I couldn't get it to compile yesterday |
18:51:00 | Jehan_ | This is untested, since I don't have the full code, but it should give you an idea how it can work. |
18:51:18 | Jehan_ | Note that I turned the TBitarray into a ref object so that new() can work. |
18:51:44 | EXetoC | "proc foo: ref T = T(...)"? I tried to explicitly assign to result too |
18:51:51 | flaviu | I assume that `len` on `cstring` scans for a null terminator? |
18:52:06 | boydgreenfield | Jehan_: Thanks, that’s incredibly helpful! I’ll still have to find another problem to use for getting my head fully wrapped around the templating syntax. |
18:52:20 | EXetoC | flaviu: can't see what else |
18:52:35 | EXetoC | since it's binary compatible with char* |
18:54:02 | Jehan_ | The templating error you get is because f is not in scope. |
18:54:22 | Jehan_ | It's only declared for the relevant branch of the if. |
18:55:25 | boydgreenfield | Jehan_: Ah. That makes sense. Do case statements not take bools by default? “Error: selector must be of an ordinal type, float or string” – I mean, it’s easy enough to go case int(in_memory), but that seems very hackish. |
18:56:13 | Jehan_ | I believe they don't, though you have to ask Araq. |
18:56:36 | Jehan_ | I guess it's because a case statement with a bool variable is indistinguishable from an if/else construct. |
18:57:22 | Araq | bool just work just fine with 'case' |
18:57:28 | Jehan_ | Note that you can always do something like "type YesOrNo = enum no, yes" |
18:57:39 | Jehan_ | Araq: Hmm, I just tested it and it didn't? |
18:57:53 | Jehan_ | I had never tried before, though. |
18:58:08 | EXetoC | Araq: "proc foo: ref T = T(...)"? tried with and without result |
18:58:43 | EXetoC | I'll see if has anything to do with variants |
18:58:43 | flaviu | Araq: I get the same error, but `enum t=0, f=1` does work with `case` |
18:59:01 | flaviu | Are bools special-cased in any way in the compiler? |
18:59:26 | Araq | well tyBool is missing for 'semCase' |
18:59:35 | Araq | so it's a simple oversight |
18:59:39 | EXetoC | should work indeed. I saw some bool case today |
18:59:47 | EXetoC | :o |
19:00:14 | Araq | might even be a regression |
19:00:37 | Araq | I bet the code used to use isOrdinalType but doesn't anymore |
19:00:55 | Jehan_ | EXetoC: It works for variant types, just not for case statements. |
19:01:47 | EXetoC | that's indeed how it was used |
19:03:13 | NimBot | Araq/Nimrod devel bdb2d21 Araq [+0 ±1 -0]: bugfix: bool for case statements |
19:03:21 | Araq | there. try again please. |
19:05:44 | boydgreenfield | Jehan_: Ok, got your change integrated. Thanks! Works well, and much cleaner. https://gist.github.com/boydgreenfield/9a46dbde20f28b5dbcfc |
19:06:09 | Jehan_ | Great to hear that! |
19:06:32 | Jehan_ | Just remember that the code is totally untested since, well, I couldn't test it. :) |
19:11:40 | boydgreenfield | Jehan_: I’ve got *some* tests, fortunately. Thanks again :). Is there an emerging unittesting standard (module) for Nimrod btw? |
19:12:10 | Jehan_ | No idea. :) |
19:18:24 | EXetoC | Araq: yeah, works |
19:20:48 | flaviu | strtabs don't seem to do anything special, it looks like they are regular tables with user-specifiable hash functions |
19:21:57 | Araq | boydgreenfield: there is a unittest module but eventually people agree with me and use 'when isMainModule' + doAssert |
19:22:41 | boydgreenfield | Araq: Haha ok. |
19:22:54 | EXetoC | you don't like the extended output? |
19:23:31 | Araq | it needs to say: error, strings differ at position xyz |
19:24:01 | Jehan_ | when isMainModule has the one downside that it's bad in conjunction with include. |
19:24:15 | Araq | but instead it produces colors. yay. |
19:25:29 | flaviu | It also needs to be web-scale and write its results into MongoDB so that nimrod on node can process and display them |
19:25:57 | EXetoC | the AST/value output is useful |
19:26:36 | EXetoC | Araq: sure, orthogonal concepts :p |
19:26:40 | EXetoC | flaviu: that never gets old |
19:31:09 | EXetoC | yeah might as well just use doAssert then ^_^ |
19:35:14 | EXetoC | it's just a matter of patching it, but I wonder if anything can be done about custom types, since `==` can be overloaded |
19:37:19 | Araq | flaviu: ready to fix the remaining VM bugs? |
19:37:37 | EXetoC | the $ outputs could be compared, even though it might not make sense |
19:38:52 | EXetoC | zahary: what's up? has all the hard work not made you rich yet? |
19:42:54 | flaviu | Araq: sure, but my free time might be limited the over the next few weeks. Which bug are you referring to? |
19:43:25 | Araq | onion-nimrod doesn't compile anymore |
19:43:35 | Araq | it used to work with the old VM |
19:53:19 | * | nande quit (Read error: Connection reset by peer) |
19:55:16 | flaviu | StringBuilder has a syntax error, Foo( a : something, b : somethingelse) isn't valid syntax from what I know |
19:55:16 | flaviu | OrionPK: Should the StringBuilder tests pass? They fail for me. Also, StringBuilder is slower than regular concatenation on my computer |
19:56:38 | EXetoC | it is if Foo is an object |
19:59:01 | flaviu | Huh, TIL |
20:00:23 | EXetoC | and optionally (a: x, b: y) for tuples |
20:00:36 | * | boydgreenfield quit (Quit: boydgreenfield) |
20:00:57 | flaviu | Ok, so that seems to be broken in my build |
20:01:41 | Araq | flaviu: additionally my recent patch broke: |
20:01:54 | Araq | macros/tstringinterp.nim (reSuccess -> reNimrodcCrash) |
20:01:55 | Araq | assert/tuserassert.nim (reSuccess -> reNimrodcCrash) |
20:02:30 | Araq | so I guess we need to bite the bullet and fix the underlying problem instead of hacking around *cough* |
20:03:07 | flaviu | Ok, I was on an old build. Everything works fine after pulling |
20:03:13 | Araq | the underlying problem is that the VM doesn't distinguish properly between *definitions* (var x = y) and *updates* (x = y) |
20:03:59 | Araq | and so when a register gets reused we can get some strange behaviours |
20:04:11 | EXetoC | apparently branch hints last mattered for the pentium 4 |
20:05:09 | EXetoC | doesn't stop mongo from using it though |
20:07:45 | Araq | EXetoC: the world doesn't consist of only x86 though |
20:08:29 | Jehan_ | Of course not, there's also x86_64. :) |
20:08:58 | EXetoC | yeah that stackoverflow answer might've been incorrect |
20:09:46 | EXetoC | Jehan_: true |
20:11:44 | Jehan_ | I was trying to be sarcastic. :) |
20:13:00 | Jehan_ | If you think about it, ARM is probably currently the dominant architecture, at least as used by individuals. |
20:13:46 | OrionPK | flaviu dont worry about the stringbuilder heh, it was an experiment |
20:14:49 | flaviu | Ok, I'm surprised that just a few hundred concatenations are about 25 seconds |
20:15:49 | EXetoC | frequent resizes/zeroing? |
20:16:10 | Jehan_ | Sounds like an O(n^2) implementation hiding underneath. |
20:16:39 | * | kunev quit (Ping timeout: 276 seconds) |
20:16:45 | EXetoC | that's exactly what I meant |
20:16:50 | EXetoC | or something |
20:18:17 | * | Puffin quit (Ping timeout: 264 seconds) |
20:19:29 | Araq | well the 'add' doesn't double, but multiplies with 1.5 iirc |
20:20:09 | * | boydgreenfield joined #nimrod |
20:20:13 | * | Puffin joined #nimrod |
20:23:46 | flaviu | With add it's 25s, with a preallocated string it's ~35s |
20:24:37 | Araq | the benchmark executes that loop 100000 times though |
20:24:47 | Araq | might explain the 25s |
20:24:54 | flaviu | Oh, that |
20:25:00 | flaviu | 's it. I didn't notice that |
20:26:41 | Araq | hmm I don't feel like doing hard work |
20:26:57 | Araq | I think I'll try to wrap that COM library |
20:29:13 | * | brson joined #nimrod |
20:30:43 | * | boydgreenfield quit (Quit: boydgreenfield) |
20:31:25 | * | Puffin is now known as BitPuffin |
20:33:23 | * | ehaliewicz joined #nimrod |
20:41:37 | flaviu | Araq: I think I see what you mean. I can't reproduce a certain error if I add an `echo "123"` in, I get a totally different error. |
20:41:56 | * | ND joined #nimrod |
20:42:03 | Araq | hi ND welcome |
20:42:33 | ND | Hi |
20:43:09 | Araq | flaviu: yeah, you need to debug it completely differently |
21:01:30 | * | boydgreenfield joined #nimrod |
21:03:25 | * | zahary1 joined #nimrod |
21:03:34 | * | brechtm quit (Quit: leaving) |
21:04:45 | * | zahary quit (Ping timeout: 240 seconds) |
21:05:57 | * | eigenlicht quit (Ping timeout: 240 seconds) |
21:19:27 | * | eigenlicht joined #nimrod |
21:22:03 | * | flaviu quit (Quit: Leaving.) |
21:31:11 | * | Matthias247 quit (Quit: Matthias247) |
21:33:00 | * | ND quit (Quit: Page closed) |
21:40:33 | * | BitPuffin quit (Quit: WeeChat 0.4.3) |
21:58:10 | OrionPK | really the only module in onion-nimrod i care about is templates |
21:58:19 | OrionPK | I want to split that off into its own repo and put it on babel |
22:04:27 | njoejoe | what is onion-nimrod? |
22:06:52 | EXetoC | a lib |
22:08:59 | njoejoe | i'm guessing this: https://github.com/onionhammer/onion-nimrod a webserver of sorts? |
22:10:24 | EXetoC | it's a collection of libs, but I don't see a web server |
22:14:43 | njoejoe | EXetoC: i was looking at this: https://github.com/onionhammer/onion-nimrod/blob/master/nimuv/nimuv.nim |
22:19:03 | EXetoC | I didn't care to look in it. I just saw uv in the name |
22:54:35 | * | Jehan_ quit (Quit: Leaving) |
23:14:41 | boydgreenfield | On my system, the .compile. pragma breaks with a linking error if the .nim file and .c file share the same name. This isn’t in the documentation. Should I create a PR that adds this to the docs, or try and diagnose the underlying issue (don’t have any experience whatsoever looking at the compiler)? Example: https://gist.github.com/boydgreenfield/85d0e4053d2151108264 |
23:17:08 | fowl | boydgreenfield, i think your problem will go away if its imported from a babel package |
23:17:42 | fowl | boydgreenfield, only local files dont get prefixed in nimcache (`ls nimcache`) |
23:18:09 | boydgreenfield | Ah. Well then I suppose that *really* makes it an edge case. |
23:18:58 | * | darkf joined #nimrod |
23:20:33 | boydgreenfield | Indeed — it works fine in another directory. |
23:23:49 | * | DAddYE quit (Remote host closed the connection) |
23:35:19 | * | Johz quit (Quit: Leaving) |