00:09:07 | * | kingofoz quit (Ping timeout: 260 seconds) |
00:09:59 | * | kingofoz joined #nim |
00:11:16 | * | PMunch quit (Ping timeout: 250 seconds) |
00:12:02 | tautologico | is accessing a tuple via [] as efficient as access through field names? |
00:12:55 | tautologico | if there's a difference, which one is faster? |
00:22:42 | * | brson quit (Quit: leaving) |
00:23:01 | * | brson joined #nim |
00:39:48 | * | libman quit (Quit: Leaving.) |
00:39:58 | * | libman joined #nim |
00:43:47 | def- | tautologico: both can be compiled to a constant offset so should be same. you could look at generated C or assembler code if you want to make sure |
00:53:16 | * | der-landgraf quit (Ping timeout: 252 seconds) |
00:56:16 | * | libman quit (Remote host closed the connection) |
00:56:30 | * | der-landgraf joined #nim |
01:01:38 | * | yglukhov quit (Read error: Connection reset by peer) |
01:02:08 | * | yglukhov joined #nim |
01:04:44 | * | yglukhov quit (Read error: Connection reset by peer) |
01:05:08 | * | yglukhov joined #nim |
01:07:10 | * | yglukhov quit (Read error: Connection reset by peer) |
01:07:21 | * | yglukhov joined #nim |
01:10:16 | * | yglukhov quit (Read error: Connection reset by peer) |
01:20:36 | tautologico | def-: thanks, after asking I thought about looking at the generated C code |
01:22:58 | * | yglukhov joined #nim |
01:23:21 | tautologico | for constant indices it is the same |
01:23:36 | tautologico | but it seems I can't index with a variable |
01:25:38 | tautologico | even if I constrain the type of the index variable to be in the range for indices |
01:27:04 | * | brson quit (Quit: leaving) |
01:27:09 | * | yglukhov quit (Ping timeout: 244 seconds) |
01:41:33 | def- | tautologico: yeah, because it's done at compile-time |
01:42:08 | * | der-landgraf quit (Ping timeout: 244 seconds) |
01:42:12 | def- | you could use an array instead and index with enum |
01:50:06 | tautologico | I was defining a 3d vector using an array |
01:50:20 | tautologico | then I can define access via names using templates |
01:51:17 | tautologico | and I can even avoid the need for an if or case by using a range type |
01:51:51 | tautologico | one problem is that UCS kinda gets in the way |
01:52:39 | tautologico | and I don't know if the compiler emits a conversion when indexing by a constant |
01:53:38 | tautologico | I imagine this was probably discussed already, but I think UCS works better with separate namespaces for variables and procs/templates/macros |
01:55:49 | * | bozaloshtsh joined #nim |
01:57:49 | * | der-landgraf joined #nim |
01:58:46 | * | yglukhov joined #nim |
02:03:27 | * | yglukhov quit (Ping timeout: 260 seconds) |
02:33:45 | * | Demos joined #nim |
02:47:31 | Demos | yo why is nimble downloading the package list from irclogs.nim-lang.org? |
04:20:05 | * | yglukhov joined #nim |
04:25:17 | * | yglukhov quit (Ping timeout: 276 seconds) |
04:31:18 | * | cjh` joined #nim |
05:26:59 | * | gokr joined #nim |
05:36:05 | * | GangstaCat joined #nim |
05:53:24 | * | kingofoz quit (Ping timeout: 246 seconds) |
05:53:37 | * | kingofoz joined #nim |
06:14:03 | * | zodiak_ quit (Ping timeout: 246 seconds) |
06:17:58 | * | zodiak joined #nim |
06:19:35 | * | endragor joined #nim |
06:28:13 | * | endragor quit (Remote host closed the connection) |
06:28:45 | * | endragor joined #nim |
06:29:25 | * | GangstaCat quit (Quit: Leaving) |
06:29:56 | * | yglukhov joined #nim |
06:34:35 | * | yglukhov quit (Ping timeout: 260 seconds) |
06:36:33 | * | kingofoz quit (Ping timeout: 240 seconds) |
06:37:16 | * | kingofoz joined #nim |
06:46:58 | * | GangstaCat joined #nim |
06:50:13 | * | themagician quit (Ping timeout: 252 seconds) |
06:56:10 | * | Matthias247 joined #nim |
06:57:50 | * | themagician joined #nim |
07:03:03 | * | autumnl quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
07:11:27 | * | themagician quit (Ping timeout: 260 seconds) |
07:11:52 | * | themagician joined #nim |
07:18:27 | * | themagician quit (Ping timeout: 246 seconds) |
07:19:03 | * | themagician joined #nim |
07:25:28 | * | themagician quit (Ping timeout: 250 seconds) |
07:25:50 | * | themagician joined #nim |
07:27:50 | * | Matthias247 quit (Read error: Connection reset by peer) |
07:32:26 | * | themagician quit (Ping timeout: 244 seconds) |
07:32:50 | * | themagician joined #nim |
07:36:25 | * | Demos quit (Ping timeout: 260 seconds) |
07:39:23 | * | cheatfate_ joined #nim |
07:39:23 | * | cheatfate quit (Read error: Connection reset by peer) |
07:46:19 | * | yglukhov joined #nim |
07:53:45 | * | Trustable joined #nim |
08:05:34 | * | Trustable quit (Remote host closed the connection) |
08:07:02 | * | Trustable joined #nim |
08:07:13 | * | endragor quit (Remote host closed the connection) |
08:23:11 | * | kseg joined #nim |
08:24:00 | * | endragor joined #nim |
08:24:59 | kseg | Is the goal to get async and threads playing nice together? |
08:35:57 | Araq_ | kseg: sure |
08:36:53 | kseg | Araq_: thanks |
08:50:18 | * | themagician quit (Ping timeout: 276 seconds) |
09:03:29 | * | yglukhov_ joined #nim |
09:05:12 | * | yglukhov quit (Ping timeout: 260 seconds) |
09:18:14 | cheatfate_ | Araq_, good morning, is there any progress in stack overflow issue? |
09:19:08 | Araq_ | cheatfate_: there is a crash with my new GC ;-) that I need to fix and then I can merge it, I hope |
09:21:25 | * | yglukhov_ quit (Remote host closed the connection) |
09:23:25 | * | yglukhov joined #nim |
09:33:42 | * | yglukhov quit (Remote host closed the connection) |
09:39:21 | * | Arrrr joined #nim |
09:43:17 | * | kseg quit (Quit: kseg) |
09:43:48 | * | kseg joined #nim |
09:46:00 | cheatfate_ | Araq_, i'm sorry, but i'm very bad with git |
09:46:17 | cheatfate_ | now when i have successfuly changed branch to prim-gc |
09:46:31 | cheatfate_ | i think i have changed... |
09:46:48 | cheatfate_ | and #4160 is still here |
09:47:50 | cheatfate_ | because GC is not a problem for #4160... the problem is in generators mechanic i think |
09:49:10 | * | yglukhov joined #nim |
09:51:19 | cheatfate_ | thats why we trying to avoid it with callSoon |
09:51:28 | * | yglukhov_ joined #nim |
09:53:37 | * | yglukhov quit (Ping timeout: 260 seconds) |
09:53:46 | Araq_ | ah yes, ok, so it's independent of my GC work |
09:54:04 | * | elrood joined #nim |
09:56:40 | * | mal`` quit (Quit: Leaving) |
09:57:13 | cheatfate_ | Araq_, but yesterday you say you check why my last PR automatic check hangs on `twrong_setconstr.nim` |
09:59:18 | Araq_ | that's because I thought my GC is ready for Windows testing. turned out, it's not. sorry. |
10:08:33 | * | kseg quit (Quit: kseg) |
10:09:00 | * | Demos joined #nim |
10:10:26 | cheatfate_ | Araq_, is there simple way to rerun tests? or i need to close this pr and create new one? |
10:10:50 | Araq_ | I think you need to do the latter |
10:11:08 | Araq_ | can you reproduce the hang on your machine? |
10:11:46 | cheatfate_ | Araq_, i will run tests in a minute... |
10:19:45 | * | Demon_Fox quit (Quit: Leaving) |
10:21:18 | * | mal`` joined #nim |
10:23:53 | * | nsf quit (Quit: WeeChat 1.4) |
10:36:46 | yglukhov_ | cheatfate_: just amend with empty commit, and force push. this will bump the tests |
10:37:21 | cheatfate_ | yglukhov_, thanks will do when local testing finishes |
10:43:23 | * | mal`` quit (Quit: Leaving) |
10:56:54 | * | mal`` joined #nim |
11:02:22 | * | robot_ joined #nim |
11:02:44 | * | robot_ quit (Client Quit) |
11:06:47 | * | kingofoz quit (Read error: Connection reset by peer) |
11:07:14 | * | kingofoz joined #nim |
11:43:41 | * | nsf joined #nim |
12:31:17 | * | arnetheduck joined #nim |
12:44:05 | * | SShrike joined #nim |
12:47:02 | * | SShrike quit (Client Quit) |
13:10:16 | * | kulelu88 joined #nim |
13:39:30 | * | kulelu88 quit (Quit: Leaving) |
13:52:44 | * | kingofoz quit (Ping timeout: 276 seconds) |
13:53:00 | * | kingofoz joined #nim |
14:08:49 | * | pregressive joined #nim |
14:51:19 | * | Parashurama joined #nim |
14:53:21 | Parashurama | Araq_: can you look at https://github.com/nim-lang/Nim/pull/4173. |
14:53:27 | Parashurama | Araq_: I wouldn't say it is high priority, but you need to tell me if you see any issue with the modifications. |
14:54:04 | Araq_ | Parashurama: I don't understand why there is a strtod fallback |
14:54:27 | Araq_ | does strtod use bigints in its implementation? |
14:54:30 | Parashurama | Well the issue is for simple floats you can parse them trivially |
14:54:58 | Parashurama | but for some cases they can only be parsed correctly with arbitrary precision |
14:55:12 | Parashurama | due to rounding errors |
14:55:26 | Parashurama | see: http://www.exploringbinary.com/decimal-to-floating-point-needs-arbitrary-precision/ |
14:56:30 | Parashurama | And this would mean a dependancy to bigint or porting 1300 LOC to nim |
14:57:39 | Parashurama | the timings are actually 30-50% faster then previous version in the fast path case and 5% slower in the slow path |
14:59:43 | cheatfate_ | Araq_, my local test run still hangs on twrong_setconstr.nim |
15:00:27 | Parashurama | Araq_: And yes they use a custom implementation with some optimisation , cpython soes the same thing, as do others. http://www.ampl.com/netlib/fp/dtoa.c |
15:00:58 | Araq_ | Parashurama: very well then but if you fallback to strtod how come you don't the locale related workarounds? |
15:01:42 | Parashurama | It is explained in the PR, I transform the float to INTEGER x 10^EXPONENT, |
15:02:33 | Parashurama | Araq_: and pass it to strtod |
15:02:51 | Araq_ | ah yeah, ok |
15:04:05 | Parashurama | I'm not saying it is perfect, but i think it is good enough for now. The correction algorithms are quite complexes and there are *many* ways to get it wrong. |
15:05:05 | Araq_ | hmmm so ... I can construct malicious input |
15:05:31 | Araq_ | floating point numbers that produce very large bignums so the server eats up its memory? |
15:05:59 | Araq_ | I think I take the 'wrong' floating point values instead, thanks ;-) |
15:06:29 | Parashurama | Araq_: It is the case with all correct implementation, but ours skip character after 496 chars |
15:06:36 | Araq_ | has anybody ever thougth about strtod taking an arbitrary amount of memory to do its job? |
15:06:51 | Araq_ | *thought |
15:07:11 | Parashurama | Araq_: for efficiency reasons |
15:07:24 | Parashurama | Araq_: array is statically allocated |
15:07:45 | Araq_ | Parashurama: you mean in strtod's implementation? |
15:08:06 | Parashurama | Araq_: no inside our nimparseBiggestFloat |
15:08:23 | Araq_ | I know, I wonder about strtod |
15:09:14 | Parashurama | Araq_: I know python keeps a freelist of Bignum up to 1024 digits i think, so it can use quite a bit of memory |
15:10:59 | pigmej | Parashurama: less than 1024 |
15:11:08 | pigmej | and also not python, but cpython :) |
15:11:55 | Parashurama | pigmej: yes, but tey often are the same (although less and less with pypy) |
15:18:57 | Parashurama | Araq_: The one thing it is missing is a good test suite. The test compiles OK and the corner case floats are passed to strtod. |
15:19:38 | Parashurama | Araq_: It would be so much easier if we had a quickcheck/hypothesis property based testing. |
15:19:52 | Araq_ | Parashurama: we have floating point tests in the testsuite |
15:21:33 | Parashurama | Araq_: Yes, i saw them, but they still fairly basic. I tried to lift the tests from cpython, but i couldn't quite managed to make into clean nim code. |
15:22:09 | Parashurama | Araq_: i wasn't sure how they were licenced, and if they were compatible with nim licence |
15:23:33 | Parashurama | Admittedly I think property based testing is far more important for dynamic languages. |
15:26:46 | Araq_ | I don't really understand you. you have pairs (input, expectedOutput), you iterate over these pairs and check f(input) == expectedOutput. well ok, in this case it's more complex since you cannot trust the Nim compiler to read in the expected floats properly since Nim uses Nim's stdlib to parse it, but you can always use strtod("2.3") |
15:27:01 | Araq_ | and rely on strtod's implementation to be reasonably bugfree. |
15:27:22 | Araq_ | I don't know what "property based testing" means though. |
15:29:54 | Parashurama | Araq_: basically instead of testing with sopecific values: you set the kind of values you want for testing ie for float: allow_nan, allow_zero, allow_inf negative and it generate random values for you. |
15:30:01 | Parashurama | see: a python impl: http://hypothesis.works/ |
15:32:13 | Parashurama | Araq_: for the strtod("2.3"), thats how i tested it actually after a few iterations in seperate project. |
15:32:48 | Parashurama | to make sure i was actually comparing to a correct float. |
15:51:04 | * | Parashurama quit (Quit: ChatZilla 0.9.92 [Firefox 46.0/20160425115046]) |
16:09:47 | endragor | Does .importcpp pattern language allow referring arguments by their numbers? |
16:18:04 | * | Sembei joined #nim |
16:21:33 | * | arnetheduck quit (Ping timeout: 240 seconds) |
16:45:52 | * | Sembei quit (Ping timeout: 252 seconds) |
16:48:50 | * | yglukhov_ quit (Ping timeout: 260 seconds) |
16:51:02 | * | Sembei joined #nim |
16:53:34 | cheatfate_ | dom96, for some reason my `callSoon` PR (https://github.com/nim-lang/Nim/pull/4172) hangs test `twrong_setconstr.nim`... and i really dont understand why... my local linux tests also hangs on this test |
17:10:58 | dom96 | cheatfate_: does it work in devel? |
17:11:57 | cheatfate_ | dom96, please dont merge because i think there can be problems with next PRs i think |
17:13:30 | dom96 | of course, I won't. |
17:13:51 | dom96 | Maybe you've branched off a commit which has that problem? |
17:14:12 | dom96 | Maybe you could run 'git pull' then 'git merge devel' in your branch? |
17:15:55 | cheatfate_ | dom96, to be sure i didn't break anything i have cloned latest Nim and then just replaced 3 files... (asyncdispatch.nim and 2 test files we patched) and then run tests |
17:16:07 | cheatfate_ | and it hangs... |
17:17:25 | dom96 | have you tried without replacing the 3 files? |
17:18:29 | cheatfate_ | dom96, yeah tests running smoothly |
17:21:24 | dom96 | cheatfate_: try removing that test |
17:26:14 | * | autumnl joined #nim |
17:29:25 | cheatfate_ | dom96, for some reason now it hangs on `PASS: twrong_discriminant_check.nim` |
17:29:29 | cheatfate_ | one test before... |
17:30:22 | dom96 | Do you get a stack trace when you terminate it? |
17:30:29 | * | yglukhov joined #nim |
17:30:44 | dom96 | One possible problem might be that async is now leaking file descriptors |
17:30:57 | dom96 | causing the other tests to run out and hang |
17:31:02 | dom96 | maybe |
17:34:49 | * | yglukhov quit (Ping timeout: 260 seconds) |
17:38:49 | cheatfate_ | dom96, testament not closing file descriptors? |
17:43:42 | zodiak | stupid question. I used to do doing scanf/sprintf to enfore the 4 characters of precision in the float.. is there a more "nim-style" way to do this ? |
17:43:55 | Demos | formatFlot |
17:43:57 | * | yglukhov joined #nim |
17:43:58 | Demos | I think |
17:44:18 | * | Demos quit (Quit: Leaving) |
17:44:23 | zodiak | awesome possum.. let me google for that :) |
17:44:47 | * | Sembei quit (Ping timeout: 276 seconds) |
18:02:10 | * | shodan45 joined #nim |
18:12:46 | * | kingofoz quit (Ping timeout: 252 seconds) |
18:13:19 | * | kingofoz joined #nim |
18:19:54 | * | libman joined #nim |
18:25:07 | * | themagician joined #nim |
18:32:21 | * | bozaloshtsh quit (Changing host) |
18:32:21 | * | bozaloshtsh joined #nim |
19:02:21 | * | fastrom joined #nim |
19:02:54 | * | gokr quit (Ping timeout: 260 seconds) |
19:29:42 | * | endragor_ joined #nim |
19:30:36 | * | Arrrr quit (Quit: WeeChat 1.4) |
19:33:49 | * | endragor quit (Ping timeout: 260 seconds) |
19:34:24 | * | endragor_ quit (Ping timeout: 260 seconds) |
19:39:08 | * | Ven joined #nim |
20:01:10 | * | yglukhov quit (Read error: Connection reset by peer) |
20:01:46 | * | yglukhov joined #nim |
20:14:31 | * | gokr joined #nim |
20:17:26 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
20:21:57 | * | fastrom quit (Quit: Leaving.) |
20:32:44 | * | fastrom joined #nim |
20:33:11 | * | yglukhov quit (Remote host closed the connection) |
20:49:06 | * | yglukhov joined #nim |
20:57:44 | * | Ven joined #nim |
21:08:24 | * | Matthias247 joined #nim |
21:19:39 | * | cheatfate_ is now known as cheatfate |
21:21:40 | * | enquora joined #nim |
21:23:42 | * | fastrom quit (Quit: Leaving.) |
21:28:13 | cheatfate | dom96, i have found problematic test |
21:28:27 | dom96 | awesome, what is it? |
21:28:58 | cheatfate | https://github.com/nim-lang/Nim/blob/devel/tests/ccgbugs/twrong_string_asgn.nim |
21:29:24 | cheatfate | its just testament bug it needs to flush stdout... this test hangs |
21:30:15 | dom96 | why didn't it happen before your changes then? |
21:33:16 | cheatfate | if you check my PR automatic tests you will never see this test... because testament binary not flushing stdout so it hungs on this test before showing it to user... |
21:35:40 | * | pregressive quit (Remote host closed the connection) |
21:43:56 | Araq_ | cheatfate: so it's a test your new async code breaks? |
21:44:15 | Araq_ | and thus we didn't notice the testament bug before? |
21:46:35 | cheatfate | Araq_, yep it breaks this test just because we found only one way to break `deep recursion` is to enqueue `immediate completed` futures... |
21:47:01 | cheatfate | and we dispatching callbacks in poll() function |
21:47:58 | cheatfate | There was 3 tests which are not using poll() at all, so me and dom96 patched them all |
21:48:43 | Araq_ | great. :-) |
21:49:49 | cheatfate | About testament, when particular test hangs... you will never know exact name of this test |
21:50:16 | cheatfate | just because testament will never show you `PASS: sometestname.nim` |
21:51:07 | Araq_ | it does show this with --verbose or something |
21:51:13 | Araq_ | iirc. |
21:58:58 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
22:01:34 | * | yglukhov quit (Read error: Connection reset by peer) |
22:01:59 | * | yglukhov joined #nim |
22:02:03 | * | jeffc_ joined #nim |
22:03:07 | dom96 | I'm still not sure why it hangs it now |
22:03:10 | dom96 | but it didn't before |
22:03:17 | dom96 | how did the change expose this testament bug? |
22:03:46 | cheatfate | dom96, you can look at new PR now |
22:03:57 | * | jeffc quit (Ping timeout: 260 seconds) |
22:04:04 | cheatfate | https://github.com/nim-lang/Nim/pull/4180 |
22:04:40 | cheatfate | and check my modifications to twrong_string_asgn.nim |
22:05:03 | dom96 | still don't understand it |
22:05:25 | dom96 | oh wait |
22:05:34 | dom96 | I see, the future never finishes |
22:06:08 | dom96 | but then how is this a testament bug? |
22:07:10 | cheatfate | its not a bug really... just if testament hangs you need to check not latest `PASS: sometest.nim` but look at next test if you know what test is next :) |
22:08:35 | dom96 | ahh |
22:09:10 | * | yglukhov quit (Read error: Connection reset by peer) |
22:09:12 | dom96 | testament should show "Running: blah.nim" |
22:09:20 | dom96 | then change it to "PASS: blah.nim" |
22:09:20 | * | yglukhov joined #nim |
22:09:38 | dom96 | but that requires command line magic |
22:11:41 | cheatfate | dom96, yeah with colors :) |
22:17:55 | cheatfate | yeah... all tests passed |
22:21:55 | * | elrood quit (Quit: Leaving) |
22:22:12 | Araq_ | dom96: it used to show that, at least |
22:23:01 | * | gokr quit (Ping timeout: 252 seconds) |
22:24:07 | * | Matthias247 quit (Read error: Connection reset by peer) |
22:38:57 | * | Trustable quit (Remote host closed the connection) |
22:49:38 | * | PMunch joined #nim |
23:07:23 | * | shodan45 quit (Quit: Konversation terminated!) |
23:10:57 | * | kseg joined #nim |
23:13:38 | * | saml_ joined #nim |
23:16:47 | * | enquora quit (Quit: enquora) |
23:28:25 | cheatfate | Araq_, i think we need a place to write Known bugs and limitation :) |
23:28:33 | cheatfate | limitations :) |
23:32:53 | Araq_ | I thought we have an issue tracker for that |
23:33:46 | * | space-wizard joined #nim |
23:36:12 | cheatfate | yeah, but we have too many issues and i think like half of them are duplicates... like this one https://github.com/nim-lang/Nim/issues/4178 |
23:39:37 | * | bozaloshtsh quit (Ping timeout: 260 seconds) |
23:41:34 | * | yglukhov quit (Remote host closed the connection) |
23:45:16 | * | bozaloshtsh joined #nim |
23:48:28 | dom96 | plenty of projects with far more issues :) |
23:54:49 | cheatfate | dom96, its not about issues count, its just to simplify work on processing issues |
23:54:53 | * | |2701 joined #nim |