<< 03-05-2024 >>
00:24:27*def- quit (Quit: -)
00:26:17*def- joined #nim
00:36:46*gst quit (Ping timeout: 250 seconds)
01:08:38*def- quit (Quit: -)
01:08:56*def- joined #nim
01:11:55*mal`` quit (Quit: Leaving)
01:34:02*krux02 quit (Remote host closed the connection)
01:40:59*mal`` joined #nim
01:41:49*SchweinDeBurg quit (Quit: WeeChat 4.3.0-dev)
01:47:07*SchweinDeBurg joined #nim
02:14:23*def- quit (Quit: -)
02:14:47*def- joined #nim
02:17:52*def- quit (Client Quit)
02:18:17*def- joined #nim
02:34:37*def- quit (Quit: -)
02:38:26*def- joined #nim
03:06:18FromDiscord<xkonti> I didn't see much about async/await in the tutorials for Nim. I'm used to the concept of using async/await for concurrency (not parallelism) when working with languages like Javascript or C#. They often have specific versions of some operations that support async/await. How would one make async file operations in nim? Things like write/read/delete etc.? Is simply wrapping the code in a proc that supports async/await enough to make it concu
03:07:28FromDiscord<Elegantbeef> https://nim-lang.org/docs/asyncfile.html
03:10:15FromDiscord<Elegantbeef> You have to use Futures and it does not magically convert sync to async
03:21:24FromDiscord<leorize> async file is not async fwiw
03:26:31FromDiscord<Elegantbeef> Let me guess it does something slightly wrong which makes it not exactly async 😄
04:15:52NimEventerNew thread by Phyton: I Have Created a Kinda Logging Solution :), see https://forum.nim-lang.org/t/11536
04:17:23*rockcavera quit (Remote host closed the connection)
05:30:27FromDiscord<leorize> not exactly is an overstatement xd
05:30:37FromDiscord<leorize> it's sync IO with async overhead
05:31:42FromDiscord<leorize> async file io is simply a mess until recently
05:32:04FromDiscord<leorize> and the recent tech (io\_uring) is not everywhere yet
05:32:12FromDiscord<leorize> so to get async file io, use threads
05:32:57FromDiscord<Elegantbeef> Are selectors not considered true async?
06:28:38*PMunch joined #nim
06:53:28FromDiscord<nikolay_a_k> sent a long message, see https://pasty.ee/ORtOYNXzhNSQ
06:54:01FromDiscord<Elegantbeef> Nope not any tool that's really usable
06:55:42*ntat joined #nim
06:55:45FromDiscord<nikolay_a_k> Well, if here exist any coders that know both languages, could you, please, convert it? Sorry for asking this...
06:56:08FromDiscord<nikolay_a_k> (edit) "Well, if here exist any coders that know both languages, could you, please, ... convertfor" added "manually" | "manuallyconvert it? Sorry for asking ... this..." added "for"
06:56:19FromDiscord<Elegantbeef> Port the code to Nim yourself
06:56:39FromDiscord<nikolay_a_k> Thank you.) I don't know Nim at all.
06:56:49FromDiscord<Elegantbeef> That's' the first step
07:09:08FromDiscord<_ot> real
07:09:27FromDiscord<nikolay_a_k> Well, i used this AI tool: https://www.neuroengine.ai/Neuroengine-Large to convert Python to Nim and got this code: https://media.discordapp.net/attachments/371759389889003532/1235850694762692669/dllama.nim?ex=6635df26&is=66348da6&hm=aecfb3ba93dd151b8ad81edddb9e7d48ca3d19fc79e72ecf600ff3893e573685&
07:10:02FromDiscord<Elegantbeef> cool it doesn't work
07:10:09FromDiscord<Elegantbeef> Learn the language and convert it yourself
07:10:41FromDiscord<nikolay_a_k> And if i'm too stupid for Nim?
07:11:27FromDiscord<Elegantbeef> How do you expect to use the Nim code, then?
07:12:10FromDiscord<nikolay_a_k> I will compile it to exe and will have fun chating with AI using small native binary file.
07:12:21FromDiscord<nikolay_a_k> (edit) "chating" => "chatting"
07:12:28FromDiscord<Elegantbeef> So time to learn Nim
07:12:31FromDiscord<Elegantbeef> Anyone can learn it
07:12:42FromDiscord<Elegantbeef> https://nim-lang.org/documentation.html
07:12:45FromDiscord<Elegantbeef> Toones of resources here
07:13:32FromDiscord<nikolay_a_k> Honestly speaking, i didn't wrote Python script. I wrote AutoIt script and then converted it to Python using the AI mentioned above.
07:14:19FromDiscord<nikolay_a_k> Anyone can learn Basic but not everyone can learn Python/Nim.
07:15:47FromDiscord<Elegantbeef> Nope everyone can learn Nim it just takes time and effort
07:17:06FromDiscord<nikolay_a_k> It like saying that everyone can learn C++ and Assembler, it just takes time and effort. Very fuuny joke.
07:17:58FromDiscord<nikolay_a_k> (edit) "fuuny" => "funny"
07:18:10FromDiscord<Elegantbeef> It's not a joke
07:18:16FromDiscord<Elegantbeef> You get out what you put in
07:18:43PMunchAnd Nim is certainly on the easier end to learn of programming languages
07:18:47PMunchAt least the basic stuff
07:19:21FromDiscord<nikolay_a_k> Basic is much easier than Nim.
07:20:33FromDiscord<huantian> There’s no shortcuts in life my friend
07:20:48PMunchHow is Basic easier than Nim?
07:20:54FromDiscord<Elegantbeef> Well there are just rely on an AI then decry when no one wants to port code for you
07:21:40PMunchBasic is horrible.. Nim is much easier
07:22:01FromDiscord<huantian> Ngl I didn’t know decry was a word
07:22:19PMunchIf you can learn basic you can definitely learn Nim
07:24:07FromDiscord<nikolay_a_k> Basic is easier, of course. For example, i have low IQ but i managed to write AutoIt (Basic dialect) script by myself. But when i try to create GUI and Dll function call using Nim, i just give up. It is very complicated in this language.
07:30:26FromDiscord<huantian> Dude don’t let your self deprecating thoughts about your own intelligence stop you from learning things
07:32:22FromDiscord<huantian> I don’t believe low IQ means anything nor do I believe you have low IQ; the only thing that is stopping you from getting to where you can feel confident in using any language you want is some time, effort, and self-belief
07:32:38FromDiscord<Elegantbeef> Leave the self deprecating to those that have built an immunity from their negative effects like me!
07:35:04FromDiscord<leorize> it's more of a \nix and windows quirk
07:35:22FromDiscord<leorize> async file io is a lie
07:35:59*Ekho quit (Quit: CORE ERROR, SYSTEM HALTED.)
07:41:32FromDiscord<Elegantbeef> So I do not have to worry about my usage of `asyncfile` ontop of inotify files 😄
07:49:18FromDiscord<nnsee> In reply to @nikolay_a_k "It like saying that": well with that defeatist attitude how do you ever expect to accomplish anything? just about everything in life takes time and effort. if you feel like it's worth your time and effort in order to achieve what you want (a small, native binary with the added bonus of now knowing a good general purpose language). if you feel like it isn't worth _your_ time and effort, why on earth would it be wo
07:50:12*Ekho joined #nim
07:54:07FromDiscord<nikolay_a_k> I just think that Nim newbies have a right to have a simple one-function library to chat with AI models. And experienced coders shouldn't hesitate making an example script for newbies. So what's the problem? Such library already exists, Dllama.dll. Working Python code also exists and was posted in this chat. What's the matter? Is it so difficult for professional coders to convert a tiny, easy Python script to Nim? Lol.
07:55:51FromDiscord<Elegantbeef> Is it so difficult to learn how to use tools to learn how to do it yoursefl
07:56:23FromDiscord<nikolay_a_k> For me it's difficult. For you it's simple, because you are clever.
07:56:30FromDiscord<Elegantbeef> No cause I put effort in
07:56:48FromDiscord<Elegantbeef> Do not attribute my intelligence in programming due to an innate talent
07:57:46FromDiscord<Elegantbeef> I've spent much time learning from attempting to script and wanting to throw my PC out cause I did not understand a thing
07:58:07FromDiscord<Elegantbeef> Grow up and spend the same time "professional coder"s have spent
07:58:59FromDiscord<nnsee> > And experienced coders shouldn't hesitate making an example script for newbies.↵er, shouldn't they? you're asking for (in your words) "professional" coders to drop what they're doing and dedicate their time solely towards something they will 1) don't need, 2) never use themselves, 3) requested by some random stranger on the internet, because _you're_ unwilling to put the effort into it to do it yourself and feel like you're somehow enti
07:59:02FromDiscord<nnsee> make it make sense brother
07:59:25FromDiscord<nnsee> (edit) removed "will" | "1) don't need, 2) ... neveris" added "will" | "1) don't need, 2)willnever use themselves, 3) ... requested" added "is"
07:59:30FromDiscord<Elegantbeef> Wait they didn't ask me to do it, Dobby is free!
07:59:39FromDiscord<solitudesf> In reply to @nikolay_a_k "I just think that": > What's the matter? Is it so difficult for professional coders to convert a tiny, easy Python script to Nim? Lol.↵↵sounds like trolling
07:59:45*beholders_eye joined #nim
07:59:49FromDiscord<Elegantbeef> Could be trolling could be entitlement
07:59:53FromDiscord<Elegantbeef> We'll never know
08:00:19FromDiscord<Elegantbeef> I'm going to go spend 40 minutes watching DS9 instead of worrying about this
08:00:29FromDiscord<nnsee> there's a dark souls 9!?
08:01:36FromDiscord<Elegantbeef> Deep space 9
08:02:13FromDiscord<solitudesf> were the first 8 so good they made another one?
08:03:00FromDiscord<sebastian_solace> how do u open folders in nim?
08:03:29FromDiscord<nnsee> In reply to @sebastian_solace "how do u open": what do you mean by "open folders"
08:03:29*beholders_eye quit (Read error: Connection reset by peer)
08:03:33FromDiscord<sebastian_solace> like uhh
08:03:36FromDiscord<sebastian_solace> go through all of a folders contents
08:03:36FromDiscord<nnsee> like, in explorer.exe?
08:03:57FromDiscord<solitudesf> In reply to @sebastian_solace "go through all of": https://nim-lang.org/docs/osdirs.html#walkDir.i,string
08:04:02FromDiscord<sebastian_solace> kind of like open folders as a list
08:04:19FromDiscord<sebastian_solace> In reply to @solitudesf "https://nim-lang.org/docs/osdirs.html#walkDir.i,str": ooh
08:04:23FromDiscord<nnsee> well programmatically there's no concept of "opening folders", you can list all of the files in a certain directory and operate based off that
08:05:19FromDiscord<sebastian_solace> thats what i mean, meant to ask how i open all files in a certain directory
08:05:22FromDiscord<sebastian_solace> (edit) "open" => "list"
08:05:45FromDiscord<nnsee> ah yeah, that link is what you want then
08:08:32FromDiscord<demotomohiro> There is `opendir` function in low level: https://www.man7.org/linux/man-pages/man3/opendir.3.html
08:08:57*redj quit (Quit: No Ping reply in 180 seconds.)
08:09:04FromDiscord<nnsee> ah damn
08:09:08FromDiscord<nnsee> of course
08:09:08*beholders_eye joined #nim
08:09:15FromDiscord<nnsee> colour me stupid lol
08:10:20*redj joined #nim
08:10:40FromDiscord<nnsee> consequentially opendir is in std/posix https://nim-lang.org/docs/posix.html#opendir%2Ccstring
08:10:46FromDiscord<nnsee> (although this probably definitely isn't what you want)
08:12:02FromDiscord<Phil> ~~Nothing in psoix is what you want~~
08:12:22FromDiscord<Phil> (edit) "psoix" => "posix"
08:13:19FromDiscord<nnsee> phil is just reflecting his posix api PTSD on us
08:15:01FromDiscord<nnsee> reflecting? projecting.
08:20:06FromDiscord<.bobbbob> erm akshualky its called a directory
08:22:58FromDiscord<nnsee> in my mind folders have always been an UI concept only, which _can_ be used to represent directories and the files they include, but can _also_ be used to represent more abstract collections of things, like... a folder of network printers or something
08:23:26FromDiscord<.bobbbob> I like that
08:36:35*beholders_eye quit (Ping timeout: 245 seconds)
08:37:11*PMunch quit (Ping timeout: 264 seconds)
08:49:55FromDiscord<Phil> In reply to @nnsee "phil is just reflecting": Every single bit of PTSD projection on posix is deserved
08:49:59FromDiscord<Phil> I know those were rougher times back then
08:50:06FromDiscord<Phil> But then update your trainwreck of a standard or sth
08:50:19FromDiscord<Phil> Which likely isn't possible because old code... gnaaaaaaa
08:52:34FromDiscord<Elegantbeef> In Phil's world POSIX starts with "Piece of Shit"
08:52:40FromDiscord<nnsee> if posix is so good why isn't there a posix 2
08:52:55FromDiscord<Phil> piece of shotix
08:52:58FromDiscord<Phil> (edit) "shotix" => "shitix"
08:53:05FromDiscord<nnsee> (although posix is updated. last time in 2017 and quite extensively, changes can be seen here https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap01.html)
09:07:57FromDiscord<aryzen> so I'm having woes trying to get my cpp interop to work, I'm getting linker issues; `ld: symbol(s) not found for architecture arm64`↵↵I confirmed the .a (and the contained .o) are the correct architecture, so something else is awry
09:19:12FromDiscord<sOkam! 🫐> sent a long message, see https://pasty.ee/MMUXXHZbSbAB
09:20:11FromDiscord<sOkam! 🫐> _(beef, not you, its for nikolay 👌)_
09:20:41*beholders_eye joined #nim
09:21:17FromDiscord<sOkam! 🫐> I'm also very stoopid, and slow, and takes me 10times longer than others to get stuff done. But its all about the hardwork and consistency, like beef mentioned
09:28:17FromDiscord<nnsee> In reply to @heysokam "I'm also very stoopid,": so _that's_ what the s in sOkam stands for
09:32:01FromDiscord<Elegantbeef> If you look closely there's only 1 s in sokam
09:32:06FromDiscord<Elegantbeef> So choose a lane!
09:33:36FromDiscord<aryzen> I'm even slower what does the s in sokam stand for?
09:33:51FromDiscord<Elegantbeef> Smart!
09:33:54FromDiscord<Elegantbeef> Sophisticated!
09:34:08FromDiscord<Elegantbeef> The S in Beef stands for sarcastic
09:35:35FromDiscord<aryzen> sophisticatedOkam
09:35:56FromDiscord<aryzen> the g in aryzen stands for gullible
09:38:17FromDiscord<nnsee> the Ras in Ras stands for Rasmus! which coincidentally is my Name!
09:38:22FromDiscord<nnsee> not sure why I capitalized that
09:38:28FromDiscord<aryzen> Rasmus
09:38:46FromDiscord<sOkam! 🫐> In reply to @aryzen "I'm even slower what": it stands for bad-Style-Choices :kappa:
09:38:53FromDiscord<nnsee> In reply to @aryzen "Rasmus": hello
09:39:02FromDiscord<sOkam! 🫐> At least that what most people would say 🙈
09:39:03FromDiscord<aryzen> hello!
09:39:28FromDiscord<aryzen> bad-style-choices....↵↵Like, when I insist the braces open on sameline in C#?
09:39:34FromDiscord<aryzen> or much worse?
09:40:11FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=kIKrGaIHgewv
09:40:22FromDiscord<nnsee> oh god why
09:40:30FromDiscord<sOkam! 🫐> ^ see
09:40:35FromDiscord<aryzen> ... that export is floating away
09:44:49FromDiscord<aryzen> well... anyways; I'm still confused about my linker issue...
09:45:34FromDiscord<aryzen> actually... I might try some things, brb
09:47:33FromDiscord<summarity> On behalf of GitHub: We're sponsoring two upcoming Open Source valleys in Berlin. One at THE MERGE (June 13 – 14) and one at WeAreDevelopers (July 17 – 19). You can apply to showcase your open source project using the links here: https://dev.to/github/showcase-your-open-source-project-at-top-developer-conferences-in-berlin-this-summer-5aki ↵↵The focus is on learning, networking, and getting more contributors. Would be great to s
09:55:51*gst joined #nim
09:59:35*def- quit (Quit: -)
09:59:58*def- joined #nim
10:16:52*beholders_eye quit (Ping timeout: 246 seconds)
10:17:10FromDiscord<pmunch> In reply to @nnsee "in my mind folders": Wait, wtf does opendir actually do?
10:18:51FromDiscord<nnsee> opens a directory stream which you can then do `readdir()` etc on to read individual entries in the dir
10:19:39FromDiscord<pmunch> Oh, durr
10:20:01FromDiscord<pmunch> Of course, it's just an inode with a special directory listing, of course you'll have a low-level way of opening those..
10:20:57Amun-Ranot an inode, regularfile contents
10:21:32Amun-Ranot "regular file", but regular contents
10:23:07Amun-Rayou can open directory with open(2) too
10:28:23NimEventerNew thread by Hobbyman: How to create a logical expression programmatically?, see https://forum.nim-lang.org/t/11538
10:44:11*nyeaa49284230101 joined #nim
11:08:13*gst quit (Quit: Client closed)
11:10:35*def- quit (Quit: -)
11:30:04*def- joined #nim
11:33:04*gst joined #nim
11:52:28*modev joined #nim
11:52:30*modev left #nim (#nim)
12:06:03*modev55 joined #nim
12:06:07*modev55 left #nim (#nim)
12:39:46*def- quit (Quit: -)
12:39:57*def- joined #nim
12:55:45*rockcavera joined #nim
13:16:33*disso-peach joined #nim
13:57:28FromDiscord<_nenc> hey, anybody familiar with websocket?
13:58:52FromDiscord<_nenc> when I use https://github.com/treeform/ws to make a websocket client (basically a chat bot), I found something surprising↵it seems that I must do some `recv`, I can't just create the connection and do all `send` s
14:01:15FromDiscord<_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=FtNbOwdGKott
14:09:59FromDiscord<Phil> In reply to @_nenc "hey, anybody familiar with": Yes, happy to help, however give me some time to finish work first
14:19:00FromDiscord<Phil> Hmmm yeah, that does seem odd. It should not be necessary.↵↵Could you give a quick show of code?
14:20:51FromDiscord<_nenc> well, I am encountering some wierd behavior... I removed some recv and it seems to work again. (a few minutes ago, when I had no recv, my bot left just after it joined the chatroom. but I can't say the codes are the same.) So, I think the problem is not here...
14:22:04FromDiscord<_nenc> thank you very much tho↵it must be my understand of Nim and WebSocket not enough
14:22:12FromDiscord<_nenc> (edit) "of" => "to"
14:25:20*def- quit (Quit: -)
14:26:17*def- joined #nim
14:31:12FromDiscord<Phil> In reply to @_nenc "thank you very much": Websockets overall are a semi-simple standard.↵It should basically "just work".↵At least when using treeform/ws for the basis of the serverbeing the receiving end of a connection instead of the sending end it tends to work as intended, that's also the scenario with which I have the most familiarity
14:31:27FromDiscord<Phil> But there's nothing about the ws standard that states inherently that you must receive messages
14:36:34FromDiscord<_nenc> wait... maybe it is because I don't use multithreading right \:(
14:37:59FromDiscord<_nenc> multithreading is hard, my test demo works but my real program with multithreading dont send them without exceptions throwed. it must be because I can't access global variables from sub threads
14:48:17FromDiscord<Phil> In reply to @_nenc "multithreading is hard, my": Are those const or let? Do you write to them? If so, are they locked or not?
14:48:35FromDiscord<Phil> You can have shared global memory, but that's the kind of thing you tend to want to really save with a lock
14:58:11*def- quit (Quit: -)
14:58:47*def- joined #nim
15:18:27FromDiscord<_nenc> sorry, I just now had some difficulties accessing discord
15:19:42FromDiscord<_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=GPBgUPwIgUVU
15:21:41FromDiscord<_nenc> now I even use channels and use parameters to pass the pusher to one sub thread, but it still does't work, concretely when it send sth, I cant see the message sent by my bot, I am sure it is very likely not the problem of the server... well it is too wierd
15:23:29FromDiscord<_nenc> In reply to @_nenc "well... it is a": I tried to just send from sub thread with the global ws. Now it's channel and parameter. Neither works
15:23:48FromDiscord<Phil> And your pusher is accessed by multiplet hreads?
15:23:51FromDiscord<Phil> (edit) "multiplet hreads?" => "multiple threads?"
15:24:01FromDiscord<Phil> What is target?
15:26:50FromDiscord<_nenc> it is just a normal string, concretely it is a username my bot is supposed to intercat with
15:27:14FromDiscord<_nenc> now I have a relatively small code to show it...
15:27:41FromDiscord<_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=BPzfGkXIWnHU
15:28:21FromDiscord<_nenc> (to simplify I removed something about target, but it can still show the problem
15:28:43FromDiscord<_nenc> (edit) "https://play.nim-lang.org/#pasty=oHZsxLYnbJRP" => "https://play.nim-lang.org/#pasty=GemvjMhfYJKU"
15:28:57FromDiscord<_nenc> (edit) "https://play.nim-lang.org/#pasty=OsPtaDIxyOyy" => "https://play.nim-lang.org/#pasty=AzusuLUpMYzs"
15:29:35FromDiscord<_nenc> it is not shared memory error, I think maybe it is wrong in mixing async with threading
15:31:50FromDiscord<Phil> Use jointhread
15:32:58FromDiscord<Phil> If you're going to use low level APIs like create thread then make sure you "jointhread" that thing back with your main thread before the end of the program. ↵That actually does what you're assuming sync will do
15:33:48*def- quit (Quit: -)
15:34:04FromDiscord<_nenc> In reply to @isofruit "If you're going to": ah, sync don't do it? isn't `std/threadpool` designed as `spawn f(); sync()` will be enough?
15:34:41FromDiscord<Phil> You're not using thread pool though, you're using createthread
15:35:03FromDiscord<_nenc> wait, am I??
15:35:07FromDiscord<Phil> Well, hidden in a sense but I don't trust thread pool too much
15:36:03FromDiscord<Phil> I can look into thread pool docs later to see if they specify any behaviour
15:36:49FromDiscord<_nenc> emmmm, i got it
15:37:15FromDiscord<_nenc> if I change to malebolgia, do you think it is likely to be solves?
15:37:17FromDiscord<_nenc> (edit) "solves?" => "solved?"
15:38:22FromDiscord<Phil> Yeah thread pool appears to not act well.↵Your chances Taskpools, weave or malebolgia , the latter of which araq is promoting, though I can't say I'm a fan of any of them
15:39:38FromDiscord<_nenc> so, the createThread is not in my code, but in threadpool, and sync is malpracticing and not joining my threads here?
15:42:37FromDiscord<Phil> Sync appears to not be working as advertised for the most part from what I can tell without running the code and based on your description
15:42:58FromDiscord<Phil> You can use echo to see if your thread proc runs or not
15:43:03FromDiscord<Phil> I would assume not
15:43:42FromDiscord<_nenc> oh, thanks very much, I think I will do more experiments on it
15:45:56FromDiscord<_nenc> well... it is very weird and it is the same as my previous experiments (in a more complex program): my thread proc is actually run, the send proc is also run, but the messages are not shown
15:46:09FromDiscord<Phil> Hmmmm
15:46:13FromDiscord<_nenc> (edit) "the same as" => "in line with"
15:48:14FromDiscord<Phil> It's running the proc to completion? ↵Does the protocol the server uses that you want to connect to maybe require extra fiddling?
15:48:36FromDiscord<Phil> Like an Auth message or the like
15:49:49FromDiscord<Phil> If you're really unlucky then spawn copies your ws
15:50:26FromDiscord<_nenc> In reply to @isofruit "If you're really unlucky": yeah, I was thinking of things like this kind
15:50:33FromDiscord<Phil> Could echo the ptrs to see if they're the same
15:51:19FromDiscord<Phil> Or rather echo the repr of the pusher obj
15:51:20*def- joined #nim
15:51:39FromDiscord<Phil> That should show the PTR of the es connection
15:55:26FromDiscord<_nenc> emmmmm, however even the addr of ws seems to be the same, to clarify I will send the newest code
15:55:40FromDiscord<_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=EabZbSLFodpc
15:56:03FromDiscord<_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=DoMldekkvVEZ
15:56:26FromDiscord<_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=xuZlgXJdvgfd
15:57:40FromDiscord<_nenc> (I assume I am printing the pointer right)
16:09:59FromDiscord<_nenc> there is actually sth special about the server, if your message is not valid json the server will close your connection
16:10:30FromDiscord<Phil> Not quite, you'd want to do ` echo cast[uint64](pusher.ws)` to check the pointer inside the pusher was the same
16:10:52FromDiscord<_nenc> ahhh! you're right
16:10:53FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=ntGsVsGZPKHf
16:11:00FromDiscord<_nenc> `addr` is like `&`
16:11:24FromDiscord<_nenc> it is addr of my stack temp var, isnt it
16:11:29FromDiscord<Phil> In reply to @_nenc "there is actually sth": yep
16:11:40FromDiscord<Phil> or rather it's an addr of the ref that is int he stack
16:14:41FromDiscord<_nenc> emmmm, when I echo like this, they are still the same...?
16:15:12FromDiscord<Phil> Yep, which means there is no copy that I can see
16:16:28FromDiscord<_nenc> In reply to @_nenc "there is actually sth": it seems that: calling send from thread causes the connection to be closed, because it doesn't send anything which is >= the first msg sent from thread in time
16:17:10FromDiscord<_nenc> I edited ws.nim to see what is sent(maybe the string gets wrong through threads?) but I cant see anything wrong
16:17:56FromDiscord<_nenc> if I can setup a local server it will be definitely clearer...
16:18:07FromDiscord<Phil> I think I could help more if I could see the WS connection on the sevrer somehow =/
16:29:08FromDiscord<Phil> Welp, can't experiment anymore, getting rate-limited or blocked
16:30:58FromDiscord<Phil> In reply to @_nenc "if I can setup": Curious for how to figure out what the minimum requirement is to trigger this behavior.↵Basically try sending something at the start and end of the program from the main thread, then make the code in the side-thread smaller and smaller until you know what triggers the problem
16:31:21FromDiscord<Phil> Might be that the mere usage of spawn triggers, it, might be the first message you send via it, might be your push proc is busted, worth figuring out
16:33:52*beholders_eye joined #nim
16:39:17FromDiscord<norax.2> a nim library to encode base85?
16:39:35FromDiscord<norax.2> (edit) "encode" => "encode/decode"
16:40:19FromDiscord<polylokh_39446> <https://github.com/scemino/engge2/blob/f0d8939896b021124aa9821e9c7d943db0d82105/src/io/base85.nim#L4>
16:42:02FromDiscord<norax.2> In reply to @polylokh_39446 "<https://github.com/scemino/engge2/blob/f0d8939896b": ty
16:42:24FromDiscord<_nenc> In reply to @isofruit "Curious for how to": it can be seen in a very pure case
16:42:37FromDiscord<_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=WiqlNGgABuHg
16:42:50FromDiscord<_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=HPOgCnSanfeR
16:43:01FromDiscord<_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=IarUgdSEfWDV
16:43:27FromDiscord<Phil> Now reduce t - does it still close when t is basically just an "echo "start" "?
16:43:44FromDiscord<_nenc> (once it printed m1 and m2 but not t1, I think it's just a little timing error)
16:43:50FromDiscord<Phil> Does it still close without spawning anything ?
16:44:07FromDiscord<Phil> (edit) "without spawning anything" => "if you remove spawn?"
16:44:09FromDiscord<Phil> (edit) removed "?"
16:44:26FromDiscord<_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=aXYPLwBssSev
16:45:02FromDiscord<Phil> Okay, comment one in
16:45:07FromDiscord<_nenc> (edit) "https://play.nim-lang.org/#pasty=eGWxXuFCTHLh" => "https://play.nim-lang.org/#pasty=eQaWzHIXFIGx"
16:45:33FromDiscord<_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=tcohJMDHVUIm
16:46:01*def- quit (Quit: -)
16:46:03FromDiscord<_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=idgCXEQYWpiM
16:46:04FromDiscord<Phil> Okay, so the mere fact you're sending from that other thread is closing the connection. It is not the act of spawning the thread, it is the act of using the ws in it
16:47:01*def- joined #nim
16:47:05FromDiscord<Phil> If you had a race condition where both threads might be sending through that ws simultaneously I'd understand
16:47:09FromDiscord<graveflo> is it possible that the socket object is being moved into the thread and that is calling the destructor?
16:47:14FromDiscord<Phil> Because you're constantly at risk of that happening and blowing up your socket
16:47:30FromDiscord<Phil> But in this example you're making sure there's ms between those occurances so it should be impossible
16:47:36FromDiscord<_nenc> In reply to @graveflo "is it possible that": yes, I thought about ARC, but idk
16:47:56FromDiscord<Phil> Put it all in a proc and then use expandArc to see the destructor-calls
16:47:56FromDiscord<_nenc> yes... maybe I can just use chan in the main thread as a workaround, but are there other solutions? is this a bad behavior, or are there higher level multithreading methods to avoid it?
16:47:57FromDiscord<graveflo> could make a dummy object and override the move semantics and see what it does
16:47:58FromDiscord<Phil> Because that might be it
16:48:28FromDiscord<Phil> Use `--expandArc:PROCNAME`
16:50:10FromDiscord<_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=hhDqkJYkpqEQ
16:51:23FromDiscord<_nenc> there is a `dup`! but in previous experiment (almost identical behavior but more complex code) ws seems to be the same pointer
16:52:11FromDiscord<_nenc> (edit) "there is a `dup`! but in previous experiment (almost identical behavior but more complex code) ws seems to be the same pointer ... " added "(maybe `dup` doesn't mean copying)"
16:53:04FromDiscord<graveflo> yea it looks like destroy is being called at the end so that's prob not it :/
16:53:05FromDiscord<Phil> That should be duplicating the ref
16:53:20FromDiscord<Phil> Which mean you should be fine because you're just getting a second ref to the same ws
16:53:20*def- quit (Quit: -)
16:54:03*def- joined #nim
17:04:38FromDiscord<_nenc> After commenting a except in ws.nim
17:04:43FromDiscord<_nenc> I got some traceback
17:05:22FromDiscord<_nenc> https://media.discordapp.net/attachments/371759389889003532/1236000662681288765/message.txt?ex=66366ad1&is=66351951&hm=7060c1765731688b24b125af2669e4580c706afce55babe6cad23599ddc02aac&
17:06:58FromDiscord<graveflo> oh that kinda makes sense. The async dispatcher is prob thread local.
17:07:45FromDiscord<_nenc> ahh yes, I thought that maybe Nim's async can't work well with threading
17:08:00FromDiscord<Phil> Which means, you no share ws
17:09:31FromDiscord<graveflo> idk if there is an easy way to submit work to a dispatcher running in another thread, but I guess the idea here would be to run a thread just for housing the dispatcher
17:10:06FromDiscord<graveflo> as opposed to trying to share the dispatcher itself that is
17:10:13FromDiscord<Phil> There is not I'm pretty sure
17:10:32FromDiscord<Phil> Or rather I have not found anything ever related to mixing async and threads easy
17:10:51FromDiscord<Phil> This kind of stuff is why actor model is so valuable, just do message passing
17:11:13FromDiscord<Phil> (Or at least in my mental model that immediately maps to actor model, I might be wrong here)
17:14:13FromDiscord<_nenc> well, I think I can solve my program
17:14:25FromDiscord<_nenc> I can create my ws in the sub thread
17:14:29FromDiscord<_nenc> and use chans
17:15:06FromDiscord<_nenc> (previously I passes ws from main thread to sub thread and let sub threads use chans to talk to ws)
17:15:14FromDiscord<_nenc> (edit) "passes" => "passed"
17:21:24FromDiscord<_nenc> anyway, thank you very much
17:22:35FromDiscord<_nenc> if not for you I can't solve such a complex problem to me
17:23:19FromDiscord<_nenc> (and I think I am correct for posting my problem here instead of on forum😂 forum won't be instant enough
17:27:46FromDiscord<Phil> In reply to @_nenc "if not for you": All good.↵I want to eventually get back to my multithreading lib so that we can have some rock solid basics of an actor model.↵At least for myself I'd love to have that. Just mentally hung up on an reactivex implementation for nim
17:27:57FromDiscord<Phil> Sidenote, by going all in on closures that one is becoming surprisingly easy
17:33:24FromDiscord<MDuardo> You want to make Erlang-like concurrency?↵(@Phil)
17:33:47FromDiscord<Phil> Maybe? I don't know enough about erlang intricacies to make that kind of claim
17:33:58FromDiscord<Phil> All I want is to have some kind of way that allows me to treat threads like an http-server
17:34:18FromDiscord<Phil> (edit) "All I want is to have some kind of way that allows me to treat threads like an http-server ... " added "with a WS connection"
17:34:34FromDiscord<Phil> "I send you X and forget about it, you may eventually send Y back" etc.
17:36:38FromDiscord<Phil> Okay this is ridiculous, how the hell is reactiveX this easy to implement with just closures, this is working way too well
17:39:34FromDiscord<bosinski2023> In reply to @isofruit "Maybe? I don't know": be aware that the erlang-intricacies involve 4-6 compiler-passes on the erlang-side. There is a YT-talk that goes into detail describing the scrunity to achieve safety & stabillity on the Erlang-VM. It's impressive and nobody has yet shown that such can be rebuild in a way that the replica can provide comparable guarantees - this includes even Scalas' actor implementation.
17:40:38FromDiscord<Phil> I don't want to replicate Erlang. I want a single-threaded-pseudo-websocket-like-server.↵With pre-defined procs that you can call on a given thread and everything. My scope is far smaller
17:45:19FromDiscord<Phil> Basically Dart-Isolates or WebWorkers suffices to me
17:45:30FromDiscord<Phil> But more that I want an even narrower API that limits what you can send
17:45:36FromDiscord<Phil> (edit) "But more that I want an even narrower API that limits what you can send ... " added "at compiletime"
17:47:08FromDiscord<bosinski2023> In reply to @isofruit "I don't **want** to": sure, and i'd love to see that work out - but, when threads are involved and smth. goes wrong, you'd need some tooling to figure out what happened - and even that migh get hairy looking at the tooling options we have at hands..
17:48:04FromDiscord<Phil> I mean, I had the basics down already, I just got frustrated with tsan/helgrin and how some versions of some nim dependencies introduces dataraces meaning one wrong version and my tests failed on me
17:48:16FromDiscord<Phil> (edit) "introduces" => "introduced"
17:48:28FromDiscord<Phil> Lock-files only helped to some degree
17:49:15FromDiscord<Phil> And then worked bombed me into oblivion with complexity so I had to take a rest.↵This reactivex implementation is getting me back into the swing of things
17:57:37*def- quit (Quit: -)
17:58:07*def- joined #nim
17:59:16FromDiscord<Phil> rewriting to go full closure on my reactivex approach for nim took me barely 3h, wtf)
17:59:18FromDiscord<Phil> (edit) "wtf)" => "wtf"
17:59:27FromDiscord<Phil> I feel like such a fool
18:29:37*beholders_eye quit (Ping timeout: 268 seconds)
18:30:48*def- quit (Quit: -)
18:30:56FromDiscord<nocturn9x> is it possible that nim's leaking memory?
18:31:18FromDiscord<nocturn9x> I switched to using `ref Thread[...]` and memory usage just goes up and up and up... until stuff crashes or slows to a crawl
18:31:49*beholders_eye joined #nim
18:31:50*def- joined #nim
18:31:57FromDiscord<nocturn9x> also interesting, if I `joinThread(t[])`, the next time I spawn a new thread and call the same function, it segfaults when it tries to set a field on a shared reference passed by the main thread
18:32:11FromDiscord<nocturn9x> which is fixed by `GcRef`ing it, but that's nonsensical
18:32:43FromDiscord<nocturn9x> and to be clear, it's not the object that I'm calling `GcRef` on, but the _field_
18:33:13FromDiscord<nocturn9x> so I have `session` and the function does `session.searcher = newSearchManager(...)` and it segfaults unless I do `GcRef(session.searcher)` before I call `joinThread`
18:33:33FromDiscord<nocturn9x> which makes no freaking sense because it's supposed to be a shared ref, and why would it segfault anyway?
18:33:37FromDiscord<nocturn9x> it doesn't do it in debug mode
18:33:50FromDiscord<nocturn9x> (for context, I'm using `atomicArc`)
18:36:08FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=EYvfsWlIUbYl
18:36:50FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=UzFutqeqwGyQ
18:36:58FromDiscord<nocturn9x> specifically at `session.searchManager = searcher`
18:37:01FromDiscord<nocturn9x> wtf is going on?
18:37:22FromDiscord<nocturn9x> I have verified `session` is not nil, neither is `searchManager` (they're both `ref`s)
18:40:26FromDiscord<nocturn9x> ok nevermind it does happen in debug mode as well
18:40:33*def- quit (Quit: -)
18:40:44FromDiscord<nocturn9x> sent a long message, see https://pasty.ee/WSZwOYVTNtMB
18:40:56*def- joined #nim
18:41:02FromDiscord<nocturn9x> but it's nim's internal stuff, `bestMove` _starts_ at line 292 so the traceback is wrong too lol
18:41:19FromDiscord<bosinski2023> In reply to @nocturn9x "wtf is going on?": well, my suspicion might be very wrong, but last time i tried smth. like this i learned that marking objects using `GCref`/`GCrunref` does not work with ARC ? Maybe that has changed in between ? How about unsing `refc` in combination with `locks` ?
18:41:41FromDiscord<nocturn9x> well okay if I wanted to use refc with locks to kill the performance I would
18:41:52FromDiscord<nocturn9x> the point is I don't want to, this is performance critical code :/
18:42:32FromDiscord<polylokh_39446> >Might be move semantics↵compile with --expandArc:some_module_name or --expandArc:some_proc_name to see what Arc's doing to the code. That'll show lifetime hooks.
18:43:19FromDiscord<polylokh_39446> some_module_name's going to be only toplevel code, so if this is bestMove, --expandArc:bestMove
18:43:21FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=eEvFtKMQvQEv
18:43:28FromDiscord<nocturn9x> motherfucker
18:43:30FromDiscord<nocturn9x> why
18:43:31FromDiscord<nocturn9x> lol
18:43:38FromDiscord<nocturn9x> it doesn't own the damn reference 😢
18:44:36FromDiscord<nocturn9x> okay it is doing a copy tho
18:44:46FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=CBGKgiYajqJU
18:47:30FromDiscord<bosinski2023> In reply to @nocturn9x "the point is I": i can feel you, but ARC is a sophisticated beast and one can at best observe what ARCs moves/operations will be as with `epandArc`, but one cannot tell ARC to keep some object/reference. Thats why i suggested to use `locks` or `atomics` - verify the code does ok with `refs` and then try ARC..
18:48:12FromDiscord<bosinski2023> (edit) "`epandArc`," => "`expandArc`," | "`refs`" => "`refc`"
18:48:24FromDiscord<nocturn9x> well with refc it segfaults when accessing the atomic
18:48:26FromDiscord<nocturn9x> ...lol
18:48:40FromDiscord<nocturn9x> and it's crashing inside the atomics library
18:48:41FromDiscord<nocturn9x> _cool_
18:49:01FromDiscord<nocturn9x> I love parallelism in nim. It's :so_ easy.
18:49:04FromDiscord<nocturn9x> (edit) ":so_" => "_so_"
18:49:06FromDiscord<bosinski2023> In reply to @nocturn9x "and it's crashing inside": which one `std/atomics` or `threading/atomics`
18:49:12FromDiscord<nocturn9x> `std/atomics`
18:49:26FromDiscord<nocturn9x> also should all references just be atomics
18:49:28FromDiscord<nocturn9x> like wat
18:54:19FromDiscord<Phil> In reply to @nocturn9x "is it possible that": Depends: It definitely will always leak ThreadVars because those do not ever get cleaned up
18:54:34FromDiscord<nocturn9x> In reply to @isofruit "Depends: It definitely will": _what_
18:54:44FromDiscord<Phil> Funny things that are threadvars would be for example the ORC-GC or the async dispatcher
18:54:59FromDiscord<nocturn9x> you're telling me it doesn't GC thread procs either?
18:55:23FromDiscord<Phil> Define thread-procs. All I can tell you is that threadVariables do not get collected. You need to destroy/nil those manually before exiting
18:55:29FromDiscord<bosinski2023> In reply to @nocturn9x "like wat": have u considered doing all allocation/deallocations yourself - i mean the thread-accessed parts ? use a arena-allocator and do one free at exit ?
18:55:42FromDiscord<nocturn9x> "have you considered going the C way"
18:55:51FromDiscord<nocturn9x> why would I use nim
18:55:59FromDiscord<nocturn9x> `malloc()` was invented 40 years ago
18:56:16FromDiscord<nocturn9x> someone is getting a pipebomb in their mailbox for this ass-backwards design
18:56:23FromDiscord<nocturn9x> like for real this is the dumbest fucking thread model _ever_
18:56:25FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=BcQudkhyYlOk
18:56:55FromDiscord<nocturn9x> I don't have any variables marked as `{.thread.}`
18:57:00FromDiscord<nocturn9x> if that is what you're wondering
18:57:07FromDiscord<nocturn9x> I do create some stuff in the thread itself
18:57:09FromDiscord<Phil> Sure, but your dependencies might
18:57:16FromDiscord<Phil> If you use async - You need to take care of the dispatcher
18:57:20FromDiscord<Phil> If you use std/times, you need to clear their shit
18:57:21FromDiscord<nocturn9x> I am not using async
18:57:30FromDiscord<nocturn9x> I also do not use `std/times`
18:57:31FromDiscord<Phil> If you use orc, you need to full-collect
18:57:32FromDiscord<nocturn9x> I do use monotimes
18:57:40FromDiscord<nocturn9x> so basically nim leaks memory
18:57:44FromDiscord<Phil> Then you might want to check if that has {.thread.}
18:57:48FromDiscord<nocturn9x> I thought only V would leak memory by design
18:58:07FromDiscord<bosinski2023> In reply to @nocturn9x "I thought only V": thats common knowledge 🙂
18:58:27FromDiscord<nocturn9x> araq, I don't know if you're reading
18:58:37FromDiscord<nocturn9x> but please do know I have a very special place in my heart for your thread model
18:58:39FromDiscord<Phil> He is not
18:58:41FromDiscord<nocturn9x> and it's not in good standing.
18:58:54FromDiscord<nocturn9x> what a colossally idiotic design oh my god
18:59:18FromDiscord<nocturn9x> how does anyone expect to use this stuff in production if it can't even clean up _its own damn garbage_
18:59:19FromDiscord<Robyn [She/Her]> If you do want him to respond to your hatred of it, you could always go to #internals which is where he lives :P
18:59:33FromDiscord<nocturn9x> people are just supposed to, oh, _know_ what stuff their dependencies use?
18:59:35*def- quit (Quit: -)
18:59:37FromDiscord<nocturn9x> that's a good way to drive people fucking insane
18:59:52FromDiscord<Phil> Note that I would definitely tone it down because I'm not sure how chill Araq is on any given day.
18:59:58FromDiscord<Robyn [She/Her]> In reply to @nocturn9x "people are just supposed": Well yeah, that's true for nearly all languages, no?
19:00:05FromDiscord<nocturn9x> In reply to @chronos.vitaqua "Well yeah, that's true": what
19:00:07FromDiscord<Phil> (edit) "Note that I would definitely tone it down ... because" added "in such a scenario"
19:00:07FromDiscord<nocturn9x> no?
19:00:13FromDiscord<Robyn [She/Her]> C, C++, Zig, Rust, etc
19:00:17FromDiscord<nocturn9x> I don't need to know if one of my dependencies is using thread memory and clean up after it
19:00:20FromDiscord<nocturn9x> the language does it for me
19:00:28FromDiscord<Phil> In reply to @chronos.vitaqua "Well yeah, that's true": They are referring to needing to clean up the garbage of your dependencies
19:00:28FromDiscord<nocturn9x> or the library does it on its own
19:00:36FromDiscord<Phil> Like nim requires you to just know if your dependencies use threadvars
19:00:42FromDiscord<Robyn [She/Her]> Aah
19:00:43FromDiscord<Phil> So that you can clean those up before the thread exits
19:00:43FromDiscord<nocturn9x> In reply to @isofruit "Note that I would": I literally do not care, he can ban me if he likes
19:01:05FromDiscord<nocturn9x> it doesn't change the fact this design is stupid and it clearly shows by the fact it doesn't even _work_
19:01:35FromDiscord<nocturn9x> if he can't take criticism that's on him
19:01:49FromDiscord<bosinski2023> In reply to @isofruit "So that you can": if that would be true - and i doubt it, never seen such with - then i'd call this a pitfall..
19:01:52FromDiscord<nocturn9x> i've been an avid nim user for a few years now and this is seriously making me consider dropping it
19:02:14FromDiscord<nocturn9x> I'm a developer, I don't have time to fix my code _and the compiler I'm using to compile it_
19:02:26*def- joined #nim
19:02:32FromDiscord<Phil> In reply to @bosinski2023 "if that would be": It is. Valgrind and asan literally confirmed it to me. The issue I referenced in the doc-comment int he code I posted is an issue I opened precisely because this is a problem
19:02:37FromDiscord<nocturn9x> if I have to write a compiler I'll write my own, which I'm currently in the process of doing. And I definitely know how I do _not_ want my threads to work
19:02:53FromDiscord<Phil> https://github.com/nim-lang/Nim/issues/23165 just to get it out of there
19:02:55FromDiscord<nocturn9x> how are people supposed to write code like this
19:03:50FromDiscord<Elegantbeef> Ideal one should audit dependencies
19:03:51FromDiscord<Elegantbeef> But yes Nim should clear thread local vars
19:04:23FromDiscord<Phil> In reply to @nocturn9x "if I have to": Just be happy you didn't have to find this out yourself via valgrind after 8h of insanity debugging
19:04:29FromDiscord<nocturn9x> dude
19:04:34FromDiscord<nocturn9x> I have been debugging these issues for days
19:04:38FromDiscord<nocturn9x> or, well, trying to
19:04:48FromDiscord<Phil> And you could have taken longer, trust me, been there.
19:04:56FromDiscord<nocturn9x> random fucking segfaults because nim's ARC impl. can't keep its shit together
19:05:00FromDiscord<Elegantbeef> Well this is a bug more than design↵(@Phil)
19:05:12*ntat quit (Quit: Leaving)
19:05:27FromDiscord<nocturn9x> is there a way to work around this or do I just throw away 3000 lines of code and start from scratch
19:05:30FromDiscord<Phil> In reply to @Elegantbeef "Well this is a": Sure, but this has been the behavior since... well I've known of it for 4 months but I'm pretty sure that behavior is way older
19:05:39FromDiscord<nocturn9x> because there is no way I'm playing whack-a-mole with my dependencies, fuck that
19:05:50FromDiscord<Elegantbeef> I don't think it'd be too hard to actually create a thread destructor that destructs all threadvars
19:06:59FromDiscord<Elegantbeef> I'm not suggesting you fix the compiler
19:07:19FromDiscord<bosinski2023> In reply to @isofruit "It is. Valgrind and": good catch - i never used `async` . Surprisingly i used the `times` and `monotimes` and have never seen leaks...
19:07:31*beholders_eye quit (Ping timeout: 255 seconds)
19:07:44FromDiscord<nocturn9x> the fun part is that doesn't even explain the segfaults
19:07:52FromDiscord<Phil> In reply to @bosinski2023 "good catch - i": All I can do is thank mratsim and leorize, otherwise I'd never have figured it out
19:08:17FromDiscord<polylokh_39446> In reply to @nocturn9x "because there is no": the next alternative is probably to reuse the threads, so that these leaks don't matter.
19:08:21FromDiscord<Phil> In reply to @Elegantbeef "I don't think it'd": Honestly that one is mildly beyond me
19:08:34FromDiscord<nocturn9x> In reply to @polylokh_39446 "the next alternative is": I suppose
19:08:43FromDiscord<Phil> And by mildly I mean very
19:10:09FromDiscord<bosinski2023> @nocturn9x but your current problem has more to do with - maybe ARC decided to release your session-object - and you get `nil`..
19:10:17FromDiscord<nocturn9x> nope
19:10:18FromDiscord<nocturn9x> it's not nil
19:10:20FromDiscord<nocturn9x> I checked
19:10:34FromDiscord<nocturn9x> unless it's releasing it inside its own machinery, after I can see it
19:10:41FromDiscord<nocturn9x> in which case arc is even more broken than I thought
19:11:36FromDiscord<nocturn9x> also
19:11:39FromDiscord<nocturn9x> if I call `joinThread`
19:11:43FromDiscord<nocturn9x> it also segfaults
19:11:46FromDiscord<nocturn9x> _thanks nim_
19:11:52FromDiscord<polylokh_39446> the general complaint is a familiar one, though. Nim has a clear "main features"/"experimental features" division in the docs, with opt-in for definitely broken stuff like viewtypes, but this doesn't go far enough. I'd like a "the language that's been heavily tested and works"/"shaky stuff"/"experimental" division, so that I can at least know what I'm increasing my likelihood of having to create a bunch of github issues.
19:12:09FromDiscord<bosinski2023> In reply to @nocturn9x "in which case arc": from your last trace it seem your code fucks up in 594 `listRemove` ? with `nil`-access ?
19:12:18FromDiscord<nocturn9x> yeah that's nim's internal stuff
19:12:21FromDiscord<nocturn9x> also the traceback is wrong
19:12:25FromDiscord<nocturn9x> there is no line 49 in bestMove
19:12:29FromDiscord<nocturn9x> it starts at line 292
19:12:36FromDiscord<nocturn9x> would be pretty hard to have a line 49 in there
19:12:47FromDiscord<Phil> In reply to @polylokh_39446 "the general complaint is": It is not all that clear though that multithreading itself is basically "do not use for your own sanity"
19:12:59FromDiscord<nocturn9x> question
19:13:04FromDiscord<nocturn9x> would -d:useMalloc change any of that
19:13:10FromDiscord<Elegantbeef> Yea phil it's all in cgen land so it's not anywhere I'm used too
19:13:11FromDiscord<Elegantbeef> to\
19:13:18FromDiscord<bosinski2023> In reply to @nocturn9x "would -d:useMalloc change any": maybe - try it !
19:13:21FromDiscord<nocturn9x> In reply to @isofruit "It is not all": also considering it's a basic ass fucking feature of a systems programming language
19:13:27FromDiscord<nocturn9x> you'd expect it to, you know, work?
19:13:37FromDiscord<Elegantbeef> Asking @jmgomez very nicely to generate a proc that destroys all `threadVar`s would probably be the route 😄
19:13:42FromDiscord<nocturn9x> how can nim even claim to be a systems programming language and NOT have working threads
19:13:46FromDiscord<nocturn9x> like this is worse than C
19:13:50FromDiscord<nocturn9x> and C has `pthread_create`
19:14:00FromDiscord<nocturn9x> how do you fuck up so royally
19:14:19FromDiscord<nocturn9x> how long has nim existed for, well over a decade?
19:14:46FromDiscord<polylokh_39446> In reply to @nocturn9x "you'd expect it to,": my impression is that this is a case where it did "just work" but had opinionated limits that people didn't like enough that's now a shakier part of the language. The old idea was no sharing at all between threads.
19:14:48FromDiscord<nocturn9x> these feel like issues I'd have with a 2 year old language, not one whose first design spec is from 2009
19:14:57FromDiscord<nocturn9x> (edit) "these feel like issues I'd have with a 2 year old language, not one whose first design spec is from 2009 ... " added "or something"
19:15:20FromDiscord<nocturn9x> maybe instead of adding features over features there should be a focus on fixing the clearly broken stuff
19:15:48FromDiscord<polylokh_39446> (edit) "that's" => "that it's"
19:15:57FromDiscord<nocturn9x> but the existence of nimskull proves araq doesn't give two shits about the language actually being stable and usable
19:16:00FromDiscord<nocturn9x> (edit) "but the existence of nimskull proves araq doesn't give two shits about the language actually being stable and usable ... " added "so whatever"
19:16:57FromDiscord<leorize> did you move an arc pointer across threads?
19:17:08FromDiscord<nocturn9x> yeah, using `atomicArc`
19:17:15FromDiscord<nocturn9x> (edit) "`atomicArc`" => "`--mm:atomicArc`"
19:17:33FromDiscord<bosinski2023> In reply to @polylokh_39446 "my impression is that": that is my impression, too. shared memory + threads is not very popular in nim-land. But all my data-structure-stuff with atomics & threads runs well - but i stay from ARC/ORC for core-mem-structures..
19:18:07FromDiscord<leorize> generics work until you try to employ it, nim stuff
19:18:22FromDiscord<leorize> if you can link your trace here I can help
19:18:25FromDiscord<leorize> but always use `-d:useMalloc`, the nim allocator has internal races
19:18:51FromDiscord<nocturn9x> yes, that appears to fix it
19:19:04FromDiscord<nocturn9x> it also makes the code measurably slower but at least it works
19:19:25FromDiscord<nocturn9x> why would one rewrite an allocator if they clearly aren't capable of doing it properly is a question for another day
19:19:26FromDiscord<bosinski2023> In reply to @nocturn9x "it also makes the": thats good news :))
19:20:12FromDiscord<Phil> -d:useMalloc when multithreading is one of those "uncommunicated must-haves"
19:20:13*def- quit (Quit: -)
19:20:15FromDiscord<leorize> that'd only work if channels work
19:20:18FromDiscord<leorize> and channels are... funny
19:20:20FromDiscord<Phil> Which, tbf, I forgot about
19:21:20FromDiscord<nocturn9x> the thing that comforts me about this
19:21:36FromDiscord<nocturn9x> is that before dealing with this I thought my own language wouldn't be able to compete with nim
19:21:40FromDiscord<nocturn9x> oh BOY was I wrong
19:21:55*def- joined #nim
19:21:57FromDiscord<nocturn9x> even if it might not go as fast, it'll surely not be this broken when it comes to basic features
19:22:27FromDiscord<nocturn9x> never have I felt this much frustrated and deprived of all the time I spent learning a new tool lol
19:23:48FromDiscord<nocturn9x> (edit) "this much" => "so"
19:23:58FromDiscord<Elegantbeef> Window's malloc bad
19:24:32FromDiscord<nocturn9x> good thing I daily drive linux hen
19:24:34FromDiscord<nocturn9x> (edit) "hen" => "then"
19:24:59FromDiscord<nocturn9x> note to self: never do anything with threads in nim ever again
19:25:14FromDiscord<nocturn9x> I _dread_ the time when I'll have to implement parallel search. That will surely be fun.
19:25:16FromDiscord<bosinski2023> In reply to @nocturn9x "even if it might": `atomicARC` is relaively new. Just to be able to troubleshoot ARC/atomicARC problems i took the arena-alloc from the `fusion`-repo, added two lines to make the allocation thread-safe with `std/atomics`. Since then i'm relaxed..
19:25:27FromDiscord<polylokh_39446> there are neat parts that are hard to compete with. Arc when it works. Effect and exception tracking. The allocator that you just saw a performance hit from moving away from. But the go/jai trend is away from this anyway.
19:25:58FromDiscord<nocturn9x> performance is meaningless if your code segfaults randomly for no apparent reason or fault of yourd
19:26:00FromDiscord<nocturn9x> (edit) "yourd" => "yours"
19:26:14FromDiscord<nocturn9x> "well I mean it segfaults really fast"
19:26:23FromDiscord<nocturn9x> that is not an argument, it's pure madness
19:26:26FromDiscord<leorize> you should try nimskull \:p
19:26:33FromDiscord<nocturn9x> is that even up to date
19:28:03*beholders_eye joined #nim
19:28:21FromDiscord<leorize> nim code is fast y'know
19:28:24FromDiscord<leorize> crash faster than anything I've ever written
19:28:32FromDiscord<nocturn9x> same
19:29:35FromDiscord<polylokh_39446> If your language has automatically managed memory but you don't want to take the hit of implementing something like Arc, then spooky stuff's still possible: <https://forum.dlang.org/post/[email protected]> . Crashes that happen because the only reference to an object was in a register, and the object got collected.
19:30:15FromDiscord<nocturn9x> what I plan to implement is generational references
19:30:24FromDiscord<nocturn9x> which is basically fancy weak references with some cheap runtime checks
19:30:28FromDiscord<nocturn9x> most of which will be elided
19:30:33FromDiscord<nocturn9x> that + regions with single ownership
19:30:41FromDiscord<polylokh_39446> Nim code that's written in the undocumented solid subset of the language is just fast, and not "crashes fast".
19:30:48FromDiscord<nocturn9x> so you can have mutable references for when you need that semantics
19:30:57FromDiscord<nocturn9x> (edit) "semantics" => "semantic"
19:31:08FromDiscord<polylokh_39446> for a start I'd like thta subset documented. I think that's easier than writing another language.
19:31:20FromDiscord<polylokh_39446> (edit) "thta" => "that"
19:31:30FromDiscord<nocturn9x> well complain to the guy who keeps adding piles of crap on top of the already huge pile of crap
19:32:19FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=gJwfJUEPiODb
19:32:25FromDiscord<nocturn9x> wanna guess which one is using malloc?
19:32:36FromDiscord<leorize> write nim like you write C, that's how you get solid nim code
19:32:36FromDiscord<leorize> that's also a big argument to just write rust and be done with it
19:32:38FromDiscord<nocturn9x> All the performance work I had done has basically evaporated
19:32:45FromDiscord<nocturn9x> _thanks nim_
19:32:55FromDiscord<System64 ~ Flandre Scarlet> Hi, does Nim supports hot reloading out of the box?
19:33:07FromDiscord<nocturn9x> nim doesn't support anything
19:33:09FromDiscord<nocturn9x> pray that it works
19:33:12FromDiscord<nocturn9x> it may work
19:33:13FromDiscord<nocturn9x> it may not
19:33:21FromDiscord<leorize> hot code reloading is practically untested
19:33:26FromDiscord<nocturn9x> is anything tested
19:33:33FromDiscord<nocturn9x> beyond toy level stuff
19:33:34FromDiscord<bosinski2023> In reply to @sys64 "Hi, does Nim supports": yes, its in the `experimental`-box..
19:33:38FromDiscord<nocturn9x> because it doesn't feel like it
19:33:40FromDiscord<nocturn9x> at all
19:33:50FromDiscord<System64 ~ Flandre Scarlet> In reply to @bosinski2023 "yes, its in the": So probably unstable?
19:33:53FromDiscord<nocturn9x> I have over 6000 lines of code written for my compiler and it's all nim
19:34:06FromDiscord<leorize> In reply to @sys64 "So probably unstable?": probably unusable
19:34:08*def- quit (Quit: -)
19:34:10FromDiscord<System64 ~ Flandre Scarlet> OOF
19:34:15FromDiscord<nocturn9x> In reply to @nocturn9x "I have over 6000": and now I'm terrified
19:34:24FromDiscord<nocturn9x> of working on it more
19:34:31FromDiscord<Elegantbeef> HCR exists but it explodes and kills dogs
19:34:31FromDiscord<bosinski2023> In reply to @sys64 "So probably unstable?": i've not tried - but it might have issues - seen some Q&As in the forums..
19:34:35FromDiscord<tsoj> You know, the whole world runs on C++
19:34:44FromDiscord<tsoj> despite all its footguns
19:34:47FromDiscord<System64 ~ Flandre Scarlet> In reply to @tsoj "You know, the whole": Including the Matrix??!!!
19:34:49FromDiscord<polylokh_39446> In reply to @sys64 "Hi, does Nim supports": it exists: <https://nim-lang.org/docs/hcr.html> . I doubt its tires have been kicked much.
19:34:59FromDiscord<Elegantbeef> I'd more so say to use DLLs or WASM for HCR
19:35:11FromDiscord<leorize> or at all, tbf
19:35:28FromDiscord<Elegantbeef> Not the same but it's more likely to work over Nim's HCR
19:35:29FromDiscord<leorize> HCR is a layer of hack on top of C gen that barely works, is how I view this stuff
19:35:46FromDiscord<polylokh_39446> or for the full hot loading experience, write that part in Erlang and use <https://github.com/wltsmrz/nimler> to get Nim doing the slow parts.
19:35:48FromDiscord<ieltan> I've been reading up on this channel and man...
19:35:49FromDiscord<leorize> beef\: the discord lag strikes again
19:36:14FromDiscord<nocturn9x> In reply to @ieltan "I've been reading up": I know right
19:36:26FromDiscord<nocturn9x> nim is a textbook example of how _not_ to schedule priorities for a language
19:36:29FromDiscord<leorize> In reply to @nocturn9x "I have over 6000": use nimskull :p
19:36:33FromDiscord<Phil> There's a ton of really good design decisions I like in nim.↵But multithreading is absolutely a weakpoint
19:36:33FromDiscord<leorize> totally not a biased opinion
19:36:47FromDiscord<nocturn9x> "ah yes let's get this cool new memory model into the compiler before threads are even fully working"
19:36:49FromDiscord<ieltan> I wanted to use threads for my library project but that does not make me want to do it lok
19:37:00FromDiscord<nocturn9x> In reply to @leorize "use nimskull :p": does it support nim 2.0
19:37:14FromDiscord<Elegantbeef> Jeez
19:37:14FromDiscord<Elegantbeef> That's some lag
19:37:59FromDiscord<leorize> In reply to @nocturn9x "does it support nim": it can do 1.6 plus a few extensions
19:38:36FromDiscord<leorize> if you use linux, there's a plugin for asdf/mise to quickly install it: https://github.com/nim-works/asdf-nimskull
19:38:38FromDiscord<tsoj> what is the threading like compared to nim?
19:39:08FromDiscord<ieltan> All I've ever seen nimskull used for was for CPS development
19:39:15FromDiscord<nocturn9x> In reply to @leorize "it can do 1.6": so no
19:39:20FromDiscord<nocturn9x> a shame
19:39:23FromDiscord<nocturn9x> I like the new top down inference
19:40:23FromDiscord<polylokh_39446> IMO Nim has just had unbalanced core devs for a long time. There's no way to talk about that without probably starting to slander one person, but the current state looks a lot better to me. Araq is still doing cool stuff that's very hard to compete with, and Ringabout's fixing tons of stuff, and docs are getting improved.
19:41:15FromDiscord<polylokh_39446> but this current state is only a few years old
19:41:17FromDiscord<nocturn9x> I considered contributing at one time
19:41:24FromDiscord<nocturn9x> then I looked at the compiler code
19:41:25FromDiscord<leorize> gee I wonder why nim had unbalanced core devs
19:41:26FromDiscord<nocturn9x> and changed my mind.
19:41:36FromDiscord<nocturn9x> In reply to @leorize "gee I wonder why": let me gues
19:41:38FromDiscord<nocturn9x> (edit) "gues" => "guess"
19:41:44FromDiscord<nocturn9x> a certain someone going on a power trip
19:41:51FromDiscord<nocturn9x> something something big ego
19:42:18FromDiscord<leorize> I wish it was that simple
19:42:23FromDiscord<nocturn9x> "cool stuff" is cool
19:42:28FromDiscord<nocturn9x> but people like the stuff that works
19:42:40FromDiscord<nocturn9x> "cool" isn't a factor when deciding a language to actually use day to day
19:43:07FromDiscord<polylokh_39446> there needs to be something for a language to be worth using at all, vs. the status quo.
19:43:12FromDiscord<nocturn9x> that's like saying "I have invented this new type of hammer that is worse than a normal hammer in almost every conceivable way except for these fun gimmicks"
19:43:26FromDiscord<tsoj> There is a reason though why people use Nim
19:43:45FromDiscord<tsoj> despite it bugs
19:43:46FromDiscord<nocturn9x> it's fast as fuck, it has that
19:43:56FromDiscord<nocturn9x> and it's better than C for most things
19:44:21FromDiscord<tsoj> It's better at quite a few things compared to alternatives such as Rust, C++ or python
19:44:22FromDiscord<nocturn9x> but you know, when I have to lose almost 20 million nodes per second on my chess movegen because the default allocator has data races
19:44:27FromDiscord<threefour> It's a systems language that isn't overly-verbose like a systems language. That alone is worth a lot, and I don't actually know any other decent competitors.
19:44:29FromDiscord<nocturn9x> that tends to not make me like the language a lot
19:44:52FromDiscord<nocturn9x> In reply to @threefour "It's a systems language": it's also a system language that leaks thread variables
19:45:05FromDiscord<nocturn9x> which is just hilarious
19:45:44FromDiscord<nocturn9x> that's like one of the basic features of a systems language, good paralleliism
19:45:46FromDiscord<nocturn9x> (edit) "paralleliism" => "parallelism"
19:45:48FromDiscord<leorize> clean syntax, easily extensible with macros, all points that are still uncontested
19:45:49FromDiscord<nocturn9x> nim doesn't have that
19:46:00FromDiscord<nocturn9x> not even good
19:46:02FromDiscord<nocturn9x> but at least usable
19:46:06FromDiscord<nocturn9x> this is hot garbage lol
19:46:10FromDiscord<leorize> the implementation is just hot garbage
19:46:17FromDiscord<nocturn9x> that's what "this" is
19:46:26FromDiscord<ieltan> afaik mratsim is the threading guy, maybe he knows a trick or two to get thru this silly stuff
19:46:48FromDiscord<bosinski2023> In reply to @threefour "It's a systems language": Mojo might become a thing some day..
19:47:23FromDiscord<ieltan> Mojo looks like rust pretending to be python 😅
19:48:14FromDiscord<ieltan> Those people coming from python will have one hell of a reality check when mojo actually becomes a thing
19:48:18FromDiscord<bosinski2023> In reply to @ieltan "Mojo looks like rust": well i like python, but the guy Chris Lattner has a series of well-done things going one.
19:48:24FromDiscord<tsoj> In reply to @ieltan "afaik mratsim is the": I mean, the workaround for this specific bug is to use `-d:useMalloc` but that leave 20 mnps for perft on the road (even though that won't matter with any kind of competetive eval).
19:49:42FromDiscord<leorize> you can link with mimalloc and hope to claw some performance back
19:49:52FromDiscord<nocturn9x> I was thinking about that
19:49:56FromDiscord<nocturn9x> how would I do that
19:50:07FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=bOcCVyeKbrRb
19:50:12FromDiscord<nocturn9x> this is with malloc and refc
19:50:20FromDiscord<nocturn9x> so it's arc that's slow as fuck
19:50:38FromDiscord<leorize> refc is not thread safe, fwiw
19:50:39FromDiscord<threefour> I haven't really looked at Mojo, admittedly. Heard it mentioned on HN that it's not even open-source, and stopped there. But honestly, Nim looking kind of like Python isn't why I picked it up in the first place, and therefore Mojo isn't that interesting to me.
19:50:45FromDiscord<bosinski2023> In reply to @ieltan "Those people coming from": yes, the reality will then be - reuse your old python code in a single-thread. But beeing able to have new code running alongside the old - with new things to learn for sure..
19:50:47FromDiscord<nocturn9x> In reply to @leorize "refc is not thread": yeah I know I was just saying
19:51:01FromDiscord<nocturn9x> _neither is ARC_
19:51:08FromDiscord<nocturn9x> except at least refc is not thread safe by design
19:51:12FromDiscord<nocturn9x> ACR is just borked.
19:51:21FromDiscord<nocturn9x> (edit) "ACR" => "ARC"
19:51:28FromDiscord<leorize> arc design is good tbf
19:51:34FromDiscord<nocturn9x> I don't deny it
19:51:39FromDiscord<nocturn9x> but designs don't run on computers
19:51:42FromDiscord<nocturn9x> implementations di
19:51:43FromDiscord<nocturn9x> (edit) "di" => "do"
19:51:44*def- joined #nim
19:51:47FromDiscord<nocturn9x> and the implementation _sucks_
19:51:54FromDiscord<leorize> you should try to see if your code compile with skull at least
19:52:00*beholders_eye quit (Ping timeout: 252 seconds)
19:52:01FromDiscord<bosinski2023> In reply to @nocturn9x "ARC is just borked.": ARC is a well-performing beast - i like it, but again - one cannot deal with ARC - it just does what it does..
19:52:15FromDiscord<nocturn9x> it almost certainly won't just because I use top down inference all over the place
19:52:44FromDiscord<nocturn9x> https://github.com/Yardanico/mimalloc_nim
19:52:47FromDiscord<nocturn9x> how functional is that
19:53:06FromDiscord<bosinski2023> In reply to @nocturn9x "https://github.com/Yardanico/mimalloc_nim": MS-labs - good stuff...
19:53:11FromDiscord<threefour> I haven't delved into threading for my HTTP framework yet (optimizing in single core first), so I'm curious: is your problem a _hard_ bug in ARC that makes implementing multithreading completely unreliable? Or is it only unstable because of your specific approach?
19:53:17FromDiscord<leorize> just install mimalloc on your compiler and `--passL:-lmimalloc`
19:53:23FromDiscord<nocturn9x> In reply to @leorize "just install mimalloc on": k
19:53:24FromDiscord<threefour> Not insulting your approach, just making a distinction.
19:53:35FromDiscord<nocturn9x> In reply to @threefour "Not insulting your approach,": dw you can insult my approach
19:53:35FromDiscord<leorize> (edit) "compiler" => "computer"
19:53:38FromDiscord<nocturn9x> it's probably not the best
19:53:44FromDiscord<nocturn9x> but the thing is, it's not my code that's segfaulting
19:53:48FromDiscord<nocturn9x> it's nim's allocator
19:54:00FromDiscord<nocturn9x> the problem is a hard bug in ARC, yes
19:54:05FromDiscord<nocturn9x> in fact there is _two_
19:54:19FromDiscord<tsoj> In reply to @nocturn9x "k": Honestly I wouldn't bother with stuff like mimalloc. Whether I disable useMalloc or enabled it makes no difference in Nalwald..
19:54:32FromDiscord<nocturn9x> In reply to @tsoj "Honestly I wouldn't bother": you're doing pseudolegal in nalwald afaik
19:54:33FromDiscord<leorize> for the most part, it's just that arc not being atomic messes up ref counting when you move references
19:54:42FromDiscord<nocturn9x> In reply to @leorize "for the most part,": which makes sense
19:54:43FromDiscord<nocturn9x> but then
19:54:53FromDiscord<nocturn9x> I would expect `--mm:atomicArc`
19:54:54FromDiscord<tsoj> In reply to @nocturn9x "you're doing pseudolegal in": Genrally the movegen will be at most like 10% of your engine
19:54:56FromDiscord<nocturn9x> to, you know
19:54:57FromDiscord<nocturn9x> be atomic?
19:55:04FromDiscord<leorize> is that tested?
19:55:11FromDiscord<nocturn9x> good question
19:55:14FromDiscord<nocturn9x> clearly not
19:55:18FromDiscord<nocturn9x> (edit) "clearly not ... " added "(enough)"
19:56:06FromDiscord<threefour> I guess I mean: is ARC completely broken for multithreading purposes, or is there a "proper" way to use it, that makes it work reliably?
19:56:30FromDiscord<leorize> for nimskull we have projects that spawn 1B lw threads to stress test this with all kind of sanitizers/grind on with good results
19:56:33FromDiscord<nocturn9x> the proper way to use it is pray
19:56:40FromDiscord<leorize> you just need to hold nim's hand really well
19:56:40FromDiscord<threefour> Lmao
19:56:57FromDiscord<nocturn9x> In reply to @leorize "you just need to": and hope ARC doesn't just destroy your refs
19:56:58FromDiscord<polylokh_39446> the other thing to do, holding Nim's implementation constant, is to change your approach to not pass refs between threads. You could allocate the shared memory ahead of time and pass indices into it. (That's "doing Rust" rather than "doing C" btw)
19:57:02FromDiscord<nocturn9x> refs which it should NOT own by the way
19:57:22FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=rtqTCSEApHhd
19:57:26FromDiscord<nocturn9x> mimalloc is great at least
19:57:36FromDiscord<nocturn9x> In reply to @polylokh_39446 "the other thing to": that's annoying and stupid
19:57:43FromDiscord<nocturn9x> I'd use Rust if I wanted to do it the rust way
19:57:47FromDiscord<nocturn9x> I'm using nim for a reason
19:57:54FromDiscord<nocturn9x> but that would be a solution I guess
19:58:36FromDiscord<tsoj> sent a code paste, see https://play.nim-lang.org/#pasty=aDScLhYmuJEA
19:58:45FromDiscord<nocturn9x> yes, that too.
19:58:56FromDiscord<nocturn9x> and the fun shit is it doesn't matter if _you_ don't use any threadvars
19:59:00FromDiscord<nocturn9x> so long as any of your dependencies
19:59:02FromDiscord<nocturn9x> direct or indirect
19:59:05FromDiscord<nocturn9x> are using threadvars
19:59:08FromDiscord<nocturn9x> then your code leaks memory
19:59:12FromDiscord<nocturn9x> isn't that GREAT?↵ù
19:59:15FromDiscord<nocturn9x> (edit) "GREAT?↵ù" => "GREAT?"
20:00:16FromDiscord<nocturn9x> In reply to @tsoj "passing refs between threads": lmfao that actually reproduces the issue perfectly
20:00:21FromDiscord<nocturn9x> it leaks gigabytes of RAM basically immediately
20:00:25FromDiscord<nocturn9x> and that's in _debug mode_
20:01:03FromDiscord<tsoj> I could make it leak terabytes if i wanted to, but that wouldn't really be a challend
20:01:05FromDiscord<tsoj> (edit) "challend" => "challenge"
20:01:13FromDiscord<nocturn9x> mfw oom_killer
20:01:15FromDiscord<nocturn9x> (edit) "oom_killer" => "oom_killer:"
20:01:33FromDiscord<tsoj> you assume I don't have 10 TB RAM?
20:01:36FromDiscord<polylokh_39446> In reply to @polylokh_39446 "the next alternative is": ^ yep, but that also has a change-your-approach solution. It's much less irritating to know that some approaches are bad before you write 3000 lines of code though.
20:01:47FromDiscord<nocturn9x> In reply to @polylokh_39446 "^ yep, but that": yeah, that
20:01:56FromDiscord<nocturn9x> would've loved to know that _before_ I wrote a chess engine in it
20:02:04FromDiscord<nocturn9x> and like other 15 thousand lines of code in other projects
20:02:10FromDiscord<nocturn9x> but hey better late than never am I right
20:02:38FromDiscord<nocturn9x> and keep in mind I've reduced refs to almost zero
20:02:41FromDiscord<tsoj> Which language do you wanna use now?
20:02:45FromDiscord<polylokh_39446> that's why I want documentation on what parts of Nim are actually solid. It doesn't require any coding or any dev time but it'd save a lot of dev time.
20:02:45FromDiscord<nocturn9x> there's like, actually 2 or 3 refs in the entire program
20:02:45FromDiscord<bosinski2023> sent a code paste, see https://play.nim-lang.org/#pasty=xhCYZwDEXhOl
20:03:07FromDiscord<nocturn9x> In reply to @tsoj "Which language do you": if the issue is fixed, then I will just stick with nim
20:03:13FromDiscord<nocturn9x> way too much work to redo this
20:03:17FromDiscord<nocturn9x> (edit) "this" => "all the movegen"
20:03:30FromDiscord<nocturn9x> mimalloc gave me the performance back
20:03:33FromDiscord<tsoj> sent a code paste, see https://play.nim-lang.org/#pasty=twUrgAAFgvqP
20:03:47FromDiscord<tsoj> i.e. it's at least "effectively" a memory leak
20:03:50FromDiscord<threefour> In reply to @polylokh_39446 "that's why I want": Agreed. I picked up Nim about a month ago, and it was very clear from the beginning that it's not stable in all aspects. Knowing what I can rely on, and what I can't, would be really helpful.
20:03:59FromDiscord<leorize> if mimalloc solves it for you then it sounds like you just need a memory pool
20:04:18FromDiscord<bosinski2023> In reply to @leorize "if mimalloc solves it": exactly
20:04:58FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=XmcNlZmIkaRp
20:05:38FromDiscord<nocturn9x> In reply to @leorize "if mimalloc solves it": it sounds like I need a language that works >:D
20:06:17FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=mHMaMOWOlHyv
20:07:06FromDiscord<Elegantbeef> To be fair `joinThread` is just to block until a thread is done, when a thread is done it should destruct it's resources
20:08:46FromDiscord<tsoj> In reply to @nocturn9x "way too much work": Well, now is the best time to decide that, because you have to expect running into more Nim bugs. Translating the movegen into C++, Rust, or whatever shouldn't take too long.
20:09:00FromDiscord<nocturn9x> I know neither C++ nor Rust
20:09:14FromDiscord<nocturn9x> nor do I plan on using Rust, the borrow checker can suck it
20:09:18FromDiscord<tsoj> yeah
20:09:28FromDiscord<tsoj> cppfront?
20:09:36FromDiscord<nocturn9x> rust was a very good idea implemented very poorly
20:09:43FromDiscord<nnsee> In reply to @nocturn9x "by "leaks memory" I": you're not looking at virtual memory are you
20:09:48FromDiscord<tsoj> i actually wrote a little move gen in cppfront
20:10:01FromDiscord<nocturn9x> In reply to @nnsee "you're not looking at": I'm not entirely sure what htop is showing there
20:10:06FromDiscord<nocturn9x> it's probably not virtual memory
20:10:23FromDiscord<nocturn9x> the point is nim 100% leaks memory, the issue proves it
20:10:29FromDiscord<nocturn9x> and my problems corroborate it
20:10:34FromDiscord<nnsee> i'm fairly sure it does show virtual memory by default
20:11:11FromDiscord<nnsee> because I've seen other people be like "how can electron use 40G of ram when my machine only has 16G" before
20:11:37FromDiscord<tsoj> When I look at the "RES" column in htop it leak
20:11:38FromDiscord<tsoj> (edit) "leak" => "leaks"
20:12:39FromDiscord<polylokh_39446> threadvar destruction's probably easily fixed. But it's one of those alarming bugs that reveals that the associated code is not really getting used. It's like a guy selling you a car and, when you get in, you realize there's no steering wheel. "Oh, don't worry! The rest of the car is fine, I just missed that!"
20:12:55FromDiscord<bosinski2023> In reply to @nocturn9x "by "leaks memory" I": hmm the test-prog allocs 1000 x 1-MB-array of float64 and mem peaks at 25-MB - thats ok...
20:14:41FromDiscord<nnsee> In reply to @nocturn9x "the point is nim": that's not to say i'm saying you're wrong here
20:14:45FromDiscord<nnsee> it's likely you're right
20:14:54FromDiscord<tsoj> In reply to @polylokh_39446 "threadvar destruction's probably easily": It's maybe because most people don't use the low level `typedthreads` but some kind of threadpool
20:14:54FromDiscord<nnsee> i'm just saying htop can be misleading
20:14:58FromDiscord<nnsee> 12G is alarming
20:15:36FromDiscord<nocturn9x> if it weren't leaking
20:15:39FromDiscord<nocturn9x> it wouldn't be writing to the swap
20:15:41FromDiscord<nocturn9x> which it is
20:15:50FromDiscord<nocturn9x> so the memory is actual physical memory being used
20:15:58FromDiscord<nnsee> sure
20:16:11FromDiscord<Phil> It's less that nim in general leaks and more that the combination of nim + threads requires you to be really damn careful because there's a lot of things that will bite you.↵The statement "nim leaks memory" is a bit too general here.
20:16:33FromDiscord<polylokh_39446> In reply to @tsoj "It's maybe because most": there's certainly an explanation. There are also other ways to use threads where this isn't a problem. But certainly nobody is creating and destroying a lot of threads over the course of a Nim program, or they'd immediately notice this issue.↵↵Likewise the car, the rest of it might be really good. But by seeing the missing steering wheel, you know that the guy telling you the car i
20:17:27FromDiscord<nocturn9x> I have decided I will rewrite my engine entirely in malebolgia
20:17:33FromDiscord<nocturn9x> see you in 2^32 years when I'm done
20:17:39FromDiscord<nocturn9x> (edit) "malebolgia" => "malbolge"
20:17:46FromDiscord<Elegantbeef> "Nim threads do not destruct thread vars and does not call the thread Orc before closing" is the issue here
20:18:00FromDiscord<tsoj> In reply to @nocturn9x "I have decided I": yeah bvefore the edit that was confusing lol
20:18:18FromDiscord<nnsee> In reply to @polylokh_39446 "there's certainly an explanation.": https://media.discordapp.net/attachments/371759389889003532/1236049213603975228/EyYnDywXMAwkcyh.jpg?ex=66369809&is=66354689&hm=2b67919a9d80f228108066d9131791aad2d2d5c13212f123f15c66a1eee50453&
20:18:37FromDiscord<tsoj> In reply to @polylokh_39446 "there's certainly an explanation.": But the guy definitely has driven the car a lot. It's just the he never used the rear windshild wipers
20:19:16FromDiscord<Phil> I just want a backend thread for GUI applications 😢
20:19:21FromDiscord<nocturn9x> In reply to @nnsee "": this but use nim code in the examples
20:20:26FromDiscord<Phil> @odexine I think I got the basics of a reactivex implementation down pat now if you're curious
20:20:31FromDiscord<bosinski2023> In reply to @Elegantbeef ""Nim threads do not": that sounds as if it was not terribly complicated to fix ?
20:20:36FromDiscord<Phil> The answer appears to really just be more closures on top of the closures I was using
20:20:38FromDiscord<Phil> Also more closures
20:20:42FromDiscord<Phil> And did I mention closures?
20:20:48FromDiscord<polylokh_39446> I'm explaining why this class of bug is alarming, but I'm being read as saying that the bug itself is a big deal. I think this bug might be fixed tomorrow.↵↵My personal rule is that unkicked tires are flat. If it's not tested, it's certainly broken. Even if that's not true, it saves me a lot of time to expect that it's true. And this is a bug that suggests that threads aren't thoroughly tested.
20:21:24FromDiscord<Elegantbeef> > that sounds as if it was not terribly complicated to fix ?↵> It's not that complicated it just requires someone that knows the compiler to emit a `proc() = =destroy(threadVar) ....`
20:21:35FromDiscord<Elegantbeef> Whoops
20:22:10FromDiscord<bosinski2023> In reply to @Elegantbeef "> that sounds as": so, we all should be nice with, maybe jmgomez ?
20:22:40FromDiscord<nocturn9x> In reply to @polylokh_39446 "I'm explaining why this": what's alarming isn't the bug itself, I agree
20:22:47FromDiscord<nocturn9x> it's the fact that if this went undetected for so long
20:22:53FromDiscord<nocturn9x> no one is actually using these features
20:22:57FromDiscord<nocturn9x> and no one is testing them properly
20:23:15FromDiscord<ElegantBeef> Matrix bridge dieded
20:23:20FromDiscord<nocturn9x> I wonder how exactly higher level libraries deal with this
20:23:25FromDiscord<nocturn9x> like weave or malebolgia
20:23:27FromDiscord<nocturn9x> do they just leak shit
20:23:29FromDiscord<ElegantBeef> Yea there should be a hellgrind and valgrind test to ensure memory is freed
20:23:35FromDiscord<nocturn9x> how did anyone not notice
20:23:49FromDiscord<ElegantBeef> Not many people have global threadvars is the answer
20:23:52FromDiscord<nocturn9x> or do they not technically leak because they reuse the same thread objects
20:24:00FromDiscord<nocturn9x> In reply to @elegantbeef "Not many people have": _bruh
20:24:01FromDiscord<nocturn9x> (edit) "_bruh" => "_bruh_"
20:24:19FromDiscord<polylokh_39446> Reusing threads is the most natural way to work with them, when you're not using them directly but writing some kind of reactor.
20:24:20FromDiscord<ElegantBeef> Hey I agree with you that it should be well tested
20:24:30FromDiscord<bosinski2023> In reply to @nocturn9x "and no one is": maybe or its more complicated, 'cos i look out for leaks and have never seen some and i use threadlocal vars, that i don't release by hand... maybe i will
20:24:42FromDiscord<ElegantBeef> But the amount of code that has global threadvars that have substantial data I imagine is not that much
20:24:44FromDiscord<ElegantBeef> I could be wrong
20:24:54FromDiscord<nocturn9x> oh
20:25:02FromDiscord<nocturn9x> there is a nim talk at the pycon I'm going to this month
20:25:06FromDiscord<nocturn9x> it's gonna be _fun_
20:25:11FromDiscord<tsoj> What exactly is meant with "global threadvars"?
20:25:15FromDiscord<Phil> If you touch dateTimes or async you have threadvars.↵Which means logging has threadvars.↵That's about it what I'm aware of
20:25:23FromDiscord<nocturn9x> In reply to @tsoj "What exactly is meant": a global variable marked with the thread pragma
20:25:27FromDiscord<ElegantBeef> A global threadvar is a global variable that is unique per thread
20:25:37FromDiscord<ElegantBeef> This is not properly destructed and leaks
20:25:47FromDiscord<nocturn9x> no, it's not improperly destructed
20:25:51FromDiscord<nocturn9x> or rather, destroyed
20:25:51FromDiscord<polylokh_39446> In reply to @tsoj "What exactly is meant": <https://github.com/nim-lang/Nim/issues/23165> mentions two in the edit
20:25:54FromDiscord<nocturn9x> it's not destroyed at all
20:25:58FromDiscord<ElegantBeef> Who s aid it is properly destructed?
20:26:01FromDiscord<ElegantBeef> (edit) "s aid" => "said"
20:26:05FromDiscord<bosinski2023> In reply to @elegantbeef "A global threadvar is": is that possible at all ?
20:26:12FromDiscord<nocturn9x> for something to be done improperly
20:26:15FromDiscord<nocturn9x> something has to be done
20:26:19FromDiscord<nocturn9x> nim is doing exactly fuck all
20:26:21FromDiscord<Phil> In reply to @polylokh_39446 "<https://github.com/nim-lang/Nim/issues/23165> ment": When assigning a var destroy is called
20:26:23FromDiscord<tsoj> sent a code paste, see https://play.nim-lang.org/#pasty=ZPTiXSgWLGnX
20:26:25FromDiscord<ElegantBeef> Which is not properly destructing
20:26:26FromDiscord<Phil> That doesn't quite count
20:26:37FromDiscord<ElegantBeef> Properly destructing would be to call `=destroy`
20:26:49FromDiscord<ElegantBeef> No that's not a threadvar
20:27:03FromDiscord<polylokh_39446> <https://nim-lang.org/docs/manual.html#threads-threadvar-pragma> ↵`var checkpoints {.threadvar.}: seq[string]`
20:27:20FromDiscord<tsoj> well, but that example leaks too
20:27:22FromDiscord<ElegantBeef> sent a code paste, see https://play.nim-lang.org/#pasty=RkbCbTamqetp
20:27:45FromDiscord<Phil> In reply to @tsoj "well, but that example": Likely just needs you to call the GC of that thread which is a threadvar
20:27:55FromDiscord<bosinski2023> sent a code paste, see https://play.nim-lang.org/#pasty=JMRrBnKtVDMq
20:28:15FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=DrtnfyasMRHT
20:28:20FromDiscord<ElegantBeef> In reply to @tsoj "But is `l` here": `All heap blocks were freed -- no leaks are possible`
20:28:32FromDiscord<ElegantBeef> If you're going to say something is leaking atleast test it
20:29:02FromDiscord<ElegantBeef> `nim c -d:useMalloc yourProg` `valgrind yourProg`
20:29:19FromDiscord<tsoj> i mean yeah, -d:useMalloc fixes it
20:29:21FromDiscord<nocturn9x> well well well
20:29:27FromDiscord<nocturn9x> looks like it ain't leaking anymore
20:29:27FromDiscord<ElegantBeef> Then it's not leaking
20:29:39FromDiscord<nocturn9x> it is segfaulting though
20:29:44FromDiscord<nocturn9x> thanks nim lovely
20:29:49FromDiscord<tsoj> Well, but why will it use swap if I doN#t have enough memory?
20:30:02FromDiscord<ElegantBeef> Cause Nim's allocator sucks
20:30:06FromDiscord<ElegantBeef> It has multiple issues
20:30:14FromDiscord<tsoj> yeah, but that I call leaking memory
20:30:22*def- quit (Quit: -)
20:30:28FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=pYckVlbMHqfL
20:30:31FromDiscord<ElegantBeef> It's unrelated to threading and just issues with the allocator
20:30:40FromDiscord<ElegantBeef> `useMalloc` is the path to sanity
20:30:52FromDiscord<tsoj> In reply to @elegantbeef "It's unrelated to threading": Ahh I see
20:30:52FromDiscord<nocturn9x> okay admittedly that was my fault
20:30:54FromDiscord<nocturn9x> was using refc
20:30:59FromDiscord<nocturn9x> upsie
20:31:32FromDiscord<tsoj> In reply to @elegantbeef "It's unrelated to threading": what issue is that specifically? is that documented somewhere?
20:31:34FromDiscord<nocturn9x> yeah no more leaks it seems like
20:31:41FromDiscord<nocturn9x> In reply to @tsoj "what issue is that": ha
20:31:43FromDiscord<nocturn9x> haha
20:31:44FromDiscord<nocturn9x> hahahaha
20:31:47FromDiscord<nocturn9x> documented
20:31:51FromDiscord<nocturn9x> funny words magic man
20:31:53FromDiscord<ElegantBeef> I think there is an issue started by guzba about the allocator
20:32:13FromDiscord<ElegantBeef> There is also a post suggesting to use malloc for the time being on 2.0
20:32:21FromDiscord<ElegantBeef> Why it's not the default then in 2.0.4 is beyond me
20:32:29FromDiscord<nocturn9x> it is beyond me as well
20:32:39FromDiscord<nocturn9x> especially considering mimalloc makes it fast
20:32:59FromDiscord<ElegantBeef> Araq just wants to use his TLSF allocator for not good reason when mimalloc exists
20:33:04FromDiscord<tsoj> I remember now, I had this issue already in 1.5 or so, but I didn't connect it to this because I was focused in the thread conection
20:33:13FromDiscord<nocturn9x> In reply to @elegantbeef "Araq just wants to": I know the reason
20:33:15FromDiscord<nocturn9x> it's called NIH
20:33:21FromDiscord<tsoj> this is why I have -d:useMalloc in Nalwald in the first palce
20:33:22FromDiscord<ElegantBeef> "No good reason"
20:33:23FromDiscord<nocturn9x> araq clearly suffers from a severe case of NIH syndrome
20:33:37FromDiscord<nocturn9x> In reply to @elegantbeef ""No good reason"": if you talk with a fool, they'll think you're the fool
20:33:42FromDiscord<nocturn9x> good is very subjective here, clearly
20:33:47FromDiscord<polylokh_39446> this one <https://github.com/nim-lang/Nim/issues/22510> ?
20:33:57FromDiscord<ElegantBeef> Yea
20:34:43FromDiscord<ElegantBeef> The issue comes down to the allocator not reusing blocks(or pages) and just allocating more
20:34:51FromDiscord<nocturn9x> what
20:34:57FromDiscord<nocturn9x> isn't that like the whole purpose of an allocator
20:35:03FromDiscord<nocturn9x> to efficiently manage memory
20:35:04FromDiscord<ElegantBeef> It's supposed to reuse them
20:35:10FromDiscord<ElegantBeef> But it does not
20:35:13FromDiscord<nocturn9x> _cool_
20:35:19FromDiscord<nocturn9x> any known reason why?
20:35:20FromDiscord<ElegantBeef> <https://github.com/nim-lang/Nim/commit/a41b4fa3eed74b4ffbfb97c3c049ec9c87c73012>
20:35:37FromDiscord<polylokh_39446> probably some idea like having better cache coherence for each individual thread
20:35:47FromDiscord<ElegantBeef> It's not intentional
20:35:49FromDiscord<nocturn9x> ah, compensateCounters
20:35:54FromDiscord<nocturn9x> the fucker was segfaulting my code before
20:35:57FromDiscord<ElegantBeef> It's a bug in the Nim TSLF implementation
20:36:38FromDiscord<bosinski2023> In reply to @elegantbeef "It's a bug in": is reuse deferred or not happening at all ?
20:36:43FromDiscord<ElegantBeef> tlsf 😄
20:37:03FromDiscord<ElegantBeef> It happens, but only for small allocations
20:37:07FromDiscord<nocturn9x> sent a long message, see https://pasty.ee/zjQWQFtLnHIC
20:37:08FromDiscord<nocturn9x> _rofl_
20:37:09FromDiscord<ElegantBeef> Larger allocations are causing issues
20:37:18FromDiscord<nocturn9x> doesn't seem like the only borked impl
20:37:22FromDiscord<nocturn9x> but hey at least that's documented
20:38:04FromDiscord<nocturn9x> cool another segfault
20:38:10FromDiscord<nocturn9x> not my fault this time
20:39:26FromDiscord<nocturn9x> I am so done with Nim
20:49:42FromDiscord<tsoj> In reply to @nocturn9x "not my fault this": What is it this time?
20:49:54FromDiscord<nocturn9x> I HAVE NO IDEA
20:49:55*def- joined #nim
20:49:56FromDiscord<Phil> On the bright side of things... somebody want to write docs for rex?
20:50:26FromDiscord<Phil> I mean, I'll likely end up doing it myself anyway. But hey, can't hurt to ask
20:50:28FromDiscord<Elegantbeef> We don't do that here
20:50:44FromDiscord<tsoj> In reply to @nocturn9x "I HAVE NO IDEA": How do you know if it's Nim then?
20:50:51FromDiscord<nocturn9x> because it wasn't doing it before
20:50:55FromDiscord<nocturn9x> and it's doing it now
20:50:55FromDiscord<Phil> That must be a very exclusionary we because I do that here very much
20:50:59FromDiscord<nocturn9x> only thing that changed is the options
20:51:02FromDiscord<nocturn9x> (edit) "only thing that changed is the ... options" added "compilation"
20:51:16FromDiscord<tsoj> In reply to @tsoj "Well, now is the": Also^
20:51:28FromDiscord<tsoj> In reply to @nocturn9x "only thing that changed": what did you cange?
20:51:43FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=AbAxzVzzYWrH
20:51:45FromDiscord<nocturn9x> this is my nim.cfg
20:51:59*disso-peach quit (Quit: Leaving)
20:51:59FromDiscord<nocturn9x> I only added `-d:useMalloc` and `-lmimalloc` to `--passL`
20:52:56*def- quit (Client Quit)
20:53:13*def- joined #nim
20:53:25FromDiscord<tsoj> Why do you use `-d:useMalloc` and not `-d:mimalloc`?
20:53:46FromDiscord<Elegantbeef> cause `-d:mimalloc` doesn't exist
20:54:02FromDiscord<Elegantbeef> `-d:useMalloc` uses `malloc` which can be replaced by linking
20:54:28FromDiscord<nocturn9x> ^
20:54:47FromDiscord<nocturn9x> do I seriously have to use boehm
20:54:56FromDiscord<nocturn9x> that has awful performance
20:55:12FromDiscord<tsoj> Have you tried without mimalloc and just -d:useMalloc?
20:55:16FromDiscord<nocturn9x> will do
20:55:57FromDiscord<nocturn9x> trying rn
20:56:13FromDiscord<tsoj> If you gonna have any slightly expensive eval, the speed difference will probably be not more than like 10 Elo
20:56:24FromDiscord<nocturn9x> fair enough
20:56:44FromDiscord<nocturn9x> wow it segfaults much quicker with malloc
20:56:47FromDiscord<tsoj> lol
20:57:06FromDiscord<ieltan> 😸
20:57:22FromDiscord<nocturn9x> let's try boehm
20:57:27FromDiscord<nocturn9x> just for good measure
20:57:40FromDiscord<nocturn9x> cool and easy way to lose 30% of the performance
20:59:20FromDiscord<nocturn9x> let's not even mention that my SPRT is not gaining for shit
20:59:28FromDiscord<nocturn9x> but whatever
20:59:40FromDiscord<nocturn9x> that at least isn't Nim's fault
21:01:07FromDiscord<nocturn9x> I'll leave it running and drown my sadness in a double cheeseburger
21:04:10*def- quit (Quit: -)
21:04:36*def- joined #nim
21:08:26FromDiscord<nocturn9x> cool boehm crashes too
21:08:30FromDiscord<nocturn9x> juust great
21:11:27*def- quit (Quit: -)
21:12:16*def- joined #nim
21:51:32FromDiscord<nocturn9x> yeah okay I'm moving away from nim
21:51:35FromDiscord<nocturn9x> this just doesn't work
21:52:00FromDiscord<nocturn9x> I can't always be wondering whether a segfault is a compiler bug or a bug in my code
21:56:12*def- quit (Quit: -)
21:56:25*def- joined #nim
21:57:34FromDiscord<nocturn9x> so it looks like nimskull only supports ARC and ORC
21:57:41FromDiscord<nocturn9x> does it mean it's maybe somehow less borked
21:58:48FromDiscord<leorize> a lot of effort is put into them, so yea
21:59:57*def- quit (Client Quit)
22:00:27*def- joined #nim
22:03:08FromDiscord<bosinski2023> In reply to @leorize "a lot of effort": and how does reference-counting work with shared-mem/threads when there is no atomicArc ? just curious..
22:08:40FromDiscord<nocturn9x> In reply to @bosinski2023 "and how does reference-counting": yes, that's my question
22:09:13*def- quit (Quit: -)
22:27:07*def- joined #nim
23:04:47*tiorock joined #nim
23:04:47*rockcavera quit (Killed (tungsten.libera.chat (Nickname regained by services)))
23:04:47*tiorock is now known as rockcavera
23:04:49FromDiscord<amjadhd> Is there an equivalent to C++'s `str.append(n, ' ');` ?
23:06:30*redj_ joined #nim
23:07:44*lain quit (Remote host closed the connection)
23:07:44*perr_ quit (Remote host closed the connection)
23:07:45*redj quit (Remote host closed the connection)
23:07:53*perr_ joined #nim
23:08:10FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=OBtjlErSKjeX
23:08:19*lain joined #nim
23:43:57FromDiscord<Robyn [She/Her]> In reply to @amjadhd "Is there an equivalent": `str &= n & ' '`?
23:44:23FromDiscord<Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=iReydzzoylpc
23:52:20FromDiscord<polylokh_39446> I didn't even notice the n there. If it's `Appends count copies of character ch.`, there isn't