<< 22-05-2023 >>

00:33:33FromDiscord<Elegantbeef> It should work the same for all intents and purposes↵(@Ayy Lmao)
00:33:37FromDiscord<Elegantbeef> The difference is the way the allocator works
00:35:01FromDiscord<Elegantbeef> Nimble is decentralised so you can upload it to a git host and then just `nimble install mylibraryUrl`↵(@wick3dr0se)
00:35:15FromDiscord<Elegantbeef> That installs it globally so you can use it with `nim c`
00:35:17FromDiscord<Ayy Lmao> In reply to @Elegantbeef "It should work the": Ok cool. It seems to solve the problems I was having with segfaults so far, aside from the one I get for turning threads on.
00:36:08FromDiscord<Elegantbeef> That sounds like Nim was deallocating something and it only fixed it cause it now uses the same allocator as the base
00:36:43*_________ quit (Ping timeout: 268 seconds)
00:41:52FromDiscord<Ayy Lmao> You mean deallocating something that it didn't allocate itself? Like something that the host allocated?
00:42:36FromDiscord<Elegantbeef> Yea
00:43:39*_________ joined #nim
00:44:09FromDiscord<Ayy Lmao> I wonder what it would be. I didn't tell it to deallocate anything other than the few things I allocated.
01:06:02*nanxiao joined #nim
01:24:32FromDiscord<Ayy Lmao> I don't really know how arc works but is it possible for it to get confused and deallocate something it isn't supposed to?
01:24:49FromDiscord<Rika> Shouldn’t be
01:24:55FromDiscord<Elegantbeef> It's scoped based
01:25:17FromDiscord<Elegantbeef> it's a relatively simple logical operation
01:25:29FromDiscord<Ayy Lmao> So it shouldn't randomly deallocate a host pointer it doesn't own?
01:25:32FromDiscord<Elegantbeef> I see now the bridge died briefly
01:25:35FromDiscord<Elegantbeef> Can i see your code agian
01:26:11FromDiscord<Ayy Lmao> In reply to @Elegantbeef "Can i see your": https://github.com/Alkamist/clap/blob/main/demo.nim
01:26:14FromDiscord<Rika> Pointers don’t deallocate by themselves
01:26:32FromDiscord<Elegantbeef> only `ref` is deallocated by the GC
01:26:33*lucasta quit (Read error: Connection reset by peer)
01:27:06*lucasta joined #nim
01:27:19FromDiscord<Rika> Ah the function pointer…
01:27:35FromDiscord<Rika> Not sure
01:27:57FromDiscord<ElegantBeef> What do you mean?
01:31:15FromDiscord<ElegantBeef> Oh shit
01:31:28FromDiscord<ElegantBeef> isnt 108 wrong?
01:32:28FromDiscord<ElegantBeef> Nevermind
01:37:09*nanxiao quit (Quit: Client closed)
01:38:11FromDiscord<ElegantBeef> Without being able to run this I guess I have to throw in the towel, nothing stands out as wrong like I said last time. Seems the api is deallocating your memory somehow
01:38:47FromDiscord<ElegantBeef> Does anything similar happen if you change that to like `foo: int`
01:39:59FromDiscord<ElegantBeef> Assuming this is heap corruption that integer should change to something unexpected
01:41:44*derpydoo joined #nim
01:41:53FromDiscord<ElegantBeef> I suppose you also could just do `echo cast[int](foo[0].addr)` 😄
01:44:32FromDiscord<Ayy Lmao> In reply to @ElegantBeef "Does anything similar happen": I'm not in a place I can test at the moment but I wouldn't think so. I only have problems when allocating. I don't think there's anything wrong with the CLAP api though since I basically completed my plugin idea in Odin without issues with this same process.
01:45:00FromDiscord<ElegantBeef> Well I'm blaming you, the bindings, and then the API in that order 😛
01:45:16*nanxiao joined #nim
01:45:33FromDiscord<Ayy Lmao> That's fair haha. I double checked my bindings and they seem right unless I'm really not catching something.
01:47:17FromDiscord<Ayy Lmao> I haven't extensively tested yet but I mean if everything works properly with `-d:useMalloc` that would mean it's a problem with Nim right?
01:48:14FromDiscord<ElegantBeef> Perhaps, but it could just be a problem with the API expecting something to be a certain way and failing. It's a shame I cannot run it cause it's sort of a braintrap for me
01:48:40FromDiscord<ricky> In reply to @Elegantbeef "Nimble is decentralised so": based
01:50:42FromDiscord<Ayy Lmao> In reply to @ElegantBeef "Perhaps, but it could": Unfortunately it's a bit complicated as it involves downloading either Bitwig or Reaper and using them in trial mode and having them finding the plugin and loading several instances on different tracks.
01:51:09FromDiscord<Ayy Lmao> And I'm not even sure it would work on Linux or even have the same problem.
01:51:12FromDiscord<ElegantBeef> Hence why i said shame 😄
01:51:43FromDiscord<Ayy Lmao> I appreciate the help and thought you've given so far though. Thank you.
02:26:08NimEventerNew Nimble package! physfs_static - Wrapper around physfs, see https://github.com/konsumer/nim-physfs_static
03:27:46*lucasta quit (Read error: Connection reset by peer)
04:16:31*ShadowSector joined #nim
04:16:36*ShadowSector quit (Remote host closed the connection)
04:23:21*nanxiao quit (Quit: Client closed)
05:56:35*advesperacit joined #nim
06:16:11*_________ quit (Quit: Reconnecting)
06:16:32*_________ joined #nim
06:23:27*PMunch joined #nim
06:28:24*nanxiao joined #nim
07:24:13NimEventerNew post on r/nim by Toma400: Weird experience with OOP, see https://reddit.com/r/nim/comments/13ojo0c/weird_experience_with_oop/
07:52:40*Notxor joined #nim
07:57:35*Notxor quit (Remote host closed the connection)
08:05:08*Notxor joined #nim
08:07:26*Notxor quit (Remote host closed the connection)
08:10:13*Notxor joined #nim
08:17:16*nanxiao quit (Quit: Client closed)
08:17:29*Notxor quit (Remote host closed the connection)
08:18:53*Notxor joined #nim
09:22:39*Notxor quit (Quit: Leaving)
09:24:21*Notxor joined #nim
10:05:19*antranigv quit (Quit: ZNC 1.8.2 - https://znc.in)
10:31:37*derpydoo quit (Read error: Connection reset by peer)
10:46:06FromDiscord<nu11pointer> Hi there folks! I am using nim in a project and I need the compilation to be done using `--app:console`, but using this flag spawns a console when I execute the compiled binary. Is there anything I can do in the source so the executable doesn't spawn the console?
10:46:43FromDiscord<nu11pointer> and another question, how can I set an icon on the executable?
10:49:46PMunchUhm, `--app:console` is how you tell the compiler that you want that console to appear. Why do you need it if you don't want the console to appear?
10:50:20PMunchThis should help with the icon issue: https://forum.nim-lang.org/t/1862
10:51:44FromDiscord<nu11pointer> well, i am developing a legitimate application but me defender is detecting it as something malicious when using `--app:gui`... when using `--app:console` it's not detected... since I want this application to be used by others, I don't want them do be whitelisting this app in the defender settings, of course
10:52:44PMunchHmm, which version of Nim are you using?
10:52:50FromDiscord<nu11pointer> latest
10:53:00PMunchDefender and friends are really annoying when it comes to this stuff
10:53:05PMunchWhat do you mean by latest?
10:53:39PMunchEven the Nim compiler is often tagged as a virus..
10:53:43FromDiscord<nu11pointer> sent a code paste, see https://play.nim-lang.org/#ix=4wqq
10:53:47FromDiscord<nu11pointer> In reply to @PMunch "Even the Nim compiler": how beautiful
10:53:56PMunchYeah..
10:54:52PMunchBasically they use way to few samples of proper Nim programs that Nim malware ends up just fingerprinting the "being written in Nim" part
10:55:20PMunchCould you try devel and see if it is tagged as malware with that as well?
10:55:26PMunchOr the v2.0 rc?
10:55:37FromDiscord<nu11pointer> wdym?
10:55:49PMunchDid you install Nim via choosenim?
10:55:52FromDiscord<nu11pointer> which tags should I use
10:56:01FromDiscord<nu11pointer> nope, downloaded from nim's website
10:56:15PMunch`choosenim \#version-2-0` I believe to switch to the 2.0rc
10:56:18PMunchAh..
10:56:36PMunchChoosenim allows you to easily switch between version
10:56:39PMunchversions*
10:57:00FromDiscord<nu11pointer> i see, like ruby and python have the same thing... should I download that?
10:57:16FromDiscord<nu11pointer> (edit) "ruby and python" => "ruby, node, python, etc."
10:57:19PMunchI always recommend using choosenim
10:58:08PMunchJust makes it easier to upgrade to a new version later on, and to test things on different versions
10:58:33FromDiscord<nu11pointer> defender is already picking up something with the choosenim installer xD
10:58:52PMunchHaha, yeah that would be another Nim binary
11:01:27PMunchIf you search the forum you will find other people with similar issues
11:01:55FromDiscord<nu11pointer> but it's strange, VT shows 0 detections (https://www.virustotal.com/gui/file/cca55bf01997a9f6c5c0556e2fa2ee4bc550c7058cbce4370518e17cf05c66b8)
11:02:18FromDiscord<nu11pointer> it's a dynamic behavior finding
11:02:24FromDiscord<nu11pointer> (edit) "finding" => "detection"
11:03:08PMunchYeah it's all up to the AV vendor
11:03:49FromDiscord<nu11pointer> i believe this can affect the nim reputation itself :/ ... needs to be patched
11:03:59PMunchJust use the --app:gui switch, using the --app:console switch to avoid AV detection is a brittle solution
11:06:39FromDiscord<nu11pointer> there are some bugs with the choosenim itself... it attempts to copy stuff from %Temp%\choosenim-dlls\\ but the folder wasn't even created O.o there's a choosenim-extraction only
11:06:58FromDiscord<nu11pointer> so, a lot of warnings appeared on the `choosenim devel --latest` command
11:07:10PMunchHmm, that's not great
11:07:11FromDiscord<nu11pointer> (edit) "itself..." => "itself I believe..."
11:07:18PMunchI have never used it on Windows myself
11:07:29PMunchOn Linux I've never had any issues with it
11:07:55FromDiscord<nu11pointer> sent a code paste, see https://play.nim-lang.org/#ix=4wqt
11:08:12FromDiscord<nu11pointer> crying
11:08:15FromDiscord<nu11pointer> (edit) "crying" => "\crying\"
11:09:16*Notxor quit (Read error: Connection reset by peer)
11:09:56PMunchIt can take a while, but shouldn't spend that long on the fetching step
11:10:17PMunchBut if you're building the compiler from scratch on a slow machine it might take a little while
11:11:01*Notxor joined #nim
11:27:05FromDiscord<demotomohiro> People using `-d:useMalloc` might be interested in this:↵https://samwho.dev/memory-allocation/
11:34:55FromDiscord<Rika> In reply to @nu11pointer "there are some bugs": liekly because defender removed them before it could do anything with them
11:58:46om3gaHello! Happy monday! (I know I know, mondays cant be happy days)
12:00:53om3gaI'm continuing to study GC, and found this procedure: GC_FullCollect(). As manual says, it should force garbage collection. But will it return previously allocated heap to the os? My tests say - no :)
12:03:40om3gabtw what is the reason that GC not returns previously taken portions of heap? This is due to speed/reuse? I tried to use deallocHeap(), of course it crashed my program, and manual free destroys GC
12:06:40om3gashould I ask for future request? I think it's strange that GC keeps that ram until the program will exit. Imagine situation, when some code should transform the data from 1TB file. I don't know how GC will act in this case, but all new() calls will hunt whole ram resources
12:09:49om3gaI modified other parts of my code to work with `ref seq[char]`, so GC not freed amount of ram raised, and counted as "Total Memory", the same number I see in `top` for the process.
12:15:51FromDiscord<nu11pointer> In reply to @demotomohiro "People using `-d:useMalloc` might": nah, didn't fix the problem
12:16:25FromDiscord<nu11pointer> oh, actually it did, it just spawned a notification from defender asking to send the suspicious file to microsoft xD
12:20:37Amun-Rasign the executable ;)
12:23:05arkanoiddo you know if there's a nim SOAP client or anything similar?
12:28:12PMuncharkanoid, can't find anything. Although "SOAP" was really annoying to Google for..
12:28:55arkanoidPMunch: I consider SOAP the worst interface ever built in history
12:29:15arkanoidand XML not far behind
12:29:21arkanoidthanks for the effort
12:29:44arkanoidsadly microsoft kinda liked it, and lots of stuff went SOAP way
12:29:44FromDiscord<chmod222> Well, SOAP is XML
12:30:58arkanoidexactly, but XML with all the features enabled. And the features are complex and contradictive
12:31:03PMunchMicrosoft likes anything that uses XML :P
12:37:55*xet7 joined #nim
12:39:58FromDiscord<nu11pointer> In reply to @PMunch "This should help with": can you help me here? didn't quite understand how to perform the operation, even after checking all the links in the page
12:40:07arkanoidPMunch: if you ever dived into XML, you would know how intricate the wannabe type system is, and how often it fails or leaves huge gaps in specification
12:40:41PMuncharkanoid, it's quite the mess indeed
12:41:22PMunchnu11pointer, which part has you stuck?
12:41:35PMunchNot sure I'm the best to help you out as I'm not on a Windows machine
12:42:10arkanoidPMunch: just consider that there's only one system-language soap library, and it's not BSD licensed https://en.wikipedia.org/wiki/List_of_web_service_frameworks
12:42:22FromDiscord<nu11pointer> i don't understand what I have to do... I believe I have to create a .rc to do it... but don't know how to use it
12:44:36PMunchIt explains that in the StackOverflow article doesn't it?
12:45:27PMunchYou run windres on the rc file to get a res file
12:45:50PMunchThen you include the res file while building. This might be the tricky part to tell the Nim compiler to do
12:47:47PMunchHmm, possibly just `--clib:my.res` or something similar
12:51:49FromDiscord<nu11pointer> sent a code paste, see https://play.nim-lang.org/#ix=4wqN
12:54:22FromDiscord<nu11pointer> In reply to @nu11pointer "nah, didn't fix the": well, now this isnt working anymore now 😐 got to nowhere now...
12:54:35FromDiscord<nu11pointer> (edit) "now" => "now, also"
13:00:00PMunchWell since I'm not on Windows it's a bit hard for me to debug further nu11pointer
13:02:42FromDiscord<nu11pointer> np... i'll try to work around
13:24:18FromDiscord<voidwalker> can you use openArray as a return type ? Or does that not make sense ? My understanding is that it's not a concrete type. I want to join the bits in two openArrays.
13:27:22FromDiscord<voidwalker> the procs that return openarray in nim are "magic" `proc toOpenArray[T](x: seq[T]; first, last: int): openArray[T] {.↵ magic: "Slice".}`
13:35:26FromDiscord<least antisemitic pole> the openArray return type might be behind some compiler flag, maybe
13:35:34FromDiscord<least antisemitic pole> I'm sure it's implemented somehow
13:40:30NimEventerNew post on r/nim by qtless: Best Web Framework Features?, see https://reddit.com/r/nim/comments/13or877/best_web_framework_features/
13:41:37arkanoidPMunch: I remember you made an MCU project for keyboards or something. I've just started learning some microcontroller programming, I would be happe to read about your work. Would you remind me the name of the project, and if possible a link where I can read about it?
13:42:12PMunchThe project is called Ratel and can be found at ratel.peterme.net
13:42:19PMunchAnd on my GitHub of course
13:42:34arkanoidthanks!
13:44:47PMunchNo problem
13:44:56NimEventerNew thread by hachem: Webui search form ,nim, see https://forum.nim-lang.org/t/10216
13:44:56arkanoidPMunch: are you aware for any Ratel + ESP32 project?
13:45:44PMunchI know someone over in the #nim-embedded channel were talking about it. Not sure if anything ever came of it though
13:47:24arkanoidPMunch: thanks again. I'll take a look at the Arduino board implementation
13:52:10*xaltsc quit (Quit: WeeChat 3.8)
13:52:18*advesperacit quit ()
14:08:23*PMunch quit (Quit: Leaving)
14:09:32*progranner joined #nim
14:21:14FromDiscord<Nerve> I have two main sources in my application (one is CLI-only, one invokes a browser frontend). The compilation commands look very much the same, but for one of them, the compiler is build the executable with a `.out` extension. The only thing that's changed since the last time I compiled is a new `gcc` version on Linux Mint. Any ideas why this is?
14:21:25FromDiscord<Nerve> (edit) "sources" => "source files"
14:24:52*progranner quit (Quit: My Mac has gone to sleep. ZZZzzz…)
14:25:29FromDiscord<kots> that happens for me when I have a directory with the same name next to the executable
14:25:52FromDiscord<Nerve> Bingo, okay
14:28:46*progranner joined #nim
14:44:29FromDiscord<nu11pointer> sent a code paste, see https://play.nim-lang.org/#ix=4wrd
14:45:04FromDiscord<nu11pointer> (edit) "https://play.nim-lang.org/#ix=4wrd" => "https://play.nim-lang.org/#ix=4wre"
14:45:24FromDiscord<nu11pointer> do you actually know how to append to gcc from the nim compiler? it would be useful
15:02:47*progranner quit (Quit: My Mac has gone to sleep. ZZZzzz…)
15:03:02FromDiscord<voidwalker> sent a code paste, see https://play.nim-lang.org/#ix=4wrn
15:04:00FromDiscord<voidwalker> `cannot instantiate: 'joinbits[uint8]'; got 1 typeof(s) but expected 3` I need to joinbits[uint8,uint8,uint8..] for this to compile. Why doesn't it detect the types of the arrays ?
15:07:23FromDiscord<Solitude> In reply to @voidwalker "`cannot instantiate: 'joinbits[uint8]'; got": move the generic you have to specify as typedesc parameter↵`proc joinbits[A,B,C](a: openArray[A], b:openArray[B], c: typedesc[C], aLen, bLen: int): seq[C] = discard`↵`let z = joinbits(x,y,uint8,5,12)`
15:09:32*progranner joined #nim
15:09:33FromDiscord<voidwalker> that works indeed. But why is this needed ?
15:12:23FromDiscord<Solitude> you either specify all generic parameters or none.
15:17:32FromDiscord<voidwalker> hm that makes sense, otherwise it could be ambiguous
15:18:37FromDiscord<ieltan> Hello, is there perhaps a macro to extract the arguments of a closure?
15:18:39FromDiscord<voidwalker> but it's still not clear to me how C gets resolved by `t: typedesc[C]`
15:23:12FromDiscord<Solitude> In reply to @voidwalker "but it's still not": `let z = joinbits(x,y,-->uint8<--,5,12)`↵you specify it yourself
15:24:00FromDiscord<voidwalker> yeah I noticed that, I am just confused by the syntax
15:25:19FromDiscord<voidwalker> if t is of type typedesc[C], that means it holds the typedesc of the C generic parameter, so by passing it, the compiler can reason that C is t
15:41:55FromDiscord<Anton i guess> game
15:48:34*progranner quit (Quit: My Mac has gone to sleep. ZZZzzz…)
15:55:07*progranner joined #nim
15:58:25*progranner quit (Client Quit)
16:00:20*progranner joined #nim
16:32:10*progranner quit (Quit: My Mac has gone to sleep. ZZZzzz…)
16:36:12*progranner joined #nim
17:07:48*rockcavera joined #nim
17:24:43*xet7 quit (Quit: Leaving)
17:35:46*progranner quit (Quit: My Mac has gone to sleep. ZZZzzz…)
17:45:58FromDiscord<sOkam!> sent a code paste, see https://play.nim-lang.org/#ix=4wsc
17:47:55FromDiscord<Solitude> sent a code paste, see https://play.nim-lang.org/#ix=4wsd
17:52:55*arkurious joined #nim
18:31:53NimEventerNew thread by arik: Nimble Directory reroutes me to distrobadges, see https://forum.nim-lang.org/t/10217
18:39:49*ntat joined #nim
18:45:01ntatHi. Is it possible to take a screenshot (capture an image into a variable) in Nim? Maybe with some module?
18:47:57FromDiscord<chmod222> Can I call a `proc foo(x: ref T)` if all I have is a `T`, without having to go through the overhead of copying my T to a new ref only to call it?
18:48:28FromDiscord<chmod222> Reason being, `=destructor` only operates on non-refs and all my methods operate by necessity on `ref`, but the destructor has to call one of these methods
19:04:20FromDiscord<demotomohiro> sent a code paste, see https://play.nim-lang.org/#ix=4wsF
19:19:25FromDiscord<chmod222> Thinking of it, it would be less overhead and more infinite loop
19:21:08FromDiscord<Elegantbeef> You can make your ref a distinct and that is allowed a destructor
19:21:26FromDiscord<chmod222> fg
19:21:35FromDiscord<chmod222> Let's test that one
19:21:57*progranner joined #nim
19:24:16FromDiscord<chmod222> Doesn't seem to work for me
19:24:26FromDiscord<chmod222> ah wait, wrong error
19:25:19FromDiscord<Elegantbeef> Just for reference
19:25:21FromDiscord<demotomohiro> In reply to @Elegantbeef "You can make your": Then, if there are 3 refs that points to one object, destructor is called for each refs?
19:25:22FromDiscord<Elegantbeef> sent a code paste, see https://paste.rs/dRSqy
19:26:42FromDiscord<Elegantbeef> Correct it gives it value semantics
19:26:48FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4wsP
19:27:03FromDiscord<chmod222> But it breaks dynamic dispatch apparently
19:27:14FromDiscord<Elegantbeef> It calls the destructor 3 times, but only deallocates the ref once
19:27:37FromDiscord<Elegantbeef> Well really one should do `=destroy((ref int)(r)` inside the destructor
19:27:59FromDiscord<chmod222> I just wish this API wasn't such a god damn OOP nightmare
19:28:06FromDiscord<chmod222> The one I'm trying to bind, that is
19:28:21FromDiscord<chmod222> I've been fighting with cyclic dependencies and all manner of nonsense and now this
19:28:39FromDiscord<Elegantbeef> This is godot?
19:28:41FromDiscord<Mr X> ji
19:28:42FromDiscord<Mr X> hi
19:28:51FromDiscord<chmod222> It is Godot, yes
19:29:18FromDiscord<Mr X> I kinda like the name and the way nim is written, where do I learn it in depth? coming from python user
19:29:20FromDiscord<jmgomez> That was a nightmare for NUE bindings too. As how it's done one module can depend on another
19:29:42FromDiscord<chmod222> I need some core classes to bind the core classes so the core classes need themselves and then half the classes need `RefCounted` but I cannot use `RefCounted` to manage the reference counts because I'm currently defining `RefCounted`
19:29:44FromDiscord<Mr X> it seems like there is limited help for beginners for it
19:29:46FromDiscord<jmgomez> And then a third on the first.. and so on to the infinity
19:29:46FromDiscord<chmod222> It's vexing
19:30:11FromDiscord<Elegantbeef> How is godot's ref count defined?
19:30:22FromDiscord<chmod222> My bindgen does some dependency resolution so most of it works, but if stuff needs itself, it gets hairy
19:30:23FromDiscord<Mr X> why are bots talking to each other lmao
19:30:44FromDiscord<chmod222> no idea, it's an opaque class where I get "reference", "unreference" and "get\_reference\_count" methods
19:30:45FromDiscord<Elegantbeef> Cause we're sentient
19:30:45FromDiscord<Elegantbeef> AGI here first
19:30:49FromDiscord<chmod222> But I cannot use them where I need to use them
19:31:02FromDiscord<huantian> yeah it's a private beta of gpt 69
19:31:08FromDiscord<Elegantbeef> Nice
19:31:24FromDiscord<chmod222> There's probably a way to make this all work semi reliable, but it's not a fun experience
19:31:34FromDiscord<chmod222> It was all fun and games until this part \:)
19:31:37FromDiscord<Elegantbeef> So you have your ptr objects which internally have a ref count
19:31:48FromDiscord<chmod222> Some of them do, some don't, yes
19:32:28FromDiscord<jmgomez> Can you showcase an example?
19:32:41FromDiscord<huantian> In reply to @Mr X "it seems like there": but yeah the documentation and tutorials are less abundant compared to python
19:32:47FromDiscord<huantian> i'd start with the tutorials in the docs
19:33:40FromDiscord<demotomohiro> In reply to @Mr X "it seems like there": https://ssalewski.de/nimprogramming.html
19:35:32FromDiscord<chmod222> sent a code paste, see https://play.nim-lang.org/#ix=4wsR
19:35:44FromDiscord<chmod222> So it's a ref parameter, otherwise dynamic dispatch wouldn't work
19:35:47FromDiscord<demotomohiro> sent a long message, see http://ix.io/4wsS
19:36:18FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4wsT
19:36:38FromDiscord<chmod222> The issue is that Godot wants to manage the reference count as well, so I cannot freely define my own
19:36:50FromDiscord<chmod222> I have to work within that framework
19:36:51FromDiscord<Elegantbeef> I mean you shouldnt use ref for the godot allocated objects
19:36:55FromDiscord<Elegantbeef> it should be a `ptr object`
19:36:55FromDiscord<jmgomez> In reply to @chmod222 "So it's a ref": Not the case if you use the Cpp backend
19:37:09FromDiscord<chmod222> The refs just carry a naked pointer
19:37:16FromDiscord<Elegantbeef> Juan... we're interfacing with C↵(@jmgomez)
19:37:22FromDiscord<Elegantbeef> Or a CAPI
19:37:35FromDiscord<chmod222> I just use them for dyamic dispatch and to get GC semantics
19:37:54FromDiscord<chmod222> I'd use naked `object` without Ref, but then I don't get dispatches
19:38:09FromDiscord<Elegantbeef> Do you even need dynamic dispatch
19:38:21FromDiscord<Elegantbeef> I don't think godot3.0 bindings used inheritance
19:38:24FromDiscord<Elegantbeef> I know they're different apis
19:38:31FromDiscord<Elegantbeef> But i assume they're the same
19:38:42FromDiscord<Elegantbeef> Where you bind a procedure by name for a type
19:38:42FromDiscord<chmod222> I don't see how I could do without, one usually wants `mySpecificObj.methodDefinedInParent()` to work
19:38:55FromDiscord<Elegantbeef> you do not need `ref` for that
19:38:58FromDiscord<chmod222> Of course I could duplicate the entire thing, I'm generating code after all
19:39:09FromDiscord<jmgomez> What Im trying to say, is that doing this in C sounds harder of what it needs to be but whatever, not my project so I will save commenting
19:39:32FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4wsW
19:39:39FromDiscord<Elegantbeef> Well juan this is the proper way to interface with godot
19:40:05FromDiscord<chmod222> The other issue is, if I generate naked objects, only the highest level `=destroy(x: var Object)` is called, even if it's a RefObject
19:40:06FromDiscord<Elegantbeef> This is using gdextensions, not hooking into the unstable engine code
19:40:17FromDiscord<chmod222> I'd much prefer naked objects to be honest
19:40:39FromDiscord<Elegantbeef> If you implement your own `=destroy` you have to call `=destroy` on all fields
19:40:49FromDiscord<jmgomez> So GDScript is 100% that?
19:40:59FromDiscord<chmod222> That's fine, there is only one field and it's a pointer
19:41:13FromDiscord<chmod222> I just want the correct =destroy called really
19:41:15FromDiscord<Elegantbeef> GDScript is practiically a highlevel API ontop of gdextensions↵(@jmgomez)
19:41:21FromDiscord<chmod222> Everything else is doable
19:41:43FromDiscord<chmod222> And the correct =destroy somehow only gets called with `ref object`, not `object`
19:42:11FromDiscord<Elegantbeef> It's hard to offer help given I do not fully see the problem
19:42:24FromDiscord<jmgomez> I dont know, this looks bindable to me https://docs.godotengine.org/en/stable/tutorials/scripting/gdextension/gdextension_cpp_example.html
19:42:27FromDiscord<chmod222> It's hard to describe as well, because it's a lot of stuff that's compounding the issue
19:42:54FromDiscord<chmod222> All my code is on https://github.com/chmod222/nodot/, but that's quite a lot to dig into as well
19:43:37FromDiscord<Mr X> thanks guys, time to have fun with it
19:44:00FromDiscord<chmod222> The issue is really two issues. If I generate my classes as `ref object`, I get the correct `=destroy` to invoke, but I cannot call methods like `get_reference_count`. If I generate them as `object` only, I could call `get_reference_count` but I cannot get to the correct `=destroy`
19:44:05FromDiscord<chmod222> Shortest way I can put it
19:44:32FromDiscord<chmod222> Maybe I need another concept entirely
19:46:25FromDiscord<jmgomez> You literally only need to copy what the C++ extension is doing
19:46:52FromDiscord<chmod222> I've been trying to decipher exactly what it is doing, but it's a whole bunch of macro nonsense that makes my head hurt
19:47:04FromDiscord<jmgomez> So you bind the macros?
19:47:26FromDiscord<chmod222> Bind macros that generate incomplete C++ AST to splice into Nim?
19:47:28FromDiscord<chmod222> Sounds fun
19:47:38FromDiscord<jmgomez> And use them ad hoc in Nim until you figure them out
19:47:45FromDiscord<jmgomez> WHAT?
19:47:52FromDiscord<jmgomez> you can just call them
19:48:26FromDiscord<chmod222> But they don't generate code that makes sense unless you are godot\_cpp
19:48:46FromDiscord<chmod222> Why would I call macros that generate incomplete class bodies
19:49:02FromDiscord<chmod222> I could do it easily if I liked compiler error messages
19:49:04FromDiscord<chmod222> The point is that I do not
19:49:36FromDiscord<jmgomez> Okay, then reinvent the wheel as you like it to be 🙂
19:49:45FromDiscord<chmod222> https://github.com/godotengine/godot-cpp/blob/master/include/godot_cpp/classes/wrapped.hpp#L309
19:49:50FromDiscord<chmod222> How do you meaningfully integrate this
19:50:09FromDiscord<chmod222> It makes no sense
19:50:23FromDiscord<chmod222> I'm working in a C based backend
19:51:32FromDiscord<Elegantbeef> It's arguably not reinventing the wheel but doing things the way the developers intended 😄
19:51:50FromDiscord<chmod222> If only the developers had documentation that is not a hunk of C++ code
19:52:00FromDiscord<jmgomez> sent a code paste, see https://play.nim-lang.org/#ix=4wt3
19:52:35FromDiscord<Elegantbeef> Wait refcount increment and decrement are pointer procs?
19:52:42FromDiscord<chmod222> Yeah
19:52:51FromDiscord<chmod222> They are not exposed in the friendly API
19:53:25FromDiscord<jmgomez> If you bind directly Sprite2D you can just do `type GDExample = object of Sprite2d` in Nim.
19:53:41FromDiscord<Elegantbeef> Ah i thought it was pluggable
19:53:41FromDiscord<Elegantbeef> It seems not shame
19:53:58FromDiscord<chmod222> I can work around that by `import ../../refcounted` just above the =destruct for `RefCounted` and the cyclic deps work out luckily
19:54:14FromDiscord<chmod222> But still, wrong =destruct is called for now
19:54:25FromDiscord<Elegantbeef> You can do the same if you just bind it in C using procs for any Sprite2D functions↵(@jmgomez)
19:54:46FromDiscord<chmod222> I mean yeah, binding godot\_cpp is arguable easier and saves a bunch of boilerplate such as this
19:54:55FromDiscord<chmod222> But I don't want to bind godot\_cpp, I want to bind GDExtension
19:55:19FromDiscord<jmgomez> In reply to @Elegantbeef "You can do the": I know but it's more work
19:55:32FromDiscord<jmgomez> You can do everything in ASM too
19:55:44FromDiscord<chmod222> Probably easier than dealing with C++
19:55:45FromDiscord<Elegantbeef> Ok so you're being reductionist
19:56:16FromDiscord<Elegantbeef> You can also do the same with steady hands and a magnet
19:56:28FromDiscord<jmgomez> In reply to @chmod222 "Probably easier than dealing": Not sure why "dealing" with C++ is a problem. Nim has probably one (or second) best interop in the whole industry
19:56:52FromDiscord<Elegantbeef> anyway chmod i'm too dense to understand the problem from words, and i'll shush
19:56:53FromDiscord<chmod222> I know, but it's still C++ which is probably the most annoying language in the whole industry
19:56:58*lucasta joined #nim
19:57:32FromDiscord<chmod222> I've spent years with it and that's enough for one life
19:57:53FromDiscord<jmgomez> Okay, I get that you dont like it
19:59:01FromDiscord<chmod222> Another maybe more practical reason not to do it that way is because that way, the complexity moves from the binding code into the ridiculous build system
19:59:02FromDiscord<huantian> tldr binding for both c and c++ has pros and cons like everything in life 😛
19:59:14FromDiscord<chmod222> cmake makes me cry
19:59:26FromDiscord<chmod222> Not ashamed to say so
19:59:40FromDiscord<chmod222> They are manly tears of cold and salty hatred
20:02:54FromDiscord<huantian> I don't know if this is expected behavior?
20:03:17FromDiscord<chmod222> It just might be, that's entirely possible
20:03:17FromDiscord<huantian> =destroy wouldn't be dynamically dispatched though
20:03:27FromDiscord<huantian> That would be my assumption?
20:04:22FromDiscord<chmod222> Well, it can be statically determined in my test case so it could at compile time determine that one =destroy is more specific than the other and call that
20:04:30FromDiscord<chmod222> In fact, this seems to happen in my minimal testcase
20:04:42FromDiscord<chmod222> No idea why it's not happening in my proper code
20:11:38*antranigv joined #nim
20:15:23NimEventerNew thread by xigoi: “NIM” backronyms, see https://forum.nim-lang.org/t/10218
20:26:53*ntat quit (Quit: Leaving)
20:46:28*progranner quit (Quit: My Mac has gone to sleep. ZZZzzz…)
20:48:47*antranigv quit (Ping timeout: 240 seconds)
20:52:12*progranner joined #nim
20:53:00*antranigv joined #nim
20:54:16*xet7 joined #nim
21:09:02*pharonix71 quit (Remote host closed the connection)
21:09:09*Notxor quit (Remote host closed the connection)
21:09:48*pharonix71 joined #nim
21:19:25*antranigv quit (Ping timeout: 240 seconds)
21:20:51*progranner quit (Quit: My Mac has gone to sleep. ZZZzzz…)
21:41:23*progranner joined #nim
21:43:30FromDiscord<Chronos [She/Her]> In reply to @huantian "=destroy wouldn't be dynamically": Maybe the destructor needs to be exported? Idk
21:46:15FromDiscord<chmod222> I think nim just recognizes it when it sees it, since it's an internal function, but it was exported
21:46:44FromDiscord<chmod222> I've managed to solve the issue though, it was a macro gone rogue that generated bad code apparently
21:47:20FromDiscord<chmod222> Well, it generated good code that did the wrong thing, I don't want to disparage the compiler
21:52:17*antranigv joined #nim
22:07:25*antranigv quit (Ping timeout: 240 seconds)
22:11:40FromDiscord<Elegantbeef> Destructors are type bound operations↵(@Chronos [She/Her])
22:11:42FromDiscord<Elegantbeef> They bind to the type
22:11:53FromDiscord<Elegantbeef> Hence why they need to be declared at first usage before any code uses the type
22:12:05FromDiscord<Chronos [She/Her]> Ah alright then, good to know
22:14:12*antranigv joined #nim
22:20:26*progranner quit (Quit: My Mac has gone to sleep. ZZZzzz…)
23:07:11*xet7 quit (Quit: Leaving)
23:13:37FromDiscord<inv> Who still uses IRC client ?
23:13:50FromDiscord<Elegantbeef> A few people, but not many
23:14:13FromDiscord<inv> ok, discord then, but I like telegram more 🙂
23:14:28FromDiscord<Elegantbeef> Just use matrix 😛
23:15:35FromDiscord<inv> I have a question: how wasMoved works?↵↵I see that it zeroed mem - it is clear ... and "to signify it was "moved" and to signify its destructor"
23:15:44FromDiscord<inv> (edit) "I have a question: how wasMoved works?↵↵I see that it zeroed mem - it is clear ... and "to signify it was "moved" and to signify its destructor" ... " added "- it is unclear"
23:15:58FromDiscord<inv> how is it possible to signify by just zeroing ?
23:16:02FromDiscord<Elegantbeef> It shouldnt zero memory afaik
23:17:05FromDiscord<Elegantbeef> I guess it does
23:17:16FromDiscord<inv> > Resets an object obj to its initial (binary zero) value to signify it was "moved" and to signify its destructor should do nothing and ideally be optimized away
23:17:27FromDiscord<Elegantbeef> It doesnt zero to signify
23:17:40FromDiscord<Elegantbeef> It's compiler magic, if something was moved you do not use a destructor
23:18:12*antranigv quit (Ping timeout: 264 seconds)
23:18:23FromDiscord<inv> yep, so it is for some kind of static check probably, but was confused with the "zero to signify"
23:18:25FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4wtK
23:18:26FromDiscord<Elegantbeef> We leak memory here
23:18:33FromDiscord<Elegantbeef> well reread it
23:18:56FromDiscord<Elegantbeef> I guess it's ambiguous
23:19:06FromDiscord<Elegantbeef> Should be a comma after value
23:19:15FromDiscord<inv> ah!
23:19:41FromDiscord<Elegantbeef> And if you're of the oxford comma predisposition one should be after '"moved"'
23:20:23FromDiscord<inv> yep, pretty like in my native language
23:21:06FromDiscord<inv> another question: should I rear it like "wasMoved from" ? looks like - just wants to be sure
23:21:54FromDiscord<inv> (edit) ""wasMoved from"" => ""wasMoved(x) - was moved _into_ x""
23:22:12FromDiscord<Elegantbeef> `x.wasMoved(0`
23:22:16FromDiscord<inv> (edit) "rear" => "read"
23:22:26FromDiscord<Elegantbeef> you're telling the RAII system that `x` is no longer the owner of memory
23:24:06FromDiscord<inv> If I check `=copy(a: var T, b: T)` then I see `=destroy(a)` and `wasMoved(a)`
23:24:29FromDiscord<inv> why do we need wasMoved(a) after is was freed already ?
23:24:42FromDiscord<Elegantbeef> It disarms a destructor
23:24:46FromDiscord<Elegantbeef> Also what nim version are you using?
23:24:56FromDiscord<inv> I am just reading mastering nim
23:25:31FromDiscord<inv> I think it is the same here: https://nim-lang.org/docs/destructors.html
23:25:33*antranigv joined #nim
23:26:37FromDiscord<inv> hm, probably - why destroy does not do wasMoved by itself?
23:26:46FromDiscord<inv> (edit) "destroy" => "`=destroy`"
23:27:35FromDiscord<inv> isn't it unclear what destructor should not be triggered after `destroy?
23:27:41FromDiscord<inv> (edit) "`destroy?" => "the `=destroy`?"
23:27:55FromDiscord<inv> sorry if too many questions
23:28:47FromDiscord<Elegantbeef> I do not think the `wasMoved` is needed inside that operation
23:35:18FromDiscord<inv> I am not sure I am right. But looks like wasMoved could be in destroy, but it is moved outside, probably just for some kind of optimization - because it could be, but not necessary
23:35:23FromDiscord<inv> (edit) "be," => "be inside,"
23:36:01FromDiscord<Elegantbeef> Well you can disarm destructors for if you give memory over to a different thread or library
23:36:03FromDiscord<inv> I cannot find an example when wasMoved is not ok after destroy
23:36:27FromDiscord<Elegantbeef> I do not know ask in #internals
23:36:53FromDiscord<inv> different thread - thank you - looks like it explains
23:39:19FromDiscord<inv> How to force `=sync` to work ? https://media.discordapp.net/attachments/371759389889003532/1110351213876236329/image.png
23:39:36FromDiscord<Elegantbeef> it's not called `=sync`
23:39:37FromDiscord<inv> (edit) "How" => "One more: how" | "One more: howto force `=sync` to work ? ... https://media.discordapp.net/attachments/371759389889003532/1110351213876236329/image.png" added "the sink T does not force it"
23:39:55FromDiscord<inv> oh, brr, thx 🙂
23:41:03FromDiscord<inv> =sink did not help too 😦
23:44:24FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4wtR
23:44:58FromDiscord<inv> =copy with error shows that it is not last https://media.discordapp.net/attachments/371759389889003532/1110352633908166666/image.png
23:45:33FromDiscord<Elegantbeef> You really should paste code
23:45:37FromDiscord<Elegantbeef> Instead of pasting images
23:46:42FromDiscord<inv> sorry, have to fix the WSL2 terminal
23:48:31FromDiscord<JJ> uh, so, question about `sink` and `let`: i'm reading up on them a bit more and am confused. if `sink` doesn't necessarily mean a parameter is consumed why is every parameter not `sink`? and why are `view` types sometimes mutable, when they are composed of either `openarray[T]` (immutable) or `lent T` (immutable)?
23:49:11FromDiscord<Elegantbeef> `--sinkInference` exists
23:49:39FromDiscord<inv> I thought that nim tries to predict sink and it is just helper
23:49:45FromDiscord<Elegantbeef> Views mutability depends on the declaration
23:49:51FromDiscord<inv> (edit) "helper" => "helper, but not directive"
23:50:01FromDiscord<Elegantbeef> There is sink inference, but it can wreak havoc on proc types
23:50:28FromDiscord<JJ> well sure but that doesn't really answer my question, if you annotate a parameter with `sink` and it doesn't have to be consumed i don't see how the explicit annotation is helpful
23:50:44FromDiscord<Elegantbeef> Uhh
23:50:56FromDiscord<Elegantbeef> The ownership is given up at `sink`
23:51:10FromDiscord<JJ> In reply to @Elegantbeef "Views mutability depends on": also right but aren't the declarations always immutable if it's just `openarray` and `lent T`
23:51:12FromDiscord<Elegantbeef> Whether it's moved and actually sank or destroyed is an optimisation that procedure can decide on
23:51:13FromDiscord<JJ> hmm
23:52:12FromDiscord<JJ> oh, i see, that makes sense
23:53:07FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4wtS
23:53:17FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4wtT
23:54:04FromDiscord<JJ> i still don't understand the case in which a view type can be mutable i think
23:54:20FromDiscord<JJ> is it like if it's an object where one of the fields is `lent T` but the others are ordinary?
23:54:33FromDiscord<inv> why sinkit(a: var MyType, b: sink MyType) is sink, but sinkit(b: sink MyType) : MyType = result = b - is not ?
23:54:34FromDiscord<Elegantbeef> `var a: var T = somePathExpr`
23:54:49FromDiscord<inv> (edit) "sinkit(a:" => "`sinkit(a:" | "`sinkit(a:var MyType, b: sink MyType) ... `sinkit(b:" added "= a = b`" | "sinkit(b:" => "`sinkit(b:" | "b" => "b`"
23:54:53FromDiscord<Elegantbeef> It calls sink cause it's consumed
23:54:58FromDiscord<Elegantbeef> It's optimised out in the other