<< 10-01-2025 >>
00:00:38*beholders_eye quit (Quit: WeeChat 4.1.2)
00:09:11FromDiscord<marximillian> Is there any way to export a default from an import, such that the symbol it's imported as refers to that as opposed to a module "namespace" (for lack of better term)?
00:11:10FromDiscord<marximillian> sent a code paste, see https://play.nim-lang.org/#pasty=kvpCfLri
00:12:01FromDiscord<marximillian> Note inconsistency, `var foo: Student` -- Student refers to the type Student defined in models/Student, while `foo = Student.Student.new()` is required to avoid the conflict ambiguity
00:27:22FromDiscord<dreamtheater92> Anyone know of an up to date AWS SDK for Nim? This one seems rather unmaintained https://github.com/disruptek/atoz
00:31:04FromDiscord<dreamtheater92> In reply to @marximillian "Note inconsistency, `var foo:": Can you import `models/Student` as some alias?
00:31:59FromDiscord<marximillian> I _can_, then Student (unqualified) falls back to the type, but stylistically and as a requirement for users to use these things I'm trying to avoid it
01:31:06FromDiscord<marximillian> This apparently seems possible: `import models/Student as _`
01:39:58FromDiscord<System64 ~ Flandre Scarlet> @treeform ↵Hi! Does https://github.com/treeform/slappy support audio buffer manipulation and callback like SDL2?
01:45:55FromDiscord<treeform> I don't think so. Audio manipulation was not some thing I was making it for.
01:46:24FromDiscord<treeform> You can create a buffer and send it and update it. But its not very real-time so you will get clipping and other artifacts.
01:46:42FromDiscord<treeform> I don't know what SDL2 supports, so can't say for sure.
01:47:10FromDiscord<treeform> I just wanted to load OGG and WAV and play them in 3d.
01:56:56FromDiscord<System64 ~ Flandre Scarlet> In reply to @treeform "I just wanted to": Oh alright, thanks anyways!
03:22:59*rockcavera quit (Remote host closed the connection)
03:46:09FromDiscord<lainlaylie> In reply to @whorf "I'm still struggling with": Here's one solution that comes to mind, though I rarely work with inheritance in Nim so: https://wandbox.org/permlink/Du9cc3vOJXfLYdvf
03:56:49*SchweinDeBurg quit (Quit: WeeChat 4.6.0-dev)
04:09:23*SchweinDeBurg joined #nim
04:37:32*xet7 quit (Remote host closed the connection)
04:40:45FromDiscord<dedraiaken> sent a code paste, see https://play.nim-lang.org/#pasty=iAVHJVlU
04:44:55FromDiscord<blackmius> it should be a 127 element array filled zeros with values at given indexes?
04:46:07FromDiscord<blackmius> if something else i suggest to use Table[int, int] for it
04:47:12FromDiscord<blackmius> (edit) "if something else i suggest to use Table[int, int] for it ... " added "or OrderedTable"
04:47:26FromDiscord<dedraiaken> In reply to @blackmius "it should be a": Yeah, well, 128 element array. 0 is intentionally skipped for an error value since the others will be mapped to zero.
04:55:48FromDiscord<michael.lenz.> In reply to @mikenew "I *think* I have": Musl’s allocator unmaps right after free() was called. Yeah, in this case it should be fine. Are you using refc collector?
04:59:48*krux02 quit (Remote host closed the connection)
05:00:25FromDiscord<blackmius> meh, seems you need make it manually
05:02:24FromDiscord<blackmius> const a = block:↵ var arr: array[128, uint8]↵ # code↵ arr
05:08:32FromDiscord<michael.lenz.> In reply to @mikenew "Would you be interested": Sure, only we had a talk wigh Araq, and he confirmed that nim’s default alocator not reaclaims back freed heap to os with current design. Probably we need to create feature request
05:11:28FromDiscord<dedraiaken> In reply to @blackmius "const a = block:": NIce! That works. I could've sworn I saw the other type of syntax somewhere, but I guess not.
07:40:52*redj quit (Quit: No Ping reply in 180 seconds.)
07:42:24*redj joined #nim
07:46:49FromDiscord<janakali> sent a code paste, see https://play.nim-lang.org/#pasty=PTPqslPR
07:47:37FromDiscord<janakali> (edit) "https://play.nim-lang.org/#pasty=eUdoCIZu" => "https://play.nim-lang.org/#pasty=BSVfGdDi"
07:48:16FromDiscord<lainlaylie> In reply to @dedraiaken "NIce! That works. I": The syntax you have there is correct but i think Nim requires the indexes to be contiguous↵See https://nim-lang.org/docs/manual.html#types-array-and-sequence-types
08:49:09*ntat joined #nim
09:01:10FromDiscord<demotomohiro> sent a code paste, see https://play.nim-lang.org/#pasty=CIdVhIAd
10:42:07FromDiscord<odexine> You can get the tuple arity using the typetraits module
10:42:44FromDiscord<odexine> And actually can't you get the length of a varargs anyway
10:42:57FromDiscord<odexine> Oh, ct
10:43:09FromDiscord<odexine> Also forgot its sparse xd
10:43:49FromDiscord<odexine> The {:} syntax would still be neater IMO
10:43:53FromDiscord<xtrayambak> Is there a reason why `if x is SomeType` always results in the branch being executed? I can't do `when x is SomeType` because of another error
10:45:27Amun-Rawhat type is x?
10:45:57Amun-Rawhen only applies to compile-time, the type must be known during the compilation
10:46:00FromDiscord<xtrayambak> `x` is just a field I'm getting from a generic type's `fieldPairs` iterator
10:46:13FromDiscord<xtrayambak> It _should_ be compile-time-able but it isn't for some reason
10:46:21Amun-Rathat's why when won't work
10:46:37FromDiscord<xtrayambak> I'`args` https://media.discordapp.net/attachments/371759389889003532/1327227088599650345/tnfdi7P.png?ex=67824c0c&is=6780fa8c&hm=b5dbf88d6ff84b0e568a8911a92811465669ce9e10f592e7f771745bd2aea4ac&
10:46:46FromDiscord<xtrayambak> (edit) "I'`args`" => "I'm iterating over `args`' fields"
10:48:03Amun-Raare you calling build in compile-time context?
10:48:05FromDiscord<xtrayambak> In reply to @Amun-Ra "that's why when won't": Ah, is there another way, then?
10:48:09FromDiscord<xtrayambak> In reply to @Amun-Ra "are you calling build": No
10:48:16Amun-Raso → no "when"
10:48:19FromDiscord<xtrayambak> I think I found the solution
10:48:40FromDiscord<xtrayambak> neeeeevermind
10:52:54FromDiscord<xtrayambak> I found the culprit, it was my check for checking if `x` is an `Option`
10:53:23FromDiscord<xtrayambak> I would check that and if it was true, I'd set `x` to `T` instead of `Option[T]` 😬
11:04:33*beholders_eye joined #nim
12:14:14FromDiscord<System64 ~ Flandre Scarlet> First position : C with GCC↵Second position : Nim https://media.discordapp.net/attachments/371759389889003532/1327249136612806779/image.png?ex=67826095&is=67810f15&hm=f242c39e6e696db14a572df99fd1a2fb12c7fe07505267822b68d7699310ee4b&
12:14:20FromDiscord<System64 ~ Flandre Scarlet> 💪
12:14:54Amun-Rathese comparisons make almost no sense at all
12:16:59FromDiscord<fabric.input_output> fr
12:17:04FromDiscord<odexine> In reply to @sys64 "First position : C": I mean to be fair the first few positions are within a few seconds
12:17:20FromDiscord<odexine> Also insert beef benchmarks rant
12:18:50Amun-Raone of the problems with those benchmarks is they almost never benchmark practical code in use
12:19:41FromDiscord<nnsee> what do you mean? i calculate pi through the leibniz formula 100000000 times in all of my projects!
12:19:47Amun-Ra:D
12:20:46Amun-Rawell, if we calculate that in nim's static context, nim should be in #1 place with 0.000s \o/
12:33:30FromDiscord<System64 ~ Flandre Scarlet> Is it possible to statically link SDL2 on Nim?
13:23:24PMunchShould be
13:34:15Amun-Rathat should be pretty hard…ish
13:36:22PMunchDoesn't look _that_ complicated: https://stackoverflow.com/questions/17620884/static-linking-of-sdl2-libraries
13:38:44Amun-Rait may be easier on windows
13:39:38PMunchIn my experience nothing is easier on Windows
13:39:42PMunchApart from getting viruses
13:40:16Amun-Ra:P
13:40:20Amun-Ratrue
13:46:35FromDiscord<Phil> Out of curiosity, what benefit does NIR/Nims own intermediary formats bring over just LLVM IR?
13:46:57FromDiscord<Phil> Is it just about being able to use gcc?
13:47:06FromDiscord<Phil> (edit) "gcc?" => "non-llvm compilers?"
13:47:28PMunchI think it will also carry a lot more information about macros etc.
13:47:52PMunchAnd better information about types
13:51:33FromDiscord<demotomohiro> In reply to @isofruit "Out of curiosity, what": https://github.com/nim-lang/nifspec?tab=readme-ov-file#why-yet-another-data-format
13:52:39FromDiscord<arnetheduck> my hope is that it's a _non-lossy_ format compared to the source code so that `nlvm` can continue to generate high-quality llvm ir from it - haven't had time to (and won't have, probably) validate that
13:52:55FromDiscord<arnetheduck> (edit) "my hope is that it's a _non-lossy_ format compared to the source code ... so" added "/ AST"
13:53:05FromDiscord<nnsee> that does seem to be one of the design goals
13:53:08FromDiscord<nnsee> >Lossless conversion back to the source code is possible.
13:55:29FromDiscord<arnetheduck> the transformation to llvm ir is lossy unless you use its custom metadata to encode the extra stuff - this is find for the last stage of compilation, but not a general-purpose high-level IR that works at the language-specific level, for transformations etc - llvm is good when you get into language-independent land but it can't reason about semantics enforced by the language (that sometimes result in optimization opportunities not open
13:55:39FromDiscord<arnetheduck> (edit) "find" => "fine"
14:01:11FromDiscord<Phil> In reply to @arnetheduck "the transformation to llvm": Why nim => LLVM IR is lossy I don't fully get there.↵↵Unless lossy here means "You lose the macro syntax", because isn't the parsing step just:↵nim with macros => nim with resolved macro code generation => llvm IR where LLVM IR => nim with resolved macro code generation should be possible?
14:01:37FromDiscord<Phil> (edit) "In reply to @arnetheduck "the transformation to llvm": Why nim => LLVM IR is lossy I don't fully get there.↵↵Unless lossy here means "You lose the macro syntax", because isn't the parsing step just:↵nim with macros => nim with resolved macro code generation => llvm IR where LLVM IR => nim with resolved macro code generation should be possible?" => "sent a long message, see https://pasty.ee/XegjTZyP"
14:01:43FromDiscord<jmgomez> In reply to @nnsee ">Lossless conversion back to": Yeah, you can’t get back to nim code (IC) if you lose information
14:08:24Amun-RaI have to finish my LL to C converter someday
14:09:51FromDiscord<arnetheduck> In reply to @isofruit "Why nim => LLVM": lossy means all kinds of losses - nim for example has specific rules for when you can "move" a value that are lost in a general-purpose IR - from there you can deduce lifetimes of variables and elide copies and memory allocations, but those rules do not exist at the LLVM IR level - aliasing is another good example - clang for example puts type-based aliasing rules in special metadata to be ab
14:20:48FromDiscord<nervecenter> I'm dealing with a data `string` with lots of `\x00` bytes in it, which means everything that interprets the string is coming up short. Is there any way around this?
14:32:34Amun-Rainterprets the string == accepts cstring type?
15:46:10*Guest14 joined #nim
15:46:16*Guest14 quit (Client Quit)
17:35:03FromDiscord<mikenew> In reply to @michael.lenz. "Sure, only we had": Ah okay, that's fair enough then. Up to you if you think it warrants a feature request; you understand it better than I do. And yes, I'm using orc. I'm actually really happy I was able to use musl and statically compile everything since it gave me a truly dependency-free binary. So the "flaw" put me in a better spot overall, but it would be nice to have a way to free the heap without havin
17:37:08FromDiscord<michael.lenz.> In reply to @mikenew "Ah okay, that's fair": It’s possible to use malloc_trim() on linux, while I have red that it’s deprecated
17:37:40FromDiscord<michael.lenz.> Also possible to tune system allocator to trigger unmapping more frequently
17:39:05FromDiscord<michael.lenz.> int mallopt(int param, int value);
17:39:32FromDiscord<michael.lenz.> M_TRIM_THRESHOLD
17:39:45FromDiscord<michael.lenz.> But I haven’t tried it yet
17:40:50FromDiscord<michael.lenz.> And for osx I used the function malloc_zone_pressure_relief, it works
17:41:10FromDiscord<michael.lenz.> In windows there’s aggresive heapmin or smth
17:41:46FromDiscord<mikenew> I am confused though; in my case this really behaves like a memory leak. The program will idle at around 150MB, and during a big op it will get up to around 200MB. With this musl build it drops immediately back down to 150 and stays there indefinitely. With glibc and nim's default allocator, it never quite drops back down to 150. Eventually it will eat the 1/2 gig of ram and 1 gig of swap until the OS kills it
17:42:14FromDiscord<mikenew> I would have thought that even if the heap gets bigger, it would eventually stabilize
17:42:54FromDiscord<mikenew> That is interesting about the system allocator though. I might play with that
17:43:56FromDiscord<michael.lenz.> Right, it’s not a leak, but growing mmaped size
17:44:49FromDiscord<michael.lenz.> And the system allocator not takes it back, because for some reason thinks it might be used later to reduce fragmentation maybe, idk
17:45:53FromDiscord<michael.lenz.> Without of use -d:malloc there’s no chance to reclaim back the ram unfortunately. For that we need gc_compact
17:46:52FromDiscord<mikenew> I feel like the system allocator is being pretty dumb here. It kills my process before it will take back the memory that's been freed
17:48:00FromDiscord<michael.lenz.> That’s problem really, and why it happens idk. Maybe it’s mandatory to advise what threshold should be
17:48:38FromDiscord<michael.lenz.> To start reclaiming back freed chunks
17:50:09FromDiscord<mikenew> Yeah that would be nice
17:56:18FromDiscord<michael.lenz.> I mean it’s only possible with malloc and the functions I mentioned above
17:57:14FromDiscord<michael.lenz.> You can try to import them , and see how process will behave
17:57:38FromDiscord<michael.lenz.> While with nim alloc no chances now unfortunately
18:10:09FromDiscord<mikenew> sent a code paste, see https://play.nim-lang.org/#pasty=bxhChNqK
18:10:22FromDiscord<mikenew> And compiled with glibc. I'll let it run for a bit and see what the memory looks like
18:12:17FromDiscord<michael.lenz.> So it should reclaim back after 128 megabytes right?
18:12:59FromDiscord<michael.lenz.> I think you have to call it once
18:13:26FromDiscord<mikenew> I'm not sure what you mean by call it
18:13:34FromDiscord<michael.lenz.> Ececute
18:14:00FromDiscord<michael.lenz.> Place discard mall… somewhere in beginning
18:14:25FromDiscord<mikenew> I'm calling it here no? `echo "mallopt returns: " & $mallopt(M_TRIM_THRESHOLD, 128 1024)`
18:14:31FromDiscord<mikenew> Do you mean something else?
18:14:47FromDiscord<michael.lenz.> Ah yes, everything is ok
18:15:03FromDiscord<michael.lenz.> I thought you placed it somewhere in loop
18:15:45FromDiscord<mikenew> Also, I'm only just reading the docs but I don't think it means that it frees memory after some threshold. I think it's setting the page size to 128kb, and it's freeing it once the memory at the top of the heap has a contiguous block of that size
18:16:13FromDiscord<michael.lenz.> Hmm let me check manpages
18:18:24FromDiscord<mikenew> Also, first impression is that I don't think it improved things. But I'm also not sure if I need a different threshold size
18:18:28FromDiscord<michael.lenz.> sent a long message, see https://pasty.ee/BDsjPEZi
18:18:37FromDiscord<michael.lenz.> Should work
18:19:17FromDiscord<mikenew> Okay I'm going to try 1kb and see
18:20:08FromDiscord<michael.lenz.> Htop is helpful in this case, residual ram column should decrease for the process
18:21:04FromDiscord<michael.lenz.> Just in case, to not use free -m or other tools
18:23:19FromDiscord<mikenew> It seems... pretty good? Hard to tell without it running for a while but it does seem like the residual ram is coming back down
18:23:33FromDiscord<mikenew> I would need to do some side-by-side to really say for sure
18:24:12FromDiscord<michael.lenz.> Not better than musl for sure, but it works similarly in osx too
18:25:02FromDiscord<mikenew> Yeah I'm definitely going to use the musl build long term. This is mostly curiosity at this point I guess
18:26:19FromDiscord<mikenew> I'm also wonder that if it only frees blocks at the top of the heap, does that mean that if the memory is fragmented it could still grow over time?
18:26:19FromDiscord<michael.lenz.> With MUSL is at the expense of speed.
18:26:35FromDiscord<michael.lenz.> Sorry, idk
18:26:41FromDiscord<mikenew> Is it slower? Do you just mean because it's more costly to get memory back?
18:26:58FromDiscord<michael.lenz.> Musl should be less efficient I think
18:27:45FromDiscord<mikenew> I certainly can't tell a difference for what I'm doing, but it's a pretty lightweight server anyway
18:28:32FromDiscord<michael.lenz.> Yeah. Anyway it’s better than having oom
18:29:41FromDiscord<mikenew> Definitely
18:33:31FromDiscord<dreamtheater92> Anyone know of an up to date AWS SDK for Nim? This one seems rather unmaintained https://github.com/disruptek/atoz
18:51:16FromDiscord<0ffh> In reply to @dreamtheater92 "Anyone know of an": Don't know. Assuming it works, why should there be updates?
19:25:09*beholders_eye quit (Ping timeout: 276 seconds)
20:18:21FromDiscord<System64 ~ Flandre Scarlet> Doesn't Nim have some kind of List Comprehension?
20:35:42FromDiscord<fabric.input_output> In reply to @sys64 "Doesn't Nim have some": there's `collect` from either `sugar` or `sequtils` which is the closest thing
20:39:43FromDiscord<System64 ~ Flandre Scarlet> In reply to @fabric.input_output "there's `collect` from either": And nothing for arrays?
20:39:59FromDiscord<dreamtheater92> In reply to @0ffh "Don't know. Assuming it": because it’s missing clients for many services so clearly he needs to run his code generator regularly
20:40:21FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=SPaUrrVc
20:57:58FromDiscord<fabric.input_output> sent a code paste, see https://play.nim-lang.org/#pasty=DNbHEicv
21:02:42FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=LIEvkERA
21:15:32FromDiscord<fabric.input_output> sent a code paste, see https://play.nim-lang.org/#pasty=CsczUSfR
21:26:04FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=qqtRpExv
21:29:14FromDiscord<fabric.input_output> sent a code paste, see https://play.nim-lang.org/#pasty=MZHqCjaj
21:32:37FromDiscord<System64 ~ Flandre Scarlet> How do sets work? Storing values on a single number?
21:39:53*ntat quit (Quit: Leaving)
21:48:24FromDiscord<fabric.input_output> In reply to @sys64 "How do sets work?": yeah, sort of like flags you do in C with bit operators, bitset essentially, but can support up to 2^16 bits.
22:25:20*beholders_eye joined #nim
23:19:50*beholders_eye quit (Ping timeout: 260 seconds)