| 00:00:00 | * | Nimrod quit (Ping timeout: 255 seconds) |
| 00:00:23 | BlameStross1 | ok. This is a learning project. Right now I think the casts are the best solution becuase a lot of the logic is as follows: bump the uint32 up to int63, do math, convert the bottom 32-bits and make a new uint32 again. |
| 00:00:30 | BlameStross1 | *int64 |
| 00:01:03 | Araq | type conversions are usually nicer |
| 00:01:16 | BlameStross1 | type conversion do things like move sign politely |
| 00:01:21 | BlameStross1 | I want to avoid that |
| 00:01:33 | Araq | oh ok |
| 00:01:42 | Araq | so you know what you're doing |
| 00:01:48 | BlameStross1 | about that bit, yes |
| 00:02:00 | BlameStross1 | so, explain what I am doing wrong with sequences. |
| 00:02:18 | BlameStross1 | BigIntDigits=seq[uint32] |
| 00:02:26 | BlameStross1 | looked like just a type delcaration |
| 00:02:30 | Araq | you allocate 2 when 1 would do too |
| 00:02:43 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 00:02:44 | Araq | the type declaration is not the problem at all |
| 00:02:51 | BlameStross1 | ok so: proc initBigInt *(val: uint32): BigInt = |
| 00:02:51 | BlameStross1 | result.digits = BigIntDigits(@[val]) |
| 00:02:51 | BlameStross1 | result.neg = false |
| 00:02:54 | BlameStross1 | ??? |
| 00:02:57 | Araq | no |
| 00:03:01 | Araq | proc invert |
| 00:03:22 | Araq | result = initbigInt(0) # ok, we have result.digits we can use |
| 00:03:33 | Araq | result.digits = digits # but we don't... damn |
| 00:03:44 | BlameStross1 | ok, I do that becuase my constructor inits it with an item, and I wanted it empty. Better to remove the item then to re-initalize? |
| 00:04:04 | Araq | setLen is your friend |
| 00:05:00 | BlameStross1 | aha |
| 00:05:13 | Araq | but you need a better initBigInt that doesn't start with a sequence of length one here |
| 00:05:31 | BlameStross1 | discard result.digits.pop() is what my first through was |
| 00:06:01 | Araq | that works too and might end up having the same performance |
| 00:06:22 | BlameStross1 | this is my fix, new constructor: |
| 00:06:23 | BlameStross1 | proc initBigInt *(): BigInt = |
| 00:06:23 | BlameStross1 | result.digits = BigIntDigits(@[]) |
| 00:06:23 | BlameStross1 | result.neg = false |
| 00:06:56 | Araq | you can do: result.digits = @[] btw |
| 00:09:28 | BlameStross1 | that was some of the first code I wrote, I was still paranoid about matchign typing |
| 00:11:29 | BlameStross1 | I really do not want to do bigint render as decimal. It hurts to think about doing efficently. |
| 00:11:30 | * | Nimrod joined #nimrod |
| 00:11:30 | * | Nimrod quit (Changing host) |
| 00:11:30 | * | Nimrod joined #nimrod |
| 00:11:52 | * | johnsoft quit (Read error: Connection reset by peer) |
| 00:14:53 | BlameStross1 | now I am going to crawl into the lshift and rshift based math with will make it a lot faster. |
| 00:15:08 | Araq | great |
| 00:15:15 | BlameStross1 | One question I asked earlier but did not get answered, how compatible with the ordinal type should I make it |
| 00:15:26 | BlameStross1 | obviously ord(BigInt) does not work well |
| 00:15:40 | Araq | don't bother with 'ord' |
| 00:15:50 | BlameStross1 | but decrement and increment work |
| 00:16:17 | Araq | look at it this way: you're writing the foundations that perhaps the compiler will use internally |
| 00:16:20 | BlameStross1 | well, I I make ord do the bottom k-bits then I would make the type hashable. |
| 00:16:40 | flaviu | BlameStross1: That isn't how you're supposed to make it hashable |
| 00:16:49 | Araq | no, just provide a 'hash' instead |
| 00:16:56 | flaviu | ^ |
| 00:17:34 | Araq | BlameStross1: again, bigint may be built into the language |
| 00:18:09 | Araq | so that bigint literals work etc. |
| 00:18:24 | BlameStross1 | Araq: oh gods. I like the idea of being that useful but I somehow doubt you want the guy who literally learned the language this morning to write that code. |
| 00:18:34 | BlameStross1 | Araq: Bigint leiteral would require a string parser >.< |
| 00:18:51 | Araq | lol |
| 00:18:55 | BlameStross1 | which is not as bad as a string generator, but wont be fun. |
| 00:19:03 | Araq | as if a string parser would be hard |
| 00:19:57 | Araq | oh btw |
| 00:20:12 | Araq | you shouldn't provide >, >= and != |
| 00:20:43 | BlameStross1 | that makes sense, defaults to inverting their complements? |
| 00:20:50 | Araq | system.nim knows a > b is b < a |
| 00:21:16 | Araq | a != b --> not (a == b) |
| 00:21:37 | BlameStross1 | well, I went the c/assembly route of writing cmp, so they were trvial |
| 00:22:31 | * | BlameStross1 is now known as blamestross |
| 00:22:34 | Araq | well you either write idiomatic code or you don't |
| 00:22:47 | Araq | I'm telling you how the idiomatic code looks like |
| 00:24:02 | blamestross | thats actually the bit I want opinions on. I program a lot but I rarely program code that needs to be maintained. (mostly 1-off, does this technique work sort of things) I am a phd student and I do a lot of fun stuff, but most of it only ever needs to be run once or twice. |
| 00:27:19 | * | Demos quit (Ping timeout: 244 seconds) |
| 00:27:59 | blamestross | In retrospect, comments seem like a good idea |
| 00:42:18 | * | boydgreenfield joined #nimrod |
| 00:43:59 | * | boydgreenfield quit (Client Quit) |
| 00:49:09 | * | superfunc quit (Ping timeout: 252 seconds) |
| 00:49:31 | * | superfun1 quit (Ping timeout: 240 seconds) |
| 00:58:13 | * | ARCADIVS joined #nimrod |
| 01:04:36 | * | goobles quit (Quit: Page closed) |
| 01:05:47 | * | brson quit (Quit: leaving) |
| 01:24:20 | * | Demos joined #nimrod |
| 01:31:46 | * | hoverbear joined #nimrod |
| 01:33:15 | * | goobles joined #nimrod |
| 01:41:51 | * | kshlm quit (Quit: Konversation terminated!) |
| 01:43:37 | * | Demos quit (Read error: Connection reset by peer) |
| 01:49:10 | * | q66 quit (Quit: Leaving) |
| 02:08:15 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) |
| 02:08:38 | blamestross | So I am going a bit nuts. int32, int64, uint32, uint64 all seem to have spotty coverage on basic operations. I'm looking at an error that says there is no system./(x: int64, y:int64) defined |
| 02:09:13 | blamestross | why have the types if you don't seem to be able to use them? This seems so basic it indicates I am missing something important about the language. |
| 02:11:48 | flaviu | blamestross: / returns a float |
| 02:12:04 | flaviu | try `div` |
| 02:12:42 | * | Nimrod_ joined #nimrod |
| 02:13:15 | blamestross | found the issue, int64 divided by int64 returning an int64 is defined as the `/%` operation. |
| 02:15:36 | * | Nimrod quit (Ping timeout: 260 seconds) |
| 02:16:45 | blamestross | ok, the fundamental bit I was missing and getting frustrated by was that `/` is not integer division, `/%` is integer division. |
| 02:17:26 | flaviu | blamestross: `/%`will do what you want, but I'd say that `div` is the better choice because it is specifically designed for integer division. The *`%` series are supposed to be used for mod-{32,64} arithmetic; I'm not really sure why `/%` even exists. |
| 02:18:14 | blamestross | im doing mod 2^32 and 2^64 arithmetic so it works |
| 02:23:24 | * | flaviu quit (Remote host closed the connection) |
| 02:37:57 | * | darkf quit (Ping timeout: 272 seconds) |
| 02:40:12 | * | darkf joined #nimrod |
| 02:40:58 | * | boydgreenfield joined #nimrod |
| 02:45:15 | * | flaviu joined #nimrod |
| 02:56:42 | * | Nimrod__ joined #nimrod |
| 02:58:53 | * | brson joined #nimrod |
| 02:59:48 | * | Nimrod_ quit (Ping timeout: 264 seconds) |
| 03:05:14 | * | superfunc joined #nimrod |
| 03:16:15 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 03:21:56 | * | ARCADIVS joined #nimrod |
| 03:30:19 | * | superfunc quit (Ping timeout: 246 seconds) |
| 03:42:45 | * | kshlm joined #nimrod |
| 04:37:17 | * | Nimrod__ is now known as Nimrod |
| 04:37:46 | * | Nimrod is now known as Guest65798 |
| 04:38:07 | * | Guest65798 quit (Changing host) |
| 04:38:07 | * | Guest65798 joined #nimrod |
| 04:51:55 | * | flaviu quit (Ping timeout: 240 seconds) |
| 05:16:57 | * | gkoller joined #nimrod |
| 05:18:52 | * | vendethiel joined #nimrod |
| 05:27:26 | * | boydgreenfield joined #nimrod |
| 05:30:26 | * | kshlm quit (Quit: Konversation terminated!) |
| 05:41:48 | * | brson quit (Quit: leaving) |
| 05:49:08 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 05:55:01 | * | boydgreenfield joined #nimrod |
| 06:11:43 | * | hoverbear quit () |
| 06:19:56 | * | kshlm joined #nimrod |
| 06:23:39 | * | nande quit (Read error: Connection reset by peer) |
| 06:26:25 | * | vbtt joined #nimrod |
| 06:26:30 | vbtt | hello friends |
| 06:27:03 | vbtt | whats new |
| 06:27:51 | vbtt | the usability of 1.6.2 is fantastic, btw. |
| 06:28:15 | vbtt | sorry, wrong channel, ignore last msg |
| 06:28:42 | flyx | morning folks |
| 06:29:33 | flyx | the compiler thinks line 6 contains an invalid expression here: https://gist.github.com/flyx/b8c1e4a4e0e8b5995889 |
| 06:29:53 | flyx | I don't really see what's the problem, as line 5 works |
| 06:33:34 | * | superfunc joined #nimrod |
| 06:33:53 | * | kunev joined #nimrod |
| 06:34:01 | * | kunev quit (Client Quit) |
| 06:37:22 | flyx | ah, it only works for multiple parameters |
| 06:50:08 | flyx | the "+" operator on sets compile time always raises a SIGSEGV. known bug? |
| 06:50:19 | flyx | *+at (compile time) |
| 06:59:05 | * | flyx opened an issue |
| 07:05:15 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 07:11:10 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 07:35:12 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 07:36:18 | superfunc | I wonder how hard it would be to achieve lazy data structures in nim, not that I want or need them for anything |
| 07:36:49 | Araq | not hard, closure iterators should work very well for these |
| 07:37:12 | Araq | the stdlib doesn't deal with closure iterators at all though, since they are too new |
| 07:38:04 | superfunc | neat, I'll look into them, haven't had the chance yet |
| 07:41:06 | * | superfunc quit (Quit: Page closed) |
| 07:41:17 | * | kunev joined #nimrod |
| 08:00:22 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) |
| 08:04:04 | * | brson joined #nimrod |
| 08:07:56 | Skrylar | lazy structures... hmmm |
| 08:08:01 | Skrylar | I guess it depends on what you need |
| 08:08:13 | Skrylar | Judy arrays are apparently very good, but.. well, patentcrap |
| 08:08:35 | Araq | Judy arrays are not lazy |
| 08:26:05 | * | kunev quit (Ping timeout: 264 seconds) |
| 08:29:27 | def- | Is the goal for nimrod to have its own bigints implementation or a binding to gmp (or another library)? |
| 08:30:05 | Araq | its own |
| 08:30:35 | Araq | other solutions don't work well with nimrod's memory management, not with compile-time evaluation |
| 08:30:43 | Araq | *nor with |
| 08:33:52 | * | kshlm quit (Quit: Konversation terminated!) |
| 08:34:01 | def- | ok, thanks |
| 08:34:17 | Edelwin | hahah, I discovered that $ is used to turn ints into a string :') |
| 08:34:34 | Edelwin | (when you come from sysadmin world, especially with *sh, this is very disturbing :p) |
| 08:35:06 | Araq | when you come from *sh your brain is already damanged :P |
| 08:35:12 | Araq | *damaged |
| 08:35:46 | Edelwin | yes, but your infrastructure is fully functionnal! |
| 08:35:55 | Edelwin | (or almost, but it's fixable with a shell script) |
| 08:41:16 | Edelwin | by the way, Araq. Sometimes I see "Error: invalid module name: <program_name>" when I compile. Are there restrictions concerning the name of the programs? |
| 08:55:36 | * | BitPuffin joined #nimrod |
| 08:55:58 | * | kunev joined #nimrod |
| 09:02:15 | Araq | well it has to be a valid nimrod identifier |
| 09:13:42 | flyx | the `==` for PTables doesn't work - it uses the same template as `==` for TTables, and hasKey doesn't dereference the pointer |
| 09:14:12 | flyx | I'll fix that later when I'm not waiting for the doctor |
| 09:16:42 | flyx | but how do I check if a PTable is nil? `==` is defined for (PTable, PTable), so if I try to use that inside the `==` implementation, it will just call itself |
| 09:36:52 | * | brson quit (Ping timeout: 245 seconds) |
| 10:20:34 | def- | any reason why you can't += with uint64s? |
| 10:22:36 | Edelwin | Araq: where can I find a list of these indentifiers? because having a "-" in the program name is quite common for me, and I'd like to know what I must avoid in the future |
| 10:23:01 | def- | Edelwin: http://nimrod-lang.org/manual.html#identifiers-keywords |
| 10:23:17 | Edelwin | thanks :) |
| 10:25:48 | def- | ok, probably because there is no int128. can anything be done about that? |
| 10:27:26 | Araq | flyx: system.isNil exists for that |
| 10:28:04 | flyx | Araq: ah. I guess I should just read the whole system.nim when I have time |
| 10:31:06 | Araq | you can also use sytem.`==` for the builtin pointer comparison |
| 10:58:45 | Araq | def-: I think += simply got its constraints wrong |
| 11:04:02 | def- | Araq: I'll see if i can find where, thought it may be intentional |
| 11:04:35 | Araq | nope, unsigned simply was added lately to the language and it still shows |
| 11:33:17 | Edelwin | hmmm |
| 11:33:24 | Edelwin | I got errors with this code => No stack traceback available |
| 11:33:27 | Edelwin | http://paste.debian.net/107004/ |
| 11:33:34 | Edelwin | (damn, wrong copy/paste order) |
| 11:33:50 | Edelwin | config/nimrod.cfg(37, 2) Hint: added path: '/home/edelwin/.babel/pkgs/' [Path] |
| 11:33:50 | Edelwin | Hint: used config file '/opt/nimrod_0.9.4_linux_amd64/config/nimrod.cfg' [Conf] |
| 11:33:50 | Edelwin | Hint: system [Processing] |
| 11:33:50 | Edelwin | Hint: Tserver [Processing] |
| 11:33:50 | Edelwin | Error: internal error: GetUniqueType |
| 11:33:53 | Edelwin | No stack traceback available |
| 11:34:31 | dom96 | s/=/:/ |
| 11:34:43 | dom96 | in your var declarations |
| 11:35:07 | dom96 | and in line 11 add TServer before the ( |
| 11:35:08 | def- | and , after serverx.hostname |
| 11:35:49 | Edelwin | oh damn |
| 11:35:50 | def- | dom96: but it's a tuple |
| 11:36:02 | Edelwin | thanks again |
| 11:36:09 | dom96 | def-: oh you're right |
| 11:36:24 | dom96 | Edelwin: yeah, sorry. You don't need the TServer before the ( |
| 11:37:28 | Edelwin | whoohooo \o/ new errors |
| 11:37:57 | Edelwin | Tserver.nim(17, 12) Error: identifier expected, but found 'server1.hostname' |
| 11:37:58 | Edelwin | :D |
| 11:38:08 | Edelwin | I think echo() don't like the way I do |
| 11:38:39 | def- | Edelwin: , after server1.hostname |
| 11:39:04 | Edelwin | the comma *before* the double quote |
| 11:39:05 | Edelwin | :) |
| 11:39:06 | Edelwin | thanks |
| 11:39:21 | def- | you're welcome |
| 11:39:30 | Edelwin | \o/ |
| 11:46:43 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 12:03:22 | def- | Araq: i think it's not wrong constraints. In compiler/types.nim it says "caution: uint, uint64 are no ordinal types!" |
| 12:08:13 | Araq | def-: yes but that doesn't mean += should not be available for uint64 |
| 12:08:38 | def- | Araq: but += is defined for TOrdinal and floats. should i add a version for uint and uint64? |
| 12:08:46 | Araq | yes |
| 12:24:22 | * | untitaker quit (Ping timeout: 245 seconds) |
| 12:29:59 | * | untitaker joined #nimrod |
| 12:47:50 | * | io2 joined #nimrod |
| 12:49:27 | * | flaviu joined #nimrod |
| 13:06:30 | * | darkf quit (Quit: Leaving) |
| 13:26:40 | * | io2 quit (Ping timeout: 260 seconds) |
| 13:45:21 | * | pafmaf joined #nimrod |
| 13:52:59 | * | pafmaf quit (Quit: This computer has gone to sleep) |
| 13:53:43 | * | io2 joined #nimrod |
| 13:54:33 | * | gkoller quit (Ping timeout: 248 seconds) |
| 13:55:03 | * | pafmaf joined #nimrod |
| 14:00:36 | * | pafmaf quit (Quit: This computer has gone to sleep) |
| 14:01:25 | * | pafmaf joined #nimrod |
| 14:04:17 | NimBot | Araq/Nimrod new_spawn 4099abc Billingsly Wetherfordshire [+0 ±1 -0]: added `==` for PJsonNode |
| 14:04:17 | NimBot | Araq/Nimrod new_spawn 56a912f klaufir [+0 ±1 -0]: adding header pragma for printf ffi example |
| 14:04:17 | NimBot | Araq/Nimrod new_spawn 93fa75b Clay Sweetser [+0 ±6 -0]: Fixed #1172 (for real) |
| 14:04:17 | NimBot | Araq/Nimrod new_spawn c2b58f3 Reimer Behrends [+0 ±1 -0]: Properly terminate "nimrod i" on end of file.... 5 more lines |
| 14:04:17 | NimBot | 59 more commits. |
| 14:08:57 | NimBot | Araq/Nimrod new_spawn 7958648 Araq [+0 ±1 -0]: compiles again |
| 14:48:09 | flyx | is nil == nil in Nimrod semantics? |
| 14:55:37 | def- | flyx: after trying around a bit i would say yes |
| 14:56:17 | flyx | well this isn't obvious for some languages… |
| 15:03:46 | flaviu | Some languages = SQL :P |
| 15:10:52 | shevy | haha |
| 15:10:56 | shevy | in haskell it might be |
| 15:10:57 | shevy | maybe |
| 15:21:36 | * | Guest65798 is now known as Nimrod |
| 15:32:56 | * | Nimrod quit (Read error: Connection reset by peer) |
| 15:41:43 | * | Trustable joined #nimrod |
| 15:45:59 | blamestross | bigints fast multiplication and lshift work. About to work on rshift and division. All the documentation on how to do bigints assumes you can use bit-strings, using 32-bit ints as the atomic unit requires some fiddly bitwise math. |
| 15:46:12 | * | io2 quit (Ping timeout: 260 seconds) |
| 15:55:42 | * | newbie194 joined #nimrod |
| 15:55:48 | * | newbie194 left #nimrod (#nimrod) |
| 15:57:33 | * | Nimrod joined #nimrod |
| 15:57:42 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 16:00:11 | * | EXetoC joined #nimrod |
| 16:06:05 | * | johnsoft joined #nimrod |
| 16:08:12 | * | hoverbear joined #nimrod |
| 16:12:19 | * | hoverbea_ joined #nimrod |
| 16:12:31 | * | hoverbea_ quit (Max SendQ exceeded) |
| 16:13:03 | * | hoverbea_ joined #nimrod |
| 16:14:43 | * | hoverbear quit (Ping timeout: 240 seconds) |
| 16:15:39 | * | 1JTAAQ2HF joined #nimrod |
| 16:15:40 | * | superfunc joined #nimrod |
| 16:19:31 | * | Matthias247 joined #nimrod |
| 16:22:17 | * | shevy quit (Ping timeout: 245 seconds) |
| 16:26:01 | * | johnsoft quit (Ping timeout: 248 seconds) |
| 16:30:27 | blamestross | Are there more mutators for a seq than add and pop? |
| 16:34:56 | * | shevy joined #nimrod |
| 16:35:17 | flyx | I cannot put anything in a PTable at compile time. it does work with a TTable. the error is different from #903 |
| 16:38:48 | * | kunev quit (Ping timeout: 264 seconds) |
| 16:42:22 | flyx | https://github.com/Araq/Nimrod/issues/1314 |
| 16:42:39 | flyx | that error might be easier to track down as it's not a SEGFAULT, but a failed assertion |
| 16:47:40 | * | foodoo joined #nimrod |
| 16:52:39 | foodoo | I like to define a set of integer values. What I currently have is: let numbers = set[int] = { 1, 2, 3 } |
| 16:52:55 | foodoo | But I get the following compilation error: Error: set is too large |
| 16:53:26 | foodoo | I know that Nimrod's standard set types use bitfields. How can I tell Nimrod that my set won't be too big? |
| 16:53:34 | flyx | foodoo: use set[int8] = {1'i8, 2'i8, 3'i8} |
| 16:54:01 | flaviu | foodoo: `let numbers = { 1, 2, 3 }` works for me |
| 16:54:09 | * | superfun1 joined #nimrod |
| 16:54:36 | foodoo | I know that Nimrod's standard set types use bitfields. How can I tell Nimrod that my set won't be too big? |
| 16:54:39 | foodoo | ups |
| 16:55:09 | foodoo | sorry for the repeated message. And yes, now it compiles when I leave out the type information |
| 16:55:12 | EXetoC | that might result in a low range type though |
| 16:55:12 | flaviu | Well, if you make a set of ints, that set will be 2^{32,64} bits long, which is too big |
| 16:55:55 | foodoo | It won't be a set of ints. Just a set of some fixed numbers |
| 16:56:16 | EXetoC | nope, set[range[0..65535]] apparently |
| 16:56:19 | EXetoC | that's reasonable |
| 16:56:24 | * | xtagon joined #nimrod |
| 16:56:25 | flaviu | ok, just don't worry about types then. Make the set and let type inference deal with it |
| 16:56:52 | foodoo | But it now dawns on me that I misunderstood what is meant by "bitvector" in the Nimrod documentation |
| 16:57:40 | * | vendethiel joined #nimrod |
| 17:01:06 | * | Demos joined #nimrod |
| 17:03:15 | blamestross | When nimrod tries to use int64 on a 32bit system, do things break? |
| 17:03:35 | flaviu | blamestross: Nope, unless you're talking about javascript |
| 17:03:43 | reactormonk | blamestross, they are just slower |
| 17:04:23 | blamestross | yay! my uint32 to int64 to uint32 hackery is cross platform! |
| 17:04:48 | reactormonk | blamestross, do not use unsigned ints |
| 17:05:09 | flaviu | reactormonk: He's justified here, he's doing bignums |
| 17:05:38 | blamestross | essentially if I use signed ints I suddenly need a lot of logic to correct for sign changes |
| 17:06:34 | reactormonk | flaviu, good, I'll go back to my trollcave |
| 17:06:43 | blamestross | the other option would be to store 31-bits per bignum-digit, which would make the not fun digit manipulation worse |
| 17:08:13 | flaviu | I also highly doubt that 64 bit integers are significantly slower on 32 bit systems on any recent systems |
| 17:08:45 | * | enurlyx joined #nimrod |
| 17:08:46 | reactormonk | sounds like they require two operations instead of one to me |
| 17:09:33 | blamestross | They are used as buffer-room while doing operations that might involve more than trivial carries up or down the bigint. Mostly for shl and shr. |
| 17:24:23 | Demos | question: why do imported symbols get their own scope? |
| 17:24:32 | Demos | well their own PScope data structure |
| 17:25:49 | flaviu | "0xFFFFFFFF is not a valid number" |
| 17:25:54 | flaviu | Huh? |
| 17:32:26 | * | nande joined #nimrod |
| 17:32:49 | reactormonk | maybe it's converted to signed int |
| 17:33:33 | flaviu | Nah, I came across a old bug |
| 17:33:54 | foodoo | I'm wondering where the code for Nimrod's set-implemenation can be found. I've searched https://github.com/Araq/Nimrod but I found only declarative code for the set methods |
| 17:34:16 | flaviu | foodoo: https://github.com/Araq/Nimrod/blob/devel/compiler/bitsets.nim |
| 17:34:25 | foodoo | flaviu: thanks |
| 17:34:50 | flaviu | Unfortunately, you'll have to search the compiler itself when you come across things marked as magic |
| 17:38:21 | * | vendethiel quit (Quit: q+) |
| 17:42:29 | * | enurlyx quit (Quit: Nettalk6 - www.ntalk.de) |
| 17:52:20 | * | brson joined #nimrod |
| 18:20:09 | * | q66 joined #nimrod |
| 18:21:00 | foodoo | I can't find the symbol for bit-and in the documentation. & doesn't seem to work with 2 integer operands. |
| 18:21:41 | def- | foodoo: and? |
| 18:22:24 | foodoo | does that perform bitwise and-ing? |
| 18:22:35 | def- | yes |
| 18:22:45 | def- | if the parameters are ints |
| 18:23:00 | Araq | flaviu: 0xffff... needs some type prefix |
| 18:23:10 | Araq | the compiler refuses to guess what you mean for it |
| 18:23:31 | flaviu | type postfix? I did have that, but it didn't get rendered in the error message |
| 18:23:59 | flaviu | https://github.com/Araq/Nimrod/issues/1166 |
| 18:24:45 | foodoo | def-: Are you really sure? The compiler complains: got (int) but expected 'bool' |
| 18:25:20 | def- | foodoo: if you want to check if something was set afterwards you have to do != 0 |
| 18:25:50 | foodoo | def-: ah, yes that's the problem |
| 18:28:08 | * | vendethiel joined #nimrod |
| 18:28:28 | * | gkoller joined #nimrod |
| 18:28:30 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 18:29:31 | * | gkoller quit (Client Quit) |
| 18:29:32 | * | johnsoft joined #nimrod |
| 18:31:28 | * | EXetoC joined #nimrod |
| 18:35:11 | * | superfun1 quit (Quit: leaving) |
| 18:36:24 | * | brson quit (Ping timeout: 264 seconds) |
| 18:45:34 | Araq | Demos: so that my.foo is picked over imported.foo |
| 18:47:01 | * | superfunc_ joined #nimrod |
| 18:47:44 | Demos | ah, that is reasonable. thanks |
| 18:49:27 | * | Le-janwar joined #nimrod |
| 18:49:41 | * | Jehan_ joined #nimrod |
| 18:49:50 | * | Le-janwar left #nimrod ("WeeChat 0.4.3") |
| 18:51:40 | Jehan_ | Araq: I've written some combinatorial functions (enumerate permutations, combinations, and choices of an array/seq). Would you like them in the standard library and if so, in algorithms.nim or a separate module? |
| 18:52:34 | * | KevinKelley quit (Ping timeout: 246 seconds) |
| 18:54:01 | Araq | Jehan_: dunno, sequtils? |
| 18:54:51 | Jehan_ | Araq: They take openarrays, not just seqs. |
| 18:54:56 | Jehan_ | So not sure about that. |
| 18:55:38 | Jehan_ | Plus, does not seem to fit what the top comment of sequtils.nim says. |
| 18:56:33 | Jehan_ | I don't really care either way, just need to know (1) if you want it for the standard library and (2) where it should go. |
| 18:56:49 | Araq | meh, create a new module |
| 18:57:02 | Araq | combinatorics.nim or something like that |
| 18:57:05 | Jehan_ | Alrighty, will do. |
| 18:57:58 | Araq | comntrcs.nim if you like the old naming scheme, nah, just kiddin |
| 18:58:31 | Araq | and somebody should rename dstinct to unique |
| 18:58:39 | Jehan_ | Lol! |
| 19:00:26 | Araq | so ... should we name the new version 0.9.4.2 or 0.9.6 ? |
| 19:00:36 | superfunc_ | lol |
| 19:00:51 | Araq | it'll be mostly a bugfix release |
| 19:01:17 | superfunc_ | probably 0.9.4.x if its just bug fixes |
| 19:01:26 | * | brson joined #nimrod |
| 19:02:13 | Araq | well I don't know ... we did half of the stuff that our roadmap lists |
| 19:02:16 | Jehan_ | Dunno, are there any package managers who will have an existential crisis if there are more than three numbers in a version? |
| 19:02:43 | superfunc_ | Why not 0.9.5? |
| 19:02:47 | flaviu | Haskell does 4 numbers |
| 19:02:49 | Araq | personally I think if you need more than three numbers you're doing it wrong |
| 19:03:12 | Araq | superfunc_: odd numbers are development versions |
| 19:03:23 | Jehan_ | Well, the roadmap stuff may have to get renumbered. |
| 19:03:25 | superfunc_ | Araq: Oh, thanks |
| 19:03:25 | * | goobles quit (Ping timeout: 246 seconds) |
| 19:03:29 | flaviu | And their rationale is pretty good, "people don't want to increment the major number except for major major changes" |
| 19:03:45 | * | Jehan_ has a sudden flashback to the days of BASIC and line renumbering commands. |
| 19:04:09 | Araq | so our 0 is meaningless? well indeed |
| 19:04:17 | superfunc_ | As long as we don't do the rust numbering scheme that confused a bunch of people at first |
| 19:04:40 | Araq | how does Rust do it? |
| 19:04:47 | superfunc_ | 0.9 went to 0.10 |
| 19:05:11 | superfunc_ | most people dont read the dot as a proper separator |
| 19:05:24 | Araq | that's a perfectly fine version number |
| 19:05:33 | Araq | but yeah it's kind of misleading |
| 19:05:50 | Araq | on the other hand we only have 0.9.6, 0.9.8, 1.0.0 left |
| 19:05:50 | superfunc_ | yeah |
| 19:06:47 | superfunc_ | that's true. |
| 19:07:06 | Araq | oh well I'll try to reduce sleep further and implement everything for 0.9.6 |
| 19:09:32 | * | superfunc_ quit (Quit: leaving) |
| 19:09:45 | * | superfunc quit (Quit: leaving) |
| 19:11:52 | * | 1JTAAQ2HF quit (Remote host closed the connection) |
| 19:11:54 | flaviu | Araq: would you be opposed to `module ...:` statements? |
| 19:12:56 | blamestross | what is the standard method of unit tests? |
| 19:13:21 | flaviu | blamestross: `when isMainModule:\n import unittest\n...` |
| 19:13:37 | Araq | blamestross: or simply system.doAssert |
| 19:13:55 | Araq | usually people start with import unittest and then see the light |
| 19:14:18 | Araq | flaviu: yes. the lack of a 'module foo' declarative element is a *feature* |
| 19:14:31 | Demos | Araq, how about scoped imports? |
| 19:14:33 | flaviu | Araq: Does `doAssert` have pretty colors and scoping? I thought not :P |
| 19:15:02 | Demos | flaviu, well it has scopeing from block, more importantly the lack of scope stuff means the scope stuff is not broken |
| 19:15:12 | Araq | flaviu: doAssert **works** though |
| 19:15:26 | EXetoC | flaviu: no, but the unittest module has some bugs |
| 19:16:09 | EXetoC | such as lack of stack trace info for raised exceptions |
| 19:16:12 | flaviu | Demos: I'm aware about block, but `block` doesn't give you colors. I prefer unittest's blocking |
| 19:16:16 | * | q66_ joined #nimrod |
| 19:16:23 | flaviu | EXetoC: The last exception gives a trace |
| 19:16:51 | Demos | yeha I use unittest as well, I try not to use isMainModule though, I like to be able to run multiple module's tests at once |
| 19:17:19 | flaviu | Demos: So your unit tests run during program initialization? |
| 19:17:48 | Demos | what? I mean I have them in a "when" block, but I use my own unit-test define |
| 19:18:13 | Araq | Demos: scoped imports won't be done before 1.0 is out. I can see the value in them but then I don't really like them either |
| 19:18:29 | flaviu | Oh, ok. I haven't really gotten to the point where that'd be useful, but it seems like a good idea for later |
| 19:18:35 | * | q66 quit (Ping timeout: 252 seconds) |
| 19:18:45 | flaviu | @Demos |
| 19:18:53 | EXetoC | flaviu: only the last trace was included the last time I checked |
| 19:19:08 | flaviu | Yeah, thats how it works |
| 19:19:25 | Demos | I was poking around the compiler trying to get them working. Getting the import working is easy, removing the symbols after the scope is over is not |
| 19:19:47 | Demos | I really like the idea of tools using scoped imports to figure out modules for you though |
| 19:19:55 | EXetoC | the last call site that is. it makes it hard to track down |
| 19:22:08 | EXetoC | I mean the first |
| 19:27:40 | Jehan_ | Araq: Speaking of doAssert: Should tests in the tests/ directory use assert or doAssert? assert seems to be more prominent, but doAssert is also used fairly widely. |
| 19:28:22 | Araq | doAssert should be used |
| 19:28:47 | Araq | assert predates doAssert so it's used in the older tests |
| 19:29:16 | * | brson quit (Ping timeout: 240 seconds) |
| 19:32:14 | * | q66_ is now known as q66 |
| 19:32:24 | * | brson joined #nimrod |
| 19:39:50 | * | dLog_ joined #nimrod |
| 19:40:13 | Jehan_ | Hmm, I think I found a compiler bug. Interesting. |
| 19:40:16 | * | Boscop_ joined #nimrod |
| 19:40:46 | Araq | let me guess: nested lambdas? |
| 19:41:05 | Jehan_ | No, no lambdas in play anywhere. Iterators, though. |
| 19:41:22 | Araq | closure iterators? |
| 19:41:35 | Jehan_ | No. |
| 19:41:53 | Jehan_ | Basically, a result_xxxxx variable got declared twice in the generated C code. |
| 19:42:10 | Jehan_ | I may have an idea. |
| 19:42:45 | Jehan_ | Ah, I think I know what triggers it. |
| 19:43:13 | * | eigenlicht quit (Ping timeout: 240 seconds) |
| 19:43:13 | * | dom96 quit (Ping timeout: 240 seconds) |
| 19:43:14 | * | Boscop quit (Read error: Connection reset by peer) |
| 19:43:15 | * | dLog quit (Ping timeout: 240 seconds) |
| 19:43:15 | * | jez0990 quit (Ping timeout: 240 seconds) |
| 19:43:16 | * | jez0990_ joined #nimrod |
| 19:43:17 | Jehan_ | The iterator has a case statement at the outer level to optimize special cases. |
| 19:43:33 | * | eigenlicht_ joined #nimrod |
| 19:43:39 | Jehan_ | That's what makes the compiler barf. |
| 19:44:24 | * | dom96 joined #nimrod |
| 19:47:45 | * | pafmaf quit (Quit: Verlassend) |
| 19:48:00 | Araq | yay I finally found the nkYield bug in the codegen |
| 19:48:14 | Araq | where a yield statement has not been eliminated |
| 19:50:29 | Jehan_ | Congratulations! |
| 19:51:24 | * | io2 joined #nimrod |
| 19:55:18 | foodoo | cheers! |
| 19:58:01 | Demos | yay! |
| 20:08:43 | * | Nimrod quit (Ping timeout: 240 seconds) |
| 20:17:47 | * | brson quit (Quit: leaving) |
| 20:19:41 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 20:27:23 | Jehan_ | Hmm, about the distnct -> unique rename. The identifier `unique` is used in quite a few places, and I'm not sure if it's a good name for the function (Ruby et al. use `uniq` in reference to the UNIX tool), and it isn't a verb that describes what the function does. Would something like `deduplicate` be better? |
| 20:28:08 | * | Daedalus_ joined #nimrod |
| 20:28:23 | flaviu | Since I love to bikeshed, I think that deduplicate is too weird |
| 20:28:57 | Demos | I think distinct is just fine |
| 20:29:46 | * | kunev joined #nimrod |
| 20:29:50 | blamestross | Is there a general vector-space math library? I'm half way though writing one for research use, figured I might throw that out there. |
| 20:30:45 | flaviu | blamestross: IIRC a couple people are working on one |
| 20:31:23 | Demos | BitPuffin is working on one and I have one |
| 20:31:34 | Araq | h Daedalus_ welcome |
| 20:31:44 | Demos | https://github.com/barcharcraz/Systemic/blob/master/vecmath.nim |
| 20:31:45 | flaviu | filwit is also making a game engine or something, so I think he has part of one |
| 20:31:58 | Araq | I like deduplicate |
| 20:32:02 | Demos | only really works for 3 and 4d, and it is a little wierd to work around compiler errors |
| 20:32:16 | blamestross | Demos: flaviu: I've implemented it a dozen times and have it down to a science. Mine shoudl work for any number of dimensions. |
| 20:32:29 | blamestross | only cross product is funky for higher dimensions |
| 20:32:45 | Demos | blamestross, right, do note that static[T] is broken |
| 20:32:55 | flaviu | Araq: Ok, now I think that deduplicate is awesome and unique is terrible. Don't use unique :P |
| 20:32:55 | Demos | so you will have to do dimensions at runtime, which is no fun |
| 20:33:26 | Jehan_ | flaviu: :) |
| 20:33:54 | Jehan_ | Incidentally, flaviu, I had a look over the logs today and looked at your issue. |
| 20:34:06 | Jehan_ | I'm wondering why you aren't doing the following: |
| 20:34:19 | Jehan_ | type Foo = ref object ... |
| 20:34:30 | Jehan_ | var x = Foo(x: 1, y:2) |
| 20:34:31 | Araq | blamestross: most people here only want 3x3 or 4x4 matrix stuff though; games don't use much else |
| 20:34:53 | flaviu | Jehan_: On the `new` thing? |
| 20:35:18 | Jehan_ | flaviu: Yeah. |
| 20:35:32 | flaviu | Because I might sometimes want to stack allocate my object, and that isn't possible without type prefixes |
| 20:35:47 | Jehan_ | Umm, in this case I prefer to have Foo and FooObj |
| 20:35:58 | flaviu | Araq: BTW, I came up with a better name than `new` for my concept, inspired by rust: `box` |
| 20:36:21 | Jehan_ | No need to use type prefixes, just have two different names for ref object and object. |
| 20:36:21 | Demos | Araq, I really like Eigen's generalized submatrix access stuff though |
| 20:36:36 | Demos | or just use ref Thing |
| 20:36:40 | Araq | flaviu: I think I named it this way in my forum answer too |
| 20:37:18 | flaviu | Jehan_: I don't really like that either. I prefer to use `ref Foo`, but the proposed syntax `(ref Foo)(x:1, y:2)` isn't really that nice looking IMO |
| 20:37:35 | blamestross | aha, we are talking about different types of vectors. |
| 20:37:48 | blamestross | I hate how overloaded that term is |
| 20:38:41 | Jehan_ | flaviu: Hmm. I don't mind the `box` version, since that would also work for ints and floats. |
| 20:39:09 | Jehan_ | At least I assume it would. :) |
| 20:39:44 | flaviu | It'd be defined as `proc box[T]*(obj: T): ref T`, so I hope it does |
| 20:39:46 | * | shodan45 joined #nimrod |
| 20:39:53 | Jehan_ | Yes, it would. |
| 20:40:40 | * | Mat3 joined #nimrod |
| 20:40:54 | Mat3 | Hello |
| 20:42:15 | * | Daedalus_ quit (Quit: Page closed) |
| 20:42:34 | flaviu | Araq: Should I close my `hash(enum)` PR? |
| 20:42:43 | blamestross | https://github.com/blamestross/nimrod-vectors/blob/master/vectors.nim |
| 20:44:57 | * | BitPuffin joined #nimrod |
| 20:45:07 | Demos | yeah, I was trying to have the dimension be part of the type |
| 20:46:06 | Araq | flaviu: yeah |
| 20:46:48 | blamestross | that is not a bad idea, |
| 20:46:51 | EXetoC | flaviu: that syntax does work |
| 20:47:11 | EXetoC | perhaps only with #!strongSpaces though |
| 20:47:16 | blamestross | Demos: i've been using python too long, using the type that way did not occur to me. |
| 20:47:19 | flaviu | EXetoC: What are you referring to? |
| 20:47:25 | EXetoC | (ref T) |
| 20:47:35 | flaviu | Its planned syntax |
| 20:47:42 | Mat3 | does the Nimrod sources require some special library dependencies ? |
| 20:47:43 | Demos | blamestross, yeah. but using the type that way does not work |
| 20:47:48 | EXetoC | flaviu: and it works in some cases |
| 20:48:08 | Demos | Mat3, nope. I think the tests like to have sqlite and nimgrep needs PCRE |
| 20:48:12 | Varriount | Mat3: The compiler doesn't. Some of the modules in the standard library do. |
| 20:50:00 | * | BitPuffin quit (Ping timeout: 260 seconds) |
| 20:50:11 | Mat3 | OK, I try to compile Nimrod on my Android tablet |
| 20:56:28 | Mat3 | (it is an experiment) |
| 20:57:54 | * | foodoo quit (Remote host closed the connection) |
| 20:58:35 | blamestross | Demos: It looks like the best you can do unless you feel like implementing each dimension manually is the asserts that I do |
| 20:59:14 | Demos | ideally you would have type Vector[N: static[int], T] = ... and overload on it |
| 20:59:26 | Demos | but overload resolution with static[T]s does not work vert well |
| 21:02:39 | blamestross | this is my first time looking at nimrod's generic system, would Vector[N: static[int]] work differently? |
| 21:02:48 | blamestross | or is that nonsense? |
| 21:07:29 | Mat3 | Ciao |
| 21:08:26 | Araq | blamestross: well you also need a T |
| 21:08:50 | blamestross | I'm trying to find documentation of nimrod's meta-typing and failing |
| 21:09:14 | blamestross | is there a pile of documents not on http://nimrod-lang.org/? |
| 21:11:52 | * | betawaffle quit (Ping timeout: 264 seconds) |
| 21:11:52 | * | Mat3 quit (Ping timeout: 246 seconds) |
| 21:11:57 | * | Demos quit (Ping timeout: 264 seconds) |
| 21:12:10 | * | Demos joined #nimrod |
| 21:13:48 | * | _dLog joined #nimrod |
| 21:14:59 | Araq | blamestross: the tutorial and the manual cover generics |
| 21:17:41 | * | dLog_ quit (Ping timeout: 264 seconds) |
| 21:22:13 | * | Demos_ joined #nimrod |
| 21:24:14 | Varriount | So, has anything important happened recently? |
| 21:24:49 | * | clone1018_ joined #nimrod |
| 21:25:13 | flaviu | You're supposed to do some fancy stuff with throwing away numbers to limit random numbers to a range |
| 21:25:17 | * | shodan45_ joined #nimrod |
| 21:25:28 | flaviu | But in my testing, just using modulus seems to be equally good |
| 21:25:49 | * | shodan45_ quit (Client Quit) |
| 21:25:55 | flaviu | 3340063032 3339977810 3339959158 - distribution of fancy scheme |
| 21:25:55 | flaviu | 3340062802 3339966256 3339970942 - distribution of modulus |
| 21:28:01 | * | xenagi joined #nimrod |
| 21:30:08 | Araq | Varriount: yes, I rewrote lambda-lifting |
| 21:30:22 | Araq | should fix lots of reported bugs |
| 21:30:25 | Varriount | *gasp* |
| 21:30:52 | Varriount | Araq: Truly, you are the bravest of us all... to face such a fearsome beast. |
| 21:31:12 | Araq | and it's about to compile jester+async which turned out to be a clusterfuck for the compiler |
| 21:31:43 | * | Demos quit (*.net *.split) |
| 21:31:43 | * | shodan45 quit (*.net *.split) |
| 21:31:43 | * | dom96 quit (*.net *.split) |
| 21:31:45 | * | TylerE quit (*.net *.split) |
| 21:31:45 | * | clone1018 quit (*.net *.split) |
| 21:33:50 | Varriount | Araq: 'it's about'? |
| 21:34:09 | * | joelmo joined #nimrod |
| 21:34:14 | Araq | Varriount: well LL is *the* hardest part in the whole compiler and the hardest transformation I've ever done |
| 21:35:04 | Varriount | Araq: I mean, I don't understand what you mean by that phrase. Do you mean it hasn't been tested yet? Or something else? |
| 21:35:26 | flaviu | Varriount: Mostly works, but there are a few edge cases |
| 21:35:29 | Araq | I'm working on making it compile dom96's new async jester |
| 21:35:43 | Araq | it works with everything else already afaict |
| 21:37:41 | Jehan_ | Araq: If you think that lambda lifting is annoying, try Eiffel's renames. :) |
| 21:38:01 | Varriount | What are Eiffel's renames? |
| 21:38:10 | Araq | they can't be as bad as LL |
| 21:38:16 | Jehan_ | It's a feature that appears to be suspiciously simple to implement, but actually spreads its tentacles all over the compiler if you aren't careful. |
| 21:38:35 | Araq | LL looks complex at first sight |
| 21:38:36 | Jehan_ | Varriount: Basically allows you to arbitrarily rename functions and variables during inheritance. |
| 21:38:37 | Araq | then simple |
| 21:38:53 | Araq | and then so complex that you're never sure you got all the edge cases |
| 21:39:24 | Araq | and indeed |
| 21:39:30 | Araq | you never get them all ... |
| 21:39:45 | Jehan_ | Araq: I guess you are talking about nested closures in particular? :) |
| 21:39:47 | flaviu | It seems you need a much bigger range to get significant biases |
| 21:39:54 | * | dom96 joined #nimrod |
| 21:40:17 | Araq | Jehan_: nimrod's LL also has to transform closure iterators in addition to the traditional unnesting |
| 21:40:31 | Jehan_ | Araq: Oh right. Fun! |
| 21:40:58 | Araq | jester for instance produces the chain proc->iter->proc->iter ... |
| 21:41:22 | Araq | where the innermost iter captures something from the outermost proc |
| 21:42:27 | flaviu | It seems that the bias when choosing from 100000 elements is maybe ~~ 1.5% towards the front |
| 21:43:53 | Araq | Jehan_: also the question is how the semantics of the language are designed, whether you respect scopes or not |
| 21:44:02 | Jehan_ | Araq: True. |
| 21:44:03 | * | tinAndi joined #nimrod |
| 21:44:11 | Araq | if you respect scopes (and we do) this means you have 2 different links |
| 21:44:27 | Araq | links across scopes and then links across proc boundaries |
| 21:45:17 | Araq | so 2 link types and 2 transformations that interact ... no wonder it took me 3 weeks ... |
| 21:47:13 | Jehan_ | Heh. |
| 21:48:20 | * | kunev quit (Quit: leaving) |
| 21:49:27 | flaviu | Araq: Are you open MurmerHash3 in the stdlib? |
| 21:50:05 | Araq | flaviu: dunno, I guess it makes some sense to have that in the stdlib and not in babel |
| 21:50:25 | Araq | to encourage people to use this and no other implementation |
| 21:50:34 | Araq | that's what you have in mind, right? |
| 21:51:02 | flaviu | Well, so far the murmerhash implementation I've found is a wrapper around C |
| 21:52:52 | flaviu | And murmerhash3 is pretty much the best hash implementation there is, I don't think there are any faster and better (and I've looked) |
| 21:54:54 | flaviu | And if you want to write the implementation, do so, I'm not reserving a monopoly on writing it |
| 21:55:03 | Jehan_ | flaviu: I take it you mean "best general-purpose hash implementation"? |
| 21:55:38 | Varriount | Is this a one way hash? |
| 21:55:56 | flaviu | Jehan_: Yes, there are cryptography strong hashes, which murmerhash isn't |
| 21:56:09 | Araq | do I look like wanting to implement murmerhash myself? |
| 21:56:17 | Jehan_ | I was actually thinking of specialized hash functions that are faster for specific cases. |
| 21:56:28 | flaviu | Varriount: Its not a cryptographic hash, if that's what you're asking |
| 21:56:56 | Varriount | flaviu: Would your hash implementation make the tables module faster? |
| 21:57:30 | Varriount | (Disclaimer: I have only a faint idea about the inner-workings of the tables module) |
| 21:58:01 | flaviu | Varriount: It might decrease collisions somewhat, but it wouldn't significantly decrease the speed even if it didn't |
| 21:58:27 | flaviu | I think that the slightly slower runtime will be made up by the decrease collisions, but no data there |
| 21:58:46 | Jehan_ | flaviu: Also, often you can gain a lot of speed by using CRC to exploit hardware support if you're willing to have slightly more collisions. |
| 21:59:55 | Jehan_ | And finally, hash table performance is not necessarily best with a function that minimizes collisions. |
| 22:00:40 | flaviu | Jehan_: Murmerhash is competitive in speed with hardware CRC |
| 22:00:41 | Jehan_ | Python intentionally uses a fairly simple string hash that has clustered values, for example. |
| 22:01:22 | flaviu | wait, let me look again |
| 22:03:36 | flaviu | does anyone here have an i7 by any chance? |
| 22:03:42 | Varriount | I do. |
| 22:04:00 | Varriount | Although it's one of the early models. |
| 22:04:03 | Jehan_ | flaviu: That would surprise me. |
| 22:04:29 | flaviu | Its measured in clock cycles on the page, but I thought it was nanoseconds |
| 22:05:05 | Jehan_ | I mean, nothing is impossible, but the SSE CRC32 instruction pretty much computes the result as fast as it can read memory. |
| 22:05:16 | flaviu | Jehan_: You're right |
| 22:05:41 | flaviu | But if I can get a benchmark together, and Varriount is willing to run it, we can see exactly how much slower it is |
| 22:05:49 | Araq | flaviu: I have an i7 :P |
| 22:05:55 | Varriount | I'm willing. |
| 22:06:03 | * | Varriount ** SysInfo ** Client: HexChat 2.10.0 (x64) ** OS: Microsoft Windows 8.1 Pro ** CPU: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (2.00 GHz) ** RAM: 8183 MB Total (3718 MB Free) ** VGA: NVIDIA GeForce GTX 460 ** Uptime: 74.91 Hours ** |
| 22:06:07 | Jehan_ | flaviu: I think it's more important to have a hash implementation with predictable performance everywhere. |
| 22:06:13 | Jehan_ | Premature optimization and all that. :) |
| 22:06:31 | Jehan_ | People who worry THAT much about performance can tweak it still. |
| 22:06:41 | flaviu | Varriount: I actually have to write the benchmark :P |
| 22:06:55 | Jehan_ | The point I was trying to make is that it can make sense to situationally choose something different. |
| 22:08:17 | Jehan_ | Also, to situationally choose a cryptographically strong hash to avoid DOS attacks. |
| 22:08:51 | flaviu | Jehan_: Or use a real database, as it becomes their problem then |
| 22:09:10 | Jehan_ | I am thinking about stuff like putting HTTP headers in a dictionary. |
| 22:09:22 | Jehan_ | Database won't help you there. |
| 22:10:26 | Jehan_ | Attacker constructs a huge HTTP request with headers that all hash to the same value => quadratic performance. |
| 22:11:42 | * | Trixar_za makes a note never to show Jehan_ his code |
| 22:12:07 | Jehan_ | Huh? :) |
| 22:12:17 | Trixar_za | My blatant lack of regard for security will give you nightmares |
| 22:14:10 | Jehan_ | Trixar_za: Nah. :) Plus, unless it's publicly available on the net, who cares? |
| 22:14:30 | Trixar_za | Lol - a few are |
| 22:15:34 | Jehan_ | Trixar_za: In practice, you'll probably be using established frameworks that are hardened against such attacks. |
| 22:15:55 | Trixar_za | I have a bad habit of writing my own |
| 22:16:25 | Jehan_ | Even then, DOS attacks really only matter for major sites. |
| 22:16:53 | * | BitPuffin joined #nimrod |
| 22:16:54 | Jehan_ | Plus, there are plenty of DDOS attacks that work even against the safest sites. |
| 22:19:53 | * | superfunc_ joined #nimrod |
| 22:24:36 | NimBot | Araq/Nimrod devel b405462 Clay Sweetser [+0 ±1 -0]: Add 'lib/pure/concurrency' path to nimrod.ini... 2 more lines |
| 22:24:36 | NimBot | Araq/Nimrod devel 43e717b Varriount [+0 ±1 -0]: Merge pull request #1317 from Varriount/fix-1303... 2 more lines |
| 22:30:57 | * | askatasuna joined #nimrod |
| 22:33:02 | * | tinAndi quit (Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]) |
| 22:38:31 | * | brson joined #nimrod |
| 22:41:15 | * | hoverbea_ quit (Ping timeout: 255 seconds) |
| 22:46:26 | * | boydgreenfield joined #nimrod |
| 22:46:28 | boydgreenfield | Is there a hex format option for printing / interpolation in Nimrod? (Can’t seem to find it in the manual) |
| 22:46:47 | def- | boydgreenfield: there's a toHex proc |
| 22:46:48 | boydgreenfield | Oops. |
| 22:46:50 | boydgreenfield | Nvm. |
| 22:47:27 | boydgreenfield | def-: Found it. Thx. Thought I’d done a seach that returned 0 results, but it was just Chrome being out of focus. |
| 22:47:32 | flaviu | boydgreenfield: If you want an awesome library, look here: https://bitbucket.org/lyro/strfmt/src |
| 22:48:29 | boydgreenfield | flaviu: Ah. That is awesome (on quick glance). Is this on the integration roadmap for v1, or always planned as a separate library? |
| 22:49:17 | flaviu | I dunno, you can ping Araq if you want |
| 22:54:05 | flaviu | I think that would be good, but saying that makes it a bit less likely :z |
| 22:58:41 | Araq | flaviu: no. in fact, I have a very high opinion of you. |
| 22:58:52 | Araq | but I won't admit it again :P |
| 22:59:38 | Araq | boydgreenfield: not on the roadmap for version 1 |
| 23:00:24 | boydgreenfield | Araq: Just curious. Looks like a great resource either way. And excited for v1 either way! :) |
| 23:03:56 | NimBot | Araq/Nimrod new_spawn 59f61ba Araq [+1 ±2 -0]: new jester compiles |
| 23:03:59 | * | darkf joined #nimrod |
| 23:04:24 | Araq | dom96: it works now, I hope |
| 23:04:29 | flaviu | Araq: Thanks, I'll try not to remind you too often :P |
| 23:04:37 | dom96 | Araq: thx |
| 23:04:45 | Araq | dom96: don't make me ever do this again |
| 23:05:22 | Araq | interesting how production code always stresses the compiler more than any test case I can envision |
| 23:05:31 | flaviu | Varriount: Well, I managed to get something to work, but I can't actually test if it compiles since I don't has msvc or whatever microsoft has |
| 23:05:32 | flaviu | http://www.mediafire.com/download/6hudj5g94u40u1a/out.zip |
| 23:05:54 | flaviu | The error messages seemed to be about what I'd expect though, so it should mostly work |
| 23:07:00 | Araq | dom96: watch out, we got a tjester test |
| 23:07:16 | dom96 | Araq: cool |
| 23:07:36 | dom96 | I wonder how many of those tests now relate to my projects :P |
| 23:07:41 | Araq | I extracted what your template fu produces |
| 23:11:42 | Jehan_ | dom96: Is babel doing any file locking in case you run two instances at the same time? |
| 23:11:53 | dom96 | Jehan_: not yet |
| 23:12:16 | Jehan_ | dom96: Noted. Not that I think that it's likely to happen, just curious. |
| 23:13:00 | Araq | hmm I feel like celebrating |
| 23:13:19 | * | Araq wonders if he has any beer left |
| 23:16:04 | * | io2 quit (Ping timeout: 260 seconds) |
| 23:23:17 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 23:27:45 | Demos_ | hit that ballmer peak! |
| 23:28:41 | Araq | well I have no beer here, only caipirinha ... |
| 23:28:50 | Araq | and my caipirinhas suck ... |
| 23:29:21 | Araq | i never get the composition right |
| 23:31:55 | * | untitaker quit (Quit: ZNC - http://znc.in) |
| 23:36:32 | * | untitaker joined #nimrod |
| 23:39:55 | Araq | now who want to hunt these VM bugs with me? |
| 23:41:47 | flaviu | Do there exist many 32 bit machines? |
| 23:43:27 | Jehan_ | Araq: I'm a bit scared of the VM. :) |
| 23:43:36 | Araq | flaviu: ARM is still 32bit mostly. yes. |
| 23:43:39 | Jehan_ | flaviu: Most current ARM machines? |
| 23:43:46 | Araq | lol |
| 23:43:54 | Jehan_ | Great minds and all that. :) |
| 23:44:10 | Jehan_ | And you'd be surprised how many Linux distributions are still 32-bit, apparently. |
| 23:44:16 | flaviu | Ok, I'm just thinking whether its a good idea to also implement the 32bit version of murmerhash |
| 23:44:28 | Jehan_ | It is most definitely a good idea. |
| 23:48:42 | * | saml_ joined #nimrod |
| 23:50:30 | Araq | Jehan_: the VM has only 1 hard part in it that continues to bite us |
| 23:50:42 | Araq | which is the data representation |
| 23:51:00 | Jehan_ | Okay, maybe I will look into it next week. |
| 23:51:13 | Jehan_ | In my ample spare time. :) |
| 23:51:45 | Araq | well I'm still flirting with the idea to get rid of it entirely and compile macros to their own executables |
| 23:52:01 | Araq | with some caching that should be even faster |
| 23:52:11 | Araq | and we get the FFI at compile-time for free |
| 23:52:55 | Jehan_ | Araq: Interesting, that's an idea that I had played around with myself. |
| 23:52:59 | Jehan_ | Also for a REPL. |
| 23:53:16 | Jehan_ | And for pretty much the same reasons (i.e, FFI). |
| 23:53:53 | Jehan_ | The concept I had been playing with was to abstract metaprogramming into meta-modules, though. |
| 23:54:26 | Jehan_ | Makes for a relatively clean multi-phase compilation process. |
| 23:55:22 | Varriount | Araq: How would programming macros to their own modules work for macros that want to share state? |
| 23:55:32 | Varriount | *compiling macros |
| 23:56:03 | Araq | state sharing has lots of problems when it comes to modularity |
| 23:56:43 | dom96 | Araq: perhaps you could combine both? VM when FFI is not used and compile the macros to an exe when FFI is used. |
| 23:57:01 | flaviu | dom96: The whole point is to avoid complexity |
| 23:57:05 | flaviu | That would just double it |
| 23:57:28 | Araq | and yet that's exactly what we would end up doing |
| 23:57:40 | Araq | to allow for a smooth transition |
| 23:57:56 | Araq | as these new macros can't do everything the current macros can do |
| 23:57:59 | dom96 | Compiling the macros will likely be slow. |
| 23:58:11 | Araq | dom96: it'll be cached |
| 23:58:52 | flaviu | Lets just use nodejs. We can be webscale, and have good compilation times |
| 23:59:11 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 23:59:15 | dom96 | Araq: Well I don't know how much you can cache. |
| 23:59:17 | Varriount | flaviu: That's a low blow. We should just use PHP |
| 23:59:25 | Araq | the JS backend supports Lua for a reason :P |
| 23:59:36 | Araq | I wanted to use LuaJIT for it |