<< 03-06-2024 >>
00:04:51FromDiscord<leorize> nim is what you call "organically grown"
00:05:03FromDiscord<leorize> as you can see, all natural doesn't mean good \:p
00:05:15FromDiscord<Elegantbeef> And much like organic food, it means it's bullshit
00:05:32FromDiscord<Elegantbeef> Believe it or not, all food is organic!
00:37:03FromDiscord<zumi.dxy> In reply to @leorize "nim is what you": php is probably the best example of "organically grown" I know :p
00:42:05FromDiscord<Elegantbeef> "best"?
00:42:24FromDiscord<zumi.dxy> "best" as in, y'know↵lmao
00:59:36*beholders_eye quit (Read error: Connection reset by peer)
01:03:27*rockcavera quit (Remote host closed the connection)
01:04:46*rockcavera joined #nim
01:05:06*beholders_eye joined #nim
01:08:26Amun-Ra;)
01:08:47Amun-Raas best STD?
01:14:01FromDiscord<leorize> https://github.com/nim-lang/Nim/commit/35b0cc67e89a929270e77c07ecbf06f7cced3668↵(@zumi.dxy)
01:14:55FromDiscord<leorize> little known trivia is that nim used to be able to compile to php
01:25:02FromDiscord<Robyn [She/Her]> Holy shit, damn
01:31:08FromDiscord<zumi.dxy> In reply to @leorize "little known trivia is": I tried that old version the other day
01:31:16FromDiscord<zumi.dxy> it was wild
02:51:43FromDiscord<fakuivan> is there an official lsp for nim? what's the status on that feature?
02:55:34*beholders_eye quit (Read error: Connection reset by peer)
02:55:44*lucasta quit (Quit: Leaving)
03:01:15*beholders_eye joined #nim
03:01:48FromDiscord<Elegantbeef> nimlangserver
03:26:59*beholders_eye quit (Ping timeout: 264 seconds)
03:36:25*krux02_ quit (Remote host closed the connection)
03:56:52FromDiscord<threefour> Status: works pretty well for me, personally.
04:31:27FromDiscord<huantian> In reply to @Elegantbeef "Why have a testable": don't you know that english is the soundest language?
04:38:30FromDiscord<Elegantbeef> @huantian It does not even use all human phonetics!
04:40:51FromDiscord<zumi.dxy> English is a "simple" language isn't it
04:44:13NimEventerNew thread by miran: This Month with Nim: October 2023 to June 2024, see https://forum.nim-lang.org/t/11693
05:26:32FromDiscord<odexine> thats a really long month
05:28:22FromDiscord<Elegantbeef> > (It is a long month)
05:38:50FromDiscord<zumi.dxy> can't be any longer than September 1993 😏
05:50:12FromDiscord<System64 ~ Flandre Scarlet> In reply to @zumi.dxy "php is probably the": Php sucks
07:04:35FromDiscord<.bobbbob> sent a code paste, see https://play.nim-lang.org/#pasty=LNEFRTiy
07:49:51FromDiscord<nnsee> interesting theory
07:50:05FromDiscord<nnsee> i'll test this when i get to the office
08:08:25FromDiscord<.bobbbob> I tested it by sending a blank get request using netcat but nginx rejects it so I don't think it's that actually
08:39:38*rockcavera quit (Remote host closed the connection)
09:17:53FromDiscord<nnsee> In reply to @.bobbbob "I tested it by": is your code available somewhere?
09:26:37Amun-Rawhat that blank request looked like?
09:32:19FromDiscord<nnsee> well i can reproduce the blank request
09:32:23FromDiscord<nnsee> but it doesn't crash for me
09:32:39FromDiscord<nnsee> probably because `ensureCorrectRoute` is not being called
09:32:49FromDiscord<nnsee> and i'm not 100% yet what codepath calls it
09:34:02FromDiscord<nnsee> unless the stacktrace is wrong
09:34:05FromDiscord<nnsee> which... wouldn't be surprising
09:39:04FromDiscord<nnsee> oh, never mind, i _can_ reproduce it
09:39:17FromDiscord<nnsee> ... on the commit tagged 0.6.4
09:39:25FromDiscord<nnsee> on the latest commit, it doesn't crash
09:41:01FromDiscord<nnsee> looks like this commit fixed it https://github.com/planety/prologue/commit/e676b9a85fc66d136177aef94d30fdcd58d45fcb
09:41:33FromDiscord<nnsee> @.bobbbob
09:41:42FromDiscord<nnsee> use `#head`
09:43:01FromDiscord<nnsee> sent a code paste, see https://play.nim-lang.org/#pasty=yPGUzrkt
09:44:06FromDiscord<nnsee> maybe there are cases where nginx lets blank requests through. i've never had this happen with pasty and i'm also on prologue v0.6.4, but i also use Caddy instead of nginx
09:45:49FromDiscord<nnsee> @ringabout you might also be interested in this
09:46:03FromDiscord<nnsee> speaking of which, are there any plans for a new tagged release any time soon?
09:51:57FromDiscord<ringabout> In reply to @nnsee "<@658563905425244160> you might also": thank you! => https://github.com/planety/prologue/releases/tag/v0.6.6
09:54:09FromDiscord<nnsee> awesome! thanks
10:01:14*beholders_eye joined #nim
10:54:34*ntat joined #nim
11:10:47*beholders_eye quit (Ping timeout: 264 seconds)
11:22:56*xet7 joined #nim
11:48:51*xutaxkamay quit (Read error: Connection reset by peer)
11:48:53*xutaxkamay_ joined #nim
11:49:44*xutaxkamay_ is now known as xutaxkamay
12:12:59*beholders_eye joined #nim
12:46:51*krux02 joined #nim
12:59:41*beholders_eye quit (Ping timeout: 240 seconds)
13:00:27*beholders_eye joined #nim
13:06:06*xutaxkamay_ joined #nim
13:06:19*xutaxkamay quit (Read error: Connection reset by peer)
13:06:56*xutaxkamay_ is now known as xutaxkamay
13:56:40*rockcavera joined #nim
15:32:01FromDiscord<.bobbbob> In reply to @nnsee "awesome! thanks": Awesome, thanks for working in that
15:32:10FromDiscord<.bobbbob> (edit) "in" => "on"
16:41:06*zgasma joined #nim
16:46:37FromDiscord<summarity> > Can't fold empty sequences↵I wish the default was to just skip empty ones ...
16:47:33*beholders_eye quit (Read error: Connection reset by peer)
16:53:29*beholders_eye joined #nim
17:06:21FromDiscord<can.l> In reply to @isofruit "At least I *think*": Sorry for the late reply, but yes that sounds about right.
17:28:54FromDiscord<Phil> In reply to @can.l "Sorry for the late": The state duplication was necessary mostly to handle stuff like dynamic widgets right?↵So e.g. add/remove a given widget if a given if condition is fulfilled or not
17:30:32FromDiscord<can.l> In reply to @isofruit "The state duplication was": Yeah, the `Widget`/`WidgetState` separation is required for widgets with internal state.
17:30:51FromDiscord<can.l> E.g. a text entry, a form, ...
17:32:27FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=ZwErQvms
17:48:24FromDiscord<can.l> sent a long message, see https://pasty.ee/uAUTJaqd
17:48:42FromDiscord<can.l> (edit) "https://pasty.ee/JdZxqQCI" => "https://pasty.ee/bSYvDLWq"
17:49:58FromDiscord<Phil> Ahh, entirely fair! @guttural666, some educational reading for you above 😄
17:50:31FromDiscord<Phil> In reply to @can.l "I am actually not": Sidenote, since I'm seeing my own comment now:↵Any thoughts on us wrapping Gio.Task?
17:50:41FromDiscord<Phil> Mostly because it is a form of multithreading
17:51:37FromDiscord<can.l> In reply to @isofruit "Sidenote, since I'm seeing": I've never used it, so I don't really have any opinions yet 🙂
17:52:13FromDiscord<Phil> In fact, if we provide an implementation for a "mailbox" (just system.Channel or therading/channels.Chan by another name) that the user can send messages to and they can also check in the main-thread on re-render, then you basically have a nim-independent version of multithreading
17:52:28FromDiscord<Phil> (edit) "therading/channels.Chan" => "threading/channels.Chan"
17:53:34FromDiscord<Phil> In reply to @can.l "I've never used it,": IIRC from my time discussing multithreading options of GTK with the folks there, GTK provides 2 mechanisms for multithreading:↵1) Their own queue↵2) Gio.Task which are just executing one-off procs like "Save this, but do it in another thread".
17:54:13FromDiscord<Phil> https://docs.gtk.org/gio/class.Task.html↵Here's the docs for it.
17:54:36*beholders_eye quit (Ping timeout: 255 seconds)
17:55:03FromDiscord<Phil> The only tricky thing could be to trigger a GUI update from Thread B after it has sent a message to Thread A
17:55:24FromDiscord<Phil> As that message should be processed by Thread A and may cause potential GUI updates (like a progress bar ping or the like)
17:55:49FromDiscord<Phil> (edit) "The only tricky thing could be to trigger a GUI update from Thread B after it has sent a message to Thread A ... " added "(Thread A has the GTK Loop)"
17:56:31FromDiscord<can.l> We definitely need better support for multithreading. If its possible to build a nice API on top of Gio.Task, then I currently don't see why we should not use it.
17:56:44FromDiscord<can.l> (edit) "currently" => "(at least currently)"
17:56:47FromDiscord<Phil> The benefit of using the GTK stuff here is that we don't have to give a hoot how Nim does multithreading
17:57:51FromDiscord<can.l> Hmm, there should probably be some level of interop with the rest of the nim ecosystem though.
17:58:21FromDiscord<Phil> I'll open an issue for that since I think it's an interesting avenue to go down.↵The API for usage here could be pretty nice, because writing a mailbox or an actor-task (equivalent to Dart isolates) is pretty simple it turns out (I started writing one, just stuck there with some issues around a memory leak at one point)
17:59:16FromDiscord<can.l> Sure, its definitely worth investigating.
17:59:26FromDiscord<Phil> In reply to @can.l "Hmm, there should probably": You don't really need it.↵As in, you don't need to care how a thread is instantiated or managed. That is almost entirely custom every time anyway.↵The important bit is inter-thread communication.↵And for that you have like, half a dozen options
18:00:19FromDiscord<Phil> From using nim's current stuff (system.Channel) to using what nim plans on going towards (threading/channels.Chan) to what likely is the best technical choice I'm aware of so far (disruptek loonyqueue), to what GTK provides itself (its own queue, though I'm not 100% if that was threadsafe or not)
18:03:48FromDiscord<leorize> famous last words
18:03:49FromDiscord<leorize> > is pretty simple it turns out
18:03:50FromDiscord<Phil (he/him)> Bridge is down it turns out, didn't see that one yet
18:03:51FromDiscord<Phil (he/him)> I mean, the principle is simple.↵The thing that leaks isn't the mailbox or the like since that's just an abstraction over an already existing thread-safe queue, the thing that leaks is everybody fucking else
18:05:32FromDiscord<leorize> it will take awhile before you can say nim have "fearless concurrency" it seems \:p
18:06:35FromDiscord<Phil> I'll need to get back to trying to figure out what leaked in my latest iteration of threadbutler/slacktors
18:06:41FromDiscord<Robyn [She/Her]> What would give Nim fearless concurrency? What sort of guarantees does a language need to provide in order to be able to claim that?
18:06:42FromDiscord<Phil> though right now just enjoying vacation
18:07:31FromDiscord<Phil> In reply to @chronos.vitaqua "What *would* give Nim": A starting point:↵1) Automatic correct change of memory ownership between threads↵2) Threads that clean up memory before they exit on their own so I don't have to investigate every single thread-variable that might blow up on me
18:07:54FromDiscord<Phil> That alone would alleviate 75% of my gripes that I encountered
18:08:03FromDiscord<Phil> (edit) "That alone would alleviate 75% of my gripes that I encountered ... " added "so far"
18:09:46FromDiscord<Phil> The other 25% are based around wanting to have async-event-loops in existing threads so that users can send async tasks and don't have to give a hoot about waitFor (basically similar dev-experience to how in JS you never need to waitFor, you only need to await)
18:10:11FromDiscord<Robyn [She/Her]> Automatic change of memory ownership sounds like it needs to be something that's expected by default :P
18:10:31FromDiscord<Robyn [She/Her]> Also with a memory manager like arc, couldn't a thread simply create a new scope that, on exit, cleans itself up?
18:10:43FromDiscord<Phil> In reply to @chronos.vitaqua "Automatic change of memory": Nim very much doesn't deal with that cleanly. Or rather is in an awkward transition point where it once to transition from what it had before but the new stuff isn't quite there
18:11:05FromDiscord<Robyn [She/Her]> Ah
18:11:16FromDiscord<Phil> And the current "solution" for that is glue a piece of paper over a hole and claim that there's no hole
18:11:31FromDiscord<Robyn [She/Her]> Does `sink` not do the job?
18:11:33FromDiscord<Phil> By which I mean std/isolation which conceptually just doesn't work
18:11:54FromDiscord<Phil> No, because while you might be sinking this particular reference of your data into a message for the other thread, that doesn't mean it's your only reference to that data
18:12:18FromDiscord<Robyn [She/Her]> Ah
18:12:32FromDiscord<Phil> And the goal must be to invalidate all your possible available references to that data when you send it to another thread
18:12:35FromDiscord<Robyn [She/Her]> Is that where compiler support like a borrow checker is needed to ensure those guarantees?
18:13:36FromDiscord<Phil> That is a problem so hard that even Araq just gave up and said "You need to make sure that only one reference exists and isolate it".↵However, that can't work.↵You often generate data in point A, e.g. via user-input and then want to pass it off to another thread
18:13:41FromDiscord<Phil> (edit) "That is a problem so hard that even Araq just gave up and said "You need to make sure that only one reference exists and isolate it".↵However, that can't work.↵You often generate data in point A, e.g. via user-input and then want to pass it off to another thread ... " added "in point B"
18:14:28FromDiscord<Phil> So now you're either polluting your entire application with isolates or you go the much saner (for the general, non performance critical usecase) route and just flipping copy the message
18:14:46FromDiscord<Phil> Which is a huge nono if whatever you want to send some huge object to another thread
18:15:00FromDiscord<Phil> And for that scenario I have no solution other than don't send large objects to another thread
18:15:49FromDiscord<Phil> In reply to @chronos.vitaqua "Is that where compiler": That goes beyond my paygrade, you'd need to ask Araq
18:15:54FromDiscord<Phil> I don't know or even if Rust does it
18:15:59FromDiscord<Phil> (edit) "I don't know ... or" added "how"
18:42:56FromDiscord<Robyn [She/Her]> In reply to @isofruit "I don't know how": Rust uses lifetimes and unless you use unsafe code, you can only have one mutable reference at a time
18:43:00FromDiscord<Robyn [She/Her]> That probably does wonders
18:44:19FromDiscord<Robyn [She/Her]> In reply to @chronos.vitaqua "Rust uses lifetimes and": At least, if I'm not mistaken this is the case
18:48:25FromDiscord<Phil> In reply to @chronos.vitaqua "At least, if I'm": Not that much, unless the compiler is capable on analyzing cross-thread lifetimes.↵It'd need to infer that the reading reference you use on Thread A falls out of scope before you free the object on Thread B.↵That is not possible at compile-time, because various operations have variable time (basically if it touches IO you can't know when something will finish)
18:48:43FromDiscord<Phil> Because who has reading and writing references isn't the problem, the problem is you having a reference at all
18:49:08FromDiscord<Phil> Because having a reference in Thread A and Thread B, means that Thread A might access the memory of that data after that memory was freed on Thread B
18:50:46FromDiscord<Phil> So how they're most likely doing it is either using unsafe or putting the message stuff in a locked datastructure from the get-go
18:51:41FromDiscord<Phil> Or they copy
18:52:38FromDiscord<Phil> Actually the locked data-structure thing is nonsense because that's just shared state, we're talking message passing so you'd just pump it into a queue and pray for the best.
18:53:13FromDiscord<Phil> The only way I can understand so far to do message-passing without fearing to blow your leg off really is just copying the message
18:53:27FromDiscord<Phil> Anything else I've seen so far relies on you having understood what you're doing
18:53:48FromDiscord<Phil> (edit) "Anything else I've seen so far relies on you having understood what you're doing ... " added "and you guaranteeing that there are no references to anything in the message remaining on your thread"
18:56:05*nils` quit (Remote host closed the connection)
18:59:36FromDiscord<Robyn [She/Her]> So fearless concurrency is a lie? :p
19:02:19FromDiscord<Phil> sent a long message, see https://pasty.ee/gUbxyHZB
19:03:01FromDiscord<Phil> That enables pretty much everything you could need from task-based concurrency, and rather neatly too I think.↵Sure, you can't do actor-based models yet, but I think tasks should cover that usecase sufficiently
19:03:51*Gliptic left #nim (WeeChat 3.5)
19:15:45*ntat quit (Quit: Leaving)
19:26:20FromDiscord<Phil> Holy shit we can do even better!↵You literally are allowed to call g_idle_add etc. from task-threads!
19:26:26FromDiscord<Phil> (edit) "task-threads!" => "task-threads to schedule callbacks on the main thread!"
19:26:48FromDiscord<Phil> So you don't even need a message queue, just call g_idle_add on the task-thread with new data
19:27:33*xutaxkamay quit (Quit: ZNC 1.8.2+deb3.1 - https://znc.in)
19:31:10FromDiscord<Phil> @michaelb.eth I am currently fascinated by the fact that GTK has something that functions similarly to what your plans for an async queue are
19:31:12FromDiscord<Phil> And I'm in awe
19:31:36FromDiscord<michaelb.eth> sounds cool!
19:32:25FromDiscord<Phil> Essentially tasks just add async callbacks and given that GTK on its own deals with having that event-loop it essentially is no effort at all on your part.↵No need for a message-queue even, just schedule a callback, done
19:32:42FromDiscord<Phil> (edit) "Essentially tasks just add async callbacks and given that GTK on its own deals with having that event-loop ... it" added "that triggers those callbacks"
19:32:54FromDiscord<Phil> Which implies that scheduling callbacks from another thread is thread-safe, which is bonkers
19:33:21FromDiscord<Phil> I mean in the context of GTK it is somewhat allowed, the assumption that your GTK thread is alive longer than your task-thread holds up
19:33:44FromDiscord<Phil> (edit) "up" => "up. Therefore accessing state on it inside a task-thread seems like it'd make sense to be legal"
19:34:20FromDiscord<Phil> What could be risky is if the task thread generates a large object and wants to push that to the main thread, I guess that could become problematic again given that nim by default would try to free that in the task-thread
19:34:25FromDiscord<Phil> (edit) "What could be risky is if the task thread generates a large object and wants to push that to the main thread, I guess that could become problematic again given that nim by default would try to free that in the task-thread ... " added "once it falls out of scope"
19:35:16FromDiscord<Phil> In that case I guess you could try to rely on using pointers and manual deallocation
19:38:32NimEventerNew thread by mantielero: Varargs pragma - expanding a seq[cint], see https://forum.nim-lang.org/t/11701
19:47:04*beholders_eye joined #nim
19:47:24*beholders_eye quit (Client Quit)
19:53:27*xutaxkamay joined #nim
20:07:44NimEventerNew thread by nrk: Monoucha: a high level QuickJS wrapper, see https://forum.nim-lang.org/t/11702
20:08:52*lain quit (Remote host closed the connection)
20:09:35*lain joined #nim
20:12:53FromDiscord<ElegantBeef> In reply to @isofruit "No, because while you": More importantly you cannot sink references 😛
20:13:25FromDiscord<ElegantBeef> In reply to @chronos.vitaqua "Rust uses lifetimes and": This only works if you do not have ref counted data
20:13:47FromDiscord<Phil> Not really more importantly. Sure, I fucked up the semantics there, but the idea was to move ownership of a given ref into proc so that you can move it into the send proc.↵That just doesn't work
20:13:49FromDiscord<ElegantBeef> If you do not use `ref` in Nim you can just pass the data like you would in Rust with the one thing that you have to manage the lifetime
20:13:59FromDiscord<ElegantBeef> I mean you cannot move ownership is the point
20:14:14FromDiscord<Phil> Of a single ref you can, not of a piece of memory
20:14:33FromDiscord<ElegantBeef> I'm fairly certain you cannot sink a reference
20:16:38FromDiscord<ElegantBeef> I could be wrong
20:17:56FromDiscord<Phil> Turns out you can, it's just a use-after-free and a bad idea
20:18:01FromDiscord<ElegantBeef> What?
20:18:03FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=EpkqTvxF
20:18:15FromDiscord<ElegantBeef> Sure you can explicitly call `=sink`
20:18:23FromDiscord<ElegantBeef> But that's not what anyone means when they say "you can sink"
20:18:39FromDiscord<ElegantBeef> The question is whether `sink` actually takes the parmeter
20:19:52FromDiscord<Phil> Turns out, it will compile, it just won't do shit
20:20:17FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=hRqtxOsu
20:20:20FromDiscord<ElegantBeef> sent a code paste, see https://play.nim-lang.org/#pasty=UPJNsZNM
20:20:29FromDiscord<ElegantBeef> sent a code paste, see https://play.nim-lang.org/#pasty=Xgzbakyi
20:20:33FromDiscord<Phil> (edit) "https://play.nim-lang.org/#pasty=RuivvZgD" => "https://play.nim-lang.org/#pasty=weHrZOcX"
20:20:46FromDiscord<ElegantBeef> so indeed `sink ref` actually does work it seems
20:21:11FromDiscord<ElegantBeef> Cmon phil you're purposely causing a copy
20:21:24FromDiscord<ElegantBeef> Use after move in Nim implicitly copies
20:21:37FromDiscord<Robyn [She/Her]> How do I make tests for my Cordyceps lib
20:21:48FromDiscord<Phil> `let` doesn't really change the outcome
20:22:00FromDiscord<Phil> Ah, hm
20:22:02FromDiscord<ElegantBeef> sent a code paste, see https://play.nim-lang.org/#pasty=VLpVOnPE
20:22:07FromDiscord<ElegantBeef> Does exactly what you expect
20:22:56FromDiscord<Phil> Yeah, because move, not sink
20:23:08FromDiscord<ElegantBeef> Well cause you use after move
20:23:12FromDiscord<nnsee> why is beef on discord
20:23:15FromDiscord<ElegantBeef> If you looked at the expanded arc it works just fine
20:23:18FromDiscord<ElegantBeef> Bridge is dieded
20:23:27FromDiscord<ElegantBeef> sent a code paste, see https://play.nim-lang.org/#pasty=NFxrAJYI
20:23:33FromDiscord<ElegantBeef> That was the expanded arc of the first example
20:23:46FromDiscord<ElegantBeef> sent a code paste, see https://play.nim-lang.org/#pasty=MzaBjNcD
20:24:07FromDiscord<ElegantBeef> No `=dup` or `=copy` was invoked
20:24:30FromDiscord<Phil> I mean, the core of the argument doesn't really change:↵You can make sure that a ref in X is no longer in X. But you can't make sure that all references to the data behind X are now nil'd
20:24:46FromDiscord<Phil> (edit) "X. But" => "X, be that via move or sink or whatnot. ↵But"
20:25:05FromDiscord<ElegantBeef> Well you can if you wrap your `ref` with something like `Isolation` and disable `=copy` and `=dup` 😄
20:25:25FromDiscord<Phil> Which now makes your code tedious, unergonomic and painful to write
20:25:40FromDiscord<Phil> Because you can no longer easily create data in point A and move it off-site in point B
20:25:43FromDiscord<ElegantBeef> You need to give up memory which means ownership is front in senter
20:25:44FromDiscord<Phil> (edit) "off-site" => "off-thread"
20:25:47FromDiscord<ElegantBeef> (edit) "senter" => "centre"
20:25:50FromDiscord<ElegantBeef> Well you can
20:25:59FromDiscord<ElegantBeef> You can write any abstraction on top of Isolation
20:26:24FromDiscord<ElegantBeef> <https://github.com/beef331/nimtrest/blob/master/loner.nim>
20:26:32FromDiscord<ElegantBeef> A shitty example created due to one of the forum posts
20:27:01FromDiscord<ElegantBeef> You can call `isolatedCopy` and it'll make a new tree copying any nodes that have multiple references
20:27:06FromDiscord<ElegantBeef> Recursively in a cyclical graph
20:28:05FromDiscord<ElegantBeef> This means `A -> B -> C -> D -> A` can be isolated but it copies the entire tree but `A -> B -> C` where you have reference to `C` elsewhere copies `C`
20:29:58FromDiscord<ElegantBeef> <https://github.com/beef331/nimtrest/blob/master/toys%20of%20toys/lonerexample.nim> for a usage example
20:30:05FromDiscord<ElegantBeef> Not overly compelling of course
20:31:43FromDiscord<Phil> Another common usecase I have there though is mutating.↵Chances are I'm building a large object in point A, forward that to point B and from there to point C where I move it to another thread.↵However along the way I want to mutate the damn thing in point B. I still don't need the data inside my own thread, but essentially a `map` operator would be prudent.
20:32:01FromDiscord<Phil> (edit) "prudent." => "prudent as I don't want to copy the entire thing, just modify it before sending."
20:48:54FromDiscord<Robyn [She/Her]> Ugh I need those helper macros and such to create `init` procs and converters
21:15:38*Jhonny2x4 quit (Quit: Jhonny2x4)
21:15:56*Jhonny2x4 joined #nim
21:15:58*Jhonny2x4 quit (Client Quit)
21:17:22*Jhonny2x4 joined #nim
21:23:04*Jjp137 quit (Quit: Leaving)
21:24:53*Jjp137 joined #nim
21:26:05*Jhonny2x4 quit (Quit: Jhonny2x4)
21:28:21*Jhonny2x4 joined #nim
21:32:26*Jhonny2x4 quit (Client Quit)
21:32:46*Jhonny2x4 joined #nim
21:34:09*Jhonny2x4 quit (Client Quit)
21:34:30*Jhonny2x4 joined #nim
21:42:07*Jhonny2x4 quit (Quit: Jhonny2x4)
21:42:28*Jhonny2x4 joined #nim
21:52:21*beholders_eye joined #nim
22:02:35*Jhonny2x4 quit (Quit: Jhonny2x4)
22:02:57*Jhonny2x4 joined #nim
22:07:09*Jhonny2x4 quit (Client Quit)
22:07:29*Jhonny2x4 joined #nim
22:40:18*rockcavera quit (Read error: Connection reset by peer)
22:40:37*rockcavera joined #nim
22:40:37*rockcavera quit (Changing host)
22:40:37*rockcavera joined #nim
22:51:11*jmdaemon joined #nim
22:56:01*deadmarshal_ quit (Remote host closed the connection)
23:02:41*jmdaemon quit (Ping timeout: 268 seconds)
23:25:36*beholders_eye quit (Ping timeout: 252 seconds)
23:26:00*beholders_eye joined #nim
23:27:51*deadmarshal_ joined #nim