<< 31-03-2020 >>
00:07:42*rnrwashere joined #nim
00:09:18*rnrwashere quit (Remote host closed the connection)
00:09:54*sleepyqt quit (Ping timeout: 256 seconds)
00:10:47*rnrwashere joined #nim
00:12:43*Guest2172 quit (Ping timeout: 260 seconds)
00:15:07*rnrwashere quit (Ping timeout: 258 seconds)
00:18:45*dadada__ joined #nim
00:20:13*rnrwashere joined #nim
00:34:04*rnrwashere quit ()
00:37:00*krux02_ quit (Remote host closed the connection)
00:42:07*dadada__ quit (Ping timeout: 260 seconds)
00:48:43*dadada joined #nim
00:49:08*dadada is now known as Guest46132
01:07:04*moerm__ quit (Quit: Leaving)
01:09:34*couven92 quit (Ping timeout: 256 seconds)
01:12:27*Guest46132 quit (Ping timeout: 260 seconds)
01:18:35*dadada__ joined #nim
01:27:33*chemist69 quit (Ping timeout: 252 seconds)
01:29:36*chemist69 joined #nim
01:42:24*dadada__ quit (Ping timeout: 265 seconds)
01:45:48*endragor joined #nim
01:48:36*dadada joined #nim
01:48:59*dadada is now known as Guest4628
01:56:06*lritter quit (Ping timeout: 240 seconds)
01:57:00*lritter joined #nim
02:12:22*Guest4628 quit (Ping timeout: 265 seconds)
02:18:35*dadada__ joined #nim
02:27:11*lritter quit (Quit: Leaving)
02:37:31FromGitter<Knaque> Has anyone ever heard of the Nim VSCode extension's linting just outright not doing anything? I'm having this issue all of a sudden.
02:37:47FromDiscord<Rika> same here, been like that for a while
02:37:51FromDiscord<Rika> cant pinpoint the issue
02:38:49FromGitter<Knaque> Do you think it's a bug in the extension, or some weird incompatibility or something like that?
02:40:09FromDiscord<Rika> prolly a bug
02:41:03*muffindrake quit (Ping timeout: 272 seconds)
02:41:06FromGitter<Knaque> Hopefully it gets fixed soon, cause god forbid I ever have to learn Vim or something.
02:42:03*dadada__ quit (Ping timeout: 260 seconds)
02:42:59*muffindrake joined #nim
02:47:49FromDiscord<Rika> you can just `nimpretty filename` you know
02:47:57FromDiscord<Rika> ah linter or formatter?
02:48:12FromDiscord<Rika> if the linter, its known
02:48:28FromDiscord<Rika> i set my "nimsuggest timeout" to like 5 minutes
02:48:39*dadada joined #nim
02:48:42FromDiscord<Rika> then restart (reload window) vscode
02:49:03*dadada is now known as Guest8830
02:53:00FromGitter<Knaque> I fixed a mistake (that I found while trying to compile) and all of a sudden everything's back in working order, so... I dunno.
03:12:49*Guest8830 quit (Ping timeout: 264 seconds)
03:18:31*dadada__ joined #nim
03:26:01*waleee-cl quit (Quit: Connection closed for inactivity)
03:34:18*rnrwashere joined #nim
03:42:13*dadada__ quit (Ping timeout: 264 seconds)
03:48:33*dadada joined #nim
03:48:56*dadada is now known as Guest34805
03:49:52FromGitter<sealmove> I realized doing `object of somObj` is not inheritance in the "Java sense"
03:50:48FromGitter<sealmove> It's just a shorthand for not writing out the same fields again right?
03:50:58*rnrwashere quit (Remote host closed the connection)
03:51:14FromGitter<sealmove> I mean, is there an hierarchy of objects created?
03:52:54*rnrwashere joined #nim
04:00:33FromDiscord<Rika> i think you want `ref object of` for the hierarchy
04:01:59FromGitter<dumjyl> Not entirely, generic match is just prefered to subtype match. So with your 'bug' the generic system `=destroy` was used instead of an upconversion. This happens with `$` too. This does make working with overly generic routines a PITA. I have to use a `{.inherit.}` macro pragma for my closed inheritance library to workaround this.
04:03:09FromGitter<sealmove> I see
04:12:32leorizeit's the same kind of inheritance
04:12:35*Guest34805 quit (Ping timeout: 260 seconds)
04:13:07leorize@dymjyl: that sounds like a bug :P
04:16:04FromGitter<dumjyl> I'm not saying I like it but its in the spec https://nim-lang.org/docs/manual.html#overloading-resolution.
04:17:07FromGitter<sealmove> It's also annoying that you can't define a field with the same name as a supertype's field
04:18:42*dadada__ joined #nim
04:18:51leorizethat one doesn't sound too bad tbh
04:21:09FromGitter<sealmove> or I am just too used to java...
04:42:12*dadada__ quit (Ping timeout: 265 seconds)
04:44:45*Asgaroth joined #nim
04:46:54*Asgaroth_ quit (Ping timeout: 240 seconds)
04:48:35*dadada joined #nim
04:48:59*dadada is now known as Guest54196
04:53:45*rockcavera quit (Remote host closed the connection)
04:55:39*rnrwashere quit (Remote host closed the connection)
05:12:12*Guest54196 quit (Ping timeout: 258 seconds)
05:18:38*dadada__ joined #nim
05:22:18*thomasross quit (Ping timeout: 256 seconds)
05:22:29*narimiran joined #nim
05:42:29*dadada__ quit (Ping timeout: 258 seconds)
05:48:37*dadada joined #nim
05:48:59*dadada is now known as Guest18951
05:57:26*rnrwashere joined #nim
05:57:35*dddddd quit (Ping timeout: 260 seconds)
06:12:44*Guest18951 quit (Ping timeout: 256 seconds)
06:16:14*PMunch joined #nim
06:18:41*dadada__ joined #nim
06:26:32*NimBot joined #nim
06:33:23*solitudesf joined #nim
06:44:23*rnrwashere quit (Remote host closed the connection)
07:00:00*gmpreussner quit (Quit: kthxbye)
07:04:57*gmpreussner joined #nim
07:25:17*hax-scramper joined #nim
07:27:01*dadada__ quit (Ping timeout: 265 seconds)
07:33:35*dadada joined #nim
07:33:59*dadada is now known as Guest5071
07:43:31*tefter joined #nim
07:57:13*Guest5071 quit (Ping timeout: 264 seconds)
08:03:44*dadada joined #nim
08:04:07*dadada is now known as Guest64104
08:05:59*sleepyqt joined #nim
08:11:41*aEverr quit (Ping timeout: 250 seconds)
08:11:55*aEverr joined #nim
08:19:55*letto quit (Ping timeout: 250 seconds)
08:27:47*letto joined #nim
08:27:55*Guest64104 quit (Ping timeout: 265 seconds)
08:33:13*oculuxe quit (Quit: blah)
08:33:46*dadada__ joined #nim
08:34:55*oculux joined #nim
08:35:28*dwdv joined #nim
08:54:47*filcuc joined #nim
08:56:50*Vladar joined #nim
08:57:24*dadada__ quit (Ping timeout: 265 seconds)
09:03:40*dadada joined #nim
09:04:03*dadada is now known as Guest13390
09:21:56FromGitter<timotheecour> can anyone merge https://github.com/nim-lang/Nim/pull/13814 to unbreak nim CI?
09:25:15narimiranmerged
09:29:14*Trustable joined #nim
09:34:44AraqtoProve: (not (=> (and (= realExponent (- (* expSign exponent) fracExponent))
09:34:44Araq (= expNegative (< realExponent 0))
09:34:44Araq (= digits (+ kdigits fdigits))
09:34:44Araq (not (and (<= 16 (+ kdigits fdigits))
09:34:44Araq (not (and (<= (+ kdigits fdigits) 16) (<= firstDigit 8)))))
09:34:45Araq (<= absExponent 22)
09:34:47Araq (<= realExponent (- 1))
09:34:49Araq (<= (- 9223372036854775808) realExponent)
09:34:51Araq (<= realExponent 9223372036854775807)
09:34:55Araq (<= (- 9223372036854775808) expSign)
09:34:57Araq (<= expSign 9223372036854775807)
09:34:59Araq (<= (- 9223372036854775808) exponent)
09:35:01Araq (<= exponent 9223372036854775807)
09:35:03Araq (<= (- 9223372036854775808) fracExponent)
09:35:05Araq (<= fracExponent 9223372036854775807)
09:35:07Araq (<= (- 9223372036854775808) absExponent)
09:35:09Araq (<= absExponent 9223372036854775807)
09:35:11Araq (<= (- 9223372036854775808) digits)
09:35:13Araq (<= digits 9223372036854775807)
09:35:15Araq (<= (- 9223372036854775808) kdigits)
09:35:17Araq (<= kdigits 9223372036854775807)
09:35:19Araq (<= (- 9223372036854775808) fdigits)
09:35:21Araq (<= fdigits 9223372036854775807)
09:35:25Araq (<= (- 9223372036854775808) firstDigit)
09:35:27Araq (<= firstDigit 9223372036854775807))
09:35:29Araq (<= 0 absExponent)))
09:35:31Araq--> Z3 takes a loooooong time :-)
09:35:33*Araq is running drnim against the Nim compiler
09:35:37narimirancan someone please ban this Araq quy for posting multiline messages?
09:35:39*luis_ joined #nim
09:35:55Araqyeah, so annoying
09:36:02FromDiscord<Recruit_main707> smh, disruptek is freaking out rn
09:36:07FromDiscord<Recruit_main707> :p
09:36:56Araqinterestingly enough, eventually it did prove it :O
09:36:58*luis_ quit (Client Quit)
09:37:25ZevvAraq: you're not pasting long snippets in irc, are you?
09:37:29*luis_ joined #nim
09:37:45Zevvoh wait that was frowned upon my narimiran already :)
09:37:56Araqmy threshold is different
09:38:11AraqI don't consider this "too long" :P
09:39:00ZevvHmm, can Z3 prove it's own implementation to be correct?
09:39:34Araqthere is some joke about that
09:39:39ZevvI bet :)
09:39:52FromDiscord<Recruit_main707> new maximum lines of code before needing to use playground: 27 :0
09:39:56ZevvI guess in the end Z3 just takes sooo long that no one can ever tell if it will one day finish
09:40:04Zevvor "halt", as it is called in some jokes
09:40:56narimiran@Recruit_main707: quod licet Iovi, non licet bovi ;)
09:42:01FromGitter<alehander92> come on man just talk in german
09:42:15dom96what is Z3 proving about the Nim compiler?
09:42:33Araqit goes something like "Milner gave ML a formal semantics. When asked to give the formal semantics a formal semantics his head exploded"
09:42:33dom96just some predicates you've added or is there more to it? :)
09:43:16Araqit proves there are no "index out of bounds" errors
09:44:27FromDiscord<Recruit_main707> narimiran: Im 'non bovi >:(
09:45:47FromGitter<alehander92> is this like bon jovie
09:46:10FromGitter<alehander92> dom96 btw offtopic: cancellation to async
09:46:24FromGitter<alehander92> do you think it's a good idea to add a simple version of that
09:47:25Araqor maybe it was Robert Harper, hmm
09:49:10FromGitter<alehander92> dom96: one thing i imagine is one can just use something like token(i called it lifetime before) and have 1) manual checks (if token.stuff => ) or automatically inserted with `{.asyncCancellable.}`
09:49:33FromGitter<alehander92> but maybe there is a better way
09:51:22FromDiscord<clyybber> I always wondered if there is a way to get a time estimate out of Z3
09:51:53FromDiscord<clyybber> At least a very pessimistic one
09:52:27Araqwe figured out this morning it doesn't like 'x * x >= 0' ;-)
09:52:40Araqit can handle it but it tries to find a counter example
09:53:01Araqand it does it pretty much by brute force apparently so int64*int64 iterations
09:53:25Araqonce you restrict the x to 1..500 it's fast
09:53:29Araq:D
09:56:14*filcuc quit (Ping timeout: 240 seconds)
09:57:57dom96alehander92: we already have a simple version of that: close the socket and your futures will get cancelled
09:58:12Araqso it's stuck in nimParseBiggestFloat
09:59:14*krux02 joined #nim
10:01:15FromGitter<alehander92> dom96 hmm, but i want
10:01:22FromGitter<alehander92> only some futures to be cancelled
10:03:05FromGitter<alehander92> like, its not a super big deal, just wondered if people had concrete proposals on how would it work
10:03:36*luis_ quit (Remote host closed the connection)
10:09:26PMunchI've seen CancellationToken in C# which seems to work fairly well
10:09:49PMunchIt's manual checks, so all your procs need to implement it, but it's better than nothing
10:10:23FromGitter<alehander92> yeah but its very manual prone and still you need to return valid stuff from each one
10:10:29FromGitter<alehander92> manual=>error prone
10:10:41FromGitter<alehander92> i wondered if one can preempt somehow :D
10:11:00FromGitter<alehander92> but from what i've read one has to deal with all that cleanup
10:11:12PMunchYeah this is used more like this: `while (!cancellationToken.IsCancellationRequested) {<main loop of your task>}`
10:12:00FromGitter<alehander92> yes, but sometimes you just have a list of awaits and you'd want to if is cancelled: do this etc before each
10:12:03PMunchI mean I guess await could auto-check the cancellation token once it got back. And null out the result because it's probably not valid..
10:12:18FromGitter<alehander92> yeah thats what i imagine optionally
10:12:21*Guest13390 is now known as dadada
10:12:42PMunchI'm not quite sure I get how you want this to work..
10:12:46dadadaPMunch: hey, how are you?
10:12:51*filcuc joined #nim
10:12:54PMunchdadada, I'm godo
10:12:56PMunchgood*
10:13:12dadadagood to hear, any progress on the macroutils front?
10:13:19PMunchThinking about streaming after work, hopefully fixing it
10:13:24FromGitter<alehander92> well, asyncCancellable just inserts the `if cancelled: return default` after awaits inside
10:13:28PMunchHaven't done anything on it since the last stream
10:13:57dadadawhat was the result thereof?
10:14:13FromGitter<alehander92> but i wondered if one can just e.g. stop a parent function and async can just wake it up next time, return its default and ignore all the children calls of it
10:14:45PMunchI think I figured out where the issue was, and how to fix it, but I was unable to do it properly
10:15:16PMunchalehander92, stop a parent function?
10:15:59FromGitter<alehander92> e.g. it gets to poll, it finds the parent function from the callbacks and it just calls a cancel callback for it
10:16:15FromGitter<alehander92> and then removes it and all of its child futures from the list
10:16:38PMunchAre async procedures stored hierarchically though?
10:16:42FromGitter<alehander92> well no
10:16:46PMunchLike can you see these processes were started by this one
10:16:48PMunchAh
10:16:54FromGitter<alehander92> but in this case it would be useful to me
10:17:00FromGitter<alehander92> that's another idea i had:
10:17:10PMunchYeah the way you'd do it in C# would be to pass along the same cancellation token
10:17:11FromGitter<alehander92> async processing is a bit like cooperative multitasking
10:17:36PMunchSo whichever task starts execution will see that the token is requesting a cancellation, and then they will all shake out of the queue eventually
10:17:49FromGitter<alehander92> and multitasking in os-es has task managers: it would be cool to be able to see
10:17:52PMunchIt is co-operative multitasking
10:17:58PMunchJust not on multiple threads
10:18:15FromGitter<alehander92> thank you!
10:18:26PMunchHuh?
10:18:39FromGitter<alehander92> well, for the affirmation, i sometimes confuse all those
10:18:45PMunchAh :P
10:18:45FromGitter<alehander92> so in this case you can see
10:18:55FromGitter<alehander92> e.g. a tui similar to task manager
10:19:05Araq async processing IS cooperative multitasking
10:19:10FromGitter<alehander92> with the currently running/pending async functions
10:19:22FromGitter<alehander92> /futures
10:19:25FromGitter<alehander92> and debug metadata about hthem
10:19:33FromGitter<alehander92> the same way you see process tasks in task manager :D
10:19:46PMunchOoh, that would actually be pretty cool
10:19:50FromGitter<alehander92> probably doesnt make a lot of sense
10:20:17PMunchI mean the async scheduler does have all that information available to it
10:20:33FromGitter<alehander92> but its still like a task tree(even if we dont record which async functions call "await"/start which ones)
10:20:46FromGitter<alehander92> so a similar ui should be still useful
10:21:21PMunchIt wouldn't be a tree though if you don't have information about who is who
10:21:34FromGitter<alehander92> PMunch well one can probably add a bit of info like that in debug mode , like a simple list of child refs
10:21:40FromGitter<alehander92> only on start of an await
10:21:46FromGitter<alehander92> it wouldnt be such a big overhead
10:21:57PMunchYeah it wouldn't be horrible
10:22:41FromGitter<alehander92> and if one updates the tree visualization from time to time only this wouldn't also be too fatal at least for some programs
10:23:02*natrys joined #nim
10:23:21FromGitter<alehander92> its not a new idea, i remember chronos are doing many visualizations but i think they are doing statistics like counts of futures of each type/timestamps, this kind of stuff
10:24:11FromGitter<alehander92> (and the dom96 logging leaking thing iirc) but this one looks different to me
10:25:27*gmpreussner quit (Ping timeout: 260 seconds)
10:25:57*gmpreussner joined #nim
10:27:12FromGitter<alehander92> basically something like async-htop
10:28:25*filcuc quit (Ping timeout: 264 seconds)
10:29:51PMunchI mean, if you just allow async to take a Channel argument and then send over the channel some debug information every time you do things to it you can spin up a thread and do whatever you want with that information (log it to a file, aggregate it, visualise it, expose it over HTTP)
10:32:13FromGitter<alehander92> yeah i think they kinda somehow wanted to do something like that in chronos using https://github.com/status-im/nim-metrics
10:32:54FromGitter<alehander92> but i am not sure about the channel argument, that would change the api too much imo
10:33:18FromGitter<alehander92> i can imagine just a global `registerDebugChannel` though
10:34:28FromGitter<kayabaNerve> I have the Nim compiler failing on an assertion check (```Error: unhandled exception: closureiters.nim(397, 9) `n.kind == nkStmtListExpr` [AssertionError]```). How can I debug this? koch debug? I tried `-- verbosity:3` but it seems to happens a few seconds after it finishes processing the last lines of Nim code.
10:35:22*couven92 joined #nim
10:36:17*abm joined #nim
10:36:22PMunchalehander92, yeah you could have `registerDebugChannel` that just registers the channel globally.
10:36:56FromGitter<alehander92> PMunch but what would we pass
10:37:27PMunchWhat do you mean?
10:37:34FromGitter<alehander92> as accessing a data structure full of refs from another thread is not trivial without some annotations right
10:37:54FromGitter<alehander92> ah, you mean one can just send simple "events"
10:37:58PMunchYeah
10:38:06FromGitter<alehander92> and to construct data structures/other stats in the thread
10:38:11PMunchSwitched to this thing, fulfilled this future, etc.
10:38:50FromGitter<alehander92> yeah this is possible, i wonder if its a lot of overhead tho with all the strings
10:38:56PMunchEssentially logging things, but with enough information to see everything that's going on
10:39:03FromGitter<alehander92> one can use enum/future id-s and mapping of course
10:39:04PMunchDoesn't have to be strings
10:39:15PMunchYeah
10:39:53FromGitter<alehander92> yeah, its doable
10:40:14FromGitter<alehander92> and one can indeed configure
10:40:43FromGitter<alehander92> the "sender" to e.g. send each event or just some types of events, or just a % of some events
10:41:34FromGitter<alehander92> which i guess is what chronos does to monitor some metrics statistically
10:41:59FromGitter<alehander92> but that's just on theory not too important
10:44:20PMunchWell if it's only for debugging then it shouldn't be too bad
10:44:39PMunchBut yeah, if you have events as an enum you can provide a set to filter by
10:48:02FromGitter<kayabaNerve> PMunch: Do you have a second? Sorry for solo'ing you out, I just trust you and this bug is weird as hell.
10:48:15PMunchHaha, sure
10:48:23FromGitter<kayabaNerve> https://github.com/nim-lang/Nim/issues/8243
10:48:33FromGitter<kayabaNerve> This bug from 2017 was a regression and is closed. I have the exact same error.
10:48:49FromGitter<kayabaNerve> I have no idea why and no chance of a MRE.
10:49:16FromGitter<kayabaNerve> I do have a traceback from a debug Nim compiler. My question for you becomes is it worth it to file an issue?
10:49:42FromGitter<kayabaNerve> Generally if I can't prove an issue without linking a large codebase, I don't bother.
10:49:43FromGitter<kayabaNerve> https://pastebin.com/d4jjbLbQ
10:50:01FromGitter<kayabaNerve> ^ Traceback for reference. It seems to solo out the location despite not specifying the cause.
10:50:14FromGitter<kayabaNerve> (and yes, I tried 1.0.6 and devel)
10:50:55FromGitter<kayabaNerve> Oh. I also did test that sample code. It's not that regression; just the same error and both dealing with async.
10:53:06*filcuc joined #nim
10:53:52PMunchHmm, I'd be curious to see what node it actually did get passed
10:54:05PMunchI mean a minimal example is always the best when you're creating an issue
10:54:12FromGitter<kayabaNerve> Yeah, I may write some debug statements myself.
10:55:25*dadada quit (Ping timeout: 264 seconds)
10:55:33FromGitter<kayabaNerve> Yeah. I've unfortunately not been able to make them lately. I also found a bug in the stdlib where sockets aren't always usable when Nim says they are. It happens when Nim wins a race against the OS. That said, I also couldn't replicate it with a MRE. My guess is I have a balance of sync and async load which causes it to trigger on random chance? But honestly no idea.
10:55:46FromGitter<kayabaNerve> I just ported my entire app from asyncdispatch/asyncnet to chronos.
10:57:09PMunchTriggering async and/or threaded errors in a MRE is indeed hard..
10:58:38FromGitter<kayabaNerve> exprToStmtList expects a Statement List Expr. It is not being handed one by lowerStmtListExprs. lowerStmtListExprs is calling itself on the children of `nkCallKinds, nkChckRange, nkChckRangeF, nkChckRange64` where it finds a `nkCast, nkHiddenStdConv, nkHiddenSubConv, nkConv, nkObjDownConv,`.
10:58:58FromGitter<kayabaNerve> So it does seem to be related? That one bug had a cast in it.
10:59:07*filcuc quit (Ping timeout: 258 seconds)
10:59:31FromGitter<kayabaNerve> So I just need to find every single cast in my branch. Great.
10:59:39FromGitter<kayabaNerve> Eh. Better then being stuck with no idea.
10:59:49FromGitter<kayabaNerve> If I do find the problem, I'll attempt a MRE.
11:00:17PMunchHmm, strange that a cast should trip something like that, no?
11:01:56FromGitter<kayabaNerve> I don't have much experience with the internals :P That's why I sought your advice.
11:02:15FromGitter<kayabaNerve> I have written some macros, so I recognize the kinds well enough, but that's about it.
11:04:40FromGitter<alehander92> @kayabaNerve btw
11:04:50FromGitter<alehander92> if you use linux, you can record some runs with `rr` so
11:05:00FromGitter<alehander92> once your record a run with the error in it
11:05:06FromGitter<alehander92> you can reproduce it then many times
11:05:22FromGitter<kayabaNerve> `rr nim c -r main` or...?
11:05:36FromGitter<alehander92> yes `rr <program> <args>`
11:05:53FromGitter<alehander92> then one you manage to reproduce it once under it
11:06:35FromGitter<alehander92> then you can run `rr replay` and you get a gdb for it (which can be ran in the same way many times)
11:06:36PMunchWait what?
11:06:39PMunchWhat does rr do?
11:07:04FromGitter<alehander92> it records program runs so they can be replayed in the same way
11:07:19FromGitter<alehander92> wrapping sources of nondeterminism like syscalls etc
11:07:41FromGitter<kayabaNerve> Interesting. If only I knew how to use GDB that well :P
11:08:04FromGitter<alehander92> well its just a normal debugger :P you can even target your visual editor debugger to it
11:08:09FromGitter<alehander92> with some tweaks in the settings
11:08:31FromGitter<alehander92> as i think many of them can call `gdb` internally
11:08:34PMunchHoly shit, how have I never known about this until now?!
11:08:42FromGitter<alehander92> dude i spam about it often :D
11:08:54FromGitter<alehander92> https://rr-project.org/
11:09:11FromGitter<kayabaNerve> If only I had a visual editor debugger
11:09:26FromGitter<alehander92> well, gdb itself is simple really
11:09:41dom96kayabaNerve: why ported to chronos?
11:09:44FromGitter<alehander92> and the good thing about `rr` is that this gives you fast reverse debugging
11:09:46FromGitter<kayabaNerve> Yeah, and `echo n` is even more simple :P
11:09:51FromGitter<alehander92> like reverse-continue etc
11:10:08FromGitter<kayabaNerve> dom96: Because I have an unfixable bug in asyncnet which is consistent yet I can't create a MRE out of it.
11:10:35FromGitter<kayabaNerve> So my only options are to fix it myself in asyncnet, which I can't do it, or fix it by leaving asyncnet.
11:10:36dom96interesting, and chronos doesn't have it?
11:10:37FromGitter<alehander92> PMunch btw if you're interested we can try to do a simple version of that async debuginfo thing
11:10:48dom96what does the bug look like?
11:11:17FromGitter<kayabaNerve> dom96: I have no idea if chronos has it. A bug in the Nim compiler won't let me compile my chronos code.
11:11:48dom96nice
11:11:49FromGitter<kayabaNerve> A socket being accepted crashes the entire async runtime when the standard library can't call fcntl on the file descriptor
11:11:59FromGitter<kayabaNerve> I brought it up a few days ago and I was told its a TOCTOU
11:12:15FromGitter<kayabaNerve> It'd be fine if it was catchable, but it's only catchable @ runForever, which loses all async ops
11:12:52FromGitter<kayabaNerve> PMunch: I may have recreated the worst debugging output to ever exist.
11:13:42FromGitter<kayabaNerve> Apparently, you can't dump the tree of PNode (I assumed they were the internal cousin of NimNodes). That said, they do have a $ defined.
11:14:02FromGitter<alehander92> you can do that
11:14:06FromGitter<kayabaNerve> https://pastebin.com/6w0Eq2s5
11:14:09FromGitter<alehander92> i think you need to write `debug n`
11:14:14FromGitter<alehander92> if `n` is the node
11:14:22FromGitter<kayabaNerve> I tried dumpTree(n) and import macros; dumpTree(n)
11:14:33FromGitter<alehander92> no no, this is only for macros
11:14:54FromGitter<kayabaNerve> I'm referring to dumping the PNode in a decent format
11:15:07FromGitter<kayabaNerve> Not the above pastebin text
11:15:14PMunchHaha, so those are the lines of code or something?
11:15:28PMunchI'm guessing line 38 is your issue though
11:15:32FromGitter<kayabaNerve> They're a printed PNode.
11:15:45FromGitter<kayabaNerve> What does `$`(n: PNode) return?
11:15:56PMunchHopefully a string..
11:16:02FromGitter<kayabaNerve> Anyways. It does inform me of the area. This is post transformation.
11:16:22FromGitter<alehander92> no no @kayabaNerve thats what `debug n` does
11:16:26FromGitter<kayabaNerve> syncAwait is just a custom function to handle time outs/multiple possible futures where only one matters.
11:16:27FromGitter<alehander92> it prints it in a goof romat
11:16:36FromGitter<kayabaNerve> Thanks
11:16:41FromGitter<alehander92> i think*
11:17:50FromGitter<kayabaNerve> `Error: undeclared identifier: 'debug'`
11:18:05FromGitter<alehander92> sorry!
11:18:05FromDiscord<clyybber> kayabaNerve: import astalgo
11:18:07FromGitter<alehander92> let me try
11:18:10FromGitter<alehander92> ah ok
11:19:58FromDiscord<clyybber> kayabaNerve: Can you post the stacktrace?
11:19:58FromGitter<kayabaNerve> It sounds like converting a value, named chronos internal future, to the type of Future[T], is the problem.
11:20:12*silvernode joined #nim
11:20:18FromGitter<kayabaNerve> Seems to be compiling. Will have the astalgo output in a minute or two
11:20:18FromGitter<kayabaNerve> https://pastebin.com/d4jjbLbQ
11:20:33FromGitter<alehander92> ahh
11:20:33FromGitter<kayabaNerve> I posted it a bit ago :P
11:20:44FromGitter<kayabaNerve> Recompiled nim
11:20:46FromDiscord<clyybber> oh, missed it
11:20:51FromGitter<kayabaNerve> All good
11:20:52FromGitter<alehander92> i had something like that problem while trying to translate some code of chronos to asyncdispatch
11:20:56PMunchHmm, it would be cool if assert could print out the result of the non-constant parts of your expression..
11:20:57FromDiscord<clyybber> kayabaNerve: Can you try devel too?
11:21:17FromGitter<kayabaNerve> clybber: I tried 1.0.6. devel doesn't work as chronicles doesn't work under devel.
11:21:28FromDiscord<clyybber> I see
11:21:36PMunchLike assert(n.kind == nkStmtListExpr) would print something like "Assertion failed: n.kind = nkNilLit != nkStmtListExpr"
11:21:40FromGitter<kayabaNerve> Since 1.0.6 didn't work, I reverted to 1.0.4 which is what my entire ecosystem uses.
11:22:07FromGitter<alehander92> kayabaNerve can you linked the internal future conversion error
11:22:09FromGitter<kayabaNerve> Got the output
11:22:34FromDiscord<clyybber> kayabaNerve: I'd try pinging yglukhov
11:23:09FromGitter<Clyybber> PMunch: You can do assert n.kind == nkStmtListExpr, $n.kind
11:23:52FromGitter<kayabaNerve> I didn't know what cut off to use, so I grabbed 83 kB https://pastebin.com/tWJifJNz
11:24:02FromGitter<kayabaNerve> The tail is probably the part to look at
11:24:25FromGitter<kayabaNerve> Here's the last node it handled: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e832869b72a4b77021e57b0]
11:24:38PMunchClyybber, yeah I know
11:24:39FromGitter<Clyybber> its a nkSym, this isn't the issue
11:24:43FromGitter<Clyybber> I think..
11:24:45PMunchBut that's more typing
11:24:50FromGitter<Clyybber> yeah :P
11:24:52FromGitter<kayabaNerve> To clarify placement: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e8328842556e77c713e4cd8]
11:25:03PMunchAnd sometimes it's a call
11:25:17PMunchSo e.g. assert(someCheckProc())
11:25:20FromGitter<Clyybber> @kayabaNerve I think you should try expanding all the macros
11:25:51FromGitter<kayabaNerve> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e8328bff7cff9290c8451c1]
11:25:54*silvernode quit (Ping timeout: 240 seconds)
11:26:02FromGitter<kayabaNerve> Is this it?
11:26:07FromGitter<kayabaNerve> I think it is the sym
11:26:08PMunchI would want that to be rewritten as `let r = someCheckProc(); assert(r, "someCheckProc() = " & $r & " != true")`
11:26:13FromGitter<Clyybber> @kayabaNerve It doesn't have to be
11:26:25FromGitter<kayabaNerve> @Clyybber That's the exprToStmtList call
11:26:26FromGitter<Clyybber> It could be that its not transformed elsewhere so it reaches that code
11:26:30*tane joined #nim
11:26:38FromGitter<Clyybber> I think that was the cause of the original issue
11:27:02FromGitter<Clyybber> @yglukhov Hey, I think you know the most about this stuff :)
11:27:02FromGitter<kayabaNerve> Wait, my bad, it could be this one: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e832906bd09254f83eadbb2]
11:27:29FromGitter<kayabaNerve> Honestly, I have no idea. I have snippets that look like it and am trying here.
11:27:41FromGitter<kayabaNerve> PMunch: I'll check the exact type now
11:27:46FromGitter<Clyybber> @kayabaNerve Can you try expanding the macros and minifying it?
11:27:52FromGitter<Clyybber> Or is it not possible?
11:29:34FromGitter<kayabaNerve> @Clyybber I could fork chronos and add dumpTree statements?
11:29:46FromGitter<kayabaNerve> I know the general area this is occurring?
11:30:00FromDiscord<clyybber> You could also add expandMacros in your code
11:30:18FromGitter<kayabaNerve> TIL that's a thing
11:33:16FromGitter<kayabaNerve> PMunch: Wasted a few minutes on a compilation run where I forgot to recompile Nim in between. Just finished recompiling Nim.
11:34:35PMunchAny process with more than two steps should be a script!
11:34:46FromGitter<kayabaNerve> PMunch: `debug n; echo n.kind; echo "\r\n"`
11:34:52FromGitter<kayabaNerve> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e832adc5e0bd65308da83fd]
11:35:08FromGitter<Clyybber> @kayabaNerve Not sure if you are already using that, but ./koch temp builds the compiler
11:35:14FromGitter<Clyybber> And puts it in bin/nim_temp
11:35:27FromGitter<Clyybber> Which is handy and faster than doing ./koch boot
11:35:29FromGitter<kayabaNerve> @Clyybber I'm using koch boot. koch temp doesn't support threads.
11:35:38FromGitter<Clyybber> Eh what?
11:35:45FromGitter<kayabaNerve> Yeah, my code has channels. It doesn't always spawn a thread but always declares channels.
11:35:58FromGitter<Clyybber> But ./koch temp builds the compiler
11:35:58FromGitter<kayabaNerve> I'm sure there's a flag for it. I just don't know it.
11:36:09FromGitter<Clyybber> You do ./koch temp
11:36:13FromGitter<kayabaNerve> Without spawn support if you just use `./koch temp`
11:36:15FromGitter<Clyybber> and then you invoke nim normally
11:36:17FromGitter<kayabaNerve> I tried that originally
11:36:24FromGitter<Clyybber> And just replace nim with nim_temp
11:36:27FromGitter<kayabaNerve> It didn't build with support for spawn
11:36:35FromGitter<kayabaNerve> I tried that. It didn't work.
11:36:35FromGitter<Clyybber> Huh
11:36:50FromGitter<Clyybber> Araq: Is that supposed to happen?
11:38:05Araqyeah, 'koch temp' leaves out a bunch of modules
11:38:12Araqso that we get faster compiles
11:38:19FromGitter<kayabaNerve> https://pastebin.com/5DjKjfKx
11:38:24FromGitter<kayabaNerve> It looks like this is the failing PNode
11:38:40FromGitter<kayabaNerve> This cast statement tries to call a StmtListExpr only function on a symbol
11:39:11FromGitter<kayabaNerve> So I assume I should create an issue with this and the stack trace? Anyone else have any advice before I do?
11:40:05FromGitter<kayabaNerve> Because to be honest, I believe this hits the peak of my debugging skills. I could try to get the expanded macro data, yet I'm not sure what that would say that the stack trace and PNode wouldn't.
11:40:25FromGitter<Clyybber> @kayabaNerve It would allow you to create a minimal example possibly
11:40:41FromGitter<Clyybber> @kayabaNerve Because this PNode may or may not be the cause.
11:40:58FromGitter<kayabaNerve> ... I mean, it's the one that's failing the assert, and then I grabbed the parent one or two levels up.
11:41:06FromGitter<Clyybber> It may be the symptom, but it could be that it ends up here because its not getting transformed somewhere else
11:41:09FromGitter<kayabaNerve> Right
11:41:19FromGitter<Clyybber> And we have no way to investigate that
11:41:22FromGitter<Clyybber> Without some code
11:41:41FromGitter<alehander92> i think i had an error like that
11:41:41FromGitter<Clyybber> https://github.com/nim-lang/Nim/issues/8243 is actually a good example for that
11:42:00FromGitter<Clyybber> If you look at the fix
11:51:19FromGitter<alehander92> cant find it hm
11:51:19ldlework.bef
11:58:02FromGitter<kayabaNerve> What's a nnkCommand node?
11:58:09FromGitter<alehander92> `a b, c`
11:58:12FromGitter<kayabaNerve> Just to be clear here. I understand the basic idea.
11:58:22FromGitter<alehander92> command syntax is like calls without parens iirc
11:58:39FromGitter<kayabaNerve> Got it, thanks.
11:58:53FromGitter<alehander92> (offtopic Araq, so what do you need for sourcemaps? just to fix the code and try to merge it)
11:59:32*hax-scramper quit (Ping timeout: 256 seconds)
12:01:54*hax-scramper joined #nim
12:05:58FromGitter<kayabaNerve> MRE'D!
12:06:16FromDiscord<clyybber> nice!
12:06:59FromGitter<kayabaNerve> It's a complex as hell MRE
12:07:09FromGitter<alehander92> give it
12:08:11dom96is this an MRE for the async bug?
12:08:36FromGitter<kayabaNerve> dom96: For the TOCTOU?
12:08:44FromGitter<kayabaNerve> The one that crashes the entire async runtime when accepting a socket?
12:08:46FromGitter<kayabaNerve> I wish.
12:09:02dom96yeah
12:09:10FromGitter<kayabaNerve> It's one for a failure in Nim's ability to handle chronos generated code.
12:09:19dom96pity
12:09:27FromGitter<kayabaNerve> Don't get me wrong, chronos could also be at fault, but Nim is asserting instead of erroring.
12:09:33FromGitter<kayabaNerve> dom96: I have a reproducible thing.
12:09:39FromGitter<kayabaNerve> It's just not a MRE.
12:09:50dom96huh, that's fine
12:09:52FromGitter<kayabaNerve> It's a 12k line Nim project with a Nimble build script and Python script to trigger it.
12:10:40FromGitter<kayabaNerve> https://github.com/MerosCrypto/Meros ⏎ https://github.com/MerosCrypto/Meros/issues/141
12:11:03FromGitter<alehander92> dom96 we have like two feature requests for asyncdispatch, where should i write them down
12:11:31dom96the issue tracker
12:11:32FromGitter<kayabaNerve> That issue documents how to trigger it reproducibly. You need to compile with release on, and it should be noted the current Nimble script uses debug. It's easier to trigger with clang than gcc.
12:11:46FromGitter<alehander92> but the nim one or the rfc one
12:12:04FromGitter<kayabaNerve> Nim setup is `nimble build`. Python setup is in the README under PythonTests/. I don't think you'll be invested enough, but I'd appreciate if you looked it over.
12:12:08FromGitter<alehander92> @kayabaNerve oh man
12:12:28FromGitter<kayabaNerve> I did warn him
12:12:30FromGitter<kayabaNerve> It's not a MRE
12:12:38FromGitter<kayabaNerve> I'm minimizing my chronos MRE even further right now
12:12:42FromGitter<Clyybber> do you need python?
12:12:44FromGitter<Clyybber> ok
12:12:46*sleepyqt_ joined #nim
12:13:47FromGitter<kayabaNerve> I wrote a Python3 script to trigger it. You don't need Python though.
12:14:02FromGitter<kayabaNerve> It's a decentralized application. A network of 5 nodes will cause a crash over a few days.
12:14:22FromGitter<Clyybber> ah
12:14:32FromGitter<Clyybber> I thought you were talking about the chronos MRE
12:14:43FromGitter<Clyybber> now it sounds like chronos is a military
12:14:45FromGitter<kayabaNerve> The Python script, with release and clang, will trigger after 20k sockets. ~30 seconds.
12:15:25FromGitter<kayabaNerve> The chronos MRE is 32 lines.
12:15:39*sleepyqt quit (Ping timeout: 250 seconds)
12:16:04FromGitter<kayabaNerve> Lines of self contained Nim. Just requires chronos.
12:16:17FromGitter<Clyybber> nice
12:16:26FromGitter<Clyybber> ready for an issue then
12:16:27dom96kayabaNerve: does it take 5 days to trigger? :)
12:17:03dom96oh, sorry, just read the rest of the messages
12:18:06dom96Can someone else try to reproduce until I get time tonight to have a look? Would be nice to know that it's reproducible by other people
12:18:53FromGitter<kayabaNerve> dom96: 30 seconds with the script. Multiple VPSs of mine crashed thanks to (18.04), along with my Arch home desktop and some other people's VPSs.
12:18:59FromGitter<kayabaNerve> No idea about Windows.
12:20:31dom96okay, I wonder if it'll repro on macOS
12:20:43dom96I'll write a sticky to give it a try tonight
12:20:50*filcuc joined #nim
12:23:32FromGitter<kayabaNerve> Thanks
12:23:59FromGitter<kayabaNerve> And then here's the Chronos/Nim MRE https://github.com/nim-lang/Nim/issues/13815
12:24:23FromGitter<Clyybber> Might wonna tag yglukhov there
12:24:36FromGitter<kayabaNerve> (saying that for PMunch/Clybber/alehander92 and co, not asking you (dom96) to look it over)
12:24:46FromGitter<kayabaNerve> On Gitter or GitHub?
12:25:13FromGitter<Clyybber> github
12:25:17FromGitter<Clyybber> already pinged him here
12:25:18*dadada joined #nim
12:25:40*dadada is now known as Guest21830
12:25:51FromGitter<kayabaNerve> Fair enough
12:27:24PMunchHmm, a lot going on in that MRE
12:27:34PMunchNeed to dig through it a bit to figure out what's wrong
12:27:55FromGitter<Clyybber> You might be able to get rid of the chronos dependency with a few expandMacro calls
12:28:01FromGitter<Clyybber> Not sure tho
12:29:33FromGitter<alehander92> sorry i thought i will try to repro
12:29:35FromGitter<alehander92> but i got an error
12:29:47FromGitter<alehander92> probably older nim/or newer version for me
12:29:51FromGitter<kayabaNerve> PMunch: It's combining commands, calls, symbols, dot expressions, function pointers, and what Nim calls GC unsafety
12:29:56FromGitter<alehander92> i'll take a look at the compiler thing
12:30:26FromGitter<kayabaNerve> It probably can be minimized even further/chronos can be removed with expandMacro. I just have to go to sleep.
12:31:02FromGitter<Clyybber> ok gn8
12:31:04PMunchDid you try to simply remove the assert?
12:31:13PMunchJust to see what would happen :P
12:31:17PMunchAh, night
12:32:12FromGitter<kayabaNerve> PMunch: No because my final solution can't modify the standard library and I'm not going to be the guy who submits a PR to remove a check to fix his own bug when he has very little experience with the Nim compiler internals :p
12:32:54FromGitter<kayabaNerve> (I have no idea how to properly test it; even fully testing it in my codebase would take a few days)
12:34:42PMunchI would just be curious if it would just immediately fail on something else, or if that check is there to guard your from some future issue
12:36:49PMunchOh fun, now we're entering the period where the country-wide stores start pushing spring-time products while we still have over a meter and a half of snow :P
12:37:46FromGitter<kayabaNerve> My guess is the assertion is so when a Nim compiler developer messes up, the assertion points it out. This isn't supposed to be user facing afaict.
12:38:36PMunchSure, but the question is if it is actually an error, or someone just being overly cautious
12:41:56FromGitter<alehander92> poor north norwaygians
12:42:32*rockcavera joined #nim
12:43:18PMunchI think I might seriously be snowed in at the moment, I've heard snow falling from the roof all day, but I'm too scared to look outside..
12:43:35PMunchI just finished shoveling the last of it on Sunday :(
12:45:12FromGitter<alehander92> people in sofia did have snow this month actually
12:45:16FromGitter<alehander92> it was very unexpected
12:45:27FromGitter<alehander92> but not this kind of .. snowfall near 31 march
12:45:29FromGitter<alehander92> :D
12:45:33FromGitter<alehander92> probably
12:46:28PMunchOur record amount was on April 29th..
12:46:38PMunch1997
12:46:48FromGitter<alehander92> how much
12:46:53PMunch240cm
12:47:13FromGitter<alehander92> why do you even not use ski for shopping
12:47:13PMunchThat's on flat undisturbed ground
12:47:26PMunchBecause taking the car is easier?
12:47:33PMunchSome people do ski to the store though
12:47:36FromGitter<alehander92> but funnn and gigles
12:47:42PMunchOr take a "spark"
12:47:51FromGitter<alehander92> yeah i imagine its like biking in southern countries
12:47:52FromDiscord<Recruit_main707> if you at least drifted all your way to the mall...
12:48:11FromGitter<alehander92> what is spark
12:48:16PMunchhttps://scontent-lga3-1.cdninstagram.com/v/t51.2885-15/e15/914562_693563127342889_164240081_n.jpg?_nc_ht=scontent-lga3-1.cdninstagram.com&_nc_cat=101&_nc_ohc=YN4lNLM3XiMAX-KLuX8&oh=f3fba8eebb9ab383098af6558a1767a5&oe=5E866E3A
12:48:19PMunchOne of those
12:48:31FromGitter<alehander92> thats a "шейна" :D
12:48:41*FromDiscord <Recruit_main707> trineo
12:48:55FromGitter<alehander92> ahhh not really
12:49:03PMunchWhen I google that I just get sleds..
12:49:18FromDiscord<Recruit_main707> light trineo
12:49:22FromGitter<alehander92> yeah in this one you're actually behind
12:49:26FromGitter<alehander92> and standing up
12:49:29FromGitter<alehander92> not like in sleds
12:49:30PMunchYeah
12:49:36PMunch"Spark" literally means "kick"
12:49:50FromGitter<alehander92> but whats the point , to just carry baggage in the thing in front
12:49:50PMunchThe full name is "sparkstøtte" which translates to "kick support"
12:50:15PMunchWell, you stand on the skates in the back, then you kick to create movement
12:50:23PMunchIt's like a scooter, but for the winter
12:50:37PMunchAnd you can put a kid or a bag in front
12:50:41FromGitter<alehander92> but isnt the movement similar to what you do when ski on ground
12:50:51FromGitter<alehander92> like ski pushing chair
12:50:51PMunchWell, not quite
12:51:11PMunchAnd this can be used with any kind of shoe, just go outside grab it and go
12:53:18*silvernode joined #nim
12:53:50FromGitter<alehander92> ahh, ok i have to see it
12:53:54FromGitter<alehander92> sounds useful
12:54:12FromGitter<alehander92> i am a big fan of this kind of alternative movement, dreaming of channels and boats trhough sofia
12:54:41FromGitter<alehander92> but i'd imagine more like a ski highway from tromso to oslo
12:57:23FromGitter<alehander92> https://www.visitnorway.com/places-to-go/northern-norway/tromso/things-to-do/ wait
12:57:28FromGitter<alehander92> do you have the dogs thing
12:58:12*waleee-cl joined #nim
12:59:08*dddddd joined #nim
13:03:42*silvernode quit (Ping timeout: 258 seconds)
13:05:06*lritter joined #nim
13:10:23PMunchSure
13:10:33PMunchBut no-one uses it for transport around town :P
13:29:08*liblq-dev joined #nim
13:33:08*silvernode joined #nim
13:48:44*Vladar quit (Quit: Leaving)
13:53:08FromGitter<alehander92> пп
13:53:09FromGitter<alehander92> mm* ok
13:53:20*tefter quit (Quit: WeeChat 2.7.1)
13:54:17FromGitter<Clyybber> Quick question: Do we use ``someVariable`` in doc comments or `someVariable` ?
13:54:47FromGitter<Clyybber> "``someVariable``" vs "`someVariable`"
13:55:02FromGitter<Clyybber> Double \` or single \`
13:55:05FromGitter<Clyybber> ?
13:57:34AraqSingle if it refers to a parameter
13:57:47Araqsingle or double otherwise ;-)
13:58:06FromGitter<Clyybber> Ok :)
14:03:04*silvernode quit (Ping timeout: 256 seconds)
14:18:31*pbb quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
14:20:08*pbb joined #nim
14:24:56*pbb quit (Ping timeout: 246 seconds)
14:25:16*pbb joined #nim
14:37:23*Kaivo quit (Quit: WeeChat 2.7.1)
14:38:56*Kaivo joined #nim
14:44:14*filcuc quit (Ping timeout: 240 seconds)
14:44:20*endragor quit (Remote host closed the connection)
14:44:43*aEverr quit (Ping timeout: 250 seconds)
14:46:54*arecaceae quit (Read error: Connection reset by peer)
14:47:16*arecaceae joined #nim
14:48:11*hax-scramper quit (Ping timeout: 250 seconds)
14:49:02*hax-scramper joined #nim
14:54:54*mjsir911 quit (Quit: Goodbye, World!)
14:55:11*mjsir911 joined #nim
14:59:47*aEverr joined #nim
15:00:58FromGitter<alehander92> i am debugging https://github.com/nim-lang/Nim/issues/13815 and i think i can
15:01:07FromGitter<alehander92> try to generate a simpler rep
15:01:21FromGitter<alehander92> basically one can go backwards from the assertion
15:01:31FromGitter<alehander92> and try to construct a breaking case
15:02:39FromGitter<alehander92> of course i use the existing example node here as a start.
15:03:48Araqty
15:09:39*silvernode joined #nim
15:12:47*Vladar joined #nim
15:13:55FromGitter<alehander92> awesome i got a small repro
15:17:36FromGitter<alehander92> https://github.com/nim-lang/Nim/issues/13815#issuecomment-606691497
15:28:39lbartthe build.sh file included in the github release is created with niminst right? If I want to add arm64 for FreeBSD, I just have to add in https://github.com/nim-lang/Nim/blob/devel/compiler/installer.ini#L12
15:28:54Araqcorrect
15:29:31lbartthanks. So I'll open a PR soon.
15:36:34*silvernode quit (Ping timeout: 256 seconds)
15:41:01FromGitter<alehander92> so basically the bug is that some `exprToStmtList` are not guarded by `if node with right kind`
15:41:12FromGitter<alehander92> i think this can be solved with z3 eventually :D
15:41:29FromGitter<alehander92> we can add such `{.require` to many procs with similar asserts
15:42:14FromGitter<alehander92> and catch many similar problems statically (except for cases where such a case should've been resolved far away)
15:43:27Araqonly with 'drnim --assumeUniqueness'
15:44:12Araqwhich isn't a thing yet but I figured out that 'n: PNode' destroys everything otherwise
15:44:47Araqthere is always some potential alias to the node and there is always some unknown function that can mutate 'n' secretly
15:45:22Araqofc 'owned' would also help
15:46:04*silvernode joined #nim
15:46:37FromGitter<alehander92> Araq hmmm yeah
15:46:41FromGitter<alehander92> but this mode sounds useful
15:47:03FromGitter<alehander92> and overally many case objects use similar asserts just because there wasnt a better way to actually write that down
15:47:38Araqthe code base suffers greatly from the lack of linear types :-)
15:47:40FromGitter<alehander92> all those assert kind is something are actually a `requires` candidate, as its usually better to just prove you call such functions only in the correct branches
15:47:49Araqyup
15:49:01FromGitter<alehander92> ok, exciting
15:50:02AraqI'm still torn between AST vs CFG :-(
15:50:31FromGitter<alehander92> for which case?
15:50:35Araqdrnim
15:51:03FromGitter<alehander92> it works with ast-s right now? which usecases need cfg
15:51:19Araq'return' and 'break', as usual
15:51:51Araq i < a.len and use(a[i]) also seems easier with a proper CFG
15:52:17Araqwho knows if we model the shortcut evaluation of 'and' properly otherwise
15:52:38Araq'and' is control flow that looks like an operator
15:52:49*thomasross joined #nim
15:57:43*silvernode quit (Ping timeout: 260 seconds)
15:59:28FromGitter<alehander92> hm, can `use(a[i])` be a part of a require
16:00:52FromGitter<alehander92> that's actually `relevant typing`, isnt it
16:11:56AraqI don't know the term 'relevant typing'
16:13:25FromGitter<alehander92> forgive me
16:13:48FromGitter<alehander92> when `var` is used at least once
16:13:50FromGitter<alehander92> afaik
16:14:32Araqpossible, so similar to affine typing
16:14:35FromGitter<alehander92> (once: linear, <= once: affine, >= once: relevant, once in order(stack like): ordered): but thats just my wikipedia :D
16:15:05FromGitter<alehander92> yeah, they are all cases of substructural typing
16:58:44*Guest21830 quit (Ping timeout: 256 seconds)
17:00:12*silvernode joined #nim
17:06:18*dadada joined #nim
17:06:41*dadada is now known as Guest38915
17:06:44*jjido joined #nim
17:07:14*silvernode quit (Ping timeout: 240 seconds)
17:29:44*Guest38915 quit (Ping timeout: 258 seconds)
17:35:31*PMunch quit (Quit: leaving)
17:36:18*dadada__ joined #nim
17:42:11*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:44:28*sagax quit (Remote host closed the connection)
17:48:09*silvernode joined #nim
17:51:34*sagax joined #nim
17:56:30*fanta1 joined #nim
17:59:43*dadada__ quit (Ping timeout: 250 seconds)
18:02:53FromGitter<alehander92> ok Araq
18:03:09FromGitter<alehander92> how can i solve the problem that i cant return in async function from a macro
18:03:36FromGitter<alehander92> (it's not fixed by async macro so it leads to yielding nil error)
18:03:42FromGitter<alehander92> i cant think of any workaround
18:03:49FromGitter<alehander92> as macros are expanded lately?
18:04:33FromGitter<alehander92> maybe return result
18:06:10*dadada joined #nim
18:06:33*dadada is now known as Guest80919
18:07:15leorizealehander92: can't return in function from a macro?
18:10:56FromDiscord<Recruit_main707> what are the plans for wasm?
18:11:41leorizenone atm
18:12:26FromDiscord<Recruit_main707> like, not even fan made?
18:12:33Yardaniconlvm exists
18:12:39Yardanicoand there's Emscripten for C->Wasm
18:12:41FromGitter<Nickiel12> I am trying to install nim on a raspberry pi, but the apt-get only installs 0.16, and jester requires V>=1.0.0. I tried using a nightly build, but now there isn't a nimble command available
18:12:55Yardanico@Nickiel12 you should add it to your $PATH
18:13:13FromGitter<Nickiel12> but where is it?
18:13:22blackbeard420when using asynchttpserver is the best way to access a global variable from within the callback a ptr? otherwise you get the `Not GC-Safe` error
18:13:31FromGitter<Nickiel12> I can't find a folder it might be in
18:13:47YardanicoHave you considered using choosenim?
18:14:11FromGitter<Nickiel12> I don't think it works for raspberry pi 3b+
18:14:16AraqNickiel12: run 'koch tools'
18:14:33FromGitter<Nickiel12> "command not found"
18:14:57Yardanico@Nickiel12 you should run ./koch tools in the same folder where you downloaded and unarchived nim
18:15:01leorizewhy does asynchttpserver even cares about gcsafe?
18:15:03FromGitter<Nickiel12> ok
18:15:04Yardanicowhat did you download exactly?
18:15:21FromGitter<Nickiel12> https://github.com/nim-lang/nightlies/releases/tag/2020-03-31-devel-119b0ce arm6
18:16:11FromGitter<Nickiel12> there it goes
18:16:13Yardanicowell there's koch in that directory
18:16:20Yardanicoand actually
18:16:22Yardaniconimble is there too
18:16:27FromGitter<Nickiel12> there is, I don't know why I didn't look there
18:16:35FromGitter<alehander92> leorize if you write if stuff: return as a result in a macro called in async
18:16:38Yardanicothere's both nim and nimble in bin directory
18:16:51FromGitter<Nickiel12> so do I add that folder to the path?
18:17:01FromGitter<alehander92> it would just result in `return` which seems to mean that the async function would yield nil
18:17:05Yardanicoyeah, add that bin folder to $PATH
18:17:09FromGitter<Nickiel12> ok
18:17:09FromGitter<alehander92> which nim shows as an error
18:17:23FromGitter<Nickiel12> do i delete the nim that was created by running install?
18:17:36FromGitter<alehander92> i guess async handles direct non-macro returns
18:17:40leorizeI guess async transformation happened before other macros :/
18:17:43FromGitter<alehander92> yes
18:17:49Yardanico@Nickiel12 if you mean nim installed by apt - yes
18:17:51FromGitter<alehander92> but return result seems to work for now
18:18:02leorizewell you can use `yield`
18:18:18FromGitter<Nickiel12> no, I ran ./install.sh and it put a "nim" file into "/usr/local/bin"
18:18:22FromGitter<alehander92> but i want to do an early return
18:18:31FromGitter<alehander92> not sure if yield wouldnt lead to it being continued
18:18:58FromGitter<alehander92> and its the same basically: i just want to return the void result future which should be completed
18:19:04FromGitter<alehander92> but return result seems to work maybe yeah
18:19:59Yardanico@Nickiel12 seems like ./install.sh only installs nim without nimble and stuff
18:20:05Yardanicobtw is this even correct behaviour?
18:20:06FromGitter<Nickiel12> hmm
18:20:43leorizeYardanico: yes, because no one uses it :)
18:20:50Yardanicoxd
18:20:54FromGitter<Nickiel12> ...
18:20:56leorizebeside from a few packagers :P
18:21:11leorizeNickiel12: are you on debian?
18:21:18FromGitter<Nickiel12> rasbian
18:21:25FromGitter<Nickiel12> i think
18:21:27leorizefederico3 should have the latest Nim in backports, can you check that?
18:22:01FromGitter<Nickiel12> no
18:22:11federico31.0.4-1~bpo10+1 to be precise
18:22:48FromGitter<Nickiel12> when I ran sudo apt-get install nim, I got nim -v == 0.16.0
18:23:40FromGitter<Nickiel12> and ./koch tools is still running
18:23:44blackbeard420not sure leorize, but asynchttpserver requires the callback to be gcsafe :(
18:24:16Yardanicoblackbeard420: do you use threads?
18:24:28Yardanicoif not, the gcsafe will be a warning
18:25:22blackbeard420in this particular case yes im using spawn with asyncevent to be able to await long running tasks flowvars
18:25:37Yardanicowell, that's the problem
18:25:48Yardanicodefault nim GC is thread-local
18:26:05blackbeard420well it works as long as i access it via a ptr in the callback
18:26:13blackbeard420i was just wondering if there was a cleaner way
18:26:25leorizespawn and async don't really go together iirc
18:26:31leorizeor is async thread safe?
18:26:46FromDiscord<Recruit_main707> arent threads async already?
18:27:11Yardanicono?
18:27:32blackbeard420no there was work on awaitable flowvars by rayman22201 iirc
18:27:36blackbeard420but not sure where it stands
18:27:45blackbeard420i used his idea to work around it
18:28:18FromGitter<alehander92> blackbeard420 oh yeah
18:28:21FromGitter<alehander92> you can kinda do that
18:28:29FromGitter<alehander92> but is your thread long running
18:28:30blackbeard420just feels sloppy
18:28:36FromGitter<alehander92> or do you spawn a new thread each time
18:29:10blackbeard420i only need to spawn off certain long running taskes to not stop the async loop for the rest of the request
18:30:03*Guest80919 quit (Ping timeout: 250 seconds)
18:30:29FromGitter<alehander92> so whats the problem
18:30:52blackbeard420accessing the globals via ptr's... not really a problem. but just feels sloppy
18:31:01FromGitter<alehander92> ah, but why do you need to access globals
18:31:06FromGitter<alehander92> probably hard to change i guess
18:32:15blackbeard420well the one 'global' is a postgres dbconn. and i cant access that in the asynchttpserver callback unless i do as a ptr. because itll throw the Not GC-safe error
18:32:48rayman22201Gc:arc is the fix for this
18:33:07rayman22201Arc let's the threads have a shared heap
18:34:56leorizeblackbeard420: well you can use this little hack
18:34:59Yardanicobut it doesn't really work for async still :P
18:35:03rayman22201But async has memory leaks with arc. It's a whole can of worms... Unfortunately my day job has not given me much time to work on fixes in a while.
18:35:08blackbeard420i was using something along the lines of https://github.com/nim-lang/Nim/issues/11564#issuecomment-539317277 to create an awaitable flowvar, but that seems to fail to compile with gc:arc
18:35:13leorize{.gcsafe.}: <- everything in this block is considered to be gcsafe
18:36:20*dadada__ joined #nim
18:38:52*FromGitter quit (Remote host closed the connection)
18:39:11*FromGitter joined #nim
18:39:51rayman22201That makes the compiler not complain, but then you have to make sure it's actually safe on your own. I.e. by using locks etc...
18:43:19livcdthere's still a few pkgs that are not happy with gc:arc
18:44:12leorizeto be fair we can't be sure
18:44:26leorizegc:arc can only work well if there aren't any cycles
18:44:36leorizeand I don't think the compiler can detect these at compile time yet
18:46:02leorizeI don't think that it can actually :P
18:47:42*fanta1 quit (Quit: fanta1)
18:50:25rayman22201there is a mode that can detect them, but it can't break them.
18:50:59rayman22201it's runtime though
18:52:21leorizeuntil we got a good way to operate on cycles I don't think arc can replace refc :/
18:53:32Araqit depends. the Nim compiler disabled cycle collection for --gc:refc
18:53:51Araqso it can happily use --gc:arc instead, the cycles don't matter :P
18:54:08leorizeI guess now we know where the leaks in nimsuggest are from :P
18:55:58Araqnimsuggest uses --gc:markAndSweep not --gc:refc but nice try :P
18:58:37*Vladar quit (Quit: Leaving)
19:00:40axionHmm, I noticed a lot of cases when the compiler is unable to infer that a var return type is initialized with result = foo as the last line of the proc. It's always fixable by moving that nearer to the top though. Strange
19:02:44leorizesince DateTime is invalid if uninitialized, should we add `{.requiresInit.}` to it?
19:03:04*couven92 quit (Quit: Client Disconnecting)
19:03:38leorizeaxion: sounds like a good test case for the CFG
19:03:39Araqit's implicitly .requiresInit iirc
19:03:42leorizemaybe you can file an issue?
19:04:51*silvernode quit (Ping timeout: 260 seconds)
19:04:58leorizeAraq: there are still people complaining about errornously using it uninitialized :/
19:05:02axionYeah I'll try to come up with a repro, if not link to persistent line of a commit
19:10:32Araqleorize, btw we don't yet use the CFG for init checking (sad, I know)
19:11:04FromDiscord<Varriount> rayman22201: Someone suggested redoing the way async transforms procs
19:11:29FromDiscord<Varriount> Turn them into a state machine, rather than a procedure that returns closures (that return other closures, etc).
19:11:32rayman22201lol. Me. Also read my comment about my day job. :-P
19:11:56FromDiscord<Varriount> Oh, woops
19:11:58rayman22201I haz to make the moneys
19:13:18leorizeAraq: is #13808 aiming to change that?
19:13:39leorizeif it tighten up requiresInit, it should make use of the better analyzer for the job :P
19:13:45axionI have a question stemming from my ignorance with C: If I care about performance when working multiple array types (just aliases to an array, not objects), would moving to object types hurt much? I kind of want to be able to distinguish between diferent array types of the same length better, so it makes sense, just unsure from a performance standpoint.
19:14:13axionI value type safety more, so will probably move thee anyway, but nice to know in any case
19:14:15FromDiscord<Varriount> axion: Not sure what you mean.
19:14:19FromDiscord<Varriount> Also, I'm on Mumble
19:14:28axionOk I'll hop on there
19:14:38leorizeaxion: should be as fast
19:14:59leorizethough distict can be useful for this as well
19:14:59leorizedistinct*
19:15:19axionYeah I want to avoid distinct because of all the borrowing and other stuff
19:15:45leorizethat's kinda a big reason why I don't use distinct often too :p
19:15:51FromGitter<alehander92> but why
19:15:56FromGitter<alehander92> isnt it easy to borrow
19:16:10leorizeaxion: but if you put it in an array, wouldn't you still have to borrow? just a bit more explicit?
19:16:42leorizealehander92: you still have to type out the full prototype to borrow
19:17:06FromGitter<alehander92> well this should be fixable with some more macros :P
19:17:22Araqrayman22201, dom96 would like to tinker with async + ARC
19:17:24*evanj joined #nim
19:17:28Araqer
19:17:33Araqthat should have been
19:17:40Araqrayman22201, dom96, I would like ...
19:17:52leorizereally annoying when you suddenly stomp into an operator while coding
19:17:59dom96Araq, okay, what do you need from us?
19:18:17leorizegotta stop and write the entire prototype out just to get it to work :(
19:18:54FromGitter<alehander92> there was an easy way to do it before afaik
19:19:09Araqmostly explain to me once again why 'iterator x(): Request' doesn't work
19:19:44Araqwe yield requests that the even loop needs to wait for
19:20:00leorizeI would like to borrow some procs too, like having an add() for the distinct seq for example
19:20:30leorizeis this doable via a macro?
19:20:45leorizeso I can do something like T.borrow identifier
19:20:53axionOk thanks
19:21:54axionAnother question. I saw some code accessing type parameters in the body of a proc, without type parameters for that proc (only for the type definition). I also noticed this doesn't work all the time. Why is that, and how does the compiler differentiate type parameters from object members?
19:22:30leorizewdym?
19:22:36livcdso with arc parallel async/await will become possible ?
19:22:39axionSec, lemme find some code that does it
19:22:59leorizelivcd: it's still possible without it
19:23:04axionhttps://github.com/stavenko/nim-glm/blob/master/glm/vec.nim#L31
19:23:11rayman22201Araq: 'iterator x(): Request' ?
19:23:44rayman22201I'm not familiar with the idea
19:23:48leorizeaxion: ooh, interesting
19:24:02leorizewell it might have something to do with Vec being a typeclass
19:24:27axionI noticed this doesn't always work, but I haven't found a pattern yet
19:24:33leorizebut I don't think that one is even in the manual
19:24:36leorizemight just be luck
19:24:39axionIt is not
19:24:53leorizetry typeof(v).N?
19:25:36Araqrayman22201, well .closure iterator build the state machine, no need to reinvent that part
19:25:45Araqand closure iterators are ARC-able
19:25:48axionwell that's krux's code. I was just playing around with it after I saw it being done, but haven't kept anything because it was too inconsistent for me
19:25:55Araqthe cycle problems come from the callbacks
19:25:56axionUB as far as I'm concerned, until it's added to the manual
19:26:48rayman22201araq: sure, but I'm not sure how the callbacks can be fixed without removing the closure iterators.
19:26:58rayman22201the design interlinks them
19:28:24Araqhttps://nim-lang.org/docs/manual.html#iterators-and-the-for-statement-first-class-iterators
19:28:37Araqscroll to the part where it says "# simple tasking"
19:28:58Araq'runTasks' is our scheduler
19:29:06Araqit needs to use our event loop
19:29:26dom96It sounds to me like you'd need to fundamentally alter how async await works
19:29:31rayman22201exactly
19:29:36rayman22201what dom96 said.
19:29:40Araqso what?
19:29:52rayman22201Araq, what you propose is similar to what I propose
19:29:55Araqwe can't we have async V3 eventually?
19:29:58rayman22201but it's a totally different design.
19:30:18Araqof course it starts as a tiny Nimble package etc etc yada yada
19:30:30Araqbut what's wrong with creative tinkering...
19:30:59rayman22201The idea is a single closure iterator with a yield for every state, yes?
19:31:46rayman22201My idea is the same, just instead of a closure iterator, use goto's and CFG like mratsim did for synthesis. Mainly because it's more efficient.
19:33:10rayman22201I'm on board with your idea Araq.
19:33:38dom96if you're going to redesign async then try to avoid dynamic heap allocs like Rust does please
19:33:46rayman22201that's exactly what it does
19:33:56dom96if you're thinking of using iterators then I think you're already losing that AFAICS
19:34:17rayman22201that's why I like the mratsim approach better. But a single closure iterator is ok for a POC
19:34:49*muffindrake quit (Quit: muffindrake)
19:34:49rayman22201same technique though
19:35:04*muffindrake joined #nim
19:35:44rayman22201have the macro "compress all the promises in an async chain" into a single "task" object that is then iterated via the event loop. This is what Rust does.
19:35:49Araqdom96, the closure iterator has minimal overhead and you need heap allocations
19:36:11Araqas the whole point of async is to avoid the stack
19:36:25rayman22201The point is not heap allocation, it's "dynamic" heap allocation.
19:36:34dom96^ yeah
19:36:38Araqwhat does that mean
19:36:45rayman22201The single object is allocated once at the beginning.
19:36:56Araqyeah, the closure iterator's closure.
19:37:02rayman22201yup.
19:37:13dom96This video explained it pretty well IIRC https://www.youtube.com/watch?v=skos4B5x7qE
19:37:41rayman22201I like this one: https://www.youtube.com/watch?v=NNwK5ZPAJCk
19:38:01rayman22201but Araq is right, a single closure iterator allocated at the front is fine.
19:38:53Araqdom96, I saw it but it lacks too many details
19:38:58rayman22201using a custom object gives a bit more control imo, but It's a "6 in one, half a dozen in the other" kind of thing. A matter of taste.
19:39:11livcdThat guy's name is Without Boats? Oo
19:39:53Araqrayman22201, with a custom object you need inheritance instead
19:40:02Araqnot that i care
19:40:03rayman22201nah
19:40:06rayman22201I don't think so
19:40:26Araqtasks require local variables
19:40:34Araqlocal vars must be moved into the object
19:40:45Araqdifferent tasks have different numbers of locals
19:40:57Araqergo you need a base class
19:41:25rayman22201Yeah. So? The macro generates a unique custom object for each async chain.
19:41:40Araqthe custom object must adhere to a protocol like
19:41:50rayman22201And then generates overloaded procs that follow an "interface"
19:41:55rayman22201use a generics
19:41:55AraqTask = ptr object fn(self: Task)
19:42:13Araqyou can't pass "generics" to the underlying event loop
19:42:36rayman22201you don't need to. The event loop just needs a callback
19:42:54rayman22201well it needs the state too. But Why can't that be a generic?
19:43:48rayman22201the event loop calls `wakeup[T](Task T)`
19:44:04rayman22201and each unique Task has it's on impl of wakeup
19:44:10rayman22201it's own*
19:44:41dom96Araq, just make a secret pragma that will make async await work with ARC and call it a day
19:44:47dom96we can redesign async later
19:45:23leorizeif life was that easy :P
19:45:49rayman22201It's called `wake` in Rust: https://rust-lang.github.io/async-book/02_execution/02_future.html
19:46:58Araqrayman22201: there are no know ways to do this without "type erasure"
19:47:32Araqin Nim inheritance can be used but of course you can also re-implement the inheritance mechanism
19:47:54Araqjust like you're about to re-implement the closure iterators' state machines :P
19:48:22rayman22201I'm ok with using closure iterators lol
19:48:27blackbeard420oh neat leorize didnt know about '{.gcsafe.}: <- everything in this block is considered to be gcsafe' thanks!
19:48:44AraqI'm ok with you using even more explicit state machines
19:48:57Araqas long as it works in the end :-)
19:49:37dom96leorize: is life not that easy? :P
19:49:44rayman22201now you have given things to think about. I take your advice seriously lol :-P
19:52:07rayman22201Why can't you have `wake(Task: unique_task_type_1)`, `wake(Task: unique_task_type_2)` etc.... Because the event loop keeps a list of tasks, and they loose their type info if kept in a common collection... hrmmm....
19:52:20Araqexactly
19:52:41rayman22201unless you keep a bunch of closures that contain the correctly typed object...
19:52:51rayman22201but then you are back to a bunch of closures.
19:52:58rayman22201They don't have cycles anymore though :-P
19:53:30rayman22201or you use dynamic dispatch, a.k.a inheritence.... damnit araq, you are right again
19:54:53Araqusually I keep my mouth shut when I'm clueless.
19:55:09AraqThe secret of why I'm always right. :P
19:55:32rayman22201hahahaha. I may never learn that lesson. But at least it makes life fun
19:57:22rayman22201technically you don't need inheritance. You need interfaces (or "traits" in Rust land)
19:58:14dom96Araq, just remember that if it wasn't for me you'd be implementing fibers in Nim :P
19:59:22*rnrwashere joined #nim
20:00:57Araqrayman22201: in the end it compiles to the same thing and in C++ it's called "type erasure"
20:00:58livcdyes please
20:01:39*rnrwashere quit (Remote host closed the connection)
20:02:02Araqdom96: I remember and fwiw fibers work with --gc:arc out of the box
20:02:24rayman22201araq. Yeah. I get it. You convinced me. I'm sold on the single closure iterator idea. Does seem like an elegant compromise. More "Nimish"
20:02:26Araqthat doesn't mean the async design was wrong, but there are always tradeoffs
20:02:31rayman22201also much easier to implement
20:02:57rayman22201absolutely. I don't think anybody is arguing that async 1.0 was bad! It worked very well.
20:03:04rayman22201works still
20:04:20dom96Well, context is important here, I like to think I saved you from implementing fibers on top of what we currently have as you had some misunderstanding about what they would enable. If I knew what I know now and Nim didn't have an async implementation, I would likely advocate for fibers instead of async await.
20:04:34*silvernode joined #nim
20:06:05Araqdom96: interesting
20:06:07FromDiscord<treeform> dom96, I did some experiments with fibers... I want easy to use real threads now...
20:07:11livcdtreeform: me too!
20:07:18rayman22201I will point out that their are some space efficiencies left on the table by using a closure for async 2.0. There are cases where a local variable is only needed for a single "state", and other cases where a local variable must live across several yield statements. A simple CFG "last read of" analysis can allow the state object to be "as small as necessary". But maybe the CFG we have already does this?
20:08:36Araqyeah we don't do that :-)
20:08:36rayman22201That is a big selling point of the Rust implementation. They "prune" the state by knowing the lifetimes.
20:09:01rayman22201It seems like a nice optimization :-)
20:09:16FromDiscord<treeform> Araq do you recommend using protect/dispose for nested ref structures?
20:09:21FromDiscord<treeform> https://nim-lang.org/docs/system.html#dispose%2CForeignCell
20:09:28rayman22201looking at the wider world, async won over fibers. I'm glad we went that way.
20:10:13dom96rayman22201, did it? Fibers are Go's best selling point and many are using it
20:10:48rayman22201and that's why Rust abandoned the idea, Windows deprectated their fibers implementation, and the Linux Kernel is racing to make their api's more async.
20:11:41FromDiscord<treeform> I feel like OS needs to provide fiber like things...
20:11:57Araqyeah and the OS does and calls them "threads"
20:11:59*qwertfisch is now known as kmplzrtfsch
20:11:59rayman22201Microsoft and Linux both disagree
20:12:12rayman22201exactly. we already have threads
20:12:13Araqand unfortunately their overhead is high
20:12:32FromDiscord<treeform> Araq, yeah OS just needs to make threads better 🙂
20:12:48rayman22201go succeeded because their fibers have a nice api. It makes threading "easy" to do.
20:12:56rayman22201but it still has many problems.
20:13:08Araqwe need to use "OS as a library"
20:13:45livcdI await Araq's nimroutines
20:14:19AraqOSes suck, they are a messy legacy *shrug*
20:14:40FromDiscord<treeform> I wish there was more docs around protect/dispose https://forum.nim-lang.org/t/3711
20:14:57rayman22201also, nodejs is a counterpoint to Go fibers for making async a selling point.
20:15:21Araqrayman22201: well both ways have their fans
20:15:45Araqbut our goal should be to write something that works well with ARC
20:15:49rayman22201fair. It's obvious what camp I fall into :-P
20:16:16*narimiran quit (Ping timeout: 256 seconds)
20:16:24FromDiscord<treeform> I started 500,000 threads on windows... they appeared to work 🙂
20:16:34Araqha, I did the same
20:16:35rayman22201the threading api on windows is amazingly good
20:16:43*silvernode quit (Ping timeout: 260 seconds)
20:16:44Araqbut it was slow
20:16:55Araqand the memory consumption was noticable
20:17:02rayman22201lol, of course.
20:17:03FromDiscord<treeform> I bet having 500,000 async thingies would be just as low.
20:17:19Araqit's not
20:17:20rayman22201actually, no
20:17:23FromDiscord<treeform> At that point you are fighting the memory caching unit. Nothing can stay in memry.
20:17:42rayman22201less kernel overhead to get in the way with async.
20:17:57rayman22201still memory overhead, but less kernel context switching.
20:18:05FromDiscord<treeform> What if your task is already kind of CPU bound, like pacing JSON and output other JSON?
20:18:44rayman22201context switching threads still overwhelms any useful work.
20:18:54rayman22201that task needs SIMD
20:19:10rayman22201make each thread do more work, instead of more threads.
20:19:26Araqcontext switches also make the caches less effective
20:20:33FromDiscord<treeform> I guess this is how I feel about this:
20:20:34FromDiscord<treeform>
20:20:35FromDiscord<treeform> https://cdn.discordapp.com/attachments/371759389889003532/694642318917238925/unknown.png
20:21:00FromDiscord<treeform> My work usually dominates not async/thread overhead
20:21:08rayman22201The thing is, you have a limited number of physical CPU cores. You want to use them effectively. After a certain point, more threads just means more things fighting to get limited physical resources.
20:21:21rayman22201yeah, well, if you just keep adding threads, the thread overhead keeps going up.
20:21:26rayman22201That's not true for async.
20:21:43rayman22201or I should say the rate of growth is mush slower.
20:21:50rayman22201much* even.
20:22:19leorizenow we just need to make threading & async easy to use :)
20:22:32rayman22201:-)
20:22:43Araqasync is harder to use but is faster
20:22:55Araqroughly speaking
20:23:06rayman22201I agree.
20:23:20FromDiscord<treeform> async has issues when you block reading a file, or block on http call because of DNS resolution blocks.
20:23:31FromDiscord<treeform> Or use a blocking c library...
20:23:41FromDiscord<treeform> Its so easy to block async and get less performance.
20:23:47rayman22201that's an implementation issue, not a property of async as a concept.
20:24:21rayman22201which goes back to what araq said. Async is harder to use. You have to make sure all your api's don't block.
20:24:35FromDiscord<treeform> yes but nim's implementation of threads already solves those problems.
20:24:46rayman22201how so?
20:25:14FromDiscord<treeform> if you start a thread, that thread blocks on file read, dns, c library... other threads continue to run.
20:25:19leorizehis idea is that he can just offload all the blocking parts to threads :P
20:25:22FromDiscord<Rika> threads are easier to use but they have a higher overhead doesnt it
20:25:22FromDiscord<treeform> while with async it blocks everything.
20:25:31leorizeI really wish life was that easy :)
20:25:44FromDiscord<treeform> I would not call nim's threads easy to use right now.
20:25:53FromDiscord<Rika> if you have too many threads it can block everything
20:25:54leorizeon Haiku we are doing exactly that
20:25:56FromDiscord<treeform> They are "ok" to use, but not "easy".
20:25:58leorizethe Haiku API is completely threaded with message passing
20:26:02rayman22201That's how async in all languages work! Nodejs. tries to use your os async apis, but if it can't it farms out to a thread.
20:26:21leorizeand now we are facing a ton of bottlenecks in networking code :)
20:26:43*abm quit (Quit: Leaving)
20:26:51rayman22201use the async networking api from your OS then!
20:27:12FromDiscord<treeform> but not all programs just do networking...
20:27:12Araqand the async API from all the DBs that you want to use...
20:27:43Araqasync is a hack, ymmv
20:27:53rayman22201see my Nodejs comment. You use as many async apis as you can, and for what you can't, you farm out to a thread.
20:28:05AraqI too would rather use threads for everything
20:28:27rayman22201Nodejs is very successful with async because they pretty much force all their apis to be async.
20:29:19axionFibers are an OS level construct for a thread with less state. I think it's confusing to relate them to coroutines
20:29:38axionOften used with them, but independent nonetheless
20:29:40Araqwell this is getting unproductive
20:29:47FromDiscord<treeform> axion, everything is confusing because OS calls them different things with different APIs.
20:30:19Araqlet's get back to the closure iterators
20:30:37rayman22201It's a good idea. Are you going to try and implement it araq?
20:31:46FromDiscord<treeform> I really like the `{.push checks: off.}` feature. Best feature.
20:32:13livcdso we should use weave?
20:32:17Araqrayman22201: I'm too busy, I hoped you would pick up my ideas
20:32:20rayman22201Or do you want me to try? Soonest I can get to it would be the weekend.
20:32:25rayman22201I want to try
20:33:50rayman22201livcd: use weave if your problem is cpu bound. It's really freaking good for number crunching stuff.
20:35:12dom96treeform: you can block a fiber in Go too
20:35:33dom96we could have hacks that run it in a separate thread automagically too
20:35:46dom96it's not prevented by async await
20:35:56rayman22201I want to do it actually. been thinking abou that :-P
20:38:06dadada__really interested in the new macros for proc types and macros for types feature, waiting for the docs
20:39:43rayman22201I was a bit harsh on fibers. They aren't "that different" than async. IMO async is more explicit but maps to the underlying apis better. So async plays nice with today's kernels more easily. But if there was better OS support, I would expect them to be pretty similar. (IIRC Google has hacked the Linux kernel to do exactly this for Go for their infrastructure.)
20:44:41*chemist69 quit (Ping timeout: 246 seconds)
20:44:52*jjido joined #nim
20:44:57*silvernode joined #nim
20:45:36dom96in the end the APIs that fibers use are the same, the implementation is just more hidden and as a result you get less control over what's happening
20:45:54*chemist69 joined #nim
20:46:00dom96that is the main reason why async await is better for a systems programming language
20:46:07rayman22201I agree
20:46:13rayman22201:-)
20:46:56axionWhoever maintains nimble.directory, if you need better hosting I'd be happy to help. As it stands, every time I try to browse I got http 500 or 429 error, and today, just times out completely trying to connect to SSL
20:47:10dom96federico3, ^
20:49:23axionOh, add 502 to that list. Resolved before a timeout for once today :)
20:53:39*rnrwashere joined #nim
20:59:20*silvernode quit (Ping timeout: 256 seconds)
21:01:08leorizerayman22201: so are you gonna do it and stream? :)
21:01:44*NimBot joined #nim
21:04:23federico3axion: that would hepl
21:05:15Araqdadada__: that has been merged already and the docs are updated
21:07:43*natrys quit (Ping timeout: 265 seconds)
21:10:01FromDiscord<treeform> dom96, yes I agree with you. I tried fibers and was not impressed and now I think that just regular threads are just better for most of my use cases.
21:13:47rayman22201@leorize... Sure I guess? You can watch me struggle with Emacs since I am trying to learn it lol.
21:14:26leorizeand once you give up I can pitch you over to neovim :)
21:14:54*rnrwashere quit (Remote host closed the connection)
21:14:54rayman22201believe me, I'm tempted to come back
21:17:19*liblq-dev quit (Quit: WeeChat 2.7.1)
21:17:49*sz0 quit ()
21:18:33*sz0 joined #nim
21:21:07dom96so this is fun
21:21:14dom96--threads:on somehow breaking generic type matching
21:21:18dom96how is that even possible
21:23:06dom96How fun. Qualifying the T with a concept (that's empty) fixes it
21:23:52*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:24:06rayman22201???? wow.
21:24:09dom96I suppose it's time I show my crazy thrift library
21:24:10FromDiscord<clyybber> Can you please open an issue
21:24:26*rnrwashere joined #nim
21:24:30FromDiscord<clyybber> That sounds really broken : D
21:24:50dom96I'm adding a todo over the line I've modified for now.
21:25:02dom96would take too long to repro
21:25:04FromDiscord<clyybber> 😦
21:25:16FromDiscord<clyybber> but this is pretty critical
21:25:35FromDiscord<clyybber> if you want nim to get better at it, you have to make an issue..
21:25:49dom96oh, that reminds me of my new lesson, I should check if it fails on 1.0.6
21:26:02FromDiscord<clyybber> were you on devel?
21:26:39*jjido joined #nim
21:26:47dom96oh shit, I didn't actually fix it
21:26:52dom96argh
21:27:36dom96same error on both 1.0.6 and devel
21:31:41dom96okay, `mixin send` helps
21:32:02dom96very peculiar that it's only needed when threads are on
21:32:12dom96Araq, any ideas why that might be?
21:34:06Araq--threads:on adds a 'send' via channels
21:34:19dom96ahhhh
21:34:25Araqand if it's the only one proc you get different symbol binding rules
21:34:49Araqnot the best part of our design tbh but I also don't have a better design either
21:35:07Araqwill think about it tomorrow during my run
21:35:15dom96cool, thanks!
21:39:37dom96bah, the game runs at least half as fast with --threads:on
21:45:05dom96and it seems that --genScript doesn't copy nimbase.h when --threads:on is specified but without it does, wtf lol
21:47:25*rnrwashere quit (Remote host closed the connection)
21:48:53*kmplzrtfsch is now known as zslkhmctpfr
21:52:08dom96and Android crashes immediately. This my friends is why I always avoid --threads:on
21:56:17Araqwell Android uses threads so you should use --threads:on
21:57:00Araquse --tlsEmulation:off too, it's slow
21:57:23*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:57:32dom96yeah, I know :(
21:58:52rayman22201sounds like we just need you to keep fighting the good fight and filing bugs so we can have a good threads:on eventually :-)
21:59:18dom96I just want to finish this game and put it on the play store
21:59:20dom96that's it
21:59:31dom96feels like a never ending fight
21:59:51rayman22201:-( fair
22:00:02dom96nativeRunMain(): Couldn't find SDL_main in library libmain.so
22:00:13dom96how? When you could find it with --threads:off
22:00:41dom96I don't expect an answer from anyone, but I think talking out these problems may help me
22:00:53*tane quit (Quit: Leaving)
22:01:08dom96i.e I'll use #nim as my rubber duck :P
22:04:35*solitudesf quit (Ping timeout: 258 seconds)
22:09:09dom96okay, so devel does not copy nimbase.h with --genScript
22:12:20dom96https://github.com/nim-lang/Nim/issues/13826
22:14:03*moerm joined #nim
22:14:14moermHello everyone
22:14:33FromDiscord<Rika> hello
22:14:44moermIs Araq here?
22:14:57dom96maybe, maybe not
22:15:00dom96ask whatever you want to ask
22:15:02moerm*g
22:15:05FromDiscord<Rika> you just pinged them
22:15:14Araqhi
22:15:40moermAraq Hi! First, thanks again for the static anal. efforts!
22:16:42FromDiscord<Rika> uh thats a really horrid place to abbreviate analysis
22:16:46Araqyou're welcome
22:16:47dom96ooh, regarding my issue above: I compiled with devel and --threads:on. Turns out my game breaks on devel on Android.
22:16:54moermI'd be willing to write a small intro into static verification - but I'm git stupid, so it woould probably go into our wiki. a) interested? b) If yes, how do I put some articel into our wiki (without using git)?
22:16:57dom961.0.6 + --threads:on works
22:17:40FromDiscord<Rika> you dont need to use git to add to the wiki
22:17:51FromDiscord<Rika> github wiki is "github specific"
22:17:52Araqmoerm: a) *very*
22:18:37moermAraq Ok, you'll get that. That's a modest contribution I can make and I think it might be quite useful/helpful for our efforts
22:18:54Araqb) iirc our Nim github wiki is open for everybody or write a forum post but I'm PM'ing you
22:19:27moermSo, if someone holds my hand on how to put an article into our wiki (or other place Araq desires) I'll start writing ...
22:19:42moermAraq Great! Thanks
22:20:15*rnrwashere joined #nim
22:20:23moerm(And as a small extra for you I'll try to bring in at least stome "comparison" to Ada/Spark too ;)
22:21:31moerm(Btw. Thanks also to Rika for his attempts to help me ;)
22:21:33AraqI'm close to finishing 'old'
22:21:43moerm??
22:21:45FromDiscord<Rika> うう
22:21:50FromDiscord<Rika> ah shite, wrong keyboard
22:21:53moermyou mean in post conditions?
22:22:00Araqyes
22:22:24Araqensures: old(x) + 1 == x
22:22:34moermAh, OK. Hint: You might want to play with Nim's "result" rather than 'old'
22:22:59moermmeaning: Just turn it around: result == x + 1
22:23:18AraqI think you underestimate how far I got with this already
22:23:43dom96out of curiosity, what are you planning to use these new formal proofing features for?
22:24:07moermSorry, it was just meant as a friendly (and potentially interesting) hint. But going the standard 'old' route is fine too, of course
22:24:32Araqdom96: I focus on proving array indexing
22:24:38moermdom96 you'll find some of the answers in my article ...
22:24:48dom96moerm, brilliant :)
22:25:06Araqbut we also discussed Rust's "type state" (back when they still had it)
22:25:11dom96Araq, does that mean we will get compile-time errors telling us our array indexing sucks? :)
22:25:16moermAraq and you need/use 'old' for that??
22:25:33Araqand I'll likely replace Nim's .tags system by something better
22:26:00Araqmoerm: yes I do
22:26:08moermHint: I'm bored and annoyed by Rust. Your approach (Nim + static verif) is by far better (and easier to use)
22:26:11dom96I love Nim's .tags system, it just needs some way for me to tell it "shut up, these are the tags"
22:26:24FromDiscord<Rika> what's wrong with Rust?
22:26:36FromDiscord<Recruit_main707> its not nim obv
22:26:47FromDiscord<Rika> lmao, seriously though
22:26:47dom96Rika: it doesn't have a book about it written by Dominik Picheta :P
22:26:56moermOne thing - and only one thing - is interesting though: the "ownership" concept (but separation logic has more on offer)
22:27:02FromDiscord<Rika> bought your book btw but i havent read it for some reason lmao
22:27:12Araqif i+1 < a.len: use(a[i]); inc(i); use(a[i])
22:27:22Araq--> I need
22:27:44Araqproc inc(x: var int) {.ensures: old(x)+1 == x.}
22:28:19moermAraq don't complicate it by mangling usage, e.g. assignment or read, with bounds verification
22:28:22Araqof course I can also hack 'inc' into drnim as a special case, but the complexity is comparable so why not add 'old' already
22:29:12moermOne good way is to check bounds pre any access
22:30:05Araqdom96: not only do you get compile-time errors, the system usually can give you concrete example
22:30:11*sleepyqt_ quit (Ping timeout: 260 seconds)
22:30:16moermmangling static verif and access operations will immensely complicate things quite quickly
22:30:23Araqvalues that make your program fail
22:31:11dom96:o
22:31:27moermBtw (it's probably my fault but) when I tried to build a freshly cloned Nim last night I failed
22:31:44moermdom96 He's riht and isn't that super cool?!
22:32:05dom96yep, it sounds awesome.
22:32:51Araqhttps://github.com/nim-lang/Nim/blob/devel/drnim/tests/tbasic_array_index.nim#L2
22:32:55moermBut there's a but too: Most static analyzers sometimes fail. They are not wrong but they simply can't "understand" the situation
22:34:17moermI had a case recently where even the best analyzers failed. the index var to an array was (x & 0x1ff) -16, so it definititely was o < x < 496 but the analyzer choked on it
22:34:47Araqfor drnim you add
22:34:51moermSo I had to go the really painful way: frama-c. Beautiful in theory but a PITA practically
22:35:18Araq.assume: 0 < x and x < 496
22:35:28Araqand then you can continue
22:35:47moermAraq thank you, I mean it. But keep in mind that I'm git stupid (I work in a totally closed environment) so I'd need a *simple* way to get and build drnim (which I'm extremely interested in)
22:36:07Araqwell we had regressions for BSD
22:36:24Araqtry again with today's devel or wait for the release
22:36:28moermAraq If THAT really works in Nim's static verif. that would be awesome.
22:36:44Araqto build drnim you can use 'koch drnim'
22:36:54Araqworks for all OSes, in theory
22:37:13Araqtested it on Windows and OSX for now
22:37:31moerm'... /Nim/compiler/vmops.nim(105, 10) Error: cannot open file: std/compilesettings' was the error I got. I *did use* koch
22:37:50moerm(on linux)
22:38:01leorizewhat version of nim do you currently have
22:38:23moerm1.0.6 Jan. 23
22:38:55leorizemaybe you gotta build it from scratch
22:39:00leorizeswitch to devel and pull
22:39:05leorizethen clone csources
22:39:19leorizegit clone https://github.com/nim-lang/csources
22:39:19Araqyeah you do, Nim 1.0.6 doesn't have the new stdlib
22:39:35moermSorry, I'm really git stupid. My limit is "git clone something" and then build it
22:39:43leorizeactually you can try this hack
22:39:52leorizehow did you install nim?
22:39:59leorizewas it with choosenim?
22:40:06moermWill a full cloning and build of the current Nim source do?
22:40:15moermno, not with chosenim
22:40:21leorizegood
22:40:36leorizecopy the nim binary to the bin/ folder in the source code
22:40:39leorizethen try running koch again
22:41:01Araqbtw https://dl.acm.org/ is now open for everybody
22:41:08moermI'll first clone an build a new Nim
22:41:08Araqso many papers to read
22:41:33moermAraq *g (yes, I saw it both on HN and on lobster)
22:41:50Araqmoerm: and yeah, we do know Rust's ownership system, it's very nice, we're getting something comparable
22:42:31moermI'll have to leave for now. And when I return most will probably be gone. So, Araq, I'll get a PM from you, right? (And I'll start the article right away)
22:42:38AraqI'm trying to PM you... :-(
22:42:48*rnrwashere quit (Remote host closed the connection)
22:43:00Araqyou don't reply
22:43:13moermI'm not on discourse. For some weird reason they didn't send a confirmation/verification email :(
22:43:27Araqwhich IRC client do you use?
22:43:28leorizewe don't have any discourse
22:43:45moermIRC (The program is called 'hexchat')
22:43:55moermor discord, I always mix those 2 up
22:44:26FromDiscord<Rika> hexchat, discord aint IRC
22:44:32FromDiscord<Rika> oh
22:44:38FromDiscord<Rika> you mean discourse vs discord
22:44:46FromDiscord<Rika> we have a discord yes
22:44:46moermyeah, I guess so
22:45:23moermIt always worked. But when I tried it yesterday they wanted me to create an account. I tried but they f*cked up the verif. email
22:45:32Araqwilling to use gitter instead?
22:45:33moerm(the discord thingy)
22:46:02moermAraq Sure. Is there some ap-get installable program for gitter?
22:46:13FromDiscord<Rika> gitter is web client i think
22:46:26moermeven better. URL?
22:46:34Araqhttps://gitter.im/nim-lang/Nim
22:46:57*thomasross_ joined #nim
22:46:57*thomasross is now known as Guest22826
22:46:57*thomasross_ is now known as thomasross
22:47:12moermYuck. I must sign in to be able to talk there (gitter)
22:47:35moermGive me some minutes. I'll try
22:47:36*Guest22826 quit (Read error: Connection reset by peer)
22:48:04Araqtelegram, skype, ...
22:48:17moermForget it. I can't. One needs either a github or gitlab or twitter account. I have none of these
22:48:35moermskype on linux is a PITA
22:48:40moermtelegram I don't trust
22:48:58moermAraq We could use a free wire room
22:49:05Araqtry to PM me via IRC
22:49:38FromDiscord<ksandvik> how to send private messages in irc: https://www.computerhope.com/issues/ch001174.htm
22:50:01Araqthanks, we managed
22:50:03FromDiscord<ksandvik> It's good to have github/gitlab/bitbucket accounts...
22:51:27*oprypin quit (Quit: Bye)
22:51:35*oprypin joined #nim
22:57:55*thomasross quit (Remote host closed the connection)
22:58:17*thomasross joined #nim
23:10:43FromDiscord<exelotl> Man I need to revisit my single-user discord-irc bridge
23:12:37FromDiscord<exelotl> It worked great but crashed when I left it running overnight. Then it got left behind since it was made with Nim 0.18
23:14:28FromDiscord<exelotl> Idea of using an empty discord server as a personal IRC client is very appealing to me though
23:18:26leorizejust use matrix :P
23:19:15dom96exelotl: just make sure it works when it restarts and have it restart automatically
23:19:19dom96works perfectly for NimBot :P
23:25:34FromDiscord<Rika> pm2
23:29:42axionSo after this large refactor my math library/first Nim library will be usable. Trying to decide what the next piece of my Lisp gamedev stack to be ported will be...
23:31:07axionIn any case, the library ecosystem is pretty lacking, so anything I choose would be useful I think (or well, at least for me)
23:31:12leorizeyou've just written it :P
23:31:19axionHmm?
23:31:24leorizehow come you're refactoring it already :P
23:32:06axionBecause as I learn pieces of the language I find room for improvement in the interest of usability and maintainability.
23:32:56axionI implemented everything the best way I knew how the first time around. It's complete, but it can be more efficient/maintainable/better interface
23:33:12leorizesounds great :)
23:33:14axionIt's complete, just not the best
23:34:30axionI actually have a question. I ran into an issue last night in my refactor
23:35:48axionHow can I overload `[]` and `[]=` so that they can work with an index or a slice like regular arrays? This would just be a light wrapper over my objects which just have an array property.
23:36:13axionI can get integral indexing/setting working, but not both for some reason
23:36:25leorizehmm that's weird
23:36:46leorizeeven the stdlib way was just to provide a `[]` that takes a Slice as the second param
23:37:15leorizedo you have a reproducible example?
23:37:26axioni didn't try too hard...i was tired last night, but does the stdlib define two variants for int and slice?
23:37:47*moerm_ joined #nim
23:37:53leorizeyes
23:38:13axionAlright...I'll try again when I get there in a few
23:39:01*sleepyqt_ joined #nim
23:41:37*moerm quit (Ping timeout: 256 seconds)
23:43:56*Trustable quit (Remote host closed the connection)
23:45:35axionHmm, I can't find a good explanation of the inject pragma, and I think I need it here. I'm guessing it prevents gensyming, but I am having a hard time finding the right passage in the manual
23:47:57FromGitter<zetashift> https://github.com/oakes/vim_cubed oh wow it's written in Nim too lmao
23:48:41*krux02_ joined #nim
23:52:48*krux02 quit (Ping timeout: 256 seconds)
23:58:19leorize[m]ah meme will make Nim great :v