<< 12-02-2025 >>
00:45:06FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=DxgEipzK
00:46:22FromDiscord<Elegantbeef> Stop using a template
00:46:24FromDiscord<Elegantbeef> use a procedure
00:47:34FromDiscord<Elegantbeef> I also don't see a proc that takes in `data: seq[byte]`
00:48:00FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=uTFnsMVq
00:49:06FromDiscord<Elegantbeef> Cool that doesn't show a proc with the last parameter as `seq[byte]`
00:49:46FromDiscord<Elegantbeef> If you look at your mismatch message you'll see there is a mismatch `new` at parameter `1`
00:49:56FromDiscord<Elegantbeef> So I have no idea what you're trying to do
00:50:00FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=aTMbqwBn
00:50:24FromDiscord<Elegantbeef> It's not in the mismatch list and it's not exported so I figure you didn't export
00:51:02FromDiscord<System64 ~ Flandre Scarlet> OH BRUH...↵I'm sorry...
00:51:11FromDiscord<Elegantbeef> Inexcusable
00:52:43FromDiscord<System64 ~ Flandre Scarlet> Nimsuggest is currently dead for me so it shows nothing :/
00:53:09FromDiscord<Elegantbeef> Well the compiler says enough
00:53:27FromDiscord<Elegantbeef> Learn to rely on compilers over tooling! 😄
00:53:45FromDiscord<Elegantbeef> I'm only partly joking
00:57:06FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=RQijcQXz
00:58:39FromDiscord<Elegantbeef> No context
00:59:20FromDiscord<System64 ~ Flandre Scarlet> Oh wait I have an idea
01:01:02FromDiscord<System64 ~ Flandre Scarlet> Ok turned it into a generic proc, it works↵Why tf did I made a template while generics exists...
01:01:26FromDiscord<Elegantbeef> I told you make it a proc
01:01:50FromDiscord<System64 ~ Flandre Scarlet> Me being dumb sometimes
01:02:14FromDiscord<Elegantbeef> Only reach for a template as a last bastion of sanity
01:03:09FromDiscord<System64 ~ Flandre Scarlet> I used templates to simplify some Dear ImGUI stuff
01:19:00FromDiscord<fl4shk> `template`s come in handy with my transpiler to PipelineC. Makes it so I can do operator overloading from the Nim side of things.
01:19:13FromDiscord<fl4shk> also my transpiler is getting close to feature complete.
01:19:26FromDiscord<Elegantbeef> Don't know how templates are any better than procs
01:53:06FromDiscord<fl4shk> In reply to @Elegantbeef "Don't know how templates": it's only relevant to the fact that the `proc` operator overloads don't show up to macros
01:55:21FromDiscord<fl4shk> as procs, that is
02:00:05*beholders_eye quit (Ping timeout: 260 seconds)
02:00:24FromDiscord<threefour> Even if they're `{.compileTime.}`?
02:02:39FromDiscord<Elegantbeef> What does that even mean?
02:04:35FromDiscord<Elegantbeef> https://play.nim-lang.org/#pasty=DguAIiBl
02:13:06*xet7 quit (Ping timeout: 246 seconds)
02:21:20*xet7 joined #nim
02:34:04*xet7 quit (Remote host closed the connection)
02:34:18FromDiscord<lainlaylie> :)
03:16:50*rockcavera quit (Ping timeout: 244 seconds)
05:07:41*xutaxkamay quit (Ping timeout: 268 seconds)
05:12:00*ntat joined #nim
05:13:16*xutaxkamay joined #nim
06:05:36*SchweinDeBurg quit (Quit: WeeChat 4.6.0-dev)
06:06:05*SchweinDeBurg joined #nim
08:08:51*ntat quit (Quit: Leaving)
08:12:04*redj quit (Ping timeout: 260 seconds)
08:12:53*redj joined #nim
10:11:49*ntat joined #nim
12:29:19FromDiscord<nocturn9x> Hello
12:29:31FromDiscord<nocturn9x> I'm getting Nim to generate invalid C code plus a bunch of warnings on the following snippet
12:30:06FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=AVrJhSdy
12:30:15FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=xMdBsSdl
12:31:08FromDiscord<nocturn9x> these are the clang errors: <https://paste.nocturn9x.space/6KZGMWDSxPUhtvcrISNDT>
12:31:21FromDiscord<nocturn9x> it seems like it's trying to get the address of the var parameter and failing?
12:31:38FromDiscord<nocturn9x> I would just expect it to tell me I can't do that
12:31:58FromDiscord<nocturn9x> (removing the `var` modifier when passing it to the thread fixes it)
12:50:58*ntat quit (Quit: Leaving)
13:33:28*ntat joined #nim
14:49:05FromDiscord<jabuci> sent a code paste, see https://play.nim-lang.org/#pasty=BYidxFLD
14:49:27FromDiscord<jabuci> (edit) "https://play.nim-lang.org/#pasty=gzwTUwYQ" => "https://play.nim-lang.org/#pasty=UxYaKsfw"
14:50:35FromDiscord<jabuci> It seems that `git` fails since it's called with too many arguments (?)
14:50:58FromDiscord<lainlaylie> https://discord.com/channels/371759389889003530/371759389889003532/1128744020609339502
14:51:02FromDiscord<lainlaylie> seems similar to this
14:55:37*xet7 joined #nim
14:56:37FromDiscord<jabuci> In reply to @lainlaylie "seems similar to this": Thanks! Yep, my username has a space in it 😦
14:59:04FromDiscord<jabuci> What could I do?
14:59:30FromDiscord<lainlaylie> erm...
15:02:56FromDiscord<lainlaylie> file an issue in nimble (if it one doesnt already exist for this bug), ponder philosophically about why its so popular around here to build commandlines by naive string concatenation, and try setting `--nimbleDir` to a path that doesnt contain spaces
15:03:13FromDiscord<lainlaylie> #tooling might also want to hear about it
15:44:55FromDiscord<jabuci> Under Windows I get this error: `Error: cannot open file: pkg/htmlparser`, though `htmlparser` was installed with nimble. In the source code I have `import pkg/htmlparser` .
15:49:52*kasimir_ quit (Remote host closed the connection)
15:50:24*kasimir_ joined #nim
15:54:25FromDiscord<nnsee> why pkg?
15:57:27FromDiscord<jabuci> I get a warning otherwise: `Warning: use `nimble install htmlparser` and import `pkg/htmlparser` instead; htmlparser is deprecated [Deprecated]`
15:57:33FromDiscord<lainlaylie> pkg is good, it shouldn't be the problem here
15:57:52FromDiscord<lainlaylie> check that you've required it in your nimble file
15:57:52FromDiscord<jabuci> Maybe the space in my user name?
15:58:37FromDiscord<jabuci> sent a code paste, see https://play.nim-lang.org/#pasty=rqaCldvG
15:58:49FromDiscord<nnsee> In reply to @lainlaylie "pkg is good, it": right, wasn't aware
15:59:39FromDiscord<lainlaylie> is that an ide error? langserver/nimsuggest tends to need a restart to pick up new paths
15:59:55FromDiscord<lainlaylie> ive also heard `nimble setup` can help
16:01:11FromDiscord<jabuci> Thanks! `nimble setup` did the trick.
16:50:07sh4hi. is the C code generated by nim portable, or tied to the specific architecture nim was used on?
17:06:26FromDiscord<janakali> sent a code paste, see https://play.nim-lang.org/#pasty=yhfoSrjW
17:08:10sh4reason i'm asking is cause i rather ship C code in a release tarball then nim, so the consumer has one less burden
17:09:03sh4and generating 50 different versions of the C code for every arch and OS in existence is impractical.
17:10:07sh4it's probably more in the order of 200...
17:17:11FromDiscord<dedraiaken> In reply to @sh4 "reason i'm asking is": There’s an interesting project called cosmopolitan for creating highly portable executables. Here’s the support vector: https://media.discordapp.net/attachments/371759389889003532/1339284174305230878/image0.jpg?ex=67ae2915&is=67acd795&hm=ac8e695bd7d9d2f3f274e60d12f5772641c114aa6203bf7658be93a5e3f8e642&
17:17:33FromDiscord<dedraiaken> https://github.com/jart/cosmopolitan
17:17:38sh4*vomit*
17:18:01sh4did you ever look the code? it's ugly af, and 64bit only
17:18:36sh4also i dont want to ship binaries, but code
17:20:07FromDiscord<solitudesf> then ship nim code and assume consumer can overcome this burden, like he does with every other non c language
17:21:40sh4and that's why i don't use those. the barrier to entry is too high, especially with stuff like java or rust that's almost impossible to bootstrap from source
17:22:17sh4was specifically looking at nim because it generates C instead of linking against the bloatfest LLVM
17:23:06sh4and i don't see good technical reasons for why the emitted code can't be portable and have a few #ifdefs in it
17:25:13FromDiscord<solitudesf> yeah, thats cool. looks like nim doesn't fit your bill too.
17:26:55FromDiscord<fabric.input_output> C is Nim's equivalent of LLVM IR. Nim's purpose is not to be a C generator. you can probably make it work that way tho
17:27:14FromDiscord<dedraiaken> In reply to @sh4 "and i don't see": I’d say you can probably get there, but it may take some experimentation to get everything setup properly. I’m not an expert there, but I haven’t found great documentation in that domain of the compiler, though I think it’s possible with the right switches and compilation environment.
17:27:22sh4as a distro maintainer, the plethora of different languages in use is really annoying. gotta have a C,C++,go,rust,haskell,java,python,ruby,perl compiler installed to use most useful programs
17:28:30FromDiscord<fabric.input_output> I remember only the texlive installed needed perl and almost nothing needed ruby for me
17:28:32FromDiscord<fabric.input_output> ¯\_(ツ)_/¯
17:28:40FromDiscord<fabric.input_output> (edit) "installed" => "installer"
17:30:10sh4perl is already needed if you want to run autoreconf -i to generate a configure script. also for intltool, used by many packages. others use it to generate some headers for the compilation process. others use python for that, etc
17:32:19sh4if there's only a single package in your stack of software that uses ruby to generate a header during compilation, you now have to compile and install that too
17:32:46sh4unless you rewrite that script and maintain it for every package version bump
17:45:34FromDiscord<dedraiaken> I guess you’d want fat C files that had all the appropriate include macros. I’m not sure Nim is intended to compile to C that way.
17:48:45sh4well, optimally there was a .c file for each .nim file so compilation can be parallelized. and have them include a compat header that uses e.g. limits.h to define the sizes of nim types e.g. depending on whether LONG_MAX is 0x7fffffffffffffffLL etc
17:55:02FromDiscord<dedraiaken> In reply to @sh4 "well, optimally there was": https://github.com/nim-lang/Nim/blob/1a7bc6d878ff04709ebb1002010fd53b4ba02179/doc/nimc.md?plain=1#L690
17:56:11sh4oh, so there's hope
17:56:36sh4cause nim looks like a language i'd actually enjoy to use
18:00:37sh4for stuff outside the stdlib/io domain like pthreads vs windows threads, a C wrapper shim could be used with a few ifdefs in it. wouldn't want to strip the language of threads.
18:03:01sh4although supporting windows would be wayyyy down my priority list. a os=posix would be best and quite simple, allowing the code to run on all bsds, mac, linux, rtos, basically everything other than windows, DOS, or AmigaOS :)
18:04:39Amun-RaI already compiled for AmigaOS (m68k) :)
18:05:31sh4cool. i guess AROS is posix compatible enough to be included in posix-compatible set
18:05:46Amun-Ramhm
18:06:08Amun-Racompiling for AmigaOS 3.x requires a few things
18:06:57sh4on the C side i suppose ?
18:07:19Amun-Rathis is a part of my nim.cfg for the platform: https://dpaste.com/D77KM5WW6
18:07:21sh4at least you already have a gcc port for that arch
18:08:06Amun-Raalthough I haven't tested it for a while
18:08:14Amun-Rain*
18:08:21sh4amigaos 3 even has mmap ? sweet
18:08:59sh4that was one of the major pain point when i (once) tried to make one of my programs compile on mingw
18:09:47sh4somehow that project attracted lots of windows users that complained about having to install cygwin to compile, until i gave in...
18:10:12Amun-Rathat build uses malloc, just the definition was missing irc
18:10:53sh4yeah, but mmap is really great to load (actually map) files from disk
18:11:39sh4the app i refer to uses a lot of file seeks on a pretty big binary format and got like a 20x speedup using mmap ofter standard file i/o code
18:12:04sh4*over
18:14:33FromDiscord<jabuci> I made a little project: https://github.com/jabbalaci/WebpageTitle . Under Windows, I cannot copy Unicode characters correctly to the clipboard. If someone knows how to do it, some help would appreciated.
18:15:40Amun-RaI think you must be using utf-8 and I think windows would prefer utf-16 instead
18:16:07Amun-Ra(just thinking outloud, I'm not a windows user)
18:33:02FromDiscord<jabuci> Thanks. I'll try with the winim package (https://nimble.directory/pkg/winim).
18:41:55FromDiscord<dedraiaken> In reply to @sh4 "oh, so there's hope": the `--nimcache` switch will let you change the C file output location
18:49:59*ftajhii joined #nim
18:56:45FromDiscord<fl4shk> does something akin to `match` exist in Nim?
18:57:12FromDiscord<Elegantbeef> There are macros for pattern matching but nim only has `case`
18:58:56FromDiscord<albassort> does nim's sqlite have a way to dump a :memory: database
18:59:34Amun-Rathere's .dump command
18:59:46FromDiscord<albassort> p sure that doesn't work over db.exec
19:05:00Amun-Rahmm, I'd check the result of exec and/or get_all_rows
19:24:11FromDiscord<.bobbbob> In reply to @janakali "it's not portable, but": doesn't pure nim code (ie code that doesnt import any c libraries) only rely on a dynamically linked c standard library? so you could probably release one binary for linux, one for windows, maybe one for freebsd, bundle any C dlls you need and that'd probably be good. idk about macOS. and you'd probably only support x86_64 and aarch64 so that's like 6 binary releases which is about par fo
19:25:29FromDiscord<summarity> What's a good way to get a stable unique ID for object instances, similar to Python's `id()`?
19:25:49Amun-Rait relies on a few more things: thread library, non-stdlib stuff as dynlib, etc.
19:26:51FromDiscord<Elegantbeef> reference and `cast[uint](myRef)`↵(@summarity)
19:27:01FromDiscord<Elegantbeef> Stable for this runtime atleast 😄
19:29:18FromDiscord<Elegantbeef> Oh actually that's exactly what `id()` does in python
19:29:26FromDiscord<Elegantbeef> > The id is assigned to the object when it is created. The id is the object's memory address
19:30:49FromDiscord<summarity> neat, my obj is already a ref obj, so this works well
19:31:19Amun-Raexcept for a few cases (small ints, etc.)
19:35:16FromDiscord<Elegantbeef> Another thing you could do without relying on a cast/ref is just use monotimes at the object creation
19:36:19FromDiscord<Elegantbeef> Since it's a precise timer the next call is always certain to be incremented by some amount and as such it works as a UID in the same way the memory address does
20:05:01*beholders_eye joined #nim
20:20:16FromDiscord<summarity> Why can't I use the `kind` value from one object in the constructor of another, when I can do the same in two separate steps: https://play.nim-lang.org/#pasty=CnyviEhZ ?
20:27:45FromDiscord<dedraiaken> In reply to @summarity "Why can't I use": I wonder if it’s because it’s not tracking the enum value of o.kind at compile time.
20:29:16FromDiscord<summarity> Which is fair, but since this is a runtime property, it's odd that it's a compile-time _error_. I feel like this should work, because this workaround forces an unnecessary `var` on something I want to be immutable.
20:30:16FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=hLKxQBlW
20:30:35FromDiscord<summarity> lol ok, but this still feels like a bug
20:31:34FromDiscord<Elegantbeef> It's not nim's tracking is subpar
20:31:52FromDiscord<Elegantbeef> It doesn't know `o.kind` is a constant
20:32:45FromDiscord<summarity> Is the `let` forcing this check to run at compile time? This seems really odd. All other variant object field access errors are runtime errors - I don't it's even possible to prove this at compile time, and yet it tries (and fails).
20:33:27FromDiscord<Elegantbeef> No
20:33:38FromDiscord<Elegantbeef> It's attempting to prevent non static field assignments inside an object variant
20:35:08FromDiscord<summarity> What does that mean?
20:35:44FromDiscord<solitudesf> you are assigning to bar in object constructor, meaning branch has to be known statically, but your discrimimant depends on runtime value.
20:36:08FromDiscord<summarity> But that's what's inconsistent
20:36:32FromDiscord<Elegantbeef> It means it prevents construction with any discriminate which is unknown at compile time
20:36:33FromDiscord<Elegantbeef> How is that inconsistent?
20:36:42FromDiscord<summarity> At runtime, I can willy-nilly access fields that don't exist for the discrimimant, and I get a runtime error. Why would this suddenly be a compile time error for _assignment_
20:37:29FromDiscord<summarity> Wait, I think I see what you mean
20:37:38FromDiscord<Elegantbeef> It's easier to statically block creation that block all field access without an `if x.kind == y`
20:37:39FromDiscord<Elegantbeef> than block\
20:38:38FromDiscord<Elegantbeef> In the above case there is no benefit in the `kind: o.kind` as there is only a single branch of that type
20:38:52FromDiscord<summarity> Yes, it's a reduced test case
20:39:32FromDiscord<dedraiaken> In reply to @summarity "At runtime, I can": I think it actually should prevent that at compile time based on the kind
20:40:07FromDiscord<Elegantbeef> That's not exactly possible given Nim's current lack of distinct typing
20:40:16FromDiscord<Elegantbeef> Each branch is the same type so you cannot actually track anything statically
20:40:48FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=HnbpTDxl
20:40:52FromDiscord<summarity> In reply to @dedraiaken "I think it actually": It's a runtime error: https://play.nim-lang.org/#pasty=KFQhXWgv
20:41:28FromDiscord<dedraiaken> In reply to @summarity "It's a runtime error:": Hmm, yep
20:42:03FromDiscord<summarity> That was the source if my confusion. I never did try to assign kinds from other instances, so in my mental model, all field errors were runtime errors
20:43:19FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=HDHoMGvL
20:44:03FromDiscord<Elegantbeef> \PS\: in case statements you do not need `[kb, kc]` , `kb, kc` works just fine
20:44:58FromDiscord<summarity> Yeah, I use it mostly for formatting - personal taste 🙂
20:45:07FromDiscord<dedraiaken> sent a code paste, see https://play.nim-lang.org/#pasty=ozahFEWv
20:45:37FromDiscord<Elegantbeef> Don't see how they're confusing
20:45:40FromDiscord<Elegantbeef> They're tagged unions
20:46:16FromDiscord<Elegantbeef> If the compiler hates you, use the cast and cry
20:48:27FromDiscord<dedraiaken> I think my expectation would be that turbo's example would work also, but it's nice there's workaround though it kind of defeats the ergonomics of the feature.
20:48:56FromDiscord<Elegantbeef> It's a fence sitting time cause it's safer to force only static values
20:49:00FromDiscord<Elegantbeef> But it's also less usable cause of that
20:49:45FromDiscord<Elegantbeef> In 10 years when the new tagged union API releases this will be a thing of the past cause branches will be statically typed
20:51:40FromDiscord<Elegantbeef> Of course once could always use fungus
20:52:09FromDiscord<Elegantbeef> one\
20:58:24*PMunch_ joined #nim
21:01:10*PMunch quit (Ping timeout: 244 seconds)
21:03:17*beholders_eye quit (Ping timeout: 248 seconds)
21:08:31FromDiscord<dedraiaken> In reply to @Elegantbeef "*Of course once could": Fungus is just the physical manifestation of a recursive macro
21:09:01*beholders_eye joined #nim
21:09:03FromDiscord<Elegantbeef> uh huh
21:10:58FromDiscord<Elegantbeef> Cannot tell if you're familiar with my macro or not with that comment
21:31:47*hippodriver joined #nim
21:37:17FromDiscord<dedraiaken> In reply to @Elegantbeef "Cannot tell if you're": lol I’m not.
21:42:10FromDiscord<dedraiaken> In reply to @Elegantbeef "Cannot tell if you're": That’s cool! I created a similar one that was Elm/Haskell style and let you do a kind of algebraic data type thing. Never published it though.
21:49:50FromDiscord<fl4shk> In reply to @Elegantbeef "There are macros for": can you point me to those pattern matching macros, Elegantbeef?
21:54:04FromDiscord<solitudesf> In reply to @fl4shk "can you point me": https://github.com/haxscramper/hmatching
21:54:15FromDiscord<fl4shk> In reply to @solitudesf "https://github.com/haxscramper/hmatching": thanks
21:55:33FromDiscord<solitudesf> In reply to @fl4shk "thanks": here is probably more up to date version https://github.com/nim-lang/fusion/blob/master/src/fusion/matching.nim
21:57:47FromDiscord<fl4shk> In reply to @solitudesf "here is probably more": thanks
23:10:56*ntat quit (Quit: Leaving)
23:19:59*rockcavera joined #nim
23:28:56*hippo joined #nim
23:31:39*hippodriver quit (Read error: Connection reset by peer)
23:45:35FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://paste.rs/UdyXy
23:49:35FromDiscord<Elegantbeef> @System64 ~ Flandre Scarlet the dumper should never crash
23:50:42FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "<@380360389377916939> the dumper should": Even if I have a VSBF in a VSBF?
23:52:49FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://paste.rs/zgoY0
23:53:00FromDiscord<System64 ~ Flandre Scarlet> (edit) "https://paste.rs/zzN9U" => "https://paste.rs/aPyuA"
23:55:37FromDiscord<Elegantbeef> Yes cause a vsbf inside of a vsbf should be skipped as an array in the dumper↵(@System64 ~ Flandre Scarlet)
23:56:40FromDiscord<Elegantbeef> Infact the vsbf inside of the vsbf will be a typed integer
23:56:57FromDiscord<Elegantbeef> So like the header would be `int8 v int8 s int8 b int8 f`