<< 18-05-2024 >>
00:02:31FromDiscord<sOkam! 🫐> kk ty
00:06:50*lucasta quit (Read error: Connection reset by peer)
00:07:05*lucasta joined #nim
00:09:47*beholders_eye quit (Ping timeout: 268 seconds)
00:25:50FromDiscord<Robyn [She/Her]> Quick question to the people here, I must enable views for types to be able to store `openArray`s of types, right? Would any modification to an object in the openArray also propagate elsewhere?
00:26:19FromDiscord<Elegantbeef> Yes
00:26:32FromDiscord<Elegantbeef> If you enable views you will have codegen issues
00:26:35FromDiscord<Elegantbeef> I garuentee it
00:26:45FromDiscord<Robyn [She/Her]> Ah
00:26:57FromDiscord<Robyn [She/Her]> So no highly optimised NBT parser 😔
00:27:18FromDiscord<Elegantbeef> I mean you can do `ptr UncheckedArray[T]` and get the exact same thing just with no safety
00:27:29FromDiscord<Robyn [She/Her]> Wanted to avoid allocations when possible
00:27:36FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "I mean you can": Type safety is important though :P
00:27:49FromDiscord<Elegantbeef> This isn't type safety
00:27:54FromDiscord<Elegantbeef> This is memory safety
00:28:06FromDiscord<Robyn [She/Her]> Ah
00:28:29FromDiscord<Robyn [She/Her]> ~~Type~~ memory safety is important though :P
00:29:06FromDiscord<polylokh_39446> yep, some of these are pretty bad: <https://github.com/nim-lang/Nim/issues?q=is%3Aissue+is%3Aopen+views+label%3A%22View+Types%22>
00:29:48FromDiscord<polylokh_39446> actually the specific one I was looking for was fixed recently, nice!
00:30:02FromDiscord<Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=ZOKskSbm
00:30:14FromDiscord<Robyn [She/Her]> In reply to @polylokh_39446 "yep, some of these": Oh well
00:30:24FromDiscord<Robyn [She/Her]> (edit) "https://play.nim-lang.org/#pasty=yRhWvMzd" => "https://play.nim-lang.org/#pasty=flvyfcBn"
00:30:26FromDiscord<Elegantbeef> where would you even put an `openArray[T]` here?
00:30:32FromDiscord<polylokh_39446> <https://github.com/nim-lang/Nim/issues/15778> is the one
00:30:54FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "where would you even": `cmpdVal: openArray[NbtNode[T]]`
00:31:10FromDiscord<Robyn [She/Her]> I forgot a snippet of code before
00:31:24FromDiscord<Elegantbeef> So use `ref seq[T]`?
00:32:05FromDiscord<Robyn [She/Her]> How would I use that when getting a slice of `NbtNode`s?
00:32:20FromDiscord<Elegantbeef> You'd have a lifetime issue regardless if the node outlives the `openArray`
00:33:15FromDiscord<Elegantbeef> `values: Slice[int]`
00:34:16FromDiscord<Robyn [She/Her]> Hm, thanks Beef! Gonna look into this tomorrow or whenever I finish my college assignments
00:34:24FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "You'd have a lifetime": Yeah that makes sense
00:35:53FromDiscord<Elegantbeef> If you really wanted to prevent allocations you'd use a fixed array of indicies and have the user pass in a `var openArray[Node[T]]`
00:39:33FromDiscord<Elegantbeef> Now you write a `proc yourName(state: NbState[T]) = ...`
00:39:33FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=ywhcYGeD
00:40:00FromDiscord<polylokh_39446> avoiding copies might also not be that much of a win. It's something I found myself easily focusing too much on, as some kind of cognitive infection from exposure to Rust. But copies can be very fast and if you do a bunch of work with the outcome of copying you might have better data locality than if you carefully worked through pointers.
00:42:02FromDiscord<Elegantbeef> Copying a seq is less than ideal, but yea don't let the perfect be the enemy of good enough
00:42:21FromDiscord<polylokh_39446> although a parser? That's the same thing that led me into Nim's bugs with viewtypes.
00:43:31FromDiscord<Elegantbeef> I just go for data oriented design and scream about reasoning
00:43:36FromDiscord<polylokh_39446> >tag based binary format designed to carry large amounts of binary data with smaller amounts of additional data.↵↵what I went with after giving up on viewtypes, was just copying everything, but something that might've worked is using an ad-hoc slice type and ensuring the lifetimes myself, like with mslice ...
00:44:31FromDiscord<polylokh_39446> <https://github.com/c-blake/cligen/blob/master/cligen/mslice.nim#L29>
00:48:17FromDiscord<Elegantbeef> Yea that works it's just a pain
00:48:57FromDiscord<Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=tdtYMPfE
00:49:32FromDiscord<Elegantbeef> The state is just an array
00:49:38FromDiscord<Elegantbeef> Or a sequence
00:49:52FromDiscord<Elegantbeef> `IdSet` tells you which element in the array is active
00:50:01FromDiscord<Elegantbeef> Like I said it's a very data oriented design
00:50:43FromDiscord<Elegantbeef> Instead of using pointers you just store all the indexes each object depends upon
00:51:15FromDiscord<Elegantbeef> It also could be a `data: Slice[int]` if you only have contiguous slices
00:51:54FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "Instead of using pointers": Yeah that was what I thought my original concept was doing even if it'd use some modification aha
00:52:05FromDiscord<Elegantbeef> The benefit here is that the user allocates a collection and you never grow out of it, if you need more you raise an error about lacking space
00:52:36FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "`IdSet` tells you which": And that's relevant only during the construction process, I'd imagine?
00:53:05FromDiscord<Elegantbeef> Well no
00:53:13FromDiscord<Elegantbeef> If you remove indices and the like from the array you need taht
00:53:21FromDiscord<Elegantbeef> I do not know what your processing is like
00:53:37FromDiscord<Robyn [She/Her]> Fair enough
00:53:58FromDiscord<Robyn [She/Her]> I think I'm gonna have to process this after sleeping, but thanks for the help :)
01:39:16*krux02 quit (Remote host closed the connection)
01:48:27*lucasta quit (Quit: Leaving)
02:52:56*hexeme_ joined #nim
02:55:20*laintree joined #nim
03:00:47*lain quit (*.net *.split)
03:00:49*anddam quit (*.net *.split)
03:00:49*hexeme quit (*.net *.split)
03:13:41*SchweinDeBurg quit (Quit: WeeChat 4.3.0-dev)
03:16:25*SchweinDeBurg joined #nim
03:38:46*Onionhammer7 joined #nim
03:40:08*anddam joined #nim
03:40:09*dtomato quit (Read error: Connection reset by peer)
03:40:21*dtomato joined #nim
03:41:34*Goodbye_Vincent1 joined #nim
03:42:01*madprops_ joined #nim
03:44:30*Onionhammer quit (Read error: Connection reset by peer)
03:44:30*Onionhammer7 is now known as Onionhammer
03:46:05*noeontheend_ joined #nim
03:46:08*LyndsySimon_ joined #nim
03:46:14*dv^_^1 joined #nim
03:46:40*oprypin_ joined #nim
03:46:43*ursa-major_ joined #nim
03:46:59*johuck_ joined #nim
03:49:45*oisota5 joined #nim
03:53:04*dv^_^ quit (*.net *.split)
03:53:04*jkl quit (*.net *.split)
03:53:05*casaca quit (*.net *.split)
03:53:05*gshumway_ quit (*.net *.split)
03:53:06*oisota quit (*.net *.split)
03:53:06*void09 quit (*.net *.split)
03:53:07*dv^_^1 is now known as dv^_^
03:53:07*oisota5 is now known as oisota
03:53:38*ursa-major quit (*.net *.split)
03:53:39*oprypin quit (*.net *.split)
03:53:39*Goodbye_Vincent quit (*.net *.split)
03:53:39*madprops quit (*.net *.split)
03:53:39*noeontheend quit (*.net *.split)
03:53:40*johuck quit (*.net *.split)
03:53:41*nils` quit (*.net *.split)
03:53:42*Ekho quit (*.net *.split)
03:53:42*bcksl quit (*.net *.split)
03:53:43*LyndsySimon quit (*.net *.split)
03:53:45*noeontheend_ is now known as noeontheend
03:53:45*LyndsySimon_ is now known as LyndsySimon
03:53:45*Goodbye_Vincent1 is now known as Goodbye_Vincent
03:53:47*johuck_ is now known as johuck
03:53:48*ursa-major_ is now known as ursa-major
03:53:55*madprops_ is now known as madprops
03:53:56*madprops quit (Changing host)
03:53:56*madprops joined #nim
03:56:01*jkl joined #nim
03:56:01*casaca joined #nim
03:56:01*gshumway_ joined #nim
03:56:01*void09 joined #nim
04:01:29*nils` joined #nim
04:02:11*bcksl joined #nim
04:03:23*Ekho joined #nim
04:08:04*jkl quit (Max SendQ exceeded)
04:08:04*gshumway_ quit (Max SendQ exceeded)
04:09:07*jkl joined #nim
04:10:15*gshumway joined #nim
04:26:40*dio quit (Read error: Connection reset by peer)
06:32:52*laintree is now known as lain
07:32:19*ntat joined #nim
07:59:59*coldfeet joined #nim
08:14:32*def- quit (Quit: -)
08:15:52*def- joined #nim
08:50:49*gst joined #nim
08:55:23NimEventerNew thread by drkameleon: Super-weird error with builds on latest Windows runner (Github), see https://forum.nim-lang.org/t/11612
09:01:25FromDiscord<Phil> Wait a minute, the entire "convert proc call to object that can be sent over channel" thing is already solved by std/tasks? Slick!
10:59:47*krux02 joined #nim
11:18:08*def- quit (Quit: -)
11:19:27*def- joined #nim
11:28:57*def- quit (Quit: -)
11:46:33*def- joined #nim
12:12:31*xet7 quit (Ping timeout: 268 seconds)
12:24:09*xet7 joined #nim
12:47:22*beholders_eye joined #nim
12:49:58*xet7 quit (Remote host closed the connection)
13:49:10FromDiscord<Phil> asan and valgrind making me remember again why I absolutely wouldn't want dealing with multithreading on my worst enemy
13:49:26FromDiscord<Phil> (edit) "want" => "wish" | "on" => "for"
14:16:12*def- quit (Quit: -)
14:17:19*def- joined #nim
14:19:38*termer_ joined #nim
14:22:49*termer quit (Ping timeout: 256 seconds)
14:27:47*xet7 joined #nim
14:52:24FromDiscord<Phil> Ey, I hate those stacktraces so damn much.↵They were pointing me over and over and over again at a `createThread` call that was spawning a thread with a while-loop in it, when the actual god damn problem was that the `=destroy` hook of `task` wasn't being called properly with tryRecv
14:52:50FromDiscord<Phil> This was worse than no info, this was actively misleading
14:53:15FromDiscord<Phil> Not sure if that's just a general asan/tsan issue or if that's being made more complicated due to the added abstraction layer of nim
14:53:47FromDiscord<Phil> (edit) "Ey, I hate those stacktraces so damn much.↵They were pointing me over and over and over again at a `createThread` call that was spawning a thread with a while-loop in it, when the actual god damn problem was that the `=destroy` hook of `task` wasn't being called properly with tryRecv ... " added "when cleaning up remaining tasks before shutting down the main-thread"
15:37:57*def- quit (Quit: -)
15:38:39*def- joined #nim
15:59:44*def- quit (Quit: -)
16:00:15*def- joined #nim
16:03:17*def- quit (Client Quit)
16:05:01*def- joined #nim
16:33:56*xet7 quit (Quit: Leaving)
17:05:23*beholders_eye quit (Ping timeout: 264 seconds)
17:32:49*disso-peach joined #nim
17:41:56*beholders_eye joined #nim
17:43:23*disso-peach quit (Quit: Leaving)
17:55:30FromDiscord<Phil> I kinda want something along the lines of "Try to shut down this other thread. If it hasn't shut down after n seconds, kill it"
17:56:03FromDiscord<Phil> Ideally without having to use sleep as that'd mean that the user always has to wait n seconds instead of just moving on as soon as possible
17:57:00FromDiscord<odexine> what's this supposed to remediate?
17:57:08FromDiscord<odexine> i mean the kill a thread after a delay
17:57:43FromDiscord<Phil> Essentially when somebody wants to shut down the program but they forgot to shut-down a thread server then that thread server will hang the shutdown of the entire application.
17:58:18FromDiscord<Phil> Though I guess I could fix that by offering some kind of global shut-down mechanism for all threadservers at once
17:58:45FromDiscord<Phil> Ah, no, can't do that, I'd need to know the threadservers available so I can wake them up first so they can escape their while-loop
18:00:08FromDiscord<Phil> ... which I can do, I can just record which threadServers are being put into the threadpool in a seq and iterate over that with a global shutdownproc
18:02:23*beholders_eye quit (Ping timeout: 264 seconds)
18:38:03*coldfeet quit (Remote host closed the connection)
18:49:12FromDiscord<albassort> can i assign a range to an enum
18:49:25FromDiscord<albassort> sent a code paste, see https://play.nim-lang.org/#pasty=rpQzdHxz
18:49:31FromDiscord<odexine> i dont think so no
18:49:57FromDiscord<albassort> thats stupid because i can do it in reverse
18:50:14FromDiscord<odexine> ?
18:50:24FromDiscord<albassort> sent a code paste, see https://play.nim-lang.org/#pasty=CUrLnjZA
18:50:30FromDiscord<albassort> (edit) "https://play.nim-lang.org/#pasty=stovQbYB" => "https://play.nim-lang.org/#pasty=XOZtwCRH"
18:50:40FromDiscord<albassort> (edit) "https://play.nim-lang.org/#pasty=deoavaWp" => "https://play.nim-lang.org/#pasty=vHbXMhLc"
18:51:38FromDiscord<albassort> eh actually
18:51:45FromDiscord<albassort> that makes sense because how word ord() work
18:51:46FromDiscord<odexine> what
18:51:54FromDiscord<albassort> would return either a range or a number
18:54:46*def- quit (Quit: -)
18:55:14*def- joined #nim
18:58:09*def- quit (Client Quit)
19:00:24*def- joined #nim
19:03:47*def- quit (Client Quit)
19:04:29*def- joined #nim
19:25:27FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=AilWHgFd
19:26:07FromDiscord<sOkam! 🫐> I even went as far as redefining `items` for `HashSet[Path]` in that file and it still crashes
19:26:16FromDiscord<michaelb.eth> `import std/sets` ?
19:26:36FromDiscord<sOkam! 🫐> In reply to @michaelb.eth "`import std/sets` ?": I literally redefined the iterator because its already imported
19:26:36FromDiscord<michaelb.eth> ah, nvm, I see it's the Path thing
19:26:56FromDiscord<sOkam! 🫐> its not, if I redefine the iterator it still crashes
19:27:54FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=iGfLRRlN
19:29:08FromDiscord<michaelb.eth> what if in the return type you have `string` instead of `Path` and yield `$A[id]`
19:30:22FromDiscord<michaelb.eth> alternatively, what if in your module you implement `iterator items[distinct T](a: set[distinct T]): distinct T` ?
19:31:03FromDiscord<michaelb.eth> sorry, I mean `HashSet[distinct T]`
19:33:06FromDiscord<sOkam! 🫐> the error is somewhere else entirely, it has nothing to do with the iterators
19:33:29FromDiscord<sOkam! 🫐> its something inside, that crashes as if it was that iterator, but really isnt
19:33:46FromDiscord<sOkam! 🫐> templates being templates 😦
19:37:03*ntat quit (Quit: Leaving)
19:42:54FromDiscord<sOkam! 🫐> how do you access `HashSet[N]` without the `[]` proc? is there a way?
19:43:11FromDiscord<sOkam! 🫐> I'm trying to reimplement `[]` but don't know how to get the value at a specific id
19:45:32FromDiscord<Zoom> Have just rewritten dumb and convoluted logic of parsing a combo of cli arguments into a nice and tidy variant object. Each occasion you can lean into the type system is so satisfying!
19:50:36FromDiscord<Zoom> Speaking of Paths, current normalization routine in the stdlib ignores the case of the Windows drive. It prevents path comparison as strings. I could make a fix. Varriount (Clay Sweetser) / @varriount pinging as I saw you reviewing some code going to pathnorm.
19:53:27FromDiscord<m4ul3r> sent a code paste, see https://play.nim-lang.org/#pasty=gBvMufgq
19:54:39FromDiscord<m4ul3r> nvm i can do `sect[0][0]; sect[0][1]`
19:55:34FromDiscord<albassort> i feel like i ask this over and over and over again
19:55:48FromDiscord<albassort> but how can i convert an integer into chars with padd
19:56:05FromDiscord<albassort> so an int16(80) gets converted to 2 characters one of which ix 0x0
19:57:30FromDiscord<Robyn [She/Her]> In reply to @m4ul3r "I'm trying to write": You can also use types in macro parameters btw
19:57:56FromDiscord<m4ul3r> yeah, i'm going to be passing in different objects into it
19:58:59FromDiscord<Robyn [She/Her]> A concept could also work perhaps? But yeah it's your choice, I'm just suggesting type safety
19:59:12FromDiscord<albassort> In reply to @albassort "so an int16(80) gets": found the solution in some old code
19:59:26FromDiscord<Robyn [She/Her]> In reply to @albassort "but how can i": I don't get it?
19:59:51FromDiscord<albassort> sent a long message, see https://pasty.ee/byUhReNA
20:00:07FromDiscord<albassort> (edit) "long message," => "code paste," | "https://pasty.ee/mKvxDoJb" => "https://play.nim-lang.org/#pasty=uEuhGRwd"
20:25:39*def- quit (Quit: -)
20:30:41FromDiscord<demotomohiro> sent a code paste, see https://play.nim-lang.org/#pasty=NrnAnXeH
20:36:46FromDiscord<Elegantbeef> Can also just do `[uint8(a and 0xff), unit8(a shr 8 and 0xff)]` 😄
20:40:07*beholders_eye joined #nim
20:45:36*def- joined #nim
20:52:01FromDiscord<m4ul3r> sent a code paste, see https://play.nim-lang.org/#pasty=rYSUgpIj
20:52:32FromDiscord<m4ul3r> (edit) "https://play.nim-lang.org/#pasty=DkqwJDXn" => "https://play.nim-lang.org/#pasty=WOvthenk"
20:54:12FromDiscord<Elegantbeef> That code works just fine
20:55:38FromDiscord<m4ul3r> I guess my issue might be coming from importing the object types from another file
20:56:05FromDiscord<Elegantbeef> No your issue is that you have a generic field most likely
20:57:01FromDiscord<m4ul3r> I'm not using any generics in the object
20:57:09FromDiscord<Elegantbeef> Are you sure?
20:57:12FromDiscord<Elegantbeef> What's the object definition?
20:59:59FromDiscord<m4ul3r> hmm, if i simplify it works - it must be the use of `type()` as a member of an object
21:00:25FromDiscord<Elegantbeef> Yes that's a generic
21:00:43FromDiscord<Elegantbeef> You cannot store a type in a runtime value
21:01:07FromDiscord<m4ul3r> I see, hmm - anyway around that?
21:01:17FromDiscord<Elegantbeef> Stop using a type field
21:03:28*def- quit (Quit: -)
21:04:16*def- joined #nim
21:05:40FromDiscord<Elegantbeef> If you explain what you're trying to do one might provide more details
21:05:55FromDiscord<m4ul3r> Have an object with function pointers
21:06:54FromDiscord<Elegantbeef> Ok so why do you need `type`?
21:08:09FromDiscord<m4ul3r> Just so i can call the functon like `o.doSomething(1,2)` and not have it take o as arg1
21:08:26FromDiscord<Elegantbeef> But it's a function pointer
21:11:46*def- quit (Quit: -)
21:34:55FromDiscord<Robyn [She/Her]> In reply to @m4ul3r "Just so i can": Do you mean an event system of some sorts?
21:35:42FromDiscord<Robyn [She/Her]> I have two different implementations of them
21:36:33FromDiscord<Robyn [She/Her]> Oof does remind me that I need to figure out a way to hook my event system up in a way that works with the JS backend
21:36:35FromDiscord<m4ul3r> no im doing something different
21:36:48FromDiscord<Robyn [She/Her]> In reply to @m4ul3r "no im doing something": What are you doing exactly? Would probably help
21:36:52FromDiscord<Phil> @michaelb.eth are you mayhaps aware of some kind of "Work through the async queue until it is empty" mechanism for chronos?↵I want to gracefully shut down a server and wrap up all the things it may have left over to do before I fully do so
21:36:56FromDiscord<m4ul3r> i got it figured out
21:37:06FromDiscord<Robyn [She/Her]> If you're doing dynamic dispatch, why not `method`s?
21:37:17FromDiscord<Robyn [She/Her]> In reply to @m4ul3r "i got it figured": Ah nice then
21:37:20FromDiscord<Phil> no generic methods
21:37:37FromDiscord<Phil> I use closures in object fields a ton as well for my reactive library
21:37:43FromDiscord<Phil> (edit) "reactive" => "reactivex implementation"
21:38:19FromDiscord<Phil> You also get to circumvent nim's type systems somewhat by just storing closures in objects instead of dealing with methods. As a mechanism they just work better
21:39:26FromDiscord<Robyn [She/Her]> In reply to @isofruit "no generic methods": I thought generic methods still worked?
21:39:36FromDiscord<Elegantbeef> They do but they warn you
21:39:43FromDiscord<Phil> In reply to @chronos.vitaqua "I thought generic methods": Sure if you like to build anything on deprecated code
21:39:45FromDiscord<Robyn [She/Her]> Meh, warnings are for cowards
21:39:46FromDiscord<Phil> I don't
21:39:54FromDiscord<michaelb.eth> In reply to @isofruit "<@383034029135364096> are you mayhaps": I don’t know offhand, there might be an internal proc for that, or you may need a counter on the main thread
21:39:55FromDiscord<Robyn [She/Her]> Why are they deprecated anyway
21:40:17FromDiscord<Robyn [She/Her]> Is it because iirc Araq wanted methods to work using a VTable instead or something?
21:40:20FromDiscord<Elegantbeef> Cause `method [T](obj: Bleh[T], meh: T)` can exist
21:40:48FromDiscord<Phil> In reply to @michaelb.eth "I don’t know offhand,": counter... for what?
21:41:14FromDiscord<michaelb.eth> number of outstanding tasks
21:41:34FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "Cause `method [T](obj: Bleh[T],": A method with no name?
21:41:46FromDiscord<Elegantbeef> No
21:41:54FromDiscord<Elegantbeef> A method that uses a generic parameter that is not the same across instances
21:41:58FromDiscord<Robyn [She/Her]> I don't get the issue then
21:42:04FromDiscord<michaelb.eth> though hmm i guess that won’t work, sorry, just thinking uncritically while waiting for a friend to arrive
21:42:18FromDiscord<Phil> In reply to @michaelb.eth "number of outstanding tasks": isn't it possible that outstanding tasks may spawn more outstanding tasks (I assume an await somewhere in a piece of code spawns a new task) ?↵So it's more like I need to while-loop over whatever counter
21:42:22FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "No": Still don't know why it's an issue
21:42:44FromDiscord<Robyn [She/Her]> Instances like, over shared lib boundaries?
21:42:59FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=fXVRmSXb
21:44:02*def- joined #nim
21:44:30FromDiscord<Robyn [She/Her]> Yep still clueless
21:44:56FromDiscord<Robyn [She/Her]> I don't use `method`s like, ever so that may be why I'm struggling a bit to see the issue
21:46:01*def- quit (Read error: Connection timed out)
21:46:02FromDiscord<Elegantbeef> I mean that's a shitty example
21:47:22FromDiscord<Elegantbeef> There's an example somewhere that I cannot recall where the generic method causes memory issues iirc
21:47:51FromDiscord<Elegantbeef> Regardless methods are lame 😄
21:49:19*def- joined #nim
21:53:45NimEventerNew thread by Isofruit: How to "drain" remaining work from Chronos Thread Dispatcher, see https://forum.nim-lang.org/t/11615
21:59:13FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "Regardless methods are lame": Fair enough lol
22:00:00Amun-RaI second that )
22:00:02Amun-Ra:>
22:32:36*def- quit (Quit: -)
22:33:24*def- joined #nim
22:39:41*def- quit (Quit: -)
23:06:55*lain quit (Ping timeout: 272 seconds)
23:07:38*lain joined #nim
23:09:21*SchweinDeBurg quit (Quit: WeeChat 4.3.0-dev)
23:15:02*SchweinDeBurg joined #nim
23:18:52FromDiscord<m4ul3r> With macros, would there be a way to list all of the members of the object, similar to repr?
23:19:06FromDiscord<m4ul3r> just members, not values
23:22:08*beholders_eye quit (Read error: Connection reset by peer)
23:26:01FromDiscord<Elegantbeef> Yes
23:26:06FromDiscord<Elegantbeef> You do not need macros though
23:26:12FromDiscord<Elegantbeef> the `fieldPairs` iterator exists
23:28:12*beholders_eye joined #nim
23:32:05FromDiscord<System64 ~ Flandre Scarlet> Are hashmaps and dictionnaries fast?
23:32:15FromDiscord<Elegantbeef> Relative to what?
23:32:57FromDiscord<System64 ~ Flandre Scarlet> an array or a seq
23:34:27FromDiscord<Elegantbeef> Well a `Table[int, T]` is slower than an `array[..., T]`
23:34:33FromDiscord<Elegantbeef> Hashing is slower than direct indexing
23:35:16FromDiscord<System64 ~ Flandre Scarlet> Like, much slower
23:35:18FromDiscord<System64 ~ Flandre Scarlet> ?
23:35:23FromDiscord<Elegantbeef> Yes
23:35:34FromDiscord<Elegantbeef> Sequences and arrays are contiguous data blocks
23:35:42FromDiscord<Elegantbeef> Tables require hashing and compairsons
23:36:52*gst quit (Ping timeout: 250 seconds)
23:36:53FromDiscord<m4ul3r> In reply to @Elegantbeef "the `fieldPairs` iterator exists": thanks you, can this be used in a macro?
23:36:55*def- joined #nim
23:37:15FromDiscord<Elegantbeef> No
23:37:18FromDiscord<Elegantbeef> Well yesn't
23:37:20FromDiscord<System64 ~ Flandre Scarlet> Oh alright
23:39:03FromDiscord<Elegantbeef> You can use `fieldPairs` on a instance you instantiate inside a macro, but you cannot use it on a NimNode you pass in
23:44:28FromDiscord<m4ul3r> That makes sense since the Nimnode will just have a bunch of dotExpr
23:44:43FromDiscord<Elegantbeef> What are you trying to do?
23:45:20*xet7 joined #nim
23:45:38FromDiscord<m4ul3r> Create an object of objects, some objects will be function pointers. I am hoping to write a macros that can iterate over an object that I know has function pointers and resolve them
23:45:52FromDiscord<Elegantbeef> "resolve them"?
23:46:02FromDiscord<Elegantbeef> I'd really suggest using closures to type erase like Phil suggested
23:49:27FromDiscord<m4ul3r> resolve them by getting where it's at in memory, I have it working for the core of what I wanted to do and was going to call the macro manually for each one, but was thinking if I could write a macro to wrap this macro it would be clever
23:49:56FromDiscord<Elegantbeef> Uh huh
23:51:06FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=cWgpUmBC
23:51:14FromDiscord<sOkam! 🫐> duplicate case label?? 🧩
23:51:38FromDiscord<Elegantbeef> What are your types?
23:51:48FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=CurMoCFG
23:52:15FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=TnDUbPxt
23:53:11FromDiscord<Elegantbeef> Line 120 is?
23:53:27FromDiscord<sOkam! 🫐> first one, the unix one
23:53:51FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=UMCNzuKe
23:54:22FromDiscord<sOkam! 🫐> if i add it back it works again 🧩
23:54:31FromDiscord<Elegantbeef> Do you do `of ext.obj` somewhere?
23:54:41FromDiscord<sOkam! 🫐> yeah
23:55:00FromDiscord<Elegantbeef> Well there you go
23:55:00FromDiscord<sOkam! 🫐> well, not ext.obj.. but rather `ext.unix.obj`
23:55:09FromDiscord<Elegantbeef> somewhere you have two `".o"`
23:55:29FromDiscord<sOkam! 🫐> and its failing there at the object declaration?
23:55:44FromDiscord<Elegantbeef> No
23:55:51FromDiscord<Elegantbeef> Constants are folded
23:55:59FromDiscord<Elegantbeef> So the error is at the fold source
23:56:03FromDiscord<Elegantbeef> Which is `".o"`
23:56:16FromDiscord<sOkam! 🫐> excuse my noobness, but what is folding?
23:56:38FromDiscord<Elegantbeef> Taking `ext.unix.obj` and turning it into \`".o"\~
23:56:48FromDiscord<Elegantbeef> `".o"`
23:56:53*def- quit (Quit: -)
23:56:55FromDiscord<Elegantbeef> Statically
23:57:09*def- joined #nim
23:57:58FromDiscord<Elegantbeef> Constants are annoying in that respect
23:59:04FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=HSeJFPiq
23:59:24FromDiscord<sOkam! 🫐> In reply to @Elegantbeef "Statically": ah i see. makes sense