| 01:37:00 | * | rockcavera quit (Ping timeout: 268 seconds) |
| 01:42:49 | * | rockcavera joined #nim |
| 01:42:49 | * | rockcavera quit (Changing host) |
| 01:42:49 | * | rockcavera joined #nim |
| 01:58:53 | * | SchweinDeBurg quit (Quit: WeeChat 4.4.0-dev) |
| 03:10:06 | * | rockcavera quit (Remote host closed the connection) |
| 03:11:03 | * | rockcavera joined #nim |
| 03:48:01 | FromDiscord | <mts508> sent a code paste, see https://play.nim-lang.org/#pasty=nQbxDgUo |
| 03:48:20 | FromDiscord | <Elegantbeef> Niim has no prefix operators |
| 03:48:28 | FromDiscord | <Elegantbeef> You could do `100'pct` |
| 03:50:02 | FromDiscord | <mts508> Oh well i guess i'll stick with that, thanks! |
| 03:50:16 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=KBjBrjtK |
| 03:50:18 | FromDiscord | <Elegantbeef> Works fine |
| 04:00:44 | * | SchweinDeBurg joined #nim |
| 05:20:09 | * | nyeaa49284230101 quit (Read error: Connection reset by peer) |
| 05:20:31 | * | nyeaa49284230101 joined #nim |
| 05:59:26 | * | rockcavera quit (Remote host closed the connection) |
| 06:06:02 | * | ntat joined #nim |
| 06:43:29 | FromDiscord | <pmunch> Did something happen to `nimTestErrorFlag`? |
| 06:43:46 | FromDiscord | <pmunch> Suddenly my MAPM project fails because it's not defined |
| 06:48:56 | FromDiscord | <pmunch> Hmm, since the same Nim version produced the error I figured it must've been the GCC version. Following the steps in https://forum.nim-lang.org/t/11587 helped |
| 06:49:26 | FromDiscord | <Elegantbeef> Is it just a case you read the last error message instead of the first from the C compiler? |
| 06:49:56 | FromDiscord | <Elegantbeef> I know C compilers really like going "Here is the problem, oh and here is a problem that makes no sense, but only cause we attempted to continue semantic analysis" |
| 06:53:15 | FromDiscord | <pmunch> Not really, this is the entire C compiler output: https://pasty.ee/ZAjdoCch |
| 06:56:07 | FromDiscord | <pmunch> Hmm, for some reason what I was trying to do (use `--wrap` to wrap `mmap`) doesn't work.. |
| 06:58:16 | FromDiscord | <Elegantbeef> Looking up wrap, interesting |
| 06:58:23 | FromDiscord | <Elegantbeef> I need this for my really dumb ldd 😄 |
| 07:17:57 | Amun-Ra | Elegantbeef: staticRead"foo" works like a prefix operator… ;) |
| 07:18:15 | FromDiscord | <Elegantbeef> That's a generalized string syntax and not a prefix operator |
| 07:18:25 | Amun-Ra | yes |
| 07:18:32 | FromDiscord | <Elegantbeef> If you think about it that's actually an infix operator 😛 |
| 07:18:44 | Amun-Ra | hehe, true |
| 07:46:45 | FromDiscord | <Elegantbeef> After taking a shot at it nope wrap is not what I need for rdldd, but I did make it print full paths for `dlopen` |
| 07:47:21 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=rmKJNmFc |
| 07:49:43 | FromDiscord | <Elegantbeef> This does require running the program for a short period to get the dependencies, but it works with Nim's `dynlib` pragma |
| 08:02:52 | NimEventer | New thread by cmc: Realtime thread in Nim (SCHED_FIFO) in Linux, see https://forum.nim-lang.org/t/11776 |
| 08:08:07 | FromDiscord | <pmunch> In reply to @Elegantbeef "After taking a shot": What's this rdldd project? I was trying to wrap mmap to see if I could get Nim to allocate all memory shared 😅 |
| 08:33:59 | * | coldfeet joined #nim |
| 08:36:04 | FromDiscord | <Elegantbeef> @pmunch I wanted to play around with LD\_PRELOAD so wrote a LDD like utillity |
| 08:37:08 | FromDiscord | <Elegantbeef> It also detects libraries that are dlopen'd so it supports Nim's binaries |
| 08:39:23 | * | xet7 joined #nim |
| 08:39:56 | * | coldfeet quit (Remote host closed the connection) |
| 08:54:55 | FromDiscord | <pmunch> Nice |
| 09:25:54 | NimEventer | New thread by physicphy: How can be compile nim by nvc compiler?, see https://forum.nim-lang.org/t/11778 |
| 09:30:55 | FromDiscord | <asbjorn2> I'm realizing that there's probably something very fundamental that I don't understand about managing threads in nim |
| 09:31:07 | FromDiscord | <asbjorn2> sent a code paste, see https://play.nim-lang.org/#pasty=aVQWiAZF |
| 09:31:28 | FromDiscord | <asbjorn2> (edit) "https://play.nim-lang.org/#pasty=RUcvHDXa" => "https://play.nim-lang.org/#pasty=uRGTdMvm" |
| 09:31:30 | FromDiscord | <asbjorn2> (edit) "https://play.nim-lang.org/#pasty=sJIqporb" => "https://play.nim-lang.org/#pasty=aeJZNLMJ" |
| 09:31:46 | FromDiscord | <asbjorn2> I can't seem to figure out why this example is failing with a `SIGSEGV: Illegal storage access. (Attempt to read from nil?)` |
| 09:32:34 | FromDiscord | <asbjorn2> (edit) "https://play.nim-lang.org/#pasty=dXxtLxrd" => "https://play.nim-lang.org/#pasty=qdDQrdbz" |
| 09:33:03 | FromDiscord | <ieltan> I think you can't return a `Thread` like that |
| 09:33:22 | FromDiscord | <asbjorn2> then what should I do with it? |
| 09:33:31 | FromDiscord | <ieltan> that `var thread: Thread[string]` should be a global |
| 09:34:03 | FromDiscord | <asbjorn2> in the example that could make sense, sure.. but what if I'm working in a context where I need to dynamically start threads. I might need to have more than one |
| 09:34:16 | FromDiscord | <ieltan> In reply to @ieltan "that `var thread: Thread[string]`": which makes your `new_model_worker()` useless, :p |
| 09:34:53 | FromDiscord | <asbjorn2> it seems like you're suggesting that all nim programs should have a constant number of threads. |
| 09:34:59 | FromDiscord | <asbjorn2> I'm probably misunderstanding something |
| 09:35:55 | FromDiscord | <ieltan> In reply to @asbjorn2 "in the example that": for dynamically spawning threads either create a global `array[NUM, Thread[T]]` and reuse those threads, or use a threadpool and `spawn` them when you need |
| 09:36:57 | FromDiscord | <ieltan> the bad thing is that threading in nim sort of sucks |
| 09:37:09 | FromDiscord | <ieltan> the good thing is there is no shortage of threadpools in Nim |
| 09:38:57 | FromDiscord | <ieltan> you have nim-taskpools, weave, weave-io, the old decrepit `std/threadpool` of course and the shiny `malebolgia` that araq made but you'll be amongst the few ones to tests it so be ready to create github issues... |
| 09:40:28 | FromDiscord | <asbjorn2> tbh I'm a bit frustrated that this `Thread`-objects-must-be-global thing was difficult to find. is it documented anywhere? |
| 09:40:42 | FromDiscord | <asbjorn2> It seems like the latest editinon of araq's nim book doesn't even mention it: https://media.discordapp.net/attachments/371759389889003532/1252196211897929799/image.png?ex=66715619&is=66700499&hm=28c0670f712139401ce621d4008f2336a97958bd0f0776f7adf0e9685f32c5c9& |
| 09:40:51 | FromDiscord | <asbjorn2> it just calls it "highly recommended" |
| 09:41:24 | FromDiscord | <ieltan> oh |
| 09:41:29 | FromDiscord | <asbjorn2> are there any other objects which must be declared globally? |
| 09:41:46 | FromDiscord | <ieltan> no it's not a rule |
| 09:41:54 | FromDiscord | <ieltan> more like araq own idioms |
| 09:42:02 | FromDiscord | <ieltan> sent a code paste, see https://play.nim-lang.org/#pasty=odVGblsF |
| 09:42:04 | FromDiscord | <ieltan> this works |
| 09:42:09 | FromDiscord | <ieltan> lol |
| 09:42:22 | FromDiscord | <asbjorn2> o_0 |
| 09:42:41 | FromDiscord | <ieltan> but it's really distasteful so i didn't think it was possible, it does make sense though.. |
| 09:42:42 | FromDiscord | <asbjorn2> here I was, thinking that `result` was just an implicit var declaration |
| 09:42:59 | FromDiscord | <asbjorn2> I'm slowly finding out that a lot of things I assumed to be true about nim aren't |
| 09:43:00 | FromDiscord | <ieltan> `result` is Nim's RVO |
| 09:43:44 | FromDiscord | <fabric.input_output> In reply to @ieltan "this works": maybe it has something to do with move/copy semantics? |
| 09:45:06 | FromDiscord | <ieltan> sent a code paste, see https://play.nim-lang.org/#pasty=mGizawrE |
| 09:45:40 | FromDiscord | <ieltan> (edit) "https://play.nim-lang.org/#pasty=etpigYjA" => "https://play.nim-lang.org/#pasty=CeSwiPzk" |
| 09:45:41 | FromDiscord | <ieltan> so |
| 09:45:55 | FromDiscord | <asbjorn2> would that still work if I called `new_model_worker` from somewhere other than global scope? |
| 09:46:00 | FromDiscord | <ieltan> i was right that you cannot return a thread |
| 09:46:11 | FromDiscord | <ieltan> but you can work around it like that using RVO |
| 09:46:21 | FromDiscord | <asbjorn2> 👍 |
| 09:46:35 | FromDiscord | <asbjorn2> can you return an object which contains a thread? |
| 09:46:44 | FromDiscord | <ieltan> RVO means Return-Value-Optimization fwiw |
| 09:46:52 | FromDiscord | <asbjorn2> yeah I found the wikipedia article 😅 |
| 09:46:54 | FromDiscord | <ieltan> In reply to @asbjorn2 "can you return an": never tested it |
| 09:46:59 | FromDiscord | <ieltan> i think you can |
| 09:47:01 | FromDiscord | <asbjorn2> I don't have a c++ background, but I'm learning a lot |
| 09:47:04 | FromDiscord | <ieltan> if you try hard enough :p |
| 09:47:25 | FromDiscord | <ieltan> meh, dont even need a c++ background |
| 09:47:28 | FromDiscord | <asbjorn2> this whole thing comes from me trying to rewrite all my threading code to avoid using `ref objects`, as someone in this channel suggested a few days ago |
| 09:47:32 | FromDiscord | <fabric.input_output> I think the problem might have been with moving the thread around. RVO just prevents that but don't take my word for it |
| 09:47:36 | FromDiscord | <ieltan> this idiom is omnipresent in C too |
| 09:47:45 | FromDiscord | <ieltan> passing a pointer to a function |
| 09:47:47 | FromDiscord | <ieltan> wow |
| 09:47:49 | FromDiscord | <asbjorn2> I sued to do it by having a `Thread` inside a `ref object` |
| 09:47:52 | FromDiscord | <asbjorn2> (edit) "sued" => "used" |
| 09:48:17 | FromDiscord | <ieltan> ☹️ |
| 09:48:18 | FromDiscord | <asbjorn2> but then someone told me that was bad. I was having a lot of memory issues- and I think that it even worked in the first place was mostly luck |
| 09:48:22 | FromDiscord | <ieltan> dont do this yeah |
| 09:48:23 | FromDiscord | <ieltan> lol |
| 09:48:24 | FromDiscord | <fabric.input_output> I think it is better to use `out` parameter than relying on implicit RVO for thread stuff |
| 09:48:35 | FromDiscord | <fabric.input_output> (edit) "I think it is better to use ... `out`" added "an" |
| 09:48:38 | FromDiscord | <ieltan> i always forget `out` exists |
| 09:51:40 | FromDiscord | <ieltan> In reply to @asbjorn2 "this whole thing comes": if you need shared state, you're gonna have a bad time like someone else did here not even that long ago |
| 09:51:54 | FromDiscord | <ieltan> mutable |
| 09:52:09 | FromDiscord | <asbjorn2> depends what you mean by mutable.. I |
| 09:52:33 | FromDiscord | <asbjorn2> (edit) "depends what you mean by mutable.. I ... " added "need channels to communicate between my memory-intensive worker thread, and a bunch of more lightweight client threads." |
| 09:52:41 | FromDiscord | <ieltan> ofc you need shared state if you're gonna use threads but if you need to have concurrent writers then reconsider if the problem requires that approach first |
| 09:53:57 | FromDiscord | <asbjorn2> I think I can radically simplify my threading code. I just keep running into opaque segfaults while I'm doing it 😅 |
| 09:54:15 | FromDiscord | <asbjorn2> but I'm very glad that I can come in here and ask my dumb questions, and get help from someone actually experienced with nim |
| 09:54:37 | FromDiscord | <ieltan> eh im also mostly speaking out of my ass :p |
| 09:54:58 | FromDiscord | <ieltan> someone here had issues with threading and the whole thing was very informative to me |
| 09:55:20 | FromDiscord | <asbjorn2> but the whole "you can't put a thread on the stack, and return it" thing was difficult to find out on my own |
| 09:58:58 | FromDiscord | <ieltan> In reply to @asbjorn2 "but the whole "you": i have a hunch maybe you can do it if you deep copy |
| 09:59:24 | FromDiscord | <asbjorn2> eh it's fine. I'll just try to allocate it in the top scope and pass it down when I need it |
| 10:01:54 | FromDiscord | <fabric.input_output> In reply to @ieltan "i have a hunch": neither `system.deepCopy` nor `=sink` makes it work. I guess you just can't move a `Thread[T]` object around |
| 10:06:54 | FromDiscord | <asbjorn2> sent a code paste, see https://play.nim-lang.org/#pasty=tsFPcoaz |
| 10:06:55 | FromDiscord | <asbjorn2> this works though |
| 10:06:56 | FromDiscord | <asbjorn2> yay |
| 10:09:38 | FromDiscord | <ieltan> well of course it works, you're still relying on RVO to avoid storing the `Worker` on the function's stackframe so it doesn't blow up :p |
| 10:10:04 | FromDiscord | <ieltan> but cool to see you're figuring out threading in Nim it's still a complicated subject |
| 10:10:11 | FromDiscord | <asbjorn2> In reply to @ieltan "never tested it": I guess we weren't sure before, but now we are 🙂 |
| 10:10:30 | FromDiscord | <asbjorn2> In reply to @ieltan "but cool to see": I'm prepared to spend some time figuring out the nasty stuff w/ threading |
| 10:10:55 | FromDiscord | <asbjorn2> honestly it's not the most fun I've had with nim, but I'm looking forward to getting it all figured out ✨ |
| 10:10:56 | FromDiscord | <asbjorn2> I'm learning |
| 10:11:06 | FromDiscord | <ieltan> In reply to @fabric.input_output "neither `system.deepCopy` nor `=sink`": rip |
| 10:11:23 | * | ntat quit (Quit: Leaving) |
| 10:39:23 | * | PMunch joined #nim |
| 10:58:34 | * | beholders_eye joined #nim |
| 11:10:20 | FromDiscord | <pmunch> Yeah you can't move threads |
| 11:29:31 | PMunch | But I don't think they have to use global memory. You just have to make sure that the place in memory you call `createThread` with won't change after it has been created. |
| 11:30:37 | PMunch | I think that's the limitation at least |
| 11:31:04 | PMunch | Which means you should be able to store them in a `ref object`, as long as you're careful that it's never copied anywhere |
| 11:34:31 | FromDiscord | <asbjorn2> Might it be possible to write some kind of safeguard for myself, so I can more easily discover if I copy it by accident? ↵I'm not very well informed on how moves and copies work in nim, but maybe one could do something like a custom move hook for my ref object type, that lets me know that I'm trying to do something dumb? |
| 11:38:09 | FromDiscord | <ieltan> In reply to @PMunch "Which means you should": storing `Thread` in a `ref object` makes me very uneasy since it's not thread-safe. why would you even need to store it in a `ref` anyways ?↵> "as long as you're careful that it's never copied anywhere"↵but thats easy to do in an `object` with `=copy {.error.}` and `=dup {.error.}` defined for it, then you're guaranteed can only just move it around and makes more sense than a `ref` imo. |
| 11:40:24 | PMunch | `ref object` mostly to make sure it ends up on the heap. With an object you risk creating it on the stack somewhere and it being freed as the stack moves around |
| 11:41:24 | PMunch | The object that holds the thread doesn't have to be thread safe because you're not passing that object between threads, it just lives with the main thread to be able to wait for the threads completion. |
| 11:41:48 | PMunch | I was just thinking of ways to be able to dynamically create an unknown number of threads |
| 11:42:07 | PMunch | For that you need some kind of dynamic memory |
| 11:42:31 | PMunch | And since sequences calls realloc as they grow those are out. Leaving us with things like linked lists |
| 11:43:17 | PMunch | That being said I haven't actually tried putting a thread in a linked list, but I don't think it should cause any trouble |
| 11:56:30 | PMunch | Just tried it, and it works great: https://pasty.ee/WESdhXmz |
| 11:56:48 | PMunch | Ran it through `valgrind --tool=helgrind` and it reported 0 errors. |
| 11:56:58 | PMunch | So should be safe :) |
| 11:58:34 | FromDiscord | <ieltan> Would using `seq[Thread]` make more sense then if you're dealing with an unknown number of threads ? If the `ref` in question is not shared it should be fine but it still makes me feel uneasy because now you must ensure there aren't multiple references to it at a time, which is something you could avoid by not using `ref`.. |
| 11:59:03 | PMunch | Nope |
| 11:59:34 | PMunch | As I said seq reallocates when capacity is reached, so it will fail |
| 11:59:57 | FromDiscord | <ieltan> ah |
| 11:59:59 | FromDiscord | <ieltan> i missed that |
| 12:00:19 | PMunch | Consider this: https://pasty.ee/YzlBAsfh |
| 12:00:26 | FromDiscord | <ieltan> this makes me grumpy |
| 12:01:00 | FromDiscord | <ieltan> not the pasty btw |
| 12:01:25 | PMunch | If you set the capacity higher than the amount of threads you want to create then you're fine |
| 12:02:18 | PMunch | So if you know how many threads you are going to use up front you could create a sequence of that length, populate each spot, and then run them |
| 12:02:37 | FromDiscord | <ieltan> well that's in case you know for sure you won't go past a certain amount of threads, in that case just do as i mentioned earlier using `array` for example |
| 12:04:48 | PMunch | Like this works fine: https://pasty.ee/JMZMBovE |
| 12:05:12 | PMunch | Well array only works if you know _on compile time_ how many threads you want |
| 12:05:30 | PMunch | With a sequence like this you only have to know _on runtime_ how many threads you need |
| 12:06:16 | PMunch | But putting them in a seq like that doesn't feel great. Perfect foot-gun for some refactoring to dynamically add a thread and reallocate all the memory.. |
| 12:07:13 | * | beholders_eye quit (Ping timeout: 255 seconds) |
| 12:08:35 | FromDiscord | <ieltan> hmm |
| 12:08:59 | * | beholders_eye joined #nim |
| 12:11:48 | * | krux02 joined #nim |
| 12:11:51 | PMunch | I really should do a deep dive on this and write an article.. |
| 12:13:17 | * | johuck quit (Remote host closed the connection) |
| 12:13:17 | * | robertmeta quit (Remote host closed the connection) |
| 12:13:17 | * | ursa-major quit (Remote host closed the connection) |
| 12:13:17 | * | noeontheend quit (Remote host closed the connection) |
| 12:13:18 | * | adigitoleo quit (Remote host closed the connection) |
| 12:13:19 | * | mronetwo quit (Write error: Broken pipe) |
| 12:13:51 | * | mronetwo joined #nim |
| 12:14:02 | * | robertmeta joined #nim |
| 12:14:02 | * | ursa-major joined #nim |
| 12:14:04 | * | noeontheend joined #nim |
| 12:14:04 | * | adigitoleo joined #nim |
| 12:14:10 | * | johuck joined #nim |
| 12:15:59 | FromDiscord | <ieltan> i really like the linked list appraoch |
| 12:16:25 | PMunch | Yeah that definitely feels the safest |
| 12:16:39 | Amun-Ra | PMunch: for i in 0..<parseInt(paramStr(1)) |
| 12:17:16 | PMunch | Amun-Ra, was there a question there? |
| 12:17:25 | Amun-Ra | I mean .. -> ..< |
| 12:17:53 | PMunch | Oh right :P |
| 12:18:11 | PMunch | Didn't matter much what the code actually did, just wanted something dynamic |
| 12:18:27 | Amun-Ra | right, just nitpicking :) |
| 12:20:43 | FromDiscord | <albassort> hello does anyone have a guide for making a nimble package which builds things that are not only nim |
| 12:20:59 | FromDiscord | <ieltan> `for thread in thr.mitems: # mitems is used here because we don't want a copy (Nim will fail to compile without it)`↵isn't that why `item` return `lent T` ? |
| 12:21:13 | FromDiscord | <ieltan> In reply to @albassort "hello does anyone have": not to my knowledge sorry |
| 12:21:24 | FromDiscord | <ieltan> (edit) "`item`" => "`items`" |
| 12:21:35 | FromDiscord | <albassort> i know you can do it, I just cant remember of a project that does |
| 12:21:54 | FromDiscord | <albassort> if you can remember one which does that would work too |
| 12:22:03 | FromDiscord | <fabric.input_output> what if you made a `seq[ref Thread[T]]` |
| 12:22:23 | FromDiscord | <ieltan> then i become sad |
| 12:22:35 | FromDiscord | <ieltan> hey, you can't just delete that message 😠 |
| 12:22:55 | FromDiscord | <ieltan> In reply to @albassort "if you can remember": i'll try to look around and see if there's anything |
| 12:22:56 | FromDiscord | <fabric.input_output> > what if you do `seq[ref Thread[T]]`↵- me |
| 12:28:49 | * | beholders_eye quit (Ping timeout: 268 seconds) |
| 12:31:25 | NimEventer | New thread by miran: Nim version 2.0.6 released, see https://forum.nim-lang.org/t/11782 |
| 12:36:22 | FromDiscord | <kots> I can't be the only one thinking we need to stop recommending that unmaintained piece of junk software called choosenim |
| 12:36:28 | PMunch | @fabric.input_output, that seems to work :) |
| 12:36:42 | PMunch | @kots, don't worry, we're working on maintaining it :) |
| 12:38:54 | FromDiscord | <zumi.dxy> choosenim is still under dom96's account? 🤔 |
| 12:39:42 | FromDiscord | <kots> In reply to @PMunch "<@305785071489515540>, don't worry, we're": Good to hear |
| 12:39:56 | PMunch | It has been forked to nim-lang/choosenim, but it had been unmaintained for so long that it has taken a bit longer than expected to be able to create a build via the CI |
| 12:40:22 | PMunch | As soon as that's resolved I'll announce the switch |
| 12:40:34 | FromDiscord | <zumi.dxy> ah, so it'll be up in a bit |
| 12:40:39 | PMunch | Yup |
| 12:40:46 | FromDiscord | <zumi.dxy> hopefully VSC/LSP issues will be resolved |
| 12:40:56 | PMunch | They won't |
| 12:41:17 | FromDiscord | <zumi.dxy> 🤔 |
| 12:41:23 | FromDiscord | <zumi.dxy> well not right now is okay |
| 12:41:24 | PMunch | Currently this is just a fork and rebuild. However it means that we can now accept PRs again :) |
| 12:41:37 | strogon14 | When the migration is done, the first order of business should be fixing all the non-HTTPS urls choosenim still uses. |
| 12:41:37 | PMunch | So at least they _can_ be fixed |
| 12:41:53 | PMunch | strogon14, good call, should be a very simple fix as well |
| 12:42:55 | FromDiscord | <albassort> In reply to @k0ts "I can't be the": hey choosenim has worked for me for like 5 years now |
| 12:42:59 | FromDiscord | <albassort> >:( |
| 12:43:26 | FromDiscord | <albassort> https://github.com/nim-lang/choosenim 404's |
| 12:43:31 | strogon14 | Then replacing startProcess here next: https://github.com/dom96/choosenim/blob/master/src/choosenimpkg/proxyexe.nim#L47 |
| 12:43:33 | PMunch | Yeah it works fine, but it doesn't have ARM support, and the proxy executables it creates are buggy |
| 12:43:57 | PMunch | @albassort, that's because it's private until I have fixed the CI :) |
| 12:44:04 | FromDiscord | <albassort> rude |
| 12:44:08 | PMunch | Remember, it's a secret still :P |
| 12:45:10 | FromDiscord | <kots> In reply to @albassort "hey choosenim has worked": What pmunch said. It has those two pretty fatal imo bugs that have gone completely ignored |
| 12:45:54 | PMunch | Well the original maintainer isn't in the community any longer. However we should've forked the repo ages ago |
| 12:46:07 | strogon14 | IMHO the file naming scheme for the binary distributions is also too simplistic. AFFAIR it only encodes OS and archtiecture, but it should probably also encode the standard C lib they're compiled against and possibly more. |
| 12:46:17 | FromDiscord | <kots> In reply to @k0ts "What pmunch said. It": I personally don't care, I gave up on it years ago and just use my own script to manage symlinks but it causes problems for newcomers |
| 12:46:43 | FromDiscord | <.lisuwu_> In reply to @PMunch "Well the original maintainer": what stopped you from doing it ages ago exactly ? |
| 12:46:44 | FromDiscord | <albassort> i tried to get nim compiler on my server and i gave up |
| 12:46:49 | FromDiscord | <albassort> because its on arm |
| 12:47:06 | FromDiscord | <zumi.dxy> In reply to @.lisuwu_ "what stopped you from": "it still works" i'm guessing |
| 12:47:08 | PMunch | @.lisuwu_, limited manpower mostly |
| 12:47:13 | FromDiscord | <albassort> i didn't try very hard, obviously |
| 12:47:14 | FromDiscord | <mratsim> In reply to @PMunch "Well the original maintainer": Politics-wise, dom took attempting at forking his stuff as way to push him out of the community.↵Happened with asyncdispatch as well.↵↵Hence why choosenim wasn't forked because hot potato |
| 12:47:30 | FromDiscord | <zumi.dxy> In reply to @albassort "because its on arm": oh yeah, arm… |
| 12:47:47 | FromDiscord | <zumi.dxy> the "official" nim docker doesn't offer arm builds |
| 12:47:50 | FromDiscord | <zumi.dxy> someone else does |
| 12:47:58 | strogon14 | albassort: compiling Nim yourself isn't hard, though. |
| 12:48:09 | FromDiscord | <albassort> In reply to @albassort "i didn't try very": . |
| 12:48:12 | FromDiscord | <.lisuwu_> In reply to @PMunch "@.lisuwu_, limited manpower mostly": i see |
| 12:48:26 | PMunch | @mratsim, well when he left of his own volition we should've forked his stuff |
| 12:48:44 | FromDiscord | <albassort> it was kinda like "huh, I wonder why they dont have arm auto build, whatever." |
| 12:48:56 | PMunch | But a combination of "it still works" and limited manpower has led to it sitting there growing stale |
| 12:48:58 | FromDiscord | <albassort> "i'll just build on my pc" |
| 12:49:13 | FromDiscord | <zumi.dxy> In reply to @strogon14 "<@217459674700578816>: compiling Nim yourself": which is more than can be said of… other tools |
| 12:49:15 | FromDiscord | <mratsim> In reply to @PMunch "<@570268431522201601>, well when he": was there an official "I leave" announcement? |
| 12:49:40 | FromDiscord | <zumi.dxy> In reply to @mratsim "was there an official": he probably just left with a "i'm not mad; just disappointed" |
| 12:50:10 | FromDiscord | <mratsim> would be nice to have this by Nim v2.2 btw: https://github.com/nim-lang/nightlies/pull/82 |
| 12:50:17 | PMunch | Can't remember if there was anything posted in the community about it, but he posted on his Twitter and let us know in the moderator chat |
| 12:50:23 | FromDiscord | <mratsim> especially now that Github uses Mac ARM in CI |
| 12:51:06 | PMunch | They do? I wonder how that works |
| 12:51:08 | FromDiscord | <albassort> good to know im not the only person here with BPD lol |
| 12:51:19 | PMunch | Do they just have a room full of Macs? |
| 12:51:43 | PMunch | BPD? |
| 12:52:16 | FromDiscord | <albassort> personality disorder characterized by rejection sensitivity |
| 12:52:20 | FromDiscord | <albassort> among other things |
| 12:52:25 | FromDiscord | <albassort> https://x.com/d0m96/status/1797272534427005349 |
| 12:52:28 | FromDiscord | <ieltan> In reply to @mratsim "Politics-wise, dom took attempting": it's odd that such an important "builtins" is not in the `nim-lang` org anyways |
| 12:52:37 | FromDiscord | <ringabout> In reply to @mratsim "would be nice to": I don't understand the CI failures besides I don't have a mac. Same for the tests on m2 https://github.com/nim-lang/Nim/pull/23290 |
| 12:53:11 | FromDiscord | <mratsim> In reply to @PMunch "They do? I wonder": broke my CI out of the biue end of April: https://github.com/mratsim/constantine/issues/372 |
| 12:53:15 | FromDiscord | <ieltan> In reply to @albassort "https://x.com/d0m96/status/1797272534427005349": lol |
| 12:53:25 | FromDiscord | <albassort> truly a rust moment |
| 12:53:29 | FromDiscord | <ieltan> cant blame the guy |
| 12:53:51 | FromDiscord | <mratsim> In reply to @albassort "https://x.com/d0m96/status/1797272534427005349": I can't read the post |
| 12:53:58 | FromDiscord | <albassort> this is good |
| 12:54:08 | Amun-Ra | C++ vs rust… hard choice… |
| 12:54:09 | FromDiscord | <albassort> https://media.discordapp.net/attachments/371759389889003532/1252244896278908959/image.png?ex=66718370&is=667031f0&hm=bd1f67942b4516c6639a05f0115d03b1ff05774b477b37a204fd5bafd4b406e3& |
| 12:54:18 | FromDiscord | <ieltan> but i heard rust does have decent embedded support because of `no-std` |
| 12:54:28 | FromDiscord | <kots> Nice avatar |
| 12:54:33 | FromDiscord | <ieltan> but the issue is that the rebuilds the world approach |
| 12:54:38 | FromDiscord | <ieltan> (edit) removed "that" |
| 12:54:49 | FromDiscord | <albassort> the problem was wrapping C++ |
| 12:54:53 | FromDiscord | <ringabout> In reply to @mratsim "broke my CI out": MacOS 14 in GitHub CI defaults to m2, you can still use MacOS 12 though |
| 12:55:00 | FromDiscord | <fabric.input_output> c++ rust interop sucks |
| 12:55:02 | FromDiscord | <albassort> he wanted to avoid the evil of nim + C++ and try to do rust + C++ |
| 12:55:02 | FromDiscord | <mratsim> In reply to @albassort "": seems like I need to log out from X to read it, I never interacted with dom on Twitter .... |
| 12:55:04 | FromDiscord | <albassort> only to figure out it sucks |
| 12:55:26 | FromDiscord | <zumi.dxy> I thought rust <-> C interop is okay? |
| 12:55:36 | FromDiscord | <mratsim> In reply to @zumi.dxy "I thought rust <->": yes, but it's C++ |
| 12:55:39 | FromDiscord | <zumi.dxy> though yeah I imagine C++ will introduce some complications |
| 12:55:46 | FromDiscord | <albassort> C++ makes interop very difficult |
| 12:55:50 | FromDiscord | <albassort> because its C++ |
| 12:55:51 | FromDiscord | <zumi.dxy> what with the name mangling and all |
| 12:56:07 | FromDiscord | <albassort> C++ seeks to devour your software into its weird types |
| 12:56:09 | * | ntat joined #nim |
| 12:56:21 | FromDiscord | <mratsim> << "devour" << |
| 12:56:35 | FromDiscord | <ieltan> in C++ you need to expose a C-API if you want your library to be interoperable at any sane levels |
| 12:56:44 | FromDiscord | <zumi.dxy> compiling directly to the target language you'd think would be a ""weakness"" but it's a pretty great strength |
| 12:56:56 | FromDiscord | <zumi.dxy> In reply to @ieltan "in C++ you need": ~~in C++~~ you need to expose a C-API if you want your library to be interoperable at any sane levels↵:) |
| 12:57:15 | FromDiscord | <ieltan> practically speaking it's impossible to support C++ interop unless you reimplement all C++ features or you do it like Nim and generate C++ |
| 12:57:18 | FromDiscord | <ieltan> (edit) "practically speaking it's impossible to support C++ interop unless you reimplement all C++ features or you do it like Nim and generate C++ ... " added "code" |
| 12:57:26 | FromDiscord | <ieltan> (edit) "practically speaking it's impossible to support C++ ... interop" added "at 100%" |
| 12:57:29 | FromDiscord | <albassort> In reply to @ieltan "in C++ you need": which, its best the cpp library already exposes the C, if it doesn't, you need to do that yourself |
| 12:57:36 | FromDiscord | <albassort> but thats so much work he just decided to use cpp |
| 12:58:29 | FromDiscord | <ieltan> yeah |
| 12:59:10 | FromDiscord | <ieltan> `simdjson` for example doesn't have a c-api, you need to make one yourself which the rust wrapper does and also a Nim wrapper does it too |
| 13:00:22 | FromDiscord | <albassort> Yeah i don't really know who makes a popular CPP and doesn't decide to make a C api |
| 13:00:24 | FromDiscord | <albassort> thats a no brainer |
| 13:00:30 | FromDiscord | <albassort> reflects poorly on the debs |
| 13:00:31 | FromDiscord | <albassort> (edit) "debs" => "devs" |
| 13:01:29 | FromDiscord | <ieltan> i have been working on bindings for https://github.com/uNetworking/uWebSockets but that stalled cause of my exams and life stuff. Now I can't even do it because the maintainer removed the bindings unless i checkout the latest commit that stills supports but that means no more update ;-; |
| 13:02:23 | FromDiscord | <ieltan> at least i could bind `uSockets` instead, and it should be straightforward to create something like `uWebSockets` in Nim using those as a foundation... |
| 13:02:23 | FromDiscord | <albassort> Oh thats so cool of them! |
| 13:02:46 | FromDiscord | <ieltan> (edit) "i have been working on bindings for https://github.com/uNetworking/uWebSockets but that stalled cause of my exams and life stuff. Now I can't even do it because the maintainer removed the bindings unless i checkout the latest commit that stills supports ... but" added "it" |
| 13:02:46 | FromDiscord | <albassort> In reply to @ieltan "at least i could": sounds like something a lot of effort though. |
| 13:03:00 | FromDiscord | <mratsim> In reply to @ieltan "i have been working": https://media.discordapp.net/attachments/371759389889003532/1252247120912580608/image.png?ex=66718583&is=66703403&hm=f8c87219e617c9e15a654b3aa083971ec09e1c736c53fc7428f969b4d274fb27& |
| 13:03:15 | FromDiscord | <mratsim> How do they do Node.js integration without C API? |
| 13:04:14 | FromDiscord | <ieltan> In reply to @albassort "sounds like something a": the code does not look very complicated to me |
| 13:04:47 | FromDiscord | <ieltan> the big part is already done, `uWebsocket` is just a dandy handy API around `uSocket` |
| 13:05:10 | FromDiscord | <mratsim> btw, would people be interested in a pure Nim TLS/SSL and QUic implementation? |
| 13:06:44 | FromDiscord | <ieltan> In reply to @mratsim "How do they do": they do use the c api though ? |
| 13:06:45 | FromDiscord | <albassort> SSL has a lot of problems but i don't think it would be reasonable to expect someone to develop a fully featured and safe implementation |
| 13:06:56 | FromDiscord | <albassort> the ssl used in nim, taht is |
| 13:06:58 | FromDiscord | <albassort> (edit) "taht" => "that" |
| 13:07:05 | FromDiscord | <mratsim> In reply to @ieltan "they do use the": but you said they reoved bindings |
| 13:07:08 | FromDiscord | <ieltan> just not the uwebsockets |
| 13:07:10 | FromDiscord | <ieltan> i mean |
| 13:07:14 | FromDiscord | <ieltan> let me check |
| 13:07:32 | * | ntat quit (Quit: Leaving) |
| 13:08:32 | FromDiscord | <albassort> the other problem is to my mind, is wrapping a socket for TLS might not have all of the things you need exposed to wrap it yourself, so you might not be able to have compatibility with previous code |
| 13:08:37 | FromDiscord | <mratsim> In reply to @albassort "SSL has a lot": Let's handle that later, for now I'm gauging interest.↵If there is some, I can outline a plan. It can start with supporting libsodium in native Nim so that someone gets trained on writing cryptography, then upgrade to TLS v1.3 (which is easier than 1.2). |
| 13:08:56 | FromDiscord | <mratsim> In reply to @albassort "the other problem is": I'm not talking about wrapping, but pure Nim. |
| 13:09:03 | FromDiscord | <albassort> im talking about the sockets |
| 13:09:08 | FromDiscord | <albassort> wrapSocket() |
| 13:09:53 | FromDiscord | <albassort> when you want to use TLS in a socket you need to wrap it, and if you cant do everything the stdlib does because the types it exposes cant be constructed externally, then you cant wrap the socket |
| 13:10:15 | FromDiscord | <albassort> so procedures which want a socket cannot take in the purenim variants |
| 13:10:39 | FromDiscord | <mratsim> sent a long message, see https://pasty.ee/mzgZDYDt |
| 13:11:14 | FromDiscord | <mratsim> See: https://nim-lang.github.io/Nim/importutils.html |
| 13:11:14 | FromDiscord | <albassort> 'https://nim-lang.org/docs/net.html#wrapSocket%2CSslContext%2CSocket |
| 13:11:27 | FromDiscord | <albassort> oh |
| 13:11:31 | FromDiscord | <albassort> I didn't know about this |
| 13:12:16 | FromDiscord | <albassort> I, and I think most people would prefer a portable and stable SSL implementation versus whatever is happening right now. |
| 13:12:18 | FromDiscord | <mratsim> and this import nativesockets, so the field are public |
| 13:12:28 | FromDiscord | <mratsim> (edit) "field" => "fields" |
| 13:12:34 | FromDiscord | <mratsim> (edit) "import" => "imports" |
| 13:12:36 | FromDiscord | <albassort> Puppy has a lot of users for example |
| 13:13:22 | FromDiscord | <albassort> the problem is, your ssl implementation would need to keep parity with vulnerabilities found in openssl, etc. Theres no way you can maintain it to the level that would need |
| 13:13:44 | FromDiscord | <ieltan> i was mistaken @mratsim. v8 has a C++ API and they seem to be using it directly |
| 13:13:45 | * | disso_pch joined #nim |
| 13:13:53 | FromDiscord | <ieltan> https://github.com/uNetworking/uWebSockets.js/blob/master/src/AppWrapper.h |
| 13:13:54 | FromDiscord | <mratsim> In reply to @albassort "the problem is, your": I don't plan to have vulnerabilities |
| 13:14:07 | FromDiscord | <albassort> in mratsim we trust |
| 13:14:09 | FromDiscord | <ieltan> so they use the C++ `uWebsocket` directly |
| 13:14:12 | FromDiscord | <ieltan> (edit) "so they use the C++ `uWebsocket` ... directly" added "api" |
| 13:14:23 | FromDiscord | <albassort> woah |
| 13:15:10 | FromDiscord | <ieltan> In reply to @mratsim "btw, would people be": I don't remember what QUIC is (http3 ?) if it means more speed then yeah of course 🙂 |
| 13:15:39 | * | disso-peach quit (Ping timeout: 256 seconds) |
| 13:15:51 | FromDiscord | <mratsim> In reply to @ieltan "I don't remember what": Quic is the same as TLS 1.3 but for UDP. |
| 13:15:54 | FromDiscord | <mratsim> same cryptography |
| 13:16:05 | FromDiscord | <ieltan> ohh |
| 13:16:14 | FromDiscord | <albassort> I didn't know about Quic |
| 13:16:18 | FromDiscord | <albassort> i must implement this everywhere |
| 13:16:37 | FromDiscord | <mratsim> https://www.chromium.org/quic/ |
| 13:16:45 | FromDiscord | <ieltan> https://media.discordapp.net/attachments/371759389889003532/1252250584732536894/quic.png?ex=667188bd&is=6670373d&hm=9ebb63048177dee1454d790c9e51c12066f70b08de76428e3636c219703a3d89& |
| 13:17:16 | FromDiscord | <ieltan> looks amazing |
| 13:17:24 | FromDiscord | <leorize> native ssl/tls would be pretty neat ngl |
| 13:17:42 | FromDiscord | <ieltan> yeah |
| 13:17:42 | FromDiscord | <fabric.input_output> do we have quic in nim> |
| 13:17:46 | FromDiscord | <fabric.input_output> (edit) "nim>" => "nim?" |
| 13:18:04 | FromDiscord | <albassort> In reply to @ieltan "": quic allows us to communicate faster than light |
| 13:18:10 | FromDiscord | <mratsim> In reply to @fabric.input_output "do we have quic": There was wrapped one: https://github.com/status-im/nim-quic |
| 13:18:22 | FromDiscord | <leorize> note that quic is kinda useless for non-multiplexing situations due to scheduling overhead |
| 13:43:08 | FromDiscord | <ieltan> In reply to @albassort "reflects poorly on the": tbf to the devs of `simdjson` the issue of making a c-api is hard because a big part of the api is inline |
| 13:43:10 | FromDiscord | <ieltan> https://github.com/simdjson/simdjson/issues/249 |
| 13:49:11 | FromDiscord | <asbjorn2> Anyone know what restrictions apply to working with `Chan` from `threading/channels`?↵I've learned that `Thread` must not be moved. Are there similar restrictions to channels?↵I'm trying to figure out what I'm allowed to do with a `Chan` |
| 13:49:59 | FromDiscord | <asbjorn2> Right now I'm doing some slightly-complex-but-really-not-that-bad stuff, with sending `Chan`s over a `Chan`. I'm looking at the `tchannels_cooperative` test from nim-lang/threading, which does something similar |
| 13:50:39 | FromDiscord | <asbjorn2> I have implemented a minimal example which seems to work fine, but when I implement (basically) the same thing in my real-world-code, I get segfaults when calling `peek` |
| 13:51:34 | FromDiscord | <asbjorn2> Since it seems like (from araq's test that I'm reading) you're supposed to pass channels into threads by `ptr Chan[T]`, I'm guessing that a similar thing applies- that you have to be careful to not move where stuff is stored. Is that right? |
| 14:04:48 | * | PMunch quit (Quit: Leaving) |
| 14:04:51 | FromDiscord | <planetis_m> You can't move the underlying pthread primitives that the channel is based on. That's correct, so you should store it on the stack and make sure that the pointer doesn't outline the scope the Chan is declared in. |
| 14:04:58 | * | rockcavera joined #nim |
| 14:26:34 | FromDiscord | <asbjorn2> How does `SharedPtr` work in relation to moving the memory around? If I make a `SharedPtr` a few calls deep, and return it "upwards", will it retain the memory location? |
| 14:38:29 | * | coldfeet joined #nim |
| 14:49:09 | FromDiscord | <albassort> sent a code paste, see https://play.nim-lang.org/#pasty=vCVUWpWR |
| 14:51:02 | FromDiscord | <albassort> In reply to @asbjorn2 "How does `SharedPtr` work": idk what "upward" means but nims memory model has 2 different types of heaps. The Shared Heap and a local-thread heap. A shared pointer is allocated on the shared heap, which is accessible to all threads at all times. |
| 14:51:32 | FromDiscord | <albassort> sent a code paste, see https://play.nim-lang.org/#pasty=JJHldcDk |
| 14:58:01 | FromDiscord | <albassort> im doing this because the gpg converters cant tell the difference if they aren't distinct |
| 14:58:20 | FromDiscord | <Robyn [She/Her]> Huh? |
| 14:58:32 | FromDiscord | <albassort> so you see the ToPublicKey and toPrivateKey |
| 14:58:35 | FromDiscord | <Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=TmojRvwZ |
| 14:58:37 | FromDiscord | <albassort> those wont work if they're not distinct |
| 14:58:44 | FromDiscord | <albassort> sequoia wrapper |
| 14:58:55 | FromDiscord | <Robyn [She/Her]> Ooh |
| 14:59:43 | FromDiscord | <albassort> In reply to @albassort "so you see the": they cant tell the difference between strings, public keys, or private keys if they are not distinct types |
| 15:00:10 | FromDiscord | <albassort> and if I don't push the distinct strings down to normal strings it causes weird issues so they cant be distinct |
| 15:00:15 | FromDiscord | <albassort> this is my solution |
| 15:06:18 | FromDiscord | <threefour> Is it impossible to use `std/net` in a multithreaded way? I don't want async, but I also don't want want to deal with sockets on a lower level. I'm currently doing `OptReusePort` and listening in multiple threads, but it behaves as single core still, even with 6 listening threads. |
| 15:06:21 | FromDiscord | <Robyn [She/Her]> It looks tidy to me at least |
| 15:06:35 | FromDiscord | <albassort> In reply to @threefour "Is it impossible to": they work fine on threads |
| 15:06:54 | FromDiscord | <albassort> there is no stdlib implementation for dispatch, thats not really what th stdlib does |
| 15:07:27 | FromDiscord | <albassort> im sure you can find one on nimble, for example, httpbeast is threaded. |
| 15:08:25 | FromDiscord | <threefour> Yeah I'm reading httpbeast's code, which is where I got the idea for `OptReusePort`. But they use `nativesockets` and selectors, and I was hoping to not have to go that deep with it. |
| 15:08:44 | FromDiscord | <albassort> no you dont need to use nativesockets |
| 15:08:54 | FromDiscord | <albassort> sorry if that wasn't specific enough |
| 15:10:43 | FromDiscord | <albassort> im sure that theres a good reason httpbeast uses nativesockets, but i don't know why |
| 15:13:49 | FromDiscord | <threefour> I'm sure there is too, but if it's because they want to squeeze every drop of performance out, then I won't follow them on that for now. I just care about getting 80% of the way there. |
| 15:14:32 | FromDiscord | <albassort> I assume that its because its just more lean, memory-wise |
| 15:24:15 | * | beholders_eye joined #nim |
| 15:30:12 | FromDiscord | <leorize> nativesockets is superior to sockets |
| 15:31:23 | FromDiscord | <fakuivan> is it possible to pass the config values `mips.linux.gcc.exe` and `mips.linux.gcc.linkerexe` as arguments when calling `nim c`? |
| 15:31:38 | FromDiscord | <fakuivan> overwriting those in the config |
| 15:32:00 | FromDiscord | <leorize> yea, all config options are valid as command line flags↵(@fakuivan) |
| 15:32:32 | FromDiscord | <albassort> sent a code paste, see https://play.nim-lang.org/#pasty=lnYlEkBD |
| 15:32:45 | FromDiscord | <fakuivan> In reply to @leorize "yea, all config options": `--mips.linux.gcc.exe:gcc_something` then? |
| 15:32:54 | FromDiscord | <leorize> yea |
| 15:33:33 | FromDiscord | <leorize> you might want to revise your strategy if you needed that much converters↵(@albassort) |
| 15:36:03 | FromDiscord | <leorize> to expand on this, std/net try to do buffering and it does it poorly. It also tries to be smart and handle SSL, common errors, all in one. This makes too many assumptions that usually doesn't hold for what you want to do |
| 15:37:11 | FromDiscord | <leorize> converters are applied haphazardly by the compiler, they slow down as well as messing up overloading in fun and exciting ways |
| 15:53:26 | * | coldfeet quit (Remote host closed the connection) |
| 16:28:46 | FromDiscord | <albassort> In reply to @leorize "you might want to": yeah I've realized this is stupid and although I would like for this to work it would easier to just put implement these on the proc level because these are buggy lole |
| 16:29:28 | FromDiscord | <threefour> Okay my setup seems like it should work properly, but something is constraining it, and I don't know what. When I have 1 thread listening with `OptReusePort`, I get the most performance. I'm using `ab -c 32` to load test. When I increase to 2 listener threads, I don't see an increase. In fact, as I add listener threads, I only see a gradual decrease in throughput. |
| 16:57:13 | * | SchweinDeBurg quit (Quit: WeeChat 4.4.0-dev) |
| 17:22:43 | FromDiscord | <leorize> do you use only threads? |
| 17:23:30 | FromDiscord | <leorize> if so then you might be facing context switch penalty |
| 17:27:33 | * | ntat joined #nim |
| 17:28:07 | FromDiscord | <leorize> if you put both client and server on the same machine, then having both the load and the server contend on CPU will set a limit in scaling |
| 17:29:24 | FromDiscord | <fakuivan> is there a way to avoid the `error: redefinition of typedef 'NIM_STATIC_ASSERT_AUX'` when using old versions of gcc? |
| 17:29:54 | FromDiscord | <leorize> make sure to also test with httpbeast to see if you're actually slower |
| 17:30:21 | FromDiscord | <leorize> file an issue \:p↵(@fakuivan) |
| 17:30:50 | FromDiscord | <fakuivan> In reply to @fakuivan "is there a way": oh ok |
| 17:31:00 | FromDiscord | <fakuivan> oh ok |
| 17:31:35 | FromDiscord | <fakuivan> sent a code paste, see https://play.nim-lang.org/#pasty=gXbgiQyh |
| 17:32:43 | FromDiscord | <leorize> maybe you should update it... |
| 17:33:03 | FromDiscord | <fakuivan> it's for an old embedded thing I'm modding |
| 17:33:39 | FromDiscord | <fakuivan> I'm not sure what options I have besides compiling buildroot or openwrt for it and using that instead |
| 17:33:55 | FromDiscord | <leorize> you can try the buildroot project\: https://buildroot.org/ |
| 17:34:08 | FromDiscord | <leorize> that's probably a better bet |
| 17:34:32 | FromDiscord | <leorize> or you can dive into nimbase.h and see if you can wrestle your way out |
| 17:34:37 | FromDiscord | <leorize> but generally support for gcc \< 6.x is pretty spotty |
| 17:37:46 | FromDiscord | <fakuivan> In reply to @leorize "you can try the": If I can get a newer compiler without having to flash a new OS on the thing then that'd be great |
| 17:38:15 | * | coldfeet joined #nim |
| 17:38:38 | FromDiscord | <fakuivan> although I doubt that's how it works |
| 17:39:11 | FromDiscord | <leorize> you don't have to, as long as your buildroot targets the exact version of uclibc on the device |
| 17:42:29 | FromDiscord | <leorize> that's exactly how it works \:p |
| 17:42:36 | FromDiscord | <fakuivan> that'd be pretty cool |
| 17:42:55 | FromDiscord | <leorize> if you want to avoid C libraries shenanigans, you can even statically link with musl libc |
| 17:43:39 | FromDiscord | <leorize> it'd increase your binary size by a ton, so only do it if your device have enough space |
| 17:44:09 | FromDiscord | <fakuivan> yeah I'd like to avoid that since flash is only 16MB |
| 17:45:45 | FromDiscord | <leorize> as long as you can figure out what's the version of uclibc is on the device, you're pretty much set |
| 17:46:49 | FromDiscord | <leorize> something else you could do is to build a compiler on top of the sdk yourself, but that's a bit involved |
| 18:09:47 | FromDiscord | <fakuivan> https://github.com/nim-lang/Nim/blob/4867931af36467c1882fc01d235fbab67c12bb16/lib/nimbase.h#L278-L279 this comments shows the intention of also using the line number for better error message |
| 18:10:03 | FromDiscord | <fakuivan> turns out that adding the line number to that array also helps avoid redefinitions 😛 |
| 18:10:38 | FromDiscord | <fakuivan> you have to do a bit of trickery to get `LINE` to resolve in the correct way |
| 18:11:34 | * | krux02 quit (Quit: Leaving) |
| 18:15:27 | FromDiscord | <Phil> Dangit, there's no simple "lowercase only the first character in string" proc |
| 18:20:48 | FromDiscord | <Phil> sent a code paste, see https://play.nim-lang.org/#pasty=OfCCHmTa |
| 18:24:18 | FromDiscord | <albassort> sent a code paste, see https://play.nim-lang.org/#pasty=CXjKtwZa |
| 18:24:31 | FromDiscord | <albassort> because rust has no way to split a vector i need to do this |
| 18:24:35 | FromDiscord | <Phil> That... what |
| 18:24:57 | FromDiscord | <albassort> you cant create a string from a "" so you need to do String::from("") |
| 18:25:01 | FromDiscord | <albassort> this language is so cool |
| 18:25:03 | FromDiscord | <that_dude.> sent a code paste, see https://play.nim-lang.org/#pasty=pNSxEdow |
| 18:25:05 | FromDiscord | <that_dude.> What about this? |
| 18:25:18 | FromDiscord | <that_dude.> `toLowerAscii` can accept chars |
| 18:25:42 | FromDiscord | <Phil> That is so much better |
| 18:25:43 | FromDiscord | <Phil> THanks! |
| 18:25:47 | FromDiscord | <Phil> (edit) "THanks!" => "Thanks!" |
| 18:26:10 | FromDiscord | <that_dude.> The only concern is non ascii chars, but I though lowercase doesn't really apply to them |
| 18:26:12 | FromDiscord | <Phil> Gets rid of the unnecessary string conversion and everything, I love it |
| 18:26:21 | FromDiscord | <Phil> Yeah this is about strings that are for writing code |
| 18:26:33 | FromDiscord | <Phil> I think if you try to use non-ascii while defining a nim type you're doomed either way |
| 18:26:40 | FromDiscord | <that_dude.> Lol |
| 18:26:55 | FromDiscord | <Phil> This is used for macro code just Fyi, thus the camelcase |
| 18:28:19 | FromDiscord | <that_dude.> sent a code paste, see https://play.nim-lang.org/#pasty=vtjJYGVt |
| 18:28:21 | FromDiscord | <fabric.input_output> In reply to @albassort "you cant create a": or "".to_owned() |
| 18:28:26 | FromDiscord | <albassort> In reply to @isofruit "That... what": another thing why i had to write this: for some reason the headers i would need to parse were of variable length depending on the length of the message and i said "Fuck that" |
| 18:28:29 | FromDiscord | <that_dude.> There's also this if you prefec |
| 18:28:31 | FromDiscord | <that_dude.> (edit) "prefec" => "prefer" |
| 18:28:52 | FromDiscord | <that_dude.> (edit) "https://play.nim-lang.org/#pasty=ItpKRUeX" => "https://play.nim-lang.org/#pasty=RWDpKxfC" |
| 18:29:07 | FromDiscord | <that_dude.> (edit) "https://play.nim-lang.org/#pasty=zwfISavw" => "https://play.nim-lang.org/#pasty=DLbUfOdV" |
| 18:29:18 | FromDiscord | <that_dude.> I think it's uglier though |
| 18:30:10 | FromDiscord | <Phil> In reply to @that_dude. "I think it's uglier": Yeh, I optimize for readability there |
| 18:30:18 | FromDiscord | <Phil> The compiler will brutalize that thing into sth unrecognizeable anyway |
| 18:32:04 | FromDiscord | <albassort> In reply to @fabric.input_output "or "".to_owned()": less clear |
| 18:36:54 | FromDiscord | <fakuivan> In reply to @leorize "file an issue \:p": https://github.com/nim-lang/Nim/commit/4742ae93e99d8bbcdeea783e8a31dd9577524436 |
| 18:56:44 | * | coldfeet quit (Remote host closed the connection) |
| 19:01:57 | * | beholders_eye quit (Ping timeout: 268 seconds) |
| 19:03:06 | FromDiscord | <kots> sent a code paste, see https://play.nim-lang.org/#pasty=fZiyqATj |
| 19:36:46 | FromDiscord | <threefour> I can't even get httpbeast to get past the first request that ab sends. Really weird. |
| 19:51:53 | FromDiscord | <leorize> you can try httpleast\: https\://github.com/disruptek/httpleast/↵(@threefour) |
| 20:00:51 | FromDiscord | <Elegantbeef> Except utf-8 has capitalization 😄↵(@that_dude.) |
| 20:02:06 | FromDiscord | <that_dude.> Are there characters in that only exist in Unicode that have upper/lower case? |
| 20:02:20 | FromDiscord | <Elegantbeef> I believe so yes |
| 20:02:26 | FromDiscord | <that_dude.> Sounds like it would be a massive mess to keep track of the mapping |
| 20:03:00 | FromDiscord | <that_dude.> But it does make sense ig. I was thinking about emojis when I said that |
| 20:05:53 | FromDiscord | <Elegantbeef> Seems it's all latin based languages that have adopted capitalisation so it's likely some accented characters exist outside of ascii space |
| 20:05:55 | FromDiscord | <Elegantbeef> But I'm guessing |
| 20:10:10 | FromDiscord | <ezquerra> Can you convert a sequence into `varargs` of the same type? |
| 20:10:31 | FromDiscord | <Elegantbeef> It's an implicit conversion |
| 20:10:33 | FromDiscord | <Elegantbeef> So yes |
| 20:10:43 | FromDiscord | <Elegantbeef> `varargs` is syntax sugar over `toOpenArray` really |
| 20:10:55 | FromDiscord | <that_dude.> I thought you can just pass the seq into the proc that takes varargs |
| 20:10:58 | NimEventer | New thread by EnteryName: Go through siblings in HTML, see https://forum.nim-lang.org/t/11783 |
| 20:11:11 | FromDiscord | <Elegantbeef> What do you think implicit means 😛 |
| 20:11:20 | FromDiscord | <ezquerra> Umm, that is what I thought, but it does not work for me when I pass a sequence to ggplotnim's `aes` macro |
| 20:11:52 | FromDiscord | <demotomohiro> In reply to @ezquerra "Can you convert a": https://internet-of-tomohiro.netlify.app/nim/faq.en.html#procedures-how-to-pass-seq-or-array-to-varargs-parameterqmark |
| 20:11:56 | FromDiscord | <that_dude.> I had typed 80% of my message on my phone and didn't want to waste the time invested 😄 |
| 20:12:02 | FromDiscord | <Elegantbeef> `aes` is an untyped macro |
| 20:12:42 | FromDiscord | <Elegantbeef> As such it just takes in any comma delimited AST |
| 20:12:45 | FromDiscord | <Elegantbeef> so the seq name is a single value |
| 20:13:04 | FromDiscord | <ezquerra> Is there some way around that? |
| 20:13:23 | FromDiscord | <Elegantbeef> Convert the macro into a proc that takes a `arg: tuple` |
| 20:13:51 | FromDiscord | <ezquerra> By wrapping the aes macro for example? |
| 20:13:56 | FromDiscord | <Elegantbeef> No |
| 20:14:05 | FromDiscord | <Elegantbeef> Replacing the aes macro with a procedure |
| 20:15:01 | FromDiscord | <Elegantbeef> Yea there is no reason for the macro imo |
| 20:15:09 | FromDiscord | <ezquerra> As in modifying ggplotnim itself? |
| 20:17:43 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=KvKOpsOu |
| 20:17:47 | FromDiscord | <Elegantbeef> Something like that 😄 |
| 20:18:19 | FromDiscord | <Elegantbeef> Do the same with a `seq` and any other type |
| 20:18:41 | FromDiscord | <Elegantbeef> the `aes` macro is fully doable in user space and is kinda complex for what it does |
| 20:18:59 | FromDiscord | <faraz> https://t.me/hamster_kombaT_bot/start?startapp=kentId99163146 |
| 20:22:03 | FromDiscord | <Phil (he/him)> So I assume this is asking for a ban? |
| 20:22:35 | FromDiscord | <Phil (he/him)> Take your time, you have 2 minutes to respond until I assume this is botspam |
| 20:22:43 | FromDiscord | <Phil (he/him)> Take your time, you have 2 minutes to respond until I assume this is botspam and act accordingly |
| 20:26:41 | * | ntat quit (Quit: Leaving) |
| 21:05:23 | FromDiscord | <ezquerra> Thank you beef |
| 21:05:52 | FromDiscord | <ezquerra> It turns out that reading the aes code made me realize I had misunderstood what it did 😅 |
| 21:06:48 | FromDiscord | <Elegantbeef> Ah |
| 21:07:18 | FromDiscord | <Elegantbeef> It's a very simple operation best done by the above proc if you ask me |
| 21:08:22 | * | xet7 quit (Ping timeout: 268 seconds) |
| 21:21:08 | * | xet7 joined #nim |
| 21:25:48 | NimEventer | New thread by LokeX: Oh threadpool, my threadpool, see https://forum.nim-lang.org/t/11784 |
| 21:28:07 | FromDiscord | <vindaar> it's `untyped` for a reason. So that you can do things like `aes(colX, colY)` with `colX/Y` automatically referring to a DF column (any argument not matching a local variable is interpreted as being a col reference).↵In addition it needs to support additional 'modifiers'. I.e. to say `aes("x", factor("y"))`. That part could also be done by having a wrapper object that returns some `Factor` object of course. |
| 21:28:27 | FromDiscord | <vindaar> (and it's really not that complicated 😜) |
| 21:29:07 | FromDiscord | <Elegantbeef> Macros are always more complicated than procs 😛 |
| 21:29:22 | FromDiscord | <Elegantbeef> But yes to me it seemed to just set aesthetics, if it does more that's beyond my reading |
| 21:32:12 | * | lx12ucy joined #nim |
| 21:35:56 | FromDiscord | <vindaar> In reply to @Elegantbeef "But yes to me": yeah. In addition you'd run into troubles of mixing things like string arguments, potential types like `Factor`, and more commonly formulas (via `f{}`) etc.↵one might be able to do something using the varargs with converter proc attached, like echo uses. But never much toyed with that |
| 21:42:37 | * | lx12ucy quit (Quit: WeeChat 4.3.2) |
| 21:54:56 | * | lx12ucy joined #nim |
| 22:02:12 | FromDiscord | <Elegantbeef> Well I'd just have a `value.convertTo(field)` |
| 22:02:15 | FromDiscord | <Elegantbeef> Then it's just generic interfaces 😄 |
| 22:06:20 | FromDiscord | <firasuke> Congratulations on the new release! |
| 22:09:07 | * | pmp-p quit (Ping timeout: 268 seconds) |
| 22:09:34 | lx12ucy | nim is so cool man |
| 22:10:08 | FromDiscord | <firasuke> it is |
| 22:35:34 | lx12ucy | what file type and package do you guys recommend for a config file for a CLI tool? |
| 22:35:50 | lx12ucy | looking at std/parsecfg is seems to use .ini files? |
| 22:40:58 | FromDiscord | <leorize> if you want it to be portable, go for a common format like toml/yaml |
| 22:41:08 | FromDiscord | <leorize> ini isn't bad either, though there's no standardization |
| 22:59:28 | FromDiscord | <Robyn [She/Her]> Learning functional concepts by binging videos is fun, gonna try applying the concepts to my Nim code when possible now, but I'm still too much of a procedural-brained folk to switch to a pure functional language :p |
| 22:59:29 | FromDiscord | <Robyn [She/Her]> Would be neat to try |
| 22:59:53 | FromDiscord | <Elegantbeef> Once you go to FP you'll never go back |
| 23:02:53 | FromDiscord | <Robyn [She/Her]> Definitely want to try Haskell, I wonder if a mixed codebase of a purely functional language and a imperative language is a bad idea |
| 23:03:15 | FromDiscord | <Robyn [She/Her]> Like, what if I had Nim and Haskell in one codebase |
| 23:03:30 | FromDiscord | <Robyn [She/Her]> In reply to @Elegantbeef "Once you go to": It is a pipeline |
| 23:03:51 | FromDiscord | <Elegantbeef> You'd be experiencing code reuse and be happy |
| 23:04:09 | FromDiscord | <leorize> I heard it's better to try out F# |
| 23:06:32 | FromDiscord | <leorize> from experience, Haskell is a horrible language to get actual work done |
| 23:07:27 | FromDiscord | <leorize> you will find more success with stuff like OCaml or F# which is a good middle ground between FP and being usable |
| 23:07:43 | FromDiscord | <sOkam! 🫐> .net 🤢 |
| 23:07:55 | FromDiscord | <Robyn [She/Her]> I wanna try a purely functional language though and Haskell fits the bill :P |
| 23:08:06 | FromDiscord | <sOkam! 🫐> I figure F# is a functional C#? |
| 23:08:23 | FromDiscord | <leorize> just don't get caught up in hyperoptimizing your code |
| 23:08:25 | FromDiscord | <sOkam! 🫐> In reply to @chronos.vitaqua "I wanna try a": is rust not purely functional? |
| 23:08:30 | FromDiscord | <Elegantbeef> It's the scala of C# |
| 23:08:39 | FromDiscord | <leorize> haskell gives you enough power to minimize a complex algorithm into 2 lines |
| 23:08:58 | FromDiscord | <Robyn [She/Her]> In reply to @leorize "just don't get caught": I don't do that to begin with 😎 |
| 23:09:19 | FromDiscord | <leorize> don't worry, you will once you learn haskell |
| 23:09:46 | FromDiscord | <Robyn [She/Her]> In reply to @heysokam "is rust not purely": I'm pretty sure it isn't, a purely functional language is always declarative, no? And immutable data and such, must process it via a function call and all that jazz |
| 23:09:52 | FromDiscord | <leorize> you will look at the world in disgust that they have not awakened to operators like `>>=` or `<|>` |
| 23:10:03 | FromDiscord | <Robyn [She/Her]> In reply to @leorize "don't worry, you will": Sounds scary |
| 23:10:18 | FromDiscord | <Robyn [She/Her]> In reply to @leorize "you will look at": What do they both do? |
| 23:10:31 | FromDiscord | <leorize> I don't even remember by now \:p |
| 23:11:10 | FromDiscord | <leorize> the gist is just that some constructs are kinda wordy in haskell |
| 23:11:23 | FromDiscord | <leorize> so people make up operators and such to minimize it |
| 23:11:40 | FromDiscord | <sOkam! 🫐> In reply to @leorize "you will look at": `shr.eq` and `lessthan.or.biggerthan` 😄 😄 |
| 23:12:08 | FromDiscord | <leorize> they overdid it a tiny bit tbh |
| 23:12:20 | FromDiscord | <leorize> you'd feel like you're writing chinese with no prior knowledge |
| 23:12:27 | FromDiscord | <sOkam! 🫐> _that was meant to @ @Robyn [She/Her], btw_ |
| 23:13:04 | FromDiscord | <Robyn [She/Her]> In reply to @leorize "they overdid it a": Yeah I don't like operators on everything :P |
| 23:13:07 | FromDiscord | <sOkam! 🫐> In reply to @leorize "you'd feel like you're": that was the feel I got when looking into it the couple of times i tried |
| 23:13:18 | FromDiscord | <Robyn [She/Her]> In reply to @heysokam "`shr.eq` and `lessthan.or.biggerthan` 😄": :P |
| 23:15:19 | FromDiscord | <sOkam! 🫐> holy crap. I thought I had passed the GLFW exam enough times already to understand it all↵https://github.com/achirkin/vulkan/blob/master/vulkan-examples/02-GLFWWindow.hs↵yeah... nvm! I don't get anything in there 🙈 |
| 23:15:55 | FromDiscord | <sOkam! 🫐> vulkan+haskell looks insane |
| 23:16:14 | FromDiscord | <leorize> here is a funny trivia, as you work your way into making real programs with Haskell, you will see an infinite amount of people saying "Don't fear the Monad" |
| 23:16:14 | FromDiscord | <leorize> indirectly making people afraid of it |
| 23:16:34 | FromDiscord | <Robyn [She/Her]> What is the monad?- |
| 23:17:41 | FromDiscord | <leorize> i'm not qualified to answer that question |
| 23:18:14 | FromDiscord | <Elegantbeef> The monad connects to the functor bone |
| 23:18:26 | FromDiscord | <sOkam! 🫐> In reply to @leorize "here is a funny": > Don't think about a pink elephant...↵_"goodjob smartie, I just did"_ |
| 23:19:09 | FromDiscord | <Robyn [She/Her]> In reply to @Elegantbeef "The monad connects to": Damn |
