<< 28-08-2019 >>
00:07:39*nif quit (Quit: ...)
00:07:48*nif joined #nim
00:24:55*lritter quit (Ping timeout: 246 seconds)
00:26:37*laaron joined #nim
00:28:11*laaron quit (Remote host closed the connection)
00:29:07*laaron joined #nim
00:33:20*laaron quit (Remote host closed the connection)
00:35:01*laaron joined #nim
00:37:07owl_000why block is useful. anything inside block is not usable outside of it.
00:43:09*laaron quit (Remote host closed the connection)
00:45:45*laaron joined #nim
01:18:35*rayman22201 quit (Quit: Connection closed for inactivity)
01:42:32FromGitter<zetashift> @owl_000 do you mean the `block foo:`statement? I found it useful for scoping, though I only have used it like twice? https://nim-by-example.github.io/block/
01:45:02owl_000yes, second example is usefull case of block
01:45:08FromGitter<dawkot> what could possibly cause karax to take 5 seconds in release mode to to a single diff?
01:45:43FromGitter<dawkot> I noticed that removing labels from a bunch of buttons fixed it completely and I'm completely lost
01:45:50FromGitter<dawkot> but I need the labels :P
02:10:46*laaron quit (Remote host closed the connection)
02:12:51*laaron joined #nim
02:29:56*snooptek joined #nim
02:41:17FromGitter<kayabaNerve> I've seen two uses for block.
02:41:44FromGitter<kayabaNerve> 1) Tests. You can write 5 tests with the same variable names in the same file without worrying of value mixing.
02:41:57FromGitter<kayabaNerve> 2) Breaking. Nested loops needing a boolean is annoying as hell.
02:42:28FromGitter<kayabaNerve> As for "anyhing inside block is not usable outside of it", yes, that's scoping. Without scoping, everything would be global, which would be quite horrific.
02:42:43FromGitter<kayabaNerve> ... Python's scoping haunts me, even now.
02:44:54*laaron quit (Remote host closed the connection)
02:48:08*cgfuh quit (Quit: WeeChat 2.5)
02:48:16owl_000i am practicing nim, in this exercise i used what i have learned so far. please review my code. thanks in advance. a bank like program. i use type = object, seq to hold accounts. user can add, view, withdraw and deposit in accounts. https://paste.ofcode.org/rJtwDHXdkAqQjsXv2gcd4D
02:51:05*laaron joined #nim
03:07:24FromDiscord_<me2beats> trying to make nimx hello world work on android. Any Ideas what I could do wrong ```..nim\nim-0.20.2\lib\system\gc_common.nim(413)
03:07:24FromDiscord_<me2beats> prepareDealloc
03:07:24FromDiscord_<me2beats> SIGSEGV: Illegal storage access. (Attempt to read from nil?)```
03:15:46*arecaceae quit (Remote host closed the connection)
03:16:10*arecaceae joined #nim
03:21:30*rockcavera quit (Remote host closed the connection)
03:32:06*laaron quit (Remote host closed the connection)
03:36:20*laaron joined #nim
03:46:15*chemist69 quit (Ping timeout: 264 seconds)
03:47:56*chemist69 joined #nim
03:47:56*snooptek quit (Remote host closed the connection)
03:51:52*fjellfras joined #nim
03:57:07*darithorn quit (Ping timeout: 258 seconds)
04:13:48*owl_000 quit (Ping timeout: 268 seconds)
04:21:43*sagax quit (Ping timeout: 245 seconds)
04:30:21*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
04:31:17*laaron joined #nim
04:37:18*nsf joined #nim
04:39:56*sagax joined #nim
04:43:16*endragor joined #nim
04:46:11*gmpreussner_ joined #nim
04:46:17*gmpreussner quit (Ping timeout: 245 seconds)
04:48:56*dddddd quit (Remote host closed the connection)
05:22:21leorize[m]narimiran: that's weird, since the code for '*' was untouched. It also doesn't use nimsuggest. Please file an issue on nim.nvim repo
05:25:32leorize[m]owl_000: here are some suggestions
05:25:57leorize[m]don't use void return type
05:26:22leorize[m]use the implicit result variable instead of making your own
05:27:24leorize[m]`echo` appends a newline automatically, so you don't have to keep adding it
05:29:24leorize[m]regarding data structure design, it seems to me that a `seq[Account]` would be more fitting than having seqs within Account
05:33:55FromDiscord_<me2beats> seem to solve the error above (somehow), now I have this one: `Error: cannot open 'main.nim'. ` Tho I can see that `nakefile.exe` and `build` folder are created. But then I see `cannot open 'main.nim'` - many times, and as a result `nakefile.exe` reports abnormal shutdown
05:34:09*narimiran joined #nim
05:35:28FromDiscord_<me2beats> Error: cannot open 'main.nim'
05:35:28FromDiscord_<me2beats> Hint: widestrs [Processing]
05:35:29FromDiscord_<me2beats> Hint: io [Processing]
05:35:29FromDiscord_<me2beats> Hint: main [Processing]
05:35:29FromDiscord_<me2beats> Error: cannot open 'main.nim'
05:35:29FromDiscord_<me2beats> Hint: widestrs [Processing]
05:35:29FromDiscord_<me2beats> ...
05:41:51*owl_000 joined #nim
05:43:05*absolutejam joined #nim
05:45:00FromDiscord_<me2beats> my nakefile.nim is `import nimx/naketools`. and in cmd I write `nake -d:release droid`. The content of `main.nim` is from this page https://github.com/yglukhov/nimx
05:45:26FromGitter<kayabaNerve> Hasn't Nake been discontinued for years?
05:45:34FromGitter<kayabaNerve> As in, ever since Nimscript was deployed?
05:52:25FromDiscord_<me2beats> well my task is simply to understand how I can create a hello world application working on android
05:57:42FromGitter<arnetheduck> @zetashift yeah, two grants
06:03:19*solitudesf- joined #nim
06:14:01*LargeEpsilon_ joined #nim
06:17:50*LargeEpsilon quit (Ping timeout: 272 seconds)
06:29:40*Senketsu joined #nim
06:41:17*absolutejam quit (Ping timeout: 244 seconds)
06:52:27*Senketsu quit (Quit: WeeChat 2.5)
06:59:29*leorize joined #nim
07:00:00*gmpreussner_ quit (Quit: kthxbye)
07:02:34*krux02 joined #nim
07:02:41*actuallybatman joined #nim
07:04:46*gmpreussner joined #nim
07:16:42*absolutejam joined #nim
07:17:49owl_000thanks leorize for your suggestions.
07:25:05owl_000one question `proc input(): (string, int) =` this return a tuple, how to unpack it. i used var x,y=input() it make to copies of input's return.
07:26:05leorize`var (x, y) = input()`
07:26:09leorizeit's in the manual :P
07:27:22FromGitter<arnetheduck> https://play.nim-lang.org/#ix=1TFF
07:30:50owl_000in manual! though i search a lot. thanks
07:39:56*ng0 joined #nim
07:55:27*shomodj joined #nim
08:01:39*faiXX joined #nim
08:04:57*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
08:07:38*laaron joined #nim
08:22:57*BigEpsilon joined #nim
08:26:43*LargeEpsilon_ quit (Ping timeout: 245 seconds)
08:29:16*faiXX quit (Ping timeout: 244 seconds)
08:41:07*Vladar joined #nim
09:06:18*solitudesf- quit (Ping timeout: 245 seconds)
09:11:11*faiXX joined #nim
09:28:18*solitudesf joined #nim
09:51:51*ng0 quit (Quit: Alexa, when is the end of world?)
10:00:43*owl joined #nim
10:00:59*absolutejam quit (Ping timeout: 268 seconds)
10:04:15*owl_000 quit (Ping timeout: 264 seconds)
10:15:37*absolutejam joined #nim
10:21:49*sagax quit (Remote host closed the connection)
10:28:18*abm joined #nim
10:45:14ZevvWhy are uint64.low and uint64.high not available?
10:46:12narimiranZevv: i think krux02 is working on that as we speak ;)
10:46:29ZevvYeah I just searched closed issues and saw recent stuff happening
10:47:15leorizenarimiran: so the `*` operator in nvim doesn't work correctly in select occasion?
10:48:07narimiranleorize: when in proc definition, and you try to search for param name, it searches for param type
10:48:33narimiranand in some other situations (i haven't pinpointed them down yet), it doesn't work at all
10:50:35leorizelooks like it doesn't correctly register identifier with length of 1
10:52:19narimiranyep, you're right, it is only for len=1
10:53:05Zevvwell, I hadn't noticed that yet :)
10:53:27leorizeit's a bug in my regex :P
10:54:13Zevvshould I post a link to the obligitory xkcd comic?
10:55:01narimiran"...now you have two problems?" ?
10:55:23Zevv"n+1" will do :)
10:56:54Zevvleorize: You want more features?
10:57:06ZevvI'd kill for shift-K support
10:59:37leorizein a way, I could support that
10:59:53leorizeso it should, uh, show the help?
11:00:14leorizeI mean the docs of that symbol?
11:02:06Zevvyesss
11:02:54Zevvthat will surpass nim support for any other editor
11:03:09Zevvimagine, the fame, the fans, the groupies!
11:03:49leorize`K` is kinda hard to implement according to its doc
11:04:07Zevvthe docs lie, I know you can do it
11:04:35leorizeafter I'm done with the refactoring :P
11:04:44*lritter joined #nim
11:04:47leorizenarimiran: I've fixed the bug, it's in master atm though
11:06:05narimiranwhat about the refactoring branch? can you patch it there, or should we switch to master?
11:06:23*fjellfras quit (Quit: Leaving)
11:06:51leorizeI can, just need to merge master to it I think
11:07:36leorizeyep, done
11:12:03*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:17:01*theelous3 joined #nim
11:23:04*cgfuh joined #nim
11:24:17*shomodj joined #nim
11:26:11Zevvleorize: I'll do some preparing work to figure out how to find a signature in the docs
11:32:52*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:33:36Zevvwell, I just realize I can just jump-to-definition and read the comments :)
11:41:53*rockcavera joined #nim
11:47:28ZevvIs there a way to "manually" apply a template to a NimNode tree? I have a DSL which is parsed by nim but which is not Nim, and I'd like to use templates or a template-like-mechanism to do parameterization/genericization.
11:48:49ZevvI have my parsed Nim AST, and if I find an unknown identifier I'd like to figure out if there exists a template with that name, and if so, apply it to that subtree of my AST
11:52:10Araqmaybe by injecting 'when compiles(foo()): foo()'
11:53:37Zevvh,,
11:53:38Zevvhmm
11:54:39leorize[m]Zevv: well it's rather easy to be done. nimsuggest `def` command already returns the doc of the symbol on cursor
11:55:21leorize[m]I can't do the `:NimDoc symbolName` with it though
11:56:00Zevvleorize[m]: makes sense
11:57:23*lritter quit (Quit: Leaving)
11:58:17*floppydh joined #nim
12:05:24*actuallybatman quit (Ping timeout: 248 seconds)
12:12:27*Kaivo joined #nim
12:14:07*actuallybatman joined #nim
12:23:38*alexander92 joined #nim
12:33:57alexander92@dom96 , yglukhov zig also seems to head to an approach that seems similar to multisync to me : https://github.com/ziglang/zig/issues/1778
12:34:56alexander92i admit, yglukhov's points that async-only is often simpler make a lot of sense, but still, both approaches seem to have their audiences
12:36:18Araqasync-only seems short-sighted to me. nimsuggest also uses sockets and is CPU bound
12:36:20FromGitter<yglukhov> Meh, still not convinced, sorry. If one wants to block he writes `waitFor someFunc()` instead of `someFunc()`. As easy as that :)
12:36:55Araqer, the 'waitFor' still gives me an event loop that my program might not be able to deal with
12:37:13FromGitter<yglukhov> how so?
12:37:27alexander92i agree, in the zig proposal, the ability to run in many env-s/cases where there is no event loop is also explicitly focused on
12:37:42AraqI'm not sure, I never even tried to port nimsuggest to async, seemed futile
12:37:50alexander92so it's not just something that dom96 wanted
12:38:40FromDiscord_<djazz> DragonRuby Game Toolkit seems cool. I wonder if I can do something similar with Nim.
12:38:46FromGitter<yglukhov> thing is, I'm not aware of a platform where there's no runloop. But I'm aware of the platforms where blocking is impossible.
12:39:30alexander92it seems to me, there are many programs, like pure data postprocessing, compilers etc which seem to never require async stuff
12:39:30FromGitter<yglukhov> Android and web browsers forbid blocking.
12:39:57alexander92but i might've just not seen contra-examples
12:39:57FromGitter<yglukhov> Sure but then they would not require multisync either, no?
12:40:32alexander92but the point is to write e.g. libs/abstractions, that can be used by both people that insist to write blocking code, and people that insist to write async-only code
12:40:52alexander92same as with generics/some other abstractions
12:41:35*laaron quit (Remote host closed the connection)
12:42:20FromGitter<yglukhov> Ok, but can you come up with a use case? E.g. why would anyone want to use a sync http client?
12:42:54Araqbecause it's simpler than an async one and it can be fast enough?
12:43:43Araqesp when you're CPU bound anyway and so this process() call does *block* anyway
12:43:45FromGitter<yglukhov> How simpler? `waitFor downloadFile()` vs `downloadFile()`?
12:44:25FromGitter<yglukhov> Ok waitFor uses the runloop, but what's wrong with that?
12:44:41*laaron joined #nim
12:45:07Araqah come on, I happen to know quite a bit about the closure iterators and closures and allocations and stuff that make 'waitFor download' work. Sure, it's simple to write, but what happens at runtime isn't simple
12:45:34FromGitter<yglukhov> Btw, along with await-as-a-template I had an idea to make await behave like waitFor in sync contexts. =)
12:46:59FromGitter<yglukhov> Efficiency, I get this, but what is a realistic scenario in which we would care so much about it in regards to an io op :)
12:47:06alexander92which reminds me, to push the asyncdispatch await as template patch: (except if you guys decide to port it to asyncdispatch as well which would be cool)
12:47:29FromGitter<yglukhov> like i said, with multisync it is messy :)
12:48:52FromGitter<arnetheduck> sync and async in the same thing feels a bit like trying to fit a square peg in a round hole - the concepts and paradigms used when doing async vs sync programming tend to be different, and to write stuff that "works" with both at the same time means you have to compromise and impose the restrictions of both styles on what you write - in the end, the only time you can save on development effort is when it doesn't
12:48:52FromGitter... really matter, ie when it's leaf stuff or non-critical
12:51:11Araqyeah, ok, so that's how you "feel" about it. in the meantime we used .multiSync without much trouble and nobody complained
12:51:39Araq(ignoring all the complaints we received for async in general)
12:52:43alexander92@arnetheduck i feel the issue is that it's totally voluntary: e.g. a project like yours can just not use multisync if it decides to, why should this stop people that like it
12:53:18alexander92(or a hypothetical safeAsync or any other similar possible abstraction)
12:54:57FromGitter<arnetheduck> well, have fun :) I'm not saying that it should be pulled or anything, but I'm with @yglukhov here that it's an unlikely direction for us to take with chronos for example, because we have a fair bit of features resting on it and the additional compromises would be hard to motivate unless a really beautiful solution comes along
12:55:19*shomodj joined #nim
12:55:59alexander92but are there any other compromises then the template await thing: which i still think can be fitted
12:56:15alexander92(and when will you https://github.com/nim-lang/Nim/issues/11912 :P
12:57:44FromGitter<arnetheduck> it's a bit like with streams vs DMA/buffers - once you accept the stream mindset with filters and converters and so on, you lose direct addressing and a bunch of things that make direct buffers fly
12:59:30AraqI don't see the "compromise" about "uh, ok, ignore the 'await' annotations and avoid the event loop dependency". In fact, it's the 'await' annotations that I dislike so much, it's like coding the kernel/App split into your program logic and calling it an "abstraction"
12:59:31FromGitter<arnetheduck> similar with async - you're suddenly in heap land and the landscape changes - you can try to structurally enforce lifetimes like @zah suggests, but that's a pretty radical constraint to put on your program, in most cases
13:01:15Araq"every 'blocking' call must be annoted with 'await'" - "ok, in what universe is that an abstraction though? it seems like the very opposite to me"
13:02:45FromGitter<arnetheduck> the await annotation is there to make you aware that things are happening out-of-order - seems pretty reasonable.. I mean, when was the last time you felt that people are good with intuitively understanding out-of-order execution?
13:03:50Araqit's far too innocent to make me aware about this
13:04:02Araqit's a point reasonable people can disagree on though.
13:04:32Araqhowever, I would put it differently: async+await is a necessary evil and when it's not necessary for your program all that remains is 'evil'
13:13:32Araqnow since you're here, can't we solve https://github.com/nim-lang/Nim/issues/11776 by new warnings that teach Nim users about Nim's exception hierarchy?
13:16:50*ng0 joined #nim
13:18:34*dddddd joined #nim
13:18:34*darithorn joined #nim
13:27:02owlis nimedit available for download?
13:28:37*owl is now known as owl_000
13:30:55owl_000though i use geany (light weight and customizable) but nim suggest does not work.
13:34:58*LargeEpsilon_ joined #nim
13:36:29leorize[m]use neovim :)
13:36:38narimiran^
13:36:57alexander92btw i was arguing with zig people about that: how far are we from something like "run-this-call-in-threadpool-and-await-it"
13:38:12*BigEpsilon quit (Ping timeout: 248 seconds)
13:40:15FromGitter<mratsim> you can use spawn/^
13:40:28alexander92mratsim but i cant
13:40:37FromGitter<mratsim> but AFAIK Zig folks don't want any runtime in their language so can they do that?
13:40:39FromGitter<arnetheduck> @Araq, I guess that's mostly as good (naming aside) - in particular, `CatchableError` is quite horrible to work with - having `Exception` branch into `Defect` and `Error` is not too bad as far as pragmatic compromises go, and at least highlights the exceptional status of `Exception`
13:41:16FromGitter<mratsim> why can't you @alexander92?
13:41:53Araqarnetheduck: neither CatchableError nor Exception nor Defect are what I really use to inherit from
13:41:54alexander92mratsim : well, i wouldn't say that: every language has a runtime, it was more of a "can the language detect a slower call in an event loop" discussion
13:42:02*owl_000 is now known as owl
13:42:11*BigEpsilon joined #nim
13:42:12alexander92mratsim: well iirc people werre working on supporting `awaiting` spawn
13:42:25alexander92but there was something that happened
13:43:05FromGitter<arnetheduck> hm, I guess that line of naming would need to go further as well: `IndexDefect` instead of `IndexError` etc so that `Error` is something expected (not Exceptional or Defective)
13:44:35FromGitter<mratsim> Ah so you meant automatically deferring IO async/await onto threadpools
13:44:41FromGitter<arnetheduck> I don't really know about inheritance and exceptions, I haven't seen many cases where it makes sense - the vast majority of error handling boils down to "did it work or not", anything else is fairly exotic (yes, you could potentially have specialized types carrying extra fancy information, but does that *really* happen?)
13:44:47FromGitter<mratsim> i.e. M:N threading like goroutines?
13:45:21FromGitter<mratsim> I think it's @rayman22201 and @zevv who were working on that.
13:45:53*LargeEpsilon_ quit (Ping timeout: 245 seconds)
13:46:17FromGitter<arnetheduck> ie in C++, the few times that exceptions are actually used in the wild, in modern code, it's fairly standard practise to throw `std::runtime_error` simply because that's the first type that has std::string as message and isn't a bother to type out/create/etc
13:46:57FromGitter<zetashift> Couldn't one port libmill to Nim?
13:46:59Zevvmratsim: we were planning to, but then came holidays. we need to get that started yes
13:47:02FromGitter<arnetheduck> *when gitter threads*
13:47:15FromGitter<zetashift> for goroutines?
13:47:18alexander92mratsim: yeah, something like that: but oly for some cases, not most async calls
13:47:50Zevvand speaking for myself, not sure if I'm really competent for that. I usually consider myself not smart enough to do threading, just to be on the safe side
13:48:09alexander92that's why you need to *write* the threading mechanism
13:50:49FromGitter<arnetheduck> oh yeah, do that and you'll be cured from threads forever ;)
13:51:49FromGitter<mratsim> Many languages moved away from M:N threading - Java and Rust most notably.
13:52:43alexander92mratsim: but again, that's not really about M:N
13:53:07FromGitter<mratsim> if it's only for blocking syscalls like reading from a terminal, I think "async" can just take a "spawnInNewThread = false" parameter
13:53:13alexander92it's about being able to say "await threadRun(x)"
13:53:29alexander92which would hopefully reuse a thread pool
13:53:34alexander92instead of always spawning a new one
13:53:44alexander92i guess? not sure :D
13:53:56Araqso it's about M:N
13:54:03alexander92but it's explicit
13:54:16alexander92not something nim's async lib has to do automatically
13:54:23Araqbecause otherwise why care about the "pool"?
13:54:46alexander92well, i just thought it's more optimal to somehow reuse threads?
13:54:54alexander92but honestly, no idea if this is true
13:55:10Araqit is true.
13:56:19alexander92but anyway, i assumed M:N is used, when most "async" operations are somehow scheduled equally between N threads
13:56:35alexander92and in this case, i expected just a small % of them to be scheduled in a different thread
13:57:13FromGitter<mratsim> I still don't understand the use case. ⏎ If it's IO, a single thread should be able to handle it.
13:58:03alexander92yes
13:58:26Zevvnot on modern systems. I did a project recording 50K concurrent RTP phone calls on a pretty large machine. There's a bunch of NICs with multiple queues scheduled on multiple CPU's
13:58:33Zevvthere's no way of eating all that on a single thread
14:03:00*lritter joined #nim
14:03:06FromGitter<mratsim> Does goroutines handle that by default?
14:03:29FromGitter<mratsim> Do*
14:03:35alexander92i think so, sometimes
14:05:42alexander92https://www.ardanlabs.com/blog/2018/08/scheduling-in-go-part2.html
14:05:51alexander92search for asynchronous system calls
14:05:54alexander92and later syncrhonous
14:07:27*nif quit (Quit: ...)
14:07:37*nif joined #nim
14:09:13AraqWhat happens when the Goroutine wants to make a system call that can’t be done asynchronously? In this case, the network poller can’t be used and the Goroutine making the system call is going to block the M. This is unfortunate but there’s no way to prevent this from happening. One example of a system call that can’t be made asynchronously is file-based system calls. If you are using CGO, there may be other situations where calling C functi
14:09:13Araqons will block the M as well."
14:10:06alexander92indeed: but i remember reading something about
14:10:23alexander92moving such calls to a routine on a different os thread
14:10:31alexander92but maybe i am imagining this
14:11:12alexander92yes: https://povilasv.me/go-scheduler/
14:11:28alexander92"Interesting things happen when your goroutine makes a blocking syscall. Blocking syscall will be intercepted, if there are Gs to run, runtime will detach the thread from the P and create a new OS thread (if idle thread doesn’t exist) to service that processor."
14:12:13*LargeEpsilon joined #nim
14:12:23alexander92the same thing i wanted for some async cases (but maybe more explicit)
14:14:19Araqwell yes, but you cannot "intercept" the blocking syscall
14:14:43Araqyou need to *start* it on a different thread
14:15:02alexander92well yeah, i guess that's what the author meant
14:15:02*BigEpsilon quit (Ping timeout: 245 seconds)
14:16:14sealmovehow to get size of a stream?
14:16:25Araqstreams don't have sizes
14:17:54sealmoveright, i meant "available bytes for read"
14:19:30Araqnever found a way to get that, the OS "hides it" from you, it's lovely
14:19:34*alexander92 quit (Ping timeout: 244 seconds)
14:20:18sealmovei see, thanks
14:20:27Araqmuch of a language's job is to work around all the OS's misdesigns
14:21:19sealmoveis it at least possible to seek to the end of the stream? like C++?
14:21:30*LargeEpsilon_ joined #nim
14:22:16sealmove(std::ios::end)
14:22:17AraqI dunno, seems misguided, a stream has no end
14:23:02sealmoveI would agree with you, sadly the API I have to implement requires such a proc...
14:23:06Araqyou cannot *attempt* to read, all you can do is to read and throw away the result until you come to the end
14:23:46sealmoveso no random access for stream
14:24:03*endragor quit (Remote host closed the connection)
14:24:22leorizeit wouldn't be a stream if you can randomly access its element :P
14:24:38sealmovemakes sense
14:24:55*LargeEpsilon quit (Ping timeout: 268 seconds)
14:25:04sealmovei guess std::ios::end is fundamentally wrong
14:26:56*BigEpsilon joined #nim
14:31:12*LargeEpsilon_ quit (Ping timeout: 272 seconds)
14:34:32*leorize quit (Ping timeout: 260 seconds)
14:35:44*leorize joined #nim
14:43:33*krux02 quit (Remote host closed the connection)
15:01:16Zevvfunny and scary how few code sometimes is needed for pretty complex features. I added parametarizable rules / template support to npeg in effectively 20 lines
15:01:50Zevvexpanding a template on NimNodes in a macro is just a tiny recursive function
15:02:38FromGitter<zetashift> How is that scary
15:02:52FromGitter<zetashift> With great power comes great responsibility/
15:02:54FromGitter<zetashift> ?*
15:02:55ZevvI never dare to touch any of that again in my life
15:04:09AraqZevv: then better submit to important_packages so that we don't break it
15:04:14*alexander92 joined #nim
15:04:24ZevvI think its already in there
15:05:27Araqyou wanted it, you are getting it, an OS written in JavaScript
15:05:28Araqhttp://runtimejs.org/
15:05:59ZevvOh I thought the world was still digesting the Mac OS X terminal in javascript
15:06:02*sagax joined #nim
15:06:05Zevvbut this is indeed one step further
15:07:00alexander92i think there are several
15:07:04alexander92oh wait, but in wasm
15:10:04*endragor joined #nim
15:17:45Araqhmmm I think I want an unikernel
15:19:27*absolutejam quit (Ping timeout: 258 seconds)
15:26:03FromGitter<zetashift> @Araq homepage mentions it's build using C++ and just embeds a V8 engine
15:28:12*abm quit (Ping timeout: 272 seconds)
15:29:40*laaron quit (Remote host closed the connection)
15:35:01*nsf quit (Quit: WeeChat 2.5)
15:37:28*laaron joined #nim
15:39:33*floppydh quit (Quit: WeeChat 2.5)
15:42:33disruptekdid quickjs ever hit nimble or w/e?
15:43:07disruptekseems like yes. https://github.com/ImVexed/quickjs4nim
15:44:05disruptekyou can often `peek` on streams.
15:44:19disrupteksealmove ^
15:56:54*uvegbot joined #nim
16:00:09*owl_000 joined #nim
16:00:53*zyklon quit (Ping timeout: 250 seconds)
16:03:35*owl quit (Ping timeout: 268 seconds)
16:11:19disruptekhow often do you find yourself having to increase vmdef.MaxLoopIterations?
16:22:56*abm joined #nim
16:27:54Araqdisruptek: never, I used staticExec to keep the compile-times at bay
16:28:36disruptekwhat does that do?
16:28:55*NimBot joined #nim
16:33:29*drewr quit (Quit: ERC (IRC client for Emacs 26.2))
16:34:10*drewr joined #nim
16:34:25*drewr quit (Remote host closed the connection)
16:36:00*wildtrees joined #nim
16:36:58*wildtrees quit (Max SendQ exceeded)
16:38:13*drewr joined #nim
16:38:20FromGitter<dawkot> is it expected that wrapping a list of buttons in Karax in a few additional divs can slow diffs down to a crawl?
16:41:26alexander92we still accept pr-s for graveyard ?
16:41:29alexander92or ?
16:41:37alexander92(with simple fixes)
16:42:26shashlick@Araq was developing a vm easier / faster than multi stage compiles?
16:45:51disrupteksome of my inputs are a few megs of json; i don't really think the reasonable solution is for me to change my code.
16:50:30alexander92dawkoit: are you using the latest karax
16:50:35alexander92dawkot *
16:50:43alexander92if you have a repro, you can submit an issue
16:53:09shashlickWell converting nimterop to do all ast to Nim from vm to compiled made it 10x faster
16:56:22disruptekhow does that work?
16:57:41FromGitter<dawkot> this runs extremely slow on my machine, for example: https://gist.github.com/dawkot/9ad53b68f4bc62e977708771c5bd23f8
16:57:52FromGitter<dawkot> I'll try using a newer version of Karax
16:59:36*endragor quit (Remote host closed the connection)
17:00:03disruptekmy use-case is that i'm generating apis with, in some cases, several hundred operations. if i compress this stuff, then the application suffers because it's not generating useful code or documentation that the user can actually use with "normal" tooling.
17:00:04*endragor joined #nim
17:01:08*endragor quit (Remote host closed the connection)
17:05:45shashlickWell I had to have come compiled stuff since tree-sitter is C code and the vm doesn't allow ffi
17:06:13shashlickSo what it did was spit out an ast to stdout
17:06:53shashlickI took that ast in using staticExec, converted it back into an object structure and then parsed it to generate Nim
17:07:14shashlickOf course you can see the extra obj to text to obj
17:07:33shashlickPlus the fact that all the ast parsing was happening in the vm
17:07:49shashlickI simply moved the ast to Nim portion also into the compiled binary
17:08:18shashlickNow toast just outputs Nim which I pull in using parseStmt
17:08:43shashlickThis change made the conversion process something that can be tolerated at compile time
17:08:44*laaron quit (Remote host closed the connection)
17:09:01shashlickPlus the fact that the nim output can be cached so you don't have to redo it all the time
17:09:08*Kaivo quit (Quit: WeeChat 2.5)
17:11:20*laaron joined #nim
17:11:47disrupteki suppose it's possible that it's cheap to render ast and expensive to render nim, but i guess i just make the user hack their compiler if they want to use moderate apis like aws, zuora, azure, etc. if i make it my problem, i'm unable to exert pressure to get it fixed.
17:13:32shashlickI think your use case is similar to nimterop, but are you converting the openapi json into Nim procs?
17:14:17alexander92disruptek: i feel this should be possible in a different way
17:14:45alexander92is it maybe possible to somehow split this work
17:15:00alexander92i thought this vm limit is for running a single top level macro
17:15:23alexander92maybe if you can generate invocations of 10 sub-macros, this might be enough to remedy it
17:16:18alexander92disruptek: but i still dont understand, why is it a problem to use staticExec: your code shouldn't change too much imho and it might run faster indeed
17:16:30disrupteki could do that if i repeat a lot of work to parse/analyze the input.
17:16:41disruptekwhat does staticExec do for me? nothing, afaict.
17:16:57Araqdawkot the fix isn't merged yet
17:17:26Araqhttps://github.com/pragmagic/karax/pull/110 try it please
17:17:31Araqand if it works, I shall merge it
17:17:50disrupteki'm pretty sure i want to convert the api into nim procs. i thought about having a pure-data api but i think that's probably less pleasant to use and more "surprising", but you could convince me otherwise.
17:18:19alexander92but you can just use the same code with staticExec
17:18:31disruptekand why would i do that?
17:18:33shashlickWell then whatever you are doing to generate the api can be done at runtime and pulled in via stdout + staticExec
17:18:50shashlickBut instead is macros, perhaps you can write runtime code
17:18:50alexander92to do it 1) faster 2) to not hit this vm limit (which seems as a good limit)
17:18:51disrupteki thought you can only return nimnode from procs at compile-time?
17:19:21disrupteki wanted this to be a runtime tool, but i got the impression that was impossible.
17:19:30alexander92but you can parseStmt iirc
17:19:42shashlickhttps://github.com/nimterop/nimterop/blob/master/nimterop/cimport.nim#L539
17:19:47Araqmarshal.nim also works at compile-time
17:19:58shashlickSee how I do it in nimterop
17:20:08Araqshashlick: given my design constraints back then I would do the same again
17:20:43shashlick@Araq any short one line explanation?
17:21:08Araqneeded: ability to construct NimNode / PNode
17:22:00Araqconsidered to use an existing VM like LuaJIT, was annoyed by producing yet another language not designed for code generation
17:23:09Araqconsidered to produce DLLs instead that Nim would load dynamically, was annoyed by Unix's handling of DLLs (I still consider it effectively *not* supported at all)
17:25:18Araqand I under-estimated how hard it would be to emulate low-level pointer stuff with the symbolic representation that my VM uses
17:26:13shashlickOk so using the staticExec equivalent or generating json or something else and convert back to NimNode would be too slow / kludgey?
17:26:28Araqit depends on what you're doing
17:27:32shashlickOk well I guess macros are powerful enough to POC it without compiler changes
17:28:51FromGitter<dawkot> Araq: the version of Karax you linked works for me!
17:29:00shashlickBut ya, other than ffi, the vm can do almost anything
17:34:25shashlickMy biggest frustration is os operations, mvFile etc which don't work in the vm
17:40:24Araqdawkot: thanks! I merged it
17:45:38shashlick@dom96 - https://github.com/nim-lang/nimble/pull/686
17:50:28*alexander92 quit (Ping timeout: 245 seconds)
17:51:56*hoijui joined #nim
17:55:51*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:06:30*abm quit (Read error: Connection reset by peer)
18:08:12*ofelas joined #nim
18:13:41FromGitter<mratsim> The new scheme that creates a .nims file from the nimble file seems to be broken
18:13:58FromGitter<mratsim> I often get ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d66c46610bb5d2db0885881]
18:14:13FromGitter<mratsim> I switch nim version, run the task and switch back and then it works
18:16:28shashlick@mratsim what version of nimble do you have
18:16:39shashlickHash
18:16:54FromGitter<mratsim> da82e3111e662fc1b12f96b3cddd66c749c0f686
18:19:21shashlickBasically this - https://github.com/nim-lang/nimble/issues/693
18:19:51shashlickWhat's the version of nimble that fails
18:20:09shashlickSince you are switching versions, you are probably using an older nimble too
18:22:44FromGitter<dawkot> Is there an idiomatic way to refer to other nodes in event handlers in Karax?
18:23:00FromGitter<dawkot> For example, you can refer to self if you use signature proc(ev: Event, n: VNode)
18:23:09FromGitter<dawkot> but what about a parent, for example
18:26:31AraqgetVNodeById iirc
18:26:51Araqthe VDOM has no parents because I don't believe in parents
18:27:07*actuallybatman quit (Ping timeout: 245 seconds)
18:28:30*rayman22201 joined #nim
18:33:08*abm joined #nim
18:33:28rayman22201I'm a few hours late (as usual lol) but I saw myself mentioned in regards to threading async stuff. I did a lot of research into how Go does it. Reading the irc logs, you basically got it right. The "goroutine" thread scheduler does work stealing. If an OS kernel call blocks, other threads in the pool steal tasks (they call them goroutines) from the blocked thread.
18:46:14FromGitter<mratsim> @shashlick, yes I'm switching via choosenim
18:51:19*laaron quit (Remote host closed the connection)
18:53:24*laaron joined #nim
18:53:46Araqrayman22201: to motivate you. your stuff is now on the critical path
18:54:05Araqwe need an asyncable spawn...
18:54:26rayman22201bah. ok
18:57:07*BigEpsilon quit (Ping timeout: 245 seconds)
19:00:04*actuallybatman joined #nim
19:01:35FromDiscord_<djazz> Huh, havent seen Karax before. Reminds me of the Mithril js framework (vdom)
19:01:45FromDiscord_<djazz> Huh, havent seen Karax before. Reminds me of the Mithril js framework (also vdom)
19:04:00FromGitter<mratsim> Ewww, What's the limit for global variables? [GC] cannot register global variable; too many global variables
19:07:46Araqmratsim: stop using unittest
19:08:19Araqthe limit is 3500
19:08:24FromGitter<mratsim> > _>
19:08:44FromGitter<mratsim> when is testament in the stdlib?
19:08:48Araq3500 different global variables are kinda good enough
19:09:40Araqtestament for the stdlib, yeah it's overdue
19:11:14FromGitter<mratsim> I agree, I'm also concerned about unittest impact on compilation speed due to all those templates instantiation. But no alternative besides the dark age of doAssert
19:11:32*owl_000 quit (Ping timeout: 248 seconds)
19:16:44*Ven`` joined #nim
19:18:18*krux02 joined #nim
19:28:20Araqtestament <pattern.here> ?
19:28:24Araqgood enough?
19:44:42*absolutejam joined #nim
19:47:51*ng0 quit (Quit: Alexa, when is the end of world?)
19:50:45*ng0 joined #nim
19:59:44*sagax quit (Quit: Konversation terminated!)
20:00:01*sagax joined #nim
20:06:42dom96Araq, yay, critical path for async spawn, how come?
20:09:02federico3we should fix unittest and merge it with testament to make it a good unit testing tool
20:10:40*abm quit (Ping timeout: 272 seconds)
20:12:57rayman22201@dom96 to give me incentive to actually work on it, and stop being lazy lol?
20:13:51*absolutejam quit (Ping timeout: 258 seconds)
20:22:33*nsf joined #nim
20:24:30FromGitter<mratsim> @narimiran there is a critical bug on Archlinux packaging of OpenBLAS - https://github.com/mratsim/Arraymancer/issues/375#issuecomment-525907194
20:24:38*Kaivo joined #nim
20:29:09*nsf quit (Quit: WeeChat 2.5)
20:40:25Araqwhy is that narimiran's problem?
20:41:54rayman22201@Araq @yglukhov[m]'s threadpool lib has two versions. A "complex" and a "simple" version. The "complex" version does simple work stealing. Do you want one or both versions in the stdlib?
20:42:10AraqI want mratsim's :P
20:42:24rayman22201Lol. Me too. But short term solution
20:46:16*hoijui quit (Ping timeout: 264 seconds)
20:48:53Araqwe should start with the 'simple' one
20:49:16Araqand we need to decide what to do with 'parallel', iirc Yuriy's doesn't support it
20:49:55narimiranAraq: it is not my problem, but i think @mratsim pinged me as i might be curious about it. and i am :)
20:50:44FromGitter<mratsim> yeah, we already had issues with arch openblas in the past when we wanted to add Arraymancer to testaments
20:50:48FromGitter<mratsim> testament*
20:51:02narimirani think it was with neo
20:51:35FromGitter<mratsim> nimblas actually ;)
20:51:46Araqwell it's linux package mangement. *shrug*
20:53:16Araqthe idea that non-authors can add value to software systems they don't understand seems to be a bad one. surprise.
20:53:55FromGitter<mratsim> Do you mean remove all the managers fromm all companies of the world?
20:55:17AraqI don't remember managers messing around with code
20:56:03FromGitter<mratsim> They mess around with requirements, deadlines, focus, metrics :P
20:56:16FromGitter<mratsim> They say "This is not important, this is"
20:56:45FromGitter<mratsim> And then you get: https://projectfailures.wordpress.com/2008/06/24/project-from-hell/
20:57:28Araqat least they get paid for it.
20:57:40rayman22201@araq hrmm I didn't consider parallel. I need to look more into it. I think even naive work stealing is a better default, but I see your point...
21:03:44*ng0 quit (Ping timeout: 260 seconds)
21:06:44*absolutejam joined #nim
21:07:49FromGitter<yglukhov> rayman22201: There's a benchmark in my threadpools repo, and it shows that simple (no work stealing) is always faster than complex (some work stealing). Didn't bother enough, because I like simple threadpool for its... simplicity :)
21:09:45FromGitter<mratsim> but do you Fibonacci? https://github.com/nim-lang/Nim/issues/11922
21:11:18*narimiran quit (Ping timeout: 268 seconds)
21:11:23*ng0 joined #nim
21:11:36FromGitter<yglukhov> no. in fact i didn't even test for recursive spawning. My use cases are always uniform tasks more or less.
21:12:47*sagax quit (Remote host closed the connection)
21:13:26rayman22201Uniform tasks are probably better with no work stealing. That's true
21:13:46FromGitter<mratsim> it's not "probably" it's always true ;)
21:14:11FromGitter<yglukhov> so why work stealing should be the default then? :)
21:14:13FromGitter<mratsim> but work stealing is asymptotically optimal on both balanced and unbalanced tasks
21:14:26rayman22201Lol. But I don't think it's true for non uniform tasks 😝
21:14:32FromGitter<mratsim> and the overhead is a couple nanosecond
21:15:39Araqrecursive stuff is quite common, esp if you simply try out the language as a newcomer
21:15:41FromGitter<mratsim> plenty of parallel algorithms are tree algorithms
21:16:17Araq("hey, I can sort in parallel with quicksort" ... <deadlock> ... "I'm underwhelmed.")
21:16:42FromGitter<yglukhov> Ok, I see. Could there be a way for the threadpool to auto-adjust dynamically somehow? So that it changes its behavior to work stealing in runtime?
21:17:05FromGitter<mratsim> just use work-stealing
21:17:16FromGitter<yglukhov> ok :)
21:17:18FromGitter<mratsim> if the worker has work, it will not steal anything so no overhead
21:17:36FromGitter<mratsim> if it has no work, well it was doing nothing anyway so ...
21:17:51Araqwell since you're all here. maybe we should learn from async's mistakes
21:18:03rayman22201Yuri! I thought your threadpool was the answer for a nice intermediate solution until Picasso RFC is ready. Now I'm worried. 😕
21:18:06FromGitter<mratsim> (my work stealing implementation is a bit different because it's the victim that has to check from time to time if there are work requests)
21:18:34Araqand simply embraces some official 3rd party solution (aka Picasso)
21:18:41FromGitter<mratsim> Picasso is not for soon
21:18:53FromGitter<yglukhov> Araq: move threadpools out of std?
21:19:19*Vladar quit (Remote host closed the connection)
21:19:26rayman22201Based on that logic both async and threadpools should be moved out of std
21:19:58Araquh oh
21:20:12AraqI summoned the demons once again
21:20:17rayman22201Lol
21:20:52FromGitter<yglukhov> Araq: no I thought that's what you meant, and just wanted to clarify. But what did you mean then? What should we learn from async mistakes?
21:21:03Araq {.deprecated: "use 'nimble install picasso' instead".}
21:21:07*tobbez quit (Ping timeout: 250 seconds)
21:21:16Araq<-- added to threadpool.nim
21:21:37FromGitter<yglukhov> So *that is* what you meant :)
21:21:38rayman22201Is that what you want for 1.0?
21:22:03Araqrayman22201: I want *some* thread pool that works with async
21:22:25Araqand the spawn/FlowVar interface is a good one
21:22:47rayman22201I agree. It's a good api.
21:23:16Araqbut this thread pool doesn't have to be in the stdlib
21:23:24FromGitter<yglukhov> but it should be `template spawnAsync(myCall: untyped): Future[T]` or smth, right? =)
21:23:28Araqas long as it works and we can delegate people to it
21:24:42Araq`spawnAsync`? ok, I guess
21:25:19Araqawait spawn foo() ?
21:25:37rayman22201what we had before was fine. FlowVar just gets modified to be compatible with Future. Exactly `await spawn foo()` just works.
21:26:13rayman22201I can submit a PR to Yuri's threadpool to do this.
21:26:27rayman22201But it leaves the stdlib threadpool kind of broken.
21:26:33FromGitter<mratsim> so when can we have interface so that we can replace threadpool by a pure interface?
21:26:44FromGitter<yglukhov> Just to let you know. I'm ok with deprecating threadpools in stdlib because theyre not meant for composability like async/await is. Asyncdispatch - dunno, I was against it recently, but i'm no longer sure.
21:27:04FromGitter<mratsim> and same thing for async, crypto, streams, json :P
21:27:06rayman22201I agre with @mratsim completely. we need interfaces
21:27:42Araqthe interfaces come afterwards, just like in math
21:27:53Araqyou end with the axioms. you don't start with them.
21:28:56rayman22201@yglukhov The nice thing about our experiment, is that you can combine asyncdispatch with threadpools easily, if you want to. If you don't want it, you can just ignore it. It's a feature :)
21:29:10FromGitter<mratsim> yes but then you have to deal with the friction/transition/deprecation period of switching
21:29:30Araqafter an endless amount of tinkering you figure out the axioms. then you present them in the book in reverse to pretend you're a genius and worked it all out from "first principles"
21:29:49FromGitter<mratsim> haha
21:29:54*laaron quit (Remote host closed the connection)
21:30:09FromGitter<mratsim> generics/typedescs would be a good candidate for that :P
21:31:08shashlickGosh anyone handing out Linux vms that I can test my Nim stuff on?
21:31:10rayman22201@Araq I just don't want to end up shipping a broken stdlib for 1.0... People will reach for the stdlib first. If they do that and see "sorry this stdlib threadpool is deprecated, use a third party lib". I think it will turn people off.
21:31:32rayman22201Why even include it in the stdlib if it's deprecated?
21:32:03FromGitter<mratsim> I don't want a split either like in D with there stdlib 1;0 and Phobos
21:32:19Araqbecause v1 is about polishing what we had, not about shiny new stuff with flaws yet to be found
21:32:25*laaron joined #nim
21:32:37sealmovequick reminder: can i compare two seqs to find out if they have same content?
21:32:43FromGitter<mratsim> anyway, managing expectations will be very important
21:32:51FromGitter<mratsim> @sealmove ==
21:32:53Araqit takes lots of iterations to produce something good
21:33:00sealmovemratsim: ty
21:33:09Araqso of course there is deprecated stuff in there
21:33:20FromGitter<yglukhov> rayman22201: Sure, I agree, but I'm not sure how to make flowvar awaitable efficiently. I'd rather do another threadpool that is async all the way :). But I didn't really put much thought into awaitable flowvars.
21:33:39rayman22201We did a livestream where we did it effectively
21:34:33FromGitter<mratsim> If you can keep the separation of concerns: async/await for IO and spawn/^ for compute and your special sauce if we want awaitable spawns that's great
21:34:54rayman22201But it sounds like Araq just wants me to "polish the turd we have" :-P
21:35:15Araqnot necessarily, I said what I would like to have
21:36:07Araqbut I am tired of this endless "oh, XYZ is not perfect, so we moved it into a Nimble package where it has the very same bugs as before, but now it's not even covered by the CIs, aren't you happy"
21:37:20Araqnot to mention that I'm sure people out there enjoy 'couldn't find threadpool.nim module' after updating Nim and having to search how to tweak their .nimble files
21:37:29Araqif they even had a .nimble file to begin with
21:37:54FromGitter<mratsim> and if nimble can read their .nimble file ....
21:38:03FromGitter<mratsim> that issue is very annoying
21:38:22Araqit's a choosenim problem IMO.
21:38:49Araqthe new Nimble is much more independent from Nim than before so there is no reason for choosenim between Nimble versions
21:38:58Araqlatest Nimble is always the best one.
21:38:59FromGitter<mratsim> ah I see
21:39:20*absolutejam quit (Ping timeout: 272 seconds)
21:40:33rayman22201This is why I was arguing for keeping threadpool in the stdlib, and replacing it with a better impl. At least then we get guaranteed CI coverage. a stdlib is all about quality control. But it seems like you are arguing to just not fix bugs in the stdlib threadpool anymore. That's what deprecated means to me anyway...
21:41:08Araqwell you're a bit unfair
21:41:50Araqif you "fix the threadpool" you cannot break 'parallel', would be a stange bugfix, don't you agree?
21:42:01*absolutejam joined #nim
21:42:18Araqand threadpool also happens to have APIs that are quite impossible to implement
21:42:33Araq(hi, interfaces! sorry we got them wrong)
21:43:01Araqso what we can do is add a threadpool2.nim
21:43:07*seni joined #nim
21:43:30Araqand don't mention threadpool.nim in the docs anymore and add a .deprecated pragma
21:43:42rayman22201technically, the only reason we are able to make stdlib FlowVars awaitable is because of a "hack" of the implementation, that we (almost unintentionally) exploited.
21:44:00Araqbut then if we add threadpool2.nim ... guess what, it starts in the state
21:44:11Araq"as unproven as threadpool1"
21:45:00shashlickI agree we shouldn't add any new features
21:45:07shashlickTakes a while to stabilize
21:45:09Araqproblems are not always "bugs to be fixed". Problems are also simply moved around and show up elsewhere
21:45:27*solitudesf quit (Ping timeout: 244 seconds)
21:46:24FromGitter<mratsim> Relevant quotes I found on my Archlinux profile I didn't use for almost 8 years ⏎ ⏎ > Ah, good taste! What a dreadful thing! Taste is the enemy of creativeness. ⏎ > Picasso ⏎ > ... [https://gitter.im/nim-lang/Nim?at=5d66f6304b1189084e7fab6b]
21:46:57rayman22201I argued originally for fixing the stdlib threadpool, and fixing bugs in the stdlib asyncdispactch. I'm not the one suggesting, "use an external lib".
21:47:45Araqrayman22201: as a contributor you have some power in how things are done here
21:48:21FromGitter<dawkot> how do you force karax to update a closure event handler?
21:49:07Araqdawkot: you recreate the virtual DOM all the time, the closures are part of it
21:49:28Araqso ... rayman22201 where is your PR again? can't find the link
21:50:08rayman22201@Araq I appreciate that. But you are king :-P so I defer to you in the end.
21:50:09rayman22201https://github.com/nim-lang/Nim/pull/11724
21:51:46*tobbez joined #nim
21:51:57Araqwell all CIs were red
21:52:07rayman22201because of the socketFD issue
21:52:11Araqdo you know why? what's this hack we exploited?
21:52:33FromGitter<mratsim> rename finish to finito and everything works
21:53:06rayman22201lol. yes
21:53:31rayman22201@Araq the hack is here: https://github.com/nim-lang/Nim/pull/11724/files#diff-d263b4d00404696838ea978039b1542cR262
21:54:22Araqwhy?
21:55:25Araqwhat's hacky about it?
21:55:57rayman22201The "event" object exists on the calling thread, but the "spawned" thread is what calls the "trigger" proc. this is unsafe, but works because of the way the compiler rewrite pass orders the code, such that the spawned thread runs the "trigger" proc before the calling thread can wake up.
21:57:30Araqhuh? "trigger" is not threadsafe?
21:57:38rayman22201No, why would it be?
21:57:49rayman22201trigger is from async, which is single threaded.
21:57:55Zevvoh no this again. as I remember it, the trigger is sent trough the pipe and makes the fd readable, so its safe. The problem was that each flowvar creates an fd. Or am I mixing stuff up?
21:58:15rayman22201Hi Zevv! I'm refreshing Araqs memory.
21:58:28Araqit's just some OS handle and OS APIs are threadsafe
21:58:33Araqusually
21:59:42FromGitter<yglukhov> that was I meant saying I can't see an obvious efficient way to make flowvars awaitable :)
21:59:51rayman22201the OS API might be, but shared memory is not. That is what is happening here.
22:00:10Araqshared memory? it's an integer
22:00:16rayman22201One thread has to reach into another threads memory to get the FD.
22:00:27Araqeven in bloody Nim land integers can be shared
22:01:30rayman22201But the "event" object that holds the integer is not threadsafe.
22:03:43Araqhmm you're right
22:03:45rayman22201It also has to get more complicated b/c as Zevv said earlier, unless we want to use a new FD for every spawn, and quickly eat all the FD's on your system, we need to do some threadsafe "psuedo FD" system.
22:04:20Araqcan't we poll it instead
22:04:22*shomodj joined #nim
22:05:28FromGitter<yglukhov> can we use one pipe per pool. and pass addrs of completed flowvars in it?
22:06:01FromGitter<yglukhov> that's what i do in my all way async thread pool :)
22:06:02rayman22201You only need one pipe per Async. threadpool doesn't need to care. Zevv and I actually devised a plan to fix this.
22:06:12rayman22201per Async Event loop*
22:06:18Zevvthat's about what we did, but that broke semantics of ioselector events
22:06:41AraqI like polling, it's the only thing that composes, this event based stuff always fails on the 'waitFor a OR b' problem when 'a' and 'b' have different implementations...
22:06:45*shomodj quit (Client Quit)
22:07:08*Zevv really needs to get to bed, only 5 hours of sleep ahead. sorry
22:07:20rayman22201gn Zevv. thanks for popping in
22:09:40*lritter quit (Quit: Leaving)
22:09:42Araqindeed, thanks Zevv
22:11:00Araqso ... implement what Zevv said and there you go. simple. I don't understand any of it but that's ok
22:11:35rayman22201lol. That was our plan, but we got sidetracked with the Chronos crap, and you said you wanted us to use Yuri's threadpool instead.
22:12:12rayman22201I'm not sure what you mean by polling? That is what AsyncDispatch does?
22:12:45rayman22201we just need to make sure it's threadsafe (something it didn't need to worry about before).
22:13:58rayman22201Anyway. I have a plan now. :-)
22:16:30*abm joined #nim
22:19:35*abm quit (Client Quit)
22:20:32*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:54:00*laaron quit (Remote host closed the connection)
22:57:19*laaron joined #nim
23:03:50*ng0 quit (Quit: Alexa, when is the end of world?)
23:08:38*absolutejam quit (Ping timeout: 272 seconds)
23:34:05Cadeyhttps://christine.website/blog/how-send-email-nim-2019-08-28
23:42:32rayman22201🎉 awesome
23:42:35*laaron quit (Remote host closed the connection)
23:44:36*laaron joined #nim
23:53:30*krux02_ joined #nim
23:56:27*krux02 quit (Ping timeout: 264 seconds)
23:58:25*owl_000 joined #nim