<< 03-10-2025 >>

00:35:03FromDiscord<janakali> grabnim fixes many of choosenim issues: https://forum.nim-lang.org/t/13132
00:54:11FromDiscord<nasuray> Won't fix folks trying to use their native package managers though lol
00:57:19FromDiscord<nasuray> In reply to @janakali "grabnim fixes many of": Unrelated but wanted to say thanks for pointing me to Mitchell's macos-sdk repo. It solved my withstanding issues cross-compiling to mac using forge (my zig cc wrapper)
02:21:19FromDiscord<nevillegg> In reply to @nasuray "Won't fix folks trying": Nix?
02:21:25FromDiscord<nevillegg> I do. Xbps
02:21:37FromDiscord<nevillegg> Nix-channel --update aint workin
02:28:06FromDiscord<nasuray> In reply to @nevillegg "Nix?": I was being sassy about people wanting to install via native package managers but they are sometimes neglected and the better supported options are choosenim or grabnim (FWIW I also use a package manager (nix) rather than choosenim, but I accept that means I need to make sure it works)
02:32:50FromDiscord<nevillegg> In reply to @nasuray "I was being sassy": Oh
02:37:17FromDiscord<Trayambak> I can confirm. A build can take upwards of 40-50s for no reason. Iirc, a strace shows that it's reading every file for every installed package, and when this is "cached", the cache gets easily invalidated by just moving into a Nix shell, moving out of one or just after a day from personal experience.↵(@Robyn [She/Her])
02:38:32FromDiscord<Elegantbeef> @TrayambakIt's even better than that, just updating a package in my game project takes like 40s to download the dependencies
02:39:59*LuckyMan joined #nim
03:28:19*SchweinDeBurg quit (Quit: WeeChat 4.8.0-dev)
03:29:09FromDiscord<Trayambak> The more I deal with Nimble, the more my urges to write a package manager from scratch grow, only to be subsided by XKCD 927
03:40:25*rockcavera quit (Remote host closed the connection)
03:49:59FromDiscord<nasuray> I guess I've largely been spared by using nimble as a package manager and not a package builder (i.e. at most I use nimble setup -l and nimble lock -l)
03:50:38FromDiscord<Elegantbeef> Well update dependency then fetch it and it'll take for ever
03:55:11*SchweinDeBurg joined #nim
03:55:47FromDiscord<nasuray> I think my expectations are much lower lol
04:00:50FromDiscord<Elegantbeef> Not taking 40s to tick one dependency is not much to ask \:D
04:01:16FromDiscord<nasuray> In reply to @Trayambak "I can confirm. A": It's not really designed with nix in mind and particularly if you are changing versions the cache will be invalidated, but otherwise I think they should be largely compatible.... The nim cache is treated differently as there is an additional name mangling but that's unrelated to nimble redownloading or checking dependencies
04:02:10FromDiscord<nasuray> In reply to @Elegantbeef "Not taking 40s to": Fair... hopefully the final pre-1.0.0 efforts pan out to improved performance.
04:37:58*LuckyMan quit (Quit: LuckyMan)
05:16:53*derpydoo joined #nim
06:16:13*derpydoo quit (Quit: derpydoo)
06:27:30FromDiscord<Robyn [She/Her]> In reply to @Trayambak "The more I deal": Just write it for a hardfork of the language with better priorities :D
06:54:04*derpydoo joined #nim
08:15:50*derpydoo quit (Ping timeout: 244 seconds)
09:03:32tokyovigilanteafter extensively wrangling atlas, I can confirm it is 1000x better than nimble ;)
09:03:51tokyovigilantebut am also using and attempting to maintain a distro nim package
09:16:34FromDiscord<xtrayambak> In reply to @battery.acid.bubblegum "Just write it for": As much as I don't like interacting with the Nim core team, I believe balkanizing Nim is the worst way to get around doing things.
09:18:16FromDiscord<xtrayambak> In reply to @nasuray "It's not really designed": it starts doing whatever in the world this is, and that happens even if you enter and exit the exact same Nix shell with no modifications https://media.discordapp.net/attachments/371759389889003532/1423600026013270098/image.png?ex=68e0e657&is=68df94d7&hm=58f98ab7fd3fb30070b1c6764e450be8a101def892405ad6d9360d847e853c65&
09:19:34FromDiscord<xtrayambak> It has genuinely started to become unusable, and I am currently in the process of migrating to my own package manager that's somewhat backwards compatible with Nimble (as in, it can read and work with the Nimble package index)
09:25:06FromDiscord<xtrayambak> oh, and as a bonus: it doesn't pollute your home dir, it stores its stuff in `~/.local/share/neo` :^)
09:27:53*derpydoo joined #nim
09:33:37*hygo quit (Ping timeout: 264 seconds)
10:02:57FromDiscord<Robyn [She/Her]> In reply to @xtrayambak "As much as I": Balkanizing?
10:03:17FromDiscord<Robyn [She/Her]> Also Skull exists because Nim is too resistant to changes
10:03:27FromDiscord<Robyn [She/Her]> and Skull intends to be something different at some point
10:04:15FromDiscord<mitranim> Curious what kinda changes they wanted to make?
10:07:48Amun-RaRobyn: I guess he means splitting into several competing solutions
10:14:04FromDiscord<kiloneie> @Robyn [She/Her] First time seeing an animated avatar, and i am already expecting, that this will become annoying with many different user's avatars all neon lighting. Did this feature bring an off switch too ?
10:14:16FromDiscord<kiloneie> (ups #offtopic )
10:28:55FromDiscord<leorize> a lot of refactoring and semantics fixes, which needless to say are all breaking changes to the language↵(@mitranim)
10:29:52FromDiscord<leorize> if you're interested in seeing the day-to-day development, consider joining our discord\: https://discord.gg/sNBG9E2zbB
10:54:50FromDiscord<aethrvmn> In reply to @Trayambak "The more I deal": If @janakali has heard xkcd, we wouldnt have grabnim, which works better than choosenim imo
10:55:18FromDiscord<aethrvmn> (edit) "has" => "had"
10:55:24FromDiscord<mitranim> The fork is ironic given that Nimony is a full rewrite and redesign with (currently) many breaking changes
11:01:36*derpydoo quit (Quit: derpydoo)
11:06:15FromDiscord<drunkenalcoholic> Noob question incoming, I am trying to trigger 2 different events on XK_g(103) and XK_G(72) but Nim gives me an error saying duplicate lables Nim seems to think XK_g and XK_G are the same, anyone have a suggestion or idea why this might be?
11:06:42FromDiscord<drunkenalcoholic> (edit) "XK_G(72)" => "XK_G(71)"
11:07:26FromDiscord<drunkenalcoholic> (edit) "Noob question incoming, I am trying to trigger 2 different ... events<--" added "keyboard" | "keyboardevents on XK_g(103) ... and<---" added "<-- lowercase "g"" | "events on XK_g(103)<-- lowercase "g"and XK_G(71) ... but" added "<--- uppercase "G", "
11:08:15FromDiscord<mitranim> Current Nim is mostly case-insensitive (except for first letter in identifiers), and also underscore-insensitive
11:11:14FromDiscord<drunkenalcoholic> and that might just a create a huge problem, KeySym XK_g and XK_G for example and every other key of the alphabet is going to be treated as duplicates if this is the case
11:12:05FromDiscord<mitranim> Yep, one of the reasons I'd like this feature gone
11:14:50FromDiscord<drunkenalcoholic> thanks for the info, I didn't think of that
11:24:02FromDiscord<leorize> we predate nimony and don't consider working with Araq an option, so it would have happened sooner or later. But talks of skull should be in offtopic↵(@mitranim)
11:33:05FromDiscord<drunkenalcoholic> I found the solution, went looking in the in the X11/keysym.nim, it seems capital "G" is defines as XKc_G, but yeah thats feels like a trap for noobs like me who was expecting XK_g and XK_G forgetting about Nim case insensitive
11:34:57FromDiscord<systemblue_whale> hey↵what error method should I use.↵Exception?↵Result[T, E]
11:35:01FromDiscord<systemblue_whale> Option[T]?
11:35:18FromDiscord<systemblue_whale> or returning error code like systemcall and C?
11:36:21FromDiscord<leorize> nim native error handling is exceptions
11:36:37FromDiscord<leorize> so it depends on whether you want a close-to-origin wrapper or a high-level nim wrapper
11:47:26FromDiscord<lainlaylie> In reply to @aethrvmn "If <@154179249614356480> had heard": I've seen libraries written to use a non-nimble package manager that are for that reason not installable through nimble. on the other hand, all functioning nim installers (choosenim, grabnim, manual installation, etc) result in the same thing, a functioning nim installation, and there are no implications on compatibility
11:55:23FromDiscord<lainlaylie> In reply to @xtrayambak "oh, and as a": `-l` exists and is already default on latest nimble
12:19:55FromDiscord<nasuray> Also NIMBLE_DIR is configurable
12:28:36FromDiscord<janakali> In reply to @aethrvmn "If <@154179249614356480> had heard": I've seen that xkcd. And I almost tried to fix choosenim, but it was literally easier to write new program from scratch.
12:44:59FromDiscord<nevillegg> In reply to @xtrayambak "it starts doing whatever": nice terminal
13:16:14*Mister_Magister quit (Excess Flood)
13:17:33*Mister_Magister joined #nim
13:18:18*zgasma quit (Ping timeout: 264 seconds)
13:18:37*Lord_Nightmare quit (Ping timeout: 264 seconds)
13:18:38*ftajhii quit (Ping timeout: 264 seconds)
13:18:49*Lord_Nightmare2 joined #nim
13:19:24*zgasma joined #nim
13:20:58*Lord_Nightmare2 is now known as Lord_Nightmare
13:21:01*xtr00 quit (Ping timeout: 264 seconds)
13:22:18*xtr00 joined #nim
13:30:01*Lord_Nightmare quit (Ping timeout: 264 seconds)
13:30:19*Lord_Nightmare joined #nim
13:38:28FromDiscord<tauruuuuuus> In reply to @janakali "I've seen that xkcd.": My old boss never believed me when he used to come with shitty projects to maintain and I told him that
13:39:21FromDiscord<xtrayambak> In reply to @aethrvmn "If <@154179249614356480> had heard": as laylie said, those aren't really related problems because you use a version manager to manage a particular toolchain, while package managers carry their own exclusive metadata in a package's repository, effectively "locking them" into that package manager
13:48:58FromDiscord<aethrvmn> In reply to @xtrayambak "as laylie said, those": Well yeah but at the same time in python you have poetry and uv as the new competing standards for package management, but they use the same configuration in pyproject.toml, because thats a language spec not a manager spec, so you can use the same toml with uv amd poetry, they just generate different lockfiles
14:12:48FromDiscord<nnsee> sent a long message, see https://pasty.ee/QXejtgPx
14:20:23FromDiscord<lainlaylie> is it possible for package managers to be compatible with each other? yes. have i found that to be the case with nim's various alternative package managers? not always.
14:28:49FromDiscord<nnsee> fair enough
14:29:48FromDiscord<TensionMan> what is there to learn in nim?
14:30:12FromDiscord<TensionMan> Can I get done with just the learning part, the conceptual, the language part in a lunch?
14:33:19FromDiscord<TensionMan> I found a mdbook or gitbook.. idk it's on my laptop's browser, idk nimibook or something. ↵it's either incomplete or it's just so small to learn nim
14:33:29FromDiscord<TensionMan> cause it's short book
14:34:26FromDiscord<nnsee> depends on how fast of a learner you are and whether you're already familiar with languages with similar syntax. the core syntax of the language is very easy to just pick up and start writing code pretty much immediately by simply following https://nimbyexample.com/, nim's primitives are easy to grasp the curve to getting started is not steep at all. however it's possible to go more in-depth by learning how macros work and trying to figure
14:35:31FromDiscord<TensionMan> I have nimlings locally... i don't understand how to do it.
14:35:49FromDiscord<TensionMan> I also read learn nim in Y minutes
14:36:10FromDiscord<TensionMan> it's not up-to-date imo but it's very short read
14:37:17FromDiscord<nnsee> In reply to @TensionMan "I have nimlings locally...": what exactly are you having issues with? i haven't done nimlings myself, but from the readme, a simple `nimble run` is all you need to get started
14:38:02FromDiscord<nnsee> looking at the code, nimlings seems very basic (or simply incomplete?)
14:38:08FromDiscord<TensionMan> I was learning C some time ago in college and it's just a week back I found out that I was learning C89 and 99 all the way and some things were very hard for me and I didn't even discovered xmacro and some more opinionated, expert level shit.
14:38:17FromDiscord<TensionMan> and that's just C99
14:38:32FromDiscord<TensionMan> C11, and 17 and 23 have a lot of differences
14:38:43FromDiscord<TensionMan> I was like what!!!!!
14:40:58FromDiscord<TensionMan> I thought it's a set of problems that you have to solve and meanwhile solving you'll learn nim ie you have to learn a concept to solve particular problems.↵problem based learning. good approach. I tried it about a year ago↵(@nnsee)
14:41:15FromDiscord<TensionMan> I would be very stupid back then
14:48:54FromDiscord<Laylie> that's probably enough to start writing at least simple programs. then for the more advanced features you can pick them up as the need arises. but i've never found trying to rush learning something to be a particularly rewarding or effective approach.
15:37:29FromDiscord<aethrvmn> In reply to @TensionMan "I thought it's a": You can try rewriting some of your C programs in nim to get a feel because you already know what it's supposed to do and how it should work
16:27:45*beholders_eye joined #nim
17:01:04FromDiscord<mitranim> So I had that simple benchmark where Nim's chunk-based allocation makes the Nim program finish in 2/3rd the time of the equivalent C program. To find out if this was really about allocation, I couldn't resist writing a C version with manual chunk allocation via `calloc`, which runs in 1/4rd the time of the Nim version. So far so good. My question is: why doesn't C ship with a better allocator, if Nim can do this so easily?
17:17:16Amun-Rathat's implementation defined
17:40:27FromDiscord<mitranim> Whatever that means, this doesn't explain why e.g. the libc on my system doesn't have a better default allocator after 40 years of tuning
17:45:56FromDiscord<nervecenter> Most likely to do with the extreme conservatism of standards and security organizations. They'd probably want years of testing for all architectures for any allocator they swap malloc for.
17:46:20FromDiscord<nervecenter> That's my guess, anyways.
17:51:09*redj quit (Ping timeout: 252 seconds)
17:54:56Amun-Rathat means the internals of malloc are up to a specific library implementation and not a C standard
18:17:56*redj joined #nim
18:21:47*Guest77 joined #nim
18:22:18*Guest77 quit (Client Quit)
18:51:37*beholders_eye quit (Ping timeout: 264 seconds)
19:52:16*beholders_eye joined #nim
20:03:37*beholders_eye quit (Ping timeout: 264 seconds)
20:37:21FromDiscord<kiloneie> https://forum.nim-lang.org/t/13440 this 2 bots talking ?
20:48:50FromDiscord<Elegantbeef> Peak internet
20:52:55FromDiscord<Robyn [She/Her]> AI slopfest go brrrr
21:29:02*beholders_eye joined #nim
21:48:11*beholders_eye quit (Ping timeout: 250 seconds)
22:12:58*beholders_eye joined #nim
22:56:25*beholders_eye quit (Ping timeout: 264 seconds)