| 00:00:12 | * | brson quit (Quit: leaving) |
| 00:00:44 | * | brson joined #nim |
| 00:11:32 | * | JehanII joined #nim |
| 00:13:36 | * | Jehan_ quit (Ping timeout: 276 seconds) |
| 00:17:05 | * | clynamen quit (Ping timeout: 246 seconds) |
| 00:18:13 | JehanII | Hmm, I think I'd go with a space-efficient variant of Fisher-Yates (where you stop after having pulled n values out of the sample) and then simply sort the result. |
| 00:19:12 | JehanII | You can replace the array in the standard Fisher-Yates implementation with a hash table where h[i] defaults to i. |
| 00:19:56 | JehanII | This is space-efficient (using O(n) space) and expected O(n) time for sampling n values out of m. |
| 00:20:46 | JehanII | You'll still have to sort the result, but I don't see an easy way around this (at least not right now). |
| 00:21:01 | BlaXpirit | well this was supposed to be the easy way |
| 00:21:24 | BlaXpirit | i'm not convinced about using shuffle |
| 00:21:40 | flaviu | I wonder if there's a O(1) space way of doing this using LCGs. |
| 00:22:12 | flaviu | well, not O(1), more like O(log_2(n)) |
| 00:22:42 | * | clynamen joined #nim |
| 00:23:20 | JehanII | Actually, I think there may be an O(n) way, but I'll have to convince myself first that it works. |
| 00:23:40 | JehanII | The idea would be to randomly pick the gaps between two successive values. |
| 00:23:58 | JehanII | I'm using a similar approach to enumerate all choices of size n out of m values. |
| 00:24:25 | BlaXpirit | this seems to be dangerous |
| 00:24:48 | BlaXpirit | may not be uniformly random |
| 00:25:22 | BlaXpirit | i'm not here to come up with or listen to new ideas |
| 00:26:04 | JehanII | https://bitbucket.org/behrends/nimcombinatorics/src/default/combinatorics.nim?at=default#cl-55 |
| 00:26:10 | JehanII | Yes, I know that. |
| 00:27:15 | BlaXpirit | what is this |
| 00:27:36 | BlaXpirit | the only relation i can think of is to give Nth combination |
| 00:27:42 | BlaXpirit | but this is biased |
| 00:27:51 | JehanII | See the comment. It's an algorithm to enumerate all choices of k distinct elements out of n, in order. |
| 00:27:57 | BlaXpirit | biased |
| 00:28:17 | BlaXpirit | 1,2 and 2,1 needs to be counted twice, but is counted once |
| 00:28:21 | BlaXpirit | something like that, cant explain it |
| 00:28:44 | BlaXpirit | i'm talking, of course, if you mean to use this for random sample |
| 00:29:15 | BlaXpirit | picking random intervals is also probably a wrong approach |
| 00:29:27 | BlaXpirit | not as easy to show why it's wrong though |
| 00:29:33 | BlaXpirit | pls |
| 00:31:28 | * | brson quit (Quit: leaving) |
| 00:31:45 | BlaXpirit | I'm not sure my thoughts actually make sense. this may actually be correct. but is generating Nth combination doable anyway? |
| 00:31:55 | BlaXpirit | nope |
| 00:34:11 | * | Jehan_ joined #nim |
| 00:34:55 | * | dtscode joined #nim |
| 00:38:15 | * | JehanII quit (Ping timeout: 276 seconds) |
| 00:40:48 | BlaXpirit | that intset thing seems similar to http://judy.sourceforge.net/doc/Judy1_3x.htm |
| 00:41:03 | flaviu | huh, interesting. Does anyone want to guess the output of this: https://gist.github.com/59ba9722bdbc9d9d3e63 ? |
| 00:41:09 | * | arnetheduck quit (Ping timeout: 264 seconds) |
| 00:41:58 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:43:02 | def- | flaviu: an overflow? |
| 00:43:35 | flaviu | Nope, it outputs nothing! |
| 00:43:38 | * | arnetheduck joined #nim |
| 00:43:44 | def- | for me it overflows |
| 00:44:01 | BlaXpirit | flaviu, it's probably because of crash |
| 00:44:08 | * | Trustable quit (Remote host closed the connection) |
| 00:44:26 | def- | and with int overflows you have undefined behaviour, so anything can happen! |
| 00:44:28 | BlaXpirit | so guys |
| 00:44:54 | BlaXpirit | Judy can give set bits in ascending order |
| 00:44:59 | BlaXpirit | we have the technology |
| 00:45:08 | flaviu | k, fixed: https://gist.github.com/f548bd8660a96db7a26b |
| 00:49:28 | * | rzzz quit (Read error: Connection reset by peer) |
| 00:52:47 | flaviu | Now, discarding the bottom bits causes the rng to loose this property. But the idea behind PCG is that *permutations*, not k-to-1 is used to do the improvement, so a properly set up PRNG could definitely do this in very small space. |
| 00:52:47 | * | davidhq quit (Ping timeout: 256 seconds) |
| 00:53:05 | flaviu | Although I guess the sorting step still requires at least n space... |
| 00:53:37 | BlaXpirit | sorting is not an absolute requirement here. |
| 00:54:18 | Jehan_ | https://gist.github.com/rbehrends/98ebf2cd893d203fb38e |
| 00:54:55 | Jehan_ | Basically, Fisher-Yates optimized for space. |
| 00:55:58 | * | davidhq joined #nim |
| 00:56:51 | Jehan_ | I'm a bit too tired to verify it completely, but it seems to work. |
| 00:58:13 | Jehan_ | Obviously, for large k, you want to use the complement instead, and for k within a constant factor of n, using an array is still better. |
| 00:58:37 | flaviu | BlaXpirit: btw, I'm not suggesting you take advantage of my idea. As you said, "i'm not here to come up with or listen to new ideas", which is reasonable given your goals here. |
| 01:00:59 | TEttinger | BlaXpirit, yeah Judy arrays are neat. they perform similarly to a typical HashMap, but use less memory on large collections, there was a good performance analysis done a while ago |
| 01:01:22 | BlaXpirit | what can help me: fix intset to be ordered or prove that it would be significantly slower or link to a proven algorithm |
| 01:01:40 | BlaXpirit | and not nim code implementing a new idea |
| 01:01:42 | BlaXpirit | sorry, Jehan_ :| |
| 01:02:15 | BlaXpirit | so the important thought here is |
| 01:02:18 | Jehan_ | BlaXpirit: Not sure what intset being ordered would buy you. |
| 01:02:28 | BlaXpirit | i explained |
| 01:02:50 | BlaXpirit | so the important thought here is judy array provides a way to iterate in order and doesn't provide a way to iterate out of order |
| 01:02:50 | Jehan_ | It's still O(n*log(n)), so it buys you nothing over just calling sort. |
| 01:03:15 | Jehan_ | And what the code I posted above is is actually a proven algorithm. |
| 01:03:25 | Jehan_ | Fisher-Yates has been analyzed to death. |
| 01:03:44 | Jehan_ | The only tweak I used was implementing it using a hash table instead of an array. |
| 01:03:54 | Jehan_ | So I didn't have to prepopulate it for large n. |
| 01:07:26 | BlaXpirit | there are so many things i'd like to benchmark |
| 01:07:29 | * | TEttinger quit (Ping timeout: 246 seconds) |
| 01:08:18 | BlaXpirit | most importantly IntSet.items vs http://judy.sourceforge.net/doc/Judy1_3x.htm#J1N |
| 01:09:08 | BlaXpirit | will do this first thing tomorrow, then look at Jehan's suggestion |
| 01:09:57 | Jehan_ | Well, Judy arrays are patented, so you probably want to steer clear of them. |
| 01:11:05 | * | TEttinger joined #nim |
| 01:12:16 | BlaXpirit | like i said, IntSet looks very much like Judy |
| 01:12:54 | BlaXpirit | using Judy array is not my intent. my intent is to see if there is any real reason IntSet is not sorted |
| 01:14:38 | BlaXpirit | I say they're alike, but I actually don't know how either of them is implemented. just similar on the outside :| |
| 01:15:51 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 01:16:01 | * | irrequietus quit () |
| 01:21:18 | flaviu | Looks like HP owns the patent on Judy, and they don't seem to have published any patent promise. Good news is we only have to wait 5 years until the patent expires! |
| 01:28:53 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 01:39:34 | * | Jehan_ quit (Quit: Leaving) |
| 01:43:45 | * | davidhq joined #nim |
| 01:46:58 | * | davidhq quit (Client Quit) |
| 01:48:16 | * | MagusOTB quit (Remote host closed the connection) |
| 01:53:37 | wink-s | I thought the floating point modulo operator was `%` but I'm getting an undeclared identifier, does someone know what it is |
| 01:54:12 | flaviu | .eval echo(342.0 mod 5.0) |
| 01:54:13 | Mimbus | flaviu: eval.nim(3, 11) Error: type mismatch: got (float, float) |
| 01:58:38 | flaviu | .give wink-s import math; echo(342.0 mod 5.0) |
| 01:58:41 | Mimbus | wink-s: 2.0 |
| 02:02:12 | wink-s | txs |
| 02:06:00 | EXetoC | why do we have that distinction again? |
| 02:07:40 | * | darkf joined #nim |
| 02:10:13 | flaviu | EXetoC: Because float mod is importc'd from math.h, while the other moduluses are C builtins. |
| 02:15:55 | * | gsingh93 joined #nim |
| 02:19:50 | flaviu | well, fmod is a builtin too, "operator" might be the better word. |
| 02:21:03 | EXetoC | what about / and div? |
| 02:27:49 | flaviu | EXetoC: I explained why it is what it is, I never said it was good design ;) |
| 02:31:12 | * | rzzz joined #nim |
| 02:32:59 | * | saml_ quit (Read error: Connection reset by peer) |
| 02:43:51 | * | gsingh93 quit (Ping timeout: 256 seconds) |
| 02:54:09 | * | dhasenan_ quit (Ping timeout: 265 seconds) |
| 02:56:40 | * | dhasenan_ joined #nim |
| 02:59:06 | * | gsingh93 joined #nim |
| 03:27:49 | * | Woflox joined #nim |
| 03:34:49 | * | dhasenan_ quit (Ping timeout: 245 seconds) |
| 03:36:03 | * | dhasenan_ joined #nim |
| 03:58:58 | * | k1i quit (Ping timeout: 245 seconds) |
| 03:58:58 | * | k1i joined #nim |
| 04:06:43 | * | mwbrown quit (Ping timeout: 255 seconds) |
| 04:08:19 | * | dhasenan_ quit (Ping timeout: 250 seconds) |
| 04:15:04 | * | gsingh93 quit (Ping timeout: 272 seconds) |
| 04:21:21 | * | dhasenan_ joined #nim |
| 04:30:20 | * | adu_ joined #nim |
| 04:36:10 | * | wink-s quit (Quit: Page closed) |
| 04:37:30 | * | wink-s joined #nim |
| 04:38:32 | * | wink-s quit (Client Quit) |
| 05:11:39 | * | gsingh93 joined #nim |
| 05:12:26 | * | filwit quit (Quit: Leaving) |
| 05:19:17 | * | mal``` joined #nim |
| 05:22:47 | * | Demos quit (Read error: Connection reset by peer) |
| 05:27:22 | * | mal`` quit (Ping timeout: 245 seconds) |
| 05:27:22 | * | k1i quit (Ping timeout: 245 seconds) |
| 05:27:22 | * | pipeep quit (Ping timeout: 245 seconds) |
| 05:27:23 | * | k1i joined #nim |
| 05:28:50 | * | pipeep_ joined #nim |
| 05:32:44 | * | Woflox quit (Ping timeout: 246 seconds) |
| 06:02:36 | * | adu_ quit (Ping timeout: 256 seconds) |
| 06:03:36 | * | dhasenan_ quit (Ping timeout: 252 seconds) |
| 06:06:22 | * | dhasenan_ joined #nim |
| 06:20:34 | * | bcinman quit (Read error: Connection reset by peer) |
| 06:21:11 | * | bcinman joined #nim |
| 06:22:18 | * | rzzz_ joined #nim |
| 06:24:17 | * | rzzz quit (Ping timeout: 256 seconds) |
| 06:24:24 | * | CryptoToad quit (Ping timeout: 265 seconds) |
| 06:26:45 | * | gsingh93 quit (Ping timeout: 264 seconds) |
| 06:27:39 | * | k1i quit (*.net *.split) |
| 06:43:00 | * | k1i joined #nim |
| 07:36:40 | fowl | sup foos and bars |
| 07:37:56 | cazov | fizzing and buzzing |
| 07:38:35 | * | pleiosaur quit (Quit: leaving) |
| 07:43:09 | * | pleiosaur joined #nim |
| 07:58:59 | * | gokr joined #nim |
| 08:02:04 | * | gmpreussner|work quit (Read error: Connection reset by peer) |
| 08:33:10 | * | a5i quit (Quit: Connection closed for inactivity) |
| 08:40:26 | * | rzzz_ quit (Ping timeout: 272 seconds) |
| 08:42:58 | * | TEttinger quit (Ping timeout: 256 seconds) |
| 09:05:54 | * | rzzz joined #nim |
| 09:07:52 | def- | Araq: Should I rename mitems/mpairs/... to items/pairs/... ? Is there a good way to deal with the duplication? |
| 09:11:42 | * | rzzz quit (Ping timeout: 244 seconds) |
| 09:11:48 | * | irrequietus joined #nim |
| 09:12:47 | fowl | def-, that would work now? |
| 09:12:55 | def- | fowl: seems so |
| 09:13:05 | fowl | awesome |
| 09:13:16 | def- | But we have to write the same proc twice basically |
| 09:13:30 | def- | I tried a (B | var B) as the return type but doesn't work unfortunately |
| 09:13:55 | def- | http://forum.nim-lang.org/t/851/3#6457 |
| 09:14:22 | fowl | i dont think auto would catch var either |
| 09:14:58 | def- | right |
| 09:15:17 | fowl | still |
| 09:15:43 | fowl | i've waited for this for years :D |
| 09:35:05 | * | HakanD_ joined #nim |
| 09:38:42 | * | HakanD__ joined #nim |
| 09:41:44 | * | BlaXpirit joined #nim |
| 09:42:18 | * | HakanD_ quit (Ping timeout: 246 seconds) |
| 09:57:10 | * | bcinman quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 10:07:07 | * | davidhq joined #nim |
| 10:07:16 | def- | I tried to make a macro-pragma to fix this, but ran into problems, I guess it's not that easy to copy a proc: https://github.com/Araq/Nim/issues/2384 |
| 10:08:22 | * | rzzz joined #nim |
| 10:12:57 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 10:13:13 | * | rzzz quit (Ping timeout: 256 seconds) |
| 10:14:19 | * | Matthias247 joined #nim |
| 10:18:29 | fowl | def-, it should work as immediate |
| 10:18:38 | def- | ah, good idea! |
| 10:18:47 | fowl | i tested it |
| 10:20:09 | fowl | my idea: i had never seen copynimtree used with sem checked ast, but by printing out treerepr i cant see any difference in the copied tree vs the original |
| 10:20:30 | def- | it's probably a problem with the symbols |
| 10:20:36 | def- | they're resolved already, and can't change this anymore |
| 10:21:35 | fowl | what is changing though |
| 10:22:04 | def- | what do you mean? |
| 10:22:19 | fowl | no symbol is changing |
| 10:22:37 | fowl | i suspect its the symbols too |
| 10:22:44 | def- | But the symbols point to wrong places I guess |
| 10:23:07 | fowl | i have no clue how they work :/ |
| 10:38:15 | * | davidhq joined #nim |
| 10:39:42 | * | davidhq quit (Client Quit) |
| 10:40:25 | * | johnsoft quit (Ping timeout: 256 seconds) |
| 10:41:22 | * | johnsoft joined #nim |
| 10:48:09 | * | davidhq joined #nim |
| 10:48:28 | * | davidhq quit (Client Quit) |
| 11:08:22 | * | phira quit (Ping timeout: 255 seconds) |
| 11:09:02 | * | phira joined #nim |
| 11:09:10 | * | rzzz joined #nim |
| 11:13:38 | * | rzzz quit (Ping timeout: 244 seconds) |
| 11:32:09 | * | Senketsu quit (Ping timeout: 264 seconds) |
| 11:33:30 | BlaXpirit | okaaaaaay |
| 11:33:40 | BlaXpirit | so IntSet seems to be much faster than judy array |
| 11:34:01 | * | Senketsu joined #nim |
| 11:36:20 | BlaXpirit | at least for my purposes (iteration) |
| 11:38:13 | * | Maxdamantus quit (Ping timeout: 256 seconds) |
| 11:41:45 | BlaXpirit | https://gist.github.com/BlaXpirit/7f6c9136ec5ba7e904f9 |
| 11:48:03 | * | davidhq joined #nim |
| 11:49:14 | * | Maxdamantus joined #nim |
| 11:49:27 | def- | BlaXpirit: do you want items ordered or sorted btw? |
| 11:49:34 | BlaXpirit | ? |
| 11:49:48 | def- | in the order you inserted them, or sorted by `<`? |
| 11:49:50 | BlaXpirit | what do you mean "ordered or sorted", isnt it the same? |
| 11:49:53 | BlaXpirit | ah right |
| 11:49:56 | BlaXpirit | i want sorted |
| 11:50:11 | BlaXpirit | judy gives sorted btw, intset is arbitrary |
| 11:50:32 | BlaXpirit | as i understand it, it gives items in the reverse insertion order, grouped by chunks |
| 11:50:43 | def- | then C++'s set doesn't do what you want either, it's ordered, not sorted |
| 11:51:00 | def- | ah, no |
| 11:51:01 | def- | my bad |
| 11:51:22 | BlaXpirit | ye.. |
| 11:51:43 | BlaXpirit | c++'s set is a different beast, not nearly as space efficient |
| 11:51:57 | def- | I'm just confused because Nim's OrderedTable remembers insertion order |
| 11:54:37 | BlaXpirit | it's probably costly to make intset sorted |
| 11:55:01 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 11:55:29 | * | BlaXpirit_ joined #nim |
| 11:55:42 | def- | indeed |
| 11:56:37 | BlaXpirit_ | the question remains how costly and is it worth making an ordered variant (or ordereditems might work( |
| 11:57:05 | def- | you should not call it sorted instead of ordered, otherwise people will be as confused as I was |
| 11:57:37 | BlaXpirit_ | uh |
| 11:57:38 | def- | well, you could just get all items and sort them afterwards |
| 11:58:04 | BlaXpirit_ | copy and sort -_- |
| 12:05:30 | * | kapil___ joined #nim |
| 12:06:26 | * | rzzz joined #nim |
| 12:11:03 | * | rzzz quit (Ping timeout: 246 seconds) |
| 12:11:52 | * | wb joined #nim |
| 12:17:36 | * | davidhq joined #nim |
| 12:48:44 | * | irrequietus quit () |
| 12:59:28 | * | BlaXpirit_ quit (Quit: Quit Konversation) |
| 13:06:24 | * | rzzz joined #nim |
| 13:09:15 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 13:11:09 | * | rzzz quit (Ping timeout: 256 seconds) |
| 13:12:03 | * | BlaXpirit joined #nim |
| 13:18:20 | * | Trustable joined #nim |
| 13:29:59 | * | irrequietus joined #nim |
| 14:05:52 | * | HakanD__ quit (Quit: Be back later ...) |
| 14:06:27 | * | rzzz joined #nim |
| 14:10:47 | * | HakanD__ joined #nim |
| 14:11:05 | * | rzzz quit (Ping timeout: 250 seconds) |
| 14:18:40 | * | darkf quit (Quit: Leaving) |
| 14:25:47 | * | keypusher quit (Remote host closed the connection) |
| 14:26:10 | * | keypusher joined #nim |
| 14:27:51 | * | brononymous joined #nim |
| 14:28:43 | * | Woflox joined #nim |
| 14:34:28 | * | rzzz joined #nim |
| 14:40:32 | * | untitaker quit (Ping timeout: 256 seconds) |
| 14:45:58 | * | untitaker joined #nim |
| 14:52:41 | * | kapil___ quit (Quit: Connection closed for inactivity) |
| 14:57:50 | * | Varriount|Mobile joined #nim |
| 15:00:58 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 15:00:59 | * | Varriount|Mobile quit (Client Quit) |
| 15:12:21 | * | arnetheduck quit (Ping timeout: 264 seconds) |
| 15:12:52 | * | HakanD__ quit (Ping timeout: 252 seconds) |
| 15:25:38 | * | mwbrown joined #nim |
| 15:26:32 | * | brononymous left #nim (#nim) |
| 15:44:32 | * | mwbrown quit (Ping timeout: 246 seconds) |
| 15:57:16 | * | BlaXpirit quit (Remote host closed the connection) |
| 15:59:13 | * | BlaXpirit joined #nim |
| 16:16:00 | * | johnsoft quit (Ping timeout: 265 seconds) |
| 16:16:55 | * | UberLambda joined #nim |
| 16:17:12 | * | johnsoft joined #nim |
| 16:19:20 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 16:28:48 | * | FusionGaming quit (Read error: Connection reset by peer) |
| 16:41:08 | * | rzzz quit (Ping timeout: 272 seconds) |
| 16:55:47 | * | reem quit (Read error: No route to host) |
| 16:58:38 | * | reem joined #nim |
| 17:13:28 | * | HakanD__ joined #nim |
| 17:15:06 | dhasenan | I want to build two targets with nim, and they share most dependencies etc. Is there a way to tell the compiler to build two outputs at once? |
| 17:15:57 | dhasenan | It would save me 5-10 seconds per build, and my project is still pretty small. |
| 17:20:04 | EXetoC | dhasenan: I don't know in what way you expect to reduce the compilation time. unchanged deps are not re-compiled |
| 17:20:19 | * | bcinman joined #nim |
| 17:23:08 | dhasenan | EXetoC: so everyone says, but I'm not believing that. |
| 17:23:27 | flaviu | dhasenan: Measure the compilation time, it's pretty fast. |
| 17:24:11 | EXetoC | dhasenan: I just tested it and what I said is true |
| 17:24:51 | dhasenan | https://gist.github.com/dhasenan/6fff33d7a6da0877cef9 |
| 17:25:07 | dhasenan | 11 seconds, mostly spent recompiling stuff. |
| 17:26:01 | * | davidhq joined #nim |
| 17:26:38 | dhasenan | I'm on the devel branch. |
| 17:26:40 | EXetoC | well, how long did it take when compiled for the first time? |
| 17:27:24 | dhasenan | 14 seconds. |
| 17:27:34 | dhasenan | I somehow doubt, though, that system_hashes changed between compilations. |
| 17:30:41 | dhasenan | I've written a script to check file modification times so it doesn't call the nim compiler at all if no files have changed. |
| 17:31:08 | dhasenan | touch(1)ing one file with no other modification causes a whole bunch of recompilations. |
| 17:31:46 | dhasenan | I'd understand recompiling that file and the files that import it, recursively to the top level. That isn't what's happening. |
| 17:32:05 | dhasenan | I'll bug report it, maybe play around with command line options. |
| 17:38:24 | EXetoC | so the compiler does not compile unchanged modules in some cases at least |
| 17:39:15 | * | _UberLambda_ joined #nim |
| 17:39:23 | EXetoC | how are they compiled? do you have a config? |
| 17:40:12 | * | UberLambda quit (Quit: Leaving the Matrix) |
| 17:40:13 | * | _UberLambda_ quit (Client Quit) |
| 17:40:35 | * | UberLambda joined #nim |
| 17:40:39 | dhasenan | ...I'm not sure what happened, but wiping out my nim cache and reverting some small number of changes seems to have fixed the problem. |
| 17:41:50 | dhasenan | Ah, I see. |
| 17:41:59 | dhasenan | Compiling one target over and over works as expected. |
| 17:42:17 | dhasenan | Compiling two different targets, one after the other, results in recompilation. |
| 17:43:55 | EXetoC | maybe use separate directories. there's also the --nimcache flag |
| 17:44:11 | dhasenan | True. |
| 17:45:29 | EXetoC | how long does it take when recompiling that way? |
| 17:46:08 | * | reem quit (Read error: Connection reset by peer) |
| 17:46:43 | dhasenan | 6.8 seconds. A savings of 5 seconds. |
| 17:46:45 | * | reem joined #nim |
| 17:47:41 | dhasenan | Not fast enough for me to abandon the file modification time portion of my build script, but a considerable savings. |
| 17:48:11 | EXetoC | lower than that would be nice. I'm sure there are hotspots that can be optimized |
| 17:48:49 | dhasenan | I've been running a debug version of the compiler due to occasional crashes, I think. |
| 17:49:24 | * | reem quit (Remote host closed the connection) |
| 17:49:44 | dhasenan | Switching to the release version cuts it down to 1.8 seconds. |
| 17:49:48 | EXetoC | speaking of which, someone claimed that the time taken to compile C++ code is insignificant in the case were templates are used properly, whatever that means. is that really true? C++ code always compiled painfully slow for me |
| 17:51:05 | dhasenan | Are you talking specifically about nim's cpp backend? |
| 17:51:07 | EXetoC | I think there are debug-related flags that slow down the compilation time but aren't of major importance, but I don't think that has been documented |
| 17:51:30 | EXetoC | no the compilation of C++ code |
| 17:52:45 | dhasenan | C++ isn't the easiest thing to parse, but a lot of effort has been spent on the tooling, so it's reasonably fast. |
| 17:53:26 | dhasenan | And most of the "not easy to parse" bits have been passed on to developers rather than the compiler, historically. |
| 17:59:57 | * | rzzz joined #nim |
| 18:04:45 | * | rzzz quit (Ping timeout: 265 seconds) |
| 18:05:39 | def- | dhasenan: i wish there was a way. I needed the same for MAL |
| 18:05:53 | def- | dhasenan: but dead code elimination and conservative recompilation probably get in the way here |
| 18:06:17 | def- | EXetoC, flaviu: sure they're recompiled, check the MAL Nim code |
| 18:09:20 | EXetoC | dead code elimination in debug mode? |
| 18:09:58 | flaviu | dhasenan: You can run a release compiler with checks and stack traces. I personally use ./koch boot -d:useGnuReadline -d:release --stackTrace:on --debuginfo --linedir:on --cc:gcc --linetrace:on |
| 18:10:40 | * | kokozedman quit (Quit: WeeChat 0.3.7) |
| 18:17:02 | * | xxx joined #nim |
| 18:20:12 | * | filwit joined #nim |
| 18:20:13 | def- | EXetoC: release mode for me |
| 18:20:58 | * | HakanD__ quit (Quit: Be back later ...) |
| 18:23:44 | EXetoC | ok well it's rarely needed |
| 18:29:12 | * | Matthias247 joined #nim |
| 18:30:21 | * | gsingh93 joined #nim |
| 18:31:19 | filwit | dom96: I have a 'static/search-help.html' in my nimforums PR: https://github.com/nim-lang/nimforum/pull/51/files .. I'm thinking that must be a mistake (and probably added to the git-ignore list). |
| 18:38:53 | * | HakanD__ joined #nim |
| 18:41:36 | ekarlso | dom96: u up ? |
| 18:42:35 | EXetoC | busy eating pizza probably |
| 18:43:19 | ekarlso | EXetoC: how so ? :p |
| 18:43:58 | EXetoC | I thought that was what he did whenever he wasn't busy writing nim code |
| 18:45:47 | ekarlso | :P |
| 18:52:43 | * | brson joined #nim |
| 18:56:19 | EXetoC | or maybe it was just this one time |
| 19:33:34 | Trustable | Hi guys, I have a problem with Gtk2 signals: When I connect the signal I give a number for "data", but in the callback proc I get another number. Example code: https://gist.github.com/trustable-code/3a6c91ec35e0711e5a55 |
| 19:35:06 | * | rzzz joined #nim |
| 19:44:59 | def- | Trustable: the first argument is a pointer to the window I guess |
| 19:45:05 | def- | Trustable: make your proc take a second argument |
| 19:45:39 | def- | this is the same as in C |
| 19:46:52 | Trustable | def-: this is the solution, thanks :) |
| 19:54:28 | * | wb quit (Ping timeout: 256 seconds) |
| 20:12:22 | * | UberLambda quit (Quit: Leaving the Matrix) |
| 20:12:29 | dom96 | EXetoC: good idea. Time to order pizza! |
| 20:12:34 | dom96 | ekarlso: now I am, what's up? |
| 20:13:39 | cazov | dom96: on the website I noticed that the nav bar when viewing the forums is different from when viewing any of the other sections of the site. someone in here told me to let you know about that. |
| 20:14:15 | dom96 | cazov: Yeah. I think that's fixed already by a PR, just need to deploy it. |
| 20:14:28 | cazov | cool deal :] |
| 20:15:27 | EXetoC | dom96: just omit the dough and complement with some veggies :p |
| 20:15:31 | EXetoC | nim- prefix for all bindings please. that would make it easier to find the gtk library via google for example |
| 20:17:00 | dom96 | EXetoC: you want me to eat a salad? |
| 20:18:30 | EXetoC | 1. consume more micronutrients 2. increase brain power 3. ?????? 4. PROFIT!!!! |
| 20:20:06 | * | wb joined #nim |
| 20:25:34 | Trustable | my code crashes the compiler, my compiler fails to compile a new one and Github servers are so slow... :D |
| 20:28:28 | * | dashed joined #nim |
| 20:33:47 | def- | Trustable: you're only cloning csources with --depth 1 i hope |
| 20:34:08 | * | brson quit (Ping timeout: 256 seconds) |
| 20:35:08 | Trustable | def-: thanks for the tip |
| 20:52:49 | * | gsingh93 quit (Ping timeout: 244 seconds) |
| 20:53:16 | Trustable | ok, I have found a compiler bug: Illegal storage access |
| 20:57:40 | * | gokr quit (Quit: Leaving.) |
| 21:01:46 | Trustable | In case someone is bored and want to read: https://github.com/Araq/Nim/issues/2389 |
| 21:04:37 | fowl | Trustable, known |
| 21:04:55 | Trustable | ok |
| 21:05:01 | fowl | add a MyClassObj type to fix it |
| 21:06:52 | * | davidhq quit (Ping timeout: 255 seconds) |
| 21:07:18 | Trustable | fowl: "var myClassObject: MyClass" does not help |
| 21:08:13 | fowl | thats not a type |
| 21:08:30 | fowl | https://github.com/Araq/Nim/issues/2096 |
| 21:09:06 | def- | https://github.com/Araq/Nim/issues/1658 |
| 21:09:10 | Trustable | I have a workaround so it's ok for me |
| 21:09:12 | def- | High priority since 5 hours ago |
| 21:10:53 | EXetoC | fowl: are there any other mistakes that I often make? I could write something on my other palm too |
| 21:11:09 | * | davidhq joined #nim |
| 21:13:59 | * | reem joined #nim |
| 21:14:10 | fowl | EXetoC, https://www.youtube.com/watch?v=d-_HDcQvnKA |
| 21:15:00 | EXetoC | thanks for the suggestion |
| 21:15:36 | * | Ven joined #nim |
| 21:15:40 | * | reem quit (Remote host closed the connection) |
| 21:16:14 | * | reem joined #nim |
| 21:18:19 | * | reem_ joined #nim |
| 21:20:22 | * | irrequietus_ joined #nim |
| 21:20:43 | * | irrequietus quit (Ping timeout: 244 seconds) |
| 21:21:44 | * | reem quit (Ping timeout: 256 seconds) |
| 21:28:59 | * | rzzz quit (Ping timeout: 246 seconds) |
| 21:39:47 | * | Woflox quit (Ping timeout: 246 seconds) |
| 21:45:48 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 21:46:24 | * | TEttinger joined #nim |
| 21:46:46 | * | reem_ quit (Remote host closed the connection) |
| 21:53:16 | * | wink-s joined #nim |
| 21:53:20 | * | reem joined #nim |
| 21:55:32 | * | rzzz joined #nim |
| 21:55:35 | wink-s | Are the nim irclogs searchable? I want to ask question that's probably been answered and I couldn't find the answer using Google. |
| 21:57:38 | EXetoC | wink-s: "site:irclogs.nim-lang.org <string>"? |
| 21:59:05 | EXetoC | with that said, ask away |
| 21:59:28 | wink-s | txs, let me search firt |
| 21:59:49 | * | rzzz quit (Ping timeout: 245 seconds) |
| 21:59:53 | * | fizzbooze joined #nim |
| 22:01:30 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 22:07:46 | wink-s | So my question was how to create a fixed sized array at runtime? I found a conversation about that in the irclogs (http://irclogs.nim-lang.org/24-07-2014.html) and it implies you have to do use {.unchecked.} very unsatisfactory, I definitely want bounds checking :( |
| 22:08:23 | def- | wink-s: See this thread and Jehan's solution: http://forum.nim-lang.org/t/499 |
| 22:08:52 | def- | But usually what I'd do is use a seq and not resize it |
| 22:24:43 | EXetoC | what about a ref array? but it would be nice to have such a type that also keeps track of the size (a conceptual property) |
| 22:24:55 | wink-s | I realize seq are preferred, right now I just the pegs module. I wanted to parse some command line stuff and after some initial newbie issues it seems to work pretty well. |
| 22:25:07 | EXetoC | in other words, you avoid an if statement when compiled in release mode. it's a tiny optimization though |
| 22:25:47 | EXetoC | wink-s: it does? there are some limitations though |
| 22:26:19 | wink-s | But the Capture object in pegs only allows 20 matches, that seems a very arbitrarily small number. What wasn't seq used for that, I'm guess performance, which is an example why a runtime allocatable fixed length array would be nice. |
| 22:26:29 | EXetoC | the matches come in the form of a flat array, and so it gets hairy when repetitions are involved |
| 22:26:56 | EXetoC | *an array |
| 22:27:01 | EXetoC | rather than a tree |
| 22:27:08 | EXetoC | yes, that too |
| 22:28:22 | wink-s | I know just above 0 about peg and I'm not much better with regex. All I know is that it seem lame to limit matches to 20 items |
| 22:28:23 | * | quartzo joined #nim |
| 22:28:56 | EXetoC | it should be improved at some point. speaking of which, this is pretty neat https://github.com/fowlmouth/glossolalia |
| 22:29:14 | EXetoC | wink-s: yeah |
| 22:29:50 | EXetoC | Araq would rather work with PEG grammars in all cases IIRC, and I can't see why not |
| 22:30:19 | EXetoC | s/PEG grammars/PEGs |
| 22:36:09 | * | TEttinger quit (Ping timeout: 244 seconds) |
| 22:38:17 | flaviu | wink-s: From what I understand, the limited number of elements helps avoid dynamic allocation. |
| 22:39:16 | fowl | wink-s, you would have to write your own bounds checking, you also need to handle refs |
| 22:39:39 | flaviu | The main reason nre is slower than the builtin re is because of the GC pressure it causes, as it always performs an allocation. |
| 22:41:44 | wink-s | I'm suggesting a fixed length array at runtime with bounds checking shouldn't be much slower that a compile time option if you are using a variable to index it. |
| 22:42:10 | wink-s | There should be enough registers in modern computers to keep the length in registers most of the time, I suspect it the performance would be very close to the compile time only arrays. |
| 22:42:13 | * | quartzo quit (Quit: Page closed) |
| 22:43:41 | * | NimBot joined #nim |
| 22:44:04 | wink-s | If I have an array of strings or Objects ... there's going to be lots more allocation associated with managing the strings then the fixed length array. |
| 22:44:43 | wink-s | We're aren't going to change it now, does anyone know if a feature request has been filed? |
| 22:45:27 | fowl | for another array type? |
| 22:45:54 | flaviu | How would you optimize the array of strings? Wouldn't the potential jaggedness cause difficulty? |
| 22:47:38 | fowl | flaviu, what does nre always perform an allocation for? |
| 22:48:02 | flaviu | fowl: seq of slice for the capture bounds. |
| 22:48:29 | BlaXpirit | wait what |
| 22:48:30 | flaviu | It also does allocations when it's asked to actually grab one of the captures. |
| 22:48:37 | BlaXpirit | why does it need to be a seq |
| 22:49:00 | flaviu | because nre has no limit on capture count. |
| 22:49:14 | EXetoC | users should be able to provide their own buffers |
| 22:49:18 | EXetoC | not sure if that's relevant |
| 22:50:08 | flaviu | My goals for nre say that convenience more important than performance. |
| 22:50:57 | wink-s | For grins I was just creating a newCaptures(maxSubpatterns: int) and then found out can't create an array at runtime, which is why I asked the question. |
| 22:51:16 | * | rzzz joined #nim |
| 22:52:10 | fowl | flaviu, in glossolalia no strings are created until they need to be, nothing can be allocated while looking ahead either |
| 22:52:22 | BlaXpirit | oh pcre writes all matches at once into your seq |
| 22:52:24 | EXetoC | .eval echo(new(array[5, int])[].repr) |
| 22:52:26 | BlaXpirit | ok, that makes sense |
| 22:52:26 | Mimbus | EXetoC: [0, 0, 0, 0, 0] |
| 22:52:35 | EXetoC | .eval echo(alloc0(array[5, int])[].repr) |
| 22:52:36 | Mimbus | EXetoC: eval.nim(3, 11) Error: type mismatch: got (typedesc[array[0..4, int]]) |
| 22:53:01 | fowl | .eval echo create(array[5,int]).repr |
| 22:53:02 | Mimbus | fowl: ref 0x7f4cdc631050 --> [0, 0, 0, 0, 0] |
| 22:53:09 | EXetoC | .eval echo(create(array[5, int])[].repr) |
| 22:53:10 | Mimbus | EXetoC: [0, 0, 0, 0, 0] |
| 22:53:12 | EXetoC | right |
| 22:53:15 | flaviu | fowl: Same in nre, but I still need dynamic memory since capture count is not fixed at compile time. |
| 22:53:16 | fowl | that wouldnt be compatible with ref array[1, int] though |
| 22:53:32 | BlaXpirit | flaviu, it theoretically could be though |
| 22:53:53 | EXetoC | flaviu: the user buffer approach would be optional though |
| 22:54:20 | fowl | flaviu, well in glossolalia the capture object if you dont save any "nodes" is just one string, you could use a string grammar and get back a seq[string] though |
| 22:54:24 | EXetoC | a la D buffer interfaces |
| 22:55:05 | flaviu | BlaXpirit: Yes, but no. Can't do FFI in the VM. |
| 22:55:06 | EXetoC | "if input == nil: result = <new buffer>" |
| 22:55:12 | BlaXpirit | flaviu, sure |
| 22:55:51 | fowl | can pegs look backwards? |
| 22:56:52 | flaviu | EXetoC: Maybe, but my excuse is that's exposing implementation details ;) |
| 22:57:19 | flaviu | Note that the size of that vector isn't just captureCount, it's more complex: https://github.com/flaviut/nre/blob/master/src/nre.nim#L309-L311 |
| 23:03:12 | * | wink-s quit (Quit: Page closed) |
| 23:03:58 | EXetoC | it could be made to work with any random-access type, but it's getting quite sophisticated at that point, but there could just be a var parameter |
| 23:07:28 | flaviu | EXetoC: Or I could just tell people to use pcre directly if that want the best possible performance. |
| 23:07:34 | flaviu | *they |
| 23:08:50 | * | rzzz quit (Ping timeout: 256 seconds) |
| 23:19:29 | EXetoC | it's a useful idiom for many things |
| 23:19:36 | * | fizzbooze quit (Ping timeout: 256 seconds) |
| 23:23:35 | dhasenan | Is there a way to import a module named foo.bar from a module named bar? Even with renamed imports, the compiler complains that I'm redefining "bar". |
| 23:25:42 | BlaXpirit | oh boy |
| 23:26:08 | BlaXpirit | strange to me that this is the first time someone runs into this |
| 23:28:46 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 23:28:56 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 23:34:58 | * | rzzz joined #nim |
| 23:36:54 | * | HakanD__ quit (Quit: Be back later ...) |
| 23:39:13 | * | irrequietus_ quit () |
| 23:39:40 | * | irrequietus_ joined #nim |
| 23:40:01 | * | rzzz quit (Ping timeout: 264 seconds) |
| 23:40:23 | * | irrequietus_ is now known as irrequietus |
| 23:40:28 | dhasenan | Hrm, it seems to work in a minimal example on the release branch. |
| 23:40:52 | * | irrequietus is now known as Guest27747 |
| 23:41:06 | * | Guest27747 quit (Client Quit) |
| 23:41:10 | dhasenan | Or rather, it fails in codegen in the release branch. |
| 23:41:44 | * | irrequietus_ joined #nim |