<< 21-01-2025 >>
00:23:54*beholders_eye quit (Ping timeout: 252 seconds)
01:01:11*SchweinDeBurg quit (Quit: WeeChat 4.6.0-dev)
01:32:35*SchweinDeBurg joined #nim
02:40:01FromDiscord<mjsdev> Is there a better way to get mutable for loop variables than adding .mitems onto things? Or some way to easily macro a `for var thing in ...` like syntax?
02:51:07*krux02 quit (Remote host closed the connection)
02:54:12FromDiscord<Robyn [She/Her]> In reply to @mjsdev "Is there a better": I'd say .mitems is the most idiomatic and replacing that with a macro is silly when it's not even a one liner
03:00:09*rockcavera quit (Remote host closed the connection)
03:27:49FromDiscord<lainlaylie> easy, just modify the language and compiler to support return type overloading and let it choose which iterator to use
03:41:24FromDiscord<heysokam> @lainlaylie that should take about five minutes. hold my beer
04:59:50FromDiscord<janakali> sent a code paste, see https://play.nim-lang.org/#pasty=sdSPRKNO
05:48:52*coldfeet joined #nim
05:59:42FromDiscord<lonepenguin91> @room Fuck NIGGERS fuck FAGGOTS trump will deport all border hopping niggers and make tranny pedophiles illegal #maga2024
06:30:55*coldfeet quit (Quit: Lost terminal)
06:40:58Amun-Raand there's also good old (and faster) for i in 0 ..
06:43:58*cm joined #nim
06:44:51*cm quit (Client Quit)
07:05:36*cm joined #nim
07:19:55*cm quit (Quit: Bye.)
07:20:58*cm joined #nim
07:39:19*cm quit (Quit: Bye.)
07:39:53*cm joined #nim
07:58:41FromDiscord<pmunch> https://pasty.ee/LNGJjhsS
07:58:51FromDiscord<pmunch> Where does the `300` go?
08:11:43*ntat joined #nim
08:16:54*redj quit (Quit: No Ping reply in 180 seconds.)
08:18:27*redj joined #nim
08:27:31FromDiscord<Elegantbeef> @pmunch I assume doing `y = 300` sets `y` to 300 then you overwrite that with the `"bob"`
08:28:22FromDiscord<Elegantbeef> Actually `test(100, 200, "Hello world", y = 300)` errors that it only got 1 argument
08:33:23FromDiscord<pmunch> That it only got one argument?
08:33:53FromDiscord<Elegantbeef> Well varargs are stubborn children so using two of them next to eachother is bound to cause problems
08:35:23FromDiscord<pmunch> Adding an argument you get the two last ones..
08:35:29FromDiscord<Elegantbeef> I know I've ran into similar before where I wanted a `nnkExprEqExpr` but instead you just get an error cause the compiler properly attempts to dispatch
08:36:06FromDiscord<Elegantbeef> `y = 300` matches for `y` which tells it to do the next vararg, odd bug
08:36:23FromDiscord<pmunch> Hmm, the issue here is that I need half my arguments typed and the other half untyped..
08:37:07FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=lZwqiVHW
08:37:12FromDiscord<Elegantbeef> This shows the funkiness
08:37:22FromDiscord<pmunch> In reply to @Elegantbeef "`y = 300` matches": Yeah that's what I was trying to do, split the varargs with the y. But it's odd that it just disappears
08:38:18FromDiscord<Elegantbeef> Well to be fair `y = 300` followed by anything should be an error
08:38:41FromDiscord<Elegantbeef> you already stated that `y` is a single value
08:39:02FromDiscord<pmunch> Hmm fair
08:39:15FromDiscord<pmunch> In my mind I parsed it as `y = (300, "bob")`
08:39:32FromDiscord<pmunch> And not `(y = 300), "bob"`
08:39:50FromDiscord<Elegantbeef> I don't know if there's a trick for this though
08:39:53FromDiscord<Elegantbeef> Need to have a think
08:41:10FromDiscord<pmunch> The problem I'm trying to solve is to take a list of arguments `100, 200, named = 100` and split them into `100, 200` and `named = 100` and then pass the first list to a macro expecting `typed` and the second half to the same macro expecting `untyped`.
08:41:23FromDiscord<Elegantbeef> Oh I have a hack
08:41:56FromDiscord<pmunch> Oh?
08:42:23FromDiscord<pmunch> I'm all ears, my next option would be to pass them in via two tuples
08:43:53FromDiscord<Elegantbeef> Nope sadly a `x: varargs[typed], dummy: int, y: varargs[untyped]` didn't work
08:43:57FromDiscord<Elegantbeef> So I guess use the tuple 😄
08:49:31FromDiscord<pmunch> It's only passing to another macro where I unpack it again, so performance shouldn't suffer
08:49:44FromDiscord<pmunch> (apart from the performance of the macro)
09:02:55*beholders_eye joined #nim
09:12:55*alexdaguy joined #nim
09:17:11*beholders_eye quit (Read error: Connection reset by peer)
09:18:09*beholders_eye joined #nim
10:54:27*beholders_eye quit (Quit: WeeChat 4.1.2)
10:56:49*beholders_eye joined #nim
11:16:30*krux02 joined #nim
11:37:54*redj quit (Ping timeout: 245 seconds)
13:56:02*pbsds3 joined #nim
13:58:42*fallback quit (Ping timeout: 276 seconds)
14:33:18*alexdaguy quit (Quit: WeeChat 4.5.1)
15:25:48*krux02 quit (Remote host closed the connection)
15:35:40*krux02 joined #nim
15:36:21FromDiscord<xtrayambak> gah I wrote a JavaScript runtime in Nim and it (sort of?) works
15:36:53FromDiscord<xtrayambak> I'm currently trying to make a HTTP server with it and it half works (i.e I can initialize a server from the JavaScript code) but the request handling part is a real pain
15:48:14FromDiscord<odexine> nice
16:07:43*krux02 quit (Remote host closed the connection)
16:20:33*ftajhii quit (Ping timeout: 248 seconds)
16:41:22FromDiscord<spotlightkid> Do `alloc`, `createShared` etc. return `nil` on failure? Or do they raise an exception?
17:17:14FromDiscord<odexine> i believe nil on failure; source code says raises: [] on allocImpl
17:28:00*beholders_eye quit (Ping timeout: 276 seconds)
17:29:15*beholders_eye joined #nim
17:31:29Amun-RaI think they just call oom handler
17:31:46Amun-Raalbeit I might be wrong
17:35:23FromDiscord<bostonboston> Allocimpl -> alloc -> rawalloc -> getsmallchunk -> getbigchunk -> requestoschunks -> allocpages/tryallocpages -> raiseOutOfMem↵↵Which will call the outofmemhook and then rawquit
17:38:14FromDiscord<odexine> oh yeah i forgot about the outofmem hook
17:40:37*beholders_eye quit (Ping timeout: 248 seconds)
17:48:28*beholders_eye joined #nim
17:48:31FromDiscord<michael.lenz.> Should return nil
17:49:49FromDiscord<michael.lenz.> In reply to @spotlightkid "Do `alloc`, `createShared` etc.": Try to allocate very huge amount. With —d:useMalloc
17:49:54*m5zs7k_ joined #nim
17:50:34*ox joined #nim
17:51:05*strogon14 quit (Ping timeout: 252 seconds)
17:51:17*oz quit (Ping timeout: 248 seconds)
17:51:17*via_ quit (Ping timeout: 248 seconds)
17:51:24*m5zs7k quit (Read error: Connection reset by peer)
17:51:35FromDiscord<odexine> iphone user spotted
17:51:44FromDiscord<michael.lenz.> In reply to @bostonboston "Allocimpl -> alloc ->": Out of mem hook not works unfortunately
17:52:55*via joined #nim
17:53:10*strogon14 joined #nim
17:54:56*disso-peach joined #nim
17:59:17Amun-Rashould work fine on linux with the default optimistic allocator
17:59:51*m5zs7k_ is now known as m5zs7k
17:59:53Amun-Rabut if you try to use that ram, that's a different story - here comes oomkiller :>
18:00:33FromDiscord<michael.lenz.> I'm afraid it will raise outfmem exception
18:03:03Amun-RaI mean when malloc return non-nil, there's not guarantee that memory will really be available
18:10:17FromDiscord<michael.lenz.> In reply to @Amun-Ra "I mean when malloc": If successful, calloc(), malloc(), realloc(), reallocf(), valloc(), and aligned_alloc() functions return↵ a pointer to allocated memory. If there is an error, they return a NULL pointer and set errno to ENOMEM
18:11:13Amun-Rayes, that's POSIX
18:11:43Amun-Rahttps://man7.org/linux/man-pages/man3/free.3.html
18:12:09FromDiscord<michael.lenz.> I tried to handle errors related to system allocator, but did it partially for strings, and if I remember it right, there was no error handling in nim
18:12:17Amun-Ra"By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. In case it turns out that the system is out of memory, one or more processes will be killed by the OOM killer."
18:13:41FromDiscord<michael.lenz.> that's true, but oom killer may be disabled for the process, or disabled entirely
18:14:01FromDiscord<michael.lenz.> this is not related to return value of malloc
18:14:07Amun-Rasure
18:14:57FromDiscord<michael.lenz.> in case if malloc returns ptr, this means system allocator "booked" the memory of requested size to the process
18:18:47FromDiscord<michael.lenz.> I mean requested size of bytes will belong to the process and no other could be able to use it
18:21:47FromDiscord<solitudesf> sent a code paste, see https://play.nim-lang.org/#pasty=zUTthgez
18:23:22FromDiscord<solitudesf> (edit) "https://play.nim-lang.org/#pasty=phZPbtsb" => "https://play.nim-lang.org/#pasty=QtzRDvFb"
18:24:25Amun-Rayes but conditions apply
18:26:53FromDiscord<solitudesf> ?
18:40:49FromDiscord<bostonboston> In reply to @michael.lenz. "Out of mem hook": Hook works for me
18:43:52FromDiscord<michael.lenz.> In reply to @bostonboston "Hook works for me": Are you able to prevent quitting the program?
18:48:17FromDiscord<bostonboston> I don't think you're supposed to be able to
18:49:12FromDiscord<michael.lenz.> In reply to @bostonboston "I don't think you're": This is the main reason of mem related errors handling
18:49:48FromDiscord<michael.lenz.> Used this approach previously
18:57:21*disso-peach quit (Quit: Leaving)
19:03:35FromDiscord<Elegantbeef> @solitudesf since they're not from the same parameter I believe the symbols are different
19:03:55FromDiscord<Elegantbeef> you can use `sameType(a, b) or sameType(b, a)` as there is some issue with aliases
19:04:43FromDiscord<solitudesf> In reply to @Elegantbeef "<@104136074569211904> since they're not": but they are the same when i compare them to bunch of other uint32's in different places.
19:05:04FromDiscord<solitudesf> In reply to @Elegantbeef "you can use `sameType(a,": that what i woud've used if i searched better
19:05:18FromDiscord<Elegantbeef> I imagine it's due to being from a parameter, but idk typed AST is buggy
19:24:48FromDiscord<yummy_licorice> Is nimterop still usable? I want to use a cop library in nim
19:24:59FromDiscord<saint._._.> Have you tried futhark?
19:25:01FromDiscord<solitudesf> futhark is better
19:25:01FromDiscord<saint._._.> @yummy_licorice
19:25:03FromDiscord<saint._._.> Ya
19:25:07FromDiscord<saint._._.> way better
19:25:16FromDiscord<yummy_licorice> In reply to @saint._._. "Have you tried futhark?": Doesn't work with cpp
19:25:23FromDiscord<yummy_licorice> According to the readme atleast
19:25:28FromDiscord<saint._._.> True
19:25:36FromDiscord<saint._._.> You an write a c wrapper though
19:25:40FromDiscord<saint._._.> And then use futhark
19:25:57FromDiscord<yummy_licorice> In reply to @saint._._. "You an write a": By hand 😨
19:26:06FromDiscord<saint._._.> Ya
19:26:25FromDiscord<yummy_licorice> Damn 😭 this isn't really a small library
19:26:30FromDiscord<solitudesf> brutal suggestion
19:27:33FromDiscord<solitudesf> you're gonna have to try it yourself. with nimterop's author leaving nim scene and futhark emerging, nimterop isn't used anymore.
19:27:59FromDiscord<yummy_licorice> In reply to @saint._._. "Ya": Atp it'd just be easier to use importcpp
19:28:09FromDiscord<yummy_licorice> And write Nim bindings by hand
19:31:40*ox is now known as oz
19:32:51FromDiscord<michael.lenz.> In reply to @yummy_licorice "Damn 😭 this isn't": Futhark works fine!
19:44:41FromDiscord<yummy_licorice> Hmm so I could either try my luck with nimterop or write a small script that uses gcc's xml to make bindings
19:49:07FromDiscord<saint._._.> What library are you trying to use btw?
19:49:21FromDiscord<saint._._.> In reply to @yummy_licorice "Atp it'd just be": Ya u could but I think usually doing like a c wrapper could be easier
19:49:27FromDiscord<saint._._.> depending on what you're doing
20:20:09*FromDiscord quit (Remote host closed the connection)
20:20:22*FromDiscord joined #nim
20:44:08*xet7 joined #nim
21:21:33*cm quit (Ping timeout: 246 seconds)
21:35:03*beholders_eye quit (Ping timeout: 252 seconds)
21:46:09*rockcavera joined #nim
22:14:57*ntat quit (Quit: Leaving)
22:23:29*beholders_eye joined #nim
22:27:14*SchweinDeBurg quit (Ping timeout: 265 seconds)
22:28:48*SchweinDeBurg joined #nim
22:31:20FromDiscord<pmunch> Thanks for the Futhark love. C++ support is high on the todo list, it's mostly just a matter of mapping C++ to Nim. All contributions are more than welcome!
22:51:24*SchweinDeBurg quit (Ping timeout: 265 seconds)
22:52:37*beholders_eye quit (Ping timeout: 248 seconds)
22:53:01*SchweinDeBurg joined #nim
22:54:44*beholders_eye joined #nim
23:06:29*beholders_eye quit (Ping timeout: 248 seconds)
23:07:05*beholders_eye joined #nim
23:42:27*SchweinDeBurg quit (Quit: WeeChat 4.6.0-dev)