| 00:00:01 | Araq | but as I said, I was fed up with string munging |
| 00:00:24 | Araq | and hey, how hard can it be to write a register based VM from scratch? ;-) |
| 00:01:22 | Varriount | Araq: Your just saying this because the VM you built in less than a year isn't perfect. |
| 00:01:47 | Varriount | *You're |
| 00:01:53 | Araq | dom96: we can cache both the .exe generation and the AST->.exe->AST step |
| 00:03:47 | dom96 | Araq: It's an interesting idea. Does any other compiler handle CTFE this way? |
| 00:03:56 | Araq | no. |
| 00:04:23 | dom96 | Any ideas why? |
| 00:04:59 | Araq | it requires other stuff that others never came up with |
| 00:05:00 | Jehan_ | dom96: Mostly because CTFE is a fairly new idea and has previously been explored primarily on JIT systems. |
| 00:05:27 | Araq | it also requires a different compiler infrastructure |
| 00:05:48 | flaviu | Isn't there some possibility to make a dependency graph and merge things that don't depend on each other into the same executable? |
| 00:05:49 | Jehan_ | Araq: Not really all that different. |
| 00:06:11 | Jehan_ | As I said, I had toyed with the idea of simply encapsulating meta-stuff in its own modules. |
| 00:06:45 | Varriount | CTFE =Compile Time Function Evaluation? |
| 00:06:56 | Jehan_ | At that point, they're basically compiler libraries that are either dynamically loaded (or you compile a new compiler where that's not possible). |
| 00:07:16 | Jehan_ | Which is not horribly different from a compiler with plugins. |
| 00:07:55 | Jehan_ | Varriount: yeah. |
| 00:08:40 | Varriount | Is this how Rust does macros? |
| 00:08:48 | Araq | Jehan_: depending on how you do it the AST->.exe->AST caching requires a whole new infrastructure |
| 00:09:24 | Araq | if you don't do this, it's easier |
| 00:09:40 | Jehan_ | Araq: What I'm talking about doesn't have to do most of it. |
| 00:11:05 | Jehan_ | When you import a metamodule, you compile and link it against the compiler. Caching = check dependencies and only compile/link if the metamodule or its dependencies have changed. |
| 00:11:30 | Araq | yeah |
| 00:12:03 | Jehan_ | Nimrod has a harder time because macros etc. aren't separated into their own modules. |
| 00:12:44 | Araq | not that much harder really |
| 00:13:07 | Araq | I abandoned the DLL generation idea because shared objects suck on Unix |
| 00:13:46 | Araq | all sorts of path issues and good luck debugging these |
| 00:14:34 | Jehan_ | dlopen() with an absolute path shouldn't be a problem? |
| 00:14:37 | Araq | Varriount: I think Rust does it via DLLs, yes |
| 00:14:51 | Jehan_ | Which is all you need when you're doing it from the compiler? |
| 00:15:19 | Araq | Jehan_: I don't remember the problems tbh |
| 00:15:53 | flaviu | If rust emits LLVM IR, shouldn't it just use the LLVM virtual machine? |
| 00:15:58 | Jehan_ | Araq: *nod* Not that I'm surprised that there are problems, and dlopen() has plenty of architecture-specific corner cases, too. |
| 00:16:30 | Jehan_ | flaviu: In principle, LLVM also has a JIT option. |
| 00:16:40 | Jehan_ | Though that can be dog slow for large amounts of code. |
| 00:20:05 | flaviu | Is there a way to get passthrough on case statements? |
| 00:21:45 | Jehan_ | flaviu: Use a template (immediate if necessary) for common code. |
| 00:22:24 | flaviu | I'm not really sure how that applies here. I want to do a C-style switch |
| 00:23:39 | Jehan_ | flaviu: Yes. Put the code for the fall-through case in a template, then use the template both at the end of the previous case and for the fall-through case. |
| 00:24:06 | Jehan_ | The template can be local to the function. |
| 00:24:19 | flaviu | https://code.google.com/p/smhasher/source/browse/trunk/MurmurHash3.cpp#296 |
| 00:24:29 | * | joelmo quit (Quit: Connection closed for inactivity) |
| 00:24:31 | flaviu | not really going to work here |
| 00:24:38 | NimBot | Araq/Nimrod devel 33eeb66 enurlyx [+0 ±1 -0]: Add support for structs/unions defined in structs/unions |
| 00:24:38 | NimBot | Araq/Nimrod devel 3648680 enurlyx [+1 ±0 -0]: Added test for anonymous structs and unions |
| 00:24:38 | NimBot | Araq/Nimrod devel 788cfb3 enurlyx [+0 ±1 -0]: Removed time and added a hash based on filename, line and column for creating a unique struct id |
| 00:24:38 | NimBot | Araq/Nimrod devel bd3f6b5 enurlyx [+1 ±1 -0]: Sorting enumerations and generation of consts for enumfields with the same value + test |
| 00:24:38 | NimBot | 2 more commits. |
| 00:25:08 | Jehan_ | Ah, I see. |
| 00:25:55 | Jehan_ | Okay, Duff's Device is a special case (no pun intended). |
| 00:26:57 | flaviu | Its also a special case, so it can't be rolled easaly |
| 00:28:22 | Jehan_ | Technically, compilers can still combine common code if you replicate it in each branch, but you may be hitting a threshold here where they give up. |
| 00:30:13 | Araq | you can easily use a for loop though |
| 00:31:13 | dom96 | I can't set the result of 'bindSym' to a variable? |
| 00:31:21 | dom96 | Is this intentional? |
| 00:31:34 | Araq | yes |
| 00:31:58 | Araq | I've recently explained why |
| 00:33:16 | dom96 | Surely this should work: https://gist.github.com/dom96/e9625a08b913fdd72b09 |
| 00:34:22 | Araq | no |
| 00:34:47 | Araq | oh wait |
| 00:34:58 | Araq | yes |
| 00:35:01 | dom96 | lol |
| 00:48:26 | superfunc_ | we may be passing the balmer peak Araq :p |
| 00:49:09 | Araq | ja du vielleicht |
| 00:49:25 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 00:49:35 | flaviu | "yes you may"? |
| 00:50:16 | Araq | I'm not sure your english translation captures the tone |
| 00:52:47 | dom96 | getAst doesn't seem to be working |
| 00:52:48 | flaviu | "yes, you maybe"? |
| 00:53:16 | dom96 | oh, I need the () |
| 00:54:27 | * | TylerE joined #nimrod |
| 00:55:15 | NimBot | dom96/jester new-async da14102 Dominik Picheta [+0 ±2 -0]: Compiles and runs. Halt/redirect etc don't work. |
| 00:55:15 | NimBot | dom96/jester new-async c76a086 Dominik Picheta [+1 ±2 -0]: Wrote a 'routes' macro. |
| 00:55:15 | NimBot | dom96/jester new-async 9daf899 Dominik Picheta [+0 ±2 -0]: Cleanup. Pass, redirect and cond work. |
| 00:55:31 | Jehan_ | flaviu: Hmm, both clang and gcc seem to be dealing with a template chain fine. |
| 00:55:56 | flaviu | I meant that the code would still be ugly |
| 00:56:30 | dom96 | So, Jester + await pretty much works. |
| 00:59:12 | Jehan_ | flaviu: https://gist.github.com/rbehrends/31a6e7f5fe8d7caa4c42 |
| 00:59:37 | Jehan_ | Not pretty, but not horrible, either. |
| 00:59:47 | Jehan_ | I'm more concerned that the optimizer may still barf on it. |
| 01:00:12 | * | superfunc_ quit (Ping timeout: 245 seconds) |
| 01:02:47 | * | Trustable quit (Remote host closed the connection) |
| 01:09:03 | dom96 | 'night |
| 01:17:18 | * | brson quit (Quit: leaving) |
| 01:37:03 | * | Demos__ joined #nimrod |
| 01:39:56 | * | Demos_ quit (Ping timeout: 240 seconds) |
| 01:49:29 | * | Demos joined #nimrod |
| 01:49:32 | * | Demos quit (Read error: Connection reset by peer) |
| 01:51:16 | * | sdw joined #nimrod |
| 01:58:45 | * | Jehan_ quit (Quit: Leaving) |
| 02:09:39 | * | q66 quit (Quit: Leaving) |
| 02:34:01 | * | johnsoft quit (Ping timeout: 248 seconds) |
| 02:41:36 | blamestross | the lack of math.random for windows hurts |
| 02:44:11 | * | johnsoft joined #nimrod |
| 02:55:13 | def- | Hm, I'm also trying BigInts; mainly interested in performance, which seems to be in the same ballpark as GMP (+ and * so far): https://github.com/def-/bigints |
| 03:15:26 | * | saml_ quit (Quit: Leaving) |
| 03:29:13 | blamestross | def-: I have not even tried to benchmark mine yet |
| 03:29:30 | blamestross | right now I am on r-shift and it is being a pain |
| 03:30:21 | blamestross | https://github.com/blamestross/nimrod-BigInt/blob/master/bigints.nim |
| 03:31:49 | blamestross | looks like we are taking the same seq[uint32] approach |
| 03:33:06 | flaviu | blamestross: I'm curious where shr is causing you trouble. It seems straightforward, but I assume the devil is in the details |
| 03:33:40 | blamestross | mostly me starting to burn out. I'm taking a break to work on other stuff. My issue is that I don't know what the problem is. |
| 03:35:00 | blamestross | shr works for 0-200ish then starts garbageing up above 200. I think I have a divison or off by one error that I am missing |
| 03:35:25 | * | Nimrod joined #nimrod |
| 03:36:05 | flaviu | blamestross: Can you push your latest revision? I'm getting nowhere on what I'm doing too, I'd like to take a look at it |
| 03:36:14 | blamestross | sure |
| 03:36:40 | blamestross | branching off main because this code is having issues |
| 03:38:46 | blamestross | https://github.com/blamestross/nimrod-BigInt/blob/WIP/bigints.nim |
| 03:41:15 | blamestross | just pushed a test that shows the issue |
| 03:42:25 | blamestross | (0x123546 shl 400) shr 396 = 0x0000000000035460 |
| 03:42:59 | blamestross | when I expect 0x1235460 |
| 03:43:44 | blamestross | based on that, it looks like I might have missed a case in the carry |
| 03:44:37 | blamestross | I'm just gonna type out my logic in a Turing TeddyBear fashion |
| 03:45:09 | blamestross | shr takes in a bigint and an integer number of positions to shift. |
| 03:45:36 | * | ARCADIVS joined #nimrod |
| 03:45:58 | blamestross | the chunk size for data stored in the bigint is 32-bits |
| 03:46:33 | blamestross | we can "shift" in multiples of 32 by deleting the lower-order chunks |
| 03:47:02 | blamestross | it divides the given integer by 32 to find out how many chunks it should discard |
| 03:47:55 | blamestross | it then uses a slice to discard those chunks as they are at the "bottom" the the sequence of chunks (As far as I can tell seq is a stack in disguise) |
| 03:48:30 | blamestross | If I managed to delete all the chunks, re-add one with the value of zero |
| 03:48:35 | flaviu | blamestross: Sorry to interrupt your thoughts, but try adding https://gist.github.com/flaviut/5b0bbf74bdc685da2e3c to your gitignore |
| 03:48:49 | flaviu | It should take care of every binary |
| 03:49:01 | blamestross | flaviu: I think I already did but after the files had been added. |
| 03:49:30 | flaviu | yes, but adding each binary is too much hassle |
| 03:50:13 | blamestross | flaviu: done. |
| 03:50:53 | blamestross | now I've taken care of all the multiples of 32, I need to deal with the remainder (literally i mod 32) |
| 03:51:26 | blamestross | I make a new variable called j to hold that value because I hate other programmers. |
| 03:51:43 | blamestross | now the difficult part is the carry |
| 03:52:30 | blamestross | and I think I might have found my issue, but I'll keep going |
| 03:53:42 | * | askatasuna quit (Quit: WeeChat 0.4.3) |
| 03:53:53 | blamestross | for each "digit" of the bigint (woo base 2^32) I need to find the value of that digit shifted, add the value of the carry from the last digit and calculate the carry for the next digit. |
| 03:54:27 | blamestross | and I thinks lines 171 to 175 are all just wrong |
| 03:55:45 | flaviu | Shouldn't you just need 1 carry variable? |
| 03:56:22 | blamestross | yeah, it is zero for the first one and thrown away for the last |
| 03:56:52 | blamestross | I just need to incorperate it before I calculate and over-write it with the new one |
| 04:00:51 | blamestross | what I am currently trying to figure out is this: |
| 04:01:14 | blamestross | when the carry is calculated, it is stored in the bottom bits of the int64 |
| 04:01:48 | * | xenagi quit (Read error: Connection reset by peer) |
| 04:01:49 | blamestross | I need to re-introduce the carry into the next digit at the top-bits of the digit. How much should I shift the carry up |
| 04:01:58 | blamestross | ? |
| 04:03:50 | flaviu | blamestross: The same amount as down |
| 04:04:27 | flaviu | Because then the bottom bits get cut off, but the data is in the initial position again |
| 04:11:23 | blamestross | I just did some git-rettconning |
| 04:11:38 | blamestross | this almost works |
| 04:11:46 | flaviu | Thats alright, I'll send regular patches if needed |
| 04:11:58 | blamestross | the current test indicates an off by one error |
| 04:15:32 | flaviu | err, what I said was completly backwards about shifting |
| 04:15:41 | flaviu | its actually the exact reverse |
| 04:16:46 | blamestross | (32 - i) ??? that was my first intution |
| 04:17:09 | blamestross | well, (32-j) in this code |
| 04:19:54 | blamestross | flaviu: pushed an updated test file to demonstrate current issue |
| 04:21:00 | flaviu | blamestross: I'm actually seeing if I can implement it myself from scratch right now |
| 04:27:50 | blamestross | I think I just fixed this issue |
| 04:27:57 | blamestross | I am testing to check |
| 04:28:25 | blamestross | I was doing an extra shr before adding val to the results list that I forgot about. |
| 04:31:09 | blamestross | flaviu: thanks! |
| 04:31:46 | blamestross | now I can start on division |
| 04:32:04 | flaviu | I'm not aware I actually did anything, but no problem |
| 04:32:27 | flaviu | I think I can get right shift to be extremely elegant, so I'll still work on that |
| 04:33:11 | blamestross | flaviu: surviving the task of being a Turing's TedyBear is worth of thanks. |
| 04:33:16 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 04:34:06 | blamestross | flaviu: My goal is allways to get it working as soon as possible, so I oftern er away from elegant, But I would love pull-requests or patches |
| 04:34:51 | flaviu | I should probably stop wasting time on that, but I can't resist :( |
| 04:35:09 | blamestross | I've lost 2 days to bigint already 0.o |
| 04:35:38 | blamestross | But I like nimrod, and it was certainly a good way to learn. |
| 04:35:56 | Nimrod | I like you too blamestross |
| 04:36:21 | blamestross | have a challenge if you need one! I am dreading writing a base10 string -> bigint interpreter. |
| 04:36:53 | blamestross | any base2^x power is trivial, but base 10 is nasty in dealing with the edges of the 32-bit chunks |
| 04:36:58 | flaviu | Seems easy, if you don't care about performance :P |
| 04:37:10 | flaviu | Let the multiply and add deal with it |
| 04:37:13 | blamestross | flaviu: exactly. but we do. |
| 04:40:24 | blamestross | def-: i stole your testing code and am benchmarking. Either my computer is faster or my code is faster |
| 04:40:31 | blamestross | I'll bet on computer |
| 04:41:26 | blamestross | I don't have GMP to compare against locally |
| 04:43:44 | blamestross | nope, nevermind I was reading the compile time. I started the first (5s on yours) test a minute ago. Still running. Am still idiot |
| 04:44:24 | flaviu | blamestross: Ok, I got it |
| 04:44:40 | flaviu | My shr looks pretty good :) |
| 04:45:04 | flaviu | https://gist.github.com/flaviut/25ca831b43e438ba8bb1 |
| 04:47:32 | blamestross | works |
| 04:47:36 | blamestross | patch accepted |
| 04:48:35 | blamestross | I still need to figure out how it works |
| 04:49:06 | flaviu | First I shift over integers as much as possible, and then I go through each integer. |
| 04:49:19 | blamestross | I know, but I am just learnign nimrod |
| 04:49:39 | blamestross | littleShifts = (i mod 32).uint32 <-- does the mod and converts the result to uint32? |
| 04:50:01 | flaviu | Yes, I'm working around some weird limitations in the library methods |
| 04:51:18 | flaviu | Since the unsigned types require two `(a, b: T)`, I can't shift a uint32 over by a int literal since nimrod doesn't really like unsigned implicit conversions |
| 04:52:32 | blamestross | I like how you get around what I was solving by using 64bit ints |
| 04:54:02 | blamestross | And on thank node I am crashing. division in the morning. |
| 04:54:12 | blamestross | *that note |
| 04:54:44 | flaviu | Same here, I need to go to bed soon |
| 05:14:09 | * | flaviu quit (Ping timeout: 252 seconds) |
| 05:14:58 | * | Demos__ quit (Read error: Connection reset by peer) |
| 05:54:01 | * | xtagon quit (Ping timeout: 248 seconds) |
| 06:45:31 | * | nande quit (Read error: Connection reset by peer) |
| 06:55:36 | * | btiffin quit (Ping timeout: 264 seconds) |
| 07:07:59 | * | btiffin joined #nimrod |
| 08:05:59 | * | Matthias247 joined #nimrod |
| 08:55:19 | * | kunev joined #nimrod |
| 09:00:35 | * | vendethiel joined #nimrod |
| 09:09:47 | * | btiffin quit (Ping timeout: 245 seconds) |
| 09:17:53 | * | Trustable joined #nimrod |
| 09:22:51 | * | btiffin joined #nimrod |
| 09:23:31 | * | io2 joined #nimrod |
| 09:37:08 | dom96 | good morning |
| 09:44:04 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) |
| 09:51:39 | * | joelmo joined #nimrod |
| 10:27:46 | * | q66 joined #nimrod |
| 10:43:24 | Araq | hey dom96 |
| 10:43:38 | Araq | new_spawn ready to be merged into devel? |
| 10:43:39 | dom96 | hi Araq |
| 10:43:49 | dom96 | not yet |
| 10:43:57 | Araq | bah. found a bug? |
| 10:44:17 | dom96 | no, but I haven't tested it well enough |
| 10:44:22 | Araq | ah good |
| 10:53:27 | Araq | brb |
| 11:14:25 | Araq | back |
| 11:16:14 | NimBot | Araq/Nimrod devel 9ea0d0c Dominik Picheta [+0 ±1 -0]: Futures with an error but no callback no longer raise.... 5 more lines |
| 11:17:21 | Araq | dom96: I'm making c2nim a babel package and give it its own repo |
| 11:17:28 | dom96 | Araq: cool |
| 11:18:14 | Araq | but Babel really needs a "generate boilderplate" feature :P |
| 11:18:20 | Araq | *boilerplate |
| 11:18:44 | dom96 | Contributions are always welcome :P |
| 11:20:04 | Araq | hmmm Araq/c2nim or nimrod-code/c2nim ? |
| 11:20:48 | dom96 | Speaking of boilerplate: https://gist.github.com/dom96/8fa50211681be4dca749 |
| 11:21:23 | Araq | *shrug* that's only a macro away |
| 11:21:45 | dom96 | somebody has to write the macro too you know |
| 11:23:18 | dom96 | Araq: nimrod-code |
| 11:25:50 | Araq | fowl will have it once he reads this |
| 11:28:20 | * | BitPuffin joined #nimrod |
| 11:30:20 | Skrylar | ugh |
| 11:30:25 | Skrylar | why does readBytes use signed 8bit ints |
| 11:30:34 | Skrylar | its a byte, not an int |
| 11:30:39 | Araq | legacy |
| 11:30:46 | Araq | use the cstring version |
| 11:30:51 | Araq | that's better anyway |
| 11:30:53 | Skrylar | that sounds worse |
| 11:31:04 | Araq | well make a PR |
| 11:31:11 | Araq | I don't think anybody really uses it |
| 11:31:20 | Araq | so let's change it |
| 11:31:39 | Araq | people here are generally happier with breaking stuff than I am ... so there. |
| 11:35:27 | dom96 | Araq: So I have these types of stack traces: https://gist.github.com/dom96/ad57255861fcb5834b10 |
| 11:35:33 | dom96 | and they suck |
| 11:35:44 | dom96 | Would you be able to provide me with a way to change that? |
| 11:36:34 | dom96 | In `cb` I have access to the iterator, so if I could say myIter.whatLineAreYouOn and then add that to the current stack trace or something |
| 11:36:50 | dom96 | or rather replace the 'asyncdispatch.nim(790) cb' with it |
| 11:38:21 | Araq | hmm isn't this just the "line info off for iterators" bug? |
| 11:38:41 | dom96 | well |
| 11:38:45 | dom96 | there is that too in there |
| 11:39:05 | dom96 | but after you fix that the cb/callback= stuff will remain in the stack trace |
| 11:39:31 | Araq | well but that's correct, isn't it? |
| 11:39:43 | Araq | it simply not relevant to you, right? |
| 11:39:47 | dom96 | yeah |
| 11:40:12 | Araq | ok this requires some new builtin then |
| 11:40:30 | dom96 | cool, so you think it's a good idea? |
| 11:40:37 | Araq | well in fact |
| 11:40:50 | Araq | you can already turn off stack traces for single prcos |
| 11:40:55 | Araq | *procs |
| 11:41:00 | Skrylar | hrmm |
| 11:41:10 | Skrylar | seems like there should be a warning if a method never returns or sets result |
| 11:41:23 | dom96 | Araq: how? |
| 11:41:39 | Araq | {.push stackTrace: off.} |
| 11:42:46 | dom96 | Araq: ok. It would still be nice to be able to replace it with something more informational. |
| 11:43:09 | dom96 | so that it gives you an idea of where in the iterator it is |
| 11:43:20 | Araq | well as I said |
| 11:43:31 | Araq | I think there some bug report about it already |
| 11:52:34 | Araq | hmm damn |
| 11:52:58 | Araq | if c2nim's docs are moved the docgen needs to learn where to find it |
| 11:54:49 | Araq | oh well, everybody will have it in $nirmrod/../c2nim anyway, right? |
| 12:08:19 | * | flaviu joined #nimrod |
| 12:08:27 | NimBot | Araq/Nimrod devel f830aed Dominik Picheta [+0 ±2 -0]: AsyncHttpServer now supports POST. |
| 12:08:50 | Araq | :O |
| 12:08:59 | dom96 | :D |
| 12:09:01 | Araq | congrats, dom96 |
| 12:10:07 | NimBot | dom96/jester new-async 3126711 Dominik Picheta [+0 ±2 -0]: Attachment, halt, and more are now operational. |
| 12:10:07 | NimBot | dom96/jester new-async c4909a3 Dominik Picheta [+0 ±2 -0]: POST support. |
| 12:10:32 | dom96 | it be ready |
| 12:11:17 | Araq | btw I might add a switch to change scoping semantics for closure captures |
| 12:11:45 | Araq | this should give async more speed but it's also risky |
| 12:12:13 | Araq | maybe I should make the analysis smarter instead ... |
| 12:12:17 | * | q66 quit (Quit: Leaving) |
| 12:13:43 | Araq | well benchmarking will tell us |
| 12:14:10 | dom96 | indeed |
| 12:14:21 | dom96 | Well, I need to go see you later |
| 12:14:30 | Araq | wait a sec |
| 12:14:39 | Araq | how do I do a pull request? :-) |
| 12:14:53 | * | Araq doesn't *request* pulls |
| 12:14:53 | dom96 | lol |
| 12:15:04 | dom96 | where do you wanna do a pull request? |
| 12:15:12 | dom96 | you basically fork it |
| 12:15:16 | Araq | add some babel package |
| 12:15:18 | dom96 | push to a new branch |
| 12:15:37 | dom96 | oh, well then https://github.com/nimrod-code/packages/edit/master/packages.json |
| 12:15:52 | dom96 | although that may commit the changes immediately |
| 12:16:11 | Araq | no let me do it like the others need to do it |
| 12:16:15 | dom96 | lol |
| 12:16:18 | dom96 | fork it then |
| 12:16:21 | dom96 | clone the fork |
| 12:16:27 | Araq | ok |
| 12:16:43 | dom96 | make changes locally |
| 12:16:44 | dom96 | commit |
| 12:16:46 | dom96 | push |
| 12:17:01 | dom96 | and then github should show you |
| 12:17:15 | dom96 | "This branch is ahead of blah blah by 1 commit, do you want to PR?" |
| 12:17:26 | dom96 | or you can go here https://github.com/nimrod-code/packages/pulls |
| 12:17:35 | dom96 | and click "New Pull Request |
| 12:18:12 | dom96 | see ya |
| 12:24:15 | * | untitaker quit (Ping timeout: 252 seconds) |
| 12:24:21 | * | flaviu quit (Quit: Leaving.) |
| 12:24:31 | * | flaviu joined #nimrod |
| 12:27:00 | flaviu | blamestross: Oh, I see what you were confused by. `foo(bar)` is equivalent to `bar.foo` |
| 12:30:06 | * | untitaker joined #nimrod |
| 12:30:25 | * | saml_ joined #nimrod |
| 12:58:06 | * | darkf quit (Quit: Leaving) |
| 12:59:40 | flaviu | Error: type mismatch: got (uint64, uint64) but expected one of: system.+=(x: var T, y: T) |
| 12:59:45 | flaviu | but the lhs is a var |
| 13:12:14 | * | Boscop_ quit (Read error: Connection reset by peer) |
| 13:12:29 | * | Boscop_ joined #nimrod |
| 13:23:34 | Araq | flaviu: T's constraint doesn't match but the compiler is evil and doesn't tell you |
| 13:23:52 | Araq | there is a PR for this to work |
| 13:26:48 | * | Boscop_ is now known as Boscop |
| 13:27:45 | def- | flaviu: https://github.com/Araq/Nimrod/pull/1312 |
| 13:28:19 | flaviu | ok, thanks |
| 13:32:20 | Araq | what's the directory layout for Babel packages again? do we have any? |
| 13:39:04 | * | johnsoft quit (Ping timeout: 248 seconds) |
| 13:40:19 | * | nande joined #nimrod |
| 13:40:28 | * | nande quit (Read error: Connection reset by peer) |
| 13:47:31 | flaviu | uint32(accm and 0xFFFF_FFFF'u32) != accm and 0xFFFF_FFFF'u32 |
| 13:47:46 | flaviu | doesn't converting to uint32 just cut off the extra bits? |
| 13:49:06 | Araq | you should convert accm to uint32 and not the result |
| 13:49:25 | Araq | uint32 and uint32 produces an uint32 |
| 13:51:01 | flaviu | I think that should be equivalent to just `uint32(accm)` |
| 13:51:30 | Araq | depends on accm's type, but in general, no |
| 13:51:55 | Araq | int64 and uint32 produces int64 iirc |
| 13:52:39 | Araq | in general the rules try to prevent as much information as possible |
| 13:52:50 | Araq | and narrowing is always bad for that |
| 13:53:16 | flaviu | accm is a uint64, so I'd expect uint32(uint64) to just cut off the bits, or maybe I don't understand what you're saying |
| 13:53:48 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 13:54:23 | Araq | uint64 and uint32 produces uint64, what else? |
| 13:54:41 | Araq | should 'and' be different than 'or' and '+' ? |
| 13:55:32 | flaviu | My goal is to cut off the top bits and put a uint64 in a uint32. `accm and 0xFFFF_FFFF'u64 != uint32(accm)` |
| 13:55:51 | flaviu | which is a bit unexpected |
| 13:57:03 | Araq | why are they unequal? |
| 13:57:24 | Araq | both get promoted to 'int'? |
| 13:58:36 | Araq | oh well I don't really care. I hate this integer type zoo bullshit |
| 13:59:19 | Araq | and especially the implicit conversions that everybody else loves so much |
| 13:59:59 | Araq | they create much more problems than they solve |
| 14:00:16 | Araq | *many |
| 14:00:43 | flaviu | I'm trying to simplify the problem as much as possible, but `invalid type: 'proc (range -1..0(uint64), range -1..0(uint64)): bool{.noSideEffect.}'` |
| 14:06:04 | flaviu | No, that works fine once I get around the weird range thing. Seems the problem is somewhere else |
| 14:11:28 | * | t0ryzal joined #nimrod |
| 14:18:13 | Araq | hi t0ryzal welcome |
| 14:20:13 | t0ryzal | hello |
| 14:32:14 | * | vendethiel joined #nimrod |
| 14:38:48 | * | kunev quit (Ping timeout: 240 seconds) |
| 14:46:37 | * | saml_ quit (Quit: Leaving) |
| 14:49:11 | * | t0ryzal quit (Quit: Leaving) |
| 14:52:47 | blamestross | Morning |
| 14:55:17 | flaviu | hi blamestross, I think I see what you were confused about in my code. `foo(bar)` is equivalent to `bar.foo` |
| 14:56:25 | blamestross | flaviu: I saw in the code. Thanks. I'm at the point with nimrod where I can write code that does a job, but I still don't know half the ways to make it elegant or pretty. |
| 15:08:59 | * | EXetoC joined #nimrod |
| 15:13:45 | flyx | can I annotate a subrange type to an int literal |
| 15:13:53 | flyx | to tell the compiler „this int is of that subrange type“? |
| 15:14:50 | flyx | otherwise, this won't compile: https://gist.github.com/flyx/1ade6064ae3872434ca9 |
| 15:15:48 | def- | flyx: i noticed this too, and wish it would work. when you write t.id = 2 directly it works |
| 15:17:06 | EXetoC | 2.TId? |
| 15:17:27 | EXetoC | I think allowing (2, "Foo") is on the horizon. I've discussed that before |
| 15:17:53 | flyx | EXetoC: right, 2.TId works, thanks! |
| 15:25:22 | EXetoC | ok so it was indeed reported some time ago https://github.com/Araq/Nimrod/issues/500 |
| 15:28:49 | EXetoC | I've been avoiding that for that reason, because it complicates things |
| 15:34:29 | EXetoC | but you can get pretty much the intended behavior by defining converters I think |
| 15:37:46 | * | johnsoft joined #nimrod |
| 16:21:58 | * | superfunc joined #nimrod |
| 16:41:52 | * | kunev joined #nimrod |
| 16:50:58 | * | Demos joined #nimrod |
| 17:15:20 | * | superfunc quit (Quit: leaving) |
| 17:15:34 | * | superfunc joined #nimrod |
| 17:15:49 | superfunc | I wonder if I could get away with secretly teaching nimrod next semester |
| 17:16:09 | superfunc | Maybe I could give away extra credit for it |
| 17:17:31 | flyx | superfunc: teaching in which context? |
| 17:18:13 | Nimrod | superfunc: teaching me what? |
| 17:18:44 | superfunc | lol, I have to teach an intro Java course next semester, I was just joking about going rogue and teaching a language I dont hate |
| 17:19:01 | flyx | oh well, the Java intro courses |
| 17:19:46 | flyx | “and here we concatenate 10 objects just for outputting text. do not ask why, that won't be taught this semester” |
| 17:19:58 | superfunc | seriously though lol |
| 17:20:03 | superfunc | Its so bad. |
| 17:20:09 | Demos | thank the norse gods they fixed java's IO functions |
| 17:20:30 | superfunc | Just wondering, has anyone messed with Scala? |
| 17:20:40 | Nimrod | flyx: maybe you could teach me java. |
| 17:22:44 | flyx | Nimrod: it's fairly easy. install IntelliJ, open a file, write 3 random characters, press ctrl+space (cmd+space on OSX), enter, repeat |
| 17:23:31 | flyx | Most Java code is written by autocompletion functions of IDEs. only a small portion is written by developers. |
| 17:24:09 | * | Jehan_ joined #nimrod |
| 17:24:45 | * | sdw left #nimrod (#nimrod) |
| 17:36:26 | Demos | it does seem like a bit of a victory that somewhat inexperienced developers can produce functioning software in java and that the IDEs are so good |
| 17:36:59 | Demos | and hey, people seem to love c#, which is pretty much exactly like java |
| 17:43:35 | Jehan_ | In the same way that apples are pretty much exactly like oranges? :) |
| 17:46:14 | Demos | eagh maybe it is just becaiuse I learned j# first then transitioned to c# |
| 17:46:22 | Demos | j# was actually just like java |
| 17:48:22 | Demos | Question: Before java was there another language that had expansive standard libraries that shipped with the compiler and tools? |
| 17:48:57 | Trixar_za | Not even Java did that |
| 17:49:35 | Jehan_ | Python, minus the compiler part. |
| 17:50:07 | Jehan_ | In fact, "batteries included" has always been one of Python's major selling points. |
| 17:50:15 | flyx | C# is actually a bit different because it learned from Java's mistakes |
| 17:50:36 | Jehan_ | But more seriously, while both C# and Java are OO languages with a JIT implementation, they have some pretty fundamental differences, too. |
| 17:51:22 | Jehan_ | flyx: Well, arguably, the problem was that Java pretty much ignored all existing programming language research. |
| 17:51:31 | Jehan_ | So it wasn't too hard to improve upon that. |
| 17:52:01 | flyx | the major drawback of C# is the missing cross-platform compatibility. because while Mono exists and is usable, you have to be extra careful if you want to write code that runs on Mono *and* .NET |
| 17:52:26 | Jehan_ | flyx: Yeah, that's an unfortunate vendor limitation. |
| 17:53:24 | Jehan_ | Speaking of which, I'd kill for Windows 9 having a POSIX compatibility layer. |
| 17:53:54 | superfunc | Jehan_: I thought windows was partially compliant |
| 17:54:02 | Demos | well windows 7's POSIX latyer was pretty bad |
| 17:54:06 | Trixar_za | Except, batteries included seems to be going down the crapper |
| 17:54:24 | Jehan_ | superfunc: Well, there was a semi-working thing, but you only got that with the pro version. |
| 17:54:48 | Jehan_ | Trixar_za: Hmm, really? My concern is more that the Python distribution is getting too big. |
| 17:54:59 | Demos | I don't think all that much actually worked under SUA |
| 17:55:18 | Trixar_za | Almost all libraries require you to install them globally or through pip since it requires other non-standard libraries that have their own non-standard requirements. |
| 17:55:29 | Trixar_za | Why do you think I'm writing my own irc library now? |
| 17:55:35 | Trixar_za | That crap just pissed me off |
| 17:55:40 | Jehan_ | Trixar_za: Hmm, I'm talking about what you get out of the box without extra packages. |
| 17:56:39 | Jehan_ | That pip/easy_install have their warts is well known. |
| 17:56:46 | Demos | I really want something like NuGet (or chocolatey) to let me install libraries without using VS |
| 17:57:37 | Trixar_za | Jehan_, my biggest problem is that I want to make my programs copy and run. Requiring libraries that needs pip to install defeats that point |
| 17:58:37 | Jehan_ | Trixar_za: Yeah. But is there any language these days that doesn't do that via a package manager? |
| 17:58:57 | Trixar_za | Also the non-standard required libraries those libraries have themselves is unforgivable. It makes including the one library requires you to include several other files as well to get 'standard' support. |
| 17:59:01 | superfunc | I thought nuget worked through powershell |
| 17:59:06 | Demos | well, c++ |
| 17:59:18 | Demos | it does, but the library bits only really work in visual studio |
| 17:59:33 | Demos | afaik it scorunges around vs project files to set up linkage options and the like |
| 17:59:58 | Jehan_ | Trixar_za: I'm not a big fan of deeply nested dependency graphs myself. :( |
| 17:59:59 | Demos | lets static link all the things |
| 18:00:47 | Jehan_ | superfunc: NuGet is a .exe at the most basic level? I know because I've run it on OS X/Linux before? |
| 18:01:26 | Trixar_za | Jehan_: I assume most users only have the most basic understanding of the language and their system's package manager. So something like pygtk or pyside is acceptable, but not so much an obscure library with several nested dependencies. Especially for a simple throw away script :P |
| 18:01:43 | Jehan_ | Trixar_za: Heh. :) |
| 18:01:53 | Jehan_ | I have to say that I'm a fan of scons for that reason. |
| 18:02:02 | Jehan_ | I.e., it doesn't require anything else to run. |
| 18:02:24 | Jehan_ | Plus, I don't have to deal with the stupid Makefile syntax. :) |
| 18:02:32 | Trixar_za | Actually that's what attracted me to Nimrod - it's pretty much self-contained |
| 18:03:26 | Jehan_ | Trixar_za: Same here. |
| 18:03:40 | Jehan_ | It's actually something I *need* for some things. |
| 18:08:32 | Jehan_ | Umm, Rust 0.10 has changed _again_ how they're dealing with pointers? |
| 18:11:23 | dom96 | back |
| 18:17:59 | dom96 | Anybody bored and wanna write a macro? |
| 18:18:11 | dom96 | If so, write one which gets rid of the boilerplate here: https://gist.github.com/dom96/8fa50211681be4dca749 |
| 18:19:38 | flaviu | dom96: Well, if that's all the boilerplate you need, I'd say you're doing pretty good |
| 18:20:25 | dom96 | flaviu: I know it's minor, but minor things add up. |
| 18:21:46 | flaviu | think about readability too. Is it easier to see what a macro does, or just to copypaste a bit? Especially since this is just in a single place |
| 18:24:35 | dom96 | That's why the macro should be designed so that it's readable. |
| 18:26:48 | * | johnsoft quit (Ping timeout: 264 seconds) |
| 18:28:02 | flaviu | Well, it seems I can't shift an unsigned value by a negative amount |
| 18:28:40 | flaviu | Since `shl(T, T): T`, so typemismatch on `shl(uint32, int): uint32` |
| 18:29:44 | flyx | is there a nice syntax for „iterate through this but skip the first element“? |
| 18:29:50 | Jehan_ | Shifting by a negative value is undefined anyway. |
| 18:30:38 | flaviu | I thought nimrod avoids undefined behavior? |
| 18:32:56 | Jehan_ | flaviu: Not in this case, apparently. |
| 18:33:56 | flaviu | I guess I'll have to do `sizeof(T)`, if that works with generics |
| 18:35:13 | Jehan_ | flaviu: what are you trying to do? |
| 18:35:45 | flaviu | Write a generic rot{l,r} |
| 18:39:02 | Jehan_ | sizeof should work for that. |
| 18:39:13 | flaviu | Yep, seems to work |
| 18:39:46 | flaviu | Not the most beautiful code, but it works |
| 18:42:06 | Jehan_ | Use [T:TInteger] as the constraint? |
| 18:42:19 | flaviu | Yes, I am |
| 18:43:18 | flaviu | `return (i shl T(distance)) or (i shr T((sizeof(T)*8)-distance))` vs `return (i shl distance) or (i shr -distance)`(ideally) |
| 18:43:37 | flaviu | Still clear and readable, but more cluttered |
| 18:43:58 | Araq | according to news.txt we're going to release tomorrow... |
| 18:44:09 | Jehan_ | I think shl and shr need to be properly overloaded. |
| 18:44:38 | Jehan_ | There's no reason why the shift offset needs to be the same type as the shifted value. |
| 18:45:01 | flaviu | ^ |
| 18:45:19 | Araq | there was a reason to do it this way, but I can't remember |
| 18:45:28 | Araq | I think it was about consistency |
| 18:46:06 | Jehan_ | Generally, you want to use shifts with unsigned values, but normal integers for the offset. |
| 18:46:31 | Araq | no. why? |
| 18:47:08 | dom96 | Araq: fuck really? |
| 18:48:01 | flaviu | The whole purpose of unsigned is to be thought of as a string of bits. Why would you want to use signed integers for shifting? |
| 18:48:24 | Jehan_ | Araq: Because shr for signed integers is not defined. |
| 18:48:28 | flaviu | There are weird issues, such as what to do with the sign bit. |
| 18:49:40 | Jehan_ | Or, to be precise, implementation-defined. |
| 18:50:05 | Jehan_ | More importantly, you rarely want the arithmetic right shift that compilers do for signed ints by default. |
| 18:50:16 | Jehan_ | most compilers* |
| 18:50:49 | flaviu | Are there even real uses for arithmetic right shift? |
| 18:51:16 | Jehan_ | Only a couple of years I wrote code to work around the Cray C Compiler not doing it right. |
| 18:51:42 | Jehan_ | flaviu: Yes, but rare. |
| 18:52:47 | Jehan_ | Example: Many interpreters encode ints by having the lowest bit set to distinguish them from pointers. |
| 18:53:03 | Jehan_ | You shift them right one bit to convert them to proper integers. |
| 18:55:35 | Jehan_ | Personally, I'd have all bit operations for unsigneds in system.nim. That (unlike arithmetic) is what unsigneds are for. |
| 18:57:41 | flaviu | I once asked about VLAs in nimrod, but I think everyone was asleep. Are they on the roadmap/does someone have a library for them? |
| 18:58:52 | flaviu | I guess my best chance of getting them is to integrate unchecked arrays with the GC, which would work about the same |
| 18:59:43 | Jehan_ | flaviu: You can {.importc: "alloca", header: "<alloca.h>".} |
| 19:00:04 | Jehan_ | That said, there's little point in using VLAs. |
| 19:00:26 | Jehan_ | You don't want to allocate arbitrarily sized arrays on the stack, so you may just as well allocate a fixed size one that's large enough. |
| 19:00:47 | * | superfunc quit (Quit: leaving) |
| 19:02:52 | Araq | Jehan_: shr/shl do pretend the numbers are unsigned even for signed |
| 19:03:05 | Araq | this avoids the undefined behaviour |
| 19:03:09 | Jehan_ | Araq: I hadn't realized that. |
| 19:03:28 | Araq | dom96: yes. |
| 19:03:44 | Araq | and yes I'll move the unsigned ops into system.nim |
| 19:03:59 | Araq | import unsigned will be an empty import then |
| 19:04:45 | Jehan_ | Araq: Hmm, I'm not sure whether that's a good idea for the arithmetic operators. |
| 19:05:05 | Araq | Jehan_: too many people complained |
| 19:05:13 | Jehan_ | Araq: Heh. :) |
| 19:06:38 | Jehan_ | Well, the thing is that in C/C++, people keep shooting themselves in the foot by using unsigneds wrong. |
| 19:07:37 | * | Varriount|Mobile joined #nimrod |
| 19:07:55 | Jehan_ | My rule has always been: ints for arithmetic, unsigneds for bitops (or where I specifically need the mod 2^n behavior). |
| 19:08:17 | Araq | I defined bitops to use unsigned semantics |
| 19:08:22 | Jehan_ | Well, not always, I'm pretty sure I got it wrong in the 1980s, too. :) |
| 19:08:34 | Araq | and so the rule is: use ints. |
| 19:08:53 | Araq | well that was the idea |
| 19:09:01 | Araq | it's not that simple in practice |
| 19:09:12 | Jehan_ | Araq: Yeah, but bitops are often combined with multiplication mod 2^n, which is only defined for unsigned. |
| 19:12:12 | Araq | lol: http://xkcd.com/619/ |
| 19:13:13 | Jehan_ | Heh. :) |
| 19:13:42 | Jehan_ | It would be nice to have a third OS for Desktop work, yeah. |
| 19:16:15 | * | Mathnerd626 joined #nimrod |
| 19:17:04 | Araq | hi Mathnerd626 welcome |
| 19:27:27 | NimBot | Araq/Nimrod devel cbcf01f Reimer Behrends [+0 ±3 -0]: Rename sequtils.distnct to sequtils.deduplicate. |
| 19:27:27 | NimBot | Araq/Nimrod devel 3310688 Andreas Rumpf [+0 ±3 -0]: Merge pull request #1318 from rbehrends/rename-distnct... 2 more lines |
| 19:28:07 | * | crippa joined #nimrod |
| 19:28:17 | Araq | hi crippa welcome |
| 19:29:12 | Araq | Jehan_: maybe reactormonk is right and it should instead be a babel package? we need more packages |
| 19:29:24 | Jehan_ | Araq: I have no preference. |
| 19:29:37 | Araq | how often is this stuff useful? |
| 19:29:48 | Jehan_ | I find the functionality useful for testing primarily. |
| 19:29:56 | Araq | has python it in its stdlib? |
| 19:30:04 | Jehan_ | I'd have to check. |
| 19:30:08 | flaviu | Araq: Yes |
| 19:30:43 | Araq | ok then, it sux to have deps simply for testing stuff |
| 19:31:06 | Araq | and english sux too btw for having so many long latin words |
| 19:31:16 | Jehan_ | Yes, it's in itertools. |
| 19:31:31 | Jehan_ | It's not _only_ useful for testing. :) |
| 19:31:55 | flaviu | I think that nimrod needs its own itertools |
| 19:32:02 | Jehan_ | That's just what I find it most useful for. |
| 19:32:37 | Araq | when I need a permutation generator, I usually write my own |
| 19:32:53 | flaviu | sequtils, strutils, algorthm, are mostly wannabe itertools |
| 19:33:16 | Araq | it's always a useful exercise and I end up tweaking it to produce not *every* permutation |
| 19:33:42 | Jehan_ | flaviu: One could argue that Python has itertools because it lacks decent inline closures. :) |
| 19:34:12 | Jehan_ | Araq: As I said, I have no preference. |
| 19:34:46 | Jehan_ | Which reminds me that I need to write up an issue for the iteration bug. |
| 19:34:50 | flaviu | Nimrod has inline closures? |
| 19:35:38 | Jehan_ | flaviu: Modulo differences in definition, yes? |
| 19:35:44 | * | johnsoft joined #nimrod |
| 19:36:16 | Jehan_ | By inline closure I mean a closure that's part of an expression/statement rather than a separate definition. |
| 19:36:46 | Jehan_ | Python has `def` and `lambda`. `def` isn't inline in that sense and `lambda` is limited in what it can do. |
| 19:36:48 | flaviu | Anyway, I think that the itertools is still useful, and closure iterators feel like an elegant way to do things |
| 19:39:25 | flaviu | Should I make the hash function so it returns the same thing on all endians? It seems that even ARM is little endian |
| 19:40:53 | Araq | flaviu: dunno, seems useful |
| 19:42:06 | Jehan_ | At least we don't seem to have architectures anymore that just randomize the byte order. |
| 19:42:42 | flaviu | lol, which architectures did that? |
| 19:42:48 | Varriount|Mobile | flaviu: I agree with you on the fact that nimrod needs an itertools module |
| 19:43:07 | * | Trustable quit (Ping timeout: 245 seconds) |
| 19:43:27 | Jehan_ | PDP-11. |
| 19:43:39 | Jehan_ | Technically, ARM can also do it when writing unaligned data. |
| 19:46:55 | Araq | hmmm itertools sometimes uses an 'i' prefix |
| 19:47:37 | flaviu | Jehan_: It seems that you have to explicitly ask for it each time you want it, so it doesn't look like a problem |
| 19:47:48 | Araq | I wonder how many people complained endlessly about that, comparing to hungarian notation |
| 19:48:18 | Jehan_ | Heh. |
| 19:48:30 | shevy | what's wrong with hungarian notation |
| 19:49:20 | flaviu | shevy: Looks ugly |
| 19:49:23 | flaviu | :P |
| 19:49:26 | shevy | programmers are lazy when it comes to typing, save for the tireless java programmers |
| 19:49:33 | shevy | C++ templates look ugly too |
| 19:49:40 | Araq | brb |
| 19:49:46 | flaviu | I dunno, I think its justified in this case, it isn't really convention |
| 19:49:52 | Jehan_ | Araq: Tell you what, I'll put the combinatorics module in a Babel package. It can still go in the stdlib at some later point if there's sufficient interest. |
| 19:50:00 | shevy | the convention of laziness? :) |
| 19:50:05 | shevy | like the linux FHS |
| 19:50:17 | flaviu | the windows API guys love their hungarian notation and uppercase type names |
| 19:50:51 | flaviu | INT_PTR WINAPI DialogBox( _In_opt_ HINSTANCE hInstance, _In_ LPCTSTR lpTemplate, _In_opt_ HWND hWndParent, _In_opt_ DLGPROC lpDialogFunc ); |
| 19:51:08 | shevy | is that hungarian |
| 19:51:13 | flaviu | Beautiful :') |
| 19:51:36 | flaviu | shevy: Yes, `hInstance`, `lpTemplate`, `hWndParent`, `lpDialogFunc` |
| 19:51:40 | shevy | then it seems as if there must be more than one hungarian notation about |
| 19:52:36 | shevy | the FHS mandates that you must have a directory called /var/lock/ :) http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES |
| 19:53:04 | Jehan_ | Araq: Especially given that I probably should rename some of the functions for consistency with itertools, anyway. :) |
| 19:53:06 | shevy | /var/opt is also great - it stores variable data from /opt |
| 19:54:10 | shevy | notice the slight inconsistency: /opt is mandatory according to http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES but there is no mandatory /var/usr/ or /var/usr/local |
| 19:54:13 | shevy | I <3 the FHS :) |
| 19:54:30 | shevy | the older ones even had a mandatory /usr/X11R6 directory |
| 19:54:46 | shevy | nowadays it is only optional, but the reasoning for it was so funny |
| 19:54:58 | shevy | basically "because everyone was using it, so let's call it a standard thusly" |
| 19:56:25 | * | Trustable joined #nimrod |
| 19:57:05 | * | kunev quit (Quit: leaving) |
| 19:58:18 | flaviu | This C code is weird |
| 19:58:25 | flaviu | https://code.google.com/p/smhasher/source/browse/trunk/MurmurHash3.cpp#108 |
| 19:58:57 | * | Puffin joined #nimrod |
| 19:59:11 | flaviu | Hey, lets use a really convoluted method of iterating through each element that involves even weirder pointer arithmatic! |
| 20:02:04 | * | BitPuffin quit (Ping timeout: 260 seconds) |
| 20:17:42 | Araq | Jehan_: ok, so make it a babel package |
| 20:17:57 | Araq | fine with me |
| 20:18:20 | Araq | Varriount, Varriount|Mobile can we release tomorrow? |
| 20:18:23 | Jehan_ | Well, that's why I was asking originally -- there's always a risk of polluting the standard library. :) |
| 20:19:05 | Araq | the stdlib is bloated, I'm also moving c2nim and pas2nim to its own repos |
| 20:19:33 | Araq | and I want to extract idetools and the docgen into its own .exes |
| 20:23:47 | * | crippa quit (Ping timeout: 264 seconds) |
| 20:25:25 | dom96 | This is weird |
| 20:25:49 | dom96 | Jester is slightly faster than standalone asynchttpserver |
| 20:45:55 | * | Puffin is now known as BitPuffin |
| 20:47:23 | * | wan joined #nimrod |
| 20:50:32 | * | silven quit (Ping timeout: 248 seconds) |
| 20:57:41 | Araq | maybe you measure it wrong |
| 21:07:54 | flaviu | The VM is doing pretty good; I can use the repl without crashes :D |
| 21:08:46 | dom96 | Araq: Not sure how I can be measuring it wrong but oh well |
| 21:09:12 | Araq | dom96: did you go the 'dispatch' route for jester? |
| 21:10:07 | * | betawaffle joined #nimrod |
| 21:10:11 | dom96 | Araq: yes |
| 21:10:19 | Araq | yay |
| 21:10:31 | Araq | this means I like Jester now :-) |
| 21:10:42 | Araq | even though it beats the shit out of the compiler |
| 21:10:54 | dom96 | might be easier on the compiler now |
| 21:10:55 | dom96 | maybe |
| 21:11:02 | dom96 | Although now there are two levels of macros :D |
| 21:11:26 | Araq | well before we had *4* levels of closures |
| 21:13:03 | dom96 | yeah, you're right. I need to up the ante. |
| 21:13:17 | dom96 | 8 levels of closures + 5 levels of macros it is |
| 21:14:07 | Araq | well I think fowl still holds the "beat the shit out of the compiler when it comes to macros" record |
| 21:14:31 | dom96 | bah really |
| 21:14:50 | Araq | well his code scares me |
| 21:15:37 | Araq | but unittest.nim also scares me |
| 21:17:58 | Demos | unittest.nim is nightmarefuel |
| 21:20:30 | Demos | is there a JSON parser around that makes use of the `.` overloading feature? |
| 21:21:00 | Araq | I don't think so but it should be easy to implement '.' on top |
| 21:21:04 | Jehan_ | I have learned to minimize my use of macros the hard way. :) |
| 21:21:20 | Jehan_ | Essentially I am using Nimrod as a Pascal dialect with a Pythonesque syntax and GC. :) |
| 21:22:48 | Araq | I'm still trying to unify macros and generics |
| 21:23:28 | flaviu | Araq: I have an idea on how to get rid of all VM bugs: Add an undocumented feature that makes macros that are too complicated not compile, like PLEASE in INTERCAL :P |
| 21:23:59 | * | q66 joined #nimrod |
| 21:24:47 | Araq | flaviu: something like "cannot map this code to the VM" might even be workable |
| 21:25:05 | Demos | that makes CTFE much less appealing though |
| 21:25:06 | Demos | :D |
| 21:25:25 | Araq | Demos: well that's what we currently have, but with crashes instead |
| 21:26:14 | flaviu | Except that crashes are actually somewhat useful in debugging |
| 21:27:20 | flaviu | Although easy debugging might be counterproductive, it makes things easier to fix and people less likely to report bugs |
| 21:28:26 | dom96 | hrm, well it seems I was wrong |
| 21:30:47 | Araq | wooohooo |
| 21:30:52 | Araq | watch out |
| 21:31:01 | Araq | my first pull request ever |
| 21:32:25 | * | Fr4n quit (Ping timeout: 252 seconds) |
| 21:33:07 | Demos | welcome to the project araq :D |
| 21:36:36 | * | Fr4n joined #nimrod |
| 21:37:26 | fowl | Araq, why does bad AST cause mysterious errors |
| 21:37:49 | fowl | see #1309 |
| 21:37:57 | Araq | fowl: I dunno it's a mystery |
| 21:42:21 | flaviu | Yay, finally got MurmurHash3 to work! |
| 21:44:22 | Araq | flaviu: is that as good as SHA-1? |
| 21:44:43 | flaviu | It isn't cryptographic, so no, but it is extremely fast |
| 21:44:55 | Araq | I want to base the future of the nimrod compiler on some hash function |
| 21:44:57 | dom96 | flaviu: So what is it useful for? |
| 21:45:04 | flaviu | dom96: Hashtables |
| 21:45:12 | flaviu | Bloom filters, general purpose hashing |
| 21:45:45 | Araq | ok, so ... do we have an SHA-1 implementation in Nimrod? |
| 21:46:09 | Araq | dom96: merge my PR! |
| 21:46:18 | flaviu | Araq: In babel, https://github.com/onionhammer/sha1/blob/master/sha1.nim |
| 21:47:16 | Araq | OrionPK: is your sha1 good enough for the compiler itself? |
| 21:47:44 | * | xenagi joined #nimrod |
| 21:48:45 | dom96 | Araq: lol what? https://github.com/nimrod-code/c2nim/blob/master/c2nim.babel |
| 21:48:55 | dom96 | So let me get this straight. |
| 21:49:01 | dom96 | c2nim is a binary package right? |
| 21:49:26 | dom96 | Not only did you not add 'bin = "c2nim"' but you also decided to skip the installation of c2nim.exe? |
| 21:49:55 | * | Fr4n quit (Ping timeout: 240 seconds) |
| 21:50:27 | dom96 | That's funny. But I shouldn't laugh since it's your first PR and all. |
| 21:50:28 | dom96 | Sorry :P |
| 21:50:33 | * | Fr4n joined #nimrod |
| 21:50:37 | dom96 | Anyway, add that please and remove the skipfile |
| 21:50:41 | flaviu | Murmurhash3 is ~1byte/cycle; sha1 is ~ 0.087bytes/cycle according to https://code.google.com/p/smhasher/wiki/MurmurHash3_x86_32 and http://www.cryptopp.com/benchmarks.html |
| 21:50:52 | Jehan_ | dom96: Feature request: It would be nice to be able to do a test install from a directory without committing first. |
| 21:50:55 | dom96 | I suggest also adding a dependency on the Nimrod compiler. |
| 21:51:02 | flaviu | SHA-1 is actually faster than I thought |
| 21:51:04 | dom96 | Jehan_: You can do that. |
| 21:51:11 | Jehan_ | dom96: How? |
| 21:51:19 | dom96 | Jehan_: just execute 'babel install' from the directory where your package resides in |
| 21:51:24 | Araq | dom96: ok, I misunderstood what SkipFiles means ... |
| 21:51:44 | Jehan_ | Okay, that was kinda too obvious for me to try. :) |
| 21:52:17 | dom96 | Araq: You may wanna use this next time :P https://github.com/nimrod-code/babel/blob/master/developers.markdown#optional |
| 21:52:46 | * | Varriount|Mobile quit (Remote host closed the connection) |
| 21:53:27 | Araq | ppfff I didn't come this far by *reading* things |
| 21:54:09 | * | Nimrod_ joined #nimrod |
| 21:54:56 | flaviu | Skein Hash is maybe twice as fast as sha-1 and actually secure |
| 21:56:29 | flaviu | BLAKE is a couple of cycles per byte slower than Skein, and about as good |
| 21:56:35 | dom96 | What about Keccak? |
| 21:56:43 | dom96 | The 'Winner' according to Wikipedia? :P |
| 21:57:18 | Jehan_ | dom96: Depends on what you want to do with it? |
| 21:57:21 | * | Nimrod quit (Ping timeout: 252 seconds) |
| 21:57:59 | flaviu | dom96: Doesn't look that fast, about equal to speed to sha-1 |
| 21:59:13 | dom96 | I wonder what the NIST hash function competition judges the hash functions on. |
| 21:59:23 | Jehan_ | If you're talking about cryptography, it's not all about cycles. |
| 21:59:38 | flaviu | Jehan_: Not real crypto, just hash tables |
| 21:59:59 | Jehan_ | flaviu: Yeah, but then you don't need cryptographic strength. :) |
| 22:00:20 | flaviu | Being slightly broken won't cause anything worse than a tiny bit slower performance |
| 22:00:25 | Jehan_ | Also, don't forget to test how they fare for short blocks. :) |
| 22:00:28 | flaviu | Jehan_: Ask Araq |
| 22:14:09 | Araq | I plan to use it for hashing ASTs and type graphs |
| 22:14:38 | Araq | I will declare two ASTs as equal when their hashes are equal |
| 22:14:48 | Araq | so ... it needs to be strong enough |
| 22:16:03 | Jehan_ | SHA-1 should work for that. |
| 22:16:24 | Jehan_ | This is, after all, the exact same criterion that git uses. |
| 22:21:23 | * | Nimrod_ quit (Ping timeout: 264 seconds) |
| 22:22:11 | OrionPK | Araq idk, I ported it from C afaik |
| 22:22:21 | OrionPK | Araq why? |
| 22:23:13 | * | Nimrod joined #nimrod |
| 22:38:31 | * | lorxu joined #nimrod |
| 22:39:58 | dom96 | hi lorxu |
| 22:40:05 | lorxu | Hi |
| 22:40:52 | lorxu | I'm new in nimrod |
| 22:41:26 | OrionPK | hi lorxu |
| 22:42:30 | lorxu | Hi |
| 22:44:07 | * | Jehan_ quit (Quit: Leaving) |
| 22:56:09 | flaviu | Araq: I guess SHA-1 might work better, but SHA-3 is stronger and more recent. MurmurHash3 also has 128-bit mode, and is strong against unintentional collision, although someone malicious could get collisions fairly easily. |
| 23:00:20 | flaviu | Also keep in mind that each node in the AST increases the collision resistance by 1/2^32 for a 32 bit hash |
| 23:07:57 | flaviu | On the other hand, SHA-1 might be the better choice beside all other factors (some weakness, a bit slow), because its actually been implemented in nimrod, which I assume is a pretty big factor in the decision |
| 23:15:15 | fowl | Rename sequtils.distnct to sequtils.deduplicate. #1318 |
| 23:15:16 | fowl | huh |
| 23:18:49 | * | darkf joined #nimrod |
| 23:20:16 | NimBot | dom96/jester new-async 2b17319 Dominik Picheta [+0 ±1 -0]: Fix incorrect Content-Length. |
| 23:27:58 | * | io2 quit () |
| 23:29:45 | * | Fr4n quit (Quit: Leaving) |
| 23:34:03 | Araq | flaviu: what do you mean it *increases* the resistance? |
| 23:39:33 | * | Trustable quit (Quit: Leaving) |
| 23:40:58 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:44:03 | flaviu | When you have one node, there is about 1/2^32 chance of collision. When you have two node, the ideal chance of collision (without anyone being malicious) is the chance of the first node having a collision times the chance of the second node having a collision is 1/2^2^32 |
| 23:44:32 | flaviu | Unless you're only doing testing the top hash, in which case that doesn't happen |
| 23:44:40 | flaviu | I don't know how you're doing things |
| 23:48:22 | Araq | well there are only 4 billion different bit combinations for a 32bit hash |
| 23:48:38 | Araq | the number of potential ASTs is enormous |
| 23:49:05 | Araq | so collisions seem to be likely |
| 23:49:40 | Araq | and I don't know what it means "to add 1 node to increase the resistance" |
| 23:51:18 | flaviu | Araq: Sorry, I was misunderstanding how you want to do this, but what I mean is also checking the the childrens' hashes for equality |
| 23:51:21 | * | asterite joined #nimrod |
| 23:52:33 | flaviu | You do want a long hash, and since SHA-1 is implemented, and there isn't a reason for someone to spend lots of money to attack the compiler, that would most likely be the best solution |
| 23:52:42 | * | Edelwin left #nimrod ("not here") |
| 23:53:17 | flaviu | I guess that most the time won't be spent calculating the hash, so you don't need a super-fast hash |
| 23:53:37 | Araq | hi asterite, how's crystal? |
| 23:54:20 | Araq | flaviu: I am not sure. could turn out to be expensive. I plan to use it a lot |
| 23:54:29 | * | joelmo quit (Quit: Connection closed for inactivity) |
| 23:54:58 | flaviu | You can benchmark later too, and replacing the hash should be pretty easy if it turns out not to work |
| 23:55:34 | Araq | i bet it's meaningless anyway. the AST traversal takes more time than the actual hash function |
| 23:55:52 | * | asterite quit (Ping timeout: 260 seconds) |
| 23:55:54 | * | asterite1 joined #nimrod |
| 23:58:15 | * | xenagi|2 joined #nimrod |
| 23:58:42 | Araq | hi lorxu welcome |
| 23:59:20 | * | Mathnerd626 quit (Read error: Connection reset by peer) |