00:22:32 | * | def- quit (Quit: -) |
00:22:50 | * | def- joined #nim |
01:16:55 | * | def- quit (Quit: -) |
01:30:54 | * | krux02_ quit (Remote host closed the connection) |
01:35:12 | * | def- joined #nim |
02:54:08 | * | def- quit (Quit: -) |
02:55:16 | * | def- joined #nim |
02:55:22 | * | deadmarshal_ quit (Quit: IRCNow and Forever!) |
02:59:29 | * | def- quit (Client Quit) |
03:01:43 | * | def- joined #nim |
03:02:56 | * | deadmarshal_ joined #nim |
03:04:38 | * | def- quit (Client Quit) |
03:05:26 | NimEventer | New Nimble package! nimtcl - Low-level Tcl & Tk bindings for Nim, see https://github.com/neroist/nimtcl |
03:05:30 | * | def- joined #nim |
03:25:39 | FromDiscord | <sOkam! 🫐> @pmunch I'm making some progress with using your opir code as a reference to translate directly into PNodes↵I'm struggling to understand how to deal with context during recursion with the `visitCB` callback 🤔↵Do you have any tips or help on how to go into the function bodies to recurse their code too? |
03:27:20 | FromDiscord | <sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=xuRfvxdcchtj |
03:28:33 | * | xet7 quit (Remote host closed the connection) |
03:30:02 | * | xet7 joined #nim |
03:41:01 | * | def- quit (Quit: -) |
03:44:55 | * | def- joined #nim |
03:56:10 | FromDiscord | <sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=edsNWHGkhTaI |
03:59:14 | * | def- quit (Quit: -) |
04:06:43 | * | def- joined #nim |
04:50:12 | * | def- quit (Quit: -) |
04:52:45 | FromDiscord | <ringabout> In reply to @vindaar "<@658563905425244160> just pushed a": It works now. Thank you! |
04:55:34 | * | def- joined #nim |
04:55:53 | FromDiscord | <pmunch> sent a code paste, see https://play.nim-lang.org/#pasty=DmGGmFmIFezd |
04:56:24 | FromDiscord | <pmunch> Why are you generating PNodes directly by the way? |
04:58:38 | * | SchweinDeBurg quit (Quit: WeeChat 4.3.0-dev) |
04:59:04 | * | SchweinDeBurg joined #nim |
05:24:43 | * | def- quit (Quit: -) |
05:25:54 | * | def- joined #nim |
05:27:13 | * | nyeaa49284230101 joined #nim |
05:54:35 | * | def- quit (Quit: -) |
05:56:00 | * | def- joined #nim |
07:40:47 | * | SchweinDeBurg quit (Quit: WeeChat 4.3.0-dev) |
07:40:57 | * | SchweinDeBurg joined #nim |
07:42:00 | FromDiscord | <whisperecean> @arnetheduck Is it possible that in my nimble configuration I specify your nil-stream branch? |
08:01:23 | * | def- quit (Quit: -) |
08:02:15 | * | def- joined #nim |
08:26:15 | * | deadmarshal_ quit (Quit: IRCNow and Forever!) |
08:35:58 | NimEventer | New Nimble package! simpleMail - Make sending HTML and file emails easier., see https://github.com/up7down8/simpleMail |
08:35:58 | NimEventer | New Nimble package! asyncssh2 - Execute commands and upload/download files using multiple processes and asynchronous methods via SSH., see https://github.com/up7down8/asyncssh2 |
08:52:13 | * | deadmarshal_ joined #nim |
09:04:12 | * | deadmarshal_ quit (Quit: IRCNow and Forever!) |
09:17:48 | * | deadmarshal_ joined #nim |
10:32:24 | * | def- quit (Quit: -) |
10:52:36 | * | def- joined #nim |
10:58:12 | FromDiscord | <sOkam! 🫐> In reply to @pmunch "Why are you generating": Because I already have a compiler from PNodes to my lang |
10:58:38 | FromDiscord | <sOkam! 🫐> Kindof figured it out. Still didn't solve it, but I guess the `parent` context is the way to do it |
10:58:50 | PMunch | Aah I see |
10:59:28 | PMunch | But yeah, you pass context along, however not through `parent` I think. Isn't there a separate context pointer thing? |
11:04:38 | FromDiscord | <sOkam! 🫐> there is a `userdata` pointer that can be set to whatever I want |
11:04:53 | FromDiscord | <sOkam! 🫐> but I meant context of the AST, not context of my own code |
11:04:54 | * | def- quit (Quit: -) |
11:08:41 | * | def- joined #nim |
11:11:45 | * | def- quit (Client Quit) |
11:14:34 | * | def- joined #nim |
11:20:25 | * | def- quit (Quit: -) |
11:35:10 | * | xutaxkamay quit (Read error: Connection reset by peer) |
11:35:20 | * | xutaxkamay_ joined #nim |
11:36:04 | * | xutaxkamay_ is now known as xutaxkamay |
11:39:26 | * | def- joined #nim |
11:56:08 | * | def- quit (Quit: -) |
11:56:30 | * | def- joined #nim |
11:59:26 | * | def- quit (Client Quit) |
12:19:28 | * | def- joined #nim |
12:36:05 | * | MacDefender joined #nim |
12:56:53 | * | def- quit (Quit: -) |
12:59:10 | * | def- joined #nim |
13:35:46 | FromDiscord | <narimiran> New Nim releases are out! https://nim-lang.org/blog/2024/04/16/versions-1620-204-released.html |
13:36:43 | FromDiscord | <nnsee> nice |
13:39:08 | NimEventer | New thread by miran: Nim 2.0.4 and 1.6.20 released, see https://forum.nim-lang.org/t/11440 |
13:41:45 | FromDiscord | <griffith1deadly> was just thinking to myself today, when is Nim 2.0.4 coming out there with the standard allocator fix. Yay! |
13:41:52 | FromDiscord | <Josue()> Nice↵(@narimiran) |
13:44:24 | * | om3ga quit (Ping timeout: 260 seconds) |
13:52:37 | * | om3ga joined #nim |
13:54:03 | * | ntat joined #nim |
13:55:12 | PMunch | :( My showstopper bug is still present in 2.0.4 |
13:55:34 | FromDiscord | <narimiran> In reply to @PMunch ":( My showstopper bug": is there a fix for it in devel? |
13:55:52 | PMunch | Let me check |
13:56:13 | PMunch | Nope, devel is also affected |
13:58:20 | FromDiscord | <nnsee> what is the bug |
13:58:46 | PMunch | https://github.com/nim-lang/Nim/issues/22672 |
13:59:13 | PMunch | Result variable isn't freed with ARC/ORC if as exception is thrown |
13:59:22 | FromDiscord | <nnsee> oh right, this one |
14:00:38 | * | PMunch quit (Quit: Leaving) |
14:13:00 | * | xutaxkamay quit (Quit: ZNC 1.8.2+deb3.1 - https://znc.in) |
14:13:58 | * | xutaxkamay joined #nim |
14:30:27 | * | def- quit (Quit: -) |
14:31:14 | * | def- joined #nim |
14:35:49 | FromDiscord | <tauruuuuuus> So devel is not the base for releases? I see far less commits in v2.0.4 with respect to what happens on devel |
14:39:21 | FromDiscord | <kots> Afaict, releases happen on the version-2-0 branch and commits need to be backported from devel in order to be included |
14:39:47 | FromDiscord | <odexine> i think devel is the base for the next major/minor |
14:39:49 | FromDiscord | <tauruuuuuus> just a brain fart, just noticed it's a bugfix release |
15:28:14 | * | def- quit (Quit: -) |
15:29:02 | * | def- joined #nim |
15:52:41 | FromDiscord | <djazz> In reply to @PMunch "Result variable isn't freed": ouch, thats bad |
15:55:54 | FromDiscord | <jaar23> sent a code paste, see https://play.nim-lang.org/#pasty=eemBSburEQac |
15:56:29 | FromDiscord | <jaar23> what does this error means? try to give `=destroy` to Task and Channel but both not working. Not quite understand why is it |
16:18:16 | * | def- quit (Quit: -) |
16:20:55 | FromDiscord | <pmunch> In reply to @djazz "ouch, thats bad": Yeah it's not great.. |
16:21:18 | FromDiscord | <pmunch> I was surprised to be the first to discover it |
16:36:58 | * | def- joined #nim |
16:49:53 | FromDiscord | <jviega> Well, the # of showstoppers w/ Orc and very bad early 2.0 experience w/ it is definitley keeping us from jumping to it quickly |
17:14:26 | * | MacDefender quit (Quit: WeeChat 4.2.2) |
17:18:07 | * | dtomato0 joined #nim |
17:19:51 | * | dtomato quit (Ping timeout: 256 seconds) |
17:19:52 | * | dtomato0 is now known as dtomato |
17:25:53 | FromDiscord | <nervecenter> Using `refc` is still fine, if just to get the nice syntactic features. |
17:26:10 | FromDiscord | <nervecenter> Haven't had any issues forcing that myself |
17:53:04 | FromDiscord | <Phil> In reply to @jaar23 "hi, i'm trying to": For one I'd more recommend using the channels from threadpool, those are fully data-race free by now |
17:53:17 | FromDiscord | <Phil> (edit) "threadpool," => "threading," |
17:55:09 | FromDiscord | <Phil> As for this one in particular, the issue lies within ch.recv↵I'm not quite sure why it's blowing up on you, can't say I ever encountered that back when I still tried to support those.↵It might be `PRawChannel` that is screwing you (ch.recv casts the channel you pass in to that one). |
17:55:38 | FromDiscord | <Phil> Which is a type you don't have access to and can't do anything about.↵↵Can you write a minimal example that blows up in a similar fashion? |
18:00:56 | FromDiscord | <jaar23> yea, sure. let me come out with an example |
18:11:56 | * | def- quit (Quit: -) |
18:12:28 | * | def- joined #nim |
18:16:47 | FromDiscord | <jaar23> sent a code paste, see https://play.nim-lang.org/#pasty=ruTSdvILzHvl |
18:17:48 | * | def- quit (Quit: -) |
18:22:28 | * | def- joined #nim |
18:23:37 | FromDiscord | <jaar23> In reply to @isofruit "For one I'd more": i will switch to `threading` at the moment then. thank you. |
18:29:13 | FromDiscord | <Phil> sent a code paste, see https://play.nim-lang.org/#pasty=OjZfrAaQUSRW |
18:29:30 | FromDiscord | <Phil> As you can see you destroy 2 objects here:↵The exception and the task |
18:30:21 | FromDiscord | <Phil> Now the big question would be either to look into wth the task is doing (it could very well be that std/tasks is just completely backstabbing you) or to wonder whether an exception (which gets assigned to a :tmpD variable) can actually blow up like this on you |
18:31:19 | FromDiscord | <Phil> Actually wait, no bad, the destroy call happens in recv, that's whats blowing up on you |
18:31:57 | FromDiscord | <Phil> sent a code paste, see https://play.nim-lang.org/#pasty=LcviluifeCSH |
18:32:41 | FromDiscord | <Phil> At which point I'm about to give up because that's an entire boatload of wtf waiting to happen |
18:33:10 | FromDiscord | <Phil> I swear multithreading in nim can be so insanely annoying to deal with |
18:34:35 | FromDiscord | <Phil> I mean sure, the threading lib are basically where things in Nim are moving but you could at least expect this kind of stuff to work more generally.↵↵@jaar23 you can also just try to use refc depending on your usecase, refc should definitely work here and not run into annoying bugs in interaction with ARC/ORC |
18:34:54 | FromDiscord | <Phil> generally you'll want to go either refc with system.Channels or ARC/ORC with threading I think |
18:37:01 | FromDiscord | <jaar23> In reply to @isofruit "I mean sure, the": hmm, i tried with refc earlier but it's end up with the same error. |
18:37:38 | FromDiscord | <Phil> Oh screw that, refc runs into compilation errors on the C level, god damn man |
18:37:47 | FromDiscord | <Phil> Yeah I'm never using tasks, nor malebolgia, jesus |
18:37:47 | FromDiscord | <jaar23> i didn't dig deep enough but i guess the destroy is called by channel since it's move out of the space. |
18:38:16 | FromDiscord | <jaar23> In reply to @isofruit "But for more general": btw, this is when you build with --expandArc? |
18:38:30 | FromDiscord | <Phil> --expandArc:<procname> |
18:38:51 | FromDiscord | <Phil> Can be any proc that gets compiled as part of your program |
18:38:56 | FromDiscord | <Phil> so you can even use that on recv |
18:39:01 | FromDiscord | <Phil> or procs that recv calls |
18:39:25 | FromDiscord | <jaar23> ah, i see. i rewrite with threading/channels with both ARC and ORC and it's working. |
18:39:46 | FromDiscord | <jaar23> like you say, multi-threading in nim something is kind of insane when debugging it |
18:40:08 | FromDiscord | <Phil> I'll tell you what somebody very wise told me and leorize will know whom I speak of |
18:40:27 | FromDiscord | <Phil> Unless a library loudly and proudly declares its for multithreading and threadsafe, it isn't |
18:40:35 | FromDiscord | <Phil> That includes any larger project including status projects |
18:40:44 | FromDiscord | <Phil> And you will ALWAYS want to use asan/tsan |
18:40:49 | FromDiscord | <Phil> Because multithreading is an asshole like that |
18:41:00 | FromDiscord | <jaar23> asan/tsan? |
18:41:29 | FromDiscord | <Phil> So you know how you might have sigsev from doing nil access, or reusing a bit of memory after you freed it or the like? |
18:41:38 | FromDiscord | <Phil> That's something you can detect via a tool ahead of time called address-sanitizier |
18:41:41 | FromDiscord | <Phil> (edit) "address-sanitizier" => "address-sanitizer" |
18:41:45 | FromDiscord | <requiresupport> noticed in some of the nim stdlib `when useLibC` how do I define `not useLibC` I assume this is default to use libc |
18:41:52 | FromDiscord | <jaar23> the very minimal thing i tried to do is reducing the number of moving variables in between and using channel as much as possible. |
18:42:23 | FromDiscord | <Phil> It's part any decent C compiler but personally I just use clang for it because it was the first to implement it |
18:42:32 | FromDiscord | <requiresupport> `--define:nimNoLibc ` ? |
18:43:10 | FromDiscord | <jaar23> ah, i see. will probably need to look into it some day |
18:44:21 | FromDiscord | <Phil> Its a feature of the underlying C compiler less than nim itself.↵Asan provides you a stack trace if you have use-after-frees or similar really evil memory bugs:↵You'll want to use these flags for asan:↵`--passl:"-fsanitize=address" --passc:"-fsanitize=address" --passc:"-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer"` |
18:45:09 | FromDiscord | <Phil> The output you'll get is normal stacktraces (think java-like stacktraces kinda if you squint very hard) that will try to show you where you do evil things.↵Trust that thing. even if you think it makes no sense, it is better than any of us in this channel at spotting memory bugs. Combined. |
18:46:36 | FromDiscord | <Phil> sent a long message, see https://pasty.ee/kTTWqOkDgqJB |
18:48:04 | FromDiscord | <Phil> There's also more tools for the same job, namely valgrind with memcheck as a slower but "different" version of asan (so it might notice things that asan misses and vice versa) while valgrin's also has a tool called "helgrind" which does the same thing tsan does (also like 10x slower but in a different way) |
18:48:18 | FromDiscord | <Phil> (edit) "valgrin's" => "valgrind" |
18:48:33 | FromDiscord | <Phil> (edit) "There's also more tools for the same job, namely valgrind with ... memchecksub-program" added "sub-program called" | "tool" => "sub-program" |
18:49:36 | FromDiscord | <Phil> Note that debugging TSAN stacktraces has been, and continues to be (or will continue to be) one of the most challenging things I've done so far because so much is non-obvious |
18:49:57 | FromDiscord | <jaar23> very infomative, thanks @Phil ↵i wish i know this tricks earlier, whn developing my previous project, that's exactly a data races thing when i have more then 1000 connection trying to access my queue. |
18:50:26 | FromDiscord | <Phil> I learned a lot of this stuff the hard way while I was starting on writing my own multithreading runtime |
18:50:40 | FromDiscord | <jaar23> i hope i don |
18:51:03 | FromDiscord | <Phil> I also recommend to not use the default nim allocator |
18:51:06 | FromDiscord | <Phil> Use malloc |
18:51:09 | FromDiscord | <jaar23> (edit) "don" => "don't end up writing my own runtime, i'm quite dumb at that. haha" |
18:51:25 | FromDiscord | <Phil> For your own sanity, the default nim allocator had data races when I checked like 4-5 months ago |
18:51:29 | FromDiscord | <jaar23> why not nim allocator |
18:51:33 | FromDiscord | <Phil> under arc/orc |
18:51:42 | FromDiscord | <jaar23> hmm, i see. |
18:51:58 | FromDiscord | <Phil> https://github.com/PhilippMDoerner/ThreadButler?tab=readme-ov-file#must-use--dusemalloc↵My reasoning |
18:53:16 | FromDiscord | <Phil> This may potentially be of use to you.↵It's written more specifically for ThreadButler, but a lot should be applicable to general multithreading:↵https://philippmdoerner.github.io/ThreadButler/bookCompiled/leaks.html |
18:53:57 | FromDiscord | <Phil> tsan works very similar to asan in how you use it.↵The domain specific knowledge on how to fix data-races I can't impart, I don't have enough myself. |
18:55:55 | FromDiscord | <jaar23> I see, I guess I might have faced this issue when passing around with ref variable, just it's not happening too frequent |
18:56:24 | FromDiscord | <Phil> Honestly system Channels won't allow you to introduce memory leaks like that |
18:56:34 | FromDiscord | <Phil> Because system channels make deep-copies of everything you send |
18:56:47 | FromDiscord | <Phil> So you're never message passing, you're always sending copies and every thread has their own copy of a given message |
18:57:11 | FromDiscord | <Phil> Only threading.Channels allows you to actually "move" a ref from one thread to another, effectively "sharing memory" in a sense |
18:57:29 | FromDiscord | <Phil> That's one of the underlying benefits ARC/ORC brings with it, it makes that possible. |
18:57:45 | FromDiscord | <Phil> That doesn't mean it works well yet in my experience, but the underlying fundamentals are there for it to work that way |
18:58:18 | FromDiscord | <jaar23> Yea, that's why I'm using it as well. System channel is safe as long as I'm running thread local var. |
18:59:15 | FromDiscord | <jaar23> I bet that's because std/tasks used ptr for it's variable access within the function. And that causing it failed to copy or not allow to copy such by design |
19:00:19 | FromDiscord | <Robyn [She/Her]> Hey Phil, would you know if you can use a different allocator instead of malloc via Nim? |
19:00:44 | FromDiscord | <Elegantbeef> https://github.com/Yardanico/mimalloc_nim |
19:00:49 | FromDiscord | <Phil> Sure you can. Have I tried? Hell naw, malloc is tried and true |
19:01:12 | FromDiscord | <Phil> malloc is the bedrock I'm willing to build a castle of multithreaded sand upon |
19:01:27 | FromDiscord | <Phil> So that when it blows up, at least it's not the bedrock's fault |
19:03:06 | * | ntat quit (Quit: Leaving) |
19:05:30 | FromDiscord | <Robyn [She/Her]> In reply to @Elegantbeef "https://github.com/Yardanico/mimalloc_nim": Neat |
19:05:37 | FromDiscord | <Robyn [She/Her]> In reply to @isofruit "Sure you can. Have": Fair enough honestly |
19:06:10 | * | def- quit (Quit: -) |
19:07:55 | * | def- joined #nim |
19:11:42 | * | def- quit (Client Quit) |
19:14:30 | FromDiscord | <Elegantbeef> The nice thing on libc linux is that `malloc` is a part of a dynlib so you can actually overload it using `LD_PRELOAD` |
19:15:17 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=LfotRkLWDsQy |
19:24:11 | * | ntat joined #nim |
19:35:20 | * | def- joined #nim |
19:50:36 | FromDiscord | <recycledloveletter> any good guides to pointers in nim? specifically getting pointer addresses |
19:51:29 | FromDiscord | <recycledloveletter> any advice is welcome except for the bot with dog profile picture |
19:54:33 | * | ntat quit (Quit: Leaving) |
19:56:35 | FromDiscord | <Elegantbeef> Lol |
19:56:35 | FromDiscord | <Elegantbeef> `addr` is all you need very rude person |
19:57:06 | Amun-Ra | hmm |
20:07:56 | FromDiscord | <Elegantbeef> What amun? |
20:12:34 | FromDiscord | <nnsee> hmmm |
20:13:41 | FromDiscord | <nnsee> In reply to @Elegantbeef "`addr` is all you": from they're live status, they're currently editing "rop.c" |
20:14:11 | FromDiscord | <nnsee> i'm not sure how rop would work in the context of nim or how nim is even relevant |
20:14:46 | FromDiscord | <demotomohiro> sent a code paste, see https://play.nim-lang.org/#pasty=nsbiZsknBOPF |
20:15:33 | FromDiscord | <Robyn [She/Her]> In reply to @Elegantbeef "`addr` is all you": Lmao |
20:16:10 | FromDiscord | <Robyn [She/Her]> Imagine being rude to the person who has very good general knowledge of Nim who is also very active |
20:16:55 | FromDiscord | <Elegantbeef> I'm sorry I'll do better next time |
20:17:06 | Amun-Ra | Elegantbeef: just wondering what that exclusion is about |
20:18:28 | FromDiscord | <Robyn [She/Her]> In reply to @Amun-Ra "<@145405730571288577>: just wondering what": Don't think it's suitable for this channel, are you in nim-offtopic? |
20:18:52 | Amun-Ra | sure |
20:19:49 | FromDiscord | <mekac4321> # Hot Teen & Onlyfans Leaks :underage: :peach: https://discord.gg/sexleaks @everyone |
20:19:57 | FromDiscord | <nnsee> <@&371760044473319454> |
20:26:23 | FromDiscord | <Robyn [She/Her]> Slightly ot but still programming related, but why is `int` not named `sint` (for signed int) in most, if not all programming languages |
20:26:53 | FromDiscord | <Robyn [She/Her]> Also it's funny how saying `not all` makes sense but `none` wouldn't in that context, even though the opposite of `all` is `none` |
20:28:19 | FromDiscord | <nnsee> i think because using unsigned ints should be a conscious choice because of the bugs they could introduce |
20:28:41 | FromDiscord | <nnsee> you're much more likely to underflow (oops, i did 0-1) etc |
20:29:07 | FromDiscord | <Robyn [She/Her]> Why don't unsigned ints handle overflow by default, seems trivial? |
20:29:17 | FromDiscord | <Robyn [She/Her]> Though, actually |
20:29:31 | FromDiscord | <Robyn [She/Her]> Signed integers have special CPU instructions, right? |
20:30:44 | FromDiscord | <nnsee> In reply to @chronos.vitaqua "Signed integers have special": well only for comparisons iirc |
20:30:45 | FromDiscord | <demotomohiro> In reply to @chronos.vitaqua "Why don't unsigned ints": https://internet-of-tomohiro.pages.dev/nim/faq.en#language-design-why-are-unsigned-types-discouragedqmark |
20:30:48 | Amun-Ra | yes, depends on a cpu |
20:33:07 | FromDiscord | <Robyn [She/Her]> In reply to @demotomohiro "https://internet-of-tomohiro.pages.dev/nim/faq.en#l": Ah |
20:42:49 | FromDiscord | <jviega> No sigifnicant architecture distinguishes type. Specific instructions will have semantics around the type, but generally for multiplies and adds there will be a special 'overflow' bit. Traditionally, many programming languages always just ignore it. The linked post from the Nim faq is a bit silly, it assumes C semantics. It's perfectly reasonable to either a) use the carry bit, or on more modern architectures use 128 bit operands for your |
20:45:38 | Amun-Ra | there are usually separate instructions for signed and unsigned operatins that differ in setting flags |
20:47:15 | Amun-Ra | as for C, C defines overflow only for signed types (which is UB until C2x - I haven't checked whether C2x still treats it as such) |
20:50:59 | Amun-Ra | (prior c23 there was no guarantee signed int representation is two's complement) |
21:24:37 | * | def- quit (Quit: -) |
21:25:25 | FromDiscord | <jviega> Who cares about C, and I don't now what architecture you're talking about, but generally there's both a carry and an overflow flag, where carry indicates the op if treated as unsigned overflowed, and overflow indicates that if treated as signed overflowed. |
21:28:14 | FromDiscord | <.bobbbob> In reply to @chronos.vitaqua "Why don't unsigned ints": do you mean throw an exception when you overflow? usually you use unsigned int specifically when you want to have overflow/underflow (think: emulating digital logic). I think most modern languages throw an exception with signed int overflow but C doesnt so good luck c users |
21:28:45 | FromDiscord | <jviega> The way ALUs work, having different instructions makes no sense, it'd be an extra opcode for no real reason. 'signed vs unsigned' really is just about which of those two bits you care about at the hardware level. |
21:29:20 | * | G3ngh1s_ quit (Read error: Connection reset by peer) |
21:29:53 | FromDiscord | <.bobbbob> In reply to @jviega "The way ALUs work,": it doesnt matter for addition and subtraction but the math is different for multiplication and division so theres different instructions for that, also checking greater than and less than |
21:31:47 | FromDiscord | <jviega> Yes, it depends on the architecture but there are a bevy of instructions on x86, and it doesn't need 2 instructions when the output is the same size as the input arguments. |
21:32:07 | FromDiscord | <jviega> Believe me, I have my own multiply instruction on the x86 🙂 |
21:32:26 | FromDiscord | <.bobbbob> I think x86 has instructions for everything imaginable lol |
21:34:04 | FromDiscord | <jviega> I'm not even kidding, `PCLMULQDQ` which is a GF(2^128) multiply operation for two 128-bit operands. |
21:35:51 | FromDiscord | <jviega> Well, actually, the instruction itself is a primitive for it, it actually works on 2 64-bit operands |
21:36:19 | FromDiscord | <jviega> But specifically was to be able to support the GF(2^128) multiplies |
21:43:15 | * | def- joined #nim |
21:49:43 | FromDiscord | <demotomohiro> !eval echo cast[int](cast[uint](-3) cast[uint](-2)) |
21:49:45 | NimBot | Compile failed: /usercode/in.nim(1, 31) Error: invalid token: (\29) |
21:50:01 | FromDiscord | <Elegantbeef> Get irc bridged |
21:51:02 | FromDiscord | <demotomohiro> !eval echo 1 1 |
21:51:04 | NimBot | Compile failed: /usercode/in.nim(1, 8) Error: invalid token: (\29) |
21:51:54 | FromDiscord | <demotomohiro> I forgot that bot doesn't work with '' from discord. |
21:54:18 | FromDiscord | <demotomohiro> Anyway, you can use `mul` for unsigned ints for multipying signed ints. |
21:56:51 | FromDiscord | <demotomohiro> But x86 has `mul` for unsigned int and `imul` for signed int. |
22:05:00 | FromDiscord | <demotomohiro> Both `mul` and `imul` returns 128bit result from two 64bit ints.↵And if you use `mul` for signed int, you get wrong higher 64bit result. |
22:08:23 | * | def- quit (Quit: -) |
22:10:53 | FromDiscord | <albassort> is there a way to parse datetimes |
22:10:57 | FromDiscord | <albassort> sent a code paste, see https://paste.rs/B0Hf7 |
22:11:21 | FromDiscord | <albassort> (edit) "is there a way to parse ... datetimes" added "ISO" |
22:13:55 | FromDiscord | <albassort> by "way" i mean a cleaner function than this |
22:26:55 | * | def- joined #nim |
23:35:07 | FromDiscord | <.bobbbob> sent a code paste, see https://play.nim-lang.org/#pasty=qpbBIKREOKVp |
23:57:19 | FromDiscord | <morgan> today i've made some progress on writing an abstraction over the raw clap api. it's not functional yet as it's just params, and i still want to write some procs for creating parameter objects more easily, but i think it'll be nicer and it's headed in the right direction |