| 00:00:39 | Araq | EXetoC: int32 on a 32bit machine for length only causes problems if your data structure is more 2GB **and** you have to use byte addressing for it |
| 00:00:44 | flaviu | I misunderstood then |
| 00:01:02 | Araq | EXetoC: and guess what ... that never happens |
| 00:02:12 | njoejoe | btw, when hashing, i had to & 0xffffffff the value in ruby to keep it 32 bit as you see in the gist |
| 00:04:42 | EXetoC | Araq: pretty close to never at least |
| 00:05:10 | EXetoC | so yeah all good |
| 00:05:42 | Araq | close enough to never that's not worth the trouble of making 'len' unsigned in the language |
| 00:06:10 | Araq | which would be bug prone as hell |
| 00:08:14 | * | Skrylar joined #nimrod |
| 00:09:24 | flaviu | Wow, murmurhash3 is much worse than I thought: http://floodyberry.com/noncryptohashzoo/Murmur-bic.html |
| 00:10:01 | flaviu | wrong link, actually http://floodyberry.com/noncryptohashzoo/Murmur3-bic.html |
| 00:13:48 | * | jbe joined #nimrod |
| 00:16:57 | boydgreenfield | flaviu: What are you using it for? |
| 00:18:14 | Araq | flaviu: any progress on the VM bugs? |
| 00:18:43 | flaviu | boydgreenfield: I was using it as a PRNG, nothing really security sensitive. But I like to use the fastest and best hash function, which is apparently CrapWow. |
| 00:18:43 | flaviu | Araq: Nope, I've been studying and fixing my computer. I have the weekend free though. |
| 00:18:59 | * | jbe quit (Remote host closed the connection) |
| 00:19:02 | Araq | ok thanks |
| 00:19:13 | Araq | still want me to install Arch btw? |
| 00:20:32 | flaviu | Sure, if you're looking for a new OS. Main thing with Arch is the AUR and that it installs the bare minimum initially. |
| 00:20:38 | boydgreenfield | flaviu: I haven’t looked into this recently, but the last time I compared things Mumur was still among the best choices for speed and distribution (along with CityHash — which I think is used extensively at Google). |
| 00:21:19 | njoejoe | CrapWow. gawd hackers are hilarious. |
| 00:21:23 | boydgreenfield | flaviu: “SuperFastHash” is slower than murmur and I’ve noticed some distribution issues with it. I don’t know that I ever tried CrapHash extensively — but perhaps that’s because of all the inline asm? |
| 00:21:34 | boydgreenfield | (or at all) |
| 00:21:46 | flaviu | boydgreenfield: http://floodyberry.com/noncryptohashzoo/ |
| 00:21:46 | flaviu | SuperFastHash is terrible |
| 00:22:05 | flaviu | 7 cycles per byte and poor distribution |
| 00:22:30 | boydgreenfield | flaviu: Was just looking at that. See code re: asm: http://floodyberry.com/noncryptohashzoo/CrapWow64.html |
| 00:22:34 | boydgreenfield | not clear how portable it is. |
| 00:22:44 | njoejoe | flaviu: wasn't there something about intel putting hardware crc32 in place? |
| 00:22:52 | flaviu | Skip to `elif !defined(INTEL)` |
| 00:22:59 | boydgreenfield | flaviu: If useful, I have a simple murmur3 wrapper on my machine all ready to push to GitHub for nimrod. Should I send it up? |
| 00:23:52 | njoejoe | http://www.strchr.com/crc32_popcnt |
| 00:27:16 | flaviu | njoejoe: It takes 0.62 cycles/byte, crapwow takes .73. Its i5/i7 only too, and implementing crc32 in software is 7 cycles/byte. Not really worth it. |
| 00:28:04 | Araq | good night guys |
| 00:28:18 | Araq | and just fyi I will be offline the entire next week |
| 00:28:25 | njoejoe | gnite Araq |
| 00:28:30 | Araq | so don't worry, I'm not dead |
| 00:28:46 | Araq | with a bit of luck I'll come back with another killer feature after this week |
| 00:29:24 | njoejoe | missing programmer posted on hackernews :-) |
| 00:32:09 | EXetoC | more features? ok fine :p |
| 00:32:23 | flaviu | boydgreenfield: CityHash uses is heavily inspired by murmerhash (according to the source comments), so it probably inherits its weaknesses. I haven't actually tested it though |
| 00:33:16 | boydgreenfield | flaviu: Fair enough. That said, I tend to trust Google more than this hash that is only documented in one place (“CrapWow64” yields only 9 results on Google — and likely Bing too ;) ). |
| 00:36:37 | * | springbok joined #nimrod |
| 00:38:31 | * | springbok quit (Changing host) |
| 00:38:31 | * | springbok joined #nimrod |
| 00:42:22 | * | brson quit (Quit: leaving) |
| 00:47:45 | * | Demos joined #nimrod |
| 00:48:54 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:50:08 | flaviu | boydgreenfield: Definitely don't use it without doing your own tests, but it does look promising. Searching just "CrapWow" yields a few hundred more results, I guess the guy who made the zoo modified it himself for 64 bits? |
| 00:53:43 | * | xenagi joined #nimrod |
| 01:03:02 | * | DAddYE quit (Remote host closed the connection) |
| 01:15:14 | * | psquid_ quit (Ping timeout: 255 seconds) |
| 01:17:19 | * | psquid_ joined #nimrod |
| 01:23:22 | flaviu | boydgreenfield: Well, you made me curious, so I'm waiting for CrapWow to pass through SMHasher, which MurmerHash uses to verify itself |
| 01:32:11 | boydgreenfield | flaviu: Let me know what you find. I am working on some bioinformatics stuff that makes extensive use or murmur, and it’s been pretty good to date, but could always be improved (that said, the cost of memory access trumps the hashing time by a substantial factor) |
| 01:47:44 | flaviu | boydgreenfield: CrapWow is a fraction of a cycle faster than MurmerHash3, but it has several cases where it fails utterly. MurmerHash3 is likely the best hash there is at this time. I'll post the full output from SMHasher on gist as soon as it finishes. |
| 01:51:13 | flaviu | https://gist.github.com/flaviut/71b771138800dedf7066 |
| 01:51:18 | reactormonk | boydgreenfield, which kind of bioinfo? |
| 01:54:28 | renesac | flaviu, when I researched about hashes sometime ago murmurhash3 was the best one in speed/quality for small strings/integers |
| 01:54:46 | renesac | for example, in this test it don't fails: http://research.neustar.biz/2012/02/02/choosing-a-good-hash-function-part-3/ |
| 01:55:00 | renesac | the "spectrograms" are dark |
| 01:55:32 | renesac | I'm not sure if this bit independence is the same as avalanche |
| 01:55:51 | renesac | but looks like it |
| 01:56:42 | flaviu | renesac: Yes, I thought that crapwow might be slightly better, but on several types of inputs it fails. It also isn't very fast on small inputs, ~100 cycles for 1-31 byte inputs. |
| 01:56:45 | renesac | flaviu, here murmurhash3 tested as a PRNG: http://xorshift.di.unimi.it/ |
| 01:57:27 | flaviu | renesac: Yes, I've been using that site. Its embarrassing how slow and crappy the java PRNG is |
| 01:58:26 | renesac | heh |
| 01:58:40 | renesac | it is an NSA backdoor |
| 01:58:56 | flaviu | It tested MurmurHash3 with dieharder too, it failed several there, although that may have been my own fault for a too-small sample size |
| 01:58:59 | flaviu | https://gist.github.com/flaviut/9376985 |
| 01:59:42 | renesac | well, remember that it has only a 64bit state |
| 01:59:43 | Demos | dieharder is a research project from UMass right? |
| 01:59:48 | renesac | it is impressive how well it does |
| 02:00:23 | Demos | oh no |
| 02:00:25 | Demos | that is something else |
| 02:00:40 | flaviu | My sample was only a few hundred MBs, even smaller than the state size |
| 02:01:44 | renesac | well, I consider a pretty good trade-off speed/quality when you have fast multiplies (like on modern x86) |
| 02:01:51 | renesac | it is pretty solid |
| 02:02:17 | renesac | only not cryptographic, so the seed can be easily bypassed in a DDOS attack |
| 02:02:52 | renesac | that is why siphash was made |
| 02:03:51 | renesac | but it's slower |
| 02:03:56 | boydgreenfield | reactormonk: Mainly metagenomics to date, though my friend/colleague and I are also starting to do some human genetics work (his phd) |
| 02:04:00 | * | DAddYE joined #nimrod |
| 02:04:11 | boydgreenfield | reactormonk: E.g., this involves a lot of hashing: www.helix.io. What’s your background? |
| 02:05:10 | boydgreenfield | I’m actually on here mostly bc I’m exploring using Nimrod for building out our bioinformatics tooling – speed/terseness feels like it could be a good fit, although migrating away from the beauty that is IPython notebooks (+ C extensions) is a drawback |
| 02:05:55 | * | xenagi quit (Quit: Leaving) |
| 02:06:53 | reactormonk | boydgreenfield, NLP |
| 02:07:18 | reactormonk | currently messing with some IE |
| 02:08:14 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 02:09:22 | boydgreenfield | reactormonk: IE? |
| 02:10:18 | reactormonk | boydgreenfield, information extraction |
| 02:10:27 | boydgreenfield | flaviu: Thanks btw. I’ll rush my repo up to Github if you want to use it as a wrapper / we can move it into babel too. I only have a hash(string) function implemented at the moment — but it’s easy to extend. |
| 02:10:56 | boydgreenfield | reactormonk: Ah. Well, I have to dart off for dinner — but would be curious to see a link to what you’re using Nimrod for then. Cheers. |
| 02:11:07 | flaviu | I think I'll write my own eventually so I can do my own mixing, but feel free to upload it |
| 02:11:08 | reactormonk | boydgreenfield, did some homework with it |
| 02:12:48 | boydgreenfield | flaviu: Great. Probably will wait until tomorrow, but will add then (it’s really trivial, but nice to have it in a module) |
| 02:13:33 | flaviu | Not hash mixing, stuff like element1 !# element2 !# element3 |
| 02:14:08 | flaviu | ok, whenever you get around to it. I don't need it any time soon |
| 02:16:56 | * | superfunc joined #nimrod |
| 02:19:08 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 02:29:47 | * | flaviu quit (Quit: Leaving.) |
| 02:59:02 | * | q66 quit (Quit: Leaving) |
| 03:00:10 | superfunc | Araq: what type of sort does stdlib use? |
| 03:31:12 | * | DAddYE joined #nimrod |
| 03:49:18 | * | superfunc quit (Ping timeout: 240 seconds) |
| 03:51:59 | * | xenagi joined #nimrod |
| 03:53:11 | * | BitPuffin quit (Ping timeout: 255 seconds) |
| 04:15:59 | * | psquid_ quit (Ping timeout: 252 seconds) |
| 04:50:41 | * | springbok quit (Ping timeout: 264 seconds) |
| 05:01:30 | * | bjz joined #nimrod |
| 05:05:00 | * | Demos quit (Read error: Connection reset by peer) |
| 05:10:12 | * | gsingh93 quit (Quit: ZNC - http://znc.in) |
| 05:29:56 | * | DAddYE quit (Remote host closed the connection) |
| 05:43:45 | * | DAddYE joined #nimrod |
| 05:47:31 | * | psquid_ joined #nimrod |
| 06:10:48 | * | xenagi quit (Quit: Leaving) |
| 07:09:24 | Araq | superfunc: a stable mergesort |
| 07:13:45 | * | DAddYE quit (Remote host closed the connection) |
| 07:34:14 | * | bjz_ joined #nimrod |
| 07:41:35 | * | Kelet quit (Ping timeout: 258 seconds) |
| 07:46:43 | * | nande quit (Read error: Connection reset by peer) |
| 07:47:44 | * | bjz quit (Ping timeout: 258 seconds) |
| 07:49:33 | * | Kelet joined #nimrod |
| 08:18:31 | * | JStoker quit (*.net *.split) |
| 08:29:28 | * | JStoker joined #nimrod |
| 08:29:59 | * | JStoker quit (Max SendQ exceeded) |
| 08:30:06 | * | JStoker joined #nimrod |
| 08:30:06 | * | JStoker quit (Changing host) |
| 08:30:06 | * | JStoker joined #nimrod |
| 08:44:15 | fowl | <_< https://gist.github.com/fowlmouth/67c4916e6bf2cb143f45 |
| 08:57:24 | * | bjz_ quit (Read error: Connection reset by peer) |
| 08:57:49 | * | bjz joined #nimrod |
| 09:00:23 | * | Matthias247 joined #nimrod |
| 09:13:01 | * | io2 joined #nimrod |
| 09:27:29 | milosn | morning |
| 09:27:33 | milosn | hi Araq |
| 09:42:11 | * | JonCB joined #nimrod |
| 09:56:42 | * | Varriount-Mobile joined #nimrod |
| 10:15:20 | * | spot35 joined #nimrod |
| 10:23:21 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 10:25:01 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 10:43:27 | * | EXetoC joined #nimrod |
| 10:44:55 | * | kunev joined #nimrod |
| 10:48:14 | * | EXetoC quit (Client Quit) |
| 10:50:39 | * | EXetoC joined #nimrod |
| 10:57:17 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 11:32:30 | Araq | hi JonCB welcome |
| 11:32:31 | Araq | hi milosn what's up? |
| 11:33:46 | JonCB | Araq: thanks you. :) |
| 11:35:44 | JonCB | I did have a question if someone's awake. |
| 11:36:09 | Araq | well I'm awake, I'm not the greeting bot |
| 11:37:41 | JonCB | Is there a gotcha involved with the queue module? When i try to use it in a different module it keeps complaining about the count variable anytime i try to call the dequeue procedure |
| 11:37:56 | JonCB | (complains at compile time) |
| 11:38:27 | Araq | it's a known regression, yes |
| 11:38:36 | Araq | remove the 'assert' and it should work |
| 11:38:53 | Araq | btw for thread communication you should use a TChannel |
| 11:39:21 | JonCB | aah. excellent. Thanks. :) I figured either it'd be known or i was doing something wrong. |
| 11:40:36 | JonCB | yep. This isn't for thread communication. |
| 12:13:05 | * | BitPuffin joined #nimrod |
| 12:22:28 | * | q66 joined #nimrod |
| 12:22:29 | * | q66 quit (Changing host) |
| 12:22:29 | * | q66 joined #nimrod |
| 12:42:41 | * | Varriount|Mobile joined #nimrod |
| 12:44:20 | * | Varriount-Mobile quit (Ping timeout: 240 seconds) |
| 13:04:22 | * | darkf quit (Quit: Leaving) |
| 13:11:23 | milosn | umm can someone tell me more about threading? or where is nimrod threading described in a bit more detail? |
| 13:15:06 | milosn | found something in the manual :) |
| 13:15:21 | milosn | guess ill have to write some code and see how it works in practice |
| 13:19:10 | milosn | Araq: not much, still playing with the ORM ... i realised i need a connection pooling mechanisam ... and to make one thats correct i need to understand how treading works |
| 13:19:16 | milosn | *threading even |
| 13:20:35 | milosn | from the looks of things, threads dont share a thing in nimrod ... so i am not sure i could have global CONNECTIO_POOL variable that holds the mysql DB connections |
| 13:20:47 | milosn | which threads can access to acquire connection |
| 13:28:13 | EXetoC | Araq, here's the error when booting with C++: https://gist.github.com/EXetoC/8cf0e7f605f2a452c01f |
| 13:33:20 | fowl | milosn, threads have their own stack and heap, there is also a shared heap |
| 13:33:32 | EXetoC | "bson_type_t value_type; union ..." can I represent this with an object variant? I don't know much about the union pragma, but this would be preferable |
| 13:34:30 | fowl | EXetoC, it will work if the alignment is right |
| 13:35:00 | fowl | EXetoC, for example this doesnt work with SDL2 because they pack the SDL_EVENT struct but it works with allegro and csfml |
| 13:35:29 | fowl | exetI would use a {.union.} type for the union field |
| 13:35:56 | EXetoC | and maybe you could specify where the variant field should appear. is it at the top by default? |
| 13:36:17 | fowl | its above where the union would be |
| 13:36:58 | EXetoC | what types accept the union pragma? apparently c2nim turned the union into a tuple |
| 13:37:16 | fowl | obj type |
| 13:39:50 | * | flaviu joined #nimrod |
| 13:39:58 | * | noam_ joined #nimrod |
| 13:40:56 | EXetoC | fowl, and the packed pragma wouldn't help in that case? perhaps it doesn't work with unions |
| 13:41:01 | EXetoC | ill start of with a union |
| 13:43:41 | * | noam quit (Ping timeout: 276 seconds) |
| 13:45:03 | * | spot35 quit (Read error: Connection reset by peer) |
| 13:49:24 | * | noam_ is now known as noam |
| 13:50:20 | * | JonCB quit (Ping timeout: 255 seconds) |
| 13:57:28 | fowl | i didnt know about packed pragma, its worth a try |
| 14:06:15 | * | JonCB joined #nimrod |
| 14:11:05 | * | JonCB quit (Ping timeout: 264 seconds) |
| 14:41:53 | * | BitPuffin quit (Quit: WeeChat 0.4.3) |
| 14:42:10 | * | BitPuffin joined #nimrod |
| 14:56:22 | * | kunev quit (Quit: Lost terminal) |
| 14:57:17 | Araq | EXetoC: well please fix it and make a PR |
| 14:57:43 | Araq | extra points for a test that checks the compiler itself compiles as C++ |
| 14:59:07 | flaviu | Araq: You mentioned a command to repr things in the compiler, but I forgot its name |
| 14:59:12 | * | zahary joined #nimrod |
| 14:59:43 | Araq | 'debug' and renderTree, flaviu |
| 15:00:18 | flaviu | Thanks, I wasn't sure what to google |
| 15:01:00 | Araq | the last lines in vmgen.nim show how to output the produced bytecode for a proc |
| 15:01:33 | Araq | though this is not really useful anymore IMO |
| 15:01:37 | EXetoC | I'm still clueless and I can't get endb to work |
| 15:01:40 | EXetoC | I might give it a shot |
| 15:02:11 | Araq | the produced bytecode is correct anyway, the remaining bugs are flaws in the VM design that we need to fix |
| 15:03:45 | Araq | EXetoC: so use GDB instead :P |
| 15:05:26 | flaviu | Araq: Actually, the vmgen messes in a certain case, it tries to perform opcEqInt on rkInt, rkNode, rkInt |
| 15:06:24 | Araq | no, that's the design bug I'm talking about |
| 15:06:37 | Araq | opEqInt is the correct opcode |
| 15:06:56 | Araq | that the VM ends up passing rkNode to it is the problem |
| 15:54:11 | * | DAddYE joined #nimrod |
| 15:59:30 | Araq | hey DAddYE |
| 15:59:40 | DAddYE | heeeeeeeeeeeeeeeeeeeeeeeeeyyyyyyyyyyyyyyy |
| 16:01:32 | * | tdc_ joined #nimrod |
| 16:01:44 | * | tdc_ quit (Read error: Connection reset by peer) |
| 16:03:32 | * | untitaker quit (Ping timeout: 240 seconds) |
| 16:09:03 | * | untitaker joined #nimrod |
| 16:10:09 | Araq | any progress on clan2nim? ;-) |
| 16:28:57 | * | nicolastarzia joined #nimrod |
| 16:29:17 | flaviu | Araq: Sorry, but I'm completely lost by what's going on in the VM and am getting nowhere, so I'm going to find easier bugs to fix instead. |
| 16:29:47 | Araq | flaviu: alright, that's perfectly fine with me |
| 16:30:04 | Araq | the VM is vastly more complex than I thought it would be ... |
| 16:30:11 | Araq | hi nicolastarzia welcome |
| 16:30:28 | nicolastarzia | hi Araq |
| 16:39:18 | * | flaviu quit (Remote host closed the connection) |
| 17:12:10 | njoejoe | how to create a sequence of arrays? var a = @[array[0..1,uint32]] ; a.add([uint32(0),uint32(1)]) chokes on me: Error: internal error: GetUniqueType |
| 17:14:52 | * | Matthias247 joined #nimrod |
| 17:17:25 | * | Demos joined #nimrod |
| 17:20:46 | dom96 | njoejoe: var a: seq[array[0..1, uint32]] = @[] |
| 17:21:04 | * | radsoc quit (Remote host closed the connection) |
| 17:23:16 | njoejoe | thanks dom96. and for a fixed length array of sequences, would it be: var b = array[0..255,seq[array[0..1,uint32]]] ? |
| 17:23:39 | dom96 | no |
| 17:23:44 | dom96 | s/=/:/ |
| 17:24:29 | njoejoe | oh yeah. thanks. |
| 17:34:21 | * | kunev joined #nimrod |
| 17:42:03 | * | Demos_ joined #nimrod |
| 17:42:29 | * | Demos quit (Quit: No Ping reply in 180 seconds.) |
| 17:45:54 | * | Varriount|Mobile is pondering how one would build a proactor based asyc framework |
| 17:46:41 | Varriount|Mobile | I wonder if an api like the one windows employs would be sufficient. |
| 17:46:54 | milosn | whats BiggestInt? |
| 17:46:58 | milosn | int64? |
| 17:47:32 | Varriount|Mobile | milosn: Yes |
| 17:47:54 | EXetoC | those types are in the system module |
| 18:05:44 | fowl | i'd pay for a decent project name generator |
| 18:08:51 | EXetoC | got 100 libs in the pipeline? |
| 18:12:52 | Matthias247 | Varriount: hmm, look up boost asio :) |
| 18:19:02 | * | boydgreenfield joined #nimrod |
| 18:22:19 | * | boydgreenfield quit (Client Quit) |
| 18:24:17 | * | bjz quit (Ping timeout: 264 seconds) |
| 18:35:15 | njoejoe | I have: var cells: seq[array[0..1,uint32]] = @[]. but when I do: while cells[i][1] != 0: I get a compile error, type mismatch. i have tried uint32() on both indexes, but still same error. |
| 18:37:07 | njoejoe | i initialize the cells like: for x in 0..ncells-1: cells.add( [uint32(0),uint32(0)] ) |
| 18:42:10 | * | bjz joined #nimrod |
| 18:42:45 | EXetoC | import unsigned? |
| 18:43:04 | EXetoC | yeah that's it |
| 18:43:55 | njoejoe | i already have import unsigned (i think i needed that for shr shl operators to work) |
| 18:44:16 | EXetoC | that's how I got rid of any type mismatch errors |
| 18:44:24 | EXetoC | for the actual condition |
| 18:45:00 | EXetoC | so I guess you aren't referring to `==` |
| 18:47:38 | njoejoe | i have tried all combinations of unit32 such as while cells[uint32(i)][uint32(1)] != uint32(0): to no avail. i am missing some fundamental understanding of seqs of arrays i think. |
| 18:48:40 | EXetoC | it works for me like I said, so either you haven't provided us with the correct information, or the compiler is outdated |
| 18:48:56 | EXetoC | wait |
| 18:49:41 | EXetoC | what is the type of 'i'? it works with "for i in 0 .. 100" |
| 18:50:52 | EXetoC | and an 'int' loop var is most likely what you want |
| 18:52:11 | njoejoe | I gisted it here: https://gist.github.com/ef7bcff862510476d063 line 53 triggers the error. i'm guessing there are more errors after that is fixed |
| 18:53:31 | EXetoC | just index with int |
| 18:54:19 | njoejoe | ah, so while cells[int(i)]... thanks. on to the next one :-) |
| 18:54:45 | EXetoC | the reason why int is used is because unsigned types are problematic, and that signed indexing is sufficient in virtually every case |
| 18:55:06 | dom96 | Varriount|Mobile: Asyncdispatch is proactor based. |
| 18:55:32 | dom96 | You may remember it was called proactor some time ago. |
| 18:59:32 | EXetoC | I guess the error message for `[]` isn't entirely obvious in this case |
| 19:01:26 | njoejoe | i got it to compile. it's not making correct data, but at least it's compiling now :-) |
| 19:05:21 | EXetoC | also, array[n, T] is short for array[0 .. n-1, T] |
| 19:06:00 | njoejoe | ah, that's good to know. much nicer. |
| 19:06:30 | EXetoC | indeedio |
| 19:12:18 | Varriount | dom96: Not quite correct. It uses the proactor mechanism on windows, but it is not itself a proactor. |
| 19:13:18 | dom96 | Varriount: What is the definition of a proactor? |
| 19:15:35 | fowl | EXetoC, voidexpr(x):expr = not(compiles(type(x))) |
| 19:16:08 | fowl | i could have saved myself a lot of trouble |
| 19:19:02 | EXetoC | it took a long time to get the other approach to work? |
| 19:19:13 | * | io2 joined #nimrod |
| 19:21:29 | fowl | EXetoC, before, i relied on checking a proc nodes return type |
| 19:22:23 | Araq | and now we see why 'compiles' is dangerous |
| 19:22:25 | EXetoC | I thought we both presented decent solutions yesterday |
| 19:22:38 | Araq | once we fix 'type' for void, voidexpr breaks ... |
| 19:22:53 | * | flaviu joined #nimrod |
| 19:23:07 | EXetoC | at least my solution wouldn't be affected by that. don't know about yours |
| 19:23:08 | fowl | that will introduce other bugs |
| 19:23:23 | Araq | fowl: like? |
| 19:23:23 | fowl | EXetoC, your solution? |
| 19:24:49 | fowl | Araq, i cant see the future in vivid detail, only in vague glimpses, thats how my power works |
| 19:25:34 | Araq | ok .... sometimes I forget that there are people unlike me who don't know everything. |
| 19:25:55 | EXetoC | hm, what was it? anyway, didn't you do something like "T: not void"? |
| 19:26:48 | fowl | EXetoC, its a nice notation but void is broken |
| 19:27:22 | fowl | it doesnt have effect |
| 19:27:41 | fowl | and you could still call it explicitly |
| 19:27:52 | EXetoC | is the macro approach not future-proof? |
| 19:28:25 | EXetoC | verbose or not. you'd just make it re-usable anyway. though I don't know if you can resolve aliases |
| 19:29:19 | fowl | i relied on nnkEmpty or nnkIdent "void" |
| 19:32:35 | fowl | Araq, should "discard echo("hi")" work? |
| 19:33:46 | Araq | fowl: no |
| 19:35:39 | Araq | fowl: c++ allows return proc_returning_void(); for generic programming |
| 19:35:52 | Araq | maybe we should do the same? |
| 19:35:57 | * | kunev quit (Quit: leaving) |
| 19:37:28 | fowl | that sounds good but discard should be compatible with return |
| 19:38:04 | Araq | yeah sure for consistency |
| 19:38:38 | Araq | however this should work: |
| 19:39:10 | Araq | proc g[T](f: proc (): T): T = f() |
| 19:39:18 | Araq | no screw this, 'void' is not inferred |
| 19:39:29 | Araq | according to the manual at least |
| 19:39:44 | fowl | not currently but that makes currying harder |
| 19:40:35 | njoejoe | alrighty! nimrod cdb writer working. 12 seconds to create on 10mm record set vs 10 minutes with ruby, vs 3.5 seconds with C. |
| 19:41:02 | EXetoC | optimizations on and all? |
| 19:41:30 | njoejoe | yeah. i'm sure it could be sped up. just wanted to get it working first |
| 19:43:34 | Araq | ping flaviu |
| 19:43:44 | flaviu | Hi |
| 19:44:07 | Araq | well it sucks when (human) resources are not used |
| 19:44:27 | Araq | so have you found something you want to work on? |
| 19:44:41 | dom96 | EXetoC: What happened to that babel issue report about dependencies? Did you ever create it? |
| 19:45:01 | flaviu | Araq: No, I've been messing with virtual machines though, for cross-platform testing |
| 19:46:08 | flaviu | But there's issues with numeric literals in some cases, I can look at that |
| 19:46:14 | Araq | flaviu: well I can give you plenty of work |
| 19:46:27 | Araq | numeric literals work fine I think |
| 19:47:18 | Araq | why should 0xff'i8 work? an int8 can't hold 255 |
| 19:49:22 | flaviu | You're right, but then the 'i8 notation should also be an error |
| 19:50:30 | flaviu | But 0xFFu8 should work, and it also throws an error |
| 19:53:18 | Araq | ok fine, work on that then |
| 19:54:06 | njoejoe | anyone have any idea if "nimrod i" will be fixed in the near future? certainly would be handy for learning the ins and outs of nimrod |
| 19:55:19 | * | DAddYE quit (Remote host closed the connection) |
| 19:55:29 | Araq | njoejoe: depends mostly on whether clang will ever provide a "void run_c_code(char* code);" |
| 19:55:47 | * | DAddYE joined #nimrod |
| 19:56:30 | Araq | the current way that relies on the VM that doesn't support FFI is a deadend for "nimrod i" |
| 20:00:04 | * | Varriount-Mobile joined #nimrod |
| 20:00:04 | * | Varriount|Mobile quit (Read error: Connection reset by peer) |
| 20:00:14 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 20:01:03 | njoejoe | gotcha. I see that there is a C++ repl (Cling) http://root.cern.ch/drupal/content/cling not sure if it has any useful bits. |
| 20:04:42 | Demos_ | hm, newSeq seems to not be working that well |
| 20:06:26 | * | Varriount-Mobile quit (Read error: Connection reset by peer) |
| 20:06:32 | * | Varriount-Mobile joined #nimrod |
| 20:09:19 | * | Varriount-Mobile quit (Read error: Connection reset by peer) |
| 20:15:47 | EXetoC | Demos_, why not? |
| 20:15:57 | EXetoC | dom96, no |
| 20:16:18 | Demos_ | EXetoC: I think it was just an error in my code, or maybe in repr |
| 20:23:28 | Araq | somebody should really fix the remaining bugs in repr |
| 20:23:48 | Araq | amazing how popular 'repr' is ... I never use it |
| 20:29:04 | njoejoe | Araq: what do you use? I would love it if there was a nimrod debugger with emacs interface for setting breakpoints watches, etc. i don't even know if such a thing is possible. |
| 20:29:38 | Araq | sure it's possible and existing GDB plugins already work decently |
| 20:29:54 | Araq | compile with --debuginfo and --lineDir:on |
| 20:31:21 | flaviu | njoejoe: There is a nimrod debugger, though without a emacs interface. |
| 20:31:54 | * | flyx quit (Excess Flood) |
| 20:31:54 | flaviu | The main issue with it is that it doesn't compile :P |
| 20:31:55 | * | flyx joined #nimrod |
| 20:32:06 | Araq | njoejoe: I use 'echo' though and my own debug stuff, like 'debug', 'renderTree' or 'echoCode'. |
| 20:32:06 | Araq | oh and 'injectStmt' ... my new favourite |
| 20:33:46 | Araq | 'injectStmt' the best thing since sliced bread and makes Nimrod the language with the best debugging supoort ever |
| 20:33:52 | * | Araq coughes |
| 20:36:12 | EXetoC | dom96, working on it now. I guess I just need to traverse recursively |
| 20:36:47 | dom96 | EXetoC: oh, are you fixing it? |
| 20:37:27 | EXetoC | trying |
| 20:43:18 | EXetoC | existing packages are removed before building starts? |
| 20:43:54 | dom96 | not from the hard drive |
| 20:44:10 | dom96 | babel builds a list of paths for the packages that package you are building depends on |
| 20:44:13 | dom96 | and passes it to the compiler |
| 20:45:34 | EXetoC | there's no babel anymore after the installation fails |
| 20:45:59 | EXetoC | while choosing to overwrite |
| 20:46:21 | dom96 | if you're installing babel then it does get removed before installing yes |
| 20:46:37 | EXetoC | before building too apparently |
| 20:47:22 | dom96 | impossible |
| 20:48:25 | EXetoC | babel install -> compilation fails -> babel install -> "nope, can't find it" |
| 20:48:30 | EXetoC | impossible where? on windows? |
| 20:48:42 | EXetoC | with its locking mechanism |
| 20:49:03 | dom96 | building shouldn't remove anything |
| 20:49:15 | dom96 | except the dependencies |
| 20:49:22 | dom96 | if it's updating dependencies |
| 20:50:20 | dom96 | and yeah, the removal of the package should happen right before the new files are to be copied over |
| 20:50:25 | dom96 | so that's a bug |
| 20:51:09 | EXetoC | only the binary seems to be removed |
| 20:51:40 | flaviu | what does procvar do? Make it passable as a function pointer? |
| 20:53:25 | Araq | flaviu: exactly |
| 20:53:33 | Araq | it's a controversial feature |
| 20:53:47 | Araq | but IME works better than the alternatives |
| 20:53:53 | dom96 | oh yeah. |
| 20:54:02 | EXetoC | as a function pointer? in what way? |
| 20:54:17 | * | dom96 is still not convinced |
| 20:54:19 | EXetoC | I've only needed closure |
| 20:54:36 | dom96 | But I haven't seriously started using FP in Nimrod yet. |
| 20:56:30 | * | DAddYE joined #nimrod |
| 20:56:50 | Demos_ | speaking of babel, it will not install on OpenBSD, since on openBSD libssl does not depend on libcrypto, so you need to dlopen libcrypto before libssl and pass the RTLD_GLOBAL flag to dlopen. I have no idea how to get nimrod's codegen to actually do this |
| 20:57:37 | EXetoC | both are needed but one does not depend on the other? |
| 20:57:57 | Demos_ | yes |
| 20:57:59 | * | iNode001 quit (Ping timeout: 252 seconds) |
| 20:58:01 | Araq | likely with --dynlibOverride and linking to their import libraries |
| 20:58:02 | dom96 | We can get rid of the babel SSL dependency now. |
| 20:58:12 | Demos_ | libssl will not load (undefined symbols) without loading libcrypto |
| 20:58:23 | Demos_ | I tried dynlibOverride but it did not work |
| 20:58:27 | Demos_ | although I think I fixed it |
| 21:00:40 | Demos_ | dynlibOverride does not work since babel recompiles itself when you install it |
| 21:01:08 | * | DAddYE quit (Ping timeout: 276 seconds) |
| 21:01:08 | Demos_ | oh, I could use a .cfg file I guess |
| 21:03:17 | Demos_ | OK that worked |
| 21:17:08 | EXetoC | did you add a platform check? |
| 21:18:02 | * | Skrylar quit (Ping timeout: 276 seconds) |
| 21:38:58 | Demos_ | no, but I will if I submit a PR. |
| 21:39:34 | Demos_ | there was also a bug in sockets.nim, again I will make a PR after putting this stuff into git |
| 21:41:03 | * | chaoticelf13 joined #nimrod |
| 21:43:53 | * | Demos_ quit (Read error: Connection reset by peer) |
| 21:54:40 | * | DAddYE joined #nimrod |
| 21:58:14 | Araq | hi chaoticelf13 welcome |
| 21:58:25 | chaoticelf13 | hello Araq |
| 21:58:57 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 21:59:11 | reactormonk | chaoticelf13, o/ |
| 22:12:34 | * | chaoticelf13 quit (Quit: Leaving) |
| 22:16:19 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 22:47:43 | flaviu | There's a ton of magic in the stdlib, and I don't really like that since 95% of the magic could be implemented with emit. |
| 22:51:06 | flaviu | I'm looking for comments on that, so if anyone is against it or has a reason it wouldn't work. |
| 22:53:01 | * | JonCB joined #nimrod |
| 22:55:29 | * | DAddYE joined #nimrod |
| 22:57:13 | Araq | what? and how do you interpret at compile-time .emit? |
| 22:58:26 | dom96 | Brace yourselves, I mentioned nimrod in #go-nuts |
| 22:58:41 | Araq | .magic is only in< system.nim and some core modules anyway |
| 22:59:08 | flaviu | Araq: I'm mostly not a fan of strings being covered in magic |
| 22:59:30 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 23:00:08 | Araq | most other languages don't even have .magic and it's all directly built-in instead. |
| 23:00:35 | Araq | no idea how you can critic a true improvement |
| 23:02:04 | flaviu | Araq: proc substr(...) = when Javascript: {.emit: "$str.substring($n1)".} else: #Nimrod code implementing substring |
| 23:02:05 | EXetoC | hiding it is worse I think |
| 23:03:49 | flaviu | I want magic's implementation to be part of the method's body, not the compiler. Magic should be reserved for things that *really* need special casing by the compiler |
| 23:04:05 | EXetoC | that's one of many procs. but why not just include a body then? |
| 23:04:11 | EXetoC | rather than emitting |
| 23:05:01 | flaviu | EXetoC: I don't understand what you're saying |
| 23:07:38 | flaviu | My syntax for the emit was wrong, I didn't look it up before writing that line. |
| 23:07:47 | EXetoC | how do you run that on the VM? |
| 23:09:45 | Araq | well what we can do, is leave the .magic annotation but provide C/JS implementation directly in the body with 'when' and 'emit' |
| 23:10:29 | Araq | and then flaviu's remaining complain is about how large system.nim is ... ;-) |
| 23:10:39 | flaviu | EXetoC: It gets a bit more complicated then, but in many cases the VM can parse the regular nimrod AST, which would simplify the VM, and there could be a special pragma to emit VM AST for certain functions. I'm not sure about the second alternative |
| 23:11:46 | flaviu | But it would somewhat simplify vmgen |
| 23:12:14 | Araq | flaviu: rigth now I'm implementing rules like x <= x + c iff c >= 0. The compiler really needs to know about the semantics for + and <= |
| 23:12:36 | Araq | that's what .magic does, there is no way to get around it |
| 23:13:31 | Araq | and it wouldn't simplify vmgen because the hard things are not even touched by your proposal |
| 23:14:36 | flaviu | Araq: What things are hard? I'm not familiar enough with the vm to know what the hard things are. |
| 23:19:17 | Araq | the hard thing is the data representation in the VM with its ability to model ASTs as they are in the compiler and at same time supporting types like 'var int' |
| 23:20:16 | Araq | the addressing modes like a.f[i] that needs to work if 'a' is a local variable and hence in a register |
| 23:20:34 | Araq | and also if 'a' is a global variable and thus not in a register |
| 23:21:39 | Araq | all the other things in the VM are straight forward, IMHO anyway |
| 23:23:24 | * | darkf joined #nimrod |
| 23:28:16 | Araq | good night and remember: I'm mostly offline this week, starting with today |
| 23:29:03 | flaviu | night |
| 23:42:27 | * | DAddYE joined #nimrod |
| 23:45:46 | * | JonCB quit (Ping timeout: 258 seconds) |
| 23:51:05 | * | JonCB joined #nimrod |
| 23:51:17 | * | JonCB quit (Client Quit) |
| 23:52:26 | * | boydgreenfield joined #nimrod |
| 23:54:12 | * | DAddYE_ joined #nimrod |
| 23:54:28 | * | DAddYE quit (Read error: Connection reset by peer) |