<< 05-05-2024 >>
00:08:07FromDiscord<aryzen> IT WORKS https://media.discordapp.net/attachments/371759389889003532/1236469440032280587/image.png?ex=66381f66&is=6636cde6&hm=60b36d834739f529425f070e73350b713b045136e25c790a70c2b57d6b901af5&
00:08:34FromDiscord<aryzen> Multiple weeks of being a damn idiot finally paid off!
00:10:22*raynei joined #nim
00:11:07*def- joined #nim
00:14:14*lucasta joined #nim
00:14:19FromDiscord<␀ Array 🇵🇸 🍉> now you are a genius↵(@aryzen)
00:18:32FromDiscord<aryzen> No, I'm still an idiot, so it'll be many weeks more before the next progress XD
00:21:23FromDiscord<odexine> Slightly-less-of-an-idiot?
00:51:26*gst quit (Ping timeout: 250 seconds)
01:00:02*nazgulsenpai quit (Quit: ZNC 1.8.2 - https://znc.in)
01:02:27*nazgulsenpai joined #nim
01:24:18FromDiscord<aryzen> Maybe… I hope so!
02:51:06FromDiscord<xkonti> 🤯 Wow! Choosenim managed to install Nim without makeing Windows Defender freak out! 🤯
02:51:18FromDiscord<xkonti> (edit) "makeing" => "making"
03:05:37*disso-peach joined #nim
03:18:01FromDiscord<sOkam! 🫐> 👀
04:10:08FromDiscord<goerge_lsd> does nim directory not have snapshots of git saved ? this is dead :\ https://nimble.directory/pkg/nimqbittorrent
04:13:14FromDiscord<Elegantbeef> Nope it's just a frontend for the registry
04:15:23*lucasta quit (Remote host closed the connection)
04:15:34FromDiscord<goerge_lsd> It should have code snapshots :\
04:15:49FromDiscord<Elegantbeef> It'd be nice
04:15:58FromDiscord<Elegantbeef> But nimble is decentralised
04:16:38FromDiscord<Elegantbeef> "PRs welcome" 😄
04:20:42FromDiscord<goerge_lsd> was looking to make a program to sync a folder of .torrent files with a qbittorrent client.. and would have been nice not to start from scratch, sigh
04:20:50FromDiscord<goerge_lsd> wonder why the author killed it
04:21:50FromDiscord<Elegantbeef> This is one of the few times those shady git rehosts might be helpful
04:22:17FromDiscord<goerge_lsd> oh ? like what
04:23:40FromDiscord<Elegantbeef> There are some sites that just rehost git repos, they're very sketchy 😄
04:30:42FromDiscord<monofuel> Today I started working on a library to allow for gpu programming in Nim with HIP.↵You can write gpu kernels as part of a Nim program! It still needs a lot more work, but it's a start. focusing on amd for now. hip also supports compiling to nvidia, but I haven't tested the library with that yet.↵↵simple vector sum example: https://github.com/monofuel/hippo/blob/master/tests/hip/vector_sum.nim
04:41:15FromDiscord<Phil> Huh, my math really isn't mathing when it comes to subjects
04:43:36FromDiscord<Phil> The "next" proc on subjects needs to return a future given that it, yknow, triggers observers.next/error procs which all return futures in turn.↵Now if you want to waitFor on that, the place where you waitFor needs to be aware of every single error callback in the observers and dispatch a given exception to the correct one
04:44:33FromDiscord<Phil> (edit) "The "next" proc on subjects needs to return a future given that it, yknow, triggers observers.next/error procs which all return futures in turn.↵Now if you want to waitFor on that, the place where you waitFor needs to be aware of every single error callback in the observers and dispatch a given exception ... to" added "that might occur from calling "next""
04:48:03FromDiscord<Phil> The fact that I can't catch an exception where it originates with async but must catch it where its awaited is really aggravating
04:48:08FromDiscord<Phil> That feels like incorrect behavior
04:48:29FromDiscord<Elegantbeef> Well it's correct cause the program is not ran where the future is created
04:48:50FromDiscord<Phil> Yeah but also means I can't deal with the exception in the actual context where it arises
04:48:57FromDiscord<Phil> Meaning now I'm forced to do hacky solutions
04:49:44FromDiscord<Elegantbeef> @monofuel is `ptr pointer` right there?
04:50:41FromDiscord<Elegantbeef> That clearly should be `hipAlloc(addr: var pointer, size: int)`
04:53:27FromDiscord<Elegantbeef> But yea it should be `var`
04:53:28FromDiscord<Elegantbeef> In hindsight that cast is redundant
04:53:55FromDiscord<monofuel> In reply to @Elegantbeef "<@215660018010161152> is `ptr pointer`": It is ptr pointer. You give it a pointer to a gpu pointer
04:54:01FromDiscord<Phil> It seems I can't interact with that exception at all, which is rough because that means this is a problem for hot observables in general
04:54:38FromDiscord<monofuel> The memory is allocated on the gpu, you pass the func a ptr to where you want it to store the pointer
04:55:32FromDiscord<monofuel> Oh right var pointer. I'm not totally sure on nim -> c interface stuff, but that might be right
04:57:10FromDiscord<monofuel> I was just trying to get things to a working state today, works on my machine (tm)
04:58:23FromDiscord<monofuel> I've been translating working cuda examples i have to nim so far. It does need to be more nim-y
05:09:24FromDiscord<Phil> Wait a second... okay I don't understand
05:11:54FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=tfeDSBWtEmCO
05:14:11FromDiscord<Phil> Wait, maybe my callbacks need to actually be fully async
05:17:09FromDiscord<Phil> Ugh, nevermind, it only works as long as the `next` proc and `error` proc inside observer are actually sync and just wrapped in an async proc
05:20:48FromDiscord<albassort> which is the best vscode extension
05:20:56FromDiscord<albassort> there are 3 currently
05:21:01FromDiscord<albassort> Nim, Nim, Nimlang
05:21:22FromDiscord<albassort> NimLang apepars to be in active development, last commit was a month ago
05:21:27FromDiscord<ringabout> the official one
05:21:30FromDiscord<albassort> the other 2 are 4 and 2 years ago respectively
05:21:54FromDiscord<albassort> In reply to @ringabout "the official one": segfault null reference
05:22:10FromDiscord<albassort> (edit) "null reference" => "(trying to read from null?)"
05:23:13FromDiscord<albassort> https://github.com/nim-lang/vscode-nim
05:26:19*SchweinDeBurg quit (Quit: WeeChat 4.3.0-dev)
05:26:41*SchweinDeBurg joined #nim
06:15:21FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=UYxczEEyiPSQ
06:18:27FromDiscord<Phil> Ah, apparently awaiting sleepAsync is insufficient (?)↵When I return the future from sleepAsync at least it gets to throwing the exception, but that exception vanishes all of a sudden
06:19:06FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=ZxRWwNoJJdWl
06:34:24FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=btJvQkvBoPpQ
06:35:02FromDiscord<sOkam! 🫐> (edit) "https://play.nim-lang.org/#pasty=NKClKegOFALK" => "https://play.nim-lang.org/#pasty=xbgmPKwTdxDO"
06:35:04FromDiscord<Elegantbeef> `type GetSystemFunc = proc (trg :Path; toCPU :ToCPUFunc; toOS :ToOSFunc) :System {.nimcall.}`
06:35:36FromDiscord<Elegantbeef> Wait what?
06:35:54FromDiscord<sOkam! 🫐> that still doesn't match it 🤔
06:36:10FromDiscord<Elegantbeef> What line is errroign?
06:36:16FromDiscord<sOkam! 🫐> same
06:36:25FromDiscord<sOkam! 🫐> sec
06:36:52FromDiscord<sOkam! 🫐> errors on the `else : getSyst( ...)`
06:37:26*disso-peach quit (Quit: Leaving)
06:38:10FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=tNyVLQueLFoL
06:40:44FromDiscord<sOkam! 🫐> oh, the cpu and os order is inverted on the proc's typedef
06:40:49FromDiscord<sOkam! 🫐> that would do it
07:11:04*ntat joined #nim
07:40:31FromDiscord<sOkam! 🫐> why is there no `+` or `union` for `OrderedSet[T] + OrderedSet[T]` in `std/sets`? 🤔
07:40:39FromDiscord<sOkam! 🫐> Is there something about sets that I am missing?
07:44:10FromDiscord<polylokh_39446> probably that there's no good order for the result
07:51:24FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=ljfeLiHmRZme
07:57:40FromDiscord<drunkenalcoholic> sent a code paste, see https://play.nim-lang.org/#pasty=FtiKUnFUZszt
07:58:38FromDiscord<polylokh_39446> EOFError is the expected outcome there, since there's nothing to supply stdin
07:59:44FromDiscord<drunkenalcoholic> Hmm okay thanks for the info, I was doing the Nim basic tutorials and using Nim Playground while on my work computer that doesn't have Nim installed
08:05:19FromDiscord<odexine> wandbox.org has stdin support
09:19:35FromDiscord<pmunch> In reply to @polylokh_39446 "EOFError is the expected": Not really, the program still has a stdin, just nothing is fed through it. The program will simply reach the container run length timeout and terminate the program.
09:26:26*def- quit (Quit: -)
09:29:18*def- joined #nim
09:41:47*krux02 joined #nim
10:27:27FromDiscord<zumi.dxy> "Be the change you want to see in the world" https://media.discordapp.net/attachments/371759389889003532/1236625292999790643/bitmap.png?ex=6638b08d&is=66375f0d&hm=cac0dbdc63e3f2dc4b65b7829079ec52534ba26e1e208e5bc47b0c912467ae74&
10:32:58*coldfeet joined #nim
10:47:36FromDiscord<_nenc> In reply to @zumi.dxy ""Be the change you": wow, Nim also has cute logo now↵but no `{..}`, I think it is the most typical 😐
10:47:38FromDiscord<_nenc> (edit) "😐" => "\:|"
10:48:14FromDiscord<zumi.dxy> Might add that
10:48:31FromDiscord<_nenc> wow, you draw it?
10:48:50FromDiscord<zumi.dxy> Some of the things that came to mind for some reason are \`=destroy\`
10:49:14FromDiscord<_nenc> I thought that this was by like https://github.com/G2-Games/fun-logos
10:49:33FromDiscord<zumi.dxy> I saw that Nim wasn't in any of them so may as well take matters into my own hands lmao
10:50:14FromDiscord<zumi.dxy> I also considered putting a macro reference in there
10:50:25FromDiscord<_nenc> I think `..<` and `proc()` are not typical, if it's `proc()=`(it seems like a Japanese character instead of `=`) it will be representative😂
10:50:43FromDiscord<_nenc> In reply to @zumi.dxy "I saw that Nim": wow, cool!!!!
10:51:09FromDiscord<zumi.dxy> I also considered this unofficial mascot
10:51:09FromDiscord<_nenc> (edit) "I think `..<` and `proc()` are not typical, if it's `proc()=`(it seems like a Japanese character instead of `=`) it will be representative😂 ... " added "(jk"
10:51:09FromDiscord<zumi.dxy> https://user-images.githubusercontent.com/8327205/39615311-627cbc2a-4fb0-11e8-8ecc-9f76430cab97.png
10:51:21FromDiscord<zumi.dxy> but I couldn't make room
10:53:06FromDiscord<zumi.dxy> Here's the SVG if y'all want: https://gist.github.com/ZoomTen/073a2e07eea88b7462135d3679c793b0
10:59:50FromDiscord<zumi.dxy> Maybe a reference to sequences, that seems common https://media.discordapp.net/attachments/371759389889003532/1236633450132406282/image.png?ex=6638b826&is=663766a6&hm=d611cb144a53841855c432995c5d45228271c82f65d5629a1f633816e1f19884&
11:00:40FromDiscord<odexine> The sizing looks off for the @ sign
11:01:01FromDiscord<zumi.dxy> the funny logos are supposed to be quirky that way
11:01:43FromDiscord<odexine> I wonder if you know what style this takes inspiration from or if you just found the style and copied it NGL
11:01:49FromDiscord<odexine> Not saying the latter is bad
11:02:14FromDiscord<zumi.dxy> yeah, I tried copying it badly lmao
11:03:03FromDiscord<odexine> If you want the direct reference most people say this style is directly inspired by how most VTubers’ icon designs
11:03:06FromDiscord<odexine> Are
11:03:11FromDiscord<firasuke> In reply to @zumi.dxy ""Be the change you": This looks really good, ngl
11:11:49FromDiscord<zumi.dxy> https://media.discordapp.net/attachments/371759389889003532/1236636464339615774/bitmap.png?ex=6638baf4&is=66376974&hm=abf78c5c29410aa038b32e20b4556e2ebadd9ef188203c28c48f9464510db47c&
11:22:55FromDiscord<xstormyy> hi
11:25:15FromDiscord<Phil> cheers
11:25:58FromDiscord<Phil> "efficient, elegant, {.gcsafe.}"
11:26:11FromDiscord<Phil> That last one given how much I interact with that pragma
11:30:22FromDiscord<zumi.dxy> `{.importc.}`
11:30:33FromDiscord<zumi.dxy> `{.raises:[].}`
11:30:48FromDiscord<Phil> I fear raises:[] for the code it forces me to write becomes annoying fast
11:31:56FromDiscord<zumi.dxy> 🙂
11:51:04NimEventerNew thread by mantielero: Issue with C array, see https://forum.nim-lang.org/t/11550
11:55:10FromDiscord<odexine> In reply to @isofruit "I fear raises:[] for": Handle all errors or else
12:00:10FromDiscord<Phil> I am actually getting kinda giddy. I managed to build in propper error handling, async, async with propper error handling, unsubscribing and completing, and all of it seems to work as per tests so far
12:01:21FromDiscord<zumi.dxy> In reply to @odexine "Handle all errors or": handling errors is always annoying
12:01:40FromDiscord<zumi.dxy> it's either try/except, if err != nil, match |error|…
12:02:04FromDiscord<zumi.dxy> at least checked exceptions here are optional
12:02:19FromDiscord<zumi.dxy> you could choose to handle everything at the topmost level
12:19:14*ntat quit (Quit: Leaving)
12:42:36FromDiscord<aryzen> you guys all talking crazy advanced thing, me comin in with the: ↵How do I branch based on what platform I'm compiling for? Like, `if macos:`
12:44:26FromDiscord<Phil> In reply to @aryzen "you guys all talking": Its fine, I started there around 2 years ago as well
12:47:17FromDiscord<aryzen> hopefully I could make progress as fast as you
12:47:56FromDiscord<Phil> In reply to @aryzen "you guys all talking": If you want to compile for a specific platform, then you want to add-in/remove specific code at compile-time.↵To do that you need to use `when/else` , as that does what you want.↵You can, in fact, lean on the existing compiler flag `--os` that determines which OS you're compiling for.↵I'm somewhat struggling on finding how to access its value but that should get you somewhere
12:48:28FromDiscord<Phil> Worst case scenario you have a repetitive flag where you use for compilation `--os:macos -d:macos` instead of only `--os:macos`
12:49:47FromDiscord<aryzen> I've seen someone use `when defined(windows)`
12:49:57FromDiscord<aryzen> but can't figure out how to search for that in the manual
12:50:20FromDiscord<Phil> `defined` typically just means there's a `-d` flag
12:50:34FromDiscord<odexine> In reply to @isofruit "`defined` typically just means": Except when it’s the OS flags :baqua:
12:51:10FromDiscord<Phil> Anyway, related to -d flags, you can check out this paragraph:↵https://nim-lang.org/docs/manual.html#implementation-specific-pragmas-compileminustime-define-pragmas
12:51:15FromDiscord<aryzen> cuz I'm doing passL to link some things, and I don't think windows needs cocoa framework
12:51:21FromDiscord<Phil> I'm going to keep looking if you can access the value of --os
12:52:04FromDiscord<aryzen> I will try and look too
12:52:40FromDiscord<Phil> As stated, worst case scenario you have to define that information twice:↵Once with `--os:macos` and on top of that `-d:macos`
12:52:43FromDiscord<Phil> Would just be nicer without
12:52:54FromDiscord<Phil> in the compilation command
12:53:01FromDiscord<odexine> In reply to @isofruit "As stated, worst case": OS defines are automatic IIRC
12:53:39FromDiscord<aryzen> automatic?
12:53:41FromDiscord<Phil> In what sense? As in the flag gets set automatically?
12:54:06FromDiscord<Phil> Because sure, it might, but you can still set it manually as that's what you do for cross-compiling
12:55:38FromDiscord<zumi.dxy> it should be automatic
12:55:53FromDiscord<Phil> Oh hey, they are separate defines
12:55:56FromDiscord<Phil> Which... is an odd choice
12:56:02FromDiscord<Phil> But I'll assume there's good reasons for it
12:56:10FromDiscord<zumi.dxy> then again i still had to replace the compiler and linker myself when using `-d:emscripten`
12:56:49FromDiscord<aryzen> how do I look up the `when` keyword?
12:57:30FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=vPfRFOQucwgv
12:58:56FromDiscord<Phil> sent a long message, see https://pasty.ee/zYPjtVqUWwoP
12:59:55FromDiscord<aryzen> I struggle to use the manual because it's all one page :S↵↵`cmd-f`ing for "when" is obviously... going to give a lot of incorrect results
13:00:08FromDiscord<aryzen> thank you so much for that link
13:02:16FromDiscord<Phil> In reply to @aryzen "I struggle to use": Aye, that is one of the problems with the manual. You can try with cmd + f and scroll through the sidebar to see if anything lights up
13:03:06FromDiscord<Phil> That should give a quicker search. In this case for example, searching for when and then scrolling through the sidebar eventually reveals this: https://media.discordapp.net/attachments/371759389889003532/1236664466960154674/image.png?ex=6638d509&is=66378389&hm=934b5f115c5eb1574a50991ba88c7826cead852db32062d503f21185a0932ace&
13:03:16FromDiscord<Phil> (edit) "when" => ""when""
13:04:08FromDiscord<aryzen> that actually makes sense
13:04:31FromDiscord<aryzen> also the search bar on the left is crazy! check this out https://media.discordapp.net/attachments/371759389889003532/1236664824163860490/image.png?ex=6638d55e&is=663783de&hm=bcbbfa2ee60c0ad17283c6e378a1f120855a86162d6c8c9bfc94becb16347b7d&
13:04:35FromDiscord<aryzen> that's where it took me
13:04:40FromDiscord<aryzen> the middle of... whatever that is
13:06:23FromDiscord<Phil> Highly depends. If you're looking for individual procs/consts/vars it tends to be more useful.↵If you're looking up concepts, yeah the search results or going to be medium since all it has indeced for searching is the head-lines of the sections
13:08:42FromDiscord<aryzen> Hmm
13:22:49*cnx quit (Ping timeout: 255 seconds)
13:28:57*cnx joined #nim
13:35:56FromDiscord<Phil> Huh
13:36:16FromDiscord<Phil> I'm running unintentionally into "I'm in a loop that wants to modify the seq being iterated over" scenarios
13:39:43FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=JfyKXClBcFyD
13:40:04FromDiscord<Phil> (edit) "https://play.nim-lang.org/#pasty=XkRGnfbzsiwD" => "https://play.nim-lang.org/#pasty=vRTBeyCOuqNj"
13:40:47FromDiscord<Phil> Not quite sure how to best iterate over that
13:46:24*ntat joined #nim
13:54:25FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=UcCKyRozllni
14:56:35*def- quit (Quit: -)
14:57:05*def- joined #nim
15:39:44FromDiscord<xkonti> I just learned that when you switch to `devel` version of the language, there are more features. Mainly theres `member` thing that NimForUE uses. Is there a way to discover what's extra is available in `devel` and if threre's some docs for it?
15:41:14Amun-Rafollow git diffs
15:41:41Amun-RaI just don't give any of flying youknowwhats and update to stable
15:49:23FromDiscord<Phil> In reply to @xkonti "I just learned that": If you just generally care for quirky and potentially upcoming features (things in experimental can stay there for a very, very long tie), you can also check out the experimental section of the manual:↵https://nim-lang.org/docs/manual_experimental.html#dynamic-arguments-for-bindsym
15:53:40FromDiscord<Phil> Is there some way to turn the bare-except warning off?
15:53:58FromDiscord<Phil> I can appreciate it, and for my own code I would very likely heed it, but when asyncdispatch uses it I can't do anything about it
15:56:12FromDiscord<Phil> Already tried `--warning:BareExcept:off` to no avail
15:56:59FromDiscord<Phil> And various permutations where I replace `:` with `=`
16:12:51FromDiscord<polylokh_39446> that's how it's turned off, but it's also off by default, so I imagine you're turning it on later than that flag
16:15:01FromDiscord<polylokh_39446> `{.push warning[BareExcept]:off.}`
16:16:10FromDiscord<polylokh_39446> if this is a unittest, unittest.nim turns it on explicitly for the body of tests
16:16:18Amun-RaI like the fact that Uninit warnings popup in stdlib
16:19:17FromDiscord<Phil> In reply to @polylokh_39446 "if this is a": It is for a unit-test
16:19:56FromDiscord<polylokh_39446> then there's nothing you can do apart from pushing the disable in the body of your tests, or by forking unittest.nim
16:20:47FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=uBbJUmvbpCJl
16:21:23FromDiscord<polylokh_39446> that's certainly an error, though. The motivation is not to randomly enforce a particular warning, but to suppress that warning earlier in the code
16:22:23FromDiscord<polylokh_39446> well, later in the code. The very next line is a bare except
16:24:23FromDiscord<sOkam! 🫐> In reply to @zumi.dxy "": dude, this is so epic!! I love it! 😮
16:24:44FromDiscord<sOkam! 🫐> you have a really good sense of graffiti-like style!
16:29:10FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=uMFCRDoCRcbf
16:31:37FromDiscord<polylokh_39446> 'internal error' is a compiler bug yeah. I'd bisect my code to find what's triggering it, rather than dig into that.
16:32:26FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=vVkfOgiJfKuh
16:33:20FromDiscord<sOkam! 🫐> specifically the `TargetTempl` formatting 🤔
16:34:16FromDiscord<polylokh_39446> ;jt
16:34:32FromDiscord<polylokh_39446> put parens around fmt's parameters
16:34:33FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=lpKhxnqddlqs
16:34:39FromDiscord<sOkam! 🫐> let me try that
16:35:16FromDiscord<sOkam! 🫐> In reply to @polylokh_39446 "put parens around fmt's": lol that solved it 🪄
16:35:44FromDiscord<polylokh_39446> ok, I'm blanking on the name, but it's the feature that makes 'echo "blah" work, and that most often hits me in a bad way with `if not x and ...`
16:36:07FromDiscord<polylokh_39446> I'd rather that feature not exist at all in an expression
16:36:29FromDiscord<polylokh_39446> your line was parsed as `fmt(HeaderTempl & "\n" & fmt(TargetTempl))`
16:36:49FromDiscord<polylokh_39446> and probably the nesting was triggered the compiler bug
16:37:40FromDiscord<polylokh_39446> the nesting of `fmt` that is
16:37:43FromDiscord<sOkam! 🫐> In reply to @polylokh_39446 "your line was parsed": oh!! interestings. great to know
16:38:56FromDiscord<polylokh_39446> <https://nim-lang.org/docs/manual.html#procedures-command-invocation-syntax>↵Command Invocation Syntax↵IMO the language would be better if this only applied in a void context
16:39:30NimEventerNew thread by anter003: Get object field by variable, see https://forum.nim-lang.org/t/11551
16:40:18FromDiscord<sOkam! 🫐> unless im misunderstanding what a void context is, I'd big time hate not having command invocation for all cases 😔
16:41:19FromDiscord<sOkam! 🫐> it removes so much vertical mental parsing!↵although I agree that it can be sketchy sometimes and confuse the compiler
16:41:54FromDiscord<polylokh_39446> it means that `let fail = optarg 1, optarg 8` wouldn't try to apply that syntax to the first `optarg` because `optarg` returns something other than void, and not for the other reason
16:42:55FromDiscord<sOkam! 🫐> yeah, solving nested cases can be sketchy for sure. had a few situations of unexpected behavior because of the nesting
16:43:10FromDiscord<sOkam! 🫐> but the compiler usually complains on compilation, for the most part
16:44:13FromDiscord<polylokh_39446> `if not flag and otherflag:` doesn't involve any nesting but it's parsed as `not(flag and otherflag)` instead of `not(flag) and otherflag`, it's a really easy error to hit.
16:49:16FromDiscord<sOkam! 🫐> ic
16:58:20FromDiscord<nocturn9x> I don't think I've ever wished to have used C instead of Nim until today
16:58:37FromDiscord<nocturn9x> the difference between no features vs shitty features is wild.
17:02:37*def- quit (Quit: -)
17:02:45Amun-Rawell… C likes to introduce shitty features no one uses
17:03:03Amun-Rathat's why I moved from C to C++ (as in C with classes) in embedded
17:03:42*def- joined #nim
17:04:17Amun-Raand god… never add features that break existing code! (no default arg values, etc.)
17:06:37*def- quit (Client Quit)
17:06:37FromDiscord<nocturn9x> In reply to @Amun-Ra "well… C likes to": well, Nim likes to introduce cool features with shitty implementations
17:06:44FromDiscord<nocturn9x> and also not document anywhere that they're shit
17:07:01FromDiscord<nocturn9x> only for users to inevitably find out that they're shift, after they've spent hours writing their code around such features
17:07:09FromDiscord<nocturn9x> (edit) "shift," => "shit,"
17:07:29FromDiscord<nocturn9x> I'm sharing a couple `SharedPtr`s across threads and clearly that's too much for atomic arc
17:07:38FromDiscord<nocturn9x> but even the boehm GC which supposedly has a shared heap
17:07:49FromDiscord<nocturn9x> so what the fuck is the point of `SharedPtr`? Fuck if I know
17:10:45FromDiscord<nocturn9x> I'm seriously probably just better off with `--mm:none` since it doesn't fucking work anyway
17:10:53FromDiscord<nocturn9x> and at that poing I might as well just use C, at least that works
17:11:01FromDiscord<nocturn9x> (edit) "poing" => "point"
17:12:06FromDiscord<polylokh_39446> In reply to @nocturn9x ""have you considered going": ^
17:12:27FromDiscord<nocturn9x> yeah at this point I might just rewrite everything in C fr
17:13:54FromDiscord<Phil> I am significantly more chill now since I managed to tame the best in my codebase
17:14:13FromDiscord<polylokh_39446> you can change your approach without changing your language, though. The reason to abandon Nim specifically would be aversion from not knowing until 3000 lines later that a given approach runs you into multiple bugs with some Nim library.
17:14:19FromDiscord<nocturn9x> well yeah I would be too if the language wasn't getting in my way every fucking chance it gets
17:14:32FromDiscord<polylokh_39446> (edit) "some" => "basic" | "library." => "features."
17:15:31FromDiscord<sOkam! 🫐> In reply to @nocturn9x "I'm seriously probably just": --mm:none is wildly broken
17:15:49FromDiscord<nocturn9x> _everything_ is wildly broken in nim if you go more than an inch deep
17:15:58FromDiscord<nocturn9x> almost nothing works like it should
17:16:02FromDiscord<sOkam! 🫐> go with [MinC](https://github.com/heysokam/minc) if you want that mm:none approach, but actually write C
17:16:18FromDiscord<polylokh_39446> the other problem to watch for IMO, with rewrites like this, is that you now have a good approach and a good understanding of the problem, so things go more smoothly - but that's not how future projects will go.
17:16:22FromDiscord<sOkam! 🫐> mm:none is not worth a single minute of your time until its fixed
17:16:37FromDiscord<nocturn9x> none of the memory management strategies are worth any time
17:16:44FromDiscord<nocturn9x> because they're all borked in some way
17:16:59FromDiscord<nocturn9x> maybe araq should get off his high horse and fix his compiler before adding new features, just saying.
17:17:37FromDiscord<guzba8> there is a sweet spot imo, value types + move / ensureMove, ignore ref for anything that isn't 100% tied to a single thread, then manually memory manage globals + a lock or whatever
17:17:38FromDiscord<nocturn9x> my last chance is nimskull, I suppose
17:17:55FromDiscord<nocturn9x> In reply to @guzba8 "there is a sweet": I don't need/want move semantics
17:18:04FromDiscord<nocturn9x> single ownership does not cut it for this use case
17:18:06FromDiscord<guzba8> then dont use them? its just avoiding copies
17:18:23FromDiscord<nocturn9x> okay I'm gonna be extra clear
17:18:31FromDiscord<nocturn9x> mutable references are a hard requirement
17:18:33FromDiscord<sOkam! 🫐> In reply to @nocturn9x "my last chance is": nimskull is pretty much nim, but cleaner. they might have fixed what you mention, and they are definitely focusing more on cleaning the codebase
17:18:35FromDiscord<nocturn9x> not copies, not moved reference
17:18:40FromDiscord<nocturn9x> multiple mutable references
17:18:51FromDiscord<guzba8> mutable references = ptr type, manual memory manage
17:18:55FromDiscord<guzba8> if across threads global
17:19:08FromDiscord<nocturn9x> and why, pray tell, would `SharedPtr` exist then
17:19:12FromDiscord<guzba8> no idea, ignore
17:19:17FromDiscord<guzba8> im mostly in your camp
17:19:27FromDiscord<guzba8> however i have found i can get what i like about nim and avoid landmines
17:19:31FromDiscord<guzba8> just trying to point it out
17:19:43FromDiscord<nocturn9x> I'll try moving to `ptr` I guess, since it makes little difference
17:19:48FromDiscord<nocturn9x> (edit) "I'll try moving to `ptr` I guess, since it makes little difference ... " added "in the actual codebase"
17:20:10FromDiscord<Phil> In reply to @guzba8 "mutable references = ptr": Do you just use ptr or did you write your own custom-type for which you specified the various hook procs?
17:20:18Amun-Ranocturn9x: it they work, they work
17:20:40FromDiscord<nocturn9x> In reply to @Amun-Ra "<@523555920265871380>: it they work,": what
17:20:47FromDiscord<guzba8> i do not use hooks presently, though mostly because these globals either live forever or have a single clear end-of-life so i just do the free there
17:21:09FromDiscord<guzba8> i do a object type as a struct, then ptr to that struct as the global
17:22:02FromDiscord<Phil> Fair. Mostly asking as I have played around with some very cheap and easy version of an actor implementation for multithreading and that was one of the things I considered at the time. Settled with just using ref-types and threading/channels
17:22:27FromDiscord<guzba8> do you require atomicArc or copy the refs across?
17:22:33FromDiscord<guzba8> just curious
17:23:11FromDiscord<Phil> No, which is one of the things making my life very brittle. I can manage to get clean asan/tsan/valgrind/helgrind reports, but only if every single dependency is absolutely the one I specify and half the time I have to disable logging because that has dataraces >_>
17:23:57FromDiscord<Phil> The tests are also by far not yet exhaustive, just first experiments have started working and then work hit me like a freight train and I couldn't focus long hard enough to dive into a topic that complex
17:24:19FromDiscord<Phil> And by working I mostly mean clean reports from sanitiziers and grinds etc.
17:24:31FromDiscord<Phil> (edit) "And by working I mostly mean clean reports from sanitiziers and grinds etc. ... " added "when running really small examples"
17:24:43FromDiscord<Phil> (edit) "sanitiziers" => "sanitizers"
17:25:10FromDiscord<Phil> (edit) "The tests are also by far not yet exhaustive, just first experiments have started working and then work hit me like a freight train and I couldn't focus long ... hard" added "and"
17:25:26FromDiscord<guzba8> yeah it technically can be done as youre finding, but requires super lots of care↵i often put things out as libraries so the bittleness just makes me unfortunately not really consider it↵for my own code tho its totally viable
17:25:46FromDiscord<Phil> I've only been capable of getting back at things for like a week, which I've been using to start implementing reactivex
17:26:05*def- joined #nim
17:26:13FromDiscord<Phil> Which was a trip and a half through like 5 problems that made me consider giving up, but it works by now and should have a basis for everything to start implementing the full spec
17:26:30FromDiscord<Phil> In reply to @guzba8 "yeah it technically can": Yeh, that part I did put out into a library
17:26:37FromDiscord<Phil> Or rather I very intentionally made it a library
17:26:40Amun-Ranocturn9x: I mean new features
17:26:52FromDiscord<nocturn9x> but they clearly _don't work_
17:26:55FromDiscord<Phil> Precisely because I really like the actor model. It's so intuitive as a webdev to me simply because HTTP servers are actors
17:26:57FromDiscord<nocturn9x> atomic ARC is not atomic
17:27:05FromDiscord<nocturn9x> nim's allocator has races
17:27:09FromDiscord<basilajith> Is Dr. Salewski's [book](https://ssalewski.de/nimprogramming.html) not highly recommended?
17:27:11FromDiscord<nocturn9x> threads are broken beyond repair
17:27:15FromDiscord<guzba8> -d:useMalloc is required thats true
17:27:27FromDiscord<Phil> In reply to @basilajith "Is Dr. Salewski's [book](https://ssalewski.de/nimpr": Ehhhhh it's... I think it's mostly alright?
17:27:30FromDiscord<nocturn9x> yes, and that doesn't even begin to address the issue
17:27:47Amun-RaI don't use these
17:27:54FromDiscord<Robyn [She/Her]> If you don't like Nim, why are you trying to force yourself to use it?
17:27:55FromDiscord<nocturn9x> good for you then
17:28:01FromDiscord<Phil> In reply to @chronos.vitaqua "If you don't like": Sunk cost
17:28:04FromDiscord<nocturn9x> In reply to @chronos.vitaqua "If you don't like": well the point is I _do_ like it
17:28:06FromDiscord<Phil> For him I mean
17:28:11Amun-RaI use many modern day features that'll never hit C
17:28:12FromDiscord<nocturn9x> I would like it even more if it weren't broken as shit
17:28:23FromDiscord<nocturn9x> In reply to @isofruit "Sunk cost": also this
17:28:54FromDiscord<Robyn [She/Her]> That's fair enough then, if you really want to force yourself to continue using it, then you could implement fixes or alternatives to existing solutions yourself
17:28:59FromDiscord<Phil> It's really mostly the multithreading stuff that is really, really fubar
17:29:06FromDiscord<nocturn9x> the things I don't like about Nim are mostly related to the people developing it not focusing on the right things
17:29:20FromDiscord<Robyn [She/Her]> Nim isn't a big project backed by someone like Mozilla or Google, it's an opensource project supported entirely by the community
17:29:25FromDiscord<nocturn9x> In reply to @isofruit "It's really *mostly* the": I've used nim for a few years and while I've had a couple facepalms
17:29:33FromDiscord<nocturn9x> they were never at this scale
17:29:38FromDiscord<nocturn9x> In reply to @chronos.vitaqua "Nim isn't a big": nono that's not the point
17:29:50FromDiscord<nocturn9x> the developers are there, they're just adding new shit on top of broken shit
17:29:55FromDiscord<nocturn9x> instead of fixing the stuff that is already there
17:29:57FromDiscord<polylokh_39446> multithreading and anything experimental. Which includes threading -- SharedPtr comes from <https://github.com/nim-lang/threading> because it's totally new stuff
17:29:59FromDiscord<basilajith> In reply to @isofruit "Ehhhhh it's... I think": Somewhere I read that it's not recommended or looked down upon by Araq.
17:30:03FromDiscord<Phil> In reply to @nocturn9x "I've used nim for": Sure, you might run into limitations here or there but none I'd consider "project-ending". Multithreading concentrates a lot of those.
17:30:12FromDiscord<nocturn9x> In reply to @isofruit "Sure, you might run": yes, I agree
17:30:24FromDiscord<Zoom> "the right things" aka "the things I want" \:P↵(@nocturn9x)
17:30:40FromDiscord<nocturn9x> In reply to @Zoom ""the right things" aka": no, the things that make a systems programming language worthy of that name
17:30:46FromDiscord<nocturn9x> like, you know, _parallelism_
17:30:48FromDiscord<Robyn [She/Her]> In reply to @nocturn9x "instead of fixing the": Yeah, I'd say that's because it's an opensource project and people don't exactly want to fix the existing issues, especially if it's not affecting them/they can put up with it
17:30:56FromDiscord<Phil> In reply to @Zoom ""the right things" aka": TBF the fact that the channels didn't pass tsan was a bit of a mind-bender when I stumbled over it
17:31:03FromDiscord<Robyn [She/Her]> (edit) "In reply to @nocturn9x "instead of fixing the": Yeah, I'd say that's because it's an opensource project ... and" added "without financial backing"
17:31:03FromDiscord<Phil> (edit) "In reply to @Zoom ""the right things" aka": TBF the fact that the ... channels" added "threading"
17:31:13FromDiscord<nocturn9x> In reply to @chronos.vitaqua "Yeah, I'd say that's": then why are those features getting merged?
17:31:14FromDiscord<guzba8> In reply to @Zoom ""the right things" aka": i mean, having a broken default allocator for 1.5 years is a bit not ideal
17:31:17FromDiscord<nocturn9x> _someone_ is acceptiung PRs
17:31:21FromDiscord<nocturn9x> (edit) "acceptiung" => "accepting"
17:31:33FromDiscord<nocturn9x> and merging them, increasing the code that is untested
17:31:54FromDiscord<Robyn [She/Her]> There's tests for the code, though?
17:32:12FromDiscord<Zoom> It's a rewrite of a rewrite of a translation of an original code that never had been tested with tsan \:P↵(@Phil)
17:32:13FromDiscord<nocturn9x> yeah, and it clearly shows that they're not enough considering nim literally leaks memory in some contexts
17:32:15FromDiscord<Robyn [She/Her]> Not enough, perhaps, but there are tests
17:32:28FromDiscord<nocturn9x> In reply to @Zoom "It's a rewrite of": is that supposed to be an excuse
17:32:31FromDiscord<polylokh_39446> there's an undocumented right way to use the features, and that way works. The features though are more generally usable, and there's no warning about invalid approaches. This applies across the language.
17:32:39FromDiscord<Phil> In reply to @Zoom "It's a rewrite of": Wait it survived that many iterations? Now that's funny
17:32:39FromDiscord<nocturn9x> In reply to @polylokh_39446 "there's an undocumented right": this ^
17:32:50FromDiscord<nocturn9x> In reply to @nocturn9x "is that supposed to": if anything that's even more concerning
17:33:15FromDiscord<nocturn9x> no one throughout that entire process even _considered_ to use ASAN/TSAN to check for leaks?
17:33:34FromDiscord<nocturn9x> "lol the toy examples work, lgtm, merged"
17:33:45FromDiscord<nocturn9x> that's fine for a hobby project
17:33:51FromDiscord<nocturn9x> not for something you expect people to use in production
17:34:07FromDiscord<guzba8> i think it is slightly more comlex than that, atomics can produce thread safe results but do not tend to work well with sanitizers
17:34:22FromDiscord<nocturn9x> In reply to @guzba8 "i think it is": my discussion is more general
17:34:31FromDiscord<guzba8> true true granted
17:34:34FromDiscord<nocturn9x> nim's threaded model leaks memory, and that's not just TSAN
17:34:42FromDiscord<nocturn9x> it's actual gigabytes of memory being hogged by nim
17:34:50FromDiscord<Zoom> Nope, the excuse is that there's just no threading expert in the team who can properly assess the PRs which is exacerbated by having no hard requirements on the scope of testing going with the PRs↵(@nocturn9x)
17:35:14FromDiscord<nocturn9x> In reply to @Zoom "Nope, the excuse is": which brings me back to my point: why are they getting merged?
17:35:17FromDiscord<Robyn [She/Her]> Honestly I haven't actually touched threading in Nim much, yet, and I've never written code intended for production either so I can't comment on any of this
17:35:22FromDiscord<nocturn9x> araq clearly has enough expertise to know better
17:35:26FromDiscord<Robyn [She/Her]> In reply to @nocturn9x "which brings me back": Why not ask Araq?
17:35:38FromDiscord<nocturn9x> oh I know how he will reply
17:35:43FromDiscord<nocturn9x> god forbid you contradict the guy
17:36:06FromDiscord<nocturn9x> he'll rant using outdated and probably untrue arguments for half an hour using a snarky tone like he's superior to everyone else
17:36:13FromDiscord<nocturn9x> I've dealt enough with him elsewhere
17:36:53FromDiscord<Robyn [She/Her]> Yikes...
17:36:57FromDiscord<nocturn9x> once he argued against Python by bringing an example that hasn't worked in the way he said it was for the past 10 years
17:37:05FromDiscord<nocturn9x> bro lives in another universe
17:37:08FromDiscord<Zoom> Hm, I clearly chose the right time to pop up with my question! \:D
17:37:11FromDiscord<polylokh_39446> the response I'd expect is an approach that would work, but is completely incompatible with the code you've written so far. "You should be doing it like this:"
17:37:27FromDiscord<nocturn9x> In reply to @polylokh_39446 "the response I'd expect": that is araq in a nutshell
17:37:28FromDiscord<Robyn [She/Her]> I never interacted with him much personally, but I'm not exactly fond of him aha
17:37:47FromDiscord<nocturn9x> "your approach is stupid, your code is dumb, here's how to do it [example that barely works and is nothing more than a toy]"
17:37:49FromDiscord<polylokh_39446> I don't think that's a bad response though. At least you have a good approach.
17:37:57FromDiscord<Robyn [She/Her]> I do enjoy Nim but don't have enough expertise or time to fix any of the issues
17:38:13FromDiscord<polylokh_39446> it's insight into the intentions of the code, and the tests that the code passed.
17:38:15FromDiscord<nocturn9x> I would've given contributing to the compiler a shot if it weren't in such a sad state
17:38:21FromDiscord<polylokh_39446> I'd just rather it were in the documentation.
17:38:30FromDiscord<Zoom> Is fondness in any way relevant to any discussions we should have in this chat?↵(@Robyn [She/Her])
17:38:32FromDiscord<nocturn9x> if I have to do all the hard work, I might as well design my own language in the first place
17:39:04FromDiscord<nocturn9x> In reply to @polylokh_39446 "I'd just rather it": yeah, this
17:39:12FromDiscord<nocturn9x> I'm not even bad that there's broken or experimental stuff
17:39:16FromDiscord<nocturn9x> but if there is a working way
17:39:22FromDiscord<nocturn9x> _tell me which one it is, gosh darn it_
17:39:34FromDiscord<nocturn9x> (edit) "bad" => "annoyed by the fact"
17:39:45FromDiscord<nocturn9x> if there isn't, say so and I'll pick a different tool for the job
17:39:47FromDiscord<nocturn9x> simple as that
17:39:57FromDiscord<Robyn [She/Her]> In reply to @Zoom "Is fondness in any": 1 reason isn't, the rest is just he doesn't like making Nim friendlier to beginners or people trying to learn how to do X thing in Nim (X not being that simple)
17:40:16FromDiscord<Robyn [She/Her]> In reply to @nocturn9x "I would've given contributing": That's what Nimskull improves on I believe
17:40:31FromDiscord<guzba8> araq has spent like 15 years being on the receiving end of complaints and demands. even if you are right and he is wrong i can imagine how worn down his enthusiasm for "community management" has become because he is human↵not sure what can be done about this though its just the nature of the beast
17:40:36FromDiscord<Robyn [She/Her]> Well, it definitely has from what I've seen
17:40:46FromDiscord<nocturn9x> In reply to @guzba8 "araq has spent like": I don't disagree with this either
17:40:56FromDiscord<nocturn9x> it is true that there's languages developers complain about and those nobody uses
17:41:09FromDiscord<nocturn9x> but shit, there's gotta be a balancing point in between
17:43:08FromDiscord<nocturn9x> since I still need to share `ptr`s across threads, should I use `allocShared`?
17:45:03FromDiscord<solitudesf> !eval import random;randomize();echo sample ["Yes","No","Maybe"]
17:45:09NimBotCompile failed: No
17:45:20FromDiscord<Zoom> This is relevant to non-arc/orc GC's I believe. ARC/ORC have shared heap.↵(@nocturn9x)
17:45:33FromDiscord<nocturn9x> gotcha
17:45:39FromDiscord<Zoom> That's documented, BTW\: https://nim-lang.github.io/Nim/mm.html
17:46:26FromDiscord<nocturn9x> yeah, you're right
17:46:36FromDiscord<Zoom> Where's beef? I have a macro question.
17:46:40FromDiscord<Zoom> Can I make my template take varargs, extend them and pass to a macro that also takes varargs? I'd like to wrap `terminal.styledWrite` but I don't think I do it correctly.
17:46:43FromDiscord<nocturn9x> well
17:46:53FromDiscord<nocturn9x> one plus side of moving to `ptr` is that the code is faster now
17:47:03FromDiscord<nocturn9x> like, significantly so
17:47:05FromDiscord<nocturn9x> _damn_
18:00:18*gst joined #nim
18:01:52FromDiscord<pmunch> Just pushed a new version of Futhark! It now has "project mode" which allows you to wrap a full project of header files into individual Nim modules with the proper imports to work the same was as the original C library!
18:02:10FromDiscord<pmunch> In reply to @Zoom "Where's beef? I have": Macros you say?
18:03:45FromDiscord<pmunch> Extending varargs like that is probably not possible using just a macro
18:10:11FromDiscord<sOkam! 🫐> In reply to @pmunch "Just pushed a new": is there an example created for this feature? sounds super cool
18:11:03FromDiscord<pmunch> Well, not really.. I've used it at work to wrap FreeRTOS
18:11:09FromDiscord<pmunch> But I can't really share that code
18:11:35FromDiscord<nocturn9x> still getting segfaults after switching to `ptr`
18:11:36FromDiscord<nocturn9x> HOW
18:11:46FromDiscord<nocturn9x> why is nim's memory manager even getting in the way
18:12:02FromDiscord<pmunch> Pointers attract segfaults like lights attract bugs
18:12:30FromDiscord<nocturn9x> the point is I moved to pointers precisely because nim can't seem to manage its own garbage
18:12:48FromDiscord<nocturn9x> the segfault have been present with `ref`s as well as `SharedPtr`s
18:12:51FromDiscord<nocturn9x> (edit) "segfault" => "segfaults"
18:13:01FromDiscord<Phil> (Note, he's multithreading, that's why the ptrs)
18:14:40*lucasta joined #nim
18:16:08FromDiscord<.lisuwu_> In reply to @nocturn9x "yeah at this point": i am honestly like always with this in kernel development, i am trying to incorporate nim in my kernel dev but goddamn it's annoying to be handling stuff like this
18:16:58FromDiscord<.lisuwu_> (edit) "stuff like this" => "nim's broken things"
18:18:21FromDiscord<.lisuwu_> trying to incorporate nim in order to stay awat from writing C only to realize writing it in C is just more worth it
18:19:05FromDiscord<.lisuwu_> (edit) "awat" => "away" | "awayfrom writing C only to realize writing it in C is just more worth it ... " added "than dealing with nim's issues that are fixed in devel but not in release, open issues"
18:23:32FromDiscord<pmunch> In reply to @heysokam "is there an example": Here's an example: https://pasty.ee/kVgTOzXSyhig
18:24:35FromDiscord<sOkam! 🫐> In reply to @pmunch "Here's an example: https://pasty.ee/kVgTOzXSyhig": you just convinced me with this part 👀 https://media.discordapp.net/attachments/371759389889003532/1236745373612249198/image.png?ex=66392062&is=6637cee2&hm=d4d10a8872562bd54bd0e8eb7e725865932840ff93e1f70cb632b9c73287c5d0&
18:24:47FromDiscord<sOkam! 🫐> lol thats so epic! finally! 🥳
18:25:25FromDiscord<pmunch> It is pretty nifty 🙂
18:28:08FromDiscord<pmunch> It matches the file structure as well, and does proper linking between modules
18:28:38FromDiscord<pmunch> It's probably a bit rough around the edges still though, I've only ever used it for FreeRTOS (and now libfuse just as a test)
18:29:11FromDiscord<pmunch> In reply to @nocturn9x "the point is I": Complex project or something I could have a look at?
18:29:35FromDiscord<nocturn9x> complex project
18:29:55FromDiscord<nocturn9x> In reply to @.lisuwu_ "trying to incorporate nim": yes, 10000% this
18:45:04FromDiscord<sOkam! 🫐> In reply to @pmunch "It's probably a bit": will give it a try when I can, can count on that, and will let you know if I find anything weird or glitching
18:45:22FromDiscord<sOkam! 🫐> could simplify my current setup a lot
18:45:47FromDiscord<pmunch> In reply to @heysokam "will give it a": Please do, and if you end up finding a better example than a 1D project I'd be happy to add it to the README 🙂
18:47:35FromDiscord<Phil> There is no RxC, I am disappoint
18:49:08FromDiscord<pmunch> RxC?
18:49:29FromDiscord<Phil> ReactiveX for C
18:49:38FromDiscord<pmunch> Yeah I just realised 😛
18:49:49FromDiscord<Phil> There is RxJS, RxRust (which seems dead, last commit 10 years ago), RxJava and 5 more java versions etc.
18:49:53FromDiscord<Phil> But no RxC!
18:51:39FromDiscord<michaelb.eth> lots of differences between the implementations, though
18:52:11FromDiscord<michaelb.eth> not that that's a bad thing, but just noting it's not like there's an "Rx blueprint" that all of the implementers have followed
18:52:54FromDiscord<Phil> Yeh, it makes me wonder if my own implementation might be worth submitting eventually
18:53:11FromDiscord<Phil> Assuming I expand the test-suite enough to reproduce more behavior reliably
18:53:20FromDiscord<Phil> And implement enough operators/subject-types
18:53:58FromDiscord<michaelb.eth> fwiw, RxJS seems to have the most bells and whistles, and the API and how the plumbing works seems well thought out
18:54:04FromDiscord<michaelb.eth> seems to me, I mean
18:54:22FromDiscord<sOkam! 🫐> In reply to @pmunch "Please do, and if": wgpu or vulkan, probably 🤔
18:54:25FromDiscord<Phil> Yeh, which is why I use its behavior as a blueprint
18:54:31FromDiscord<Phil> Not its implementation because it has luxuries I do not
18:54:43FromDiscord<Phil> Like a flipping eventloop that I am intensely jealous of
18:55:10FromDiscord<sOkam! 🫐> although I believe `raylib` or `sokol` or `fwk` would be much better projects to test the feature
18:55:21FromDiscord<Phil> But I can at least sus out where my implementation behaves slightly differently, see a bit of the finer details in how to connect instances etc.
18:55:42FromDiscord<pmunch> Can't you just make your own event loop?
18:55:51FromDiscord<Phil> In reply to @pmunch "Can't you just make": I can't really assume one
18:56:08FromDiscord<Phil> What I did is make sure that the default version of my procs respond with futures
18:56:13FromDiscord<Phil> Which can be ignored if you have an eventloop
18:56:27FromDiscord<pmunch> Hmm
18:56:29FromDiscord<Phil> And then supply convenience procs that `waitFor` those futures in case you don't have an eventloop
18:56:32FromDiscord<michaelb.eth> I always like to also mention that IxJS is too underapreciated, though the main two guys who worked one Ix put in a lot of work into Rx over the years, and it's easy to see that a lot of the lessons they learned from Rx helped Ix to have a nice shape to it from the get go
18:57:08FromDiscord<pmunch> I'm a bit disappointed with myself. I've created this fun little music-player-as-a-filesystem thing. And to name it something I went with `filesound` as a placeholder.
18:57:24FromDiscord<pmunch> But the name should obviously be `audiofile`! Not sure how I missed that one!
18:57:24FromDiscord<Robyn [She/Her]> In reply to @heysokam "although I believe `raylib`": Tbf Naylib does a much better job of this imo anyway because it uses the JSON that Raylib provides for binding creation
18:57:34FromDiscord<michaelb.eth> lots of power in Ix, and pull-based reactive flows should probably be used much more often than they get used in practice, i.e. too many people reach for Rx first because they don't know to consider whether Ix is the better fit
18:57:45FromDiscord<Robyn [She/Her]> But maybe for testing it'd be useful
18:58:32FromDiscord<Phil> In reply to @michaelb.eth "lots of power in": I might be missing the imagination, but at least for frontend I find it hard to find an argument for pull over push
18:58:34FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=PNUAyQNFevSX
18:58:48FromDiscord<Elegantbeef> `parseEnum`
18:58:53FromDiscord<Phil> Just "Update state and your rendered stuff is automatically consistent with what is in state" is really nice
18:58:54FromDiscord<sOkam! 🫐> ty beef ✍️
18:59:15FromDiscord<Phil> And the "Update of state automatically updates rendered Interface" I can't see without rx
18:59:48FromDiscord<Elegantbeef> Zoom no your template's varargs are turned into an `nnkBracketExpr` your macro takes a `typed` or `untyped` then expands them
19:00:37FromDiscord<Zoom> Huh, just a macro. What else is there? Extending the compiler?↵(@pmunch)
19:00:43FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=sfBWmVJbhcQl
19:01:21FromDiscord<michaelb.eth> In reply to @isofruit "I might be missing": pull-based flows let "your code" drive the reaction rate rather than the event source driving the reaction rate, which in a lot of cases is what you want; but instead people stick debounces and little timers here and there until it works well enough, but that's inherently fragile↵↵in any case, UIs and networking calls can benefit from both push and pull, and Ix and Rx can work well to
19:01:24FromDiscord<Elegantbeef> `parseEnum[Os](...)`
19:01:24FromDiscord<Elegantbeef> It's a generic
19:01:28FromDiscord<Elegantbeef> IT does not just iterate all generics
19:01:33FromDiscord<sOkam! 🫐> ohhh, tru
19:01:35FromDiscord<_nenc> In reply to @isofruit "Just "Update state and": what about S.~~js~~nim (((
19:01:44FromDiscord<pmunch> In reply to @Zoom "Huh, *just* a macro.": Shit, I meant just a template
19:02:06FromDiscord<Phil> What about what now?
19:02:11FromDiscord<pmunch> But you'd be surprised with the shenanigans you can get up to with some compiler flags and strange paths
19:03:28FromDiscord<Phil> In reply to @michaelb.eth "pull-based flows let "your": I'd need to see an example architecture, for now I can't really imagine it. My first reaction would even be to not be a huge fan of having both at the same time since now you have 2 ways of doing the same thing.
19:04:32FromDiscord<michaelb.eth> that's the thing, they're not reducible to one another, that's the mental model part that people often miss, because they haven't spent much time with pull-based flows, so they assume/conclude (wrongly) that it's "2 ways of doing the same thing"
19:04:42FromDiscord<michaelb.eth> pull is pull, push is push
19:04:59FromDiscord<_nenc> In reply to @Zoom "Can I make my": what about https://nim-lang.org/docs/macros.html#unpackVarargs.m%2Cuntyped%2Cvarargs%5Buntyped%5D
19:05:29FromDiscord<Phil> ~~I'm already more knowledgeable than most of my team I'm pretty sure and that goes above even my head~~
19:05:54FromDiscord<michaelb.eth> pull is single-consumer, consumer decides to pull the next event/data, and they're can be queueing of of the source data between times consumer isn't ready to pull next
19:05:56FromDiscord<_nenc> (edit) "https://nim-lang.org/docs/macros.html#unpackVarargs.m%2Cuntyped%2Cvarargs%5Buntyped%5D" => "https://nim-lang.org/docs/macros.html#unpackVarargs.m%2Cuntyped%2Cvarargs%5Buntyped%5D↵wait, is it suitable? it also takes a vararg"
19:06:31FromDiscord<michaelb.eth> push is single or multi consumer, producer (source) determines to send next data and the consumer reacts to that
19:06:41FromDiscord<_nenc> (edit) "vararg" => "vararg↵oh, according to the document it seems to be suitable here"
19:07:38*def- quit (Quit: -)
19:09:25*def- joined #nim
19:14:00FromDiscord<Phil> I would likely still need to see an example of a usecase to start connecting the dots. Like sure, I get the description, but I can't produce a mental image of where I'd use it
19:46:05FromDiscord<Zoom> sent a code paste, see https://play.nim-lang.org/#pasty=gjAxyirvxknF
19:46:34FromDiscord<Zoom> sent a code paste, see https://play.nim-lang.org/#pasty=vDPwieTCbhSn
19:46:54FromDiscord<Zoom> sent a code paste, see https://play.nim-lang.org/#pasty=LpteEghLDdnK
19:47:50*coldfeet quit (Remote host closed the connection)
19:49:45FromDiscord<Zoom> In other words, when I try to use my macro, which takes `varargs` and constructs a new `nnkBracket` node with some items prepended, inside a call for another macro, the latter just sees an array, not `varargs`.
19:52:15FromDiscord<michaelb.eth> In reply to @isofruit "I would likely still": working on something for you that might help to expriment with push vs. pull
19:54:05FromDiscord<pmunch> In reply to @Zoom "So, what can I": Something like this: https://play.nim-lang.org/#pasty=yVQBQpBqAJJG
19:54:41FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=dpBggYDaVKVa
20:17:35FromDiscord<Zoom> If it really happens at callsite, why isn't foo("abc", "def") and foo(["abc", "def"]) equivalent? I mean, if it really happens at callsite how can any callee distinguish varargs from an array?
20:17:48FromDiscord<Elegantbeef> varargs accepts arrays
20:18:21*ntat quit (Quit: Leaving)
20:23:03FromDiscord<Zoom> It means that the quote from the docs is wrong. No transformation happens at callsite, as it would just mean that the callee would see `[[stuff]]`
20:23:49FromDiscord<Elegantbeef> In what case is that wrong?
20:24:46FromDiscord<Elegantbeef> > A varargs parameter is an open array parameter that additionally allows a variable number of arguments to be passed to a procedure. The compiler converts the list of arguments to an array implicitly\:↵Checks out
20:25:33FromDiscord<Elegantbeef> > Note that an explicit array constructor passed to a varargs parameter is not wrapped in another implicit array construction
20:25:35FromDiscord<Elegantbeef> Also checks out
20:27:00FromDiscord<Zoom> sent a code paste, see https://play.nim-lang.org/#pasty=lWMlrOjYcSgs
20:27:10FromDiscord<Zoom> sent a code paste, see https://play.nim-lang.org/#pasty=yeqIJDQDqPpj
20:27:52FromDiscord<Elegantbeef> It's a template
20:28:44FromDiscord<Elegantbeef> Oh wait wrong thing
20:28:53FromDiscord<Elegantbeef> > varargs[typed] is treated specially\: It matches a variable list of arguments of arbitrary type but always constructs an implicit array. This is required so that the builtin echo proc does what is expected\:
20:29:18FromDiscord<Elegantbeef> When `varargs[T]` matches an array it converts the array to a string
20:29:44FromDiscord<Elegantbeef> well `varargs[string, `$`]`
20:29:53FromDiscord<Elegantbeef> Cause it does not match string so it gets stringified
20:30:09FromDiscord<Elegantbeef> This allows `test([1, 2, 3], 4, 5, 6)`
20:31:56FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=QXoVafxNCjGf
20:32:08FromDiscord<Zoom> This is not the culprit
20:33:05FromDiscord<Elegantbeef> Zoom if that message is to me it is the culprit
20:33:17FromDiscord<Elegantbeef> `[1, 2, 3]` is not `string` so it turns into `$`([1, 2, 3])\`
20:33:25FromDiscord<Zoom> sent a code paste, see https://play.nim-lang.org/#pasty=irzPnHLOKibc
20:33:43FromDiscord<Zoom> sent a code paste, see https://play.nim-lang.org/#pasty=KBctUaCljSMF
20:33:48FromDiscord<polylokh_39446> expandArc also shows callsite transformation
20:34:19FromDiscord<Elegantbeef> Except Zoom you're wrong
20:34:24FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=hTSSLrLyFVbV
20:34:35FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=CFVFxbqRuXuU
20:34:57FromDiscord<Elegantbeef> It's turned into a single expression that is almost like an array
20:35:07FromDiscord<Zoom> Yeah, I'm right, there's no array, but the docs say there would be.
20:35:09FromDiscord<Elegantbeef> It's not an array cause it's untyped
20:35:19FromDiscord<Elegantbeef> An array of what?
20:35:25FromDiscord<Elegantbeef> You explicitly said untyped 😄
20:35:58FromDiscord<Zoom> Yeah, that's probably it, the hole in my understanding.
20:36:00FromDiscord<Elegantbeef> If you switch that to `int` it resolves into an array
20:36:52FromDiscord<Elegantbeef> `typed` and `untyped` are special
20:37:02FromDiscord<Elegantbeef> Since they accept any types
20:37:50FromDiscord<Elegantbeef> Arguably it should be a `nnkBracket` but there might be an internal reason it's' not
20:37:58FromDiscord<Elegantbeef> typed does emit a bracket
20:38:55FromDiscord<Elegantbeef> The reason it's not a bracket might be a bug in how parameters are lifted or it might be intentional
20:49:28FromDiscord<Zoom> I still don't understand how can I just rewrite the arglist at callsite. I can construct a call from inside a macro, but a simple rewrite would suffice.
20:50:02*Jjp137 quit (Quit: Leaving)
20:50:38FromDiscord<michaelb.eth> sent a long message, see https://pasty.ee/JfCUHosVJXYW
20:51:00FromDiscord<michaelb.eth> (edit) "https://pasty.ee/LNNTFztUGCvZ" => "https://pasty.ee/evSGjkEhVaHZ"
20:51:34*Jjp137 joined #nim
20:53:01FromDiscord<goerge_lsd> @ElegantBeef can you name some of those shady github caches or whatever ? Haven't been able to locate any. And I'd rather not redo all the boring work of writing API wrappers
21:01:13FromDiscord<Phil> In reply to @michaelb.eth "<@180601887916163073> see https://gist.github.com/m": interestingly enough - impossible to connect to that url
21:01:22FromDiscord<Phil> Ah, now it worked
21:01:24FromDiscord<Phil> wonky internet
21:05:18FromDiscord<Phil> In reply to @michaelb.eth "<@180601887916163073> see https://gist.github.com/m": I mean sure, but that still focuses on the technical aspects of it.↵What tangible scenario exists, particularly in frontend since that's where I see the main draw for RxJS and friends, where that is relevant to me?↵That's where I'm struggling
21:09:14FromDiscord<Phil> sent a long message, see https://pasty.ee/ZEkKfVhUALDz
21:10:20FromDiscord<Phil> In contrast essentially the entire way my product folks are thinking is along the lines "If this event happens with these requirements I want this to appear on screen", which is very much event-driven thinking
21:14:41FromDiscord<Elegantbeef> @goerge_lsd I could not find any
21:15:57FromDiscord<goerge_lsd> Well nvm, found some older API wrapping code I did that I can use as template. I wish somebody would make the ultimate http api wrapper in nim template.
21:16:52FromDiscord<goerge_lsd> I've seen several approachhes, would be nice to have a more or less standardized way for this very common library type
21:17:01FromDiscord<goerge_lsd> (edit) "approachhes," => "approaches,"
21:19:48FromDiscord<goerge_lsd> I am trying to write a program that keeps a folder of .torrent files in sync with qbittorrent. Add a torrent file to it, it gets added in the client, remove a file, it gets removed from client/disk. So you can manipulate a larger dataset-like collection of torrents just by moving files around. I am surprised this doesn't exit already. Or I haven't been able to find it.
21:20:38FromDiscord<Elegantbeef> Inotify is your friend
21:21:06FromDiscord<goerge_lsd> yeah but that won't work for the win plebes
21:21:38FromDiscord<Elegantbeef> Time to wrap the windows, bsd, and mac APIs 😛
21:21:49FromDiscord<goerge_lsd> `toSeq(walkDir(path, relative=true)).mapIt(it.path)`
21:21:52FromDiscord<goerge_lsd> or just use this lol
21:22:38FromDiscord<Elegantbeef> Thanks I hate it
21:23:29FromDiscord<goerge_lsd> I'd rather get the program working first rather than going in a rabbit hole that's way over my head, and the responsability of nim core devs.. it's basic functionality after all, having a filesystem monitor proc
21:23:43FromDiscord<goerge_lsd> (edit) "rather" => ""
21:24:28FromDiscord<Elegantbeef> We have inotify, whatelse do we need
21:25:37FromDiscord<goerge_lsd> Even if my use case is just linux, i'd rather use a dumb proc + sleep and have it working on any platform.
22:07:28*lucasta quit (Quit: Leaving)
22:10:30*krux02_ joined #nim
22:13:39*krux02 quit (Ping timeout: 272 seconds)
22:25:45FromDiscord<Zoom> sent a code paste, see https://play.nim-lang.org/#pasty=VBXzcvdOTrye
22:31:50FromDiscord<xkonti> sent a code paste, see https://play.nim-lang.org/#pasty=zzElswUIVRTs
22:32:38FromDiscord<Elegantbeef> If you did `OsFs.new` could just pass `OsFs` 😄
22:35:23FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=ZzeusvPBaSTk
22:39:02FromDiscord<xkonti> Then whoever uses the library will need to import "new" from OsFs to instantiate it. If they import OsFs only, Nim will call the system `new`. One more friction point for the lib user. OsFs tyle isn't even exported to the user 😄
22:42:04FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=FFUvVrbGpryQ
22:42:51FromDiscord<sOkam! 🫐> and if I get that to be `list.toSeq` then I trigger the error from before
22:43:23FromDiscord<xkonti> Additionally some implementations will require additional configuration (connection strings, limits, credentials, etc)
22:44:31FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=OBxdsMrVQzjz
22:44:43FromDiscord<polylokh_39446> (edit) "https://play.nim-lang.org/#pasty=sxtVEYLFtbdP" => "https://play.nim-lang.org/#pasty=DIpHaJPToPyL"
22:44:51FromDiscord<sOkam! 🫐> oh
22:45:34FromDiscord<sOkam! 🫐> that was it, ty @polylokh_39446 ✍️
22:59:52FromDiscord<goerge_lsd> https://github.com/qbittorrent/qBittorrent/wiki/WebUI-API-(qBittorrent-4.1)#add-new-torrent - do you think it's possible to generate this kind of multipart data with nim's httpclient ? `Content-Disposition: form-data; name="torrents"; filename="8f18036b7a205c9347cb84a253975e12f7adddf2.torrent"` with 2 properties on the same line ?
23:14:02FromDiscord<goerge_lsd> ah nvm, this is exactly what addFiles is for https://nim-lang.org/docs/httpclient.html#addFiles%2CMultipartData%2CopenArray%5Btuple%5Bstring%2Cstring%5D%5D
23:24:18*def- quit (Quit: -)
23:24:30*def- joined #nim
23:56:07FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=MChceCdAzMhK