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:18 | FromDiscord | <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:28 | FromDiscord | <Elegantbeef> https://nim-lang.org/docs/asyncfile.html |
03:10:15 | FromDiscord | <Elegantbeef> You have to use Futures and it does not magically convert sync to async |
03:21:24 | FromDiscord | <leorize> async file is not async fwiw |
03:26:31 | FromDiscord | <Elegantbeef> Let me guess it does something slightly wrong which makes it not exactly async 😄 |
04:15:52 | NimEventer | New 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:27 | FromDiscord | <leorize> not exactly is an overstatement xd |
05:30:37 | FromDiscord | <leorize> it's sync IO with async overhead |
05:31:42 | FromDiscord | <leorize> async file io is simply a mess until recently |
05:32:04 | FromDiscord | <leorize> and the recent tech (io\_uring) is not everywhere yet |
05:32:12 | FromDiscord | <leorize> so to get async file io, use threads |
05:32:57 | FromDiscord | <Elegantbeef> Are selectors not considered true async? |
06:28:38 | * | PMunch joined #nim |
06:53:28 | FromDiscord | <nikolay_a_k> sent a long message, see https://pasty.ee/ORtOYNXzhNSQ |
06:54:01 | FromDiscord | <Elegantbeef> Nope not any tool that's really usable |
06:55:42 | * | ntat joined #nim |
06:55:45 | FromDiscord | <nikolay_a_k> Well, if here exist any coders that know both languages, could you, please, convert it? Sorry for asking this... |
06:56:08 | FromDiscord | <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:19 | FromDiscord | <Elegantbeef> Port the code to Nim yourself |
06:56:39 | FromDiscord | <nikolay_a_k> Thank you.) I don't know Nim at all. |
06:56:49 | FromDiscord | <Elegantbeef> That's' the first step |
07:09:08 | FromDiscord | <_ot> real |
07:09:27 | FromDiscord | <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:02 | FromDiscord | <Elegantbeef> cool it doesn't work |
07:10:09 | FromDiscord | <Elegantbeef> Learn the language and convert it yourself |
07:10:41 | FromDiscord | <nikolay_a_k> And if i'm too stupid for Nim? |
07:11:27 | FromDiscord | <Elegantbeef> How do you expect to use the Nim code, then? |
07:12:10 | FromDiscord | <nikolay_a_k> I will compile it to exe and will have fun chating with AI using small native binary file. |
07:12:21 | FromDiscord | <nikolay_a_k> (edit) "chating" => "chatting" |
07:12:28 | FromDiscord | <Elegantbeef> So time to learn Nim |
07:12:31 | FromDiscord | <Elegantbeef> Anyone can learn it |
07:12:42 | FromDiscord | <Elegantbeef> https://nim-lang.org/documentation.html |
07:12:45 | FromDiscord | <Elegantbeef> Toones of resources here |
07:13:32 | FromDiscord | <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:19 | FromDiscord | <nikolay_a_k> Anyone can learn Basic but not everyone can learn Python/Nim. |
07:15:47 | FromDiscord | <Elegantbeef> Nope everyone can learn Nim it just takes time and effort |
07:17:06 | FromDiscord | <nikolay_a_k> It like saying that everyone can learn C++ and Assembler, it just takes time and effort. Very fuuny joke. |
07:17:58 | FromDiscord | <nikolay_a_k> (edit) "fuuny" => "funny" |
07:18:10 | FromDiscord | <Elegantbeef> It's not a joke |
07:18:16 | FromDiscord | <Elegantbeef> You get out what you put in |
07:18:43 | PMunch | And Nim is certainly on the easier end to learn of programming languages |
07:18:47 | PMunch | At least the basic stuff |
07:19:21 | FromDiscord | <nikolay_a_k> Basic is much easier than Nim. |
07:20:33 | FromDiscord | <huantian> There’s no shortcuts in life my friend |
07:20:48 | PMunch | How is Basic easier than Nim? |
07:20:54 | FromDiscord | <Elegantbeef> Well there are just rely on an AI then decry when no one wants to port code for you |
07:21:40 | PMunch | Basic is horrible.. Nim is much easier |
07:22:01 | FromDiscord | <huantian> Ngl I didn’t know decry was a word |
07:22:19 | PMunch | If you can learn basic you can definitely learn Nim |
07:24:07 | FromDiscord | <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:26 | FromDiscord | <huantian> Dude don’t let your self deprecating thoughts about your own intelligence stop you from learning things |
07:32:22 | FromDiscord | <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:38 | FromDiscord | <Elegantbeef> Leave the self deprecating to those that have built an immunity from their negative effects like me! |
07:35:04 | FromDiscord | <leorize> it's more of a \nix and windows quirk |
07:35:22 | FromDiscord | <leorize> async file io is a lie |
07:35:59 | * | Ekho quit (Quit: CORE ERROR, SYSTEM HALTED.) |
07:41:32 | FromDiscord | <Elegantbeef> So I do not have to worry about my usage of `asyncfile` ontop of inotify files 😄 |
07:49:18 | FromDiscord | <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:07 | FromDiscord | <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:51 | FromDiscord | <Elegantbeef> Is it so difficult to learn how to use tools to learn how to do it yoursefl |
07:56:23 | FromDiscord | <nikolay_a_k> For me it's difficult. For you it's simple, because you are clever. |
07:56:30 | FromDiscord | <Elegantbeef> No cause I put effort in |
07:56:48 | FromDiscord | <Elegantbeef> Do not attribute my intelligence in programming due to an innate talent |
07:57:46 | FromDiscord | <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:07 | FromDiscord | <Elegantbeef> Grow up and spend the same time "professional coder"s have spent |
07:58:59 | FromDiscord | <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:02 | FromDiscord | <nnsee> make it make sense brother |
07:59:25 | FromDiscord | <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:30 | FromDiscord | <Elegantbeef> Wait they didn't ask me to do it, Dobby is free! |
07:59:39 | FromDiscord | <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:49 | FromDiscord | <Elegantbeef> Could be trolling could be entitlement |
07:59:53 | FromDiscord | <Elegantbeef> We'll never know |
08:00:19 | FromDiscord | <Elegantbeef> I'm going to go spend 40 minutes watching DS9 instead of worrying about this |
08:00:29 | FromDiscord | <nnsee> there's a dark souls 9!? |
08:01:36 | FromDiscord | <Elegantbeef> Deep space 9 |
08:02:13 | FromDiscord | <solitudesf> were the first 8 so good they made another one? |
08:03:00 | FromDiscord | <sebastian_solace> how do u open folders in nim? |
08:03:29 | FromDiscord | <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:33 | FromDiscord | <sebastian_solace> like uhh |
08:03:36 | FromDiscord | <sebastian_solace> go through all of a folders contents |
08:03:36 | FromDiscord | <nnsee> like, in explorer.exe? |
08:03:57 | FromDiscord | <solitudesf> In reply to @sebastian_solace "go through all of": https://nim-lang.org/docs/osdirs.html#walkDir.i,string |
08:04:02 | FromDiscord | <sebastian_solace> kind of like open folders as a list |
08:04:19 | FromDiscord | <sebastian_solace> In reply to @solitudesf "https://nim-lang.org/docs/osdirs.html#walkDir.i,str": ooh |
08:04:23 | FromDiscord | <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:19 | FromDiscord | <sebastian_solace> thats what i mean, meant to ask how i open all files in a certain directory |
08:05:22 | FromDiscord | <sebastian_solace> (edit) "open" => "list" |
08:05:45 | FromDiscord | <nnsee> ah yeah, that link is what you want then |
08:08:32 | FromDiscord | <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:04 | FromDiscord | <nnsee> ah damn |
08:09:08 | FromDiscord | <nnsee> of course |
08:09:08 | * | beholders_eye joined #nim |
08:09:15 | FromDiscord | <nnsee> colour me stupid lol |
08:10:20 | * | redj joined #nim |
08:10:40 | FromDiscord | <nnsee> consequentially opendir is in std/posix https://nim-lang.org/docs/posix.html#opendir%2Ccstring |
08:10:46 | FromDiscord | <nnsee> (although this probably definitely isn't what you want) |
08:12:02 | FromDiscord | <Phil> ~~Nothing in psoix is what you want~~ |
08:12:22 | FromDiscord | <Phil> (edit) "psoix" => "posix" |
08:13:19 | FromDiscord | <nnsee> phil is just reflecting his posix api PTSD on us |
08:15:01 | FromDiscord | <nnsee> reflecting? projecting. |
08:20:06 | FromDiscord | <.bobbbob> erm akshualky its called a directory |
08:22:58 | FromDiscord | <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:26 | FromDiscord | <.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:55 | FromDiscord | <Phil> In reply to @nnsee "phil is just reflecting": Every single bit of PTSD projection on posix is deserved |
08:49:59 | FromDiscord | <Phil> I know those were rougher times back then |
08:50:06 | FromDiscord | <Phil> But then update your trainwreck of a standard or sth |
08:50:19 | FromDiscord | <Phil> Which likely isn't possible because old code... gnaaaaaaa |
08:52:34 | FromDiscord | <Elegantbeef> In Phil's world POSIX starts with "Piece of Shit" |
08:52:40 | FromDiscord | <nnsee> if posix is so good why isn't there a posix 2 |
08:52:55 | FromDiscord | <Phil> piece of shotix |
08:52:58 | FromDiscord | <Phil> (edit) "shotix" => "shitix" |
08:53:05 | FromDiscord | <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:57 | FromDiscord | <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:12 | FromDiscord | <sOkam! 🫐> sent a long message, see https://pasty.ee/MMUXXHZbSbAB |
09:20:11 | FromDiscord | <sOkam! 🫐> _(beef, not you, its for nikolay 👌)_ |
09:20:41 | * | beholders_eye joined #nim |
09:21:17 | FromDiscord | <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:17 | FromDiscord | <nnsee> In reply to @heysokam "I'm also very stoopid,": so _that's_ what the s in sOkam stands for |
09:32:01 | FromDiscord | <Elegantbeef> If you look closely there's only 1 s in sokam |
09:32:06 | FromDiscord | <Elegantbeef> So choose a lane! |
09:33:36 | FromDiscord | <aryzen> I'm even slower what does the s in sokam stand for? |
09:33:51 | FromDiscord | <Elegantbeef> Smart! |
09:33:54 | FromDiscord | <Elegantbeef> Sophisticated! |
09:34:08 | FromDiscord | <Elegantbeef> The S in Beef stands for sarcastic |
09:35:35 | FromDiscord | <aryzen> sophisticatedOkam |
09:35:56 | FromDiscord | <aryzen> the g in aryzen stands for gullible |
09:38:17 | FromDiscord | <nnsee> the Ras in Ras stands for Rasmus! which coincidentally is my Name! |
09:38:22 | FromDiscord | <nnsee> not sure why I capitalized that |
09:38:28 | FromDiscord | <aryzen> Rasmus |
09:38:46 | FromDiscord | <sOkam! 🫐> In reply to @aryzen "I'm even slower what": it stands for bad-Style-Choices :kappa: |
09:38:53 | FromDiscord | <nnsee> In reply to @aryzen "Rasmus": hello |
09:39:02 | FromDiscord | <sOkam! 🫐> At least that what most people would say 🙈 |
09:39:03 | FromDiscord | <aryzen> hello! |
09:39:28 | FromDiscord | <aryzen> bad-style-choices....↵↵Like, when I insist the braces open on sameline in C#? |
09:39:34 | FromDiscord | <aryzen> or much worse? |
09:40:11 | FromDiscord | <sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=kIKrGaIHgewv |
09:40:22 | FromDiscord | <nnsee> oh god why |
09:40:30 | FromDiscord | <sOkam! 🫐> ^ see |
09:40:35 | FromDiscord | <aryzen> ... that export is floating away |
09:44:49 | FromDiscord | <aryzen> well... anyways; I'm still confused about my linker issue... |
09:45:34 | FromDiscord | <aryzen> actually... I might try some things, brb |
09:47:33 | FromDiscord | <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:10 | FromDiscord | <pmunch> In reply to @nnsee "in my mind folders": Wait, wtf does opendir actually do? |
10:18:51 | FromDiscord | <nnsee> opens a directory stream which you can then do `readdir()` etc on to read individual entries in the dir |
10:19:39 | FromDiscord | <pmunch> Oh, durr |
10:20:01 | FromDiscord | <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:57 | Amun-Ra | not an inode, regularfile contents |
10:21:32 | Amun-Ra | not "regular file", but regular contents |
10:23:07 | Amun-Ra | you can open directory with open(2) too |
10:28:23 | NimEventer | New 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:28 | FromDiscord | <_nenc> hey, anybody familiar with websocket? |
13:58:52 | FromDiscord | <_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:15 | FromDiscord | <_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=FtNbOwdGKott |
14:09:59 | FromDiscord | <Phil> In reply to @_nenc "hey, anybody familiar with": Yes, happy to help, however give me some time to finish work first |
14:19:00 | FromDiscord | <Phil> Hmmm yeah, that does seem odd. It should not be necessary.↵↵Could you give a quick show of code? |
14:20:51 | FromDiscord | <_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:04 | FromDiscord | <_nenc> thank you very much tho↵it must be my understand of Nim and WebSocket not enough |
14:22:12 | FromDiscord | <_nenc> (edit) "of" => "to" |
14:25:20 | * | def- quit (Quit: -) |
14:26:17 | * | def- joined #nim |
14:31:12 | FromDiscord | <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:27 | FromDiscord | <Phil> But there's nothing about the ws standard that states inherently that you must receive messages |
14:36:34 | FromDiscord | <_nenc> wait... maybe it is because I don't use multithreading right \:( |
14:37:59 | FromDiscord | <_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:17 | FromDiscord | <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:35 | FromDiscord | <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:27 | FromDiscord | <_nenc> sorry, I just now had some difficulties accessing discord |
15:19:42 | FromDiscord | <_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=GPBgUPwIgUVU |
15:21:41 | FromDiscord | <_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:29 | FromDiscord | <_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:48 | FromDiscord | <Phil> And your pusher is accessed by multiplet hreads? |
15:23:51 | FromDiscord | <Phil> (edit) "multiplet hreads?" => "multiple threads?" |
15:24:01 | FromDiscord | <Phil> What is target? |
15:26:50 | FromDiscord | <_nenc> it is just a normal string, concretely it is a username my bot is supposed to intercat with |
15:27:14 | FromDiscord | <_nenc> now I have a relatively small code to show it... |
15:27:41 | FromDiscord | <_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=BPzfGkXIWnHU |
15:28:21 | FromDiscord | <_nenc> (to simplify I removed something about target, but it can still show the problem |
15:28:43 | FromDiscord | <_nenc> (edit) "https://play.nim-lang.org/#pasty=oHZsxLYnbJRP" => "https://play.nim-lang.org/#pasty=GemvjMhfYJKU" |
15:28:57 | FromDiscord | <_nenc> (edit) "https://play.nim-lang.org/#pasty=OsPtaDIxyOyy" => "https://play.nim-lang.org/#pasty=AzusuLUpMYzs" |
15:29:35 | FromDiscord | <_nenc> it is not shared memory error, I think maybe it is wrong in mixing async with threading |
15:31:50 | FromDiscord | <Phil> Use jointhread |
15:32:58 | FromDiscord | <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:04 | FromDiscord | <_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:41 | FromDiscord | <Phil> You're not using thread pool though, you're using createthread |
15:35:03 | FromDiscord | <_nenc> wait, am I?? |
15:35:07 | FromDiscord | <Phil> Well, hidden in a sense but I don't trust thread pool too much |
15:36:03 | FromDiscord | <Phil> I can look into thread pool docs later to see if they specify any behaviour |
15:36:49 | FromDiscord | <_nenc> emmmm, i got it |
15:37:15 | FromDiscord | <_nenc> if I change to malebolgia, do you think it is likely to be solves? |
15:37:17 | FromDiscord | <_nenc> (edit) "solves?" => "solved?" |
15:38:22 | FromDiscord | <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:38 | FromDiscord | <_nenc> so, the createThread is not in my code, but in threadpool, and sync is malpracticing and not joining my threads here? |
15:42:37 | FromDiscord | <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:58 | FromDiscord | <Phil> You can use echo to see if your thread proc runs or not |
15:43:03 | FromDiscord | <Phil> I would assume not |
15:43:42 | FromDiscord | <_nenc> oh, thanks very much, I think I will do more experiments on it |
15:45:56 | FromDiscord | <_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:09 | FromDiscord | <Phil> Hmmmm |
15:46:13 | FromDiscord | <_nenc> (edit) "the same as" => "in line with" |
15:48:14 | FromDiscord | <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:36 | FromDiscord | <Phil> Like an Auth message or the like |
15:49:49 | FromDiscord | <Phil> If you're really unlucky then spawn copies your ws |
15:50:26 | FromDiscord | <_nenc> In reply to @isofruit "If you're really unlucky": yeah, I was thinking of things like this kind |
15:50:33 | FromDiscord | <Phil> Could echo the ptrs to see if they're the same |
15:51:19 | FromDiscord | <Phil> Or rather echo the repr of the pusher obj |
15:51:20 | * | def- joined #nim |
15:51:39 | FromDiscord | <Phil> That should show the PTR of the es connection |
15:55:26 | FromDiscord | <_nenc> emmmmm, however even the addr of ws seems to be the same, to clarify I will send the newest code |
15:55:40 | FromDiscord | <_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=EabZbSLFodpc |
15:56:03 | FromDiscord | <_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=DoMldekkvVEZ |
15:56:26 | FromDiscord | <_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=xuZlgXJdvgfd |
15:57:40 | FromDiscord | <_nenc> (I assume I am printing the pointer right) |
16:09:59 | FromDiscord | <_nenc> there is actually sth special about the server, if your message is not valid json the server will close your connection |
16:10:30 | FromDiscord | <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:52 | FromDiscord | <_nenc> ahhh! you're right |
16:10:53 | FromDiscord | <Phil> sent a code paste, see https://play.nim-lang.org/#pasty=ntGsVsGZPKHf |
16:11:00 | FromDiscord | <_nenc> `addr` is like `&` |
16:11:24 | FromDiscord | <_nenc> it is addr of my stack temp var, isnt it |
16:11:29 | FromDiscord | <Phil> In reply to @_nenc "there is actually sth": yep |
16:11:40 | FromDiscord | <Phil> or rather it's an addr of the ref that is int he stack |
16:14:41 | FromDiscord | <_nenc> emmmm, when I echo like this, they are still the same...? |
16:15:12 | FromDiscord | <Phil> Yep, which means there is no copy that I can see |
16:16:28 | FromDiscord | <_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:10 | FromDiscord | <_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:56 | FromDiscord | <_nenc> if I can setup a local server it will be definitely clearer... |
16:18:07 | FromDiscord | <Phil> I think I could help more if I could see the WS connection on the sevrer somehow =/ |
16:29:08 | FromDiscord | <Phil> Welp, can't experiment anymore, getting rate-limited or blocked |
16:30:58 | FromDiscord | <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:21 | FromDiscord | <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:17 | FromDiscord | <norax.2> a nim library to encode base85? |
16:39:35 | FromDiscord | <norax.2> (edit) "encode" => "encode/decode" |
16:40:19 | FromDiscord | <polylokh_39446> <https://github.com/scemino/engge2/blob/f0d8939896b021124aa9821e9c7d943db0d82105/src/io/base85.nim#L4> |
16:42:02 | FromDiscord | <norax.2> In reply to @polylokh_39446 "<https://github.com/scemino/engge2/blob/f0d8939896b": ty |
16:42:24 | FromDiscord | <_nenc> In reply to @isofruit "Curious for how to": it can be seen in a very pure case |
16:42:37 | FromDiscord | <_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=WiqlNGgABuHg |
16:42:50 | FromDiscord | <_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=HPOgCnSanfeR |
16:43:01 | FromDiscord | <_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=IarUgdSEfWDV |
16:43:27 | FromDiscord | <Phil> Now reduce t - does it still close when t is basically just an "echo "start" "? |
16:43:44 | FromDiscord | <_nenc> (once it printed m1 and m2 but not t1, I think it's just a little timing error) |
16:43:50 | FromDiscord | <Phil> Does it still close without spawning anything ? |
16:44:07 | FromDiscord | <Phil> (edit) "without spawning anything" => "if you remove spawn?" |
16:44:09 | FromDiscord | <Phil> (edit) removed "?" |
16:44:26 | FromDiscord | <_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=aXYPLwBssSev |
16:45:02 | FromDiscord | <Phil> Okay, comment one in |
16:45:07 | FromDiscord | <_nenc> (edit) "https://play.nim-lang.org/#pasty=eGWxXuFCTHLh" => "https://play.nim-lang.org/#pasty=eQaWzHIXFIGx" |
16:45:33 | FromDiscord | <_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=tcohJMDHVUIm |
16:46:01 | * | def- quit (Quit: -) |
16:46:03 | FromDiscord | <_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=idgCXEQYWpiM |
16:46:04 | FromDiscord | <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:05 | FromDiscord | <Phil> If you had a race condition where both threads might be sending through that ws simultaneously I'd understand |
16:47:09 | FromDiscord | <graveflo> is it possible that the socket object is being moved into the thread and that is calling the destructor? |
16:47:14 | FromDiscord | <Phil> Because you're constantly at risk of that happening and blowing up your socket |
16:47:30 | FromDiscord | <Phil> But in this example you're making sure there's ms between those occurances so it should be impossible |
16:47:36 | FromDiscord | <_nenc> In reply to @graveflo "is it possible that": yes, I thought about ARC, but idk |
16:47:56 | FromDiscord | <Phil> Put it all in a proc and then use expandArc to see the destructor-calls |
16:47:56 | FromDiscord | <_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:57 | FromDiscord | <graveflo> could make a dummy object and override the move semantics and see what it does |
16:47:58 | FromDiscord | <Phil> Because that might be it |
16:48:28 | FromDiscord | <Phil> Use `--expandArc:PROCNAME` |
16:50:10 | FromDiscord | <_nenc> sent a code paste, see https://play.nim-lang.org/#pasty=hhDqkJYkpqEQ |
16:51:23 | FromDiscord | <_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:11 | FromDiscord | <_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:04 | FromDiscord | <graveflo> yea it looks like destroy is being called at the end so that's prob not it :/ |
16:53:05 | FromDiscord | <Phil> That should be duplicating the ref |
16:53:20 | FromDiscord | <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:38 | FromDiscord | <_nenc> After commenting a except in ws.nim |
17:04:43 | FromDiscord | <_nenc> I got some traceback |
17:05:22 | FromDiscord | <_nenc> https://media.discordapp.net/attachments/371759389889003532/1236000662681288765/message.txt?ex=66366ad1&is=66351951&hm=7060c1765731688b24b125af2669e4580c706afce55babe6cad23599ddc02aac& |
17:06:58 | FromDiscord | <graveflo> oh that kinda makes sense. The async dispatcher is prob thread local. |
17:07:45 | FromDiscord | <_nenc> ahh yes, I thought that maybe Nim's async can't work well with threading |
17:08:00 | FromDiscord | <Phil> Which means, you no share ws |
17:09:31 | FromDiscord | <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:06 | FromDiscord | <graveflo> as opposed to trying to share the dispatcher itself that is |
17:10:13 | FromDiscord | <Phil> There is not I'm pretty sure |
17:10:32 | FromDiscord | <Phil> Or rather I have not found anything ever related to mixing async and threads easy |
17:10:51 | FromDiscord | <Phil> This kind of stuff is why actor model is so valuable, just do message passing |
17:11:13 | FromDiscord | <Phil> (Or at least in my mental model that immediately maps to actor model, I might be wrong here) |
17:14:13 | FromDiscord | <_nenc> well, I think I can solve my program |
17:14:25 | FromDiscord | <_nenc> I can create my ws in the sub thread |
17:14:29 | FromDiscord | <_nenc> and use chans |
17:15:06 | FromDiscord | <_nenc> (previously I passes ws from main thread to sub thread and let sub threads use chans to talk to ws) |
17:15:14 | FromDiscord | <_nenc> (edit) "passes" => "passed" |
17:21:24 | FromDiscord | <_nenc> anyway, thank you very much |
17:22:35 | FromDiscord | <_nenc> if not for you I can't solve such a complex problem to me |
17:23:19 | FromDiscord | <_nenc> (and I think I am correct for posting my problem here instead of on forum😂 forum won't be instant enough |
17:27:46 | FromDiscord | <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:57 | FromDiscord | <Phil> Sidenote, by going all in on closures that one is becoming surprisingly easy |
17:33:24 | FromDiscord | <MDuardo> You want to make Erlang-like concurrency?↵(@Phil) |
17:33:47 | FromDiscord | <Phil> Maybe? I don't know enough about erlang intricacies to make that kind of claim |
17:33:58 | FromDiscord | <Phil> All I want is to have some kind of way that allows me to treat threads like an http-server |
17:34:18 | FromDiscord | <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:34 | FromDiscord | <Phil> "I send you X and forget about it, you may eventually send Y back" etc. |
17:36:38 | FromDiscord | <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:34 | FromDiscord | <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:38 | FromDiscord | <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:19 | FromDiscord | <Phil> Basically Dart-Isolates or WebWorkers suffices to me |
17:45:30 | FromDiscord | <Phil> But more that I want an even narrower API that limits what you can send |
17:45:36 | FromDiscord | <Phil> (edit) "But more that I want an even narrower API that limits what you can send ... " added "at compiletime" |
17:47:08 | FromDiscord | <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:04 | FromDiscord | <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:16 | FromDiscord | <Phil> (edit) "introduces" => "introduced" |
17:48:28 | FromDiscord | <Phil> Lock-files only helped to some degree |
17:49:15 | FromDiscord | <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:16 | FromDiscord | <Phil> rewriting to go full closure on my reactivex approach for nim took me barely 3h, wtf) |
17:59:18 | FromDiscord | <Phil> (edit) "wtf)" => "wtf" |
17:59:27 | FromDiscord | <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:56 | FromDiscord | <nocturn9x> is it possible that nim's leaking memory? |
18:31:18 | FromDiscord | <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:57 | FromDiscord | <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:11 | FromDiscord | <nocturn9x> which is fixed by `GcRef`ing it, but that's nonsensical |
18:32:43 | FromDiscord | <nocturn9x> and to be clear, it's not the object that I'm calling `GcRef` on, but the _field_ |
18:33:13 | FromDiscord | <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:33 | FromDiscord | <nocturn9x> which makes no freaking sense because it's supposed to be a shared ref, and why would it segfault anyway? |
18:33:37 | FromDiscord | <nocturn9x> it doesn't do it in debug mode |
18:33:50 | FromDiscord | <nocturn9x> (for context, I'm using `atomicArc`) |
18:36:08 | FromDiscord | <nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=EYvfsWlIUbYl |
18:36:50 | FromDiscord | <nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=UzFutqeqwGyQ |
18:36:58 | FromDiscord | <nocturn9x> specifically at `session.searchManager = searcher` |
18:37:01 | FromDiscord | <nocturn9x> wtf is going on? |
18:37:22 | FromDiscord | <nocturn9x> I have verified `session` is not nil, neither is `searchManager` (they're both `ref`s) |
18:40:26 | FromDiscord | <nocturn9x> ok nevermind it does happen in debug mode as well |
18:40:33 | * | def- quit (Quit: -) |
18:40:44 | FromDiscord | <nocturn9x> sent a long message, see https://pasty.ee/WSZwOYVTNtMB |
18:40:56 | * | def- joined #nim |
18:41:02 | FromDiscord | <nocturn9x> but it's nim's internal stuff, `bestMove` _starts_ at line 292 so the traceback is wrong too lol |
18:41:19 | FromDiscord | <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:41 | FromDiscord | <nocturn9x> well okay if I wanted to use refc with locks to kill the performance I would |
18:41:52 | FromDiscord | <nocturn9x> the point is I don't want to, this is performance critical code :/ |
18:42:32 | FromDiscord | <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:19 | FromDiscord | <polylokh_39446> some_module_name's going to be only toplevel code, so if this is bestMove, --expandArc:bestMove |
18:43:21 | FromDiscord | <nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=eEvFtKMQvQEv |
18:43:28 | FromDiscord | <nocturn9x> motherfucker |
18:43:30 | FromDiscord | <nocturn9x> why |
18:43:31 | FromDiscord | <nocturn9x> lol |
18:43:38 | FromDiscord | <nocturn9x> it doesn't own the damn reference 😢 |
18:44:36 | FromDiscord | <nocturn9x> okay it is doing a copy tho |
18:44:46 | FromDiscord | <nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=CBGKgiYajqJU |
18:47:30 | FromDiscord | <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:12 | FromDiscord | <bosinski2023> (edit) "`epandArc`," => "`expandArc`," | "`refs`" => "`refc`" |
18:48:24 | FromDiscord | <nocturn9x> well with refc it segfaults when accessing the atomic |
18:48:26 | FromDiscord | <nocturn9x> ...lol |
18:48:40 | FromDiscord | <nocturn9x> and it's crashing inside the atomics library |
18:48:41 | FromDiscord | <nocturn9x> _cool_ |
18:49:01 | FromDiscord | <nocturn9x> I love parallelism in nim. It's :so_ easy. |
18:49:04 | FromDiscord | <nocturn9x> (edit) ":so_" => "_so_" |
18:49:06 | FromDiscord | <bosinski2023> In reply to @nocturn9x "and it's crashing inside": which one `std/atomics` or `threading/atomics` |
18:49:12 | FromDiscord | <nocturn9x> `std/atomics` |
18:49:26 | FromDiscord | <nocturn9x> also should all references just be atomics |
18:49:28 | FromDiscord | <nocturn9x> like wat |
18:54:19 | FromDiscord | <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:34 | FromDiscord | <nocturn9x> In reply to @isofruit "Depends: It definitely will": _what_ |
18:54:44 | FromDiscord | <Phil> Funny things that are threadvars would be for example the ORC-GC or the async dispatcher |
18:54:59 | FromDiscord | <nocturn9x> you're telling me it doesn't GC thread procs either? |
18:55:23 | FromDiscord | <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:29 | FromDiscord | <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:42 | FromDiscord | <nocturn9x> "have you considered going the C way" |
18:55:51 | FromDiscord | <nocturn9x> why would I use nim |
18:55:59 | FromDiscord | <nocturn9x> `malloc()` was invented 40 years ago |
18:56:16 | FromDiscord | <nocturn9x> someone is getting a pipebomb in their mailbox for this ass-backwards design |
18:56:23 | FromDiscord | <nocturn9x> like for real this is the dumbest fucking thread model _ever_ |
18:56:25 | FromDiscord | <Phil> sent a code paste, see https://play.nim-lang.org/#pasty=BcQudkhyYlOk |
18:56:55 | FromDiscord | <nocturn9x> I don't have any variables marked as `{.thread.}` |
18:57:00 | FromDiscord | <nocturn9x> if that is what you're wondering |
18:57:07 | FromDiscord | <nocturn9x> I do create some stuff in the thread itself |
18:57:09 | FromDiscord | <Phil> Sure, but your dependencies might |
18:57:16 | FromDiscord | <Phil> If you use async - You need to take care of the dispatcher |
18:57:20 | FromDiscord | <Phil> If you use std/times, you need to clear their shit |
18:57:21 | FromDiscord | <nocturn9x> I am not using async |
18:57:30 | FromDiscord | <nocturn9x> I also do not use `std/times` |
18:57:31 | FromDiscord | <Phil> If you use orc, you need to full-collect |
18:57:32 | FromDiscord | <nocturn9x> I do use monotimes |
18:57:40 | FromDiscord | <nocturn9x> so basically nim leaks memory |
18:57:44 | FromDiscord | <Phil> Then you might want to check if that has {.thread.} |
18:57:48 | FromDiscord | <nocturn9x> I thought only V would leak memory by design |
18:58:07 | FromDiscord | <bosinski2023> In reply to @nocturn9x "I thought only V": thats common knowledge 🙂 |
18:58:27 | FromDiscord | <nocturn9x> araq, I don't know if you're reading |
18:58:37 | FromDiscord | <nocturn9x> but please do know I have a very special place in my heart for your thread model |
18:58:39 | FromDiscord | <Phil> He is not |
18:58:41 | FromDiscord | <nocturn9x> and it's not in good standing. |
18:58:54 | FromDiscord | <nocturn9x> what a colossally idiotic design oh my god |
18:59:18 | FromDiscord | <nocturn9x> how does anyone expect to use this stuff in production if it can't even clean up _its own damn garbage_ |
18:59:19 | FromDiscord | <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:33 | FromDiscord | <nocturn9x> people are just supposed to, oh, _know_ what stuff their dependencies use? |
18:59:35 | * | def- quit (Quit: -) |
18:59:37 | FromDiscord | <nocturn9x> that's a good way to drive people fucking insane |
18:59:52 | FromDiscord | <Phil> Note that I would definitely tone it down because I'm not sure how chill Araq is on any given day. |
18:59:58 | FromDiscord | <Robyn [She/Her]> In reply to @nocturn9x "people are just supposed": Well yeah, that's true for nearly all languages, no? |
19:00:05 | FromDiscord | <nocturn9x> In reply to @chronos.vitaqua "Well yeah, that's true": what |
19:00:07 | FromDiscord | <Phil> (edit) "Note that I would definitely tone it down ... because" added "in such a scenario" |
19:00:07 | FromDiscord | <nocturn9x> no? |
19:00:13 | FromDiscord | <Robyn [She/Her]> C, C++, Zig, Rust, etc |
19:00:17 | FromDiscord | <nocturn9x> I don't need to know if one of my dependencies is using thread memory and clean up after it |
19:00:20 | FromDiscord | <nocturn9x> the language does it for me |
19:00:28 | FromDiscord | <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:28 | FromDiscord | <nocturn9x> or the library does it on its own |
19:00:36 | FromDiscord | <Phil> Like nim requires you to just know if your dependencies use threadvars |
19:00:42 | FromDiscord | <Robyn [She/Her]> Aah |
19:00:43 | FromDiscord | <Phil> So that you can clean those up before the thread exits |
19:00:43 | FromDiscord | <nocturn9x> In reply to @isofruit "Note that I would": I literally do not care, he can ban me if he likes |
19:01:05 | FromDiscord | <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:35 | FromDiscord | <nocturn9x> if he can't take criticism that's on him |
19:01:49 | FromDiscord | <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:52 | FromDiscord | <nocturn9x> i've been an avid nim user for a few years now and this is seriously making me consider dropping it |
19:02:14 | FromDiscord | <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:32 | FromDiscord | <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:37 | FromDiscord | <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:53 | FromDiscord | <Phil> https://github.com/nim-lang/Nim/issues/23165 just to get it out of there |
19:02:55 | FromDiscord | <nocturn9x> how are people supposed to write code like this |
19:03:50 | FromDiscord | <Elegantbeef> Ideal one should audit dependencies |
19:03:51 | FromDiscord | <Elegantbeef> But yes Nim should clear thread local vars |
19:04:23 | FromDiscord | <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:29 | FromDiscord | <nocturn9x> dude |
19:04:34 | FromDiscord | <nocturn9x> I have been debugging these issues for days |
19:04:38 | FromDiscord | <nocturn9x> or, well, trying to |
19:04:48 | FromDiscord | <Phil> And you could have taken longer, trust me, been there. |
19:04:56 | FromDiscord | <nocturn9x> random fucking segfaults because nim's ARC impl. can't keep its shit together |
19:05:00 | FromDiscord | <Elegantbeef> Well this is a bug more than design↵(@Phil) |
19:05:12 | * | ntat quit (Quit: Leaving) |
19:05:27 | FromDiscord | <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:30 | FromDiscord | <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:39 | FromDiscord | <nocturn9x> because there is no way I'm playing whack-a-mole with my dependencies, fuck that |
19:05:50 | FromDiscord | <Elegantbeef> I don't think it'd be too hard to actually create a thread destructor that destructs all threadvars |
19:06:59 | FromDiscord | <Elegantbeef> I'm not suggesting you fix the compiler |
19:07:19 | FromDiscord | <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:44 | FromDiscord | <nocturn9x> the fun part is that doesn't even explain the segfaults |
19:07:52 | FromDiscord | <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:17 | FromDiscord | <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:21 | FromDiscord | <Phil> In reply to @Elegantbeef "I don't think it'd": Honestly that one is mildly beyond me |
19:08:34 | FromDiscord | <nocturn9x> In reply to @polylokh_39446 "the next alternative is": I suppose |
19:08:43 | FromDiscord | <Phil> And by mildly I mean very |
19:10:09 | FromDiscord | <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:17 | FromDiscord | <nocturn9x> nope |
19:10:18 | FromDiscord | <nocturn9x> it's not nil |
19:10:20 | FromDiscord | <nocturn9x> I checked |
19:10:34 | FromDiscord | <nocturn9x> unless it's releasing it inside its own machinery, after I can see it |
19:10:41 | FromDiscord | <nocturn9x> in which case arc is even more broken than I thought |
19:11:36 | FromDiscord | <nocturn9x> also |
19:11:39 | FromDiscord | <nocturn9x> if I call `joinThread` |
19:11:43 | FromDiscord | <nocturn9x> it also segfaults |
19:11:46 | FromDiscord | <nocturn9x> _thanks nim_ |
19:11:52 | FromDiscord | <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:09 | FromDiscord | <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:18 | FromDiscord | <nocturn9x> yeah that's nim's internal stuff |
19:12:21 | FromDiscord | <nocturn9x> also the traceback is wrong |
19:12:25 | FromDiscord | <nocturn9x> there is no line 49 in bestMove |
19:12:29 | FromDiscord | <nocturn9x> it starts at line 292 |
19:12:36 | FromDiscord | <nocturn9x> would be pretty hard to have a line 49 in there |
19:12:47 | FromDiscord | <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:59 | FromDiscord | <nocturn9x> question |
19:13:04 | FromDiscord | <nocturn9x> would -d:useMalloc change any of that |
19:13:10 | FromDiscord | <Elegantbeef> Yea phil it's all in cgen land so it's not anywhere I'm used too |
19:13:11 | FromDiscord | <Elegantbeef> to\ |
19:13:18 | FromDiscord | <bosinski2023> In reply to @nocturn9x "would -d:useMalloc change any": maybe - try it ! |
19:13:21 | FromDiscord | <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:27 | FromDiscord | <nocturn9x> you'd expect it to, you know, work? |
19:13:37 | FromDiscord | <Elegantbeef> Asking @jmgomez very nicely to generate a proc that destroys all `threadVar`s would probably be the route 😄 |
19:13:42 | FromDiscord | <nocturn9x> how can nim even claim to be a systems programming language and NOT have working threads |
19:13:46 | FromDiscord | <nocturn9x> like this is worse than C |
19:13:50 | FromDiscord | <nocturn9x> and C has `pthread_create` |
19:14:00 | FromDiscord | <nocturn9x> how do you fuck up so royally |
19:14:19 | FromDiscord | <nocturn9x> how long has nim existed for, well over a decade? |
19:14:46 | FromDiscord | <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:48 | FromDiscord | <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:57 | FromDiscord | <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:20 | FromDiscord | <nocturn9x> maybe instead of adding features over features there should be a focus on fixing the clearly broken stuff |
19:15:48 | FromDiscord | <polylokh_39446> (edit) "that's" => "that it's" |
19:15:57 | FromDiscord | <nocturn9x> but the existence of nimskull proves araq doesn't give two shits about the language actually being stable and usable |
19:16:00 | FromDiscord | <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:57 | FromDiscord | <leorize> did you move an arc pointer across threads? |
19:17:08 | FromDiscord | <nocturn9x> yeah, using `atomicArc` |
19:17:15 | FromDiscord | <nocturn9x> (edit) "`atomicArc`" => "`--mm:atomicArc`" |
19:17:33 | FromDiscord | <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:07 | FromDiscord | <leorize> generics work until you try to employ it, nim stuff |
19:18:22 | FromDiscord | <leorize> if you can link your trace here I can help |
19:18:25 | FromDiscord | <leorize> but always use `-d:useMalloc`, the nim allocator has internal races |
19:18:51 | FromDiscord | <nocturn9x> yes, that appears to fix it |
19:19:04 | FromDiscord | <nocturn9x> it also makes the code measurably slower but at least it works |
19:19:25 | FromDiscord | <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:26 | FromDiscord | <bosinski2023> In reply to @nocturn9x "it also makes the": thats good news :)) |
19:20:12 | FromDiscord | <Phil> -d:useMalloc when multithreading is one of those "uncommunicated must-haves" |
19:20:13 | * | def- quit (Quit: -) |
19:20:15 | FromDiscord | <leorize> that'd only work if channels work |
19:20:18 | FromDiscord | <leorize> and channels are... funny |
19:20:20 | FromDiscord | <Phil> Which, tbf, I forgot about |
19:21:20 | FromDiscord | <nocturn9x> the thing that comforts me about this |
19:21:36 | FromDiscord | <nocturn9x> is that before dealing with this I thought my own language wouldn't be able to compete with nim |
19:21:40 | FromDiscord | <nocturn9x> oh BOY was I wrong |
19:21:55 | * | def- joined #nim |
19:21:57 | FromDiscord | <nocturn9x> even if it might not go as fast, it'll surely not be this broken when it comes to basic features |
19:22:27 | FromDiscord | <nocturn9x> never have I felt this much frustrated and deprived of all the time I spent learning a new tool lol |
19:23:48 | FromDiscord | <nocturn9x> (edit) "this much" => "so" |
19:23:58 | FromDiscord | <Elegantbeef> Window's malloc bad |
19:24:32 | FromDiscord | <nocturn9x> good thing I daily drive linux hen |
19:24:34 | FromDiscord | <nocturn9x> (edit) "hen" => "then" |
19:24:59 | FromDiscord | <nocturn9x> note to self: never do anything with threads in nim ever again |
19:25:14 | FromDiscord | <nocturn9x> I _dread_ the time when I'll have to implement parallel search. That will surely be fun. |
19:25:16 | FromDiscord | <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:27 | FromDiscord | <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:58 | FromDiscord | <nocturn9x> performance is meaningless if your code segfaults randomly for no apparent reason or fault of yourd |
19:26:00 | FromDiscord | <nocturn9x> (edit) "yourd" => "yours" |
19:26:14 | FromDiscord | <nocturn9x> "well I mean it segfaults really fast" |
19:26:23 | FromDiscord | <nocturn9x> that is not an argument, it's pure madness |
19:26:26 | FromDiscord | <leorize> you should try nimskull \:p |
19:26:33 | FromDiscord | <nocturn9x> is that even up to date |
19:28:03 | * | beholders_eye joined #nim |
19:28:21 | FromDiscord | <leorize> nim code is fast y'know |
19:28:24 | FromDiscord | <leorize> crash faster than anything I've ever written |
19:28:32 | FromDiscord | <nocturn9x> same |
19:29:35 | FromDiscord | <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:15 | FromDiscord | <nocturn9x> what I plan to implement is generational references |
19:30:24 | FromDiscord | <nocturn9x> which is basically fancy weak references with some cheap runtime checks |
19:30:28 | FromDiscord | <nocturn9x> most of which will be elided |
19:30:33 | FromDiscord | <nocturn9x> that + regions with single ownership |
19:30:41 | FromDiscord | <polylokh_39446> Nim code that's written in the undocumented solid subset of the language is just fast, and not "crashes fast". |
19:30:48 | FromDiscord | <nocturn9x> so you can have mutable references for when you need that semantics |
19:30:57 | FromDiscord | <nocturn9x> (edit) "semantics" => "semantic" |
19:31:08 | FromDiscord | <polylokh_39446> for a start I'd like thta subset documented. I think that's easier than writing another language. |
19:31:20 | FromDiscord | <polylokh_39446> (edit) "thta" => "that" |
19:31:30 | FromDiscord | <nocturn9x> well complain to the guy who keeps adding piles of crap on top of the already huge pile of crap |
19:32:19 | FromDiscord | <nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=gJwfJUEPiODb |
19:32:25 | FromDiscord | <nocturn9x> wanna guess which one is using malloc? |
19:32:36 | FromDiscord | <leorize> write nim like you write C, that's how you get solid nim code |
19:32:36 | FromDiscord | <leorize> that's also a big argument to just write rust and be done with it |
19:32:38 | FromDiscord | <nocturn9x> All the performance work I had done has basically evaporated |
19:32:45 | FromDiscord | <nocturn9x> _thanks nim_ |
19:32:55 | FromDiscord | <System64 ~ Flandre Scarlet> Hi, does Nim supports hot reloading out of the box? |
19:33:07 | FromDiscord | <nocturn9x> nim doesn't support anything |
19:33:09 | FromDiscord | <nocturn9x> pray that it works |
19:33:12 | FromDiscord | <nocturn9x> it may work |
19:33:13 | FromDiscord | <nocturn9x> it may not |
19:33:21 | FromDiscord | <leorize> hot code reloading is practically untested |
19:33:26 | FromDiscord | <nocturn9x> is anything tested |
19:33:33 | FromDiscord | <nocturn9x> beyond toy level stuff |
19:33:34 | FromDiscord | <bosinski2023> In reply to @sys64 "Hi, does Nim supports": yes, its in the `experimental`-box.. |
19:33:38 | FromDiscord | <nocturn9x> because it doesn't feel like it |
19:33:40 | FromDiscord | <nocturn9x> at all |
19:33:50 | FromDiscord | <System64 ~ Flandre Scarlet> In reply to @bosinski2023 "yes, its in the": So probably unstable? |
19:33:53 | FromDiscord | <nocturn9x> I have over 6000 lines of code written for my compiler and it's all nim |
19:34:06 | FromDiscord | <leorize> In reply to @sys64 "So probably unstable?": probably unusable |
19:34:08 | * | def- quit (Quit: -) |
19:34:10 | FromDiscord | <System64 ~ Flandre Scarlet> OOF |
19:34:15 | FromDiscord | <nocturn9x> In reply to @nocturn9x "I have over 6000": and now I'm terrified |
19:34:24 | FromDiscord | <nocturn9x> of working on it more |
19:34:31 | FromDiscord | <Elegantbeef> HCR exists but it explodes and kills dogs |
19:34:31 | FromDiscord | <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:35 | FromDiscord | <tsoj> You know, the whole world runs on C++ |
19:34:44 | FromDiscord | <tsoj> despite all its footguns |
19:34:47 | FromDiscord | <System64 ~ Flandre Scarlet> In reply to @tsoj "You know, the whole": Including the Matrix??!!! |
19:34:49 | FromDiscord | <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:59 | FromDiscord | <Elegantbeef> I'd more so say to use DLLs or WASM for HCR |
19:35:11 | FromDiscord | <leorize> or at all, tbf |
19:35:28 | FromDiscord | <Elegantbeef> Not the same but it's more likely to work over Nim's HCR |
19:35:29 | FromDiscord | <leorize> HCR is a layer of hack on top of C gen that barely works, is how I view this stuff |
19:35:46 | FromDiscord | <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:48 | FromDiscord | <ieltan> I've been reading up on this channel and man... |
19:35:49 | FromDiscord | <leorize> beef\: the discord lag strikes again |
19:36:14 | FromDiscord | <nocturn9x> In reply to @ieltan "I've been reading up": I know right |
19:36:26 | FromDiscord | <nocturn9x> nim is a textbook example of how _not_ to schedule priorities for a language |
19:36:29 | FromDiscord | <leorize> In reply to @nocturn9x "I have over 6000": use nimskull :p |
19:36:33 | FromDiscord | <Phil> There's a ton of really good design decisions I like in nim.↵But multithreading is absolutely a weakpoint |
19:36:33 | FromDiscord | <leorize> totally not a biased opinion |
19:36:47 | FromDiscord | <nocturn9x> "ah yes let's get this cool new memory model into the compiler before threads are even fully working" |
19:36:49 | FromDiscord | <ieltan> I wanted to use threads for my library project but that does not make me want to do it lok |
19:37:00 | FromDiscord | <nocturn9x> In reply to @leorize "use nimskull :p": does it support nim 2.0 |
19:37:14 | FromDiscord | <Elegantbeef> Jeez |
19:37:14 | FromDiscord | <Elegantbeef> That's some lag |
19:37:59 | FromDiscord | <leorize> In reply to @nocturn9x "does it support nim": it can do 1.6 plus a few extensions |
19:38:36 | FromDiscord | <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:38 | FromDiscord | <tsoj> what is the threading like compared to nim? |
19:39:08 | FromDiscord | <ieltan> All I've ever seen nimskull used for was for CPS development |
19:39:15 | FromDiscord | <nocturn9x> In reply to @leorize "it can do 1.6": so no |
19:39:20 | FromDiscord | <nocturn9x> a shame |
19:39:23 | FromDiscord | <nocturn9x> I like the new top down inference |
19:40:23 | FromDiscord | <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:15 | FromDiscord | <polylokh_39446> but this current state is only a few years old |
19:41:17 | FromDiscord | <nocturn9x> I considered contributing at one time |
19:41:24 | FromDiscord | <nocturn9x> then I looked at the compiler code |
19:41:25 | FromDiscord | <leorize> gee I wonder why nim had unbalanced core devs |
19:41:26 | FromDiscord | <nocturn9x> and changed my mind. |
19:41:36 | FromDiscord | <nocturn9x> In reply to @leorize "gee I wonder why": let me gues |
19:41:38 | FromDiscord | <nocturn9x> (edit) "gues" => "guess" |
19:41:44 | FromDiscord | <nocturn9x> a certain someone going on a power trip |
19:41:51 | FromDiscord | <nocturn9x> something something big ego |
19:42:18 | FromDiscord | <leorize> I wish it was that simple |
19:42:23 | FromDiscord | <nocturn9x> "cool stuff" is cool |
19:42:28 | FromDiscord | <nocturn9x> but people like the stuff that works |
19:42:40 | FromDiscord | <nocturn9x> "cool" isn't a factor when deciding a language to actually use day to day |
19:43:07 | FromDiscord | <polylokh_39446> there needs to be something for a language to be worth using at all, vs. the status quo. |
19:43:12 | FromDiscord | <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:26 | FromDiscord | <tsoj> There is a reason though why people use Nim |
19:43:45 | FromDiscord | <tsoj> despite it bugs |
19:43:46 | FromDiscord | <nocturn9x> it's fast as fuck, it has that |
19:43:56 | FromDiscord | <nocturn9x> and it's better than C for most things |
19:44:21 | FromDiscord | <tsoj> It's better at quite a few things compared to alternatives such as Rust, C++ or python |
19:44:22 | FromDiscord | <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:27 | FromDiscord | <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:29 | FromDiscord | <nocturn9x> that tends to not make me like the language a lot |
19:44:52 | FromDiscord | <nocturn9x> In reply to @threefour "It's a systems language": it's also a system language that leaks thread variables |
19:45:05 | FromDiscord | <nocturn9x> which is just hilarious |
19:45:44 | FromDiscord | <nocturn9x> that's like one of the basic features of a systems language, good paralleliism |
19:45:46 | FromDiscord | <nocturn9x> (edit) "paralleliism" => "parallelism" |
19:45:48 | FromDiscord | <leorize> clean syntax, easily extensible with macros, all points that are still uncontested |
19:45:49 | FromDiscord | <nocturn9x> nim doesn't have that |
19:46:00 | FromDiscord | <nocturn9x> not even good |
19:46:02 | FromDiscord | <nocturn9x> but at least usable |
19:46:06 | FromDiscord | <nocturn9x> this is hot garbage lol |
19:46:10 | FromDiscord | <leorize> the implementation is just hot garbage |
19:46:17 | FromDiscord | <nocturn9x> that's what "this" is |
19:46:26 | FromDiscord | <ieltan> afaik mratsim is the threading guy, maybe he knows a trick or two to get thru this silly stuff |
19:46:48 | FromDiscord | <bosinski2023> In reply to @threefour "It's a systems language": Mojo might become a thing some day.. |
19:47:23 | FromDiscord | <ieltan> Mojo looks like rust pretending to be python 😅 |
19:48:14 | FromDiscord | <ieltan> Those people coming from python will have one hell of a reality check when mojo actually becomes a thing |
19:48:18 | FromDiscord | <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:24 | FromDiscord | <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:42 | FromDiscord | <leorize> you can link with mimalloc and hope to claw some performance back |
19:49:52 | FromDiscord | <nocturn9x> I was thinking about that |
19:49:56 | FromDiscord | <nocturn9x> how would I do that |
19:50:07 | FromDiscord | <nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=bOcCVyeKbrRb |
19:50:12 | FromDiscord | <nocturn9x> this is with malloc and refc |
19:50:20 | FromDiscord | <nocturn9x> so it's arc that's slow as fuck |
19:50:38 | FromDiscord | <leorize> refc is not thread safe, fwiw |
19:50:39 | FromDiscord | <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:45 | FromDiscord | <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:47 | FromDiscord | <nocturn9x> In reply to @leorize "refc is not thread": yeah I know I was just saying |
19:51:01 | FromDiscord | <nocturn9x> _neither is ARC_ |
19:51:08 | FromDiscord | <nocturn9x> except at least refc is not thread safe by design |
19:51:12 | FromDiscord | <nocturn9x> ACR is just borked. |
19:51:21 | FromDiscord | <nocturn9x> (edit) "ACR" => "ARC" |
19:51:28 | FromDiscord | <leorize> arc design is good tbf |
19:51:34 | FromDiscord | <nocturn9x> I don't deny it |
19:51:39 | FromDiscord | <nocturn9x> but designs don't run on computers |
19:51:42 | FromDiscord | <nocturn9x> implementations di |
19:51:43 | FromDiscord | <nocturn9x> (edit) "di" => "do" |
19:51:44 | * | def- joined #nim |
19:51:47 | FromDiscord | <nocturn9x> and the implementation _sucks_ |
19:51:54 | FromDiscord | <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:01 | FromDiscord | <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:15 | FromDiscord | <nocturn9x> it almost certainly won't just because I use top down inference all over the place |
19:52:44 | FromDiscord | <nocturn9x> https://github.com/Yardanico/mimalloc_nim |
19:52:47 | FromDiscord | <nocturn9x> how functional is that |
19:53:06 | FromDiscord | <bosinski2023> In reply to @nocturn9x "https://github.com/Yardanico/mimalloc_nim": MS-labs - good stuff... |
19:53:11 | FromDiscord | <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:17 | FromDiscord | <leorize> just install mimalloc on your compiler and `--passL:-lmimalloc` |
19:53:23 | FromDiscord | <nocturn9x> In reply to @leorize "just install mimalloc on": k |
19:53:24 | FromDiscord | <threefour> Not insulting your approach, just making a distinction. |
19:53:35 | FromDiscord | <nocturn9x> In reply to @threefour "Not insulting your approach,": dw you can insult my approach |
19:53:35 | FromDiscord | <leorize> (edit) "compiler" => "computer" |
19:53:38 | FromDiscord | <nocturn9x> it's probably not the best |
19:53:44 | FromDiscord | <nocturn9x> but the thing is, it's not my code that's segfaulting |
19:53:48 | FromDiscord | <nocturn9x> it's nim's allocator |
19:54:00 | FromDiscord | <nocturn9x> the problem is a hard bug in ARC, yes |
19:54:05 | FromDiscord | <nocturn9x> in fact there is _two_ |
19:54:19 | FromDiscord | <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:32 | FromDiscord | <nocturn9x> In reply to @tsoj "Honestly I wouldn't bother": you're doing pseudolegal in nalwald afaik |
19:54:33 | FromDiscord | <leorize> for the most part, it's just that arc not being atomic messes up ref counting when you move references |
19:54:42 | FromDiscord | <nocturn9x> In reply to @leorize "for the most part,": which makes sense |
19:54:43 | FromDiscord | <nocturn9x> but then |
19:54:53 | FromDiscord | <nocturn9x> I would expect `--mm:atomicArc` |
19:54:54 | FromDiscord | <tsoj> In reply to @nocturn9x "you're doing pseudolegal in": Genrally the movegen will be at most like 10% of your engine |
19:54:56 | FromDiscord | <nocturn9x> to, you know |
19:54:57 | FromDiscord | <nocturn9x> be atomic? |
19:55:04 | FromDiscord | <leorize> is that tested? |
19:55:11 | FromDiscord | <nocturn9x> good question |
19:55:14 | FromDiscord | <nocturn9x> clearly not |
19:55:18 | FromDiscord | <nocturn9x> (edit) "clearly not ... " added "(enough)" |
19:56:06 | FromDiscord | <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:30 | FromDiscord | <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:33 | FromDiscord | <nocturn9x> the proper way to use it is pray |
19:56:40 | FromDiscord | <leorize> you just need to hold nim's hand really well |
19:56:40 | FromDiscord | <threefour> Lmao |
19:56:57 | FromDiscord | <nocturn9x> In reply to @leorize "you just need to": and hope ARC doesn't just destroy your refs |
19:56:58 | FromDiscord | <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:02 | FromDiscord | <nocturn9x> refs which it should NOT own by the way |
19:57:22 | FromDiscord | <nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=rtqTCSEApHhd |
19:57:26 | FromDiscord | <nocturn9x> mimalloc is great at least |
19:57:36 | FromDiscord | <nocturn9x> In reply to @polylokh_39446 "the other thing to": that's annoying and stupid |
19:57:43 | FromDiscord | <nocturn9x> I'd use Rust if I wanted to do it the rust way |
19:57:47 | FromDiscord | <nocturn9x> I'm using nim for a reason |
19:57:54 | FromDiscord | <nocturn9x> but that would be a solution I guess |
19:58:36 | FromDiscord | <tsoj> sent a code paste, see https://play.nim-lang.org/#pasty=aDScLhYmuJEA |
19:58:45 | FromDiscord | <nocturn9x> yes, that too. |
19:58:56 | FromDiscord | <nocturn9x> and the fun shit is it doesn't matter if _you_ don't use any threadvars |
19:59:00 | FromDiscord | <nocturn9x> so long as any of your dependencies |
19:59:02 | FromDiscord | <nocturn9x> direct or indirect |
19:59:05 | FromDiscord | <nocturn9x> are using threadvars |
19:59:08 | FromDiscord | <nocturn9x> then your code leaks memory |
19:59:12 | FromDiscord | <nocturn9x> isn't that GREAT?↵ù |
19:59:15 | FromDiscord | <nocturn9x> (edit) "GREAT?↵ù" => "GREAT?" |
20:00:16 | FromDiscord | <nocturn9x> In reply to @tsoj "passing refs between threads": lmfao that actually reproduces the issue perfectly |
20:00:21 | FromDiscord | <nocturn9x> it leaks gigabytes of RAM basically immediately |
20:00:25 | FromDiscord | <nocturn9x> and that's in _debug mode_ |
20:01:03 | FromDiscord | <tsoj> I could make it leak terabytes if i wanted to, but that wouldn't really be a challend |
20:01:05 | FromDiscord | <tsoj> (edit) "challend" => "challenge" |
20:01:13 | FromDiscord | <nocturn9x> mfw oom_killer |
20:01:15 | FromDiscord | <nocturn9x> (edit) "oom_killer" => "oom_killer:" |
20:01:33 | FromDiscord | <tsoj> you assume I don't have 10 TB RAM? |
20:01:36 | FromDiscord | <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:47 | FromDiscord | <nocturn9x> In reply to @polylokh_39446 "^ yep, but that": yeah, that |
20:01:56 | FromDiscord | <nocturn9x> would've loved to know that _before_ I wrote a chess engine in it |
20:02:04 | FromDiscord | <nocturn9x> and like other 15 thousand lines of code in other projects |
20:02:10 | FromDiscord | <nocturn9x> but hey better late than never am I right |
20:02:38 | FromDiscord | <nocturn9x> and keep in mind I've reduced refs to almost zero |
20:02:41 | FromDiscord | <tsoj> Which language do you wanna use now? |
20:02:45 | FromDiscord | <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:45 | FromDiscord | <nocturn9x> there's like, actually 2 or 3 refs in the entire program |
20:02:45 | FromDiscord | <bosinski2023> sent a code paste, see https://play.nim-lang.org/#pasty=xhCYZwDEXhOl |
20:03:07 | FromDiscord | <nocturn9x> In reply to @tsoj "Which language do you": if the issue is fixed, then I will just stick with nim |
20:03:13 | FromDiscord | <nocturn9x> way too much work to redo this |
20:03:17 | FromDiscord | <nocturn9x> (edit) "this" => "all the movegen" |
20:03:30 | FromDiscord | <nocturn9x> mimalloc gave me the performance back |
20:03:33 | FromDiscord | <tsoj> sent a code paste, see https://play.nim-lang.org/#pasty=twUrgAAFgvqP |
20:03:47 | FromDiscord | <tsoj> i.e. it's at least "effectively" a memory leak |
20:03:50 | FromDiscord | <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:59 | FromDiscord | <leorize> if mimalloc solves it for you then it sounds like you just need a memory pool |
20:04:18 | FromDiscord | <bosinski2023> In reply to @leorize "if mimalloc solves it": exactly |
20:04:58 | FromDiscord | <nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=XmcNlZmIkaRp |
20:05:38 | FromDiscord | <nocturn9x> In reply to @leorize "if mimalloc solves it": it sounds like I need a language that works >:D |
20:06:17 | FromDiscord | <nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=mHMaMOWOlHyv |
20:07:06 | FromDiscord | <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:46 | FromDiscord | <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:00 | FromDiscord | <nocturn9x> I know neither C++ nor Rust |
20:09:14 | FromDiscord | <nocturn9x> nor do I plan on using Rust, the borrow checker can suck it |
20:09:18 | FromDiscord | <tsoj> yeah |
20:09:28 | FromDiscord | <tsoj> cppfront? |
20:09:36 | FromDiscord | <nocturn9x> rust was a very good idea implemented very poorly |
20:09:43 | FromDiscord | <nnsee> In reply to @nocturn9x "by "leaks memory" I": you're not looking at virtual memory are you |
20:09:48 | FromDiscord | <tsoj> i actually wrote a little move gen in cppfront |
20:10:01 | FromDiscord | <nocturn9x> In reply to @nnsee "you're not looking at": I'm not entirely sure what htop is showing there |
20:10:06 | FromDiscord | <nocturn9x> it's probably not virtual memory |
20:10:23 | FromDiscord | <nocturn9x> the point is nim 100% leaks memory, the issue proves it |
20:10:29 | FromDiscord | <nocturn9x> and my problems corroborate it |
20:10:34 | FromDiscord | <nnsee> i'm fairly sure it does show virtual memory by default |
20:11:11 | FromDiscord | <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:37 | FromDiscord | <tsoj> When I look at the "RES" column in htop it leak |
20:11:38 | FromDiscord | <tsoj> (edit) "leak" => "leaks" |
20:12:39 | FromDiscord | <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:55 | FromDiscord | <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:41 | FromDiscord | <nnsee> In reply to @nocturn9x "the point is nim": that's not to say i'm saying you're wrong here |
20:14:45 | FromDiscord | <nnsee> it's likely you're right |
20:14:54 | FromDiscord | <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:54 | FromDiscord | <nnsee> i'm just saying htop can be misleading |
20:14:58 | FromDiscord | <nnsee> 12G is alarming |
20:15:36 | FromDiscord | <nocturn9x> if it weren't leaking |
20:15:39 | FromDiscord | <nocturn9x> it wouldn't be writing to the swap |
20:15:41 | FromDiscord | <nocturn9x> which it is |
20:15:50 | FromDiscord | <nocturn9x> so the memory is actual physical memory being used |
20:15:58 | FromDiscord | <nnsee> sure |
20:16:11 | FromDiscord | <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:33 | FromDiscord | <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:27 | FromDiscord | <nocturn9x> I have decided I will rewrite my engine entirely in malebolgia |
20:17:33 | FromDiscord | <nocturn9x> see you in 2^32 years when I'm done |
20:17:39 | FromDiscord | <nocturn9x> (edit) "malebolgia" => "malbolge" |
20:17:46 | FromDiscord | <Elegantbeef> "Nim threads do not destruct thread vars and does not call the thread Orc before closing" is the issue here |
20:18:00 | FromDiscord | <tsoj> In reply to @nocturn9x "I have decided I": yeah bvefore the edit that was confusing lol |
20:18:18 | FromDiscord | <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:37 | FromDiscord | <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:16 | FromDiscord | <Phil> I just want a backend thread for GUI applications 😢 |
20:19:21 | FromDiscord | <nocturn9x> In reply to @nnsee "": this but use nim code in the examples |
20:20:26 | FromDiscord | <Phil> @odexine I think I got the basics of a reactivex implementation down pat now if you're curious |
20:20:31 | FromDiscord | <bosinski2023> In reply to @Elegantbeef ""Nim threads do not": that sounds as if it was not terribly complicated to fix ? |
20:20:36 | FromDiscord | <Phil> The answer appears to really just be more closures on top of the closures I was using |
20:20:38 | FromDiscord | <Phil> Also more closures |
20:20:42 | FromDiscord | <Phil> And did I mention closures? |
20:20:48 | FromDiscord | <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:24 | FromDiscord | <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:35 | FromDiscord | <Elegantbeef> Whoops |
20:22:10 | FromDiscord | <bosinski2023> In reply to @Elegantbeef "> that sounds as": so, we all should be nice with, maybe jmgomez ? |
20:22:40 | FromDiscord | <nocturn9x> In reply to @polylokh_39446 "I'm explaining why this": what's alarming isn't the bug itself, I agree |
20:22:47 | FromDiscord | <nocturn9x> it's the fact that if this went undetected for so long |
20:22:53 | FromDiscord | <nocturn9x> no one is actually using these features |
20:22:57 | FromDiscord | <nocturn9x> and no one is testing them properly |
20:23:15 | FromDiscord | <ElegantBeef> Matrix bridge dieded |
20:23:20 | FromDiscord | <nocturn9x> I wonder how exactly higher level libraries deal with this |
20:23:25 | FromDiscord | <nocturn9x> like weave or malebolgia |
20:23:27 | FromDiscord | <nocturn9x> do they just leak shit |
20:23:29 | FromDiscord | <ElegantBeef> Yea there should be a hellgrind and valgrind test to ensure memory is freed |
20:23:35 | FromDiscord | <nocturn9x> how did anyone not notice |
20:23:49 | FromDiscord | <ElegantBeef> Not many people have global threadvars is the answer |
20:23:52 | FromDiscord | <nocturn9x> or do they not technically leak because they reuse the same thread objects |
20:24:00 | FromDiscord | <nocturn9x> In reply to @elegantbeef "Not many people have": _bruh |
20:24:01 | FromDiscord | <nocturn9x> (edit) "_bruh" => "_bruh_" |
20:24:19 | FromDiscord | <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:20 | FromDiscord | <ElegantBeef> Hey I agree with you that it should be well tested |
20:24:30 | FromDiscord | <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:42 | FromDiscord | <ElegantBeef> But the amount of code that has global threadvars that have substantial data I imagine is not that much |
20:24:44 | FromDiscord | <ElegantBeef> I could be wrong |
20:24:54 | FromDiscord | <nocturn9x> oh |
20:25:02 | FromDiscord | <nocturn9x> there is a nim talk at the pycon I'm going to this month |
20:25:06 | FromDiscord | <nocturn9x> it's gonna be _fun_ |
20:25:11 | FromDiscord | <tsoj> What exactly is meant with "global threadvars"? |
20:25:15 | FromDiscord | <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:23 | FromDiscord | <nocturn9x> In reply to @tsoj "What exactly is meant": a global variable marked with the thread pragma |
20:25:27 | FromDiscord | <ElegantBeef> A global threadvar is a global variable that is unique per thread |
20:25:37 | FromDiscord | <ElegantBeef> This is not properly destructed and leaks |
20:25:47 | FromDiscord | <nocturn9x> no, it's not improperly destructed |
20:25:51 | FromDiscord | <nocturn9x> or rather, destroyed |
20:25:51 | FromDiscord | <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:54 | FromDiscord | <nocturn9x> it's not destroyed at all |
20:25:58 | FromDiscord | <ElegantBeef> Who s aid it is properly destructed? |
20:26:01 | FromDiscord | <ElegantBeef> (edit) "s aid" => "said" |
20:26:05 | FromDiscord | <bosinski2023> In reply to @elegantbeef "A global threadvar is": is that possible at all ? |
20:26:12 | FromDiscord | <nocturn9x> for something to be done improperly |
20:26:15 | FromDiscord | <nocturn9x> something has to be done |
20:26:19 | FromDiscord | <nocturn9x> nim is doing exactly fuck all |
20:26:21 | FromDiscord | <Phil> In reply to @polylokh_39446 "<https://github.com/nim-lang/Nim/issues/23165> ment": When assigning a var destroy is called |
20:26:23 | FromDiscord | <tsoj> sent a code paste, see https://play.nim-lang.org/#pasty=ZPTiXSgWLGnX |
20:26:25 | FromDiscord | <ElegantBeef> Which is not properly destructing |
20:26:26 | FromDiscord | <Phil> That doesn't quite count |
20:26:37 | FromDiscord | <ElegantBeef> Properly destructing would be to call `=destroy` |
20:26:49 | FromDiscord | <ElegantBeef> No that's not a threadvar |
20:27:03 | FromDiscord | <polylokh_39446> <https://nim-lang.org/docs/manual.html#threads-threadvar-pragma> ↵`var checkpoints {.threadvar.}: seq[string]` |
20:27:20 | FromDiscord | <tsoj> well, but that example leaks too |
20:27:22 | FromDiscord | <ElegantBeef> sent a code paste, see https://play.nim-lang.org/#pasty=RkbCbTamqetp |
20:27:45 | FromDiscord | <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:55 | FromDiscord | <bosinski2023> sent a code paste, see https://play.nim-lang.org/#pasty=JMRrBnKtVDMq |
20:28:15 | FromDiscord | <Phil> sent a code paste, see https://play.nim-lang.org/#pasty=DrtnfyasMRHT |
20:28:20 | FromDiscord | <ElegantBeef> In reply to @tsoj "But is `l` here": `All heap blocks were freed -- no leaks are possible` |
20:28:32 | FromDiscord | <ElegantBeef> If you're going to say something is leaking atleast test it |
20:29:02 | FromDiscord | <ElegantBeef> `nim c -d:useMalloc yourProg` `valgrind yourProg` |
20:29:19 | FromDiscord | <tsoj> i mean yeah, -d:useMalloc fixes it |
20:29:21 | FromDiscord | <nocturn9x> well well well |
20:29:27 | FromDiscord | <nocturn9x> looks like it ain't leaking anymore |
20:29:27 | FromDiscord | <ElegantBeef> Then it's not leaking |
20:29:39 | FromDiscord | <nocturn9x> it is segfaulting though |
20:29:44 | FromDiscord | <nocturn9x> thanks nim lovely |
20:29:49 | FromDiscord | <tsoj> Well, but why will it use swap if I doN#t have enough memory? |
20:30:02 | FromDiscord | <ElegantBeef> Cause Nim's allocator sucks |
20:30:06 | FromDiscord | <ElegantBeef> It has multiple issues |
20:30:14 | FromDiscord | <tsoj> yeah, but that I call leaking memory |
20:30:22 | * | def- quit (Quit: -) |
20:30:28 | FromDiscord | <polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=pYckVlbMHqfL |
20:30:31 | FromDiscord | <ElegantBeef> It's unrelated to threading and just issues with the allocator |
20:30:40 | FromDiscord | <ElegantBeef> `useMalloc` is the path to sanity |
20:30:52 | FromDiscord | <tsoj> In reply to @elegantbeef "It's unrelated to threading": Ahh I see |
20:30:52 | FromDiscord | <nocturn9x> okay admittedly that was my fault |
20:30:54 | FromDiscord | <nocturn9x> was using refc |
20:30:59 | FromDiscord | <nocturn9x> upsie |
20:31:32 | FromDiscord | <tsoj> In reply to @elegantbeef "It's unrelated to threading": what issue is that specifically? is that documented somewhere? |
20:31:34 | FromDiscord | <nocturn9x> yeah no more leaks it seems like |
20:31:41 | FromDiscord | <nocturn9x> In reply to @tsoj "what issue is that": ha |
20:31:43 | FromDiscord | <nocturn9x> haha |
20:31:44 | FromDiscord | <nocturn9x> hahahaha |
20:31:47 | FromDiscord | <nocturn9x> documented |
20:31:51 | FromDiscord | <nocturn9x> funny words magic man |
20:31:53 | FromDiscord | <ElegantBeef> I think there is an issue started by guzba about the allocator |
20:32:13 | FromDiscord | <ElegantBeef> There is also a post suggesting to use malloc for the time being on 2.0 |
20:32:21 | FromDiscord | <ElegantBeef> Why it's not the default then in 2.0.4 is beyond me |
20:32:29 | FromDiscord | <nocturn9x> it is beyond me as well |
20:32:39 | FromDiscord | <nocturn9x> especially considering mimalloc makes it fast |
20:32:59 | FromDiscord | <ElegantBeef> Araq just wants to use his TLSF allocator for not good reason when mimalloc exists |
20:33:04 | FromDiscord | <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:13 | FromDiscord | <nocturn9x> In reply to @elegantbeef "Araq just wants to": I know the reason |
20:33:15 | FromDiscord | <nocturn9x> it's called NIH |
20:33:21 | FromDiscord | <tsoj> this is why I have -d:useMalloc in Nalwald in the first palce |
20:33:22 | FromDiscord | <ElegantBeef> "No good reason" |
20:33:23 | FromDiscord | <nocturn9x> araq clearly suffers from a severe case of NIH syndrome |
20:33:37 | FromDiscord | <nocturn9x> In reply to @elegantbeef ""No good reason"": if you talk with a fool, they'll think you're the fool |
20:33:42 | FromDiscord | <nocturn9x> good is very subjective here, clearly |
20:33:47 | FromDiscord | <polylokh_39446> this one <https://github.com/nim-lang/Nim/issues/22510> ? |
20:33:57 | FromDiscord | <ElegantBeef> Yea |
20:34:43 | FromDiscord | <ElegantBeef> The issue comes down to the allocator not reusing blocks(or pages) and just allocating more |
20:34:51 | FromDiscord | <nocturn9x> what |
20:34:57 | FromDiscord | <nocturn9x> isn't that like the whole purpose of an allocator |
20:35:03 | FromDiscord | <nocturn9x> to efficiently manage memory |
20:35:04 | FromDiscord | <ElegantBeef> It's supposed to reuse them |
20:35:10 | FromDiscord | <ElegantBeef> But it does not |
20:35:13 | FromDiscord | <nocturn9x> _cool_ |
20:35:19 | FromDiscord | <nocturn9x> any known reason why? |
20:35:20 | FromDiscord | <ElegantBeef> <https://github.com/nim-lang/Nim/commit/a41b4fa3eed74b4ffbfb97c3c049ec9c87c73012> |
20:35:37 | FromDiscord | <polylokh_39446> probably some idea like having better cache coherence for each individual thread |
20:35:47 | FromDiscord | <ElegantBeef> It's not intentional |
20:35:49 | FromDiscord | <nocturn9x> ah, compensateCounters |
20:35:54 | FromDiscord | <nocturn9x> the fucker was segfaulting my code before |
20:35:57 | FromDiscord | <ElegantBeef> It's a bug in the Nim TSLF implementation |
20:36:38 | FromDiscord | <bosinski2023> In reply to @elegantbeef "It's a bug in": is reuse deferred or not happening at all ? |
20:36:43 | FromDiscord | <ElegantBeef> tlsf 😄 |
20:37:03 | FromDiscord | <ElegantBeef> It happens, but only for small allocations |
20:37:07 | FromDiscord | <nocturn9x> sent a long message, see https://pasty.ee/zjQWQFtLnHIC |
20:37:08 | FromDiscord | <nocturn9x> _rofl_ |
20:37:09 | FromDiscord | <ElegantBeef> Larger allocations are causing issues |
20:37:18 | FromDiscord | <nocturn9x> doesn't seem like the only borked impl |
20:37:22 | FromDiscord | <nocturn9x> but hey at least that's documented |
20:38:04 | FromDiscord | <nocturn9x> cool another segfault |
20:38:10 | FromDiscord | <nocturn9x> not my fault this time |
20:39:26 | FromDiscord | <nocturn9x> I am so done with Nim |
20:49:42 | FromDiscord | <tsoj> In reply to @nocturn9x "not my fault this": What is it this time? |
20:49:54 | FromDiscord | <nocturn9x> I HAVE NO IDEA |
20:49:55 | * | def- joined #nim |
20:49:56 | FromDiscord | <Phil> On the bright side of things... somebody want to write docs for rex? |
20:50:26 | FromDiscord | <Phil> I mean, I'll likely end up doing it myself anyway. But hey, can't hurt to ask |
20:50:28 | FromDiscord | <Elegantbeef> We don't do that here |
20:50:44 | FromDiscord | <tsoj> In reply to @nocturn9x "I HAVE NO IDEA": How do you know if it's Nim then? |
20:50:51 | FromDiscord | <nocturn9x> because it wasn't doing it before |
20:50:55 | FromDiscord | <nocturn9x> and it's doing it now |
20:50:55 | FromDiscord | <Phil> That must be a very exclusionary we because I do that here very much |
20:50:59 | FromDiscord | <nocturn9x> only thing that changed is the options |
20:51:02 | FromDiscord | <nocturn9x> (edit) "only thing that changed is the ... options" added "compilation" |
20:51:16 | FromDiscord | <tsoj> In reply to @tsoj "Well, now is the": Also^ |
20:51:28 | FromDiscord | <tsoj> In reply to @nocturn9x "only thing that changed": what did you cange? |
20:51:43 | FromDiscord | <nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=AbAxzVzzYWrH |
20:51:45 | FromDiscord | <nocturn9x> this is my nim.cfg |
20:51:59 | * | disso-peach quit (Quit: Leaving) |
20:51:59 | FromDiscord | <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:25 | FromDiscord | <tsoj> Why do you use `-d:useMalloc` and not `-d:mimalloc`? |
20:53:46 | FromDiscord | <Elegantbeef> cause `-d:mimalloc` doesn't exist |
20:54:02 | FromDiscord | <Elegantbeef> `-d:useMalloc` uses `malloc` which can be replaced by linking |
20:54:28 | FromDiscord | <nocturn9x> ^ |
20:54:47 | FromDiscord | <nocturn9x> do I seriously have to use boehm |
20:54:56 | FromDiscord | <nocturn9x> that has awful performance |
20:55:12 | FromDiscord | <tsoj> Have you tried without mimalloc and just -d:useMalloc? |
20:55:16 | FromDiscord | <nocturn9x> will do |
20:55:57 | FromDiscord | <nocturn9x> trying rn |
20:56:13 | FromDiscord | <tsoj> If you gonna have any slightly expensive eval, the speed difference will probably be not more than like 10 Elo |
20:56:24 | FromDiscord | <nocturn9x> fair enough |
20:56:44 | FromDiscord | <nocturn9x> wow it segfaults much quicker with malloc |
20:56:47 | FromDiscord | <tsoj> lol |
20:57:06 | FromDiscord | <ieltan> 😸 |
20:57:22 | FromDiscord | <nocturn9x> let's try boehm |
20:57:27 | FromDiscord | <nocturn9x> just for good measure |
20:57:40 | FromDiscord | <nocturn9x> cool and easy way to lose 30% of the performance |
20:59:20 | FromDiscord | <nocturn9x> let's not even mention that my SPRT is not gaining for shit |
20:59:28 | FromDiscord | <nocturn9x> but whatever |
20:59:40 | FromDiscord | <nocturn9x> that at least isn't Nim's fault |
21:01:07 | FromDiscord | <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:26 | FromDiscord | <nocturn9x> cool boehm crashes too |
21:08:30 | FromDiscord | <nocturn9x> juust great |
21:11:27 | * | def- quit (Quit: -) |
21:12:16 | * | def- joined #nim |
21:51:32 | FromDiscord | <nocturn9x> yeah okay I'm moving away from nim |
21:51:35 | FromDiscord | <nocturn9x> this just doesn't work |
21:52:00 | FromDiscord | <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:34 | FromDiscord | <nocturn9x> so it looks like nimskull only supports ARC and ORC |
21:57:41 | FromDiscord | <nocturn9x> does it mean it's maybe somehow less borked |
21:58:48 | FromDiscord | <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:08 | FromDiscord | <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:40 | FromDiscord | <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:49 | FromDiscord | <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:10 | FromDiscord | <polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=OBtjlErSKjeX |
23:08:19 | * | lain joined #nim |
23:43:57 | FromDiscord | <Robyn [She/Her]> In reply to @amjadhd "Is there an equivalent": `str &= n & ' '`? |
23:44:23 | FromDiscord | <Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=iReydzzoylpc |
23:52:20 | FromDiscord | <polylokh_39446> I didn't even notice the n there. If it's `Appends count copies of character ch.`, there isn't |