<< 15-05-2018 >>
00:00:32FromGitter<data-man> @Araq: https://github.com/miloyip/nativejson-benchmark
00:01:10Araqno. not parsing json.
00:01:18Araqdoing something with the json.
00:02:31*gokr joined #nim
00:17:38*jrbrt quit (Quit: jrbrt)
00:18:07dom96Araq: https://github.com/kostya/benchmarks#json
00:18:10dom96This is the classic
00:31:43*vivus joined #nim
00:38:34*ahmed___ joined #nim
00:40:44FromGitter<navicstein_twitter> Hi, all?
00:43:03FromGitter<Quelklef> howdy
00:43:58FromGitter<navicstein_twitter> so nice to be reaching here at this time from nigeria :)
00:55:39*cspar_ quit (Ping timeout: 260 seconds)
01:02:26*cspar_ joined #nim
01:03:42*xkapastel quit (Quit: Connection closed for inactivity)
01:14:58*gokr quit (Ping timeout: 256 seconds)
01:33:05FromDiscord<NotoriousRebel> Has anyone used nim for cybersecurity?
01:45:39skrylarin what way
01:46:54skrylarfor white hat stuff i don't see a problem, you get all the usual C stuff plus some convenience. for black hat its probably not great because the GC and nim_ symbols aren't populous enough in the wild, so antivirus could just assume all 'nim' is a virus
01:48:49*Lord_Nightmare quit (Ping timeout: 248 seconds)
01:49:18*Lord_Nightmare joined #nim
02:27:57*vivus quit (Ping timeout: 255 seconds)
02:40:25*vivus joined #nim
02:51:50*m712 joined #nim
03:00:27*SenasOzys__ quit (Ping timeout: 240 seconds)
03:05:06*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
03:19:13*dddddd quit (Remote host closed the connection)
03:20:27*endragor joined #nim
03:30:14*skrylar quit (Ping timeout: 276 seconds)
03:32:59*endragor quit (Ping timeout: 265 seconds)
03:40:45*vivus quit (Quit: Leaving)
03:47:08*darithorn joined #nim
03:49:20*skrylar joined #nim
04:05:14*leorize quit (Ping timeout: 260 seconds)
04:29:26*nolanv quit (Read error: Connection reset by peer)
04:36:45*nolanv joined #nim
04:46:22*couven92 joined #nim
04:52:13*cspar_ quit (Read error: Connection reset by peer)
04:52:38*cspar_ joined #nim
05:00:04*cspar_ quit (Ping timeout: 260 seconds)
05:08:12*CodeVance joined #nim
05:09:41*skrylar quit (Remote host closed the connection)
05:25:53*miran joined #nim
05:28:10*leorize joined #nim
05:34:13*darithorn quit (Quit: Leaving)
05:36:26*nsf joined #nim
05:54:43*ftsf quit (Remote host closed the connection)
05:55:11*ftsf joined #nim
05:57:25*leorize quit (Ping timeout: 256 seconds)
06:15:36*leorize joined #nim
06:20:58*xkapastel joined #nim
06:24:37*miran quit (Ping timeout: 256 seconds)
06:25:26*skrylar joined #nim
06:26:22*skrylar quit (Client Quit)
06:27:50FromGitter<survivorm> @dom96 Ping. Then you're available, please pong me.
06:29:23*leorize quit (Ping timeout: 255 seconds)
06:29:57*leorize joined #nim
06:50:23*Ven`` joined #nim
06:54:57*Ven`` quit (Ping timeout: 248 seconds)
06:56:08*Ven`` joined #nim
06:58:38*Ven`` quit (Client Quit)
07:04:06*yglukhov_ joined #nim
07:04:28*Ven`` joined #nim
07:05:39*yglukhov quit (Ping timeout: 265 seconds)
07:31:44*gokr joined #nim
07:39:23*Ven` joined #nim
07:39:23*Ven`` quit (Read error: Connection reset by peer)
07:41:11*floppydh joined #nim
07:43:35*PMunch joined #nim
07:51:37*arecaceae quit (Read error: Connection reset by peer)
07:52:00*arecaceae joined #nim
07:56:03*jjido joined #nim
07:56:59*yglukhov_ quit (Read error: Connection reset by peer)
07:57:30*yglukhov joined #nim
07:57:33*byte512 quit (Ping timeout: 256 seconds)
08:02:20*ftsf quit (Quit: Leaving)
08:03:30*byte512 joined #nim
08:03:57*gmpreussner quit (Ping timeout: 264 seconds)
08:05:37PMunchHmm, Error: template instantiation too nested, try --evalTemplateLimit:N, but when I try that switch I get an error that it doesn't exist..
08:05:42*gmpreussner joined #nim
08:08:33*thor77 quit (Quit: ZNC 1.7.0 - https://znc.in)
08:08:59*thor77 joined #nim
08:09:32*gokr quit (Ping timeout: 260 seconds)
08:10:27PMunchUhm dom96: http://ix.io/1amF/
08:13:51*byte512 quit (Ping timeout: 240 seconds)
08:16:04*SenasOzys joined #nim
08:20:47*jjido quit (Ping timeout: 256 seconds)
08:26:35*byte512 joined #nim
08:27:52*SenasOzys quit (Remote host closed the connection)
08:28:39*SenasOzys joined #nim
08:29:16PMunchNice I managed to get Nim's score in completely-unscientific-benchmarks down to below the shared and unique pointer C++ versions
08:29:59*xkapastel quit (Quit: Connection closed for inactivity)
08:30:23PMunch0.282s for Nim, vs 0.249 for C++ raw pointers, 0.394 for C++ shared pointers, and 0.337 for C++ unique pointers
08:31:06PMunchMemory usage is still slightly higher though at 890KiB vs. 520Kib
08:32:53livcdPMunch: you made me smile good job :D
08:33:40PMunchDown to 0.278 now :)
08:33:50PMunchThis is averaged over 101 runs by the way
08:34:06PMunchWell it was mratsim who had the noInit trick
08:34:11PMunchThat makes a huge difference
08:34:15*byte512 quit (Ping timeout: 255 seconds)
08:34:29PMunchI've only been messing about with templates and such
08:35:33*byte512 joined #nim
08:35:49livcddid you already send a PR ?
08:35:55PMunchNope
08:36:23*SenasOzys quit (Ping timeout: 276 seconds)
08:37:49livcdD is alslo quite "competitive"
08:46:30*Ven` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:48:44FromGitter<narimiran> @PMunch but that result is only on nim devel, right? because OP said he will continue to use stable, IIRC
08:48:44*EastByte quit (Ping timeout: 276 seconds)
08:50:09*sendell joined #nim
08:51:17PMunchYeah, it's only devel :(
08:54:31*nolanv quit (Read error: Connection reset by peer)
09:01:23FromGitter<mratsim> @skrylar Tacotron?
09:01:27*nolanv joined #nim
09:01:50FromGitter<mratsim> @miran @pmunch, it should work on 0.17.2 as well.
09:02:11PMunchHmm, interesting
09:02:21PMunchOh well, lunch
09:02:38FromGitter<mratsim> it’s just that there was also a 30% improvement between 0.17.2 and now that is also hidden by this perf regression
09:03:11FromGitter<mratsim> But well as Araq said, we should probably fix the need of noInit for ref type altogether
09:03:22*EastByte joined #nim
09:07:23FromGitter<narimiran> @mratsim re: it should work on 0.17.2 --> does it work on 0.18.0? https://github.com/frol/completely-unscientific-benchmarks/pull/17#issuecomment-388947703
09:10:18FromGitter<mratsim> the regression is in 0.18.0
09:13:45FromGitter<narimiran> hopefully we'll get 0.18.2/0.19 soon.... maybe when araq-big-refactoring is merged :)
09:17:24*Ven`` joined #nim
09:21:25*yglukhov quit (Ping timeout: 256 seconds)
09:22:16*yglukhov joined #nim
09:25:59FromGitter<mratsim> big refactoring would not be 0.18.2, even now with the not nil change I think next version should be 0.19.0
09:26:42FromGitter<mratsim> but I’d like to tackle the {.noInit.} thing so that be default ref types are not producing so many genericResets
09:28:49FromGitter<narimiran> that would be great!
09:29:09FromGitter<mratsim> I’m so in the dark with the compiler and the effect of such changes though =)
09:29:59FromGitter<mratsim> And I don’t see how to design a test that would catch “genericReset"
09:30:55FromGitter<narimiran> argh, i can't name my variable `u'` nor `u_` :(
09:31:17*xet7 joined #nim
09:31:59FromGitter<narimiran> (i need this to differentiate `u(at time t=n)` and `u(at time t=n+1)`)
09:32:11*cspar joined #nim
09:32:32*yglukhov quit (Ping timeout: 255 seconds)
09:33:21FromGitter<mratsim> u and u1
09:34:25FromGitter<mratsim> or u and nu (new u) or u and up ...
09:35:43FromGitter<narimiran> yeah, it will be something like that.... unneeded complications/unreadability
09:36:08FromGitter<mratsim> or u and v?
09:36:19FromGitter<mratsim> (I have the same issue for recurrent neural net)
09:37:00FromGitter<narimiran> eh, `v` is something else. i will keep `u`, and then figure out some suffic
09:37:01PMunchWoo, 0.237, faster than C++ raw pointers :)
09:37:04FromGitter<narimiran> *suffix
09:41:52*yglukhov joined #nim
09:43:51livcdPMunch: with devel ?
09:49:02livcdah i cant find the fs monitor pkg that worked with windows as well :/
09:50:55PMunchYeah, with devel
09:52:32PMunchOr 0.17.2, just tested and got 0.234 there
09:54:25FromGitter<survivorm> @narimiran why are you against u1 or u_1?
09:54:51FromGitter<survivorm> that's somethat common shorthand
09:55:19FromGitter<survivorm> or, more clear will be un and un1
09:55:42sendellactually i think "u_" is valid, it's just that its the same as "u"
09:55:57FromGitter<survivorm> yeah, think so too
09:56:32*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:56:44FromGitter<survivorm> IIRC _ is a almost meaningless symbol at nim var names/int values
09:58:32FromGitter<narimiran> @survivorm because it is IMO unneeded noise, and i'm used to the `foo_` to represent "post-value" (e.g. in scikit-learn)
09:59:29FromGitter<survivorm> unfortunately, this is "not nim way" if i'm correct :)
09:59:39PMunchHmm, but memory usage is must higher in 0.17.2
10:00:12FromGitter<narimiran> yep, it isn't, i guess because of that "style doesn't matter" where `foo_bar` is the same as `foobar` and `fOoBaR`
10:00:20FromGitter<survivorm> and the difference very slight between `_` and `1` ;)
10:00:46FromGitter<survivorm> i mean the noise difference
10:00:54sendellyeah I also feel that the case insensitive and underscore insensitive rules for symbol names is weird
10:01:28FromGitter<narimiran> @survivorm it is huge when you also unpack some vector to its components and you have u0, u1, u2, and then u01, u11. u21
10:01:43sendellbut probably here to stay for a long time since it would break everything to remove it :p
10:01:51FromGitter<narimiran> or is that u10, u11, u12? :P
10:02:37FromGitter<survivorm> Pray for you don't unpack more-dimensional array :)
10:02:49*leorize quit (Ping timeout: 260 seconds)
10:03:10FromGitter<survivorm> cause that may be u1_1_1, u_1_2_1, ...
10:03:20FromGitter<narimiran> maybe, like there is first-letter sensitivity, there should be last-symbol sensitivity too?
10:03:42FromGitter<survivorm> Edge cases?
10:03:59FromGitter<survivorm> I don't think it's a great idea
10:04:10FromGitter<narimiran> then add second-letter sensitivity, third-letter sensitivity, etc. :D :D
10:09:56livcdhmm i cant really serch irc logs here right ?
10:11:46FromGitter<krux02> well there are ire logs
10:11:52PMunchirclogs.nim-lang.org
10:14:04FromGitter<mratsim> I’m with miran here, I don’t like ‘ but a non-noisy postfix symbol like `’` or `_` would be awesome for maths/statistics/machine learning
10:15:00FromGitter<mratsim> actually `'` is better than `_` because `’'` is more readable than `__`
10:15:28FromGitter<narimiran> `'` also doesn't work in python as a suffix
10:16:31FromGitter<narimiran> btw @mratsim, you have some kind of autocorrect which turns `'` into `’` - that's why some of your examples didn't work the other day (i don't know if you recall)
10:16:58FromGitter<mratsim> MacOS with French keyboards layout tries to be clever.
10:18:20FromGitter<mratsim> next time I’ll buy one with a Swiss keyboard >_>
10:23:52PMunchmratsim, I created a PR in your fork so you can create one PR with all changes when a new Nim version hits
10:26:02PMunchI agree that suffixes would be cool in Nim
10:26:05FromGitter<krux02> I don't like symbols like '`’´
10:26:16FromGitter<krux02> they are weird
10:26:29FromGitter<krux02> but I would like unicode symbols
10:26:35FromGitter<narimiran> @krux02 so `_` is ok? :)
10:26:40FromGitter<krux02> no
10:26:51FromGitter<narimiran> too late :P
10:26:55PMunchvar u👑 = 100
10:27:13FromGitter<krux02> `_` is ok as the sink symbols
10:27:27FromGitter<krux02> let *,a,* = extractSomething
10:28:10FromGitter<krux02> with unicode I mean letters
10:28:16FromGitter<krux02> λ-expressions
10:28:24FromGitter<krux02> μm
10:28:27FromGitter<mratsim> miran, u and ù ;)
10:28:33FromGitter<krux02> yes
10:28:33FromGitter<narimiran> julia has a possibility where you start typing `\the`, you press tab, it autocompletes to `\theta`, one tab more and you get `θ`
10:29:07FromGitter<mratsim> yeah they took LaTeX symbol declaration for that.
10:29:08FromGitter<narimiran> the same with other greek letters
10:29:31*noonien joined #nim
10:29:37FromGitter<narimiran> they also have `∑` when you type `\sum`, etc.
10:29:42FromGitter<mratsim> I wonder if you can do u_{t} and u_{t+1} for super/under positioning
10:29:54FromGitter<krux02> I just type Σ to get Σ
10:30:04FromGitter<mratsim> u\_{t} and u\_{t+1}
10:30:21FromGitter<krux02> it's the keyboard layout that does it for me
10:30:34FromGitter<krux02> ¬∨∧
10:31:01FromGitter<krux02> no super und under positioning sucks
10:31:04FromGitter<krux02> unreadable
10:31:07FromGitter<krux02> too small
10:31:26FromGitter<chartera> hello, i want to learn more about the asyncdispatch module. i see there ⏎ a Callback type (i.e. proc addEvent(ev: AsyncEvent; cb: Callback) {..}) without explanation . Is there more to know about ? THX
10:51:12PMunchCallback is just a proc, see the first example in the asyncdispatch module documentation
10:54:25*gokr joined #nim
10:55:39PMunchhttps://github.com/nim-lang/Nim/blob/99ae9269f0163e79e3a20a92f872c327d681cf30/lib/pure/asyncdispatch.nim#L240
10:55:49PMunchThat's the definition @chartera ^
10:56:39PMunchFeast your eyes on this: https://i.imgur.com/8Wg5D81.png
10:57:15PMunchMost of the Nim GCs are faster than the C++ raw pointer implementation :)
11:00:09enthus1astif a package is linked with "nimble develop" the vscode "jump to definition" jumps to the old implementation
11:00:40enthus1asti like nimble but developing with it sometimes is annoying
11:02:32FromGitter<narimiran> @PMunch: very nice! btw, which is the default version?
11:07:59*nolanv quit (Read error: Connection reset by peer)
11:10:00*Ven`` joined #nim
11:14:54dom96enthus1ast: In what way is that Nimble's fault? :)
11:14:55*nolanv joined #nim
11:23:09enthus1asti am not complaining too much dom96 ;) `nimble develop` helped a lot already, but i sometimes wich that nimble would be more like git
11:24:16enthus1astand i maybe dont see the whole picture
11:26:06dom96more like git? how?
11:26:14FromGitter<survivorm> @dom96 What's with my PR's on times.nim? They're awaiting for your reactions for several days ⏎ https://github.com/nim-lang/Nim/pull/7664 ⏎ https://github.com/nim-lang/Nim/pull/7806
11:26:43*FuntDobra joined #nim
11:26:51dom96yay for GitHub unicorn
11:27:13FromGitter<survivorm> @krux02 No unicode code symbols, please
11:27:15dom96I'm busy with the forum right now so don't have time for PRs. I've pretty much given my opinions in there anyway though.
11:27:32*Ven`` quit (Read error: Connection reset by peer)
11:27:39*Ven` joined #nim
11:27:56FromGitter<survivorm> Thanks, but there've been some important changes
11:28:16FromGitter<survivorm> I'll wait till you're more free
11:30:32FromGitter<survivorm> Personally, i'm for @mratsim 's definitions with u_{n} and u_{n+1} which are MUCH clearer and are always displayed (and understood) the same
11:32:06PMunchnarimiran, the default is refc I believe
11:37:33*FuntDobra quit (Ping timeout: 264 seconds)
11:38:04FromGitter<mratsim> well with noInit the GC is never called because memory is never released i think :P
11:39:36*Vladar joined #nim
11:40:17PMunchThat's not true, if you look at how much memory `none` uses it's way more than `refc`
11:40:26PMunchSo it is definitely releasing memory at some point
11:40:32FromGitter<mratsim> interesting.
11:41:19*leorize joined #nim
11:42:59FromGitter<mratsim> anyway in my experience the Nim default GC is working very well, but I guess a blog post about how Nim GC is faster than raw C++ is needed ;)
11:43:14*FuntDobra joined #nim
11:56:26sendellhow is that even possible? better allocation times?
11:57:30PMunchI think it's because I used templates instead of procs
11:57:39PMunchMeaning that you avoid the overhead of calling
11:58:07PMunchBut it's interesting to see that the overhead of the GC is so negligible :)
12:00:10sendellhehe sure :)
12:00:30sendellwhat version of the GC are you talking about though?
12:01:11PMunchWell, markAndSweep seems to perform extremely well
12:01:37sendelloh right just saw your graph
12:02:36leorizehi, anyone knows what is the difference between --gc:regions vs the default gc?
12:06:10*CodeVance quit (Read error: Connection reset by peer)
12:06:20*Ven` quit (Ping timeout: 276 seconds)
12:07:20*Ven`` joined #nim
12:07:29*CodeVance joined #nim
12:11:19PMunchRe-ran my tests with --passC:-flto (since the C++ results had it and it seemed like markAndSweep got a bost from it)
12:11:21PMunchhttps://i.imgur.com/4xRFdjV.png
12:11:33PMunchSorted by memory usage: https://i.imgur.com/H6aD2g4.png
12:12:01PMunchrefc somehow manages to use less memory than the C++ versions, but it's quite a bit slower
12:15:00PMunchstack, regions, and none basically don't clean up their memory for some reason (well none is obvious). Apart from those markAndSweep is the fastest, followed by boehm, then C++ raw pointers. Refc unfortunately comes in last on speed, although it's not slow per se.
12:15:54PMunchConsidering how much memory boehm appears to use, markAndSweep comes in as a good overall balance in this case.
12:16:12PMunchSame testing methodology as yesterday, averaged over 101 runs
12:18:36Araqthat matches my benchmarking experience too
12:18:44FromGitter<survivorm> Interesting. And what's the test itself?
12:18:49Araqalso, try the minimum instead of the average and see if it makes a difference
12:19:38*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:21:08PMunchsurvivorm, this is the benchmark: https://github.com/frol/completely-unscientific-benchmarks
12:22:37PMunchUgh, then I have to recalculate all of them :P
12:23:08PMunchDid markAndSweep and C++ raw pointers
12:23:37PMunchmarkAndSweep still wins with 0.217 over C++ with 0.235
12:24:20YardanicoPMunch, on devel?
12:24:31PMunchYes
12:24:43PMunchInteresting boehm has a lower minimum, 0.213
12:25:02PMunchErr 0.219 for markAndSweep
12:25:05Yardanicoresults in the repo are worse because of a regression in nim
12:25:08Yardanico0.18.0
12:25:45PMunchLowest for refc is 0.384
12:25:50PMunchYardanico, yeah I know..
12:26:06PMunchI get the same speeds running on 0.17.2, but then it uses 5MiB of memory..
12:27:51PMunchWhen next version drops we'll show them :P
12:29:51*Ven`` joined #nim
12:32:44*FuntDobra_ joined #nim
12:35:13*FuntDobra quit (Ping timeout: 248 seconds)
12:35:39*Snircle joined #nim
12:36:50*FuntDobra_ quit (Remote host closed the connection)
12:37:16*FuntDobra_ joined #nim
12:40:07*Ven`` quit (Read error: No route to host)
12:40:22*Ven`` joined #nim
12:57:19PMunchhttps://github.com/frol/completely-unscientific-benchmarks/pull/30
12:57:26PMunchMy PR, let's hope he merges it :)
12:59:15*cspar quit (Ping timeout: 268 seconds)
13:04:23*athenot joined #nim
13:05:26leorizePMunch: I noticed that the random number generator is being used without seeding with 'randomize()', can you please add it?
13:05:42*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:06:27*dddddd joined #nim
13:08:21FromGitter<krux02> Araq: Ping
13:09:24*athenot quit (Ping timeout: 276 seconds)
13:10:05*athenot joined #nim
13:11:04PMunchleorize, that would add another variable though..
13:11:53leorizePMunch: I don't see why https://nim-lang.org/docs/random.html#randomize,
13:12:24*nsf quit (Quit: WeeChat 2.1)
13:12:50PMunchBecause the values of y would change between each run
13:12:58PMunchThis way you will always get the same chain
13:16:05FromGitter<mratsim> ^
13:16:50FromGitter<mratsim> if other implementations are randomizing, we should to but otherwise it’s fine (default seed is 0)
13:17:38leorizelooks like only pascal does it. Thanks for the explaination PMunch
13:18:20*Ven`` joined #nim
13:19:25*FuntDobra_ quit (Remote host closed the connection)
13:21:36*Ven`` quit (Client Quit)
13:25:18*FuntDobra joined #nim
13:26:35PMunchTried for fun to compare the Nim JS target to the native JS code
13:26:54PMunchNative 1.340s, 49MiB
13:27:11PMunchNim 2.855s, 25MiB
13:27:20PMunchSo better memory performance, but worse time
13:36:52FromGitter<narimiran> who would have tell that some simple "unscientific" benchmark would attract so much attention....
13:37:11FromGitter<narimiran> i guess everybody wants to see their language as the bestest evaaah
13:37:14PMunchHaha, for me it started with the horrible results Nim had initially :P
13:38:05PMunchhttps://github.com/frol/completely-unscientific-benchmarks/commit/a3f25323f88a31ebb72f0e0b0d14e5a5f4334456#diff-04c6e90faac2675aa89e2176d2eec7d8R12
13:38:49PMunchGoing from 3.95s to 0.208s isn't all that bad :P
13:39:35FromGitter<narimiran> naaaah, not even 20x speedup.... :P
13:40:26FromGitter<narimiran> let's see if OP will accept your changes....
13:40:42PMunchHaha, feel free to write a version that is just one big {.emit.} of AST code :P
13:40:58PMunchnarimiran, he seems to want to merge it as a separate thing
13:41:24PMunchWhich isn't perfect, but it's better than nothing I guess
13:41:57FromGitter<narimiran> as i said there, i don't see the reason why, because you didn't do anything exotic
13:42:05PMunchI know..
13:42:17PMunchWell the {.inline.} is a bit exotic
13:42:37PMunchApart from that though it's pretty straight forward
13:42:50PMunchDoes basically the same as the C++ version
13:43:12FromGitter<narimiran> you mean {.noInit.}?
13:43:29*FuntDobra quit (Ping timeout: 248 seconds)
13:43:42PMunchOh yeah, noInit
13:44:43FromGitter<narimiran> OP replied. i must say i don't agree with his reasoning, but i guess - his repo, his rules
13:47:54PMunchHaha, same
13:48:00PMunchI get the `--gc` thing though
13:49:00Araqso ... fork the repo and name it "scientific benchmark without arbitrary rules" ?
13:50:37*FuntDobra joined #nim
13:51:18PMunchHaha :P
13:55:47FromGitter<narimiran> PMunch: what common API did you break?!
13:56:37PMunchHuh?
13:58:19FromGitter<narimiran> see the PR discussion, i don't get it either
13:59:06Yardanicoprobably he means "common features"
13:59:38Yardanicohttps://github.com/frol/completely-unscientific-benchmarks/pull/17#issuecomment-388939830 - his opinion about noinit
13:59:41FromGitter<narimiran> well, even i use templates. this means they are common :)
13:59:59Yardanicobut yeah, why would we care too much if their repo has such stupid rules ;)
14:00:13FromGitter<narimiran> oh, ok, noInit is not something common, agreed
14:02:09*leorize quit (Ping timeout: 268 seconds)
14:03:20PMunchI think the latest is more about me using var Node instead of returning a compound kind of some sort
14:04:22shashlickwhy is nim slower today than it was yesterday on that website
14:04:50Yardanicoshashlick, because there was a bug in Nim code which made Nim to not calculate any results at all
14:05:11shashlickokay
14:05:18Yardanicosee https://github.com/frol/completely-unscientific-benchmarks/commit/ee670ededbac9043e36560c3fa6cbd76c8dddb83
14:07:02*Ven`` joined #nim
14:07:05*FuntDobra quit (Ping timeout: 268 seconds)
14:08:55FromGitter<navicstein_twitter> nim looks like a better python
14:09:25FromGitter<navicstein_twitter> if nim was written like typescript, it would have gained a lot of traction by now:)
14:11:02Yardanicowhat do you mean by that?
14:11:22Yardanicobtw, can someone answer that? https://www.reddit.com/r/programming/comments/8jbfa7/naive_benchmark_treap_implementation_of_c_rust/dz0jded/
14:11:45Yardanicohttps://www.reddit.com/r/programming/comments/8jbfa7/naive_benchmark_treap_implementation_of_c_rust/dz0jded/?context=8&depth=9
14:12:16FromGitter<navicstein_twitter> hi
14:13:35Yardanicopersonally I started writing Nim because it looked python-like, not because of features (I didn't know anything about them)
14:14:07FromGitter<navicstein_twitter> @FromIRC hmmm, thats nice
14:14:27FromGitter<navicstein_twitter> @FromIRC ok, lets chat
14:14:36YardanicoYou should ping me directly
14:14:37FromGitter<navicstein_twitter> ok, shutup
14:14:43Yardanico?
14:14:56FromGitter<navicstein_twitter> excuse me?
14:16:31YardanicoI'm currently using IRC, so there's a gitter<->irc bridge, and you see my "yardanico" nickname
14:16:39Yardanicoand why are you so rude? :)
14:17:48*leorize joined #nim
14:18:00FromGitter<navicstein_twitter> because you are a bot :)
14:19:24Yardanicoofc
14:19:26PMunchYardanico isn't a bot..
14:19:45YardanicoHe means that FromIRC is a bot :P
14:19:51Yardaniconext-level trolling xD
14:20:13FromGitter<navicstein_twitter> ok, sorry
14:24:13*jaco60 joined #nim
14:25:29sendellYardanico you look like a bot too from here :p
14:25:30sendellhttp://prntscr.com/ji6nhj
14:25:53sendellnavicstein_twitter, not Yardanico sry
14:27:59*gokr quit (Ping timeout: 256 seconds)
14:28:51*jaco60 quit (Ping timeout: 255 seconds)
14:32:40FromGitter<Quelklef> Anything else I should do besides `-d:release --opt:speed` when compiling for speed?
14:33:12sendell--passC:-flto
14:33:52leorizePMunch: since my PR is merged, you could just rebase your PR with master, then you can do your modifications
14:33:59sendell(allows for inlining across modules)
14:34:12FromGitter<Quelklef> Thanks @sendell
14:35:48PMunch--gc:markAndSweep apparently :)
14:35:56PMunchleorize, yeah just did :)
14:36:00*Jehan_ joined #nim
14:36:11PMunchAssuming you are alviss on GitHub
14:36:23FromGitter<Quelklef> @PMuch subject to change, eh? thanks =]
14:36:33leorizePMunch: you should do a rebase, which would avoids duplicating all the commits :)
14:36:34Jehan_-d:release implies --opt:speed, no need to provide both.
14:36:44leorizeand yes, I'm alaviss on GitHub :D
14:36:49FromGitter<Quelklef> Oh thanks @Jehan)
14:37:10FromGitter<Quelklef> also markAndSweep makes my program hang, hmm
14:37:15Jehan_You can look at the Nim config file to see exactly what -d:release implies.
14:37:33YardanicoQuelklef - might be a bug in GC (but not sure), do you use devel?
14:37:35Jehan_--gc:markandsweep is a stop the world collector, but shouldn't (by itself) make it hang.
14:37:54FromGitter<Quelklef> Ah, didn't hang, just froze for a bit
14:38:02FromGitter<Quelklef> I'm on devel, yeah
14:38:06FromGitter<Quelklef> recompiled, I think, yesterday?
14:38:06Jehan_It also doesn't make things necessarily faster; if you're talking about the treap benchmark, that's because lots of pointers are being written to the heap.
14:38:38PMunchleorize, yeah I did.. Not sure why all those still show up
14:38:58FromGitter<Quelklef> Also, the compiler user guide doesn't specifically mention that d:release implied opt:speed
14:39:05FromGitter<Quelklef> Simply that it "Turns off runtime checks and turns on the optimizer."
14:39:10Jehan_Incremental/generational GCs require a write barrier for pointer updates on the heap; stop-the-world collectors don't.
14:39:23Yardanicotime to test latest devel - there was a big refactoring :)
14:39:36Jehan_"turns on the optimizer" means --opt:speed.
14:39:48FromGitter<Quelklef> fair enough
14:39:50leorizePMunch: it could be because you used `git merge` instead of `git rebase`
14:39:58FromGitter<Quelklef> just --opt also has `size`, so seems ambig to me
14:40:07leorizebut anyway, OP resolved it with squash and merge :)
14:40:09Jehan_True.
14:42:13PMunchHmm, I didn't merge though.. I had done some changes on a separate branch. Merged that into my branch, then rebased against origin/master
14:42:44PMunchYardanico, I would but choosenim doesn't want to :(
14:42:57PMunchhttp://ix.io/1ao2/
14:43:04Yardanicough
14:43:10Yardanicothat's actually very strange
14:46:37leorizePMunch: Looks like you have splitted the var block into separate statements, is it intentional?
14:47:49*miran joined #nim
14:48:10FromGitter<xmonader> Good evening
14:48:30FromGitter<Quelklef> howdy
14:48:47FromGitter<xmonader> arghh u just reminded me i didn't watch `westworld` thanks :( @Quelklef
14:48:59Yardanicoleorize, that's probably a personal thing, there's no difference at all
14:49:49FromGitter<Quelklef> @xmonader go do that!
14:50:01sendellso what kinds of GC are still compatible with GC_step and GC_setMaxPause?
14:50:46Araqrefc and maybe v2
14:51:14PMunchleorize, no, not sure why that happened
14:51:14*jaco60 joined #nim
14:51:34sendellok so the original one that had no overhead for stack refs is the one called "refc"
14:51:50sendellwhich needs "weak" hints to break cycles
14:51:52sendellright?
14:51:59leorizePMunch: I'm gonna push a PR to improve styling for both versions then :)
14:52:10Araqthey all have zero overhead for stack refs
14:52:40sendellnice then :)
14:52:43Araqand refc ignores .acyclic annotations these days, instead it runs a non-incremental M&S step these days
14:53:00PMunchleorize, good
14:53:00sendelloh good to know
14:53:18Araqwhich you can disable indepently from the RC'ing collector
14:53:33Araqthat's what the Nim compiler uses
14:54:41sendelland v2 is the same but with incremental mark and sweep?
14:54:56Araqit's only incremental mark and sweep, no refcounting
14:55:16Araqit used to be a hybrid but omg these algorithms are so hard to compose
14:55:27Araqso I threw away the RC'ing part
14:55:36sendellI believe you on that haha
14:55:49sendellso what are the downsides ?
14:56:33Araqit's slower and in general I've given up on GC algorithms
14:58:01sendellbeing able to run them incrementally is a huge thing for games actually
14:58:17*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:58:29PMunchAraq, they seem to perform pretty good :)
14:58:30sendell(and other realtime apps ofc)
14:58:31miranPMunch: wasn't in the benchmarks at one point "type Tree = object"? now i see it is 'ref object'
14:58:49miranis 'ref object' faster/better?
14:58:58FromGitter<krux02> no
14:59:07FromGitter<krux02> ref is generally slower and uses more memory
14:59:08PMunchmiran, it is in main_fast.nim
14:59:18PMunchAn object that is
14:59:46PMunchWait, it's an object in all the version..
14:59:47miranPMunch: oh, it is also in main.nim and i'm an idiot
14:59:54PMunchWhere are you looking? :P
15:01:30*Jehan_ quit (Quit: Leaving)
15:02:14miranat "type Node" :D :D
15:02:38*nsf joined #nim
15:02:39*darithorn joined #nim
15:03:26PMunchAh :P
15:06:14sendelldo seqs and strings generate garbage?
15:06:27Araqyup. plenty.
15:06:32sendelldamn
15:07:13sendellI thought the copy on affectation thing was a hack to avoid that
15:07:27Araqyeah. we're getting there.
15:07:35Araqv2 features and all that.
15:08:01sendellthat's cool then :)
15:08:14AraqI'm still convinced of my design
15:09:27sendellgood to hear :) how much work left to reach that point?
15:10:19Araqhttps://github.com/nim-lang/Nim/issues/7041
15:10:36sendellthx
15:18:41PMunchleorize, isn't unshortening res to result a bad idea?
15:18:47miranyeah
15:18:51PMunchresult being an implicit variable and all
15:18:52mirani'm writing the reply
15:19:03PMunchHaha, okay cool :)
15:20:48leorizePMunch: well, I'm just following what I've seen within the stdlib, like in https://github.com/nim-lang/Nim/blob/devel/lib/pure/collections/sequtils.nim#L453
15:21:06miranleorize: see my comment on github
15:21:27miranin the linked example, `result` is the return variable, unlike in the benchmark
15:25:13PMunchYeah, using result is normal as the implicit result variable. I'm using an optimisation there of not returning the Nodes but directly setting them. Similar to passing a pointer to a pointer in C
15:25:15*PMunch quit (Quit: Leaving)
15:28:55*Trustable joined #nim
15:29:09*leorize quit (Ping timeout: 255 seconds)
15:34:26Yardanicoalso, about me - I wasn't active in nim community in last months because I was preparing for exams - I will take my first USE ( https://en.wikipedia.org/wiki/Unified_State_Exam ) in 2 weeks (first one is maths, then russian language on 7th and physics on 20th )
15:35:46Araqyeah I had to update the stdlib and remove the .deprecated stuff all by myself :P
15:36:04Araqbut it was as much work as a review would have been, so no worries
15:39:10*noonien quit (Quit: Connection closed for inactivity)
15:39:36*cspar joined #nim
15:47:45FromGitter<zetashift> @Yardanico good luck!
15:47:58Yardanicothanks :)
16:11:49*sendell quit (Remote host closed the connection)
16:14:14*FuntDobra joined #nim
16:15:22miranPMunch (and others): on my machine, main_fast.nim is ~4x faster than main.nim - is this expected? i didn't know the difference is so large
16:15:49miransorry, ~3x
16:18:52FromGitter<Vindaar> @Yardanico: probably not necessary but: if you have some (random) questions for the physics exam, just ping me :)
16:21:22FromGitter<data-man> @Araq: c2nim again is not compiles with devel :( I again ask you to create the c2nim's devel branch, please.
16:21:39*athenot quit (Remote host closed the connection)
16:22:16*athenot joined #nim
16:22:51Araqdata-man, will fix it
16:26:27*FuntDobra_ joined #nim
16:29:21*FuntDobra quit (Ping timeout: 248 seconds)
16:33:36*floppydh quit (Quit: WeeChat 2.1)
16:35:23FromGitter<data-man> Thanks!
16:36:06*jrbrt joined #nim
16:38:30*jrbrt quit (Client Quit)
16:40:42*FuntDobra__ joined #nim
16:42:24*vivus joined #nim
16:43:34*FuntDobra_ quit (Ping timeout: 260 seconds)
16:46:10*FuntDobra__ quit (Remote host closed the connection)
16:46:36*FuntDobra__ joined #nim
16:58:08*nsf quit (Quit: WeeChat 2.1)
17:01:27*FuntDobra__ quit (Ping timeout: 240 seconds)
17:04:59*jrbrt joined #nim
17:08:27*FuntDobra__ joined #nim
17:11:22*jrbrt quit (Quit: jrbrt)
17:12:47FromGitter<mratsim> @Yardanico I replied to https://github.com/status-im/nim-stint
17:15:18FromGitter<mratsim> oh forgot about embedded device
17:21:53*FuntDobra_ joined #nim
17:24:19FromGitter<mratsim> sorry to https://www.reddit.com/r/programming/comments/8jbfa7/naive_benchmark_treap_implementation_of_c_rust/dz0jded/
17:25:02*FuntDobra__ quit (Ping timeout: 268 seconds)
17:29:28Yardanicothanks a lot :) we need people to know more about Nim
17:29:50FromGitter<mratsim> we need to fix .noInit. :P
17:31:01FromGitter<mratsim> btw a list of Nim repo for embedded devices would be super handy, do you perhaps have that @FedericoCeratto?
17:33:09FromGitter<krux02> @mratsim did you bisect the compiler to find out where the problem got introduced?
17:34:23*xkapastel joined #nim
17:34:25FromGitter<mratsim> @krux02 it was always there - https://github.com/nim-lang/Nim/blob/master/compiler/cgen.nim#L312
17:35:05FromGitter<mratsim> basically I think the cleanest solution is that if the compiler can prove that the result value is fully initialized, it can skip that
17:35:42FromGitter<mratsim> It makes the “compiler cannot prove that this is properly initialized” more palatable becomes it will come with a 2x~3x perf improvement ;)
17:36:54*FuntDobra__ joined #nim
17:36:58*gmpreussner quit (Ping timeout: 264 seconds)
17:37:11FromGitter<krux02> this prof of initialization reminds me of flow typing like a college of mine is implementing right now
17:37:31Araqit is a variant of flow typing, yes.
17:39:15FromGitter<krux02> flow typing is interesting, before he wanted to implement it, I did not hear about it. But if you ask me it totally makes sense.
17:39:29FromGitter<krux02> it's like dynamic typing statically checked.
17:39:34*FuntDobra_ quit (Ping timeout: 260 seconds)
17:39:48FromGitter<mratsim> I’m lost Ó_Ó
17:40:18Araqwe have the technology to prove every array index is without bounds
17:40:23FromGitter<krux02> @mratsim on each assignment to a variable the static types of that variables changes
17:40:33Araqwith our flow typing. all it requires is much more polish
17:40:36*gmpreussner joined #nim
17:41:49FromGitter<krux02> he also wants to have things like ``if i > 0: #[ here i is actually known to be > 0 at compile time]#``
17:41:58AraqNim has that...
17:42:16Araqwrote a proof inference engine for these things
17:42:30Araqit's pretty awful to maintain though :-)
17:42:38FromGitter<krux02> I can imagine
17:42:54Araqcheck compiler/guards.nim
17:43:20Araqit contains plenty of rules to replicate some basic logic good programmers can do in their heads
17:43:33FromGitter<krux02> my collegue, he is actually also my suprevisor of my master thesis, wants to support recursive types and he wants integers to be unbounded by default
17:43:39FromGitter<krux02> like big int in Python
17:44:03FromGitter<krux02> I am not sure how well that will turn out
17:44:12FromGitter<krux02> especially because he wants to have high performance
17:44:41FromGitter<mratsim> high performance, GMP like, lower or higher?
17:45:03FromGitter<krux02> well gmp is just for general precision
17:45:05*gmpreussner quit (Ping timeout: 248 seconds)
17:45:08FromGitter<mratsim> bigint in python are using this: http://www.bytereef.org/mpdecimal/index.html
17:45:15FromGitter<krux02> I can imagine he would use that library under the hood
17:45:32FromGitter<krux02> but in general the compiler should optimize away almost all arbitrary sized integers
17:45:54FromGitter<mratsim> This is recursive type stack integer library in Nim ;): https://github.com/status-im/nim-stint/blob/master/stint/private/datatypes.nim
17:46:16FromGitter<krux02> decial? that is discusting :P
17:46:21Araqyeah, I'm not convinced
17:46:36FromGitter<krux02> it sounds interesting though
17:46:37Araq"optimize away almost all..."
17:46:49Araq^ rarely works.
17:46:59FromGitter<krux02> today he explainde to me how a flat array of [1,2,3] is also of type json
17:47:09FromGitter<mratsim> it’s higher perf than GMP normally. I basically followed that paper: https://hal.archives-ouvertes.fr/hal-00582593v2/document
17:48:07FromGitter<krux02> and json is this recursive type that can be ``nil | int | string | bool | [json] | {string->json}``
17:48:41Araqsure, that's json
17:48:46Araqwhat's special about it?
17:48:58FromGitter<krux02> well it is recursive
17:49:13Araqcertainly. it's also linear.
17:49:41FromGitter<krux02> well in json each node needs to know what type it is
17:50:06FromGitter<krux02> but in an array like [1,2,3] the elements are just integers without a tag saying what type they are
17:50:12*zahary_ joined #nim
17:50:34FromGitter<krux02> and [1,2,3] should be json
17:51:23*FuntDobra_ joined #nim
17:52:36*gmpreussner joined #nim
17:53:02FromGitter<krux02> I think that is really a powerful concept.
17:53:29AraqI don't get it
17:53:40Araqthe layouts in memory are completely different
17:54:02Araqyou can patch over it to achieve some mathematical purity
17:54:11*FuntDobra__ quit (Ping timeout: 276 seconds)
17:54:37FromGitter<krux02> yes that was exactly my thought, too, the memory layout is completely different
17:55:11FromGitter<krux02> but if you pair the type with the pointers instead with the values, it could work
17:55:50FromGitter<krux02> the seq type ``[...]`` is just an interface that requires an index operator and a length.
17:56:32FromGitter<krux02> when [int] returns a part of (tyInt, intvalue), it could work
17:56:56FromGitter<krux02> but yea, time will tell if he acutally manages it to work
17:57:04FromGitter<krux02> he is for sure very smart.
17:58:25*FuntDobra_ quit (Ping timeout: 256 seconds)
17:58:45Araqreminds me of Nim's RTTI
17:59:31Araqwhich is used in 'genericReset', mratsim loves it for performance
17:59:43Araq:-)
18:00:18FromGitter<krux02> well I never used the RTTI
18:00:26Araqbut you can look at LuaJIT for an implementation that rules
18:01:06FromGitter<krux02> yea luajit is a pretty cool project for sure
18:01:14FromGitter<krux02> probably the one that makes lua so attractive
18:01:46FromGitter<krux02> and they they screwed over the simplicity of lua by adding the integer types ¯\_(ツ)_/¯
18:02:13Araqthey screwed over by merging lists and tables
18:02:44FromGitter<mratsim> ugh
18:03:13FromGitter<krux02> I think at some point when the original developers of Go are not in power anymore, but some other people, Go will also get a lot more featuers all of a sudden
18:03:28FromGitter<krux02> and then the simplicity of Go will also vanish
18:03:56AraqI think it already is fiction, they have pragmas but they write them in comments.
18:04:07FromGitter<mratsim> Antoine de Saint-Exupéry “Perfection is not achieved when there is nothing to add, but when there is nothing to take away."
18:04:37AraqI can not document plenty of Nim's pragmas. and then it's a much simpler language. right?
18:04:37FromGitter<krux02> it is something that has been done with almost everything. hey our feature is simplicity so that it is easy to understand. And then everybody yells, yes but we also nead feature 1 2 3 4 5 6 ... 1324
18:05:06FromGitter<mratsim> Story of Perl :P
18:05:15Araqthey also don't have exceptions, but er, panic and defer.
18:05:17FromGitter<mratsim> (or PHP)
18:05:18FromGitter<krux02> Well I just think that making a language simple is simply not possible.
18:05:19*FuntDobra_ joined #nim
18:05:31FromGitter<mratsim> You can make DSL.
18:05:36FromGitter<krux02> Either the language is complex or the language sucks at some point
18:05:48Araqand they don't have inheritance but "delegation and interfaces"
18:06:08FromGitter<krux02> but what I think is very well possible is to have a simple easy to understand core that is well documented and suitable for most use cases.
18:06:24Araqwhich is not bad, but also so close to "real" inheritance that you cannot claim any simplicity awards
18:06:55FromGitter<krux02> I think the Go programming language sucks at some point, but still I would recommend that language to beginners of programming, because it has this simple core.
18:07:16FromGitter<krux02> well that is true
18:07:44FromGitter<krux02> Go has type embedding, which is very close to multiple inheritance
18:08:02FromGitter<mratsim> it really depends on the usage. I can’t recommend go to anyone wanting to do anything remotely related to science.
18:08:11Araqyou can argue it's "MI done right (TM)"
18:08:27Araqand it would require some decent analyis to prove / disprove that.
18:08:44Araqbut you can't claim "see, it's much simpler" IMO anyway.
18:09:17FromGitter<krux02> well I see for the most part what features of a language do and not what they are called, and multiple inheritance is for me type embedding.
18:09:19*FuntDobra__ joined #nim
18:10:04FromGitter<krux02> but I think it is more transparent it what it does than the c++ inheritance model
18:10:34FromGitter<krux02> because it doesn't magically inherit, but it is just an anonymous member of the struct.
18:10:34Araqmaybe, I dunno. inheritance in modern C++ is rather rarely used
18:10:57FromGitter<krux02> but it could also be me, because at the time I learned go I had much more experience than when I learned c++
18:11:07FromGitter<krux02> true
18:11:26Araqyet the accesses that avoid the middle man (x.f vs x.y.f) are as "magical" as they are in inheritance
18:12:03FromGitter<krux02> yea they are
18:12:22*FuntDobra_ quit (Ping timeout: 264 seconds)
18:14:35FromGitter<krux02> Araq: another question, when I generate my glsl code from nim, how do I avoid generating colliding identifiers
18:14:53Araqwith gensym() ?
18:15:08FromGitter<krux02> well I already have a typechecked ast
18:15:20FromGitter<krux02> and the symbols are resolved on the nim side
18:15:44FromGitter<krux02> but I am generating identifiers from for glsl from the nim symbol
18:15:51FromGitter<krux02> and I can get coflicting names
18:15:59Araqlike?
18:16:20FromGitter<krux02> for item in myitems: let i = 123
18:16:31FromGitter<krux02> there is one i generated from the for loop
18:16:57FromGitter<krux02> wait, maybe I am wrong here, I modify the for loop quite a but
18:17:03FromGitter<krux02> my bug might be somewher else
18:18:17*FuntDobra_ joined #nim
18:18:47Araqyou can use gensym() to get a unique prefix/suffix and concat the name to some original name
18:18:54Araqin order to avoid clashes
18:19:05Araqno idea if that helps you
18:21:57*FuntDobra__ quit (Ping timeout: 255 seconds)
18:22:37*icebattle joined #nim
18:22:50*FuntDobra__ joined #nim
18:24:57*FuntDobra_ quit (Ping timeout: 240 seconds)
18:25:59FromGitter<krux02> I found out the problem
18:26:15*thmslld joined #nim
18:26:18FromGitter<krux02> the problem had to do with for loops
18:26:35FromGitter<krux02> the for loop is nim unrolls to some named break thing.
18:26:49FromGitter<krux02> The problem is that glsl has no goto
18:26:56FromGitter<krux02> so I cannot translate that part
18:27:43FromGitter<krux02> what I did was, I did pattern matching on the generaded blocks with break statements and generated a simple for loop in glsl
18:28:45FromGitter<krux02> most important is that it works, but now I had one less level of block nestings and the i inside of the block clashed with the i of the for loop
18:29:12FromGitter<data-man> @mratsim: Special for you :) http://arblib.org
18:29:37FromGitter<mratsim> ballsy
18:33:59FromGitter<krux02> Araq: how do you prevent that identifiers clash with keywords in the backend language?
18:34:20FromGitter<krux02> I just look in my list of keywords and when it clashes I prepend a postfix
18:34:33FromGitter<krux02> I append a postfix
18:34:39Araqyeah like that.
18:34:53AraqI used to simply produce names that are not keywords in C
18:35:00Araqlike foo_<ID>
18:35:12Araqbut people complained the mangling is bad for debugging
18:35:25Araqand now there is some super complex logic that deals with this shit
18:35:27FromGitter<Varriount> Araq: I'm really impressed by the refactoring work you've done. That was a lot of code. :D
18:37:46FromGitter<krux02> Araq: well like how nim tries to keep identifier names intact. It really helps for debugging.
18:37:48*FuntDobra_ joined #nim
18:37:56FromGitter<krux02> I want that, too.
18:38:10FromGitter<krux02> Even though my supervisor told me to just rename everything.
18:38:17FromGitter<krux02> I really dislike that idea
18:39:15Araqvarriount: I figured it's time to drag this codebase into the new century
18:40:24FromGitter<krux02> Araq: what did you work on
18:40:28Araqplenty of people are now copying and contributing to the compiler and I'd like to show them how things should be done
18:40:44FromGitter<krux02> yes that is a very good idea
18:40:51Araqalso it makes the compiler-as-an-API better to use and helps with --symbolFiles
18:41:05*FuntDobra__ quit (Ping timeout: 248 seconds)
18:41:06Araqthree good things at the same time.
18:41:12FromGitter<krux02> people get inspired by the nim code, show some resposiblility and make them not get inspired by bad code :P
18:42:13FromGitter<krux02> I remember you showed some resistence when I wanted to remove the linked list implementation that was only used for include files (long time ago)
18:42:28FromGitter<data-man> @Araq: New century? Are you from the MacLeod's Clan? :)
18:43:25FromGitter<krux02> @data-man I think it is just normal exaggeration
18:43:31Araqdon't understand this reference
18:43:39FromGitter<krux02> me neither
18:44:07subsetparkThat's Highlander, I know that one
18:44:19FromGitter<data-man> Yes :)
18:44:27FromGitter<krux02> I wanted to reply something and now I realized sometimes it is just better to just say nothing
18:44:41Araqha ha, quote of the day
18:45:28FromGitter<krux02> well people, I leave the office for today.
18:45:39Araqsure, good bye
18:45:53FromGitter<krux02> I think I might be online again at home, but not working anymore
18:45:57FromGitter<krux02> bye
18:46:21Araqvarriount: could have delegated the refactoring but reviewing such a patch would likely have been even more work
18:46:49*thmslld quit (Quit: Page closed)
18:47:03*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
18:47:31*nsf joined #nim
18:47:33AraqI just hope I don't have to break Nimble again
18:51:00*FuntDobra__ joined #nim
18:52:57*FuntDobra_ quit (Ping timeout: 240 seconds)
18:53:00*FuntDobra joined #nim
18:55:15*FuntDobra__ quit (Ping timeout: 255 seconds)
19:15:57*FuntDobra_ joined #nim
19:18:12*FuntDobra quit (Ping timeout: 255 seconds)
19:19:24Yardanicodom96, btw, all async tests pass for me with "yield in try" PR and your commit removing try transformation
19:20:18Yardanicoand simplest "await" in try with async httpclient works
19:26:19*FuntDobra_ quit (Ping timeout: 260 seconds)
19:27:20FromGitter<Varriount> So what's the magic bullet to make async super fast?
19:32:19*Trustable quit (Remote host closed the connection)
19:34:13*FuntDobra_ joined #nim
19:36:13*FuntDobra joined #nim
19:36:15dom96Depends on your use case
19:36:36subsetparkAre we still working on/did we finish with unifying `await` on a future and `await` in async?
19:37:34dom96you mean FlowVar?
19:39:05*FuntDobra_ quit (Ping timeout: 240 seconds)
19:39:07*FuntDobra__ joined #nim
19:42:04*FuntDobra quit (Ping timeout: 265 seconds)
19:45:08*gokr joined #nim
19:46:11*Ven`` joined #nim
19:50:59*Ven`` quit (Ping timeout: 256 seconds)
19:58:12*Ven`` joined #nim
20:06:22*nsf quit (Quit: WeeChat 2.1)
20:12:58*darithorn quit (Ping timeout: 264 seconds)
20:15:47*Ven`` quit (Read error: Connection reset by peer)
20:16:10*Ven`` joined #nim
20:19:05*darithorn joined #nim
20:21:34*athenot quit (Read error: Connection reset by peer)
20:23:36*athenot joined #nim
20:28:09*Ven`` quit (Ping timeout: 260 seconds)
20:28:41*Ven`` joined #nim
20:29:32*cspar quit (Ping timeout: 276 seconds)
20:35:52*cspar joined #nim
20:38:43*Ven`` quit (Ping timeout: 268 seconds)
20:49:52*jaco60 quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:57:21*cspar quit (Ping timeout: 240 seconds)
20:59:00livcdis there a fs monitor pkg that works with Windows ?
21:00:07*olleh joined #nim
21:00:20ollehHi guys. How can one determine the len of a set?
21:00:27ollehvar x = {1,2,3}
21:01:24*FuntDobra__ quit (Ping timeout: 260 seconds)
21:01:40Araqcard(s)
21:04:30ollehty
21:10:25*miran quit (Ping timeout: 248 seconds)
21:14:18*cspar joined #nim
21:14:57*tiorock joined #nim
21:14:57*tiorock quit (Changing host)
21:14:57*tiorock joined #nim
21:14:57*rockcavera is now known as Guest16662
21:14:57*tiorock is now known as rockcavera
21:17:53dom96livcd: Don't think so
21:18:04Araqthere was, check the forum please
21:18:05*Guest16662 quit (Ping timeout: 240 seconds)
21:18:12Araqsomebody had a windows implementation
21:18:33livcdhmm
21:18:35livcdI found this
21:18:36livcdhttps://github.com/snowlt23/nimwatch
21:18:47livcdNot sure if it's usable ..
21:19:27FromGitter<zetashift> says it supports windows
21:20:11livcddid not try it yet but looks like the import is broken
21:20:17livcdwindows -> oldwinapi/windows
21:20:26euantorI'm trying to update the Nix package for Nim to 0.18.0, but it looks like there are several test failures. PR: https://github.com/NixOS/nixpkgs/pull/40556 - test results: https://logs.nix.ci/?key=nixos/nixpkgs.40556&attempt_id=0bc36c07-e0ee-46d5-b4f8-30d43cbcfe3a
21:20:58euantorSome of the failures are interesting, such as missing binaries (`/usr/bin/env`, `/bin/sleep`) and `cannot open 'jester'`
21:21:29euantorPerhaps there's some setup stage missing for running the tests that I'm not aware of? Should all the test be ran, or should it only run a couple?
21:21:35Araqseems like the dependencies are incompletely listed for NixOS
21:22:00Araqand NixOS is much more picky about it than other distros (?)
21:22:21euantorNot sure. There are also some failures about timezones too for the times module
21:23:18euantorDepending on Jester for core tests seems like a pretty ba idea to me though, not sure why that's done?
21:23:46Araqlegacy
21:23:52Araqplus we test Nimble this way
21:24:15*NimBot joined #nim
21:24:44euantorInteresting. I've never ran the full test suite before because it takes ages
21:25:46euantorCould the timezone ones also be due to missing packages/host configuration possibly?
21:26:12euantor`ttimes.nim(262, 17): Check failed: diff == 2208986872'i64; diff was 2208988800`
21:33:18*gangstacat quit (Remote host closed the connection)
21:33:40*gangstacat joined #nim
21:33:50Araqit doesn't take ages, it takes 30-60 minutes
21:34:30dom96yeah, it's not that bad
21:34:38dom96I ran it on an RPi once, now that did take ages :)
21:34:54dom96But it still finished after a couple of hours
21:35:09euantorTakes ages when I'm too inpatient ;)
21:35:15euantor*impatient
21:36:50euantorAlso, is `koch tests` the recommended way to test, or should it be doing what the `travis.yml` file does: `tests/testament/tester --pedantic all -d:nimCoroutines`?
21:37:35Araq--pedantic should be the default
21:37:49Araqcoroutines are not required and weird
21:43:51FromGitter<GULPF> @euantor the timezone tests fail because they require some specific timezones to be available
21:44:19euantor@GULPF Ah, ok. I'll need to see what I can do about those then
21:47:50FromGitter<GULPF> found this: https://nixos.org/nix-dev/2014-April/013190.html
21:47:57*jxy quit (Quit: leaving)
21:48:32FromGitter<GULPF> the tests uses $TZ to change the timezone, which apparently (?) doesn't work on nixos
21:49:15euantorNot sure, I've only used Nix the package manager, not the full Nix OS
21:49:44*jxy joined #nim
21:53:47ollehguys, in something like this, is new required? let mittens: ref Animal = new(Animal)
21:54:08ollehhow is it different when compared to this? let mittens: ref Animal = Animal
21:54:20ollehor this let mittens: ref Animal = Animal()
21:55:46ollehalso, when should one prefer reference types over values types?
21:57:52*Vladar quit (Quit: Leaving)
21:59:14Araquse ref types if you don't understand value types
21:59:22Araqprefer value types.
22:00:19Araqthe other questions are better answered by the compiler. (most variants don't even compile)
22:08:19ollehthanks mate
22:10:07ollehAraq. any idea why this snippet doesn't compile? https://pastebin.com/vt7YX0uT
22:30:45FromGitter<zetashift> @olleh because I think that's invalid syntax; you can't just do ref Animal but you need to fully type it like ref object of Animal : https://nim-lang.org/docs/tut2.html#object-oriented-programming-objects
22:31:49FromGitter<zetashift> you could also check this out: https://peterme.net/nim-types-originally-a-reddit-reply.html
22:33:10ollehbut doesn't Animal become a type alias?
22:33:15ollehthat's why is should work
22:33:36FromGitter<data-man> @olleh: Something like this: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5afb604041f54f22e23111e8]
22:37:25ollehanyways.
22:37:41*mostly-harmless quit (Ping timeout: 268 seconds)
22:37:43ollehdoes anybody know the difference between int(1.2) and toInt(1.2)
22:37:44olleh?
22:53:50*sz0 quit (Quit: Connection closed for inactivity)
22:57:12FromGitter<zetashift> How can I show the keys that have a value of 0 in a CountTable: https://wandbox.org/permlink/6RgupBJRVxxqpaVx ?
22:58:22FromGitter<zetashift> @olleh, int() accepts more than a float
23:06:21*olleh quit (Ping timeout: 264 seconds)
23:15:36FromGitter<data-man> @zetashift: CountTable don't keep keys with zero values
23:20:35FromGitter<zetashift> Any other structure I can use? @data-man
23:24:42*athenot_ joined #nim
23:24:56*athenot quit (Ping timeout: 276 seconds)
23:27:06FromGitter<data-man> CritBitTree[int] supports inc
23:27:37FromGitter<data-man> And with keys as string only
23:33:08*leorize joined #nim
23:33:53*mostly-harmless joined #nim