<< 14-06-2024 >>
00:00:25FromDiscord<ElegantBeef> If only Nim had a spec, then you could just run against all the specs you cared about
00:00:40FromDiscord<sOkam! 🫐> would be great
00:01:08FromDiscord<sOkam! 🫐> hoping right into a different plane of existence where that is a thing. brb 🕰️
00:05:24FromDiscord<ElegantBeef> Well when you're done hoping may you might want to try hopping
00:06:10FromDiscord<sOkam! 🫐> too late for the p
00:17:26FromDiscord<sOkam! 🫐> the syntax rules for `do` are really annoying, btw. it really makes no sense to me
00:18:27FromDiscord<ElegantBeef> Which part?
00:22:26FromDiscord<sOkam! 🫐> nothing can start with `do` for example. thats the most unintuitive part
00:22:34FromDiscord<ElegantBeef> What
00:22:46FromDiscord<sOkam! 🫐> `do thing: asd` is an error
00:22:56FromDiscord<ElegantBeef> right cause `do` is a keyword
00:23:09FromDiscord<sOkam! 🫐> `thing do: asd` becomes a `thing( asd )`
00:23:37FromDiscord<ElegantBeef> It's a post operation to allow passing more arguments
00:23:46FromDiscord<sOkam! 🫐> In reply to @elegantbeef "right cause `do` is": well I was expecting that to generate a `nkDo`.. but it doesn't
00:24:13FromDiscord<ElegantBeef> Do is apart of the grammar so it has to be parsed in it's expected form
00:24:23FromDiscord<ElegantBeef> This means `bleh .... do: ...` or `bleh do -> (...): ....`
00:24:44FromDiscord<ElegantBeef> Whoops
00:24:49FromDiscord<ElegantBeef> `do (...) -> ...: ....`
00:25:41FromDiscord<sOkam! 🫐> also, isolated `...` operators break the syntax too, so no `proc thing( arg :T; ... ) :T` for me either 😔
00:26:16FromDiscord<ElegantBeef> Well operators operate on things
00:26:59FromDiscord<sOkam! 🫐> In reply to @elegantbeef "Do is apart of": yeah I'm just trying to find a way to spell `do while condition: body`, but the grammar is not bending
00:27:28FromDiscord<ElegantBeef> `doWhile bleh: ....`
00:27:30FromDiscord<sOkam! 🫐> having to do `doWhile condition: body` and redirect the `nkCommand` to a different part of the compiler
00:27:44FromDiscord<sOkam! 🫐> yeah but its hacky. i was hoping to use nkDo
00:29:46FromDiscord<ElegantBeef> while and do both have their own gramars
00:29:49FromDiscord<ElegantBeef> grammars
00:31:22FromDiscord<ElegantBeef> So much like one has to when writing macros you need to get as close as you can
00:31:40FromDiscord<sOkam! 🫐> yeah im noticing 😦
01:02:54FromDiscord<sOkam! 🫐> @ElegantBeef would it be a pipedream to hack the parser to add `# thing` comments, instead of ignoring them?↵also, same for blank lines 🤔↵is it an impossible, or really crazy, or actually doable?
01:03:25FromDiscord<sOkam! 🫐> (edit) "@ElegantBeef would it be a pipedream" => "sry, moved" | "hack the parser to add `# thing` comments, instead of ignoring them?↵also, same for blank lines 🤔↵is it an impossible, or really crazy, or actually doable?" => "#langdev"
01:57:06FromDiscord<sirolaf> sent a code paste, see https://play.nim-lang.org/#pasty=Kabaxnwf
01:57:53FromDiscord<sirolaf> Some part of the transformation ruins it
02:06:18FromDiscord<ElegantBeef> Yea removing the error and checking `--expandMacro:async` is really unclear with the copy is needed
02:10:11FromDiscord<sirolaf> sent a code paste, see https://play.nim-lang.org/#pasty=WAncBKve
02:11:58FromDiscord<ElegantBeef> sent a code paste, see https://play.nim-lang.org/#pasty=HXNmoFRV
02:12:02FromDiscord<ElegantBeef> Annnnnnnd there we go
02:12:48*krux02_ quit (Remote host closed the connection)
02:14:38FromDiscord<sirolaf> That doesn't look like it should fail to me
02:16:09FromDiscord<sirolaf> Maybe the tmpD assignment? But that should be able to move too, not sure how the environment works
02:16:59FromDiscord<ElegantBeef> The env lives with the instantiation of the iterator
02:17:18FromDiscord<ElegantBeef> So while it's `var envP.foo1` I think it's really env.foo1 = ...
02:17:26FromDiscord<ElegantBeef> Which means the `:tmpD = foo1` causes a copy
02:18:12FromDiscord<sirolaf> You think that can be "fixed"? Makes async pretty weak when you can't have any control over copies
02:19:00FromDiscord<ElegantBeef> Not without growing the stack for each iterator invocation
02:20:14FromDiscord<ElegantBeef> Actually no, all locals have to be lifted to the env
02:20:19FromDiscord<sirolaf> It should only be needed in a state branch leading up to a yield
02:20:53FromDiscord<sirolaf> It might as well be linear like this
02:21:27FromDiscord<ElegantBeef> All locals that preceed a yield must be lifted, if there is no yield them being local is likely fine
02:22:51FromDiscord<ElegantBeef> The awful solution is to raise it to the heap
02:24:47FromDiscord<ElegantBeef> sent a code paste, see https://play.nim-lang.org/#pasty=KVYKhnvg
02:25:19FromDiscord<ElegantBeef> sent a code paste, see https://play.nim-lang.org/#pasty=mhoRDoDZ
02:27:34FromDiscord<sirolaf> Well that doesn't have to copy Foo
02:27:35FromDiscord<sirolaf> It only copies the ref
02:29:00FromDiscord<sirolaf> Point of disabling copy is to get some compile-time help with it, this could blow up at runtime
02:29:41FromDiscord<ElegantBeef> I realize this
02:32:27FromDiscord<sirolaf> Gonna try patching closureiterators to only do this nonsense when a yield is in sight after the var later
02:32:34FromDiscord<sirolaf> It shouldn't use the env at all
02:32:58FromDiscord<ElegantBeef> Well it's a stack optimization to use all locals
02:33:12FromDiscord<sirolaf> The local disappears after this state so it's just wasting resources
02:33:34FromDiscord<ElegantBeef> Recursive calls is the concern I'm talking about
02:34:41FromDiscord<sirolaf> Explain please, don't see the issue
02:35:15FromDiscord<ElegantBeef> Say you recursively call instances of this iterator
02:35:21FromDiscord<ElegantBeef> Each call adds all the locals to the stack
02:35:45FromDiscord<sirolaf> And it should, if it doesn't the value will collide
02:35:53FromDiscord<ElegantBeef> I'm practically talking about something like TCO
02:36:00FromDiscord<ElegantBeef> Where you do not grow the stack
02:36:12FromDiscord<ElegantBeef> But anyway it's probably fine to remove the copies
02:36:19FromDiscord<sirolaf> Yeah good luck with that using nim's closure iterators
02:36:58FromDiscord<ElegantBeef> Well I'm not saying TCO directly, but it does elision the growth of the stack, but it does so by throwing everything on the heap 😄
02:39:44FromDiscord<sirolaf> Wouldn't the stack grow anyways if it has to copy all over the place
02:40:06FromDiscord<ElegantBeef> Only has to grow due to the `sink` afaik
02:41:46FromDiscord<sirolaf> Yeah this is pretty annoying
02:42:16FromDiscord<sirolaf> For now it can probably be assumed that not copying would be more efficient though, we all know async has huge issues with memory usage
03:09:10FromDiscord<sirolaf> It seems someone had the same idea https://media.discordapp.net/attachments/371759389889003532/1251010515954565190/image.png?ex=666d05d5&is=666bb455&hm=523dc4e05443cc71c2c71b5f20528cee46474db36dbd73ee3822d0e7c063e989&
03:10:18FromDiscord<sirolaf> That someone being araq from 9 years ago
04:01:34*end quit (Quit: end)
04:01:34*bcksl quit (Quit: \)
04:20:54*bcksl joined #nim
04:28:00*end joined #nim
06:06:26*cm quit (Ping timeout: 268 seconds)
06:07:12*ntat joined #nim
06:07:19*cm joined #nim
06:23:25*cm quit (Ping timeout: 256 seconds)
06:36:36*PMunch joined #nim
06:38:27*rockcavera quit (Remote host closed the connection)
06:38:45FromDiscord<arnetheduck> In reply to @sirolaf "For now it can": fwiw, chronos is a lot more memory efficient than AD since it skips the cycles↵↵also if you want to move things to the stack, https://github.com/nim-lang/Nim/issues/23425 would help a lot in keeping the stack size sane
06:39:50FromDiscord<arnetheduck> otherwise, there are also quite a few bugs in the closure iterator transformation where things are added to the heap env even though they shouldn't be there
07:08:48*xet7 joined #nim
08:17:16*ntat quit (Quit: Leaving)
08:21:59*cm joined #nim
08:21:59*xet7 quit (Quit: Leaving)
08:22:27*xet7 joined #nim
08:23:06*xet7 quit (Remote host closed the connection)
08:25:49*xet7 joined #nim
08:26:39NimEventerNew thread by Martinix75: Template import non compile in nim 2.0.4, see https://forum.nim-lang.org/t/11757
08:27:52*xet7 quit (Remote host closed the connection)
08:30:01*xet7 joined #nim
08:30:33*xet7 quit (Remote host closed the connection)
08:35:20*xet7 joined #nim
08:35:50*xet7 quit (Client Quit)
09:21:45*nyeaa49284230101 joined #nim
09:21:47*nyeaa49284230101 quit (Client Quit)
09:22:17*nyeaa49284230101 joined #nim
09:23:14*nyeaa49284230101 quit (Client Quit)
09:24:09FromDiscord<mratsim> In reply to @arnetheduck "otherwise, there are also": I think @yglukhov yasync does this.↵↵And CPS too, at least my experiments at manual CPS did: https://github.com/nim-works/cps/blob/master/talk-talk/manual1_stack.nim
09:27:38*nyeaa49284230101 joined #nim
09:42:05*coldfeet joined #nim
10:27:45*coldfeet quit (Remote host closed the connection)
11:47:29FromDiscord<xtrayambak> sent a code paste, see https://play.nim-lang.org/#pasty=HurppFKb
11:47:48FromDiscord<xtrayambak> (edit) "https://play.nim-lang.org/#pasty=ZFzCQSlU" => "https://play.nim-lang.org/#pasty=glBEtqBR"
11:58:39FromDiscord<fabric.input_output> is there a way to call the method `x` of the parent class from the `x` method implementation of the child class?
12:10:12FromDiscord<griffith1deadly> In reply to @fabric.input_output "is there a way": `procCall` maybe
12:14:01FromDiscord<fabric.input_output> In reply to @griffith1deadly "`procCall` maybe": that works, thansk
12:14:05FromDiscord<fabric.input_output> (edit) "thansk" => "thanks"
12:30:36*FromDiscord quit (Remote host closed the connection)
12:30:50*FromDiscord joined #nim
12:33:06FromDiscord<pmunch> In reply to @xtrayambak "Is there any way": You could try `{.noinit.}`
12:33:31FromDiscord<pmunch> But I've fought with `nimZeroMem` before, and its surprisingly stubborn sometimes
12:37:51FromDiscord<xtrayambak> I've found a solution by making my `memset` implementation a `{.cdecl.}` so that everything uses it whenever possible, and it seems to work.
12:42:15*PMunch quit (Ping timeout: 264 seconds)
12:44:13*beholders_eye joined #nim
13:02:59*beholders_eye quit (Ping timeout: 264 seconds)
13:13:20*beholders_eye joined #nim
13:37:06*beholders_eye quit (Ping timeout: 252 seconds)
13:41:26*krux02 joined #nim
13:54:06*ntat joined #nim
14:12:34*rockcavera joined #nim
14:13:55*ntat quit (Quit: Leaving)
14:22:05FromDiscord<matrix-t2bot> @pmunch:fosdem.org on matrix would like to bridge this channel. Someone with permission to manage webhooks please reply with `!matrix approve` or `!matrix deny` in the next 5 minutes.
14:22:11FromDiscord<pmunch> !matrix approve
14:22:12FromDiscord<matrix-t2bot> Thanks for your response! The matrix bridge has been approved.
14:22:38FromDiscord<pmunch> Sorry A2 the bridge seems to have died at some point. Try asking again now for a broader audience \:)
14:26:58FromDiscord<A2> ha, awesome! thanks.I have a weird memory bug in my nim project. Something is becoming `nil` inside a worker thread on the receiving end of a `Chan` from `threading/channels`.↵I'm kind of banging my head against a wall at this point, so I appreciate any kind of brainstorming, or tips for debugging tooling, or even bodgy hacks that can help me avoid the problem.
14:26:59FromDiscord<A2> My project works something like this\:↵I'm compiling to a .so library file for the Godot game engine to use. I'm using the C++ backend and creating a C++ class that Godot can instantiate.↵In my nim code, I start a thread, and use threading/channels to send data between the main thread (called synchronously from godot) and the worker thread.↵From inside the worker thread, I'm getting segfaults.
14:27:22FromDiscord<A2> sent a code paste, see https://play.nim-lang.org/#pasty=rBgVxUlt
14:28:02FromDiscord<A2> I used to expose a simpler nim library, and write the C++ class in plain C++, which would link against the nim library.↵It worked fine then, but I would use `GC_ref` a bunch of times when returning objects to C++.↵For a variety of reasons (I'm sure you can imagine), I decided to rewrite the C++ class (which wrapped a nim library) fully in nim.↵It's basically working, except for those memory errors in channels.
14:28:08FromDiscord<A2> If anyone has suggestions on something I could look into, tools to help me debug it, or bodgy-solutions that might help me avoid the problem, I'm all ears.. I'm really beating my head against the wall on this one.
14:28:40FromDiscord<nnsee> is the code available somewhere?
14:28:48FromDiscord<A2> The code is open source and available here\: https://gitlab.com/nobodywho/nobody/-/tree/rewrite-godot-integration-in-nim
14:28:59FromDiscord<A2> but... it's pretty messy and complicated at this point tbh
14:29:09FromDiscord<A2> and there's a bunch of random debugging prints and uncommented stuff on that branch
14:29:19FromDiscord<A2> I haven't made a minimal reproduction of the issue (yet), but am working towards it
14:31:46FromDiscord<A2> sent a code paste, see https://play.nim-lang.org/#pasty=uXnFAyMw
14:34:53FromDiscord<A2> sent a code paste, see https://play.nim-lang.org/#pasty=KYDGwjjd
14:35:09FromDiscord<A2> sent a code paste, see https://play.nim-lang.org/#pasty=UonhQqPc
14:38:14*lucasta joined #nim
14:38:17*ntat joined #nim
14:48:57FromDiscord<A2> sent a long message, see https://pasty.ee/tASaKzTq
14:50:13FromDiscord<A2> Again\: I'm not expecting anybody to spend a lot of time debugging my issue for me. But I would love to hear the thoughts of more experienced nim developers on issues like this. I'm running out of ideas... so if someone has a thought like "I wonder if it could be something related ti XYZ...", I'd really like to hear it
14:50:32FromDiscord<A2> Again\: I'm not expecting anybody to spend a lot of time debugging my issue for me. But I would love to hear the thoughts of more experienced nim developers on issues like this. I'm running out of ideas... so if someone has a thought like "I wonder if it could be something related to XYZ...", I'd really like to hear it
14:54:04FromDiscord<A2> sent a long message, see https://pasty.ee/rEBgeXPP
14:54:24FromDiscord<asbjorn2> (oh no... edits across discord and matrix are weird)
14:56:18FromDiscord<asbjorn2> In reply to @nnsee "is the code available": more specifically:↵↵The worker thread is here: https://gitlab.com/nobodywho/nobody/-/blob/rewrite-godot-integration-in-nim/nobody-lib/src/model.nim?ref_type=heads↵and it is being started from the C++ class that I define here: https://gitlab.com/nobodywho/nobody/-/blob/rewrite-godot-integration-in-nim/nobody-godot/src/nobodycard.nim?ref_type=heads
15:04:13FromDiscord<ieltan> sent a long message, see https://pasty.ee/PPJiXRlH
15:12:05FromDiscord<A2> Thanks! this is a lot of useful information to me.
15:16:21*coldfeet joined #nim
15:50:27*SchweinDeBurg quit (Quit: WeeChat 4.4.0-dev)
15:50:49*SchweinDeBurg joined #nim
16:11:48NimEventerNew thread by basow53698: The best gui bible library in your opinion., see https://forum.nim-lang.org/t/11760
16:24:02FromDiscord<odexine> sorry, what? bible?
16:28:40FromDiscord<bosinski2023> In reply to @odexine "sorry, what? bible?": i guess, the poster seems to seek for enlightment and has obviously missed the long thread on GUI's in the forum..
16:36:34FromDiscord<rakgew> oh, so the bridge is up again? thank you so much pmunch (@pmunch\:fosdem.org) and everyone else involved in the reapair.. \:-D
17:29:15NimEventerNew thread by hc: Why does ORC GC alter my data in Nim but ARC doesn't? What am I doing wrong?, see https://forum.nim-lang.org/t/11761
19:25:25*ntat quit (Quit: Leaving)
19:41:39FromDiscord<asbjorn2> In reply to @ieltan "A2, welcome to pain.": hm... I trust you on your advice to use `--mm:atomicArc` , but it looks like `threading/channels` only supports `--mm:arc` and `--mm:orc` though...
19:41:57FromDiscord<asbjorn2> at least the compiler sternly tells me `Error: This channel implementation requires --gc:arc or --gc:orc` when I have `--mm:atomicArc` set
19:42:23FromDiscord<asbjorn2> Can you point me to a resource that explains the difference between atomicArc and arc? Or why it's important to `atomicArc` specifically?
19:46:51FromDiscord<bosinski2023> sent a code paste, see https://play.nim-lang.org/#pasty=hqkQdhSt
19:47:45FromDiscord<asbjorn2> uh-oh, that seems likely
19:48:07FromDiscord<bosinski2023> In reply to @asbjorn2 "uh-oh, that seems likely": just a wild guess on my part..
19:48:39FromDiscord<asbjorn2> strange though; I'm just using what came with `nim` from nixpkgs unstable. `nim --version` returns "Nim Compiler Version 2.0.4 [Linux: amd64]"
19:49:01FromDiscord<asbjorn2> but I think you're right, that it's the problem
19:50:32FromDiscord<bosinski2023> In reply to @asbjorn2 "but I think you're": you could check out `threading/channels` from GH and edit it, just to make sure you use the right module. compiler-version looks good - should work - regards
19:51:18FromDiscord<asbjorn2> this rabbithole is getting deeper
19:51:30FromDiscord<asbjorn2> but thanks for the help!
19:51:56FromDiscord<bosinski2023> In reply to @asbjorn2 "this rabbithole is getting": OMG rabitts coming - maybe somebd who actually works with channels want to help out 🙂 ?
19:53:50FromDiscord<bosinski2023> @a2 there is a magic signal in this chat : try 'beef' or @ElegantBeef and good things will surely happen soon...
19:55:17FromDiscord<pmunch> Indeed! And sorry it took so long to get everything fixed
19:55:37FromDiscord<asbjorn2> ElegantBeef has helped me soo much in the past! They're great.↵↵But I've already got so much help in here, and I don't want to take up too much of other people's time.↵...also it's 22pm on a friday here, and I'm still at the office, having not fixed the bug. I think I'm gonna give up and go home within an hour or so.
19:56:45FromDiscord<bosinski2023> In reply to @asbjorn2 "ElegantBeef has helped me": yeah, it soccer-time - put it in the forum - BTW have u checked there ?
19:57:14FromDiscord<pmunch> At the office? Another elusive work Nimmer?↵(@asbjorn2)
19:57:40FromDiscord<bosinski2023> @a2 help arrived, hi peter..
20:11:11*beholders_eye joined #nim
20:11:43*lucasta quit (Quit: Leaving)
21:01:46*coldfeet quit (Remote host closed the connection)
21:07:16FromDiscord<Robyn [She/Her]> Time to make a shitty macro that transforms a limited subset of Nim code to an abstracted query format thing
21:07:28FromDiscord<Robyn [She/Her]> Not sure if I could get that to work with JSON but meh
21:13:11FromDiscord<leorize> there's a nim macro for transforming sql-with-nim syntax to sqlite commands
21:13:23FromDiscord<leorize> I'm pretty sure whatever you want is possible
21:15:55FromDiscord<Robyn [She/Her]> Fair, it'll still be a pita to figure that out though hah
21:17:43*beholders_eye quit (Ping timeout: 260 seconds)
21:30:50FromDiscord<leorize> you can always just create like a traversal table and interpret it at runtime
21:39:53FromDiscord<Robyn [She/Her]> Yeah that's the plan, it'll also work nicely with my plan to implement multiple database providers for my server
21:47:21FromDiscord<pmunch> Good evening↵(@bosinski2023)
21:50:54FromDiscord<bosinski2023> In reply to @pmunch "Good evening (<@754284517316886598>)": 🙂 that took two hours - user-asbjorn had some problem, that you could prbly. help him with - but i think he left the office...
21:55:58FromDiscord<Robyn [She/Her]> What's the easiest way to check if a field exists on a type via a typedesc, in a macro?
22:03:45FromDiscord<bosinski2023> In reply to @chronos.vitaqua "What's the easiest way": maybe this one https://forum.nim-lang.org/t/5638
22:08:00FromDiscord<Robyn [She/Her]> Hm thanks! It should help me a bit
22:09:44FromDiscord<␀ Array 🇵🇸 🍉> what libs do yall use for databases?
22:13:01FromDiscord<Robyn [She/Her]> In reply to @␀ Array 🇵🇸 🍉 "what libs do yall": Tad vague, what do you need exactly?
22:13:16FromDiscord<Robyn [She/Her]> Debby is a nice ORM, there's also NORM which is more popular I believe
22:15:39FromDiscord<␀ Array 🇵🇸 🍉> tbh not sure but as of now just storing file paths with a sequence of tags↵(@Robyn [She/Her])
22:16:49FromDiscord<␀ Array 🇵🇸 🍉> i am currently looking at norm but i wanted to see what other options exist
22:42:53FromDiscord<A2> I did! And now I'm having de-stress cocktails. Will continue digging the rabbit hole in the future 🐇↵(@bosinski2023)
22:43:29FromDiscord<A2> But thanks for being helpful.
22:44:42FromDiscord<A2> Yuup- aaand we're hiring ;)
22:50:02*disso-peach quit (Quit: Leaving)
22:57:02FromDiscord<Robyn [She/Her]> Anyone know how I'd get a NimNode from a typedesc?
22:58:30FromDiscord<Robyn [She/Her]> Wait can macros not do generics?
23:02:30FromDiscord<demotomohiro> In reply to @chronos.vitaqua "Anyone know how I'd": There are procs in macros module that have typedesc parameter.
23:17:04FromDiscord<Robyn [She/Her]> In reply to @demotomohiro "There are procs in": None that I can see do what I want, though
23:40:04*lucasta joined #nim