<< 10-08-2019 >>
00:01:34*Vladar quit (Remote host closed the connection)
00:21:13FromDiscord_<bevo> @Kiloneie you have quite a few videos on your youtube chan
00:21:13FromDiscord_<bevo> I'll watch your Nim ones if they're post-beginner to intermediatte
00:22:53*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:24:54*laaron quit (Remote host closed the connection)
00:27:34*laaron joined #nim
00:27:51*rayman22201 quit (Quit: Connection closed for inactivity)
01:03:27*ng0_ joined #nim
01:06:12*ng0 quit (Ping timeout: 260 seconds)
01:07:49*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
01:09:32*laaron joined #nim
01:16:47*stefanos82 quit (Quit: Quitting for now...)
01:24:14*ng0_ quit (Quit: Alexa, when is the end of world?)
02:01:30FromDiscord_<treeform> I use Nim in production. It's great. It's faster python that prevents typos.
02:01:51FromDiscord_<treeform> The only issues I had are with openssl.
02:02:01FromDiscord_<treeform> But I had those with python too
02:02:08FromDiscord_<treeform> I hate ssl
02:02:58FromDiscord_<treeform> Lack of libs has not stopped me. I like writing my low level libs
02:03:52FromDiscord_<treeform> @slymilano do you have something sepesific?
02:10:16*noeontheend joined #nim
02:11:09*noeontheend quit (Remote host closed the connection)
02:35:33FromGitter<awr1> "prevents typos" i chuckled
02:37:10*rayman22201 joined #nim
02:49:55*dddddd quit (Remote host closed the connection)
02:54:24*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
02:55:15*laaron joined #nim
03:02:07*lritter quit (Ping timeout: 245 seconds)
03:03:06*lritter joined #nim
03:17:19FromDiscord_<Shield> I'm not sure if I understand correctly, but I thought strings were copied by value, I'm using gc:regions, I have an object A that holds a string, I used withScratchRegion to create object B with a different string, then I used A = B to see what happens
03:18:35FromDiscord_<Shield> withScratchRegion should deallocate the temporary memregion, so I expected that the string in A would be deep copied, but when I check the address of the string in both A and B, they're the same, why is that?
03:24:07*nif quit (Quit: ...)
03:24:16*nif_ joined #nim
03:27:13*nif_ quit (Client Quit)
03:27:21*nif joined #nim
03:28:27*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
03:28:52*laaron joined #nim
03:31:18FromDiscord_<Shield> http://ix.io/1Rbo
03:33:31leorize[m]you only copied the reference to an Entity object
03:33:48leorize[m]ofc it would point to the same address, hence the same string
03:36:01FromDiscord_<Shield> it's not that, I expected the string to exist in the scratch region, then get deallocated at the end of the block
03:37:08leorize[m]deallocation never means override that region with zeros :p
03:40:03leorize[m]as long as the memory region is unused it should still be accessible
03:42:29FromDiscord_<Shield> oh wow, it's not returning memory to the system
03:44:45*aq60 quit (Remote host closed the connection)
03:45:09rayman22201I think if you use -d:useMalloc it will. But I could be remembering incorrectly.
03:46:22rayman22201Nim doesn't like to give memory back to the OS. It might need that memory again 😛
03:52:00FromDiscord_<Shield> using useMalloc doesn't change a thing, while allocating manually and deallocating does give back memory
03:58:06FromDiscord_<Shield> I think there's a difference between c_malloc and emalloc in the gc file if useMalloc isn't freeing memory
03:58:24FromDiscord_<Shield> whelp, back to manual memory management
03:58:28*laaron quit (Remote host closed the connection)
04:00:29*laaron joined #nim
04:04:07FromGitter<bevo009> @leorize[m] ⏎ I installed your nvim plugin on wsl and got some strange behaviour ⏎ I tested it in Vimter on vscode(which utilizes nvim) and also nvim on Cmder ⏎ It's hiding lines and blocks like below ⏎ I have to jump to the next line and hit b, then they display ... [https://gitter.im/nim-lang/Nim?at=5d4e42371dadc42a1143920a]
04:13:06rayman22201@Shield why not newruntime?
04:19:00FromDiscord_<Shield> I'm still confused about newruntime, things said in the blog posts end up different from what people are discussing
04:19:15FromDiscord_<Shield> I think the comment on gc:regions was misleading
04:21:02rayman22201Which comment?
04:21:37FromDiscord_<Shield> "# "Stack GC" for embedded devices or ultra performance requirements."
04:22:27rayman22201That's correct. And it has been used for that exact purpose
04:24:30leorize[m]@bevo009 it's code folding
04:24:45rayman22201Not giving memory back to the OS is a performance optimization. Getting memory from the OS is slow. It's a trade-off between higher memory footprint and speed.
04:26:06leorize[m]@bevo009 see `:h fold` (iirc) for details on how to work with it
04:26:46FromGitter<bevo009> is there a line I can put in my init.nvim to disable that?
04:26:56leorize[m]if you dislike auto code folding, `:set nofoldenable` should do
04:29:00FromDiscord_<Shield> the problem with not releasing memory back to the system, is that if you allocate really fast, it will never reuse memory and will end up consuming the whole memory and holding it, unless you enforce a full collect after every use, which can still get out of hand, gc:regions suffers from the same fate
04:29:00FromDiscord_<Shield> this is relevant for servers with small memory, if you have too many connections or serve big files, there's no way to get that memory back without killing the program or killing the thread (I didn't confirm this yet)
04:30:06FromGitter<bevo009> I actually was going to ask if that was a code-folding feature, but I couldn't find an obvious way to toggle it
04:30:18FromGitter<bevo009> Thanks, that line worked perfect :)
04:30:50rayman22201Gc:regions specifically gives control over reusing memory. Don't use a scratch region. Explicitly make one and reuse it.
04:33:43leorize[m]@Shield: deallocAll(MemRegion) will free a region
04:35:06FromDiscord_<Shield> the scratch region was a test, the problem still persists, the server for example will use memory enough to for the ongoing connections, so one spike in traffic leads to the program keeping that memory until you restart it
04:35:39leorize[m]weird, withScratchRegion should have freed the region
04:36:30FromDiscord_<Shield> there's a lot of string generation and copying, so reaching the memory cap isn't implausible
04:36:59rayman22201It's possible that it was freed and the memory just happened to not be overwritten yet.
04:37:14leorize[m]hmm, how did you know that withScratchRegion didn't release the memory?
04:37:57FromDiscord_<Shield> it doesn't release it to the system, as rayman22201 said, Nim refuses to give it back to the system
04:38:18FromDiscord_<Shield> otherwise I'd get a sigfault with that example
04:38:22leorize[m]it does according to the code for it
04:38:32leorize[m]oh, segfault if not guaranteed
04:38:36leorize[m]is*
04:38:51rayman22201You would not necessarily get a segfault. Exactly
04:39:01leorize[m]a fair share of use-after-free survived for a reason
04:39:22rayman22201leorize[m] knows more about the impl than I do.
04:39:35FromDiscord_<Shield> you should check osalloc.nim to get the full picture
04:40:07FromDiscord_<Shield> deallocAll doesn't give memory to the system, it frees it for the program itself
04:40:35leorize[m]use -d:useMalloc
04:40:38leorize[m]that'll do
04:41:13FromDiscord_<Shield> I tried, it doesn't for some reason
04:41:35leorize[m]although at one point someone should try to make the gc release the memory to the os
04:41:39rayman22201I think that is a bug actually. -d:usemalloc should work
04:42:12leorize[m]@Shield segfault is not a good indicator
04:43:32FromDiscord_<Shield> I wish you can use gc:regions with the normal gc, as a good middle ground to manual MM, sometimes you want to nuke a whole page of memory and be sure that it's released to the os
04:43:55rayman22201A better indicator is strace to see the matching alloc and free calls
04:44:00FromDiscord_<Shield> I see the general memory use of the program not just segfault
04:44:06FromGitter<bevo009> @leorize[m] ⏎ Sorry to bug you again ⏎ I get this line in the console whenever I exit nvim: ⏎ nimsuggest instance for project: `/c/a/nim/01/' exited with exitcode: 0 ⏎ Can I make that silent somehow? ... [https://gitter.im/nim-lang/Nim?at=5d4e4b959507182477b0cdd6]
04:45:00leorize[m]it'd require some work from me, but is it that annoying?
04:45:14FromGitter<bevo009> Well, not if it requires work
04:45:32FromGitter<bevo009> I thought there might be a verbosity line there
04:45:39leorize[m]well "work" = one conditional to hide it :p
04:47:20rayman22201@Shield your point about not freeing memory back to the OS is a good one. It has been brought up before. Nim takes a very greedy approach in general.
04:47:45leorize[m]@Shield weird, can you try modifying gc_regions.nim to hook onto osDeallocPages in the useMalloc branch?
04:48:40leorize[m]add a printf "free" should be enough
04:51:14FromDiscord_<Shield> this what I found in osalloc.nim
04:52:02FromDiscord_<Shield> according to Microsoft, 0 is the only correct value for MEM_RELEASE: This means that the OS has some different view over how big the block is that we want to free! So, we cannot reliably release the memory back to Windows :-(. We have to live with MEM_DECOMMIT instead. Well that used to be the case but MEM_DECOMMIT fragments the address space heavily, so we now treat Windows as a strange unmap target.
04:54:52FromDiscord_<Shield> it's strange
04:55:32rayman22201@Shield: you are on Windows?
04:55:39FromDiscord_<Shield> yeah
04:55:58rayman22201Ahhh. I assumed Linux. Interesting
04:56:36FromDiscord_<Shield> the weird thing is, using pointers and (de)allocating memory works fine, it does give it back to the os
04:57:13FromDiscord_<Shield> if it's using malloc for both manual and gc, why is the result different?
05:02:57rayman22201It shouldn't be different. Something weird is going on I think.
05:04:08*solitudesf joined #nim
05:06:55FromDiscord_<Shield> the weird thing is that, in gc:regions, useMalloc defines efree, but it's never called, what gets called is c_free, which isn't defined in a file I see, replacing it doesn't change anything
05:07:45FromDiscord_<Shield> the little things that drive you insane
05:14:19FromDiscord_<Shield> oh wow, no wonder useMalloc doesn't matter, c_free is basically efree, it gets called directly in regions
05:14:34FromDiscord_<Shield> malloc efree*
05:14:41*vlad1777d joined #nim
05:20:23*narimiran joined #nim
05:23:22FromDiscord_<Shield> the comment says "We have to live with MEM_DECOMMIT instead" but it actually uses MEM_RELEASE
05:23:36FromDiscord_<Shield> there's no change
05:27:34*narimiran quit (Remote host closed the connection)
05:59:59FromDiscord_<Shield> this doesn't make sense at all, I tried to limit the variables, it seems that deallocateAll works when you call it inside the block "withRegion", but not outside it, the only difference inside or outside Try
06:00:37FromDiscord_<Shield> why would try affect this?
06:07:16*solitudesf quit (Ping timeout: 272 seconds)
06:27:01FromGitter<alehander42> Zevv, i agree with vindaar
06:27:09FromGitter<alehander42> if possible, save those procs in some data structure
06:27:20FromGitter<alehander42> and use only keys for them in Patt i guess
06:28:39*freddy92 joined #nim
06:31:33Zevvyeah that was my idea, but later I realized I probably dont need to serialize procs here. My goal is to be able to provide a library of reusable peg patterns as building blocks. But inside this lib it does not mak sense to have code blocks embedded, thats typically only done in the final peg.
06:31:38FromDiscord_<Shield> actually, deallocAll(region) doesn't work, only deallocAll() does, and it has be within the withRegion block, outside it doesn't work, if you do it multiple times and ignore the previous way for the initial allocations, memory usage will revert to the last correct way, this implies some nesting happening
06:31:46FromDiscord_<Shield> it's just bizzar
06:32:01FromDiscord_<Shield> anybody else on windows to try it?
06:32:08*fredrik92 quit (Ping timeout: 245 seconds)
06:32:29Zevvso now I manaually build the Ast for my data structures that quotedo/getast is not able to, and that seems to work so far. Next step would be to see how I can put this back into my macros to generate Nim code from them.
06:32:32*lritter quit (Ping timeout: 245 seconds)
06:40:35*laaron quit (Remote host closed the connection)
06:43:47*laaron joined #nim
06:57:56*joshbaptiste quit (Ping timeout: 272 seconds)
07:00:00*gmpreussner quit (Quit: kthxbye)
07:04:23FromDiscord_<Shield> http://ix.io/1Rc2
07:04:36*gmpreussner joined #nim
07:06:02FromDiscord_<Shield> I'm out of ideas, not sure if I should open an issue
07:07:20leorizeprobably you should
07:09:10FromDiscord_<Shield> I'm waiting for somebody else to try it in case it's win7 fucking up, os specific issues are no fun
07:18:36FromGitter<bevo009> You want that code you linked to compiled?
07:20:01FromGitter<bevo009> If so, it compiles on cmd-Win10. But, I haven't really been following this
07:20:43leorize@Shield it's hard to monitor RAM usage on *nix though
07:21:07leorizebut I do see munmap calls
07:22:08leorize@Shield it's like what you described
07:22:24leorizeI only see munmap calls when deallocAll is called within the region
07:24:35*joshbaptiste joined #nim
07:25:57FromDiscord_<Shield> but why is that? deallocAll is basically tlRegion.deallocAll(), I suspect it's either try block or the variable swap with tlRegion
07:26:04FromDiscord_<Shield> I can't make sense of ot
07:26:07FromDiscord_<Shield> it*
07:28:05leorizeprobably time to read the generated C code
07:28:40leorizeI think I get the idea now
07:29:12leorize@Shield found the prob
07:29:18leorizesee withRegion template
07:29:29leorizethere's a line commented in the `finally` branch
07:29:33leorizethat's the problem
07:30:55leorizeAraq: can you explain why was this commented away? https://github.com/nim-lang/Nim/blob/0e4a8bfb289d707909069e72ca24efd2a074a5f1/lib/system/gc_regions.nim#L111
07:31:29FromDiscord_<Shield> what does it do? the problem is that deallocAll only works within the region, outside the block it doesn't work
07:31:48leorizeMemRegion is an object
07:32:09leorizeit's copied around
07:32:21leorizethat line didn't copy the memregion back, so you can't free it
07:34:30FromDiscord_<Shield> lemme double check, but withScratchRegion has the same problem
07:35:33leorizesee withScratchRegion for explaination
07:35:48leorizeit's appear that even Araq assumed that MemRegion have reference semantics...
07:37:29FromDiscord_<Shield> you are right
07:37:38FromDiscord_<Shield> uncommenting that line makes it work as expected
07:40:42FromDiscord_<Shield> I can't believe I've spent a whole night to debug a commented line
07:43:46leorizethat's why you should always read the source several times :P
07:43:52leorizepreferably when you're wide awake
07:45:33FromDiscord_<Shield> I even glanced over memRegion to see of copying semantics was correct...
07:45:41FromDiscord_<Shield> if*
07:46:50FromDiscord_<Shield> thanks for the help btw
07:47:09leorizenp
07:47:20leorizeare you going to fix it?
07:47:25leorizealthough not sure why it was commented
07:50:33FromDiscord_<Shield> you mean a pr?
07:50:37leorizeyea
07:51:47FromDiscord_<Shield> I'm not using git, if you can't push it, I'll wait for Araq
07:53:04leorizeI'm gonna open a PR and see why if uncommenting that breaks anything
07:54:21FromDiscord_<Shield> you need to add "scratch = tlRegion" before https://github.com/nim-lang/Nim/blob/0e4a8bfb289d707909069e72ca24efd2a074a5f1/lib/system/gc_regions.nim#L286
07:54:35leorizeyep, I know
07:54:37FromDiscord_<Shield> now both withRegion and withScratchRegion work as intended
07:59:21FromDiscord_<Shield> I wonder if that swaping is generating garbage in the main region
08:06:44*rayman22201 quit (Quit: Connection closed for inactivity)
08:11:31FromDiscord_<Shield> no, but printing debug strings was
08:27:13*Trustable joined #nim
08:32:09FromDiscord_<Shield> more memory fun time http://ix.io/1Rcb/nim
08:33:00FromDiscord_<Shield> I suspected this would happen, not even a deepcopy help
08:36:00FromGitter<zacharycarter> @Vindaar: nested objects aren't as straightforward as we thought - couple of things... ⏎ 1) The `genGetProc` macro calls `getVarNode` and most likely a nested object isn't going to be a `var` - to handle this I am now generating two get procs `getVarFoo` and `getFoo` and it will be up to the user to call the correct one
08:37:27FromGitter<zacharycarter> 2) The second problem is that inside the `genGetProc` we call some variation of `getNode` and pass in vmargs as well as an index. Since our nested object isn't an argument in the args passed to the VM, it's nested inside one of them - simply calling the `getFoo` proc we produce will not work
08:40:04leorize@Shield: the only way to do so is to allocate `a` outside of the region, then do some voodoo magic to copy the string buffer over
08:40:56FromGitter<zacharycarter> but I think I have a fix for this
08:43:24FromDiscord_<Shield> the problem is that all memory functions are applied to the current memory region alone, this is why I suggested the ability to have two memory regions at the same time without one overriding the calls of the other
08:45:36FromDiscord_<Shield> I don't think voodoo would work on this, how can you even communicate to the target memregion that it needs to grow/reallocate?
08:53:03leorizehave 2 memregion
08:53:07leorizeone for that string
08:53:29leorizeand one's the scratch itself
08:54:00FromGitter<zacharycarter> wewt
08:54:03leorizethen just `let bLen = b.len; withRegion(aRegion): a = newString(b.len)`
08:54:05FromGitter<zacharycarter> got the get proc working for nested objects
08:54:36leorizethen scope to the outer region and start copying with copyMem
08:54:43leorize"easy" :P
08:56:13FromGitter<zacharycarter> so now you can call either `getVarFoo` or `getFoo` and you'll either get back a `var` or a `let` basically
08:56:25FromGitter<zacharycarter> well not a `let` but an immutable instance of `Foo`
08:56:42FromDiscord_<Shield> I was trying that with pointers and failed miserably, and apparently, it's impossible to use index access on ptr string, p[][0] doesn't work, something needs to be done about '[]'
08:56:56FromGitter<zacharycarter> we could go back to `->`
08:57:16FromGitter<zacharycarter> wait - why doesn't p[][0] work?
08:57:26FromGitter<zacharycarter> strings are implemented w/ seqs right? that should totally work...
08:57:55leorize@Shield wait a bit, I'll try to write an example
08:57:55FromDiscord_<Shield> it doesn't, because [] to deference is interfeering with [] for table access
08:58:41leorizeI don't think you're doing it right...
08:58:46FromGitter<zacharycarter> this works
08:58:56FromGitter<zacharycarter> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d4e87505178a7247660dafc]
08:59:14FromDiscord_<Shield> that would be helpful @leorize
08:59:37FromGitter<zacharycarter> prints `ptring`
09:02:50leorize@Shield http://ix.io/1Rcm/nim
09:03:10leorizeofc you can also just do a for loop copy instead of copyMem
09:03:27FromGitter<zacharycarter> Shield: once you've mastered memory regions - would you mind writing a blog post about them maybe?
09:03:48FromGitter<zacharycarter> and what problems you were able to solve using them?
09:04:12leorize@Shield it's even simpler
09:04:21leorizejust a = b inside that withRegion block lol
09:05:39FromGitter<zacharycarter> @Vindaar - would you be cool with me writing up a blog post about these macros / how I'm going to be using them in my game?
09:05:51FromGitter<zacharycarter> I will credit you as the author :)
09:05:57FromGitter<zacharycarter> not of the blog post but the macros haha
09:05:58leorizeI can see that gc:regions is an interesting gc
09:06:57FromGitter<zacharycarter> leorize: I think it's just not very well documented, and the folks that understand it enough to know how to use it and how it's useful are too busy to dispense that knowledge
09:07:09FromGitter<zacharycarter> also - not insinuating that yuuou and Shield aren't busy :P
09:07:42FromGitter<zacharycarter> I played around with it a little bit about a year ago but couldn't make heads or tails of how to use it - the example code I found on the forums compiled, but then I was left scratching my head - like okay, what did I just do?
09:08:42leorize@Shield this is interesting... https://github.com/nim-lang/Nim/blob/0e4a8bfb289d707909069e72ca24efd2a074a5f1/lib/system/gc_regions.nim#L94
09:09:10shashlickWill be great if we can just regions to fix the dll issue
09:09:36FromGitter<zacharycarter> well - I'm hopeful that Araq (or someone else) will investigate the stack issue with Nim HCR
09:09:59leorizeshashlick: technically you can
09:10:17FromGitter<zacharycarter> because if that's easily fixed and is the main pain point of all the problems people are experiencing with HCR (big ifs I know) - then HCR will be very useful
09:10:21FromGitter<zacharycarter> obviously
09:10:37FromDiscord_<Shield> region is pretty straight forward, what isn't clear is what does "=" and "deepcopy" and "shallowcopy" means for each types, once you have complex objects with nested stuff, you're in for a fun time
09:12:30leorize`=` being broken for string is a bug I think
09:12:42leorizeregions was designed with that in mind
09:12:59leorizea pointer to the region that created the string is there
09:15:48FromDiscord_<Shield> I've yet to understand why it segfaulted in the first place, and how did your solution work, and more importantly, what effects does it have on the region
09:16:39FromDiscord_<Shield> I've noticed that you have to use nested regions to avoid polluting the main region
09:16:56leorizeyou can't capture the main region actually
09:17:00leorizeor I'd have already used that
09:17:21leorizeso here's my speculation of how this works
09:17:46leorizewhen you assign `a = b` in the scratch region, a new string is created for a
09:18:04FromDiscord_<Shield> even an echo $ & is enough to fill a region with no way to free it without nuking the whole thing
09:18:29leorizesince the current region is the scratch one, this also causes a's memory to be held by the region
09:18:47leorizethen when you free it you lost everything
09:18:52leorizewhich is why you get segfault
09:19:36leorizeby nesting the region, I make sure that a's memory will be owned by a region that'd still be alive
09:20:26shashlickI agree we need good docs explaining how to use regions
09:20:56FromDiscord_<Shield> I see, I just deallocated aRegion and got a segfault
09:22:05leorizeI think the default main region was intended to be a feature
09:22:34leorizebut it might causes more problems than it solves
09:22:36FromDiscord_<Shield> this would be useful for dlls if you're careful which memory gets to persist
09:22:50FromDiscord_<Shield> the problem is, how do you copy stuff between regions
09:23:04leorizenest them, that's how
09:23:30leorizeyou can just copy them actually
09:24:00leorizejust make sure that you are in the target region before you copy
09:24:06FromGitter<zacharycarter> there's also - `joinRegion` - but it's inside a `when false` block
09:24:38FromDiscord_<Shield> ix.io/1Rcp/nim
09:25:45leorizethat's the problem
09:25:49FromGitter<alehander42> i cant understand
09:25:51leorizeyou can't capture the main region
09:25:55FromGitter<alehander42> you dont seem to copy it to the main region
09:25:56leorizeso you can't scope back to it
09:27:18leorizemaybe there should be a proc that returns the current region?
09:27:58FromDiscord_<Shield> that's irrelevant, you can drop the hidden main region and use yours from the beginnig, or just add a * to tlRegion to make it public
09:28:32FromDiscord_<Shield> the problem is how do you transfer a variable to the wanted region and make sure it lives there
09:28:51leorizedeepCopy it while you're in the wanted region?
09:28:53FromDiscord_<Shield> it got tricky for 1 string, imagine a nested object
09:36:19FromGitter<mratsim> you can’t mix regions with normal code right?
09:36:54FromGitter<mratsim> Using regions would be helpful for a memory pool/object pool for the low-level details of my multithreading runtime
09:38:15FromGitter<mratsim> uh, I wasn’t aware of the MemRegion type :O
09:40:01FromDiscord_<Shield> no you can't, and that's the problem, you can only write to one and only region, the only solution here would be turning allocators into function pointers, instead of everything working in one exact region
09:41:03FromDiscord_<Shield> declaring a variable in one region and assigning something to it in another leads to a bad time
09:41:04leorizewell but since you can read from any region, copying is trivial
09:41:54FromDiscord_<Shield> I can't get it to work
09:42:12leorizeany example?
09:43:38*Vladar joined #nim
09:44:02*shomodj joined #nim
09:47:13FromDiscord_<Shield> your own, try to move a from aRegion to the main region, I'm using a third variable for swapping and getting errors
09:49:46FromDiscord_<Shield> the solution would be making newObj, newSeq.... take a region argument, so they can reallocate correctly
09:51:14leorizehere's how you move it to the main region
09:51:18leorize`a = a`
09:51:20leorizedone
09:52:41leorizethough I think at this point betting on newruntime is better than gc:regions
09:53:10FromDiscord_<Shield> ix.io/1Rcw/nim
09:54:00leorizethat copyMem is incorrect
09:54:34leorizealso you introduced an another `var c` in the `withRegion` blok
09:54:35leorizeblock*
09:54:51leorizeofc once you got out of it you won't get the `c` you wanted
09:55:16leorizealso newString is not necessary
09:55:50leorizehttp://ix.io/1RcA/nim
09:56:08leorizethat's a simplified way to copy things to the main region
09:58:13FromDiscord_<Shield> http://ix.io/1RcB/nim
09:58:41FromDiscord_<Shield> the real voodoo magic is, why does a = a even work
09:59:17leorizeplease note that `a.addr` is the address to the variable `a` on the stack
09:59:51leorizeyou'd want `a[0].addr` or `a.cstring` instead
10:00:10FromDiscord_<Shield> yeah I noticed that
10:00:53FromDiscord_<Shield> so it does make a copy, the question is why and how
10:01:34leorizeso with the "old" runtime, move optimization for string and seq don't exist
10:01:40leorizeevery assignment is a copy
10:01:46leorizeeven if you self-assign
10:02:55leorizeI just merely exploited this fact to get things to the main region
10:03:27FromGitter<zacharycarter> nested objects work with the generated setResult procs now - did a similar thing where I have `setObject` and `setInnerObject` since the set inner proc shouldn't call setResult and should instead return a PNode
10:03:40FromDiscord_<Shield> I was doing some tests with objects and got some weird results between "=" and deepcopy, it's simply unreliable, regions isn't as helpful as it should be
10:04:16leorizeit's underdeveloped
10:04:46leorizethe majority of the code has been untouched for ≈3yrs
10:05:26leorizecan I have your tests?
10:08:46FromGitter<zacharycarter> https://gist.github.com/zacharycarter/71bc76ec1a7f24ed76eacc350d9969d9
10:08:54FromGitter<zacharycarter> gist of how this looks and works
10:09:02FromDiscord_<Shield> I doubt there's much to do in regions itself, the problem is that anything related to memory happens in the current region reguardless where the variable actually exist, and passing things between region results a random crash
10:09:31*krux02 joined #nim
10:11:05leorizeyea, region needs some kind of write tracking to ward off possible cross region mutation
10:11:18leorizealthough that might have actually existed
10:11:37leorizeiirc there were "memory regions" concept in Nim
10:11:46FromGitter<mratsim> no, write-tracking and escape analysis was something araq always wanted to do and never found the time for
10:12:10leorizeyou can mark a pointer as belonging to a specified region and you won't be able to trade them around
10:12:29FromGitter<mratsim> yes, it was removed because too unergonomic: https://forum.nim-lang.org/t/3158
10:15:34*solitudesf joined #nim
10:17:05FromDiscord_<Shield> interesting
10:18:40FromDiscord_<Shield> regions will be somehow usable if you can copy variables cross regions safely, because otherwise, it's an all or nothing memory manager
10:21:11FromDiscord_<Shield> anybody wants to tackle this?
10:23:31*dddddd joined #nim
10:28:07leorizethe infrastructure seems to be there already
10:29:32*endragor joined #nim
10:29:36*stefanos82 joined #nim
10:30:19leorizebut with how the gc runtime is designed, copying is certainly not easy
10:30:38FromDiscord_<Shield> btw, using deepcopy instead of "=" for both a=b and a=a seems to make it work when a is an object with a ref to string, with "=" you need to do it the hard way
10:31:01leorizeofc
10:31:12leorizewith `=` you're only coping the `ref`
10:31:22leorizedeepCopy reconstruct any `ref`
10:31:36leorizecopying*
10:32:22leorizedoing regions is kinda like using threads in Nim
10:32:40leorizeyou have to be aware of when a deepCopy is required
10:32:48leorizeor else your ref just die
10:32:59FromDiscord_<Shield> is the tradoff even worth it anymore? this needs to be more efficient
10:33:28leorizethe more efficient variant is known as `newruntime`
10:33:44leorizeit abandons the gc entirely :P
10:33:53FromGitter<mratsim> only for owned ref
10:34:10leorizebut the heap is now shared
10:34:12leorizeso less copying neede
10:34:16leorizeneeded*
10:34:19FromGitter<mratsim> but i didn’t try them yet :P, well Araq said that linked lists worked with owned refs so mmmmh
10:34:33*endragor quit (Ping timeout: 268 seconds)
10:34:35FromDiscord_<Shield> newruntime seems scary
10:34:54leorizeI can't really recommend newruntime until the `=move` change is sorted out
10:34:59FromGitter<mratsim> it needs brave explorers to defuse the land mines
10:35:42leorizeI've defused several of them
10:35:44*endragor joined #nim
10:35:48FromDiscord_<Shield> regions kinda solved the problem with server and returning memory, but dll is still a problem
10:36:10FromGitter<mratsim> What are you using newruntime for leorize?
10:36:24leorizeothers are even trying newruntime as their default mode :P
10:37:02leorize@mratsim: nothing much, I'm just experimenting and benchmarking
10:37:18leorizefound several trivial bugs that way
10:37:37FromDiscord_<Shield> which file contains it?
10:37:49leorizenew runtime?
10:38:00FromDiscord_<Shield> yeah
10:38:01leorizelib/core/seqs.nim
10:38:04leorizelib/core/strs.nim
10:38:09leorizethe rest is in the compiler
10:38:21leorizenew runtime is a huge codegen change
10:39:04leorizeoh lib/core/allocators.nim also
10:39:40leorizeand runtime_v2.nim
10:40:45leorizewell any attempt with newruntime should be armed with -d:useMalloc and valgrind
10:41:24leorizenewruntime is really stressing the destructors system
10:42:43FromGitter<mratsim> ugh, there is no pthread_barrier_t on OSX :/ so much for being posix compliant … https://blog.albertarmea.com/post/47089939939/using-pthreadbarrier-on-mac-os-x
10:43:51FromGitter<alehander42> how often does the `=` happen
10:43:57FromGitter<alehander42> `=sink` thing *
10:44:10FromGitter<alehander42> and yeah , does valgrind work well?
10:44:28FromGitter<alehander42> i wanted to run my newly ported-to-c-backend binary
10:44:29FromGitter<alehander42> under it
10:44:32leorize@mratsim: if you're interested in Nim's threadpool, check this out: https://github.com/yglukhov/threadpools
10:44:35FromGitter<alehander42> but afaik i have to use some skiplists
10:44:58leorizethat's going to be the next threadpool I think
10:45:14FromGitter<mratsim> Yeah, I know yglukhov threadpools but there is no load balancing
10:45:15leorizethat was*
10:45:28FromDiscord_<Kiloneie> Did anyone use this site to train Nim ? https://exercism.io/my/tracks/nim
10:45:53leorize@alehander42: valgrind works if you -d:useMalloc (according to Araq anyway, never tried myself)
10:46:41FromGitter<mratsim> it’s fairly recent @Kiloneie, it was setup by one of the community members about 9 months ago iirc
10:46:51leorizedamn, Nim is big on exercism now
10:47:03leorizewhen I first started there were like 10 tasks?
10:48:58FromGitter<mratsim> but Yardanico disappeared :P
10:49:08FromDiscord_<Kiloneie> first 2 side exercises really streched my brain yesterday xD... i have not coded this much since i was 15 trying to do a WAY too ambitious game in Game Maker, i really want to finish it one day...
10:50:20FromDiscord_<Shield> will the newruntime replace gc for good? I've spent too long trying to figure out each gc..
10:50:41FromGitter<mratsim> The issues with games is that you also have the sound, graphics, AI, input and art/music to manage
10:50:43FromDiscord_<Shield> and I've yet to tackle multithreading and dll plugin system
10:50:53leorizeprobably
10:50:56FromGitter<mratsim> No, it will be opt-in
10:51:04FromGitter<mratsim> defautl seq and strings will use newruntime
10:51:05leorizeit's still an experiment
10:51:24FromGitter<mratsim> user object will use newruntime if tagged “type Foo = owned ref object"
10:51:38FromGitter<mratsim> and use GC if tagged “Foo = ref object"
10:51:50leorizeeh, that's not how newruntime works?
10:52:48FromGitter<mratsim> is it? that’s what it said at the bottom of the RFC: https://github.com/nim-lang/RFCs/issues/144
10:53:28leorizeyou can't take in bits by bits
10:53:40leorizeeither you adopt the entire thing with --newruntime
10:53:44leorizeor you don't
10:53:56leorizeif you can slowly migrate then it'd be the default by now :P
10:54:08FromDiscord_<Shield> let's hope it doesn't break existing libraries, it seems that a lot of people stop updating libraries, what a shame
10:54:09FromGitter<mratsim> mmm, the RFC says that you need to tag your types with “owned” otherwise they work as before
10:54:35leorize> use a switch like --newruntime and needs to use owned annotations
10:54:46FromDiscord_<Shield> somehow godot bindings is the most up to date library
10:55:03leorize@Shield migration is simple
10:55:08FromDiscord_<Shield> for games I mean
10:55:19leorizeand the change is staged for nim v2
10:55:32leorizeso if you don't update your library by then it probably won't compile :P
10:55:35FromGitter<mratsim> But Godot bindings are used by a commercial company
10:56:35FromDiscord_<Shield> I also see some libraries that are neither included in nimble.directory nor has the Nim tag so finding them is up to pure chance
10:57:21FromGitter<alehander42> @mratsim leorize is right, i think the "work as before" is about the newruntime again
10:57:31FromGitter<alehander42> i guess, using some form of refcount
10:57:52FromDiscord_<Shield> isn't it too soon to spend effort on v2 features when v1 still yet to happen?
10:58:05FromDiscord_<Kiloneie> Well it's no suprise Godot bindings are the most up to date. Who doesn't like games and game coding(as a coder) ? Godot is the best 2D engine right now and growing really fast, support will only go higher.
10:58:59leorize@Shield technically v1 is already complete
10:59:26leorizebut then Araq wants to have newruntime as part of v1 so...
10:59:29FromDiscord_<Shield> it's undergoing changes
11:00:19leorizeah, some last changes til v1 https://github.com/nim-lang/Nim/issues?q=is%3Aopen+is%3Aissue+milestone%3Av1
11:00:29FromDiscord_<Shield> Godot was fine and dandy until I've read its source code, dictionaries everywhere, calling stuff using strings, strings everywhere, callbacks everywhere, it was a nightmare
11:00:48FromGitter<mratsim> I think we should have v1 with the current GC.
11:01:04leorizethat's the plan
11:01:08*krux02 quit (Remote host closed the connection)
11:01:11FromGitter<mratsim> newruntime is too much of a change
11:01:22leorizeand looks like newruntime has been taken off the list
11:01:29FromDiscord_<Shield> I feel that nim is wasted on it, the only reason I'd use godot would be easy porting to multiple platforms, if you're using nim, that means you're doing the compiling yourself
11:01:41FromDiscord_<Shield> and you're locked to whatever you can compile on
11:01:50FromDiscord_<Kiloneie> Wait what is this new runtime is supposed to do ?
11:01:54leorize@mratsim it was going to be included as --newruntime for experimentation
11:02:06FromGitter<mratsim> ah yeah then OK
11:02:11leorizeiirc Araq wanted it to be functional enought
11:02:24FromDiscord_<Kiloneie> Idk GDscript is way slower than Nim, and a lot of people hate c++, therefore if you really need some crazy calculations, it would be great.
11:02:30leorizethen probably with all the blockers around he dropped it from v1
11:04:57FromDiscord_<Shield> gdscript is slow, but also well integrated, you realise that get_node is doing a full look up in the node's children, using the string name, and calling godot functions is like hitting a speed bump
11:05:15leorizeat least with godot you can read the source code
11:05:28FromDiscord_<Shield> last time I checked, if you want to change a field, you need to asign the whole object, like what
11:05:40leorizewho knows what horror lies in Unity
11:07:41FromGitter<alehander42> i guess new-runtime can still come as
11:07:42FromDiscord_<Shield> I rather have updated sfml libraries and bindings for physics and other cool libraries, and a tiled importer
11:07:46FromGitter<alehander42> --experimental-runtime
11:07:47FromGitter<alehander42> or something
11:08:05FromGitter<alehander42> its in the codebase anyway, it doesnt make sense to completely hide it
11:08:24FromDiscord_<Shield> I tried to make bindings for dragonbones runtime, but the bastards locked the export features behind signing up
11:08:53FromDiscord_<tomku> would it still be practical to use nim in godot for self-contained modules like pathfinding?
11:08:56leorize@alehander42: it's still there, just that blockers for it won't block v1 anymore
11:10:30FromDiscord_<Shield> godot has A* and navmesh tho, both are in C++
11:10:49FromGitter<alehander42> of course
11:12:25FromDiscord_<Shield> but yeah, anything is practical as long as you don't call godot functions that much, and you need to cache any call, and be careful about exessive copying
11:12:57leorizeAraq: https://github.com/nim-lang/Nim/issues/11217 <- so you decided to keep `=sink`?
11:13:01FromDiscord_<Shield> personally I just dropped it instead of hacking around the engine, I mean, it's open source, whatever feature you like you can steal and make it better
11:13:10Araqleorize: yep
11:13:31leorizeyay, less rewrites
11:13:31Araqthe competition is strong, can't affort a 3% overhead
11:13:42FromDiscord_<Shield> because somebody tried to push a PR to avoid using dumb dictionaries and speeding the engine dramatically, but they refused
11:14:34leorizeAraq: so what's your final solution for the self-assignment problem?
11:14:42leorizejust special casing it?
11:14:53FromDiscord_<tomku> gotcha. are there any game engines in nim ecosystem that are acutally alive and maintained?
11:16:01*endragor quit (Remote host closed the connection)
11:16:01leorizewrite games, don't write engines :)
11:16:52FromDiscord_<Shield> there are a couple that I couldn't even compile, but I'd rather avoid engines, for 2d games, you really only need basic drawing functions
11:16:59*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:17:04Araqleorize: self assign is a copy
11:17:38FromDiscord_<Shield> and for 3d, the best option is Unreal, unity is trash, every gdc talk is about how they fight the engine
11:17:56*endragor joined #nim
11:18:25AraqUnreal seemed pretty bloated and they have their own C++ variant with a GC and stuff
11:19:17FromDiscord_<Shield> still faster and more professional than unity, but they're pushing blueprint spaghetti too much
11:19:19FromDiscord_<tomku> i use UE4 at work and am not a huge fan of c++, nim looks like a perfect language for me to do some gamedev on a side
11:19:49FromDiscord_<tomku> but I kinda don't want to roll my own tech in yet another language if you catch my drift
11:20:23leorizehttps://github.com/Vladar4/nimgame2 <- this is a quite functional game engine the last time I checked
11:23:02FromGitter<alehander42> what happened with unity'c "custom C# fast as C++"
11:23:09FromDiscord_<Shield> use what satisfies your need, you trade time for performance and vice versa, but really, how hard is it when you have tons of libraries? you can piggy back other editors
11:24:50FromDiscord_<Shield> https://www.youtube.com/watch?v=mQ2KTRn4BMI
11:25:33FromGitter<Vindaar> @zacharycarter great to hear it's working! And hell yeah, write a blog post! And it's not like I wrote all of it. :) Give me credit for the stuff I actually wrote ;)
11:25:50*solitudesf quit (Ping timeout: 272 seconds)
11:27:26leorize@Shield my god that title is depressing
11:27:44*endragor quit (Remote host closed the connection)
11:27:58*endragor joined #nim
11:28:02FromDiscord_<Shield> if nim can run on android somehow without the disgusting sdk I'll never look at an engine ever again, because porting is the only thing that actually made people switch to engines, everything else is workable
11:28:37FromDiscord_<Shield> it is, and those are professionals with access to unity source code
11:28:58leorizehttps://forum.nim-lang.org/t/4840
11:29:07FromDiscord_<Shield> it's funny how they had to expose an existing function to get a decent speed up
11:33:31FromDiscord_<Shield> @Ieorize that's the project that should be backed by a comercial company, all it needs is a graphic library, I'm curious if sdl2 works
11:34:48leorizeit's leorize with a lowercase `l` :p
11:39:19leorizeI kinda want to make an android app, but then you can't easily build a decent gui without java
11:41:39leorizeI guess I can do a karax-based app
11:41:41leorizethis is one of those times where all those bloated web features are actually useful
11:45:48FromDiscord_<Shield> webgl works surprisingly well on android, and imgui is your best bet
11:45:50*PMunch joined #nim
11:46:17FromDiscord_<Shield> I don't know who thought java was the best choice for an os
11:46:57leorizeto be fair, when android came out, most mobile devs know java (thanks to j2me)
11:47:13leorizeand everyone was learning java at that point
11:47:28leorizeso it's a good move to quickly build an ecosystem
11:47:38FromGitter<alehander42> yeah, they didnt really had a good alternative back then
11:47:45FromGitter<alehander42> what could they use, c++
11:48:00FromGitter<alehander42> for userland apps*
11:48:18leorizenot to mention how the big smartphone OS Symbian has a stupid C++ API that doesn't conform with the standard
11:48:40FromGitter<alehander42> leorize, how can you remember symbian
11:48:54leorizekinda shy everyone away back then
11:49:01FromGitter<alehander42> aren't you .. younger than it
11:49:03FromDiscord_<Shield> at least windows is less shitty in that reguard
11:49:08FromGitter<alehander42> almost
11:49:26leorize@alehander42: I was die hard nokia user :)
11:49:39FromGitter<alehander42> well, windows tried to push .NET with mostly c# code
11:49:40FromGitter<alehander42> for user apps
11:49:44FromGitter<alehander42> i dont see the difference
11:50:03FromGitter<alehander42> now for games, i was under the impression one can use c/c++ with NDK on android
11:50:05leorizewindows mobile wasn't using C# I think?
11:50:06FromGitter<alehander42> so whats the issue
11:50:32leorizeAndroid native APIs are extremely limited
11:50:44FromDiscord_<Shield> windows mobile now is basically like desktop
11:51:13FromDiscord_<Shield> visual studio is a bloated mess tho
11:51:14FromGitter<alehander42> it seems both c++/c# were possible for win mobile
11:51:25FromDiscord_<Shield> yeah
11:52:02FromGitter<alehander42> well, its too bad native apis are limited: i guess hard to support stable native API-s across all the hardware?
11:52:13FromGitter<alehander42> which doesnt sound right
11:52:16leorizeeven BBOS was mostly java
11:52:18FromGitter<alehander42> so it must be somethign else
11:52:31leorize@alehander42: NDK was added as an afterthought
11:52:43leorizejava is the superior language on android
11:52:49leorizebut since java is slow
11:52:51FromGitter<alehander42> ok, but e.g. what does unity and other engines use
11:53:14FromDiscord_<Shield> hardware got faster and software got slower
11:54:04leorizethat moment when phones having 4gb of ram is not enough
11:54:28FromGitter<alehander42> phones stopped being phones long ago
11:54:38FromDiscord_<Kiloneie> hardware is running ahead since AMD caught up and got ahead, Samsung will be using RDNA mobile in like 2 years
11:54:40FromGitter<alehander42> they are just smaller touchscreen-based laptops
11:55:29FromDiscord_<Shield> 8 cores became the norms yet they still manage to make it stutter
12:00:24FromGitter<bevo009> FFI question, could I include a C++ third party library? (fmt) Is it possible?
12:00:38leorizeyes, it is
12:00:52leorizeyou'd have to write the wrapper though
12:01:05leorizec2nim should be able to do a decent amount of them for you however
12:01:11FromGitter<bevo009> What I would use in a minimal working .cpp file is this: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d4eb207bb5364334c07e850]
12:02:49leorize`importcpp: "fmt::print(@)"`
12:03:08leorizethen change the proc name to something that's a valid Nim identifier
12:04:32FromDiscord_<Kiloneie> Operator overload is freaking cool.
12:04:45Araqhere I am ... wondering about linefmt vs lineCg
12:04:48FromGitter<bevo009> "fmt::print(@)" ... what does the `@` do?
12:04:54Araqturns out ... they are the same
12:05:13Araqand people want an 'alias' feature. madness :P
12:06:29leorize@bevo009 https://nim-lang.org/docs/manual.html#importcpp-pragma-importcpp-for-procs
12:07:54FromDiscord_<Kiloneie> Is there a link that has the most useful pragmas in one place ? I am not at that understanding yet.
12:08:11FromGitter<bevo009> yeah I've been reading that, trying to make sense of it
12:09:32FromDiscord_<Kiloneie> Oh man this sucks, i did first challenge of Hello World on Exercism, then the 2 side ones, then did Two Fer second main exercise, now i can't do anything until someone reviews my code... bollocks.
12:09:37FromGitter<bevo009> that formatstr: cstring can't be right for C++ though
12:12:34*ng0 joined #nim
12:13:37FromGitter<bevo009> ```code paste, see link``` ⏎ ⏎ file not recognized: File format not recognized [https://gitter.im/nim-lang/Nim?at=5d4eb4f1c87a0963e747351c]
12:23:23Araqdon't wrap format, we have 'strformat' which is superior
12:26:40FromGitter<bevo009> I do use strformat
12:26:56FromGitter<bevo009> I just want to get this working so I know how to do it
12:27:33FromGitter<bevo009> Should I use (.link: instead?
12:27:44FromGitter<bevo009> {.limk:
12:27:52FromGitter<bevo009> ahh the typos
12:28:17FromDiscord_<Kiloneie> Why won't this reverse ? https://play.nim-lang.org/#ix=1RdL
12:28:17FromDiscord_<Kiloneie> I thought i saw this working somewhere...
12:28:41FromGitter<bevo009> The compiler isn't really giving me clues which part(s) are wrong
12:30:34FromGitter<bevo009> I'm thinking it's "/c/h/format.cc" because it's already in quotes
12:31:25FromDiscord_<Kiloneie> Okay this works: https://play.nim-lang.org/#ix=1RdQ
12:31:26FromDiscord_<Kiloneie> BUT, why doesn't my previous one do anything ?
12:32:20FromDiscord_<Shield> it can only count up
12:32:40FromDiscord_<Shield> it fails on counting down and exists the for loop
12:33:14FromDiscord_<Kiloneie> OH well, i guess that's why countdown exists D:
12:54:56FromDiscord_<Shield> I'd like to confirm, is useMalloc only available for gc regions and none right? the default gc doesn't use it?
13:05:01AraqI can't remember
13:05:19Araqfor emscripten it's also used or something
13:11:13*joki1337 joined #nim
13:19:15*joki1337 quit (Quit: leaving)
13:25:02*joki1337 joined #nim
13:42:54FromGitter<bevo009> Success! :D ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ nim cpp -r "/c/a/nim/nimcpp/01/a4.nim" ... [https://gitter.im/nim-lang/Nim?at=5d4ec9dd4e17537f520960df]
13:43:30FromGitter<bevo009> I did some knucklehead mistakes before that though
13:46:01FromGitter<bevo009> If I wanted to add more headers, can I just comma-separate them, or does each one nead a header: line
13:46:49leorizeyou can {.emit.} them if you feel like it :P
13:46:56leorizetypically a proc only have one header
13:47:15FromGitter<bevo009> Ok I saw that, I'll try it
13:47:22leorizeso I believe the compiler is only equipped to deal with one per symbol
13:47:31FromGitter<bevo009> Thanks for the tips leorize
13:48:40FromGitter<bevo009> the {.emit would follow indented after the proc?
13:49:21leorizeno, just like in C, emit at the top
13:49:32Araqdon't use emit, .header support multiple lines
13:49:37Araqheader: """
13:49:45Araq#include "foo.h"
13:49:50Araq#include "bar.h"
13:49:51Araq"""
13:50:12Araqhowever, it's super rare that you need that since a symbol can only really be in one header
13:53:52FromGitter<bevo009> I think some features of fmt might need format.cc plus their header
13:54:21FromGitter<bevo009> I mostly use print and format though, I'll just make separate procs
13:54:57FromGitter<bevo009> Way cool that it works, once I stopped making mistakes, like compiling with c :)
14:09:41FromGitter<bevo009> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d4ed0254e17537f52098b2d]
14:09:55FromGitter<bevo009> That compiles, just for a test.
14:10:02FromGitter<bevo009> Thanks Arak!
14:10:04FromGitter<zacharycarter> extremely quick write up on those macros - https://gist.github.com/zacharycarter/50064c3cf93c58af1663e91e7fdce758
14:13:45FromGitter<deech> Dumb question, how I do prevent the compiler from spitting out all those "Hint:" and "CC"" lines? Couldn't find a quiet mode in the command line switches
14:14:20FromGitter<bevo009> --verbosity:0 --hints:off
14:14:30FromGitter<deech> Thanks!
14:14:58FromGitter<bevo009> Glad to help :)
14:17:17FromGitter<bevo009> @zacharycarter so NimScript > Wren?
14:18:15FromGitter<zacharycarter> well - I haven't benchmarked NimScript vs Wren or anything like that - but NimScript is a subset of Nim so you can use the same type definitions which is nice
14:18:44FromGitter<zacharycarter> also, Wren has features I'm probably never going to use - like fibers and it's also object oriented to a degree
14:18:59FromGitter<zacharycarter> I think Wren is fine - it's just I think it's nicer to be able to leverage what Nim already has builtin
14:19:21FromGitter<alehander42> wren was by the
14:19:46FromGitter<alehander42> crafting interpeters nystrom guy right
14:19:52FromGitter<bevo009> Last time I checked you looked set to go with Wren
14:20:00FromGitter<bevo009> It looks quite good
14:20:10FromGitter<zacharycarter> well yeah - that was a few days ago
14:20:21FromGitter<zacharycarter> and I was - but then I got help from Vindaar on this macro
14:20:33FromGitter<zacharycarter> this was my main blocker from using NimScript, which was my goto
14:20:56FromGitter<zacharycarter> well actually working HCR is my goto, but until HCR has all the kinks worked out NimScript was my primary fallback
14:21:16FromGitter<zacharycarter> I did manage to figure out how to do the same thing with Wren - it's not difficult, but it's definitely more verbose than what these macros allow for
14:22:56FromGitter<alehander42> what you need is probably working nimrtl stdlib?
14:23:12FromGitter<alehander42> did you hit a purely hcr problem
14:23:21livcdwhen do we use #nim-offtopic ? :-)
14:23:35FromGitter<zacharycarter> I guess when you're not talking about Nim
14:24:03FromGitter<zacharycarter> @alehander42 - I was getting errors when using hcr about memory being read from beyond the top of the stack
14:24:30FromGitter<zacharycarter> it was suggested that perhaps the pointer to the top / bottom of the stack were off when HCR was in use
14:24:38FromGitter<zacharycarter> and that it's the reason HCR is blowing up for folks
14:24:46shashlickNice work guys, this is awesome
14:24:48FromGitter<zacharycarter> but I don't know how to investigate if that's the case nor how to fix it if it is
14:25:10FromGitter<alehander42> it doesnt sound too bad but no idea if people work on it
14:25:13FromGitter<alehander42> does it have an issue
14:27:31livcdI'd like to get into gaming and making addons. Sounds like a nice hobby to have.
14:28:12FromGitter<zacharycarter> kind of - I filed an issue about the bug I was encountering while using HCR, and the Dr. Memory output I included in the issue has this error in it
14:28:27FromGitter<zacharycarter> by this error I mean an error about memory being read from beyond the top of the stack
14:28:43FromGitter<zacharycarter> but I don't think any formal investigation has gone into determining if that's actually the issue or not (pointer to top of stack being incorrect)
14:31:08FromGitter<bevo009> Is there much/any overhead or negative effect compiling to cpp rather than c?
14:31:52Araqcpp is slower to compiler but produces better code since we can map Nim's exceptions to C++'s
14:32:37FromGitter<bevo009> Order of magnitude slower to compile, or just a little?
14:33:28AraqI never noticed the difference
14:33:38FromGitter<bevo009> cool, thanks
14:34:45*clyybber joined #nim
14:36:06*nsf joined #nim
14:36:47*HP-YC9 joined #nim
14:45:28*laaron- joined #nim
14:45:41*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
14:46:03*laaron- quit (Remote host closed the connection)
14:46:27*laaron joined #nim
14:46:49FromGitter<alehander42> btw my hoby lang finally got a small c backend : i totally forgot about exceptions and the backend being cpp
14:47:35FromGitter<alehander42> which reminds me:
14:47:44FromGitter<alehander42> does nim cpp new runtime use malloc/free in c++
14:48:38*leorize quit (Quit: WeeChat 2.4)
14:50:46*joki1337 quit ()
14:54:40*rayman22201 joined #nim
14:55:09*leorize joined #nim
14:59:09Araqwhen you use -d:useMalloc
15:10:43FromGitter<deech> What should we use instead of `debug`?
15:11:06*NimBot joined #nim
15:12:17*solitudesf joined #nim
15:14:20*shomodj joined #nim
15:34:44Araqecho n ?
15:37:28*PMunch quit (Remote host closed the connection)
15:38:19FromGitter<deech> Yeah, sorry. I kept seeing deprecation warnings on debug but it turns out that's a false warning.
15:48:09*Trustable quit (Remote host closed the connection)
15:48:40*clyybber quit (Quit: WeeChat 2.5)
15:50:43FromGitter<deech> Araq, was disallowing variants in const a conscious design decision?
15:53:23*joshbaptiste quit (Ping timeout: 245 seconds)
15:53:31*HP-YC9 quit (Remote host closed the connection)
15:53:42*HP-YC9 joined #nim
16:01:01Araqyeah but we will allow it soon
16:01:14Araqsince C got an update and does support named union fields now
16:01:25Araqthough I'm not sure about C++...
16:21:19*nsf quit (Quit: WeeChat 2.4)
16:21:26*joshbaptiste joined #nim
16:27:34*vlad1777d quit (Ping timeout: 244 seconds)
16:36:53*HP-YC9 quit (Remote host closed the connection)
16:37:04*HP-YC9 joined #nim
16:40:53*sentreen quit (Ping timeout: 245 seconds)
16:41:04*endragor quit (Remote host closed the connection)
16:46:18*joshbaptiste quit (Ping timeout: 272 seconds)
16:52:33Zevvhooray, const variants! \o/
16:57:35FromGitter<deech> At least Visual Studio seem to support them.https://docs.microsoft.com/en-us/cpp/cpp/unions?view=vs-2019#using-unions
16:59:12FromGitter<mratsim> Why is TLS emulation on by default on OSX?
17:06:03Zevvbtw, given consts variants are not supported, should this not give an error instead of silently compile: https://play.nim-lang.org/#ix=1Rfo
17:10:16FromGitter<deech> Yeah, that's the same issue as the one you reported on macros.
17:12:25AraqZevv: I fixed it in a PR but it breaks existing code
17:12:44Araqso instead we will support const object variants properly and not break the code
17:13:36Zevvthat is nice
17:13:53Zevvdeech: I did? :)
17:24:06FromGitter<deech> Zevv, oops I thought it was https://github.com/nim-lang/Nim/issues/11862.
17:24:53FromGitter<deech> In any case on my branch your Playground example compiles and evaluates to `0x5647643fd5a0@[[kOneone = 3], [kTwotwo = 0]]`.
17:25:42*joshbaptiste joined #nim
17:25:52Zevvexactly, it compiles but silently gives wrong results
17:26:39FromGitter<deech> Araq, the PR doesn't break all existing code, it also stops bad constructs like: `let a, b {.compileTime.} = foo()`.
17:27:28ZevvAnd if you change it into https://play.nim-lang.org/#ix=1Rfr you get [[kOneone = 0], [kTwotwo = 6]] :)
17:27:34FromGitter<deech> It just tries to enforce that access to compile time values at runtime has to be mediated by a const which I think is far easier to reason about especially for larger programs that lean on metaprogramming a lot.
17:28:47*lritter joined #nim
17:28:58Zevvthat makes sense, would also disallow my second example probly? Assign a .compileTime. proc result to a let
17:30:02FromGitter<deech> Yeah if it gets merged you'd need to do `let a {.compileTime.} = newThings(); const A = a`.
17:30:11*joshbaptiste quit (Ping timeout: 268 seconds)
17:31:05FromGitter<deech> But still it wouldn't work in your particular case as object variants don't currently cross over from compile to runtime even in my PR.
17:32:08Zevvsure
17:32:35FromGitter<deech> Remove the discriminators and it'll work, you would also be able to do just: `const A = newThings()`.
17:32:50Zevvof course, that would be the way to go.
17:34:32ZevvI've been fiddling with this over the last few days with some help from #nim, but I'm still not where I want to be. I now manually ast-ize my data structures to be able to get them into a const, but now I need to get this const data structure back into a macro in order to generate my nim code AST from it.
17:35:16ZevvI now handle each object variant kind case specificly to generate only the allowed fields for that kind, which works although it is a bit cumbersome
17:47:05*nsf joined #nim
17:54:44*joshbaptiste joined #nim
18:05:10*sentreen joined #nim
18:16:35FromGitter<awr1> does mac os seriously not have thread-local storage
18:18:21Araqit used to lack it
18:19:21FromGitter<awr1> https://stackoverflow.com/a/29929949/10444138
18:19:22FromGitter<awr1> hm
18:23:02FromGitter<mratsim> well hunting TLS emulation issues is a pain ...
18:23:57FromGitter<awr1> i'll have to admit i'm flying blind when it comes to any sort of macOS development, if for lack of owning a mac
18:24:34FromGitter<mratsim> I spent my afternoon fixing dumb MacOS things
18:25:36FromGitter<mratsim> 1) lack of pthread_barrier ⏎ 2) Trying to understand a bug that was in fact linked to Nim TLS while I was using raw pthread ⏎ 3) Trying to do a perf comparison with a C++ lib but realizing that the C++ stdlib on Mac is missing aligned_alloc :/
18:25:37*HP-YC9 quit (Remote host closed the connection)
18:26:44*HP-YC9 joined #nim
18:31:04AraqOSX also has a really low limit on the number of possible threads iirc, it's garbage
18:32:31FromGitter<deech> Are there any plans for Nim green threads or does each `spawn` kick off an OS thread?
18:33:04Araq'spawn' never did that, it schedules a task to be run on the thread pool
18:33:14*joki1337 joined #nim
18:33:24FromGitter<mratsim> you have the coro module if you want lightweight threads
18:34:16FromGitter<deech> Yes you're right, sorry, is the thread pool a set of OS threads?
18:34:20*joki1337 quit (Client Quit)
18:34:29FromGitter<mratsim> yes
18:35:18FromGitter<mratsim> If you want better lightweight threads that might be a good start: http://www.1024cores.net/home/lock-free-algorithms/tricks/fibers
18:36:24FromGitter<deech> That explains why 20,000+ calls to `spawn` ground the process to a halt.
18:37:16FromGitter<deech> I was benchmarking Nim against https://docs.rs/rayon/1.1.0/rayon/. The latter is a pretty amazing library.
18:44:31FromGitter<mratsim> rayon also uses OS threads
18:46:18FromGitter<mratsim> you can try my POC, it has a scheduler so it doesn’t swamp the OS with threads: https://github.com/mratsim/weave/blob/master/e04_channel_based_work_stealing/async_internal.nim#L155-L175
18:47:04FromGitter<mratsim> It scales to billions of spawn https://github.com/mratsim/weave/blob/master/e04_channel_based_work_stealing/tests/fib.nim#L17 (since fibonacci is 2^n)
18:49:41FromGitter<deech> Oh very nice!
18:49:48Araqmratsim: are you aware of https://thetechsolo.wordpress.com/2016/08/28/scaling-to-thousands-of-threads/ ?
18:58:04FromGitter<deech> @mratsim Do it rely on GC?
18:58:36FromGitter<deech> s/Do/Does/ ...sigh.
19:14:18FromGitter<zacharycarter> anyone know how I pretty print w/ nim-gdb?
19:15:47FromGitter<zacharycarter> nevermind I just needed to look at the python source
19:31:16FromGitter<zacharycarter> Hmm having trouble getting it working on windows, doh well
19:35:56FromGitter<mratsim> @deech no no GC
19:36:13*joki1337 joined #nim
19:37:11FromGitter<mratsim> @Araq no but it’s about threads for blocking IO while I’m doing things for compute
19:39:21FromGitter<zacharycarter> attempting to look more into the hcr issue
19:42:12*joki1337 quit ()
19:43:15FromGitter<zacharycarter> gdb apparently doesn't like windows paths though and won't resolve the nim-gdb.py file location
19:49:25*HP-YC9 quit (Remote host closed the connection)
19:49:34*HP-YC9 joined #nim
19:54:56*HP-YC9 quit (Remote host closed the connection)
19:55:04*HP-YC9 joined #nim
19:55:54*clyybber joined #nim
19:56:20*HP-YC9 quit (Remote host closed the connection)
19:56:43*nif quit (Quit: ...)
19:56:54*nif joined #nim
19:58:35FromGitter<zacharycarter> I got it working - first thing I notice in relation to the issue I posted is that `failedAssertImpl_W9cjVocn1tjhW7p7xohJj6A` is not in the `modules` table in nimhcr which makes sense based on the error I'm getting. so it looks like `hcrRegisterProc` is never getting called for `failedAssertImpl`
19:59:24*HP-YC9 joined #nim
20:06:51Zevvyou fixed your hcr problem?
20:09:49FromGitter<zacharycarter> no - I'm just looking more into it
20:10:15FromGitter<zacharycarter> I'm now trying to do - `discard nimhcr.hcrRegisterProc("""C:\Users\carte\nimcache\demo_d/stdlib_assertions.nim.c.dll""", "failedAssertImpl_W9cjVocn1tjhW7p7xohJj6A", failedAssertImpl)` in my program because this is the lookup into the `modules` table that nimhcr is failing on - but that doesn't work either
20:12:14Zevvyou should ask Zah I guess
20:13:10clyybberor onqtam when he's here
20:14:10FromGitter<zacharycarter> yeah - I"m guessing when `hcrRegisterProc` is called in the C codegen - it's not getting called for this particular proc
20:14:59ZevvI tried to look in to this a few weeks ago, but I quickly got lost
20:15:09*krux02 joined #nim
20:15:53FromGitter<Varriount> @mratsim I'm somewhat skeptical of that post... From what I've seen, as the number of threads go up, the number of context switches increase, which cause more and more time to be wasted pausing one thread and resuming another.
20:18:31FromGitter<Varriount> Additionally, you have problems like this: https://web.archive.org/web/20150214094736/https://corbinsimpson.com/entries/take-a-bow.html
20:21:10FromGitter<mratsim> which post?
20:21:40FromGitter<mratsim> the one from the techsolo?
20:24:12FromGitter<mratsim> I’m not sure, their techniques require changing the ulimit of threads. Also it rely on the kernel thread scheduler which uses fair scheduling and optimizes for latency. In userspace often it makes more sense to optimize for throughput
20:24:20FromGitter<mratsim> (well maybe not for a web server)
20:25:17FromGitter<zacharycarter> hmm it looks like normally when `hcrGetProc` is called there is a check preceding the invocation that checks `isReloadable` - but there is one place where `hcrGetProc` is called that this check is absent from
20:25:45FromGitter<zacharycarter> I'm checking now to see whether `failedAssertImpl` passes the `isReloadable` check - if it doesn't I will add that `isReloadable` check and see what happens
20:33:48FromGitter<zacharycarter> well - it does pass the check so hmm
20:42:07*kungtotte quit (Quit: WeeChat 2.5)
20:42:50FromGitter<zacharycarter> actually it doesn't pass the check
20:43:17FromGitter<zacharycarter> because I guess for the module it's being called for `hcrOn` is set to false
20:43:45FromGitter<mratsim> Were case object with a bool instead of an enum tested @Araq? ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d4f2c81d03a7c63e6050d0e]
20:47:42clyybbermratsim: A bool is an enum, so they should have been
20:52:06*HP-YC9 quit (Remote host closed the connection)
20:52:14*HP-YC9 joined #nim
21:01:00krux02bool is not 100% enum
21:01:28krux02internally it is of type ``tyBool`` not ``tyEnum`` therefore it is different
21:04:15clyybberkrux02: May I ask why it is that way?
21:04:20clyybberBecause of if ?
21:04:44krux02might be
21:20:48*Vladar quit (Remote host closed the connection)
21:25:03*HP-YC9 quit (Remote host closed the connection)
21:25:11*HP-YC9 joined #nim
21:29:46*HP-YC9 quit (Remote host closed the connection)
21:29:55*HP-YC9 joined #nim
21:33:55FromDiscord_<Shield> and suddenly, regions works as expected, you don't need the a=a hack, if A belongs to region X, and B belongs to region Y, then all you need to do is to call A = B in region X while it's nested in region Y
21:34:41FromDiscord_<Shield> I'm seeing weird memory usage, but that may be due withRegion copying MemRegion
21:35:39FromDiscord_<Shield> also you should either expose tlRegion or do everything you need in your own (call it Main if you want)
21:36:52FromDiscord_<Shield> this is better than trying to rewrite stdlib to take an optional MemRegion argument for every object
21:40:31FromDiscord_<Shield> the real trick here is how to avoid polluting main region without deallocating the whole region, since even an echo causes a bunch of strings to live forever in your current Memregion
21:41:05FromDiscord_<Shield> any ideas?
21:46:19*joshbaptiste quit (Ping timeout: 246 seconds)
21:51:04Araqmratsim: tested for what? they were used in sockets for years
21:57:35FromGitter<mratsim> just wanted to know if it was possible to use them
22:02:26rayman22201@shield: sorry, I had to take off last night. Glad you got regions working. Was a bug fix / PR required to fix it?
22:06:08rayman22201@Shield: I would probably not ever use the main region. I would always define explicit regions, and switch between them often. One of the quirks of regions is that you have to be careful / explicit about the active region. This is either a disadvantage or an advantage depending on how you feel about that.
22:08:14rayman22201on a tangent, I hate to say it, because I like gc:regions, but you should try newruntime. It is newer and more experimental, but it's more actively developed, so you may get better support from the core devs.
22:09:06FromGitter<zacharycarter> okay - found out some more information about the HCR error I encountered around `failedAssertImpl`
22:11:00FromGitter<zacharycarter> in `cgen.nim` there is a proc: `genProcNoForward` - inside this proc C code is generated to call `hcrGetProc` for `failledAssertImpl`. Prior to this code being generated, there is a check for: `isReloadable` which takes in the module the symbol resides in as well as the symbol itself
22:11:23*solitudesf quit (Ping timeout: 268 seconds)
22:11:52FromGitter<zacharycarter> when this is called for let's say `system.nim` the check fails because inside `isReloadable` the module is checked to see if `hcrOn` is true / false. if it is false then `isReloadable` will in turn return false
22:13:09FromGitter<zacharycarter> however, this proc gets called for `failedAssertImpl` with the main module that I'm compiling, and `hcrOn` is set to true there - thus a `hcrGetProc` call is generated however `hcrRegisterProc` was never called for `failedAssertImpl`
22:19:24*joshbaptiste joined #nim
22:22:14FromDiscord_<Shield> @rayman22201 I need some clear documentation to know how to handle newruntime
22:24:04*joshbaptiste quit (Ping timeout: 244 seconds)
22:27:07FromDiscord_<Shield> I'm spending time on regions because I want full control on what to deallocate and what to keep without going full manual, and with a little function you can add partial deallocation, this would be amazing for a realtime app
22:27:34FromDiscord_<Shield> yes a PR/fix was required
22:28:36FromDiscord_<Shield> now I have 2 problems, if stdlib does any funny allocations, that will be unaccounted for, which happens to be true
22:29:07*joshbaptiste joined #nim
22:29:50rayman22201Those funny allocations in the stdlib may be bugs, but IDK if you want to spend time to track that down.
22:30:16FromDiscord_<Shield> the second problem is, I'm running a test and the program is reserving a minimum memory that isn't shown with the getTotalMem or any other function, I'm not sure why
22:30:38FromDiscord_<Shield> but at least that memory gets reused so it's not that bad
22:30:40FromGitter<zacharycarter> https://github.com/nim-lang/Nim/blob/devel/doc/destructors.rst
22:30:42FromGitter<zacharycarter> might help
22:31:10rayman22201also this: https://github.com/nim-lang/RFCs/issues/144
22:31:18FromDiscord_<Shield> I still see the potential in regions
22:31:34*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:31:40rayman22201newruntime is a cross between (a better version of) C++ uniquePtr and the Rust borrow checker.
22:32:12rayman22201newruntime will also have better stdlib support, since Araq is putting a lot of time into it.
22:32:49rayman22201The documentation is definitely not good yet (but it's not good for regions either)
22:33:08AraqI'm updating the spec while you're talking :P
22:33:16FromDiscord_<Shield> @zacharycarter thanks, I'll give it a read
22:33:44AraqI consider regions to be a deadend because the memory overhead can easily be a factor of 2 or more
22:34:27FromDiscord_<Shield> but doesn't newruntime do automatic deallocation when the lifetime of an object ends? what if you want to defer deallocation or do it in chunks?
22:34:49rayman22201That's what pools are for. The same thing you would do in any language.
22:35:21FromGitter<zacharycarter> np
22:35:52Araqwell you can use regions, destructors are the most flexible tool, make subobject destructors trivial and use the region's destructor to free multiple objects in one go
22:36:13Araqso we are getting the most flexible tool and you can pick your poison.
22:37:11rayman22201The lifetime of an object is tied to it's a parent. So you make a pool (or "region" :-P) that hands out objects, then destroy it when you are done. The destructor will make sure child objects are properly freed as well.
22:37:25FromDiscord_<Shield> which poison will be less deadly with stdlib tho? 😛
22:37:53FromGitter<zacharycarter> @onqtam - whenever you are next around, if you could ping me about an HCR issue (if you still ever work on it) I would appreciate it!
22:38:19AraqShield: stdlib is betting on --newruntime
22:39:24FromDiscord_<Shield> I see, is there a way to ref/unref something? how can you extend the life of an object?
22:39:52clyybberAraq: In the new spec can you leave the possibility open to change where destructors get inserted? As in at the end of proc vs end of scope vs end of branch?
22:40:13clyybberOh god english
22:40:14Araqclyybber: that's already part of the spec
22:40:25Araqand I only change the =sink vs =move wordings
22:40:44Araqwell
22:40:53FromDiscord_<Shield> well, if it works across dlls, I'm all for it
22:40:54Araqwe have end of scope vs end of proc.
22:41:30clyybberAraq: Ok
22:41:33AraqShield: GC_ref/unref will be available, we need it for async
22:41:58clyybberAraq: Btw, how about not disallowing x = x but just making it a no-op?
22:42:30Araqclyybber: yeah, good point
22:42:39clyybberAnd for cases where we can't prove there will be no self assign just wrap the `=move`/`=` in an if clause
22:42:42Araqcould be useful for template expansions
22:43:15Araqclyybber: the plan is to not use =sink but = for potential self assignments
22:44:37clyybberAraq: Yeah, but wdyt about just wrapping =sink in an if statement and clarifying in the spec that all self assignments are no-ops?
22:47:42Araqhow would that look like?
22:48:47Araqtbh my 'select' example works with --newruntime and I'm not sure why
22:48:55clyybbervar x = someFunctionThatMightReturnOneOfItsSinkArguments(x, y)
22:49:04clyybberwould get transformed to:
22:49:19clyybbervar :temp
22:49:36clyybber:temp = someFunctionThatMight...
22:49:45clyybberif x != :temp:
22:49:53Araq`=sink`(x, select(true,
22:49:53Araq let blitTmp = x
22:49:53Araq wasMoved(x)
22:49:55Araq blitTmp,
22:49:58Araq let blitTmp = y
22:49:59Araq wasMoved(y)
22:50:01Araq blitTmp))
22:50:03Araqis what the compiler produces for
22:50:10Araqx = select(true, x, y)
22:50:18Araqso ... it "just" works
22:50:33clyybberAraq: What is :temp?
22:50:55clyybberWe gotta make sure select is only executed once
22:51:09Araqlook at the transformed code
22:51:14Araqit is only called once
22:51:23clyybberBut what is :temp?
22:51:47Araqthere is no :temp
22:52:09Araqthere are temps for x and y but the transformation is so clever (?) that it works out
22:52:16clyybberOh, damnit, I mentally concatenated my code and your code
22:52:51clyybberAraq: Ah, thats due to cooldomes destructiveMoveVar
22:53:12Araqso what... it works
22:54:21AraqShield: yes it works better with DLLs. And with web assembly. And for Python and C++ interop.
22:55:52Araqwe solved every problem. We can even have good compat with a tracing GC technology.
22:56:28clyybberAraq: Lets assume x is pointing to some resource. The `=sink` call without a check for self assignment will still `=destroy` x and then perhaps the x will point at null?
22:59:57clyybberWait, but we do have self assign checks in =sink
23:01:51*nsf quit (Quit: WeeChat 2.4)
23:05:06clyybberAraq: Wait, it "just works".. But that also means we leak.
23:05:19clyybberThe above case leaks
23:05:54clyybberBecause either the resource pointed at by `y` or by `x` will not get destroyed
23:06:29clyybberAssuming wasMoved nils its argument
23:06:35Araqit's late but I removed the builtin self-checks and it still works
23:06:49Araqfor reasons that escape me, oh wait
23:06:58Araqstring literals are never freed, ugh.
23:07:11clyybberYeah.
23:07:44*stefanos82 quit (Quit: Quitting for now...)
23:08:51clyybberAraq: Well, so WDYT about moving the self-check out of `=sink` and to an if case encapsulating `=sink` when there is a potential self assign?
23:09:47Araqso far everything I tried works
23:10:04Araqremember that 'sink' parameters are destroyed inside 'select' too, so nothing leaks
23:11:08clyybberAraq: How can sink parameters be destroyed inside select?
23:11:21clyybberI thought you want the caller responsible for destroying?
23:11:30Araqfor =move, yes.
23:11:40Araqfor =sink the design was different
23:12:19clyybberAraq: It works because even when you =sink a string literal, it stays a string literal. So you have to `=` to get a non-literal string.
23:12:41AraqI did 'var x = "abc" & param' now
23:12:56Araqno literal strings, no crashes, no leaks.
23:13:03clyybberAraq: But that can only work when we have branch or in this case scope based destructor injection. So I dont get why it works now.
23:13:38clyybberAraq: Ugh, your branch doesn't have move for strings yet, right?
23:13:52Araqbecause inside 'select' there are also 'wasMoved' calls
23:14:03Araqas well as destructor injections
23:14:10Araqso that it works out
23:14:16clyybberAraq: But the destructors are injected at the end of the proc right?
23:14:21Araqyes
23:14:27*Jesin quit (Quit: Leaving)
23:14:31clyybberSo we destroy x even when we return it
23:14:49Araqwhen we return it, it is 'wasMoved'
23:14:59clyybberOh
23:15:01Araqso we disarm its destructor
23:15:03clyybberNice haha
23:15:18Araqand that's why everything works out.
23:15:27Araqand devel DOES move strings already
23:15:35Araqhow do you think these bugs got reported?
23:15:38Araq:P
23:15:42clyybberHehe
23:15:46Araqbut I need to sleep now, good night.
23:15:50clyybberGood night
23:16:09*clyybber quit (Quit: WeeChat 2.5)
23:16:35*krux02_ joined #nim
23:16:53*Jesin joined #nim
23:19:31*ng0 quit (Quit: Alexa, when is the end of world?)
23:19:39*clyybber joined #nim
23:19:53clyybberAraq: Ugh, if you are still here, I found an issue
23:20:08Araqyes?
23:20:47clyybberIn the caller scope, we still need to `=destroy` x or y
23:20:52*krux02 quit (Ping timeout: 272 seconds)
23:21:08FromGitter<zacharycarter> is it possible to iterate over an objects fields inside a template - or can you only do this in a macro?
23:21:43clyybberAraq: And either we generate wasMoved(x), wasMoved(y) at the callsite, causing a leak
23:21:50clyybberor we dont, and we get a double free
23:22:00Araqlook at what I wrote
23:22:05clyybberBecause sink parameters aren't passed by reference
23:22:15Araqwe produce wasMoved(x), wasMoved(y)
23:22:23clyybberAraq: But that must leak?
23:22:26clyybberHow the fuck
23:22:34Araqit doesn't leak.
23:22:45clyybberAh
23:22:56Araqboth x and y's ownership is transferred to 'select'
23:22:58clyybberBecause wasMoved(x) gets called before assigning to x
23:23:01clyybberI got it
23:23:14Araqyeah, it's super tricky
23:23:23clyybberAraq: Haha, looks like cooldome solved all problems before we even realized :D
23:23:28AraqI'm not sure it always works
23:23:42Araqhey, I also wrote this code :P
23:24:14clyybberAraq: Oh, right. The destructiveMoveVar isn't even needed
23:24:40clyybberthen you solved problems before you wrongly realized they were there :D
23:25:15Araqwell good night
23:25:23clyybberGood night
23:25:35*clyybber quit (Quit: WeeChat 2.5)
23:33:10*steshaw_ joined #nim
23:36:58*steshaw_ quit (Client Quit)
23:37:25*steshaw_ joined #nim
23:45:48FromDiscord_<Shield> >Objects that contain pointers that point to the same object are not supported by Nim's model
23:45:48FromDiscord_<Shield> is that a feature or a bug
23:58:29FromGitter<Varriount> Shield: what do you mean?