<< 02-05-2024 >>
00:05:48FromDiscord<morgan> i decided to look thru the code on my phone and found a few mistakes
00:22:08FromDiscord<morgan> In reply to @morganalyssa "after this i gotta": the plugin is a graphic eq, not emulating anything in specific but it is going for that sort of analog retro sound, it’s very nonlinear
00:28:00FromDiscord<morgan> also i’m contemplating what to call the library, nim-plug sounds nicer than nim-plugin but nih-plug (in rust) is literally one character off
00:28:34FromDiscord<morgan> i might call it nap, for nim audio plugin and theme all the names related to sleep
00:29:06FromDiscord<morgan> also i should probably split apart clap specific code from the abstraction layer and whatever else
00:30:32FromDiscord<Elegantbeef> Putting Nim in the title is lame
00:31:57FromDiscord<Elegantbeef> I like silly names so I'd probably call it like "quarterinch"
00:33:05FromDiscord<Elegantbeef> For those that are confused. 1/4" is a common size of audio plugs outside of consumer electronics
00:33:40FromDiscord<morgan> hm yea
00:40:27FromDiscord<aryzen> instead of doing about 30 lines of `{.link: "xyz.a".}` is there a way to link a directory?
00:41:02FromDiscord<Elegantbeef> Use a macro to iterate a directory and emit the link statements
00:41:16FromDiscord<Elegantbeef> Use CTE in your config to pass link to the C compiler
00:42:13*def- quit (Quit: -)
00:42:25*def- joined #nim
00:42:46FromDiscord<aryzen> oof... I don't think I'm smart enough to figure out how to do that yet :S
00:42:58FromDiscord<aryzen> I'll look it up, thanks!
00:43:18FromDiscord<Elegantbeef> `<https://github.com/beef331/keyboardwarrior/blob/master/programs/programutils.nim#L13-L18>`
00:43:23FromDiscord<Elegantbeef> Whoops
00:43:23FromDiscord<Elegantbeef> https://github.com/beef331/keyboardwarrior/blob/master/programs/programutils.nim#L13-L18
00:44:01FromDiscord<Elegantbeef> Replace with `newStmtList()` and `nnkPragmaExpr.newTree(ident"link", fileName)`
00:44:10FromDiscord<aryzen> oh wait this looks easy...
00:45:07FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=IlAEpwRNrcKo
00:49:18*progranner joined #nim
00:50:26*progranner quit (Client Quit)
01:21:59*lucasta quit (Quit: Leaving)
01:22:31FromDiscord<wileycoleman> sent a code paste, see https://play.nim-lang.org/#pasty=DDDVMWshqJju
01:22:53FromDiscord<Elegantbeef> You didn't export
01:24:11FromDiscord<Phil> I understand that guy was being a really dumb bot - the problem is that both PMunch and I are sleeping (or I should be sleeping again rather)
01:25:50FromDiscord<wileycoleman> sent a code paste, see https://play.nim-lang.org/#pasty=IconziAmEgqk
01:26:00FromDiscord<Elegantbeef> `export GameView`
01:26:10FromDiscord<Elegantbeef> `export GameViewState`
01:28:44FromDiscord<wileycoleman> In reply to @Elegantbeef "`export GameView`": Where do I put those lines? It doesn't work in game_view.nim file.
01:28:55FromDiscord<Elegantbeef> After you define the type
01:34:50FromDiscord<wileycoleman> sent a code paste, see https://play.nim-lang.org/#pasty=mHWcbnMVkJUj
01:36:13FromDiscord<Elegantbeef> Not in the type definition
01:36:18FromDiscord<Elegantbeef> `export` is a Nim feature
01:36:25FromDiscord<Elegantbeef> you can use it anywhere to export a symbol in a module
01:36:36FromDiscord<Elegantbeef> It has to be top level though
01:37:40FromDiscord<wileycoleman> The example that I linked to doesn't do any export.
01:41:27FromDiscord<Elegantbeef> You have to export the viewable if you want to use it outside
01:41:27FromDiscord<Elegantbeef> I do not care what they do 😄
01:41:40FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=xlvyXdqCmwEF
02:04:18FromDiscord<wileycoleman> sent a code paste, see https://play.nim-lang.org/#pasty=tqdGGNOpeKUB
02:15:34FromDiscord<morgan> In reply to @isofruit "I understand that guy": ah understandable, are there any mods in the americas? spreading out timezone coverage would be a good idea
02:41:05*def- quit (Quit: -)
02:41:59*def- joined #nim
02:52:28*def- quit (Quit: -)
02:54:15*def- joined #nim
03:11:07*def- quit (Quit: -)
03:13:00*def- joined #nim
07:05:05*PMunch joined #nim
07:09:54*ntat joined #nim
07:18:51*def- quit (Quit: -)
07:19:18*def- joined #nim
07:19:40*SchweinDeBurg quit (Quit: WeeChat 4.3.0-dev)
07:20:01*SchweinDeBurg joined #nim
07:23:11*beholders_eye joined #nim
07:30:35*beholders_eye quit (Read error: Connection reset by peer)
07:36:39*beholders_eye joined #nim
07:49:17*def- quit (Quit: -)
07:49:50*def- joined #nim
07:52:50*beholders_eye quit (Ping timeout: 245 seconds)
08:55:35*PMunch quit (Ping timeout: 268 seconds)
08:59:52*def- quit (Quit: -)
09:01:42*def- joined #nim
09:05:55*beholders_eye joined #nim
09:19:38*beholders_eye quit (Ping timeout: 268 seconds)
09:52:20*beholders_eye joined #nim
10:07:59*beholders_eye quit (Ping timeout: 252 seconds)
10:12:10*beholders_eye joined #nim
10:27:56*def- quit (Quit: -)
10:28:52*def- joined #nim
10:31:58*def- quit (Client Quit)
10:32:25*def- joined #nim
10:37:19*def- quit (Quit: -)
10:39:02*def- joined #nim
11:12:13*def- quit (Quit: -)
11:12:55*def- joined #nim
12:01:05*def- quit (Quit: -)
12:03:00*def- joined #nim
12:03:01*PMunch joined #nim
12:03:15*coldfeet joined #nim
12:05:34FromDiscord<mvictor97> 18+ Teen Girls and onlyfans leaks for free :peach: :underage: https://discord.gg/nsfwxxx @everyone
12:23:46*beholders_eye quit (Read error: Connection reset by peer)
12:27:04*coldfeet quit (Remote host closed the connection)
12:29:37*beholders_eye joined #nim
12:31:40*def- quit (Quit: -)
12:31:56*def- joined #nim
12:33:12FromDiscord<nocturn9x> Any clue as to why calling `joinThread()` on a thread would cause random segfaults when I spawn a new thread with the same variable?
12:33:25FromDiscord<nocturn9x> Which is of course reinitialized with a `new Thread[...]`
12:35:12*def- quit (Client Quit)
12:35:24*def- joined #nim
12:37:04FromDiscord<nocturn9x> ah, I figured it out, I had to `GcRef` the search manager
12:37:13FromDiscord<nocturn9x> I assume because its ownership had been moved to the other thread
12:37:15FromDiscord<nocturn9x> weird
12:41:41FromDiscord<thesherwood> Is there any way to loop over 2 iterators at once?
12:48:05*cnx quit (Ping timeout: 256 seconds)
12:54:56FromDiscord<Phil> In reply to @thesherwood "Is there any way": In functional programming what you're looking for is typically called the "zip" method.↵So searching for that delivers the solution: https://linuxconfig.org/how-to-set-kernel-boot-parameters-on-linux ↵😉
12:55:46FromDiscord<Phil> Note that this is going to create an entirely new sequence before whatever iteration you want to do, so it's not really all that performant
12:56:04FromDiscord<Phil> If you want to do something time critical, you'll want to write the loops explicitly or use the zero-functional lib
12:58:05FromDiscord<nnsee> In reply to @isofruit "In functional programming what": that... probably isn't the link you wanted to post
12:58:17FromDiscord<Phil> Oh ffs
12:58:24FromDiscord<Phil> Sometimes copy paste on linux is so finnicky
12:58:41FromDiscord<Phil> https://nim-lang.org/docs/sequtils.html#zip%2C%2C ↵@thesherwood there you go
12:58:49FromDiscord<Phil> The stuff I wrote above still applies
13:00:57FromDiscord<thesherwood> Yeah, I saw the `zip` func, but I want to avoid reifying into sequences. I'll take a look at zero-functional.
13:02:07*cnx joined #nim
13:07:13*PMunch quit (Ping timeout: 256 seconds)
13:08:57NimEventerNew thread by moigagoo: Anonymous chat service, powered by Nim, see https://forum.nim-lang.org/t/11532
13:31:08NimEventerNew thread by DMisener: How do I emulate ruby's super() for a subclass object's constructor., see https://forum.nim-lang.org/t/11533
13:34:09*def- quit (Quit: -)
13:34:48*def- joined #nim
13:51:52FromDiscord<xtrayambak> Any idea why casting a non-GC'd type to a pointer fails? I'm probably doing something dumb here :P
13:57:51FromDiscord<griffith1deadly> In reply to @xtrayambak "Any idea why casting": show ur code
13:58:39Amun-Rayou can't cast anything to anything
13:58:47FromDiscord<xtrayambak> sent a code paste, see https://play.nim-lang.org/#pasty=SDcGgUIhGaZB
13:58:49FromDiscord<xtrayambak> In reply to @Amun-Ra "you can't cast anything": ah
13:59:11FromDiscord<xtrayambak> I just want to keep a pointer that can be casted into any type
13:59:24FromDiscord<griffith1deadly> sent a code paste, see https://play.nim-lang.org/#pasty=rBvlecMQMORL
14:00:08FromDiscord<xtrayambak> won't that return a `ptr typedesc[T]`?
14:00:27FromDiscord<griffith1deadly> `cast` that to pointer
14:00:35Amun-Rathis is a very ugly and dangerous code
14:01:08FromDiscord<xtrayambak> In reply to @Amun-Ra "this is a very": I'm trying to create a garbage collector
14:01:12FromDiscord<xtrayambak> that's why it looks obnoxious
14:01:31FromDiscord<xtrayambak> In reply to @griffith1deadly "`cast` that to pointer": ah alright
14:01:33FromDiscord<xtrayambak> thanks
14:01:42FromDiscord<griffith1deadly> :nim1:
14:02:02Amun-Raxtrayambak: you have to keep tracking of all the data you keep pointers to
14:02:56FromDiscord<xtrayambak> In reply to @Amun-Ra "<@498088092406644736>: you have to": I am
14:03:19FromDiscord<xtrayambak> I'm splitting up all the cells (container types for atoms/dynamic values) into generational "arenas"
14:03:40FromDiscord<xtrayambak> the older generations aren't sweeped as frequently as the newest and new ones
14:03:51FromDiscord<xtrayambak> I'm just learning how to make a GC off of how V8 does it
14:16:15*def- quit (Quit: -)
14:27:55*PMunch joined #nim
14:41:15FromDiscord<dissolved.girl> Last time I looked at it, the V8 GC seemed really complex. Generational multi-tier GC with support for parallelization that employs different strategies depending on the collectable object's age, etc
14:41:43FromDiscord<dissolved.girl> But I don't really know anything about GC, so I guess anything even slightly complex would look impressive to me 😅
14:44:05FromDiscord<nervecenter> I'm always impressed by how RC 1) just works, 2) can be statically inlined at compile time, 3) doesn't actually hit too hard on the performance front these days. KISS in practice.
14:49:01FromDiscord<nervecenter> Then again if you're never making explicit `ref`s on the heap then who cares? I love that Nim prefers stack-controlled lifetimes by default.
14:49:24FromDiscord<nervecenter> (Yes I know `string` and `seq` are technically allocated on the heap.)
14:55:13*def- joined #nim
15:01:42*PMunch quit (Ping timeout: 252 seconds)
15:06:32*ntat_ joined #nim
15:06:49*ntat quit (Ping timeout: 268 seconds)
15:15:01*PMunch joined #nim
15:20:06*disso-peach joined #nim
15:53:00FromDiscord<nocturn9x> quick question about threads
15:53:05FromDiscord<nocturn9x> if I send a `ref` to another thread
15:53:15FromDiscord<nocturn9x> is it reasonable to expect that the ref is the same
15:53:23FromDiscord<nocturn9x> or does it get copied
15:53:37FromDiscord<nocturn9x> using atomic ARC
15:57:43FromDiscord<nocturn9x> _nevermind_
16:01:20*PMunch quit (Quit: Leaving)
16:02:25FromDiscord<Phil> In reply to @nocturn9x "or does it get": Pretty sure refs get copied, as in you now have multiple refs to the same value
16:02:41FromDiscord<nocturn9x> No yeah I was not updating a field in my ref object
16:02:44FromDiscord<nocturn9x> then wondering why it was zero
16:02:44FromDiscord<Phil> You can use =move / sink to try and reduce that, but that requires additional code
16:02:46FromDiscord<nocturn9x> silly me
16:12:30*def- quit (Quit: -)
16:13:03*def- joined #nim
16:48:49*gst joined #nim
17:20:31*beholders_eye quit (Ping timeout: 260 seconds)
17:30:07*disso-peach quit (Quit: Leaving)
17:31:11FromDiscord<Phil> Conceptually, combining observables is an absolute nightmare
17:34:13FromDiscord<Phil> Like, you can have a cold and a hot observable.↵Simple things like "If a cold/hot observable completes, then its children also complete" no longer hold up, because maybe the child is a combined with another observable which is very much still active. So now when you complete you somehow need to be able to check "Are all other observables that are related to this child observable of mine also completed so that the child can complete?"
17:36:31FromDiscord<nnsee> what are hot and cold observables
17:38:07FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=NAUfeIZsdQKd
17:38:21FromDiscord<Phil> It is an observable that immediately emits its values when you subscribe
17:39:37FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=qMOBPmgGEAza
17:39:54FromDiscord<Phil> (edit) "https://play.nim-lang.org/#pasty=ghzGkUnEflJq" => "https://play.nim-lang.org/#pasty=IbvMideUiJDl"
17:40:35FromDiscord<Phil> now a cold observable is essentially already complete. It will not receive new values, it is done
17:41:06FromDiscord<Phil> A hot observable like the subject is only complete once you actually shut it down (by calling `subject.complete()`), because you can always emit a new value into it otherwise
17:42:35FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=CrHjYYvxaBZP
17:42:48FromDiscord<odexine> cold vs hot is not about whether it completes immediately or not
17:42:57FromDiscord<odexine> its more of whether the data is generated from within the observable or not
17:43:22FromDiscord<odexine> at least thats the definition i know. it prolly is a "depends on who you ask" kinda thing
17:43:40FromDiscord<Phil> In reply to @odexine "cold vs hot is": I feel like that is inferrable that a cold observable is immediately complete. Being complete means no new values can enter the stream - that is the case for cold observables
17:43:46FromDiscord<odexine> no
17:44:05FromDiscord<Phil> Example please because then this needs adjustment in the model the lib is built upon
17:44:11FromDiscord<odexine> cold observables can send data "not immediately"
17:44:18FromDiscord<odexine> as long as its within the observable itself
17:44:39FromDiscord<odexine> given js and its global evloop, you can do a settimeout and dispatch another value from within such
17:44:45FromDiscord<Phil> Correct, but that still means the observable itself is complete. There can be no additional events emitted other than what is defined in the observable
17:44:50FromDiscord<odexine> that would still count as cold
17:44:57FromDiscord<Phil> Sure you can push stuff with timeouts into the future
17:45:00FromDiscord<odexine> In reply to @isofruit "Correct, but that still": if that is the definition, then we agree
17:45:02FromDiscord<Phil> But there's still no new events coming
17:45:15FromDiscord<odexine> its just a matter of wording in that sense
17:45:32FromDiscord<Phil> I'll look up again if observables complete or only observers
17:45:34FromDiscord<odexine> "within the observable itself" and "no new events coming" are the same in this case
17:45:42FromDiscord<odexine> observables complete
17:46:30FromDiscord<odexine> well
17:46:36FromDiscord<odexine> its a bit convoluted now i guess
17:46:37FromDiscord<Phil> Assuming that the same observable can't complete over and over again (because mentally that makes no sense to me atm) I can only assume that a cold observable is complete by definition.
17:46:43FromDiscord<odexine> observers have a next/complete/error
17:46:58FromDiscord<odexine> whether you define that as to mean that observables can complete or not is a matter of wording
17:47:29FromDiscord<odexine> a cold observable can decide not to complete (aka run observer.complete)
17:48:20FromDiscord<Phil> In reply to @odexine "observers have a next/complete/error": I'm aware of that one, I swear I saw observers in rxjs also carrying around a completion boolean somewhere
17:48:33FromDiscord<odexine> a cold observable is only defined to be that the events emitted are defined in such observable's subscribe proc i believe
17:51:09FromDiscord<Phil> From everything I've read the expected behavior should be that a finite, cold observable is basically complete and is expected to call complete on any of its subscribers after the last value was emitted
17:51:47FromDiscord<odexine> expected but not required
17:52:32FromDiscord<Phil> Man, I feel like I either need some workable kind of interface type-stuff or generic methods
17:52:52FromDiscord<odexine> observables can be infinite (~~welcome to FP, things can be infinite here~~)
17:52:53FromDiscord<Phil> The approach of using an observable base-type and inheriting off of that is really hitting limits
17:53:06FromDiscord<Phil> In reply to @odexine "observables can be infinite": I mean, sure, that's observables based on intervals
17:53:13FromDiscord<Phil> Ah, wait, those still count as cold observables
17:53:14FromDiscord<Phil> Ugh
17:53:21FromDiscord<odexine> :baqua:
17:53:27FromDiscord<odexine> have fun
17:53:59FromDiscord<Phil> I'm not and about to drop the project again because certain things just appear fundamentally impossible if you have neither flexible types like JS nor generic methods like java
17:54:19FromDiscord<odexine> do you need it to be oop
17:54:39FromDiscord<odexine> ive heard of FRP but ive been intimidated by the intersection of functional and reactive
17:55:00FromDiscord<odexine> nim doesnt have megastrong support of functional either (typeclass in particular)
17:55:05FromDiscord<Phil> Fundamentally what I need is interfaces.↵I need to be able to define an interface and have various types have their own specific implementation
17:55:13FromDiscord<odexine> In reply to @odexine "nim doesnt have megastrong": though that isnt a requirement, i'm just used to it
17:55:38FromDiscord<Phil> Like, I want subscribe on subjects to work one way and subscribe on cold observables another
17:56:54FromDiscord<Phil> Currently I have an ugly mangled subscribe proc that can deal with both subjects and observables and deals with the various aspects of behavior they want by being able check fields that both must have if they meet the requirements for said behavior.↵↵Like a "initialValuesHandler"-closure that you need to have if you want to emit certain values immediately upon subscribe.↵Subjects don't have one, observables do.
17:57:22FromDiscord<Phil> But that approach is rather hacky and very quickly hits bugs for obvious reasons - because I can't properly anticipate all combinations of behavior I need for correct behavior in that subscribe proc
17:59:30FromDiscord<Phil> I honestly don't have a concept on how to define these things without going down an OOP route.↵You want to interact with these types in a lot of similar ways - but they should behave different in subtle ways.↵A subject should be subscribeable, so should an observable, but then both have slightly different behaviors they should display
17:59:50FromDiscord<Phil> The only other route I can think of is go full "custom-OOP", meaning subjects now get a field that holds a "subscribe"-closure etc.
18:00:16FromDiscord<odexine> i thought that was the way you were doing already
18:00:38FromDiscord<Phil> Not fully, I'm currently on a very mangled intermedium approach to share the code that looked so very dang similar
18:00:52FromDiscord<Phil> Which is currently eating my ass alive
18:01:13FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=SNGHLiLIQHZY
18:01:31FromDiscord<Phil> Which is just... ripe to throw bugs your way - which it does
18:12:08FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=kQSqWgSvVtpe
18:12:28FromDiscord<Phil> Likely with some closure pragmas attached, not sure yet
18:13:05FromDiscord<Phil> Storing closures in objects very much feels like poor man's OOP
18:14:47FromDiscord<odexine> why the complete/d fields?
18:15:13FromDiscord<odexine> In reply to @isofruit "Storing closures in objects": iirc its whats done in many impls actually
18:15:28FromDiscord<Phil> completed is needed to know if you actually add an observer to your observers or not
18:15:40FromDiscord<Phil> Because if you are already completed, then there's no point to adding an observer to your observers
18:15:50FromDiscord<Phil> Like subscribing to a completed subject should be a no-op
18:17:21FromDiscord<odexine> iirc the expected behaviour when subbing to a completed ob'le is that ob'er.complete() is immediately called
18:17:51FromDiscord<Phil> But that would make no sense for cold observables, no?
18:17:53FromDiscord<odexine> so i think technically only completed: bool is needed
18:18:18FromDiscord<odexine> In reply to @isofruit "But that would make": sure, neither field make sense for colds
18:18:27FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=EvWnFcAeysHh
18:18:27FromDiscord<odexine> only un/subscribe would matter in such case
18:18:48FromDiscord<polylokh_39446> (edit) "https://play.nim-lang.org/#pasty=sEzfqOwtOzTS" => "https://play.nim-lang.org/#pasty=GXYJfVpfDpxC"
18:20:02FromDiscord<polylokh_39446> `a != b` is also true in that test
18:20:05FromDiscord<Phil> In reply to @polylokh_39446 "I have a github": assuming nimble can even deal with 4 number semver like this, maybe it was cached locally.↵I am fairly familiar with the behavior that nimble tends to stick with the version it installed for you unless e.g. your .nimble file explicitly requests another version
18:20:33FromDiscord<Phil> nimble install <name> will try to stick with what you have for a time instead of downloading the latest
18:20:35FromDiscord<odexine> four number versions are not semver compat iirc?
18:21:14FromDiscord<odexine> not sure why it doesnt work when the functionality is there otherwise tho
18:21:14FromDiscord<Phil> I have honestly no clue. Software packages on e.g. arch also use a custom versioning that is kinda semver but have -X at the end with X I assume the "version" of the way it was packaged
18:21:37FromDiscord<odexine> it is the version of the pkgbuild pretty much
18:21:59FromDiscord<polylokh_39446> I don't think I blew away the cache while testing. I was doing 'nimble remove'/'nimble install', and testing with a script that used the module without its own nimble file.
18:22:25FromDiscord<Phil> The "cache" in this case is very likely the package.json file nimble downloaded
18:22:35FromDiscord<Phil> Which is somewhere in the nimble directory
18:23:30FromDiscord<polylokh_39446> I guess ~/.nimble/nimbledata2.json might've done it. Maybe it's just the timing that made it look like 4.6.1 fixed it
18:23:31FromDiscord<Phil> might be nimbledata2.json, might be one of the 2 packages.json files
18:23:53FromDiscord<Phil> Generally deleting those should prompt nimble to try a redownload
18:24:08FromDiscord<Phil> though keep a backup in case it doesn't
18:24:26FromDiscord<polylokh_39446> aye, thanks.
18:26:06FromDiscord<Phil> Ah, `nimble refresh` is for that purpose apparently
18:26:08FromDiscord<Phil> @polylokh_39446
18:26:22FromDiscord<Phil> https://nim-lang.github.io/nimble/use-packages.html#nimble-refresh
18:29:22FromDiscord<Phil> Okay, narimiran did a pretty banger job here.↵Splitting nimble commands into "This is how you use packages, this is how you publish packages" splits the commands rather nicely
18:30:52FromDiscord<Phil> In reply to @odexine "iirc its whats done": Btw. this is oddly reassuring to here.↵So basically imperative reverts to storing closures in object-fields when they need sort-of-OOP ?
18:31:05FromDiscord<Phil> (edit) "In reply to @odexine "iirc its whats done": Btw. this is oddly reassuring to here.↵So basically imperative reverts to storing closures in object-fields ... when" added "as a general pattern"
18:31:29FromDiscord<Phil> (edit) "here.↵So" => "hear.↵So"
18:31:33FromDiscord<odexine> i dont truly know btw, its just what i remember seeing
18:31:54FromDiscord<odexine> lots of discussion about how to optimise out closures in the rx space
18:32:10FromDiscord<odexine> "its all closures?" "always was" kinda shit
18:32:28FromDiscord<Phil> "It's closures all the way down baby!"
18:34:02FromDiscord<Phil> I think one of the benefits of this project is it really is teaching me a propper understanding of closures and their usecases
18:34:13FromDiscord<Phil> I never thought that deeply about them (or used them that consciously for that matter)
18:34:23FromDiscord<odexine> hey youre one step closer to FP land
18:34:36FromDiscord<odexine> if OOP is "its all objects" then FP is "its all functions"
18:34:42FromDiscord<Phil> What I don't get though is why I can't capture a `var int`
18:34:49FromDiscord<odexine> because its a var
18:34:54FromDiscord<Phil> I do not follow
18:35:04FromDiscord<Phil> That's the point, it's state I want to mutate, it allows mutating, what's forbidden?
18:36:01FromDiscord<odexine> it can die with repercussions, for nonvar you can just copy the data into the hidden env no problem, for var basically you can dangling pointer it
18:36:47FromDiscord<Phil> But way too often I want to share the state between inside the closure and outside... so basicall it wants me to use ref-variables?
18:36:50FromDiscord<odexine> sent a code paste, see https://play.nim-lang.org/#pasty=PYEkbahvgtIX
18:36:52FromDiscord<odexine> pretty much
18:37:47FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=xUzwhRqImDlT
18:38:06FromDiscord<odexine> pretty much
18:38:10FromDiscord<Phil> Is there some way I don't have to do the song an dance of `new(T)` to then do an assignment?
18:38:54FromDiscord<odexine> for primitives? i dont think so
18:39:12FromDiscord<Phil> Boooooo doing that is annoying every time I have to do it
18:39:15FromDiscord<odexine> for defined objects? `(ref YourObject)(fields: values)`
18:43:13FromDiscord<odexine> sent a code paste, see https://play.nim-lang.org/#pasty=ERuTxdPzYOdL
18:43:28FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=cBzwLbgQjRCk
18:44:20FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=nAbgjRYNKVoY
18:44:23FromDiscord<odexine> sent a code paste, see https://play.nim-lang.org/#pasty=nCSbFRvhSDyo
18:45:04FromDiscord<Phil> What should I be seeing?
18:45:19FromDiscord<odexine> x is dead once you exit a
18:45:33FromDiscord<Phil> sent a long message, see https://pasty.ee/nbyDALVODoBC
18:45:55FromDiscord<odexine> In reply to @isofruit "Unrelated sidenote, this post": cool
18:46:01FromDiscord<odexine> didnt think too much about it in that way
18:46:06FromDiscord<Phil> In reply to @odexine "x is dead once": I'd honestly assume nim just treats x as a ref under the hood and keeps it as it is store in the closure until the closure falls out of scope
18:46:20FromDiscord<Phil> (edit) "store" => "stored"
18:46:28FromDiscord<odexine> In reply to @isofruit "I'd honestly assume nim": and become java?
18:46:47FromDiscord<odexine> youve basically said "i want everything to be refs"
18:47:01FromDiscord<Phil> Wasn't nim treating var's as refs?
18:47:06FromDiscord<Phil> when convenient
18:47:09FromDiscord<odexine> limited refs
18:47:23FromDiscord<odexine> which includes the limitation of "closures cannot capture them"
18:47:48FromDiscord<odexine> keeps it quick, since theyre not true refs, more akin to ptr
18:47:58FromDiscord<odexine> no gc involved in such case
19:07:48*modev joined #nim
19:08:11*modev quit (Client Quit)
19:08:46*nyeaa49284230101 quit (Quit: The Lounge - https://thelounge.chat)
19:34:40FromDiscord<Elegantbeef> Make a proc that is `new[T: not ref](t: sink T): ref T`↵(@Phil)
19:43:35*ntat_ quit (Quit: Leaving)
20:21:46*FromDiscord quit (Remote host closed the connection)
20:22:02*FromDiscord joined #nim
21:26:09*om3ga quit (Ping timeout: 252 seconds)
21:39:07*def- quit (Quit: -)
21:41:21*def- joined #nim