<< 05-02-2025 >>
00:04:26*beholders_eye quit (Ping timeout: 252 seconds)
00:08:41*tiorock joined #nim
00:08:41*rockcavera is now known as Guest7842
00:08:41*Guest7842 quit (Killed (tungsten.libera.chat (Nickname regained by services)))
00:08:41*tiorock is now known as rockcavera
00:23:34*rockcavera quit (Remote host closed the connection)
00:24:16*rockcavera joined #nim
00:33:02*xutaxkamay quit (Ping timeout: 252 seconds)
00:33:29*xutaxkamay joined #nim
01:15:05FromDiscord<umi_l> sent a code paste, see https://play.nim-lang.org/#pasty=kMCQgpPf
01:21:42FromDiscord<Elegantbeef> The `Pragma` node is empty so you cannot do anything
01:22:15FromDiscord<umi_l> In the AST the pragma node doesn't identify which pragma is being applied?
01:23:30FromDiscord<Elegantbeef> No it does
01:23:36FromDiscord<Elegantbeef> But it should have children nodes
01:23:46FromDiscord<Elegantbeef> So this macro is ran after the pragmas were stripped of the typesections
01:28:24FromDiscord<lainlaylie> In reply to @eebahn "https://github.com/nim-lang/Nim/blob/devel/doc/gram": i think its the one described here: https://nim-lang.github.io/Nim/manual.html#about-this-document
01:35:46FromDiscord<umi_l> In reply to @Elegantbeef "So this macro is": Hm, this is the signature if that helps:↵`macro registerScripts(scriptTypes: varargs[typed]) =`↵what could I do to make it run prior to the pragmas being stripped, and or where should I look to figure out more?
01:36:30FromDiscord<umi_l> Maybe important to note the macro is defined in a different module from where the pragma is defined and used.
01:38:10FromDiscord<Elegantbeef> Oh I thought this was a type section macro, what pragmas are you annotating with?
01:43:11FromDiscord<umi_l> sent a code paste, see https://play.nim-lang.org/#pasty=JOuMExGM
01:44:30FromDiscord<Elegantbeef> exported is?
01:49:58FromDiscord<umi_l> exported is just the name of the pragma, its purpose is supposed to just be a tag, the name doesn't matter functionality is supposed to be similar to Unity's SerializeField if you're familiar with that.
01:50:09FromDiscord<umi_l> unless I'm misunderstanding how pragmas work
01:52:18FromDiscord<Elegantbeef> Well that pragma doesn't do anything
01:52:23FromDiscord<Elegantbeef> `{.pragma: exported.}` is an empty pragma it's not detectable by anything
01:52:30FromDiscord<Elegantbeef> Cause it expands to `{..}`
01:52:31FromDiscord<Elegantbeef> you want `template exported() {.pragma.}`
01:52:51FromDiscord<Elegantbeef> You'd do like `{.pragma: exported, dynlib, exportc.}` `proc sendItToC(){.exported.}`
01:53:53FromDiscord<umi_l> sent a code paste, see https://play.nim-lang.org/#pasty=GnLbxSNV
01:55:24FromDiscord<Elegantbeef> You also can use the `macros.hasCustomPragma` on an instantiated object's field
01:55:40FromDiscord<Elegantbeef> so you can do like `hasCustomPragma(x.speed)`
01:55:42FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=GiXshtcI
02:00:17FromDiscord<umi_l> 👍
02:46:21FromDiscord<arkanoid> that really smells like https://en.wikipedia.org/wiki/Aspect-oriented_programming↵(@pmunch)
03:10:15*xet7 quit (Remote host closed the connection)
03:41:00*rockcavera quit (Remote host closed the connection)
08:43:08FromDiscord<xtrayambak> @yummy_licorice I've updated the [Louvre bindings](<https://github.com/xTrayambak/nim-louvre>) to be in a separate package which you can import into your compositor, and I'll continually try to keep it in parity with the current Louvre version.
09:02:03*alexdaguy joined #nim
10:45:56*beholders_eye joined #nim
10:47:04FromDiscord<nocturn9x> I have a bit of compile time code that is crashing with nonsense errors
10:47:11FromDiscord<nocturn9x> and I can't seem to be able to get a stack trace
10:47:26FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=SDSAfcjL
10:47:40FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=bhAvkQoT
10:48:23FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=pMdgJAYa
10:48:41FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=YGNKHika
10:48:47FromDiscord<nocturn9x> regardless of me using `-d:debug` or `-d:danger`
10:49:15FromDiscord<nocturn9x> if I replace the entire body of the compile time function with `doAssert false` it fails as expected, but if I just place it at the very beginning and leave the body unchanged, it's like it's getting ignored
10:49:18FromDiscord<nocturn9x> tf is going on?
10:49:42FromDiscord<nocturn9x> my guess is that `ord` is crashing
10:50:40FromDiscord<nocturn9x> (nevermind, removing `ord` does not change things)
10:51:05FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=JpGebGVt
10:51:33FromDiscord<nocturn9x> ALIGNMENT_BOUNDARY is just 64
10:54:58FromDiscord<nocturn9x> lol I just noticed the function isn't even correct
10:55:05FromDiscord<nocturn9x> so it's like not even compiling it all
10:55:26FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=WDoAQgYs
10:57:00FromDiscord<nocturn9x> if I do something like comment out all the loops and just have a for loop printing numbers it works as expected
10:57:07FromDiscord<nocturn9x> as soon as I uncomment even just the first loop nim chokes
10:57:09FromDiscord<nocturn9x> wtf
10:57:45FromDiscord<xtrayambak> sent a code paste, see https://play.nim-lang.org/#pasty=fNRVaqBN
10:57:55FromDiscord<nocturn9x> well it's supposed to run at compile time lol
10:57:59FromDiscord<xtrayambak> The Nim VM can be wonky at times
10:58:05FromDiscord<nocturn9x> I am aware
10:58:38FromDiscord<nnsee> sent a code paste, see https://play.nim-lang.org/#pasty=ctQLNrSZ
10:58:45FromDiscord<nocturn9x> a ~33MB string
10:58:48FromDiscord<xtrayambak> Are you that person making a machine learning library with zero allocations or something?
10:58:57FromDiscord<nocturn9x> In reply to @xtrayambak "Are you that person": no, I'm making a chess engine
10:58:57FromDiscord<xtrayambak> In reply to @nocturn9x "a ~33MB string": That could very well be the cause :P
10:59:06FromDiscord<nocturn9x> really?
10:59:07FromDiscord<nocturn9x> bruh
10:59:10FromDiscord<xtrayambak> A 33MB string iteration sounds bad
10:59:25FromDiscord<xtrayambak> that's 33 MB turned into bytes divided by a uint8
10:59:26FromDiscord<nocturn9x> I need this to be evaluated at compile time
10:59:28FromDiscord<nocturn9x> C++ can do it just fine
10:59:29FromDiscord<nocturn9x> rofl
10:59:33FromDiscord<nnsee> i mean i don't necessarily see a reason why that should fail
10:59:44FromDiscord<nocturn9x> I want to store the network weights in the .static segment
10:59:53FromDiscord<nocturn9x> then, at compile time, construct the network object
10:59:57FromDiscord<nocturn9x> so at runtime I just need to assign it
11:00:05FromDiscord<xtrayambak> It shouldn't unless you're doing silly stuff in it
11:00:13FromDiscord<nocturn9x> how is this silly
11:00:13FromDiscord<nocturn9x> lol
11:00:31FromDiscord<nocturn9x> it's standard practices to load the embedded network of a chess engine from a constant
11:00:34FromDiscord<nocturn9x> (edit) "practices" => "practice"
11:00:47FromDiscord<xtrayambak> Hold on, are you iterating over every character in DEFAULT_NET_PATH?
11:01:11FromDiscord<xtrayambak> My bad I thought you're iterating over that haha
11:01:11FromDiscord<nocturn9x> In reply to @nocturn9x "I use it like": no, it's DEFAULT_NET_WEIGHTS as seen here
11:01:17FromDiscord<xtrayambak> If you aren't, it shouldn't cause any problems
11:01:21FromDiscord<xtrayambak> Weird...
11:01:23FromDiscord<nocturn9x> which is the ~33MB string
11:01:38FromDiscord<nocturn9x> If I make the loop iterate it works fine
11:01:44FromDiscord<nocturn9x> it's as soon that I access the string that it dies
11:04:54FromDiscord<nocturn9x> I have this now
11:05:00FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=ugwwMiES
11:05:02FromDiscord<nocturn9x> which runs fine
11:05:09FromDiscord<nocturn9x> so it's definitely not an index out of bounds error
11:05:43FromDiscord<nnsee> can it be the calls to toLittleEndian?
11:05:53FromDiscord<nocturn9x> ah I'm never incrementing pos
11:05:54FromDiscord<nocturn9x> brb
11:05:58FromDiscord<nocturn9x> should go up by 2
11:06:11FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=NhoZAWsN
11:06:15FromDiscord<nocturn9x> idk how this could cause problems
11:07:01FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=eoFJJhCD
11:07:01FromDiscord<nocturn9x> this runs fine
11:07:40FromDiscord<nocturn9x> if I change it to pos += 3 it fails with an index out of bounds exception
11:07:41FromDiscord<nocturn9x> as expected
11:10:36FromDiscord<nocturn9x> anyway I'm slowly working my way towards something that works
11:10:41FromDiscord<nocturn9x> seems like nim's vm is just buggy as usual
11:13:01FromDiscord<nocturn9x> `/home/nocturn9x/.choosenim/toolchains/nim-2.2.0/lib/system/memory.nim(10, 5) Error: cannot 'importc' variable at compile time; c_memcpy`
11:13:03FromDiscord<nocturn9x> oof
11:13:15FromDiscord<nocturn9x> toLittleEndian requires memcpy
11:13:17FromDiscord<nocturn9x> time to rewrite it
11:26:36FromDiscord<nocturn9x> can someone enlighten me
11:26:44FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=olSsDCPr
11:26:54FromDiscord<nocturn9x> why in the unholy fuck does this work witn `int16` but not `uint16`
11:27:32FromDiscord<nocturn9x> with any `uint` it just fails
11:27:46FromDiscord<nocturn9x> (edit) "witn" => "with"
11:29:04FromDiscord<nocturn9x> I love it when nim's vm acts retarded like this
11:29:09FromDiscord<nocturn9x> definitely a plus of the language
11:30:54FromDiscord<Robyn [She/Her]> In reply to @nocturn9x "toLittleEndian requires memcpy": Could use stew/endians2 btw
11:31:13FromDiscord<nocturn9x> this does not fix the problem of nim's vm being a massive piece of shit
11:31:25FromDiscord<nocturn9x> if I just use unsigned instead of signed integers it shits itself
11:31:29FromDiscord<Robyn [She/Her]> stew/endians2 has a pure Nim impl
11:31:35FromDiscord<nocturn9x> yes I am aware
11:31:39FromDiscord<nocturn9x> again, not the problem
11:31:44FromDiscord<Robyn [She/Her]> In reply to @nocturn9x "why in the unholy": could be something to do with signed code or smth?
11:31:52FromDiscord<Robyn [She/Her]> What did i just say
11:32:10FromDiscord<Robyn [She/Her]> I mean, could it be something to do with overflow checking logic? Since uints dont have that
11:32:13FromDiscord<nocturn9x> the problem is the nim VM shitting itself whenever I use `uint16`
11:32:16FromDiscord<nocturn9x> which I need
11:32:42FromDiscord<nocturn9x> because bit operations on signed vs unsigned integers work differently
11:33:17FromDiscord<nocturn9x> when it works, nimvm is great, but when it doesn't work it makes me want to crack my skull against a wall
11:33:30FromDiscord<nnsee> In reply to @nocturn9x "because bit operations on": they do?
11:33:37FromDiscord<nocturn9x> sign extension
11:33:39FromDiscord<nocturn9x> fucks things
11:33:42FromDiscord<Robyn [She/Her]> In reply to @nocturn9x "when it works, nimvm": Justifiable
11:33:55FromDiscord<nocturn9x> why tf is araq bothering with a new IR or some shit
11:34:01FromDiscord<nocturn9x> if pretty basic fucking features of the language don't even work
11:34:08FromDiscord<nnsee> In reply to @nocturn9x "sign extension": are you 100% sure about this
11:34:20FromDiscord<nocturn9x> I am only certain when it comes to death
11:34:35FromDiscord<Robyn [She/Her]> In reply to @nocturn9x "why tf is araq": It's a full rewrite
11:34:43FromDiscord<nnsee> because i'm like 60% sure that operations should be the same and if you cast the result to a uint16 it should be identical
11:34:48FromDiscord<Robyn [She/Her]> Have you looked at Nimony?
11:34:53FromDiscord<nocturn9x> In reply to @nnsee "because i'm like 60%": that is literally the problem
11:34:56FromDiscord<nocturn9x> I can't cast to an uint16
11:34:59FromDiscord<nocturn9x> the VM shits itself
11:35:00FromDiscord<nocturn9x> lmao
11:35:06FromDiscord<nnsee> not the result even? after doing the bitwise OR
11:35:19FromDiscord<nnsee> if that is so then that's definitely a VM bug
11:35:21FromDiscord<nocturn9x> I have rewritten a toLittleEndian impl. in pure nim
11:35:23FromDiscord<nocturn9x> and even there
11:35:25FromDiscord<nocturn9x> the VM shits itself
11:35:29FromDiscord<nocturn9x> if I use uint16
11:35:50FromDiscord<lainlaylie> if the problem has been identified an issue should be filed and a workaround used in the meantime
11:35:52FromDiscord<nocturn9x> In reply to @battery.acid.bubblegum "Have you looked at": only read the roadmap
11:36:09FromDiscord<nocturn9x> In reply to @lainlaylie "if the problem has": I have no idea what the issue is so I can't tell what I'm supposed to be working around
11:36:38FromDiscord<Robyn [She/Her]> Yeah it's an impl from the ground up which'll hopefully fix quite a lot of the small inconsistencies in the language and supported backends that pile up
11:36:46FromDiscord<nocturn9x> does it also fix nimvm
11:37:02FromDiscord<nocturn9x> cuz that thing either works perfectly with no special casing needed or it just chokes on its own vomit
11:37:05FromDiscord<nocturn9x> there is no in between
11:37:23FromDiscord<Robyn [She/Her]> It's still in development :P but since they'd be using NIF they'd prolly have to rewrite the VM anyway
11:37:58FromDiscord<nnsee> as a workaround if signed int16s work can't you just assign those to the weights array and cast to uint16 when you actually use them? not the neatest but would stop the vm from shitting the bed as far as i can tell
11:38:10FromDiscord<nocturn9x> that does not work because it would require runtime code
11:38:15FromDiscord<nocturn9x> which is the very thing I'm trying to avoid
11:38:21FromDiscord<nocturn9x> I want the network to be in the static segment
11:38:45FromDiscord<nocturn9x> it's no big deal, just extra performance because then it's easier to share the network across processes by mmapping the weights
11:38:58FromDiscord<Robyn [She/Her]> Isn't casting not really a performance hit by compilers?
11:39:09FromDiscord<nocturn9x> the problem isn't the casting itself
11:39:14FromDiscord<nocturn9x> the problem is that it would be a constant
11:39:23FromDiscord<nocturn9x> there is no easy way to cast the entire network object
11:39:35FromDiscord<nocturn9x> because there is alignment involved too
11:39:42FromDiscord<nnsee> hm
11:39:48FromDiscord<nocturn9x> for AVX2 inference
11:39:53FromDiscord<Robyn [She/Her]> This sounds like a pain
11:39:57FromDiscord<nocturn9x> (edit) "AVX2" => "AVX(51)2"
11:39:58FromDiscord<nocturn9x> it is
11:39:58FromDiscord<nocturn9x> lol
11:40:49FromDiscord<nnsee> if casting to uint16s really is broken in the vm (which is a wtf sentence on its own) then writing a reproducer for this should be really simple
11:40:55FromDiscord<nocturn9x> yeah
11:40:58FromDiscord<nocturn9x> my thoughts exactly
11:41:45FromDiscord<nocturn9x> just read bytes from a `static string` in a loop and try to do something with those
11:41:49FromDiscord<nocturn9x> (edit) "just read bytes from a `static string` in a loop and try to do something with those ... " added "by casting"
11:43:01FromDiscord<nocturn9x> idk if the string being very large is the problem
11:43:12FromDiscord<nocturn9x> it's some 34 million bytes
11:44:03FromDiscord<nnsee> might be overflowing something, somewhere, and that's why you're getting really funky behavior. but 34 million isn't really that much by any standard
11:44:11FromDiscord<nocturn9x> _I know_
11:44:21FromDiscord<nocturn9x> but it's Nim, nothing surprises me anymore
11:44:42FromDiscord<nocturn9x> I've encountered bugs where doing a case statement on a string caused the C codegen to silently die
11:44:47FromDiscord<nocturn9x> no error, no longs, nothing
11:44:52FromDiscord<nocturn9x> this is child's play compared to that
11:45:02FromDiscord<nocturn9x> (edit) "longs," => "logs,"
11:45:10FromDiscord<nocturn9x> especially since this is a noncritical feature
11:45:12FromDiscord<nocturn9x> if it doesn't work, too bad
11:45:35FromDiscord<nocturn9x> In reply to @nocturn9x "I've encountered bugs where": (that was reported and subsequently fixed, or at least my github issue was closed)
12:13:12FromDiscord<xtrayambak> sent a code paste, see https://play.nim-lang.org/#pasty=JXwKYVFc
12:13:23FromDiscord<xtrayambak> Wait let me check what type `ord` returns
12:13:34FromDiscord<xtrayambak> I've gotten funky behaviour when casting integers before
12:13:55FromDiscord<xtrayambak> @nocturn9x Try replacing `cast[int16]()` with `int16()`
12:43:04Amun-Rabeen there done that, there's a user error somewhere in compile-time function
12:44:28Amun-RaI don't like the conversions in https://play.nim-lang.org/#pasty=SDSAfcjL at all
12:46:07FromDiscord<nnsee> huh, why are the asterisks converted to bullet points
12:47:07Amun-Raord returns int, you should really use uint16 instead; is toLittleEndian aware that only 16 lower bits or 32-bit/64-bit signed integer should be swapped?
12:47:41Amun-Ras/or/of/
12:49:17Amun-Raif you make an integer out of two bytes you don't need any endianness convertion at all; either do: `data[pos] or (data[pos+1].uint16 shl 8)` or `data[pos+1] or (data[pos].uint16 shl 8)`
12:49:25Amun-RaconversioN*
12:53:46Amun-Raalso readInt16 in line 14 is endianness unaware
13:35:41*ntat joined #nim
13:44:01FromDiscord<nocturn9x> In reply to @xtrayambak "<@523555920265871380> Try replacing `cast[int16]()`": no that works
13:44:04FromDiscord<nocturn9x> it's uint16 that's the problem
13:44:11FromDiscord<nocturn9x> and using uint16() leads to the same error
13:44:47FromDiscord<nocturn9x> In reply to @Amun-Ra "if you make an": lol I do make an integer out of 2 bytes
13:44:59FromDiscord<nocturn9x> why do you think I'd be caring about endianness???
13:45:03FromDiscord<nocturn9x> I'm dumb but not that dumb
14:05:13FromDiscord<fl4shk> Does Nim provide control to the developer of whether a C struct it emits is a pointer?
14:05:33FromDiscord<fl4shk> Or is every C struct it emits a pointer?
14:05:51FromDiscord<fl4shk> Like can I pass a Nim data structure by value?
14:10:35FromDiscord<xtrayambak> In reply to @fl4shk "Does Nim provide control": What?
14:11:24FromDiscord<xtrayambak> Could you elaborate? I didn't quite get you
14:12:01FromDiscord<lainlaylie> https://nim-lang.org/docs/manual.html#foreign-function-interface-bycopy-pragma
14:12:14FromDiscord<lainlaylie> but usually you shouldn't have to worry about this
14:19:03FromDiscord<fl4shk> In reply to @lainlaylie "but usually you shouldn't": it's relevant to a weird use case I've got
14:19:34FromDiscord<fl4shk> I want to use Nim to write PipelineC code
14:20:09FromDiscord<fl4shk> PipelineC takes a variant of C code as input
14:20:43*alexdaguy quit (Quit: w)
14:27:50FromDiscord<fl4shk> so I agree, normally you don't need stuff like this
14:27:54FromDiscord<fl4shk> :)
15:48:19FromDiscord<thomastjdev> sent a code paste, see https://play.nim-lang.org/#pasty=uwCcFzFY
15:53:47Amun-Ranocturn9x: that what I mean, you don't need to call any byte swapping function
15:54:32FromDiscord<nocturn9x> I do!
15:54:36FromDiscord<nocturn9x> byte order matters.
15:54:42FromDiscord<nocturn9x> I'm reading 16 bit integers
15:54:46Amun-Raright
15:54:58Amun-Rathen construct uint16 by yourself
15:55:09Amun-Raare these values big-endian or little-endian?
15:55:43FromDiscord<nocturn9x> that's the point, I have no idea, hence the endianness check
15:55:50Amun-Rawait, what?
15:55:53FromDiscord<nocturn9x> the network file is supposed to be encoded in little endianness
15:55:57FromDiscord<nocturn9x> (edit) "endianness" => "endian"
15:56:06Amun-Ranetwork byte order == big-endian order
15:56:06FromDiscord<nocturn9x> as in that's how the final quantised network is outputted
15:56:17FromDiscord<nocturn9x> 16 bit little endian integers
15:56:35Amun-Raso if that's little-endian, the code should be like that:
15:56:51Amun-Racast[int16](data[0] or (data[1].uint16 shl 8))
15:58:12Amun-Raif you want to check where's the error - rewrite the exact function for runtime
15:58:19Amun-Rajust to test it
15:58:30FromDiscord<nocturn9x> will try
15:59:18Amun-Raand use fixed size types for type conversion, don't use ord
16:00:01Amun-Raah, data is a string
16:00:10Amun-Racast[int16](data[0].uint16 or (data[1].uint16 shl 8))
16:11:03FromDiscord<fl4shk> how do you compile into C source code?
16:16:24FromDiscord<.bobbbob> nim c source.nim
16:17:26FromDiscord<fl4shk> that doesn't seem to emit C source code, but rather a compiled executable
16:18:22FromDiscord<fl4shk> sent a code paste, see https://play.nim-lang.org/#pasty=UHmHjzXr
16:18:53FromDiscord<fl4shk> might have to do with the config files?
16:22:52FromDiscord<spotlightkid> @fl4shk\: see the `--genScript` option (look at `nim --fullhelp | less`)
16:23:05FromDiscord<fl4shk> oh `--genScript`? I'll look at that
16:24:34Amun-Ra--nimcache=outdir/
16:25:43FromDiscord<infohazrd_> Hello, @pmunch! ↵I have some questions regarding the usage of futhark when the c headers/source code contain some nim keywords. Could i contact you directly or would you prefer i open an issue in github?
16:26:52FromDiscord<pmunch> Open an issue please 🙂 I'm sick atm, and with any luck someone else can answer you
16:27:22FromDiscord<pmunch> Futhark should automatically handle Nim keywords though
16:27:46FromDiscord<infohazrd_> In reply to @pmunch "Open an issue please": will do 🙂 wish you a speedy recovery!
16:27:58FromDiscord<solitudesf> In reply to @thomastjdev "I finally got around": why not use `nimble lock` nimbledeps aren't made to be commited.
16:28:29FromDiscord<solitudesf> (edit) "lock`" => "lock`?"
16:28:43FromDiscord<infohazrd_> sent a code paste, see https://play.nim-lang.org/#pasty=CrUSnDsh
16:29:55FromDiscord<fl4shk> hm it appears that maybe Nim won't do what I need for the `PipelineC` stuff
16:30:15FromDiscord<fl4shk> oh well!
16:30:58FromDiscord<fl4shk> ...though maybe I can strip out the functions I write
16:31:28FromDiscord<fl4shk> it does appear that the available cross-compilation targets are hard-coded though
16:31:32FromDiscord<fl4shk> so I can't... use it directly
16:31:54FromDiscord<fl4shk> not for the embedded system I wrote a GCC port for
16:32:08FromDiscord<fl4shk> maybe could instead write up a more direct C code generation thing I came up with
16:32:29FromDiscord<fl4shk> which I almost certainly could write as a Nim library that is for emitting C.
16:47:14*coldfeet joined #nim
16:49:08FromDiscord<zumi.dxy> worst case scenario: creating wrapper executables :)↵<https://github.com/ZoomTen/jibby/blob/master/jibby/tools/compile.nim>
16:49:21FromDiscord<zumi.dxy> and then tricking nim into using them
16:50:45FromDiscord<fl4shk> I know you
16:50:49FromDiscord<fl4shk> you're in another server I'm in at least
16:53:20FromDiscord<zumi.dxy> In reply to @fl4shk "that doesn't seem to": for completeness: `nim c -c --nimcache:somedir`
16:53:59FromDiscord<zumi.dxy> `-c` just does "compile-only"
16:54:05FromDiscord<zumi.dxy> (edit) ""compile-only"" => ""compile-to-C-only""
16:54:44FromDiscord<thomastjdev> In reply to @solitudesf "why not use `nimble": To ensure we're not dependend on Github, Gitlab and external users deleting their nimble packages. We have critical packages which requires full SBOM, signing and reproducible builds when requested.↵↵As far as I can see the `nimble lock` only provides a lock file, but that might allow me create a `nimbledata2.json` with only `{ "version": 1, "reverseDeps": {} }` the empty content.
16:56:44FromDiscord<fl4shk> @zumi.dxy have you any clue how to get just the functions I write as C code?
16:56:53FromDiscord<fl4shk> or do I need to do a script of some sort for that?
16:58:49FromDiscord<zumi.dxy> only thing I can think of is using `{.exportc.}`↵just so your functions will have the same name in C as in Nim
16:59:01FromDiscord<fl4shk> okay I guess I could use a script for that
17:18:04FromDiscord<xtrayambak> In reply to @fl4shk "<@233547000426135552> have you any": `{.exportc: "yourFunctionName".}`
17:18:09FromDiscord<fl4shk> right
17:18:11FromDiscord<xtrayambak> (edit) "`{.exportc: "yourFunctionName".}`" => "`{.exportc.}`"
17:18:59FromDiscord<xtrayambak> In reply to @fl4shk "that doesn't seem to": You'll have to point Nim's C cache to your local directory to do that
17:19:51FromDiscord<xtrayambak> `nim c --nimcache:cgen` and then you can view the generated C source code in there
17:19:58FromDiscord<xtrayambak> (edit) "there" => "the `cgen` directory"
17:20:03FromDiscord<fl4shk> thanks
17:22:08FromDiscord<fl4shk> so how do I do an operator overload?
17:22:15FromDiscord<fl4shk> (that's C++ terminology, apologies)
17:22:55FromDiscord<fabric.input_output> the same way you overload a function
17:23:05FromDiscord<fabric.input_output> but you put the operator in backticks
17:23:20FromDiscord<fl4shk> ah that's what I was not seeing in the documentation
17:23:44FromDiscord<fabric.input_output> sent a code paste, see https://play.nim-lang.org/#pasty=HOLrZdci
17:24:03FromDiscord<fl4shk> `Vec2` is the example I was going with for testing out operator overloading, too!
17:24:16FromDiscord<fl4shk> sent a code paste, see https://play.nim-lang.org/#pasty=pVRNvKJE
17:24:41FromDiscord<fl4shk> but I would prefer to use type parameterization for something like this
17:25:37FromDiscord<fabric.input_output> generics
17:25:40FromDiscord<fl4shk> right
17:25:43FromDiscord<fl4shk> I'll look them up
17:26:00FromDiscord<fl4shk> this seems like a language that's right up my alley.
17:26:12FromDiscord<fl4shk> but now that my lunch break is over, I've gotta get back to work
17:26:14FromDiscord<fl4shk> ttyl
17:26:18FromDiscord<fl4shk> oh but
17:26:19FromDiscord<fl4shk> I work remotely
17:26:31FromDiscord<fl4shk> so like... I can do somethign like this during my lunch break, haha
17:26:35FromDiscord<fl4shk> (edit) "somethign" => "something"
17:34:09*beholders_eye quit (Ping timeout: 248 seconds)
17:36:10*beholders_eye joined #nim
18:11:21FromDiscord<summarity> What's the reason `deepCopy` is disabled by default? Are there any risks associated with enabling it?
18:20:41*beholders_eye quit (Ping timeout: 268 seconds)
18:21:51*pqflx3 quit (Read error: Connection reset by peer)
18:22:15*pqflx3 joined #nim
18:32:18*coldfeet quit (Quit: Lost terminal)
18:43:34*beholders_eye joined #nim
19:04:41FromDiscord<yummy_licorice> In reply to @xtrayambak "<@801227226749599754> I've updated the": Great lol I'll contribute some more bindings when I get the time
19:09:24*pqflx3 quit (Ping timeout: 268 seconds)
19:12:55*pqflx3 joined #nim
19:13:11*pqflx3 quit (Remote host closed the connection)
19:23:50*beholders_eye quit (Ping timeout: 252 seconds)
19:29:32FromDiscord<nasuray> In reply to @thomastjdev "To ensure we're not": I'd think at that point it would be easier to just manually vendor the dependencies (or use submodules) and ignore nimble all together
19:33:24*Jjp137 quit (Ping timeout: 260 seconds)
19:46:57*Jjp137 joined #nim
20:12:11*kenran joined #nim
20:13:06*kenran quit (Remote host closed the connection)
20:20:52FromDiscord<nnsee> In reply to @pmunch "Open an issue please": get well soon
20:25:10*kenran joined #nim
20:49:19FromDiscord<pmunch> Thanks 🙂
21:05:44FromDiscord<fl4shk> get well soon!
21:08:50FromDiscord<arkanoid> is there a way to share data between threads without ever touching unsafe features like pointers? And without using channels?
21:15:34*ntat_ joined #nim
21:15:36*ntat_ quit (Remote host closed the connection)
21:17:53*__________ joined #nim
21:18:11*FromDiscord quit (Ping timeout: 252 seconds)
21:18:11*_________ quit (Ping timeout: 252 seconds)
21:18:12*ntat quit (Ping timeout: 252 seconds)
21:18:12*om3ga quit (Ping timeout: 252 seconds)
21:18:28*FromDiscord joined #nim
21:18:44FromDiscord<nervecenter> Oh yeah so that's #1
21:19:53*om3ga joined #nim
21:25:30FromDiscord<Elegantbeef> Pass a struct that is a value type to the thread as a parameter
21:25:41FromDiscord<Elegantbeef> Sharing is an unsafe operation
21:26:08FromDiscord<Elegantbeef> I believe Araq wants it done in macro in a Orc/Arc world↵(@summarity)
21:26:29FromDiscord<arkanoid> that's avoiding the problem, not a solution. That's ok only if you are using tasks for short living tasks
21:26:43FromDiscord<arkanoid> that's avoiding the problem, not a solution. That's ok only if you are using theads for short living tasks
21:27:02FromDiscord<Elegantbeef> I mean there is no safe way to share a value in present Nim as it's not a safe thing Nim can handle
21:27:07*rockcavera joined #nim
21:27:10FromDiscord<Elegantbeef> atomicarc approaches safety
21:27:33FromDiscord<Elegantbeef> But it still has gcsafe issues since it doesn't tell Nim to sod off
21:27:50FromDiscord<Elegantbeef> You can use atomic arc and do `--threadAnalysis:off`
21:28:24FromDiscord<Elegantbeef> If you use the guarded pragma you'll be fine
21:29:31*__________ quit (Quit: Reconnecting)
21:29:53*_________ joined #nim
21:33:58*kenran quit (Remote host closed the connection)
21:38:44FromDiscord<arkanoid> still not compiling with --mm\:atomicArc --threadAnalysis\:off and using locks and guarded pragma\: https://play.nim-lang.org/#pasty=OIKMZMHz
21:39:44FromDiscord<Elegantbeef> annotate it gcsafe
21:40:23FromDiscord<Elegantbeef> With thread analysis off procedures have to be annotated gcsafe explicitly to be passed to `gcSafe` parameters
21:45:23FromDiscord<Elegantbeef> https://play.nim-lang.org/#pasty=wwoWzNjz for an example that doesn't rely on a global value
21:49:00FromDiscord<Elegantbeef> Actually for that example you do not even need thread analysis turned off
22:27:38*jjido joined #nim
23:44:25*jjido quit (Quit: My laptop has gone to sleep. ZZZzzz…)