<< 16-04-2024 >>
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:26NimEventerNew Nimble package! nimtcl - Low-level Tcl & Tk bindings for Nim, see https://github.com/neroist/nimtcl
03:05:30*def- joined #nim
03:25:39FromDiscord<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:20FromDiscord<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:10FromDiscord<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:45FromDiscord<ringabout> In reply to @vindaar "<@658563905425244160> just pushed a": It works now. Thank you!
04:55:34*def- joined #nim
04:55:53FromDiscord<pmunch> sent a code paste, see https://play.nim-lang.org/#pasty=DmGGmFmIFezd
04:56:24FromDiscord<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:00FromDiscord<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:58NimEventerNew Nimble package! simpleMail - Make sending HTML and file emails easier., see https://github.com/up7down8/simpleMail
08:35:58NimEventerNew 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:12FromDiscord<sOkam! 🫐> In reply to @pmunch "Why are you generating": Because I already have a compiler from PNodes to my lang
10:58:38FromDiscord<sOkam! 🫐> Kindof figured it out. Still didn't solve it, but I guess the `parent` context is the way to do it
10:58:50PMunchAah I see
10:59:28PMunchBut yeah, you pass context along, however not through `parent` I think. Isn't there a separate context pointer thing?
11:04:38FromDiscord<sOkam! 🫐> there is a `userdata` pointer that can be set to whatever I want
11:04:53FromDiscord<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:46FromDiscord<narimiran> New Nim releases are out! https://nim-lang.org/blog/2024/04/16/versions-1620-204-released.html
13:36:43FromDiscord<nnsee> nice
13:39:08NimEventerNew thread by miran: Nim 2.0.4 and 1.6.20 released, see https://forum.nim-lang.org/t/11440
13:41:45FromDiscord<griffith1deadly> was just thinking to myself today, when is Nim 2.0.4 coming out there with the standard allocator fix. Yay!
13:41:52FromDiscord<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:12PMunch:( My showstopper bug is still present in 2.0.4
13:55:34FromDiscord<narimiran> In reply to @PMunch ":( My showstopper bug": is there a fix for it in devel?
13:55:52PMunchLet me check
13:56:13PMunchNope, devel is also affected
13:58:20FromDiscord<nnsee> what is the bug
13:58:46PMunchhttps://github.com/nim-lang/Nim/issues/22672
13:59:13PMunchResult variable isn't freed with ARC/ORC if as exception is thrown
13:59:22FromDiscord<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:49FromDiscord<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:21FromDiscord<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:47FromDiscord<odexine> i think devel is the base for the next major/minor
14:39:49FromDiscord<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:41FromDiscord<djazz> In reply to @PMunch "Result variable isn't freed": ouch, thats bad
15:55:54FromDiscord<jaar23> sent a code paste, see https://play.nim-lang.org/#pasty=eemBSburEQac
15:56:29FromDiscord<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:55FromDiscord<pmunch> In reply to @djazz "ouch, thats bad": Yeah it's not great..
16:21:18FromDiscord<pmunch> I was surprised to be the first to discover it
16:36:58*def- joined #nim
16:49:53FromDiscord<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:53FromDiscord<nervecenter> Using `refc` is still fine, if just to get the nice syntactic features.
17:26:10FromDiscord<nervecenter> Haven't had any issues forcing that myself
17:53:04FromDiscord<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:17FromDiscord<Phil> (edit) "threadpool," => "threading,"
17:55:09FromDiscord<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:38FromDiscord<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:56FromDiscord<jaar23> yea, sure. let me come out with an example
18:11:56*def- quit (Quit: -)
18:12:28*def- joined #nim
18:16:47FromDiscord<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:37FromDiscord<jaar23> In reply to @isofruit "For one I'd more": i will switch to `threading` at the moment then. thank you.
18:29:13FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=OjZfrAaQUSRW
18:29:30FromDiscord<Phil> As you can see you destroy 2 objects here:↵The exception and the task
18:30:21FromDiscord<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:19FromDiscord<Phil> Actually wait, no bad, the destroy call happens in recv, that's whats blowing up on you
18:31:57FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=LcviluifeCSH
18:32:41FromDiscord<Phil> At which point I'm about to give up because that's an entire boatload of wtf waiting to happen
18:33:10FromDiscord<Phil> I swear multithreading in nim can be so insanely annoying to deal with
18:34:35FromDiscord<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:54FromDiscord<Phil> generally you'll want to go either refc with system.Channels or ARC/ORC with threading I think
18:37:01FromDiscord<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:38FromDiscord<Phil> Oh screw that, refc runs into compilation errors on the C level, god damn man
18:37:47FromDiscord<Phil> Yeah I'm never using tasks, nor malebolgia, jesus
18:37:47FromDiscord<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:16FromDiscord<jaar23> In reply to @isofruit "But for more general": btw, this is when you build with --expandArc?
18:38:30FromDiscord<Phil> --expandArc:<procname>
18:38:51FromDiscord<Phil> Can be any proc that gets compiled as part of your program
18:38:56FromDiscord<Phil> so you can even use that on recv
18:39:01FromDiscord<Phil> or procs that recv calls
18:39:25FromDiscord<jaar23> ah, i see. i rewrite with threading/channels with both ARC and ORC and it's working.
18:39:46FromDiscord<jaar23> like you say, multi-threading in nim something is kind of insane when debugging it
18:40:08FromDiscord<Phil> I'll tell you what somebody very wise told me and leorize will know whom I speak of
18:40:27FromDiscord<Phil> Unless a library loudly and proudly declares its for multithreading and threadsafe, it isn't
18:40:35FromDiscord<Phil> That includes any larger project including status projects
18:40:44FromDiscord<Phil> And you will ALWAYS want to use asan/tsan
18:40:49FromDiscord<Phil> Because multithreading is an asshole like that
18:41:00FromDiscord<jaar23> asan/tsan?
18:41:29FromDiscord<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:38FromDiscord<Phil> That's something you can detect via a tool ahead of time called address-sanitizier
18:41:41FromDiscord<Phil> (edit) "address-sanitizier" => "address-sanitizer"
18:41:45FromDiscord<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:52FromDiscord<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:23FromDiscord<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:32FromDiscord<requiresupport> `--define:nimNoLibc ` ?
18:43:10FromDiscord<jaar23> ah, i see. will probably need to look into it some day
18:44:21FromDiscord<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:09FromDiscord<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:36FromDiscord<Phil> sent a long message, see https://pasty.ee/kTTWqOkDgqJB
18:48:04FromDiscord<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:18FromDiscord<Phil> (edit) "valgrin's" => "valgrind"
18:48:33FromDiscord<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:36FromDiscord<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:57FromDiscord<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:26FromDiscord<Phil> I learned a lot of this stuff the hard way while I was starting on writing my own multithreading runtime
18:50:40FromDiscord<jaar23> i hope i don
18:51:03FromDiscord<Phil> I also recommend to not use the default nim allocator
18:51:06FromDiscord<Phil> Use malloc
18:51:09FromDiscord<jaar23> (edit) "don" => "don't end up writing my own runtime, i'm quite dumb at that. haha"
18:51:25FromDiscord<Phil> For your own sanity, the default nim allocator had data races when I checked like 4-5 months ago
18:51:29FromDiscord<jaar23> why not nim allocator
18:51:33FromDiscord<Phil> under arc/orc
18:51:42FromDiscord<jaar23> hmm, i see.
18:51:58FromDiscord<Phil> https://github.com/PhilippMDoerner/ThreadButler?tab=readme-ov-file#must-use--dusemalloc↵My reasoning
18:53:16FromDiscord<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:57FromDiscord<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:55FromDiscord<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:24FromDiscord<Phil> Honestly system Channels won't allow you to introduce memory leaks like that
18:56:34FromDiscord<Phil> Because system channels make deep-copies of everything you send
18:56:47FromDiscord<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:11FromDiscord<Phil> Only threading.Channels allows you to actually "move" a ref from one thread to another, effectively "sharing memory" in a sense
18:57:29FromDiscord<Phil> That's one of the underlying benefits ARC/ORC brings with it, it makes that possible.
18:57:45FromDiscord<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:18FromDiscord<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:15FromDiscord<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:19FromDiscord<Robyn [She/Her]> Hey Phil, would you know if you can use a different allocator instead of malloc via Nim?
19:00:44FromDiscord<Elegantbeef> https://github.com/Yardanico/mimalloc_nim
19:00:49FromDiscord<Phil> Sure you can. Have I tried? Hell naw, malloc is tried and true
19:01:12FromDiscord<Phil> malloc is the bedrock I'm willing to build a castle of multithreaded sand upon
19:01:27FromDiscord<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:30FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "https://github.com/Yardanico/mimalloc_nim": Neat
19:05:37FromDiscord<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:30FromDiscord<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:17FromDiscord<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:36FromDiscord<recycledloveletter> any good guides to pointers in nim? specifically getting pointer addresses
19:51:29FromDiscord<recycledloveletter> any advice is welcome except for the bot with dog profile picture
19:54:33*ntat quit (Quit: Leaving)
19:56:35FromDiscord<Elegantbeef> Lol
19:56:35FromDiscord<Elegantbeef> `addr` is all you need very rude person
19:57:06Amun-Rahmm
20:07:56FromDiscord<Elegantbeef> What amun?
20:12:34FromDiscord<nnsee> hmmm
20:13:41FromDiscord<nnsee> In reply to @Elegantbeef "`addr` is all you": from they're live status, they're currently editing "rop.c"
20:14:11FromDiscord<nnsee> i'm not sure how rop would work in the context of nim or how nim is even relevant
20:14:46FromDiscord<demotomohiro> sent a code paste, see https://play.nim-lang.org/#pasty=nsbiZsknBOPF
20:15:33FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "`addr` is all you": Lmao
20:16:10FromDiscord<Robyn [She/Her]> Imagine being rude to the person who has very good general knowledge of Nim who is also very active
20:16:55FromDiscord<Elegantbeef> I'm sorry I'll do better next time
20:17:06Amun-RaElegantbeef: just wondering what that exclusion is about
20:18:28FromDiscord<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:52Amun-Rasure
20:19:49FromDiscord<mekac4321> # Hot Teen & Onlyfans Leaks :underage: :peach: https://discord.gg/sexleaks @everyone
20:19:57FromDiscord<nnsee> <@&371760044473319454>
20:26:23FromDiscord<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:53FromDiscord<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:19FromDiscord<nnsee> i think because using unsigned ints should be a conscious choice because of the bugs they could introduce
20:28:41FromDiscord<nnsee> you're much more likely to underflow (oops, i did 0-1) etc
20:29:07FromDiscord<Robyn [She/Her]> Why don't unsigned ints handle overflow by default, seems trivial?
20:29:17FromDiscord<Robyn [She/Her]> Though, actually
20:29:31FromDiscord<Robyn [She/Her]> Signed integers have special CPU instructions, right?
20:30:44FromDiscord<nnsee> In reply to @chronos.vitaqua "Signed integers have special": well only for comparisons iirc
20:30:45FromDiscord<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:48Amun-Rayes, depends on a cpu
20:33:07FromDiscord<Robyn [She/Her]> In reply to @demotomohiro "https://internet-of-tomohiro.pages.dev/nim/faq.en#l": Ah
20:42:49FromDiscord<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:38Amun-Rathere are usually separate instructions for signed and unsigned operatins that differ in setting flags
20:47:15Amun-Raas 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:59Amun-Ra(prior c23 there was no guarantee signed int representation is two's complement)
21:24:37*def- quit (Quit: -)
21:25:25FromDiscord<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:14FromDiscord<.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:45FromDiscord<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:53FromDiscord<.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:47FromDiscord<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:07FromDiscord<jviega> Believe me, I have my own multiply instruction on the x86 🙂
21:32:26FromDiscord<.bobbbob> I think x86 has instructions for everything imaginable lol
21:34:04FromDiscord<jviega> I'm not even kidding, `PCLMULQDQ` which is a GF(2^128) multiply operation for two 128-bit operands.
21:35:51FromDiscord<jviega> Well, actually, the instruction itself is a primitive for it, it actually works on 2 64-bit operands
21:36:19FromDiscord<jviega> But specifically was to be able to support the GF(2^128) multiplies
21:43:15*def- joined #nim
21:49:43FromDiscord<demotomohiro> !eval echo cast[int](cast[uint](-3) cast[uint](-2))
21:49:45NimBotCompile failed: /usercode/in.nim(1, 31) Error: invalid token: (\29)
21:50:01FromDiscord<Elegantbeef> Get irc bridged
21:51:02FromDiscord<demotomohiro> !eval echo 1 1
21:51:04NimBotCompile failed: /usercode/in.nim(1, 8) Error: invalid token: (\29)
21:51:54FromDiscord<demotomohiro> I forgot that bot doesn't work with '' from discord.
21:54:18FromDiscord<demotomohiro> Anyway, you can use `mul` for unsigned ints for multipying signed ints.
21:56:51FromDiscord<demotomohiro> But x86 has `mul` for unsigned int and `imul` for signed int.
22:05:00FromDiscord<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:53FromDiscord<albassort> is there a way to parse datetimes
22:10:57FromDiscord<albassort> sent a code paste, see https://paste.rs/B0Hf7
22:11:21FromDiscord<albassort> (edit) "is there a way to parse ... datetimes" added "ISO"
22:13:55FromDiscord<albassort> by "way" i mean a cleaner function than this
22:26:55*def- joined #nim
23:35:07FromDiscord<.bobbbob> sent a code paste, see https://play.nim-lang.org/#pasty=qpbBIKREOKVp
23:57:19FromDiscord<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