<< 23-03-2023 >>
00:18:01*beholders_eye quit (Ping timeout: 240 seconds)
00:54:01FromDiscord<Dale> Andrew is really charismatic as well, hard not to like the guy
00:55:35FromDiscord<Dale> It's kinda weird to compare nim and zig though, they are polar opposites in many respects
00:56:13FromDiscord<Dale> Though I like them both a lot
00:56:32FromDiscord<Elegantbeef> They are both system languages, so they're not that opposite
00:56:42FromDiscord<Elegantbeef> One cares more about explicitly though
00:57:13FromDiscord<Dale> Well zig is all about no hidden control flow, nim goes the complete other way
00:57:30FromDiscord<Dale> Aesthetically they are very different
00:57:56FromDiscord<Dale> and in terms of feature uptake, they are pretty polarised also
00:59:42FromDiscord<Dale> Has anyone ever made a sizeable nim project without using any of the macro stuff? I was wondering how effective you can be without using them
01:01:14*koltrast_ joined #nim
01:01:17FromDiscord<Elegantbeef> https://github.com/treeform/pixie doesnt have any macros inside it's direct code
01:01:20FromDiscord<Elegantbeef> It's dependencies do have it
01:01:35FromDiscord<Elegantbeef> You obviously can write code like in Zig without macros all day long
01:01:41*koltrast quit (Ping timeout: 265 seconds)
01:02:00FromDiscord<Elegantbeef> Though `compTime` might require macros to be on parity with
01:02:17FromDiscord<Elegantbeef> I have an entire ECS that only uses 1 macro 😄
01:02:56FromDiscord<Dale> Yeah, but nim does have some nice compile-time stuff anyways
01:10:58FromDiscord<Dale> Thanks for link to Pixie, I had seen it before (I mean, it's by treeform!) but I didn't know it had no macros
01:14:36*nanxiao joined #nim
01:16:07FromDiscord<Elegantbeef> It probably has templates and generics, but yea the there are no actual macros
01:20:01*genpaku quit (Remote host closed the connection)
01:36:58FromDiscord<Diogenes of Toronto> It has templates
01:37:03FromDiscord<Diogenes of Toronto> Just checked
01:45:40FromDiscord<Diogenes of Toronto> I feel like nim has long learning curve. It's not steep but I feel like there's just a lot to language. You don't need to use it all for it to be useful.
01:56:24FromDiscord<Elegantbeef> You call that a language, now this is a language
01:57:36*arkurious quit (Quit: Leaving)
02:11:52FromDiscord<PunchCake> I wonder why nim isnt used as much in mobile dev it has so much potential
02:19:44FromDiscord<sOkam!> sent a code paste, see https://play.nim-lang.org/#ix=4rzx
02:21:44FromDiscord<Elegantbeef> It means an compiler error
02:21:58FromDiscord<Elegantbeef> If you want to see the actual error use a debug compiler as it says
02:22:19FromDiscord<Elegantbeef> but it looks like you're doing something that is causing the compiler to attempt to do `ord(SomeObject)` internally
02:22:22FromDiscord<Elegantbeef> Or there abouts
02:22:48FromDiscord<sOkam!> sent a code paste, see https://play.nim-lang.org/#ix=4rzz
02:23:26FromDiscord<sOkam!> i imagine im doing something wrong with the type declaration
02:23:44FromDiscord<Elegantbeef> `N: static int`
02:24:04FromDiscord<Elegantbeef> No clue if you can alias using ranges like that
02:24:11FromDiscord<Elegantbeef> Might need to d o`Shape2D[range[3..255]]`
02:24:29FromDiscord<Elegantbeef> Likely the issue is that `3..255` is turned into a `Slice[int]`
02:24:42FromDiscord<sOkam!> range seems to solve it
02:27:02FromDiscord<sOkam!> sent a code paste, see https://play.nim-lang.org/#ix=4rzA
02:28:31FromDiscord<Elegantbeef> You cannot alias this way
02:28:39FromDiscord<Elegantbeef> `N` is a type so it only accepts types
02:28:40FromDiscord<Elegantbeef> `2` is an integer
02:29:28FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4rzF
02:29:44FromDiscord<Elegantbeef> Now you can do `type Line = Shape2D(2)` and `type Line = Shape2D(range[3..255])`
02:29:44FromDiscord<Elegantbeef> Or even `Shape2D(bool)`
02:30:31FromDiscord<sOkam!> `array[bool?, ...]` ? how does that work?
02:34:34*xet7 quit (Quit: Leaving)
02:37:40FromDiscord<Elegantbeef> The same as `array[YouEnum, int]`
02:37:50FromDiscord<Elegantbeef> Nim supports ordinals in the first position of an array
02:43:29FromDiscord<sOkam!> ic
02:47:49*xet7 joined #nim
02:48:39*nanxiao quit (Quit: Client closed)
03:36:35FromDiscord<slime> 👀
03:37:15FromDiscord<Elegantbeef> 👁️👁️
03:37:23FromDiscord<slime> 🧐
03:44:04FromDiscord<huantian> 😳 🥺 😏
03:52:48FromDiscord<halc> sent a code paste, see https://play.nim-lang.org/#ix=4rzU
03:53:33FromDiscord<Elegantbeef> I mean concepts are typeclasses and not runtime interfaces
03:53:55FromDiscord<halc> what's that got to do with this?
03:54:14FromDiscord<halc> there's nothing dynamic going on here
03:54:39FromDiscord<Elegantbeef> Wait nevermind misread
03:54:44FromDiscord<Elegantbeef> Thought `container` was a concept
03:55:04FromDiscord<halc> it doesn't compile because the compiler can't figure out that the `x.draw()` call isn't a call to the generic `draw[T](cont: Container[T])` proc
03:55:56FromDiscord<halc> the concept isn't necessary btw, I just slapped it in there to illustrate why I'd want to write that kind of code
03:56:07FromDiscord<halc> but you can remove it and it still won't compile
03:57:17FromDiscord<halc> the workaround is to just choose a different name like `proc drawItems[T](cont: Container[T])`
03:57:41FromDiscord<halc> but that feels silly, I want name overloading to work lol
03:57:47FromDiscord<Elegantbeef> There you go `mixin` your concepts
03:57:50FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4rzW
03:58:04FromDiscord<halc> hm
03:58:13FromDiscord<halc> lemme see if that works with my real code
03:58:17FromDiscord<Elegantbeef> The solution is to use mixin
03:58:32FromDiscord<halc> I'll love you if it works
03:58:54FromDiscord<ElegantBeef> Matrix bridge is really being ap rick
03:58:57FromDiscord<Elegantbeef> I assume matrix bridge broke
03:59:07FromDiscord<Elegantbeef> Of course it should the compiler will now leave the symbol as open
04:00:49FromDiscord<Elegantbeef> You have `bind` and `mixin` the former forces that symbol to be closed, which means it uses the generic declaration, the other forces it open which means it uses the declaration and instantiation scope
04:01:52*fallback quit (Quit: IRCNow and Forever!)
04:02:27FromDiscord<halc> sent a code paste, see https://play.nim-lang.org/#ix=4rzZ
04:02:27FromDiscord<halc> I am very thankful
04:05:00FromDiscord<halc> I've used mixin before for templates, I still don't quite understand what it does tho lol
04:05:48FromDiscord<Elegantbeef> It works a bit different in templates
04:05:53FromDiscord<Elegantbeef> But i just described how it works for generics
04:06:16FromDiscord<Elegantbeef> by default the symbol is open if it's an overloaded symbol, and closed if it's not
04:06:39FromDiscord<Elegantbeef> so in your above case your `draw` was turned into a `nnkCloseSymChoice`, which means it only considered scope at procedure declaration
04:15:22FromDiscord<halc> so I guess the compiler decides it's a closed symbol because it's the same name as the proc's?
04:15:36FromDiscord<Elegantbeef> No cause there is no other overload
04:16:13FromDiscord<halc> ohhhhh
04:16:17FromDiscord<halc> I think I understand
04:16:36FromDiscord<halc> cause if I declare `TypeA` and `draw` first, it does compile
04:16:45FromDiscord<Elegantbeef> sent a code paste, see https://paste.rs/3eF
04:16:53FromDiscord<Elegantbeef> our proc\
04:17:22FromDiscord<Elegantbeef> if you add a `proc doThing(i: int) = discard` above the bleh declaration it'd then call yours
04:17:27FromDiscord<Elegantbeef> Cause it's an open symbol now
04:18:10FromDiscord<halc> ahh
04:18:27FromDiscord<halc> okay, okay, I think I actually get it, probably
04:18:34FromDiscord<Elegantbeef> You also can of course just explicitly state "i want this symbol open" with `mixin` 😄
04:19:53FromDiscord<halc> so it isn't actually considered an overloaded symbol until I actually make it an overloaded symbol, makes sense
04:27:39NimEventerNew thread by Naterlarsen: Screenshot works fine in own code but not over sockets., see https://forum.nim-lang.org/t/10032
04:57:13*derpydoo quit (Quit: derpydoo)
05:00:47FromDiscord<Diogenes of Toronto> sent a code paste, see https://play.nim-lang.org/#ix=4rAb
05:01:14FromDiscord<Diogenes of Toronto> i guess this is a generic type?
05:01:48FromDiscord<ElegantBeef> This matrix bridge really pisses me off 😄
05:01:59FromDiscord<Elegantbeef> Works fine
05:02:00FromDiscord<Elegantbeef> image.png https://media.discordapp.net/attachments/371759389889003532/1088326761625944125/image.png
05:02:00FromDiscord<Elegantbeef> @huantian\: well thanks for accidently encouraging me to add negation querying https://github.com/beef331/nimtrest/blob/master/toys%20of%20toys/ecs.nim#L71-L80
05:02:06FromDiscord<ElegantBeef> Yea `type Cmd[T] = object` and replace `type` with `T`
05:02:28FromDiscord<Diogenes of Toronto> thanks
05:03:25FromDiscord<ElegantBeef> But generics are not homogenous types so you may want to use an object variant
05:03:52FromDiscord<ElegantBeef> Assuming you have a limited number of possible values
05:05:51FromDiscord<Diogenes of Toronto> I am considering allowing enums and strings, bools, ints, and floats.
05:14:14*rmt joined #nim
05:19:04*nanxiao joined #nim
05:30:49FromDiscord<huantian> In reply to @Elegantbeef "<@300050030923087872>\: well thanks for": Haha np
05:31:31FromDiscord<Elegantbeef> I do wonder if any thing else needs to be added... the joys of making an ECS never have actually used one
05:46:24*derpydoo joined #nim
05:49:56FromDiscord<vmawz> sent a code paste, see https://play.nim-lang.org/#ix=4rAe
05:50:20FromDiscord<Elegantbeef> Not much to comment on
05:50:28FromDiscord<vmawz> took me about 10 tries lol
05:50:51FromDiscord<vmawz> kept getting errors about discard
05:56:37*advesperacit joined #nim
06:15:14*rockcavera quit (Remote host closed the connection)
06:21:18FromDiscord<Dudugz> If that token goes to a bot then it's not against the discord TOS, otherwise all the developers who made the APIs for the bots would be fined lol
06:23:06*nanxiao quit (Quit: Client closed)
06:35:07FromDiscord<Elegantbeef> "fined"
06:35:07FromDiscord<Elegantbeef> As if they do not just drop the hammer
06:36:03*nanxiao joined #nim
06:39:24FromDiscord<vmawz> In reply to @Dudugz "If that token goes": speaking of that, what's the best or most used nim discord wrapper
06:41:29FromDiscord<Elegantbeef> dimscord
06:46:51*azimut joined #nim
06:56:18FromDiscord<huantian> sent a code paste, see https://play.nim-lang.org/#ix=4rAt
06:56:40FromDiscord<huantian> That really needs to be better documented
06:57:03FromDiscord<Elegantbeef> cmon destructors do your thing please
08:02:20FromDiscord<ricafeal> sent a code paste, see https://play.nim-lang.org/#ix=4rAC
08:02:38*kenran joined #nim
08:04:52FromDiscord<{{N00nehere.username}}> if i'm working with a csv but the delimiter is not a comma, how can i change the default delimiter(in this case a ; )
08:05:40FromDiscord<Elegantbeef> @ricafeal\: are you doing a release build in Nim?
08:06:28FromDiscord<Elegantbeef> Closely look at the `open` procedure from parsecsv
08:09:07NimEventerNew question by DARSHAN KOIRALA: How to access elements of pointer array in Nim?, see https://stackoverflow.com/questions/75820514/how-to-access-elements-of-pointer-array-in-nim
08:13:51FromDiscord<ricafeal> sent a code paste, see https://play.nim-lang.org/#ix=4rAE
08:14:57FromDiscord<Elegantbeef> Take a look at zippy and see if it's any better
08:15:08FromDiscord<Elegantbeef> Or profile the Nim code
08:20:15FromDiscord<{{N00nehere.username}}> i just did a fresh install of nim and clang on windows but when compiling i get "string.h" file not found
08:26:55*nanxiao quit (Quit: Client closed)
08:34:58FromDiscord<ricafeal> sent a long message, see http://ix.io/4rAK
08:35:23FromDiscord<ricafeal> (edit) "http://ix.io/4rAK" => "http://ix.io/4rAL"
08:36:27*rmt quit (Ping timeout: 268 seconds)
08:39:10*nanxiao joined #nim
08:39:16FromDiscord<Elegantbeef> Well profile and PR somewhere 😄
08:40:30*Notxor joined #nim
08:54:58FromDiscord<Dudugz> In that case wouldn't using the zip wrapper be better?
08:55:17FromDiscord<Dudugz> You just need to install zip on your machine and then you can use std/zip
08:55:34FromDiscord<Dudugz> I believe it has native support for file streaming
08:55:46*rmt joined #nim
08:56:17FromDiscord<Dudugz> I used zippy just because I'm dealing with zlib and I don't need something fancy.
09:01:52FromDiscord<Elegantbeef> Scroll up that was the start of their problem
09:03:34FromDiscord<Elegantbeef> Hence why i suggested profiling and making a PR to either Zippy or Zip depending on the work required
09:04:39FromDiscord<vmawz> how do you walk through folders, subfolders, files
09:08:18FromDiscord<ayex> @vmawz\: https://nim-lang.org/docs/os.html `walkdir` might interest you
09:16:58*nanxiao quit (Quit: Client closed)
09:23:59*nanxiao joined #nim
10:01:16FromDiscord<ricafeal> In reply to @Elegantbeef "Hence why i suggested": Thanks!
10:09:45FromDiscord<Kiloneie> Why did i have a mention/announcement icon for #main ?
10:13:20*kenran quit (Remote host closed the connection)
10:13:39*kenran joined #nim
10:22:57*nanxiao quit (Quit: Client closed)
10:53:17*nanxiao joined #nim
11:05:36*nanxiao quit (Quit: Client closed)
11:23:34*rmt quit (Ping timeout: 268 seconds)
11:32:42*Notxor quit (Remote host closed the connection)
11:34:07*Notxor joined #nim
11:53:13FromDiscord<System64 ~ Flandre Scarlet> sent a long message, see https://paste.rs/QSq
11:56:39FromDiscord<Andreas> In reply to @System64 "How to make an": maybe you want NAN-boxing ? this is used in many interpreters.
11:57:17FromDiscord<Andreas> (edit) "In reply to @System64 "How to make an": maybe you want NAN-boxing ? this is used in many interpreters. ... " added "So you end up with a Union-type that can carry anything."
11:59:06FromDiscord<System64 ~ Flandre Scarlet> In reply to @Andreas "maybe you want NAN-boxing": What is NAN-Boxing?
12:01:38FromDiscord<Andreas> In reply to @System64 "What is NAN-Boxing?": https://leonardschuetz.ch/blog/nan-boxing/ explained here. It is found e.g. in the QuickJS-engine.
12:06:03FromDiscord<Andreas> In reply to @System64 "What is NAN-Boxing?": AFAIK in dynamic-land this concept is the best one can get. Compared to static-/ homogeneous-types they have some overhead in size and speed.
12:07:19FromDiscord<System64 ~ Flandre Scarlet> In reply to @Andreas "AFAIK in dynamic-land this": Wait, types are bad in dynamic-land?
12:09:54FromDiscord<Andreas> In reply to @System64 "Wait, types are bad": ahh, no, but you pay a price for it. You get a unified type with a bit higher requirements in memory. Native-Nim-types will perform better and use less resources - but they are not dynamic..
12:13:14*beholders_eye joined #nim
12:14:27FromDiscord<sOkam!> sent a code paste, see https://play.nim-lang.org/#ix=4rBC
12:17:58FromDiscord<Andreas> sent a code paste, see https://play.nim-lang.org/#ix=4rBE
12:18:02FromDiscord<sOkam!> --gc:none
12:19:01FromDiscord<demotomohiro> !eval let x: array[3, int] = [0, 1]
12:19:06NimBotCompile failed: /usercode/in.nim(1, 24) Error: type mismatch: got 'array[0..1, int]' for '[0, 1]' but expected 'array[0..2, int]'
12:19:15*nanxiao joined #nim
12:20:11FromDiscord<demotomohiro> !eval let x: array[3, int] = block: var ret: array[3, int]; ret[0] = 0; ret[1] = 1; ret
12:20:15NimBotCompile failed: /usercode/in.nim(1, 31) Error: nestable statement requires indentation
12:21:08*nanxiao quit (Client Quit)
12:21:46FromDiscord<sOkam!> @demotomohiro i can populate it with a for loop, ofc. but was wondering if I was missing something obvious in how to deal with arrays
12:22:42FromDiscord<System64 ~ Flandre Scarlet> In reply to @Andreas "ahh, no, but you": And CPU too no?
12:27:21FromDiscord<Andreas> In reply to @System64 "And CPU too no?": sure, 'cos your types are bigger and you'll need to do typechecks all over your code - all the static-compiletime-guarantees are gone. Thats why dynamic-typed langs are typically a tad slower. Iterations on containers will be slower, e.g. because of typechecking.
12:27:54FromDiscord<System64 ~ Flandre Scarlet> In reply to @Andreas "sure, 'cos your types": Ah alright, so why is it used in some languages?
12:28:58FromDiscord<Andreas> In reply to @System64 "Ah alright, so why": because for prototyping things having dynamic-types is great - look at Python/JS/Ruby et al..
12:30:14FromDiscord<System64 ~ Flandre Scarlet> Oh alright
12:35:41FromDiscord<Andreas> In reply to @System64 "Oh alright": and everybd. want the-best-of-both-worlds. Python does it with fast-types via C-interop. NodeJS same way. And when i'm done with Nim+QuickJS you'll be able to use any Nim-Type - think of Arraymancer-Matrices - from Javascript..
12:37:17FromDiscord<Andreas> (edit) "want" => "wants"
12:43:31FromDiscord<System64 ~ Flandre Scarlet> In reply to @Andreas "and everybd. wants the-best-of-both-worlds.": This is interesting!↵Btw JS is... Weird...
12:43:39*derpydoo quit (Quit: derpydoo)
12:44:45FromDiscord<Andreas> In reply to @System64 "This is interesting! Btw": It's already there, thx to the `quickjs4nim`-project. I'm just adding some stuff to make the interop a bit easier..
12:45:12FromDiscord<Andreas> (edit) "In reply to @System64 "This is interesting! Btw": It's already there, thx to the `quickjs4nim`-project. I'm just adding some stuff to make the interop a bit easier.. ... " added "And add some documentation 🙂"
12:45:37FromDiscord<System64 ~ Flandre Scarlet> is QuickJS fast?
12:46:06FromDiscord<Andreas> In reply to @System64 "This is interesting! Btw": i'd prefer Coffeescript - which than finally compiles to C-bytecode 🙂
12:46:15FromDiscord<System64 ~ Flandre Scarlet> wait what??
12:49:13FromDiscord<Andreas> In reply to @System64 "wait what??": QuickJS can trans-/compile Coffeescript -> ECMA-Javascript. and it can produce bytecode from that - so that you save the parsing-stage. And yes i assume it will be fast, fast enough. And when parts of the code are slow, well then there is nim to the rescue..
12:49:54FromDiscord<System64 ~ Flandre Scarlet> Nim is very fast!↵Btw↵Would be cool to have Nim for the SEGA MegaDrive!
12:50:09FromDiscord<Andreas> (edit) "rescue.." => "rescue..↵This is true for all the languages that compile to JS - e.g. Civet, Nimba whatever"
12:53:07FromDiscord<System64 ~ Flandre Scarlet> Pretty sure its possible with the C interop
12:56:05FromDiscord<0ffh> In reply to @System64 "Nim is very fast!": Nim is very well suited for embedded systems, you can practially use it for ever platform you've got a C compiler for, as long as it's not absolutely tiny with next to no memory.
12:56:43FromDiscord<System64 ~ Flandre Scarlet> In reply to @0ffh "Nim is very well": the MegaDrive has 64kb of RAM
12:57:27FromDiscord<0ffh> In reply to @System64 "the MegaDrive has 64kb": I think that should work.↵Maybe ask in the #embedded channel.
12:58:08FromDiscord<0ffh> But 64k should be more than enough, I think.
12:58:27FromDiscord<Andreas> In reply to @System64 "the MegaDrive has 64kb": hm, quickJS needs 221-Kb at least, prbly. not gonna work there..
12:59:01FromDiscord<Andreas> (edit) "In reply to @System64 "the MegaDrive has 64kb": hm, quickJS needs 221-Kb at least, prbly. not gonna work there.. ... " added "Maybe MRuby fits into 64Kb ?"
13:01:52FromDiscord<System64 ~ Flandre Scarlet> In reply to @Andreas "hm, quickJS needs 221-Kb": I was talking about Nim
13:05:41FromDiscord<Andreas> In reply to @System64 "I was talking about": idk, maybe if one rips the parser-code from quickjs, than a bytecode-runner might fit into 64-Kb... embedded is not my priority.
13:07:12FromDiscord<System64 ~ Flandre Scarlet> In reply to @Andreas "idk, maybe if one": Oh wait, 2 conversations are overlapping, woops↵I'm sorry, I confused you with 0ffh
13:20:04FromDiscord<System64 ~ Flandre Scarlet> In reply to @0ffh "I think that should": but wouldn't the GC take a lot of CPU?
13:26:15FromDiscord<0ffh> In reply to @System64 "but wouldn't the GC": Nah, not too much.↵Also, ARC and ORC are not GC in the same sense as e.g. the JVM's.
13:27:50FromDiscord<0ffh> They're reference counters, in the case of ORC with a cycle collector on top. So you'll only need ORC if you actually use data structures with cyclical references.
13:31:17FromDiscord<System64 ~ Flandre Scarlet> Oh alright↵When someone says "GC", I'm thinking to the JVM's one↵But isn't the JVM's one more powerful?
13:31:33FromDiscord<0ffh> In reply to @System64 "Oh alright When someone": Nope.
13:33:21FromDiscord<System64 ~ Flandre Scarlet> Oh alright↵I wonder how Nim would perform on a MegaDrive, but for that, it needs SGDK bindings for Nim and it will be an hard time
13:34:12FromDiscord<0ffh> The only difference I can think of is that Java can move objects, IIRC. If so, it could compact memory. But not all GCs of that kind do that.
13:34:55FromDiscord<0ffh> In reply to @System64 "Oh alright I wonder": Yeah bindings are a pain, but I think Nim has some tooling for that, though I haven't used it myself yet.
13:35:22FromDiscord<0ffh> You'd probably need to invest some work in that.
13:39:10FromDiscord<System64 ~ Flandre Scarlet> In reply to @0ffh "Yeah bindings are a": It's easy with Futhark, but I doubt Futhark will do a good job for that kind of bindings
13:44:27*beholders_eye quit (Ping timeout: 256 seconds)
13:53:47*nanxiao joined #nim
13:59:07*nanxiao quit (Quit: Client closed)
14:15:01*rockcavera joined #nim
14:16:14FromDiscord<etra> sent a code paste, see https://play.nim-lang.org/#ix=4rBY
14:30:27FromDiscord<etra> In reply to @etra "this work without the": huh, apparently still initializes triangles?
14:33:39FromDiscord<Yardanico> sent a code paste, see https://play.nim-lang.org/#ix=4rC4
14:33:53FromDiscord<etra> OOH right
14:33:59FromDiscord<etra> static arrays are initialized with 0 in C
14:34:02FromDiscord<etra> I forgot about that
14:34:13FromDiscord<Yardanico> i mean specifically in Nim all value types are always zero-initialized
14:34:17FromDiscord<Yardanico> `{.noinit.}` prevents that
14:34:26FromDiscord<etra> yes, I put noinit but still got 0s
14:34:33FromDiscord<etra> but in C static arrays are initialized at 0
14:34:36FromDiscord<Yardanico> In reply to @etra "yes, I put noinit": you just got lucky, you could get random data as well
14:34:37FromDiscord<etra> so it makes sense now
14:34:41FromDiscord<Yardanico> it depends on the compiler settings and stuff
14:35:33FromDiscord<etra> I guess, but since now is only _(officially C)_ the C spec requires static arrays to be 0
14:35:49FromDiscord<etra> (edit) "_(officially C)_" => "_(officially)_ C"
14:36:08FromDiscord<Yardanico> but they're not static since they're runtime-initialized
14:36:14FromDiscord<Yardanico> I'm not good in C but aren't static arrays basically constant ones?
14:36:42FromDiscord<Yardanico> In Nim `let` means that the variable is initialized at runtime and its value can't be changed
14:36:55FromDiscord<Yardanico> ah, static as in allocated on the stack
14:37:39FromDiscord<etra> oh, since it was on main scope, it was static, I moved into a proc and now it's filled with garbage, as I hoped for!
14:37:44FromDiscord<etra> because that one is stack allocated
14:38:59*kenran quit (Remote host closed the connection)
14:40:13FromDiscord<etra> so my point of using `{.noinit.}` was to avoid unnecessary initializations and it was actually doing that, static arrays are initialized at compile time and so it was full of 0s, and if you do the same on a function it gets stack allocated which is full of garbage
15:03:30FromDiscord<lightninja> Hi all, any one have idea for what could be that `\x59\x6a\x49\x34\x4f\x44\x67\x77\x59\x6a\x67\x32\x4d\x6a\x52\x6b\x59\x54\x63\x32\x5a\x6d\x45\x35\x59\x54\x49\x32\x5a\x44\x51\x7a\x59\x7a\x4d\x34\x4d\x54`
15:07:54FromDiscord<0ffh> hex numbers
15:08:38FromDiscord<0ffh> looks like 2-digit hex numbers with a \x prefix per byte
15:09:01FromDiscord<lightninja> thanks
15:09:09FromDiscord<lightninja> _lightninja sends fireworks 🎆_
15:09:15FromDiscord<0ffh> welcome
15:13:30*Notxor quit (Remote host closed the connection)
15:15:04*Notxor joined #nim
15:31:05*derpydoo joined #nim
15:39:48FromDiscord<Piqueiras> If I have to save a tridiagonal matrix (so only main diagonal and surrounding elements have to be stored) what would be best, an object with "size" parameter and 3 seqs, or try and do an object with a generic N and 3 static arrays of sizes N-1, N and N-1
15:39:56FromDiscord<caravaggio> sorry if this is the wrong spot, other than semantics and syntax. what would u say differentiates nim from zig?
15:41:33FromDiscord<Piqueiras> In reply to @caravaggio "sorry if this is": idk maybe garbage collector
15:41:53FromDiscord<caravaggio> In reply to @Piqueiras "idk maybe garbage collector": i thought soo too, but u can turn it off in nim
15:41:54FromDiscord<caravaggio> right?
15:42:02FromDiscord<Piqueiras> yea
15:42:24FromDiscord<Piqueiras> like I havent even gotten into it but yea I think you can add your own
15:44:55FromDiscord<eyes> https://media.discordapp.net/attachments/371759389889003532/1088488554331656325/image.png
15:44:59FromDiscord<eyes> i am perplexed atm
15:45:45FromDiscord<eyes> in this image you can see the type definition for Options, ``bynmonthday`` is clearly ``Option[seq[number]]``
15:45:50FromDiscord<Nerve> In reply to @caravaggio "sorry if this is": Nim forces memory considerations to the back and makes all other efforts to make business logic come to the forefront and make it pragmatically easy to write fast programs. It's a practical language without a hyper-focus on memory semantics like all the other systems languages. Its focus is on building feature-filled software.
15:46:32*kenran joined #nim
15:46:34FromDiscord<Nerve> If you want pointers, they're there. Otherwise, the RC and GC strategies are more than enough.
15:48:40*Notxor quit (Remote host closed the connection)
15:48:58FromDiscord<Nerve> sent a long message, see http://ix.io/4rCm
15:49:08FromDiscord<PunchCake> Does nim support async await or does it have another form of async?
15:49:17FromDiscord<caravaggio> In reply to @PunchCake "Does nim support async": yeah it does
15:49:22FromDiscord<PunchCake> Ok
15:49:39FromDiscord<caravaggio> In reply to @Nerve "The Rust and Zig": hmmm i always assumed memory safety = holding back on speed
15:50:22*Notxor joined #nim
15:50:39FromDiscord<eyes> not with rust
15:50:49FromDiscord<eyes> memory saftey = its hard to write in that language lol
15:50:54FromDiscord<eyes> (edit) "hard" => "harder"
15:51:07FromDiscord<PunchCake> Tbh nim gets its garbage collection right
15:51:24FromDiscord<caravaggio> safe rust still has some bottle necks
15:51:34FromDiscord<PunchCake> Unless your doing either embedded or os kernal dev you dont need manual memory management
15:51:36FromDiscord<Nerve> Yes, when we're talking about things like checking array bounds you will always pay a ~20% penalty over raw C code that doesn't check that stuff. But in the vast majority of cases, the benefits of not having to do any memory semantics in Nim vastly outweight the maybe 1.5x slowdown over the equivalent Rust code
15:51:44FromDiscord<spoon> it might just be me being bad at rust but its forced me to copy memory before for "safety"
15:51:52FromDiscord<Nerve> In reply to @caravaggio "hmmm i always assumed": Yes, when we're talking about things like checking array bounds you will always pay a ~20% penalty over raw C code that doesn't check that stuff. But in the vast majority of cases, the benefits of not having to do any memory semantics in Nim vastly outweight the maybe 1.5x slowdown over the equivalent Rust code
15:52:11FromDiscord<Nerve> We're not talking a 10-100x slowdown like Python
15:52:17FromDiscord<PunchCake> Bro i dont think its 1.5x slow down
15:52:38FromDiscord<PunchCake> Its probably like 0.9s
15:52:46FromDiscord<PunchCake> (edit) "0.9s" => "0.9x"
15:52:50FromDiscord<Nerve> Yeah in some cases Nim is faster
15:52:58FromDiscord<Nerve> MAX 1.5x
15:53:01FromDiscord<spoon> arent array bound checks performed at compiletime?
15:53:07FromDiscord<PunchCake> And its not even relevant now days as long as your not 30x slower than rust
15:53:08FromDiscord<spoon> well some
15:53:24FromDiscord<PunchCake> Since computers nowdays can go 1000x faster than computer back in the day
15:53:43FromDiscord<caravaggio> how does nim ffi compare to others? if i ffi to c , i get the best of both worlds? seen alot of ppl talk about various overheads online
15:53:59FromDiscord<Nerve> In reply to @caravaggio "how does nim ffi": 0 overhead and SUPER easy, you literally just write a function signature
15:54:03FromDiscord<Nerve> Hooking into C is trivial
15:54:04FromDiscord<spoon> nim has two-way FFI, most other languages dont
15:54:17FromDiscord<caravaggio> In reply to @Nerve "0 overhead and SUPER": okay i see thanks
15:54:23FromDiscord<caravaggio> In reply to @spoon "nim has two-way FFI,": u mean c and js?
15:54:23FromDiscord<PunchCake> Nim ffi is one of the fastest
15:54:46FromDiscord<spoon> In reply to @caravaggio "u mean c and": i mean that since it compiles directly to c, you can use nim code in a c program
15:55:01FromDiscord<PunchCake> And why does nim lack so many mobile gui libs?
15:55:05FromDiscord<Nerve> In reply to @caravaggio "okay i see thanks": Actually there is overhead for mismatching types, for example Nim strings and seqs have structures to help the memory semantics, sometimes they need to be copied when turning them into `cstring` or raw pointers
15:55:12FromDiscord<PunchCake> And is flutter bindings possible for nim?
15:55:30FromDiscord<Nerve> But that copying is automatic
15:55:38FromDiscord<spoon> is flutter dart?
15:55:50FromDiscord<caravaggio> yeah
15:56:04FromDiscord<Nerve> `string` and `cstring` conversion is just a method call, and getting a pointer to a `seq` is easy
15:56:08FromDiscord<PunchCake> In reply to @spoon "arent array bound checks": That wouldn't make much sense if you have a vector for example
15:56:16FromDiscord<caravaggio> In reply to @Nerve "Actually there is overhead": yeah but cstring is defualt to nim, right?
15:56:19FromDiscord<PunchCake> But a regular array would yeah
15:56:58FromDiscord<Nerve> In reply to @caravaggio "yeah but cstring is": `cstring` stands for "comatible string", it's the FFI type you use to interface with C/C++/Obj-C/JS
15:57:03FromDiscord<Nerve> (edit) ""comatible" => ""compatible"
15:57:12FromDiscord<Nerve> it doesn't literally mean a C-string
15:57:28FromDiscord<PunchCake> In reply to @spoon "is flutter dart?": Yes
15:57:39FromDiscord<caravaggio> In reply to @Nerve "it doesn't literally mean": oh makes sense
15:57:55FromDiscord<caravaggio> ill try ffi with js later tonight
15:58:00FromDiscord<caravaggio> want to see what i can do
15:59:01FromDiscord<Nerve> I should point out: If you ever interface with C, there is a `csize_t` type. Use it where C uses `size_t`. If you try to pick an unsigned int type and use that you WILL be sorry
15:59:09FromDiscord<spoon> In reply to @PunchCake "Yes": in that case i dont know, dart has its own gc and everything
15:59:22FromDiscord<PunchCake> Yeah
15:59:31FromDiscord<PunchCake> Why would its gc be an issue?
16:03:09FromDiscord<Gumbercules> In reply to @Nerve "I should point out:": You can just use int
16:03:22FromDiscord<Gumbercules> Int32 for cint
16:03:59FromDiscord<PunchCake> Oh wait
16:04:00FromDiscord<Yardanico> In reply to @Gumbercules "You can just use": `csize_t` exists specifically so that you can use `size_t` in Nim
16:04:09FromDiscord<Gumbercules> Int is the same
16:04:20FromDiscord<PunchCake> Do you guys think tauri bindings for nim would work?
16:04:22FromDiscord<Gumbercules> Is my point - you can just use int either way
16:04:34FromDiscord<Yardanico> In reply to @Gumbercules "Is my point -": it will probably work for most platforms, but better be safe anyway
16:04:40FromDiscord<Yardanico> why not just write the correct C function signature
16:04:42FromDiscord<Gumbercules> It's literally the same thing
16:04:46FromDiscord<Gumbercules> I do it all the time
16:04:56FromDiscord<Nerve> In reply to @Gumbercules "Is my point -": That is NOT a good idea
16:05:01FromDiscord<Yardanico> In reply to @Gumbercules "It's literally the same": it's not
16:05:04FromDiscord<Gumbercules> Why use a whole separate set of aliases when you can just use the built-in types?
16:05:18FromDiscord<Nerve> Different platforms alias `size_t` differently
16:05:23FromDiscord<Gumbercules> No
16:05:24FromDiscord<Yardanico> size_t is implementation defined technically, ofc it will work with "just" int or uint on popular platforms
16:05:31FromDiscord<Yardanico> https://en.cppreference.com/w/c/types/size_t
16:05:36FromDiscord<Gumbercules> It's 64 bits on 64 but machine
16:05:40FromDiscord<Yardanico> no?
16:05:41FromDiscord<Gumbercules> It's 32 on 31
16:05:44FromDiscord<Gumbercules> 32
16:05:45FromDiscord<Nerve> You don't know what you're talking about
16:05:56FromDiscord<Gumbercules> Yes I have no idea
16:06:25FromDiscord<Gumbercules> Even though Ive probably written more C and C++ interop code than anyone else herw
16:06:30FromDiscord<Gumbercules> (edit) "herw" => "here"
16:06:30*Notxor quit (Remote host closed the connection)
16:06:52FromDiscord<Yardanico> writing a lot of code doesn't mean you wouldn't make wrong assumptions
16:06:52FromDiscord<Rika> But that does not mean you are correct
16:07:01FromDiscord<Yardanico> size_t is clearly implementation-defined per the standard itself
16:07:01FromDiscord<Gumbercules> It's not an assumption
16:07:06FromDiscord<Gumbercules> Right
16:07:13FromDiscord<spoon> In reply to @PunchCake "Do you guys think": i know there are alternatives (neel and nimview) that use the native OS web renderer
16:07:15FromDiscord<Yardanico> again, it will work on popular platforms the way you want it to, but that doesn't make it _correct_
16:07:41FromDiscord<Nerve> https://www.enseignement.polytechnique.fr/informatique/INF478/docs/Cpp/en/c/types/size_t.html
16:07:59FromDiscord<Nerve> It's implementation defined. There are scenarios where it might not be 64-bit on 64-bit platforms and assuming so is a mistake
16:08:01FromDiscord<Nerve> One I have made
16:08:15FromDiscord<PunchCake> In reply to @spoon "i know there are": Hm alright
16:08:18FromDiscord<Gumbercules> https://nim-lang.org/docs/system.html#csize_t
16:08:30FromDiscord<Gumbercules> Even though it's just an alias
16:08:32FromDiscord<Yardanico> In reply to @Gumbercules "https://nim-lang.org/docs/system.html#csize_t": yes, this literally uses importc
16:08:34FromDiscord<Yardanico> In reply to @Gumbercules "Even though it's just": it's not
16:08:48FromDiscord<Yardanico> `uint` is just for Nim to think it's uint, while it might actually be not it
16:08:55FromDiscord<Yardanico> otherwise there wouldn't be `importc` there
16:09:00FromDiscord<Gumbercules> What might else it be?
16:09:16FromDiscord<Yardanico> literally anything?
16:09:21FromDiscord<Nerve> In reply to @Gumbercules "What might else it": This entirely depends on the `types.h` at the root of the platform's C standard lib
16:09:23FromDiscord<Gumbercules> If it's not going to be. 32 or 64 but unsigned integer
16:09:27FromDiscord<Yardanico> the standard doesn't guarantee what size or type csize_t will be
16:09:36FromDiscord<Yardanico> it can be a struct even, the point is to abstract the actual size away
16:09:48FromDiscord<Gumbercules> This is ridiculous
16:09:53FromDiscord<Nerve> Yes, it is
16:09:57FromDiscord<Gumbercules> The Nim code then would break
16:10:00FromDiscord<Yardanico> yes, arguing about something that's clearly written in the standard is ridiculous
16:11:21FromDiscord<Gumbercules> All one has to do is look at how it's defined in whatever they are wrapping
16:11:33FromDiscord<Gumbercules> And mirror that in their Nim code
16:11:39FromDiscord<Gumbercules> Then there is no ambiguity
16:12:08FromDiscord<Nerve> `csize_t` also leaves no ambiguity
16:12:22FromDiscord<Nerve> AND you don't have to look at the platform implementation
16:12:23FromDiscord<Gumbercules> Uhhhhhh
16:12:39FromDiscord<Gumbercules> It certainly does, but whatever
16:13:16FromDiscord<Nerve> The goal is for interfacing Nim code to past the proper bit width to C `size_t` parameters. `csize_t` does that.
16:13:24FromDiscord<Nerve> (edit) "past" => "pass"
16:14:05FromDiscord<Gumbercules> I get that and you can do exactly the same thing without using csize_t and using the actual types
16:14:38FromDiscord<Nerve> And you can get the wrong. It depends on your implementation and stdlib.
16:14:53FromDiscord<Nerve> We've argued this ad naesuem so let's call it a difference it philosophy
16:14:58FromDiscord<Nerve> (edit) "naesuem" => "nausuem"
16:15:01FromDiscord<Gumbercules> My point ia
16:15:06FromDiscord<Nerve> (edit) "nausuem" => "nauseum"
16:15:13FromDiscord<Nerve> (edit) "it" => "in"
16:15:33FromDiscord<Gumbercules> I'd rather not have a ton of c_blah declarations in my code
16:16:11FromDiscord<Gumbercules> And it's quite simple to map these to Nim types if you know C which you should anyway if you're interoping with C
16:16:45FromDiscord<Gumbercules> Now anyone reading my code doesn't have to ask themselves wtf a cint or csize_t is
16:16:48FromDiscord<Nerve> ? If you only need it when defining the foreign function signature and when interfacing with that function, you only need those types in two places. You handle the conversion at the interface point
16:17:32FromDiscord<Gumbercules> Well there is no conversion usually only in the case of c_string
16:17:41FromDiscord<Gumbercules> (edit) "c_string" => "cstring"
16:18:12FromDiscord<Gumbercules> That's the only ctype that has to be used
16:19:58FromDiscord<Nerve> This is not advice you should be giving new Nim programmers. They should be converting all inputs to C functions to the compatible types, full stop. If they do what you say they'll start segfaulting everywhere as soon as they hit `-d:release` because they don't know how directly Nim types map to C types.
16:20:27FromDiscord<Gumbercules> New Nim programmers shouldn't be interoping with C
16:20:49FromDiscord<Nerve> So when should they?
16:21:18FromDiscord<Gumbercules> When they know the language and C
16:21:36FromDiscord<Gumbercules> They're going to segfault everywhere anyway if they don't
16:21:41FromDiscord<Nerve> What's your standard there? What is "know the language"?
16:21:47FromDiscord<PunchCake> In reply to @Gumbercules "They're going to segfault": xD
16:22:06FromDiscord<cloud> :nimGlow:
16:22:07FromDiscord<PunchCake> You know when i was a noob i intentionally tried to segfault C but didnt know how
16:22:09FromDiscord<PunchCake> Its ok
16:22:15FromDiscord<spoon> libraries frequently use c interop though, and leave the cint binding
16:22:15FromDiscord<cloud> Nim jumpscare
16:22:19FromDiscord<PunchCake> Just do int ptr = 0
16:22:31FromDiscord<PunchCake> 100x speed boost in C
16:22:33FromDiscord<spoon> In reply to @cloud "Nim jumpscare": got me
16:22:36FromDiscord<Gumbercules> In reply to @spoon "libraries frequently use c": Sure and new Nim users ask all the time wtf is a cint
16:23:00FromDiscord<Gumbercules> Not many ask what an int32 is
16:23:03FromDiscord<PunchCake> Yeah what is that
16:23:06FromDiscord<PunchCake> Wtf is cint
16:23:11FromDiscord<spoon> easy then you say RTFM
16:23:13FromDiscord<Gumbercules> It's an int32
16:23:17FromDiscord<spoon> :-)
16:23:21FromDiscord<PunchCake> Then why not use int
16:23:21FromDiscord<Nerve> In reply to @Gumbercules "Sure and new Nim": wtf is a long uint
16:23:25FromDiscord<PunchCake> And call it a day
16:23:27FromDiscord<Nerve> (edit) "long uint" => "`long uint`"
16:23:38FromDiscord<Gumbercules> Uint64
16:23:49FromDiscord<Nerve> Nope, that depends on the PLATFORM
16:23:54FromDiscord<Nerve> `long uint` can be 32-bit
16:24:13FromDiscord<spoon> if you're interfacing with microcontrollers i imagine that's important
16:24:23FromDiscord<etra> iirc the only requirement of int/uint is it's at least 16 bit
16:24:32FromDiscord<Gumbercules> I don't use 32 bit machines but if I did I'd care
16:24:42FromDiscord<Nerve> I thought you said you know what you're talking about
16:24:47FromDiscord<PunchCake> xD
16:24:50FromDiscord<Gumbercules> And so would the person targeting them
16:25:05FromDiscord<spoon> cint is just for c compatibility since it'd handle the allocation the same as the c compiler
16:25:10FromDiscord<Gumbercules> Someone is grasping at straws here to try to make a point
16:25:12FromDiscord<spoon> or whatever platform
16:25:17FromDiscord<PunchCake> Tbh if your using a 32 bit machine in 2023 its your problem bro
16:25:20FromDiscord<Nerve> In reply to @Gumbercules "Someone is grasping at": You?
16:25:22FromDiscord<Gumbercules> No
16:25:32FromDiscord<PunchCake> As a dev im not supporting decade old hardware
16:25:35FromDiscord<Gumbercules> I've already explained my point multiple times
16:25:48FromDiscord<etra> In reply to @PunchCake "Tbh if your using": not all embedded devices are 64 bit though?
16:25:49FromDiscord<Gumbercules> It's better to know explicitly what types you're dealing wirh
16:26:07FromDiscord<PunchCake> In reply to @etra "not all embedded devices": Embedded is a whooole different story bro
16:26:21FromDiscord<Gumbercules> Rather than rely on some type that changes width depending on the platform
16:26:25FromDiscord<Nerve> In reply to @PunchCake "Tbh if your using": I work at a company that targets 16-bit microcontrollers, this stuff is still very relevant and platform-specific behavior of C types has to be studied here
16:26:28FromDiscord<PunchCake> Most embedded devices have 230kb of ram or somewhere around that @etra
16:26:40FromDiscord<PunchCake> So you can throw the gc out the window
16:26:42FromDiscord<Gumbercules> And if I worked at that
16:26:47FromDiscord<Rika> you'd care
16:26:50FromDiscord<Gumbercules> I'd worry about that as well
16:26:51FromDiscord<Rika> but you dont so you dont
16:26:55FromDiscord<Gumbercules> Right
16:27:02FromDiscord<PunchCake> In reply to @Nerve "I work at a": I am talking about consumer pc
16:27:06FromDiscord<Gumbercules> No one that does is not going to understand these things
16:27:07FromDiscord<PunchCake> Not this embedded bollocks
16:27:19FromDiscord<PunchCake> Embedded i would use C
16:27:22FromDiscord<PunchCake> Not nim
16:27:25FromDiscord<Rika> but that doesnt mean that what you do is correct for what everyone else does, its just that you're informed that what you're doing is correct for what you do
16:27:32FromDiscord<Gumbercules> Nor are they going to be writing correct code that does this kind of interop
16:27:40FromDiscord<spoon> reminds me i still need to try ratel on my esp32
16:27:45FromDiscord<Rika> and those who are not informed (beginners) would follow you without knowing why its fine
16:27:50FromDiscord<Gumbercules> I get that Rika
16:28:07FromDiscord<Gumbercules> My advice is - use the correct Nim type not the C type
16:28:12FromDiscord<Rika> for
16:28:15FromDiscord<Gumbercules> It's clearer code
16:28:19FromDiscord<PunchCake> (If you dont want C interop)
16:28:20FromDiscord<0ffh> In reply to @PunchCake "Not nim": Meh, Nim is so much nicer than C, I'd use it wherever possible.
16:28:35FromDiscord<PunchCake> In reply to @0ffh "Meh, Nim is so": Ok the gc is a huge problem in embedded
16:28:42FromDiscord<spoon> cint etc is only for compatibility with c ffi, it shouldn't really be used otherwise
16:28:43FromDiscord<Gumbercules> I wasn't saying or advocating for usage of the incorrect type
16:28:44FromDiscord<0ffh> In reply to @PunchCake "Ok the gc is": Not ARC.
16:28:50FromDiscord<PunchCake> Even arc
16:28:57FromDiscord<Gumbercules> I'm also typing this all on a phone which is incredibly annoying
16:28:59FromDiscord<Nerve> In reply to @PunchCake "Ok the gc is": RC is not, it's deterministic
16:29:04FromDiscord<0ffh> In reply to @PunchCake "Even arc": Elaborate
16:29:05FromDiscord<PunchCake> Anything with any ref counting is a problem
16:29:06FromDiscord<Rika> In reply to @PunchCake "Even arc": have you hit this problem?
16:29:18FromDiscord<Nerve> Also if you stack allocate everything and turn off any AMM then you're fine for embedded
16:29:22FromDiscord<PunchCake> You need more memory to store the ref counts and keep track of stuff
16:29:38FromDiscord<Gumbercules> Unless cycles
16:29:39FromDiscord<Rika> In reply to @PunchCake "You need more memory": has it practically affected you?
16:29:43FromDiscord<Gumbercules> Then not so much
16:29:55FromDiscord<PunchCake> Bro any gc is a huge problem in embedded
16:29:59FromDiscord<spoon> arc is just the equivalent of inserting mallocs and frees
16:30:13FromDiscord<Piqueiras> uhmm quick question how to make all of them take same space? https://media.discordapp.net/attachments/371759389889003532/1088499953430712430/image.png
16:30:13FromDiscord<PunchCake> There is a reason why nobody uses exceptions or gcs in embedded
16:30:15FromDiscord<Nerve> Sorry, not just stack allocate, you might make a heap arena
16:30:21FromDiscord<Gumbercules> Is RAII GC?
16:30:31FromDiscord<Gumbercules> That's the real question
16:30:35FromDiscord<PunchCake> No
16:30:42FromDiscord<Gumbercules> Some would disagree
16:30:44FromDiscord<0ffh> In reply to @PunchCake "You need more memory": Even in embedded, most systems aren't like 4k RAM anymore. I've done embedded programming for a living. In the worst case, you can live in Nim without even Arc.
16:30:45FromDiscord<PunchCake> Nope
16:30:47FromDiscord<PunchCake> It isnt
16:31:06FromDiscord<PunchCake> In reply to @0ffh "Even in embedded, most": 200 kb of ram sounds like enough
16:31:13FromDiscord<PunchCake> But not enough to run a gc
16:31:22FromDiscord<Gumbercules> In reply to @PunchCake "It isnt": Why not?
16:31:23FromDiscord<spoon> even if arc affected you, you can just turn the gc off
16:31:28FromDiscord<spoon> or view the expandarc
16:31:30FromDiscord<etra> In reply to @Nerve "Also if you stack": AMM?
16:31:33FromDiscord<PunchCake> In reply to @Gumbercules "Why not?": I dont think you understand
16:31:45FromDiscord<PunchCake> With raii there is no gc scanning the program
16:32:10FromDiscord<Gumbercules> So?
16:32:12FromDiscord<PunchCake> Gc scanning takes memory
16:32:15FromDiscord<Gumbercules> RC is GC no?
16:32:22FromDiscord<PunchCake> BRO WTF IS RC
16:32:27FromDiscord<Gumbercules> Reference counting
16:32:28FromDiscord<Rika> reference counting?
16:32:36FromDiscord<PunchCake> In C?
16:32:42FromDiscord<PunchCake> Or cpp backend
16:32:42FromDiscord<Rika> dude i'm not so sure you know what the heck you're talking about anymore
16:32:47FromDiscord<Gumbercules> In any language
16:33:16FromDiscord<PunchCake> In cpp wouldnt work for embedded so im guessing C
16:33:17FromDiscord<Nerve> In reply to @etra "AMM?": Automatic memory management
16:33:18FromDiscord<PunchCake> Right?
16:33:26FromDiscord<Rika> what
16:33:32FromDiscord<PunchCake> Wdym what
16:33:37FromDiscord<PunchCake> Cpp sucks balls for embedded
16:33:40FromDiscord<PunchCake> Big balls
16:33:56FromDiscord<spoon> you know nim arc isn't an overheaded GC but a compiletime check, right?
16:34:02FromDiscord<PunchCake> No
16:34:04FromDiscord<PunchCake> I did not
16:34:17FromDiscord<PunchCake> Ok that changes a lot of what i was thinking
16:34:45FromDiscord<Gumbercules> wtf is going on here today
16:34:48FromDiscord<Gumbercules> ref counting is GC
16:35:02FromDiscord<PunchCake> I thought all nim gc was overhead gcs
16:35:08FromDiscord<Gumbercules> ref counting has overhead
16:35:10FromDiscord<Gumbercules> all GC has overhead
16:35:20FromDiscord<PunchCake> Then no gc works for embedded brooo
16:35:26FromDiscord<PunchCake> :nimRawr:
16:35:31FromDiscord<spoon> there's a blog post about it, it's deterministic scope-based reference counting
16:35:47FromDiscord<spoon> https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html
16:35:50FromDiscord<etra> In reply to @Nerve "I work at a": out of curiosity, do you use Nim for such devices?
16:35:51FromDiscord<Nerve> So is `std::unique_ptr` GC if it's a counted reference but you specify it manually? The behavior is the same
16:35:57FromDiscord<etra> (edit) "In reply to @Nerve "I work at a": out of curiosity, do you use Nim for such devices? ... " added "or have you used it?"
16:35:58FromDiscord<PunchCake> The thing is you wouldnt even use nim for embedded even if you can
16:36:04FromDiscord<PunchCake> Nearly all embedded devs know C
16:36:05FromDiscord<0ffh> In reply to @Gumbercules "ref counting is GC": Kind of, but I doesn't need to trace, and the refcounting is completely deterministic. That's a big plus for embedded.
16:36:08FromDiscord<PunchCake> But they dont know nim
16:36:23FromDiscord<Nerve> In reply to @etra "out of curiosity, do": I've used C for it but I'm proposing Nim since it worked quite well for another backend system
16:36:40FromDiscord<spoon> for personal projects i'd absolutely use nim
16:36:45FromDiscord<PunchCake> In reply to @Nerve "I've used C for": They wont like kt
16:36:49FromDiscord<PunchCake> (edit) "kt" => "it"
16:36:53FromDiscord<Gumbercules> unless you have cycles and then you need ARC and you're paying for m&s
16:36:55FromDiscord<Nerve> I want to test it on ARM/RISC-V but your microcontrollers are I believe 6502s
16:36:56*ixmpp quit (Ping timeout: 265 seconds)
16:37:00FromDiscord<Nerve> (edit) "your" => "our"
16:37:01FromDiscord<PunchCake> And it wont work too @Nerve
16:37:05FromDiscord<Gumbercules> err ORC rather
16:37:12FromDiscord<PunchCake> Its hard to find nim embedded devs
16:37:18FromDiscord<PunchCake> Easy to find C embedded devs
16:37:20FromDiscord<Gumbercules> just go to #embedded
16:37:21FromDiscord<etra> In reply to @PunchCake "Nearly all embedded devs": I think you should turn off a bit the assumptions about /all/ people
16:37:33FromDiscord<PunchCake> No
16:37:42FromDiscord<PunchCake> In this context its correct
16:37:53FromDiscord<PunchCake> Bro wtf are you doing if your an embedded dev and dont know C
16:38:13FromDiscord<Gumbercules> maybe they're writing assembly?
16:38:21FromDiscord<Gumbercules> and they never learned C?
16:38:23FromDiscord<spoon> since nim ARC often gets confused with other ARC models, should just rename it to DARC
16:38:24FromDiscord<PunchCake> Very rarely that ever happens
16:38:31FromDiscord<Gumbercules> did you do a study?
16:38:36FromDiscord<PunchCake> And thats why i saod nearly too
16:38:42FromDiscord<PunchCake> (edit) "saod" => "said"
16:38:45FromDiscord<Gumbercules> My father only knows assembly
16:38:53FromDiscord<PunchCake> My father too
16:38:55FromDiscord<Gumbercules> He doesn't program anymore or work on embedded devices but still
16:38:55FromDiscord<etra> In reply to @PunchCake "In this context its": well, good luck in life presenting everything you think it's correct as facts
16:38:56FromDiscord<PunchCake> 8088 asm
16:39:15FromDiscord<PunchCake> In reply to @etra "well, good luck in": So this bozo completely ignored the nearly part
16:39:21FromDiscord<System64 ~ Flandre Scarlet> Wait, so if you enable ARC, there is no garbage collector? It's like the compiler puts free() functions where it should?
16:39:22FromDiscord<Gumbercules> I'm sure there are lots of people that never bothered to learn C who still program
16:39:33FromDiscord<Gumbercules> lots of Forth programmers too probably
16:39:41FromDiscord<spoon> In reply to @Piqueiras "uhmm quick question how": how are you handling it now?
16:39:43FromDiscord<Gumbercules> In reply to @System64 "Wait, so if you": no there is still a GC
16:39:49FromDiscord<etra> In reply to @PunchCake "So this bozo completely": thanks for the unwanted name calling :^)
16:39:51FromDiscord<PunchCake> Bro wtf is going on here
16:39:51FromDiscord<Gumbercules> reference counting is a type of garbage colection
16:39:53FromDiscord<spoon> In reply to @System64 "Wait, so if you": yep
16:39:58FromDiscord<PunchCake> Im being misunderstood all the way
16:39:59FromDiscord<Gumbercules> there's just no mark and sweep garbage collection happening
16:40:02FromDiscord<spoon> In reply to @Gumbercules "reference counting is a": i'd just call it a bad name
16:40:13FromDiscord<Piqueiras> In reply to @spoon "how are you handling": just strformat and tabs lol
16:40:20FromDiscord<Gumbercules> I mean - it's just a different algorithm is what it boils down to
16:40:22FromDiscord<0ffh> In reply to @System64 "Wait, so if you": It adds a few increments, decrements, and conditional jumps.
16:40:23FromDiscord<PunchCake> @Gumbercules I said nearly all embedded devs know C
16:40:40FromDiscord<Gumbercules> I'm just saying I have no clue on the numbers
16:40:41FromDiscord<System64 ~ Flandre Scarlet> In reply to @0ffh "It adds a few": Oh alright↵Same for ORC?
16:40:50FromDiscord<Gumbercules> ORC has a m&s GC
16:40:53FromDiscord<Gumbercules> bolted on
16:40:54FromDiscord<Gumbercules> for cycles
16:41:01FromDiscord<0ffh> In reply to @System64 "Oh alright Same for": No, orc needs to trace for cycles.
16:41:02FromDiscord<System64 ~ Flandre Scarlet> But what happens if you allocate stuff at runtime?
16:41:13FromDiscord<Gumbercules> you allocate stuff at runtime?
16:41:17FromDiscord<spoon> In reply to @Gumbercules "I mean - it's": did you read the blog post?
16:41:25FromDiscord<Gumbercules> In reply to @spoon "did you read the": I mean these things aren't unique to Nim
16:41:31FromDiscord<System64 ~ Flandre Scarlet> In reply to @Gumbercules "you allocate stuff at": yeah↵Like malloc() or calloc() in C
16:41:35FromDiscord<PunchCake> In reply to @Gumbercules "you allocate stuff at": Ever heard of heap allocs?
16:41:46FromDiscord<Gumbercules> it was a rhetorical question
16:41:53FromDiscord<Gumbercules> like - the eprson asked - what happens when you do this?
16:42:00FromDiscord<Gumbercules> and I was jokingly saying - you do this...?
16:42:01FromDiscord<PunchCake> What does rhetorical mean?
16:42:06FromDiscord<Gumbercules> wasn't meant to be answered
16:42:10FromDiscord<PunchCake> Oh
16:42:11FromDiscord<PunchCake> My fault
16:42:14FromDiscord<Gumbercules> all good
16:42:29FromDiscord<PunchCake> You do any embedde dev gumber?
16:42:33FromDiscord<PunchCake> (edit) "embedde" => "embedded"
16:42:45FromDiscord<Gumbercules> In reply to @PunchCake "You do any embedded": No - my github is here: https://github.com/zacharycarter
16:42:54FromDiscord<Gumbercules> and https://github.com/Tail-Wag-Games/frag
16:43:17*arkurious joined #nim
16:43:26FromDiscord<PunchCake> In reply to @Gumbercules "No - my github": Oh nice your the creator of the nukelar bindigs
16:43:30FromDiscord<PunchCake> (edit) "bindigs" => "bindings"
16:43:31FromDiscord<Gumbercules> @System64 ~ Flandre Scarlet reference counting and mark and sweep will both automatically manage memory for you
16:43:41FromDiscord<Gumbercules> if you're manually allocating memory, you need to manually free it
16:43:44FromDiscord<PunchCake> Would like to say thanks for making it i liked it a lot and i used it a lot
16:44:04FromDiscord<Gumbercules> I just recently updated them
16:44:17FromDiscord<PunchCake> Keep at it bro
16:44:18FromDiscord<Gumbercules> https://github.com/Tail-Wag-Games/frag/blob/master/thirdparty/nuklear.nim
16:44:36FromDiscord<Gumbercules> eh - I just work on my own project now - not trying to contribute anything anywhere
16:44:46FromDiscord<Gumbercules> but I mean, my project is FOSS so - people can do what they want with any of it
16:44:46FromDiscord<PunchCake> Did you do it by hand or did you use automatic bindings?
16:45:08FromDiscord<Gumbercules> I used c2nim - there was some manual work which could be easily automated but I'm lazy
16:45:28FromDiscord<Gumbercules> https://github.com/Tail-Wag-Games/frag/tree/master/thirdparty
16:45:47FromDiscord<Gumbercules> there are quite a few libraries I've written wrappers for in this project
16:46:02FromDiscord<Gumbercules> I'm currently integrating https://github.com/jrouwe/JoltPhysics with my project
16:46:48FromDiscord<Gumbercules> @System64 ~ Flandre Scarlet the primary difference between the two is mark and sweep is a scanning GC: https://www.geeksforgeeks.org/mark-and-sweep-garbage-collection-algorithm/
16:47:10FromDiscord<PunchCake> Want a good project?
16:47:10FromDiscord<System64 ~ Flandre Scarlet> So mark and sweep is like Java?
16:47:14FromDiscord<PunchCake> Bring nim to godot engine
16:47:29FromDiscord<Gumbercules> whereas reference counting is a GC with a different deterministic algorithm, however it can't handle cycles: https://www.tutorialspoint.com/explain-in-detail-about-reference-counting-garbage-collection-in-javascript
16:47:43FromDiscord<Gumbercules> In reply to @PunchCake "Bring nim to godot": I vehemently dislike the Godot engine and its dev team
16:47:54FromDiscord<Gumbercules> In reply to @System64 "So mark and sweep": Yes Java uses some mark and sweep algo
16:48:10FromDiscord<Gumbercules> Swift for instance, uses atomic reference counting
16:48:17FromDiscord<spoon> In reply to @Gumbercules "I vehemently dislike the": that's why i found a way to download their software without paying >:)
16:48:31FromDiscord<Phil> ... aren't there already godot bindings?
16:48:38FromDiscord<Phil> I swear I saw a project
16:48:39FromDiscord<spoon> there are, just not for godot 4
16:48:43FromDiscord<Gumbercules> I think so - probably just not the newest version
16:48:47FromDiscord<Gumbercules> but really, F Godot
16:48:51FromDiscord<Gumbercules> that Juan dude, ugh
16:48:57FromDiscord<PunchCake> In reply to @Gumbercules "I vehemently dislike the": Why tho?
16:48:58FromDiscord<System64 ~ Flandre Scarlet> In reply to @Gumbercules "Yes Java uses some": and is there a GC with no overhead?
16:48:59FromDiscord<spoon> godot 4 replaced their FFI model
16:49:00FromDiscord<Gumbercules> they are expert handwavers
16:49:20FromDiscord<PunchCake> What foes that mean
16:49:25FromDiscord<Gumbercules> In reply to @System64 "and is there a": Not really no - I mean, manual memory management is always going to perform better than automatic
16:49:25FromDiscord<PunchCake> They're scumbags?
16:49:29FromDiscord<Gumbercules> No
16:49:38FromDiscord<Gumbercules> it means when it comes to explaining why they make certain design decisions
16:50:00FromDiscord<Gumbercules> they come up with some bullshit excuse and then expect people to accept it as a good one
16:50:06FromDiscord<spoon> sent a code paste, see https://paste.rs/yq8
16:50:21FromDiscord<Gumbercules> `the use of gestures and insubstantial language meant to impress or convince.`
16:50:59FromDiscord<Nerve> In reply to @Gumbercules "Not really no -": If something like ARC or Rust's borrow checker inserts destruction logic at the end of any owning scope like one should do when manually managing memory using something like `std::unique_ptr`, then...what's the difference?
16:50:59FromDiscord<System64 ~ Flandre Scarlet> In reply to @spoon "from the blog post:": Oh alright↵And what about an auto-free? I've heard the V programming language will have this thing
16:51:11FromDiscord<spoon> it's still a "planned" feature
16:51:15FromDiscord<spoon> i think
16:51:22FromDiscord<Nerve> (edit) "one should do" => "happens"
16:51:28FromDiscord<Gumbercules> In reply to @Nerve "If something like ARC": You're still using a general purpose allocator
16:51:36FromDiscord<PunchCake> Arc leaks
16:51:40FromDiscord<PunchCake> So its no use
16:51:42FromDiscord<PunchCake> Orc is good
16:51:51FromDiscord<spoon> In reply to @PunchCake "Arc leaks": proof? evidence?
16:51:54FromDiscord<spoon> 🤨
16:51:59FromDiscord<PunchCake> Literally the nim site
16:52:09FromDiscord<Gumbercules> you can't decide to perform a specific allocation with a specific allocator - you can if you patch `system/alloc`
16:52:26FromDiscord<Gumbercules> so no arenas, no temp allocators, etc....
16:52:31FromDiscord<PunchCake> Look
16:52:31FromDiscord<PunchCake> https://media.discordapp.net/attachments/371759389889003532/1088505568408371250/Screenshot_20230323_195224_Chrome.jpg
16:52:34FromDiscord<System64 ~ Flandre Scarlet> In reply to @PunchCake "Arc leaks": it leaks if you use cycles
16:52:45FromDiscord<spoon> In reply to @PunchCake "": 1.4.0???!
16:52:46FromDiscord<Nerve> In reply to @Gumbercules "You're still using a": https://forum.nim-lang.org/t/8225#52979
16:52:49FromDiscord<Nerve> It's designed to be constant time
16:52:59FromDiscord<spoon> we're on 1.6.10
16:53:04FromDiscord<PunchCake> In reply to @System64 "it leaks if you": Which is useless for me
16:53:07FromDiscord<PunchCake> Just use orc bruh
16:53:07FromDiscord<System64 ~ Flandre Scarlet> Wait it even have the Go GC??
16:53:15FromDiscord<System64 ~ Flandre Scarlet> (edit) "have" => "has"
16:53:16FromDiscord<PunchCake> Yes for interop
16:53:21FromDiscord<PunchCake> I think
16:53:31FromDiscord<System64 ~ Flandre Scarlet> is the Go GC good?
16:53:37FromDiscord<PunchCake> No
16:53:39FromDiscord<PunchCake> Its so bad
16:53:43FromDiscord<Gumbercules> In reply to @Nerve "It's designed to be": can still beat that with an arena and dishing out memory
16:53:58FromDiscord<spoon> 😭 this guy trollin
16:54:00FromDiscord<System64 ~ Flandre Scarlet> In reply to @PunchCake "Its so bad": Why?
16:54:09FromDiscord<PunchCake> What do you mean why? Have you trird go?
16:54:17FromDiscord<System64 ~ Flandre Scarlet> Yeah, it's good
16:54:25FromDiscord<PunchCake> Do you know the huge overhead ffi because of it
16:55:01FromDiscord<spoon> go gc is only really a problem when you're serving millions of customers and performance spikes down for garbage collector cycles
16:55:18FromDiscord<PunchCake> Yeah and thats where go runs anyways you genius
16:55:20FromDiscord<System64 ~ Flandre Scarlet> In reply to @PunchCake "Do you know the": Ah yeah, C interop is PAIN
16:55:41FromDiscord<PunchCake> In reply to @System64 "Ah yeah, C interop": Oh yeah boi
16:55:50FromDiscord<PunchCake> I like nim because it goes fast
16:55:52FromDiscord<PunchCake> And is easy
16:56:01FromDiscord<PunchCake> And has a billion gcs to choose from
16:56:06FromDiscord<PunchCake> And can compile to javascript
16:57:23FromDiscord<Нудл> guys, how to download faster-than-requests the last version?
16:57:35FromDiscord<Нудл> so need
16:58:24FromDiscord<System64 ~ Flandre Scarlet> In reply to @PunchCake "I like nim because": Yeah it's very fast!↵I guess you can do DSP stuff with it too
16:58:28FromDiscord<Gumbercules> In reply to @Nerve "https://forum.nim-lang.org/t/8225#52979": The larger point is, being able to choose an allocation algorithm on a per-allocation basis is going to yield advantages when it comes to maximizing space and time
16:58:37FromDiscord<PunchCake> In reply to @System64 "Yeah it's very fast!": Dont see why not
16:58:39FromDiscord<Gumbercules> And avoiding fragmentation
16:58:50FromDiscord<PunchCake> Dsp as in digital signal processing right @System64 ~ Flandre Scarlet
16:59:00FromDiscord<System64 ~ Flandre Scarlet> In reply to @PunchCake "Dsp as in digital": Yeah
16:59:10FromDiscord<PunchCake> Yup nim would be plenty fast
16:59:13FromDiscord<System64 ~ Flandre Scarlet> for VST, synthesizers, filters, ...
16:59:14FromDiscord<Нудл> In reply to @Нудл "guys, how to download": answer please
16:59:23FromDiscord<PunchCake> Bro stop begging for answers
16:59:32FromDiscord<System64 ~ Flandre Scarlet> What if we replace Python by Nim?
16:59:58FromDiscord<PunchCake> It would be bad
17:00:06FromDiscord<PunchCake> Since python ecosystems depends on what
17:00:08FromDiscord<PunchCake> Python
17:00:11FromDiscord<PunchCake> Who knew
17:00:20FromDiscord<spoon> ???
17:00:33FromDiscord<PunchCake> ????
17:00:43FromDiscord<System64 ~ Flandre Scarlet> Python is slow, so better to use Nim instead
17:00:46FromDiscord<PunchCake> Wait i misread
17:00:49FromDiscord<PunchCake> xD
17:00:57FromDiscord<PunchCake> If you can use nim instead of python then do it
17:01:08FromDiscord<PunchCake> If you want try bindings tensorflow to nim
17:01:10*beholders_eye joined #nim
17:01:16FromDiscord<PunchCake> That would be great
17:01:20FromDiscord<spoon> python for AI is just a slow interface for calling C code
17:01:25FromDiscord<Нудл> uhh, guys, please, im so want to try it
17:01:29FromDiscord<spoon> why even use python for AI
17:01:34FromDiscord<PunchCake> In reply to @spoon "python for AI is": Its not slow
17:01:44FromDiscord<Нудл> faster-than-requests
17:02:00FromDiscord<PunchCake> Benchmarks prove that calling c from python is as fast as just using the regular C
17:02:00FromDiscord<System64 ~ Flandre Scarlet> In reply to @PunchCake "If you want try": Is it possible??
17:02:07FromDiscord<PunchCake> Why not
17:02:13FromDiscord<spoon> python over there being 10x slower than lua
17:02:23FromDiscord<PunchCake> Tensorflow is in C++
17:02:49FromDiscord<spoon> you know most popular python libraries use a C FFI, including scipi, tensorflow, numpy, etc
17:02:58FromDiscord<PunchCake> Yes
17:03:03FromDiscord<PunchCake> Bring it over to lua then
17:03:37FromDiscord<PunchCake> The thing is that python is so balls deep into ai that there is no hope for other langs to take its place
17:03:41FromDiscord<Нудл> @PunchCake do u know how to download faster-than-requests&
17:03:43FromDiscord<Gumbercules> In reply to @Нудл "faster-than-requests": I don't even know what you're referring to
17:03:51FromDiscord<spoon> In reply to @Нудл "faster-than-requests": the python library?
17:03:56FromDiscord<Нудл> yup
17:04:05FromDiscord<Gumbercules> pip
17:04:12FromDiscord<PunchCake> And primarily because ai devs are more intrested in theory than the actual language so they want something thats dead easy to use
17:04:21FromDiscord<spoon> sir this is the nim server
17:04:22FromDiscord<Нудл> In reply to @Gumbercules "pip": dont download, im tryed
17:04:27FromDiscord<Gumbercules> This is off-topic
17:04:28FromDiscord<Нудл> with 2 devices
17:04:37FromDiscord<Gumbercules> In reply to @Нудл "dont download, im tryed": This isn't a python help channel
17:04:38FromDiscord<PunchCake> In reply to @spoon "sir this is the": I thought this was taco bell bro
17:04:47FromDiscord<PunchCake> Wheres my burrito at
17:04:55FromDiscord<Gumbercules> This chat is getting out of control
17:04:59FromDiscord<PunchCake> xD
17:05:05FromDiscord<spoon> In reply to @PunchCake "I thought this was": the poor taco bell drive through employee when i sit there holding up the line explaining GC
17:05:06FromDiscord<Gumbercules> Main is for questions related to Nim development only
17:05:13FromDiscord<PunchCake> In reply to @spoon "the poor taco bell": XD
17:05:24FromDiscord<Gumbercules> So let's everyone limit conversation to that
17:05:30FromDiscord<PunchCake> me explaining to the taco bell employee why arc gc leaks:
17:05:42FromDiscord<Andreas> In reply to @PunchCake "The thing is that": we should at least try..
17:05:51FromDiscord<Gumbercules> Off topic
17:05:55FromDiscord<Нудл> In reply to @Gumbercules "This isn't a python": its a yours product? right?
17:06:04FromDiscord<PunchCake> In reply to @Andreas "we should at least": Resources would be better allocated elsewhere
17:06:06FromDiscord<Gumbercules> Off topic
17:06:08FromDiscord<Нудл> Why not help?
17:06:11FromDiscord<PunchCake> First we need a gui lib for mobile bruh
17:06:25FromDiscord<Gumbercules> Don't make me ping mods
17:06:28FromDiscord<PunchCake> Blyat
17:06:46*ixmpp joined #nim
17:06:56FromDiscord<Andreas> In reply to @PunchCake "Resources would be better": "AI" gives magic propaganda points..
17:07:00FromDiscord<Нудл> Mmm naxui
17:07:02FromDiscord<Нудл> okey
17:07:07FromDiscord<Нудл> thanks
17:07:13FromDiscord<Нудл> good product
17:07:17FromDiscord<Нудл> very good
17:07:26FromDiscord<PunchCake> In reply to @Нудл "Mmm naxui": Lmao russia?
17:07:28FromDiscord<Нудл> ахуенный
17:07:30FromDiscord<Нудл> пиздатый
17:07:35FromDiscord<Gumbercules> <@&371760044473319454>
17:07:39FromDiscord<PunchCake> No i dont speak much russian nor can i read
17:07:42FromDiscord<spoon> oh wait i take back what i said about 1.6.10 we on 1.6.12 when this happen
17:07:47FromDiscord<PunchCake> I just know a few things
17:07:51FromDiscord<PunchCake> Long live russia tbh
17:10:09FromDiscord<Gumbercules> Probably wasn't a great idea to choose all European mods
17:10:16FromDiscord<PunchCake> lol
17:10:30FromDiscord<PunchCake> Why you calling the cops on us bro
17:10:40FromDiscord<PunchCake> Your like the neighbour who calls the cops on a party
17:10:43FromDiscord<Gumbercules> Because this is dumb and not what main is for
17:10:45FromDiscord<Phil> What are you talking about? The man was banned before I could even get to it
17:10:53FromDiscord<PunchCake> What man?
17:10:54FromDiscord<PunchCake> Who
17:10:57FromDiscord<Phil> His messages were merely not deleted
17:11:08FromDiscord<Gumbercules> Enforcing mains rules I mean Phil
17:11:33FromDiscord<Gumbercules> It's been drivel in here the past 30+ minutes
17:11:43FromDiscord<eyes> bruh
17:11:51FromDiscord<eyes> can we get threads in this chat
17:11:56FromDiscord<PunchCake> No
17:12:01FromDiscord<Phil> No, also offtopic question
17:12:27FromDiscord<PunchCake> bruh
17:12:27FromDiscord<eyes> im trying to ask an unrelated question which people should be able to answer whenever they want, not just right after i send it
17:12:39FromDiscord<eyes> In reply to @Isofruit "No, also offtopic question": exactly why i want threads lol
17:12:52FromDiscord<eyes> only reason i can think of for no threads is matrix/irc bridges
17:12:55*kenran quit (Remote host closed the connection)
17:16:11FromDiscord<eyes> anyways my question is: could somebody please clone https://github.com/the-argus/rrule_nim and run ``nimble test`` and help me debug this little error
17:16:36FromDiscord<pietroppeter> In reply to @Gumbercules "It's been drivel in": It is kind of hard to see what was the topic in here, one thing for sure faster-than-requests is a Python library made in Nim to prove that you can easily make fast Python libraries using Nim, so that part (even if not clearly articulated) I would say is on topic
17:17:15FromDiscord<eyes> sent a code paste, see https://play.nim-lang.org/#ix=4rCG
17:17:17FromDiscord<eyes> on the ``ttr = Parser...`` line
17:17:28FromDiscord<pietroppeter> https://github.com/juancarlospaco/faster-than-requests
17:18:55FromDiscord<Rika> In reply to @eyes "i have this function:": `rules = ...`
17:19:10FromDiscord<eyes> BRUH
17:19:13FromDiscord<eyes> nimlsp moment
17:19:41FromDiscord<eyes> thank you
17:19:56FromDiscord<eyes> i really should start making issues for all the shit i find with nimlsp
17:20:36FromDiscord<Rika> its an issue of nimsuggest more of
17:21:07FromDiscord<eyes> what is the difference between nimlsp and nimsuggest?
17:21:19FromDiscord<eyes> i guess uh wait
17:21:21FromDiscord<Phil> nimsuggest is the core utility everything uses to analyze your nim code
17:21:33FromDiscord<eyes> included in the nim-lang/nim code?
17:21:46FromDiscord<Phil> I'd need to check if it's in the same repo or not, but basically it's a core utility
17:21:50FromDiscord<eyes> yeah okay
17:22:17FromDiscord<spoon> nimlsp uses nimsuggest as the backend
17:22:36FromDiscord<eyes> yeah that makes sense
17:22:51FromDiscord<Phil> It is the thing that analyzes code and spits out what's wrong with it or what suggestions it can provide.↵Everything else just manages communication with whatever code turns that into showing up in a GUI
17:22:53FromDiscord<eyes> just an lsp implementation for nimsuggest
17:23:10FromDiscord<eyes> interesting
17:23:34FromDiscord<Phil> https://github.com/nim-lang/Nim/tree/devel/nimsuggest↵There you go, part of the core compiler repo
17:23:46FromDiscord<eyes> im amazed that a lsp made by the language developers could have so many flaws
17:23:59FromDiscord<Phil> And uses the compiler itself for analysis
17:24:03FromDiscord<eyes> yeah
17:24:13FromDiscord<eyes> im getting an error rn which just directly conflicts with the compiler error
17:24:19FromDiscord<Rika> its very new and its more of the suggestion backend with the flas
17:24:21FromDiscord<Rika> (edit) "flas" => "flaws"
17:24:29FromDiscord<Gumbercules> In reply to @pietroppeter "It is kind of": I wasn't aware, thanks for the info
17:25:55FromDiscord<jmgomez> In reply to @eyes "im amazed that a": Most people use nimsuggest directly
17:26:16FromDiscord<jmgomez> AFAIK they didnt develop the lsp. Did they?
17:26:20FromDiscord<spoon> i use nimlsp in neovim
17:26:28FromDiscord<Gumbercules> Nimsuggest has the flaws
17:26:34FromDiscord<spoon> it told me symbols from raylib didn't exist
17:26:57FromDiscord<jmgomez> Yeah, and the lsp has its own flaws too. I used it for a bit but it's kind of abandoned
17:27:00FromDiscord<Gumbercules> Nimlap uses nimsuggest
17:27:14FromDiscord<jmgomez> Im planning to do something about the editor soon, as soon as I get the VM thing usable
17:27:58FromDiscord<Gumbercules> Well the maintainer hangs out with the numskull crowd
17:28:13FromDiscord<Gumbercules> Nimskull
17:28:30FromDiscord<jmgomez> I will do one for NUE and as a byproduct make it usable for Nim too. It mainly will be a companion for NimSuggest
17:28:45FromDiscord<jmgomez> Cant really release NUE without proper discovery tools..
17:28:47FromDiscord<Gumbercules> Should just fix nimsuggest
17:29:18FromDiscord<jmgomez> I think that's beyond my current skills. I can wait until Araq fixes IC but in the meantime I think I can do something about it
17:29:49FromDiscord<jmgomez> So it will be just a layer on top of nimsuggest that wont understand macros etc.
17:30:28FromDiscord<Gumbercules> I don't know what the underlying issue with them suggest is All I know is it launches way too many processes and it leaks
17:30:44FromDiscord<Gumbercules> But I assume one should be able to hook it up to Val grind or address sanitizer or something and find the leak fairly easily
17:30:53FromDiscord<Gumbercules> I just don't know if people have tried
17:31:12FromDiscord<Gumbercules> I don't really use it so....
17:31:23FromDiscord<Gumbercules> I also wouldn't look to incremental compilation as some savior because it might not ever arrive
17:31:58FromDiscord<jmgomez> What I know is that IC may help because all is "cached" so it doesnt have to do the rediscovery again and again. Yeah, that's why I want to do something about it
17:32:25FromDiscord<spoon> that and treesitter grammar
17:33:36FromDiscord<Gumbercules> I don't even have Nim suggest built on my machine because the last time I tried sometime in the past week or so, it failed to build on Windows
17:33:51FromDiscord<Gumbercules> Maybe if I ever have a spare moment I will try again and see if I can find the leak
17:33:54FromDiscord<jmgomez> In reply to @Gumbercules "I don't even have": it works fine for me though
17:33:58FromDiscord<Gumbercules> It can't be that hard...
17:34:09FromDiscord<Gumbercules> Well I tried to compile some random devel version
17:34:14FromDiscord<jmgomez> I think it's mostly the extension opening too many instances
17:34:19FromDiscord<Gumbercules> Whatever was head on that given day
17:34:29FromDiscord<Gumbercules> I don't think so at least not the leak
17:34:49FromDiscord<Gumbercules> I think it still leaks even in other editors
17:35:21FromDiscord<jmgomez> Dunno, didnt really look into it. TBH what bothers me is that it's slow, sometimes doesnt suggest and the order of things is messed up
17:36:04FromDiscord<jmgomez> That's said for me the tooling is good enough, but I cant expect other people to feel the same. Especially those unfamiliar with Nim
17:36:47FromDiscord<Gumbercules> Most people want refactoring tools like you'd find in intelliJ or resharper
17:37:02FromDiscord<Gumbercules> Which Nim is pretty far away from
17:37:21FromDiscord<jmgomez> haha lol, yes. I think something at the average C++ level can be neat
17:37:34FromDiscord<Gumbercules> We're often dealing with people coming from higher level languages not lower so expecting them to know how a C compiler tool chain functions is a bit of a stretch
17:37:47FromDiscord<Gumbercules> They want easy mode
17:41:03FromDiscord<Gumbercules> There were all these attempts in the past to make Nim tooling - Nim's wrapper around GDB, a couple of IDEs / Editors, a REPL, etc...
17:41:41FromDiscord<Gumbercules> they have all been abandoned and the community didn't pick any of them up
17:43:00FromDiscord<jmgomez> 😦
17:43:41FromDiscord<Gumbercules> Dogfooding is hard
17:44:36FromDiscord<Gumbercules> And so is convincing people to spend time developing tools against a moving target - but now that Nim seems to be on more stable footing, maybe it's time to reinvest energy in this area
17:44:43FromDiscord<Gumbercules> I'm just not sure what people want - beyond a working nimsuggest
17:45:33FromDiscord<Andreas> In reply to @Gumbercules "And so is convincing": right so, lets compile nimsuggest/nimlsp to WASM and use Lapce with nim..
17:45:59FromDiscord<Gumbercules> I can't tell if you're being serious or not haha
17:46:26FromDiscord<Andreas> In reply to @Gumbercules "I can't tell if": TBH i tried Lapce and its a snappy one..
17:46:41FromDiscord<Gumbercules> I didn't even know what it was - I don't think this is going to really solve anything though
17:46:53FromDiscord<Gumbercules> besides having another editor to write Nim code in - and then losing support for the VSCode extension
17:47:09FromDiscord<Gumbercules> The problem isn't lack of an editor - it's lack of language tooling
17:47:09FromDiscord<spoon> all i want besides that is treesitter grammar, i know a few small editors/projects that are waiting on nim treesitter grammars to be complete to include syntax highlighting
17:47:34FromDiscord<Andreas> In reply to @Gumbercules "The problem isn't lack": what tooling is missing ?
17:48:22FromDiscord<Gumbercules> In reply to @Andreas "what tooling is missing": Well - for one, a working version of Nimsuggest that doesn't spawn an insane number of processes and leak like a sieve
17:48:41FromDiscord<Gumbercules> Every time I use Nimsuggest and I want to re-compile Nim, it's a giant PITA
17:49:07FromDiscord<Gumbercules> I'd also venture that people would like more refactoring tools
17:49:11FromDiscord<Andreas> In reply to @Gumbercules "Well - for one,": true, but it got beeter since nimlsp controls nimsuggest..
17:49:17FromDiscord<Gumbercules> Basically the environment needs to be able to parse and understand Nim code better
17:50:10FromDiscord<Andreas> In reply to @Gumbercules "Basically the environment needs": my impression was, that nimsuggest struggles most when macros come into play. It would be nice to be able to deactivate that.
17:50:22FromDiscord<Phil> In reply to @Gumbercules "I'm just not sure": In tooling?
17:50:27FromDiscord<Gumbercules> In reply to @Isofruit "In tooling?": Yes
17:50:31FromDiscord<Gumbercules> In reply to @Andreas "my impression was, that": I has no idea
17:51:34FromDiscord<spoon> i gtg but here is an example of an editor waiting for treesitter grammar↵https://github.com/helix-editor/helix/issues/3117↵and a plugin↵https://github.com/nvim-treesitter/nvim-treesitter/issues/3011
17:52:34FromDiscord<Andreas> In reply to @spoon "i gtg but here": add Zed to the list
17:52:55FromDiscord<Gumbercules> https://gist.github.com/Aerijo/df27228d70c633e088b0591b8857eeef
17:53:19FromDiscord<Phil> sent a long message, see http://ix.io/4rCO
17:54:22FromDiscord<Gumbercules> Seems like some of this is out of scope for the language development team itself though
17:54:24FromDiscord<Phil> And then one thing that is special for each code area which would be better testing tooling
17:54:30FromDiscord<Gumbercules> Besides faster compile times
17:54:37FromDiscord<Phil> Yeah fair
17:54:40FromDiscord<Phil> Ohh!
17:54:44FromDiscord<Phil> Nimpretty improvements
17:54:47FromDiscord<Gumbercules> Ah yeah
17:54:49FromDiscord<Gumbercules> Nimpretty blows
17:54:56FromDiscord<Gumbercules> that's a good one
17:54:56FromDiscord<Phil> An actual propper linter
17:55:46FromDiscord<Andreas> In reply to @Isofruit "And then one thing": how about the `testing with balls`-thinggy ?
17:56:29FromDiscord<Phil> In reply to @Andreas "how about the `testing": for the basics std/unittest is adequate, but I wish we had ways to make it easier to test your owlkettle, jester or prologue application
17:56:41FromDiscord<Phil> For a propper test I have to compile the project, start the server and then use a client to poke the server
17:57:05FromDiscord<Gumbercules> Sounds like Nim needs a mock http server
17:57:06FromDiscord<Phil> Test-tooling that would make the entire part that compiles and starts the server (and corresponding database) easier would be really nice
17:58:00FromDiscord<Phil> I still have no clue how I'll end up testing owlkettle tbh other than the backend
17:58:02FromDiscord<Andreas> In reply to @Isofruit "Test-tooling that would make": i would use the `tearup/teardown`-sections - isn't that enough..
17:58:17FromDiscord<jmgomez> I would add more support for the NimVM as standalone application. In the sense of being able to bind anything easily
17:58:45FromDiscord<Phil> In reply to @Andreas "i would use the": You can absolutely do that there, but you still have to first write the code that does all the things
17:58:50FromDiscord<jmgomez> That would be a game changer. Im in the midle of preparing a demo and it's really a game changer
17:59:10FromDiscord<jmgomez> like 100<ms iteration times
17:59:36FromDiscord<Phil> sent a long message, see http://ix.io/4rCS
18:00:37FromDiscord<Gumbercules> I think this kind of stuff is better framed as - what tooling does prologue need?
18:00:46FromDiscord<Gumbercules> or insert web dev framework name
18:00:52FromDiscord<Phil> In reply to @Gumbercules "I think this kind": It's an issue ... yeah that,
18:01:01FromDiscord<Phil> If I used jester I'd say the same thing
18:01:11FromDiscord<Phil> And I believe it might also be true for owlkettle
18:01:14FromDiscord<Gumbercules> But this is also one of the problems
18:01:23FromDiscord<Gumbercules> at one point, the dev team got bored of building actual tooling
18:01:31FromDiscord<Gumbercules> and thought it'd be a good idea to try and write an ORM
18:01:41FromDiscord<Gumbercules> or a snake game etc
18:02:01FromDiscord<Gumbercules> or web forums
18:02:02FromDiscord<Andreas> In reply to @Isofruit "I had to write": sure, buts that has not been not too much work, i'd doubt a framework could provide such stuff..
18:02:08*derpydoo quit (Quit: derpydoo)
18:02:19FromDiscord<Phil> I mean, it's not like it's insanely hard to do all of that without the tooling, but it'd be nice if there were some way to make it easier
18:04:05*derpydoo joined #nim
18:04:34FromDiscord<Gumbercules> ops are always a pain
18:04:59FromDiscord<Gumbercules> In my almost two decades of web dev experience - you're either using something like Docker these days or mocking stuff
18:05:31FromDiscord<Gumbercules> if you're using docker - you don't need to write any code to launch your database sidecar
18:05:49FromDiscord<Gumbercules> and often - people are using some sort of library that provides migrations for their database to handle the creation of the actual database / tables etc
18:06:16FromDiscord<Gumbercules> they're also using some unit testing library that allows them to standup and teardown their schema between test runs
18:06:45FromDiscord<Gumbercules> if you want a good example of a good web framework - look at Elixir and Phoenix
18:07:33FromDiscord<Gumbercules> https://www.phoenixframework.org/
18:07:47FromDiscord<jmgomez> In reply to @Gumbercules "if you want a": played with it back in the day. WOuldnt be cool Nim bindings for the erlang vm? 😄
18:08:26FromDiscord<Andreas> In reply to @jmgomez "played with it back": there has been smth. published already..
18:08:29FromDiscord<Gumbercules> why not just write a BEAM backend for Nim?
18:08:47FromDiscord<jmgomez> In reply to @Andreas "there has been smth.": oh really?
18:08:55FromDiscord<jmgomez> In reply to @Gumbercules "why not just write": Dunno, sounds like more work?
18:09:02FromDiscord<Gumbercules> Possibly, I'm not sure
18:09:04FromDiscord<jmgomez> but yeah, that would be killer
18:09:06FromDiscord<Andreas> In reply to @Gumbercules "why not just write": 'cos that'll take decades 🙂
18:09:09FromDiscord<Gumbercules> No
18:09:15FromDiscord<Gumbercules> https://github.com/llaisdy/beam_languages
18:09:54FromDiscord<Gumbercules> I don't think you'd end up with something that had the selling points of Erlang or Elixir either
18:10:20FromDiscord<Gumbercules> Mostly because those languages are designed to take advantaege of BEAM's architecture. Nim is not
18:10:26FromDiscord<Gumbercules> I think Zevv is trying to do something similar with Nim
18:10:32FromDiscord<Dimi> Hey. I have a quick question. How can I access and update variable from main thread and spawned thread. I'm asking because my variable if flagged with {.threadvar.} has its own value for every thread and {.global.} pragma also doesn't help
18:10:42FromDiscord<Dimi> (edit) "Hey. I have a quick question. How can I access and update variable from main ... thread" added "the"
18:10:46FromDiscord<Gumbercules> https://github.com/zevv/actors
18:11:01FromDiscord<Gumbercules> In reply to @Dimi "Hey. I have a": use locks and shared memory
18:11:06FromDiscord<jmgomez> what do you think makes so different erlang from Nim? Dynamism?
18:11:12FromDiscord<Gumbercules> That's one major thing
18:11:13FromDiscord<jmgomez> (edit) "erlang" => "elixir"
18:11:33FromDiscord<Gumbercules> Be back in a moment, need to change a poopy diaper
18:11:55FromDiscord<Dimi> In reply to @Gumbercules "use locks and shared": Thanks. Too complicated comparing to Golang
18:12:11FromDiscord<Andreas> In reply to @jmgomez "oh really?": nimler https://github.com/wltsmrz/nimler
18:14:04Zevvthat actors thing mostly works. I can spawn a million in a few seconds and have them do stuff
18:14:39Zevvhave to jump through hoops to allow nim to properly move memory between threads because ARC is trying in every way to mess that up when you're not looking
18:14:52Zevvwith ORC it's not even possible yet. I'd love to be proven wrong on that to
18:14:53Zevvtho
18:19:36FromDiscord<Dimi> Anyone can give me the link to the documentation on how to use locks and shared memory to access variables from the main thread and spawned thread?
18:20:11FromDiscord<Andreas> @zevv hi, i tried bitline yesterday - had to change some imports - but `bitline perf.txt` takes 2min to start and shows no data ? tried `bitline -s perf.txt` same thing ?
18:20:57FromDiscord<Andreas> (edit) "@zevv ... hi," added ""
18:21:01Zevvpff not sure what state it is in I must admit
18:21:05ZevvI didn't know i had any users
18:21:35Zevvthe format changed a few times so I'm not sure if the tools match the binary anymore
18:21:38Zevvgimme a few mins
18:21:51FromDiscord<Andreas> In reply to @Zevv "I didn't know i": at least one - i'd like to use to like the Activity-App on mac, showing perf-stats
18:22:03FromDiscord<Gumbercules> In reply to @Dimi "Anyone can give me": https://github.com/nim-lang/Nim/blob/devel/tests/threads/tmanyjoin.nim
18:22:43FromDiscord<Gumbercules> In reply to @Andreas "nimler https://github.com/wltsmrz/nimler": This just lets you write functions to be able to call from Erlang / Elixir
18:22:59FromDiscord<Gumbercules> Similar to Nim's C/C++ interop
18:23:06FromDiscord<Andreas> In reply to @Gumbercules "This just lets you": it's a start, isn't ?
18:23:16FromDiscord<Gumbercules> Well I think it's a start and an end
18:23:43FromDiscord<Andreas> In reply to @Gumbercules "Well I think it's": what's on your mind ?
18:24:00FromDiscord<Gumbercules> If you truly wanted to target the BEAM with Nim you'd do something like this - https://www.slideshare.net/hamidreza-s/create-your-own-language
18:24:00FromDiscord<Andreas> (edit) "In reply to @Gumbercules "Well I think it's": what's on your mind ? ... " added "A full nim-backend ?"
18:25:16FromDiscord<Gumbercules> probably a bad example - let me try to find something else that shines light on the process
18:25:28FromDiscord<Gumbercules> https://www.programmingtalks.org/talk/implementing-languages-on-the-beam
18:25:30FromDiscord<Gumbercules> I think this is better
18:26:22ZevvAndreas: perf works for me
18:26:59ZevvI did the stuff from the comments in perf2event.nim
18:27:14Zevvthen run perf2event.nim to convert perf.txt to bitline format
18:27:20Zevvand just run `bitline perf.stuff`
18:27:41FromDiscord<Gumbercules> https://www.erlang-factory.com/upload/presentations/523/EFSF2012-Implementinglanguages.pdf is probably good too
18:28:11ZevvAndreas: http://zevv.nl/div/bl.png
18:30:45FromDiscord<Dimi> In reply to @Gumbercules "https://github.com/nim-lang/Nim/blob/devel/tests/th": So if I have "var videoArray : seq[string]" variable, I need to access from main and thread, I have to incorporate it along with the object which has Lock var + create pointer additionally?
18:31:09FromDiscord<Gumbercules> In reply to @Dimi "So if I have": You'd just need the sequence and a lock
18:31:18FromDiscord<Gumbercules> assuming you're using ARC/ORC and not the refc GC
18:31:49FromDiscord<Gumbercules> alternatively you could create a lock free version of sequence and use atomics or something else to control access
18:32:11FromDiscord<Gumbercules> but you wouldn't be able to use this seq with the stdlib - so there's not much point
18:32:50FromDiscord<Gumbercules> It's pretty much the same way you'd do this type of stuff in C/C++
18:33:12FromDiscord<jmgomez> In reply to @Gumbercules "Well I think it's": ideally you would do both. For pure CPU erlang/elixir is not that good
18:33:13FromDiscord<Gumbercules> If you don't want to have to deal with locks you can use channels
18:33:43FromDiscord<jmgomez> but yeah, you are right. In the general case it's much better to implement nim with it
18:33:47FromDiscord<Gumbercules> In reply to @jmgomez "ideally you would do": Yeah - I just meant that you're not going to end up with a language that can run on the BEAM VM with just NIFs solved
18:33:56Zevvdon't use the nim-lang/thrading channels, they're borked and broken
18:34:09FromDiscord<jmgomez> (edit) "nim" => "a lang" | "it" => "nim"
18:34:24FromDiscord<Gumbercules> Do the Nim developers know this 😃 ?
18:34:56ZevvDunno.
18:34:56Zevvhttps://github.com/nim-lang/threading/issues/24
18:35:16Zevvactually, it's just a mess.
18:35:36Zevvthe whole thing should be just a dequeue with a mutex and a condition variable, no more no less
18:35:54Zevvbut it's 400+ lines and they are wrong
18:36:25FromDiscord<Gumbercules> Boggles my mind people aren't testing multithreaded code with valgrind / asan
18:36:34Zevvpreaching to the choir
18:36:47ZevvI pointed out to a few projects that their code is not running clean under helgrind
18:37:02ZevvI consistently get the answer "helgrind is giving false positives, i know what I'm doing"
18:37:04FromDiscord<Gumbercules> Maybe we do all need Rust
18:37:06Zevvi gave up on that
18:37:11FromDiscord<Gumbercules> Heh
18:37:41ZevvI spent over a month with this actors stuff to get it clean on helgrind and friends
18:37:54Zevvit's hell. but I trust that stuff.
18:38:58ZevvI was shocked to only properly learn all these details about the C/C++ memory model and threading in my 40's. And now i'm shocked about how few people know this stuff.
18:38:58FromDiscord<Gumbercules> yeah - I've been there as well
18:39:12ZevvI've had nice talks with seniors and professionals, and they all just have it wrong
18:39:13FromDiscord<Dimi> In reply to @Gumbercules "It's pretty much the": I was learning C/C++ 20 years ago, then was working with Python, Go. Now I found Nim as a perfect combination of small binary size (this is important for me though), speed and simple syntax. But when I approached threads, then I've been lost in syntax and possibilities. Thanks. I will check this docs and options out
18:39:14Zevvtime after time.
18:40:08FromDiscord<Gumbercules> In reply to @Dimi "I was learning C/C++": Yeah, Nim's concurrency model is nothing like Golang's but if you want you can use Boehm and then some of this stuff is easier
18:40:15FromDiscord<Gumbercules> but now you have a stop the world GC
18:40:37FromDiscord<Dimi> In reply to @Gumbercules "If you don't want": Yes. I've dealt with the channels already. Thanks for the idea
18:41:16FromDiscord<Dimi> (edit) "In reply to @Gumbercules "If you don't want": Yes. I've dealt with the ... channels" added "Nim"
18:43:54FromDiscord<Gumbercules> In reply to @Zevv "I've had nice talks": Doesn't take much to become an expert in things these days
18:44:02FromDiscord<Gumbercules> Or claim to be one rather
18:44:07FromDiscord<Gumbercules> (edit) "Or ... claim" added "to be able to"
18:44:45Zevvi'm no expert
18:45:06FromDiscord<Gumbercules> err I was referring to the seniors and professionals 😛
18:45:33Zevvwell, these were people I regard as professionals, they know where their towel is at
18:45:39Zevvbut not in this particular subject, it seems
18:47:22FromDiscord<Gumbercules> https://media.discordapp.net/attachments/371759389889003532/1088534468257665135/thistall.png
18:47:24FromDiscord<Gumbercules> there's a reason this exists
18:47:40Zevvi do agree with that one
18:48:34Zevvthe only reason for writing actors was so that i do not have to write any more threading code
18:48:43Zevvjust parallelize by default and don't care shit about it
18:49:24FromDiscord<Gumbercules> definitely a sound approach
18:52:17FromDiscord<Andreas> In reply to @Zevv "then run perf2event.nim to": i'll do - forget the conversion step - thx
18:53:27FromDiscord<Gumbercules> It's fun to reread that blog post and be reminded of how old I am
18:55:30FromDiscord<Gumbercules> Not in my 40s yet though 😓
18:55:40FromDiscord<Gumbercules> (edit) "😓" => "😅"
18:55:44FromDiscord<Gumbercules> Just very close
18:56:01*xet7 quit (Quit: Leaving)
18:56:20*xet7 joined #nim
18:58:26*beholders_eye quit (Ping timeout: 252 seconds)
19:01:06FromDiscord<guzba> re: multithreading, seems like it would be better to have people go ahead and make some mistakes and learn↵peeps gata learn somehow after all↵this does not apply to stdlib code or many workplace settings of course, but for personal projects or whatever, i dunno about the fear advice
19:04:04Zevvfair point, in the end you want people to learn and understand that stuff, true. My point is that people are just overconfident in this subject.
19:04:50Zevvyou *should* be afraid. The problem is that threading in C and C++ is "just hard" as long as you keep to the basic rules
19:05:05Zevvlike, only share date when writer and reader use the same lock
19:05:14Zevvbut in nim, things still blow up in your face when you do that
19:05:21Zevvin Nim, it's harder than in C or C++
19:05:34Zevvbecause ARC is really not helping here.
19:06:04Zevvyou can do your best to protect your data, but who is protecting the ARC ref counters
19:06:22Zevvthese are not atomics, but you can't put a lock around the RC ops, because these are injected by the nim compiler
19:06:42Zevvso write yourself some simple threaded code in nim. feel free to add some .gcsafe. pragmas as advised by the experts
19:06:54Zevvrun it in helgrind or tsan, and then think about what is happening with these reference counters
19:07:05Zevvthese are just solid old fashioned data races.
19:07:41Zevvwith ORC it's even more fun because orc referenced data points back to a threadvar. So move your data between threads and expect a good time.
19:07:57FromDiscord<guzba> it is very true nim is another layer of stuff to think about, and that is assuming youre arc/orc, let alone the refc legacy right now
19:10:33FromDiscord<guzba> i dont really have any disagreement with the facts in the convo, just pointing out that the intent is probably not to stop people from experimenting with threads on their own↵its more about what to watch out for and perhaps dont go do that exploring at work where other ppl will experience pain from mistakes haha
19:11:00Zevvsure, I agree.
19:12:22FromDiscord<guzba> an example of a perhaps negative outcome of thread-fear is that instead we get in situations where tons of single-thread processes run on tiny vms that have to get orchestrated through k8s↵as opposed to one server with some threads handling tons of requests in parallel↵is the thread complexity worse than the sysadmin complexity?
19:13:09Zevvif the thread complexity leads to broken code, yes, it is worse
19:13:42Zevvbecause it is broken in undefined ways. It is literally undefined behavior. It works on machine A, it does not on machine B. It works on today, but not tomorrow. If it does not work, it can do so in very sneaky ways.
19:14:14Zevvit's not just throwing you a big SIGSEGV, because that would be obvious. It just adds up your bank balance wrong once every few months.
19:14:26Zevvthen you run it in a debugger, and the problem goes away.
19:15:22FromDiscord<guzba> i propose not all uses of threads are equally complex or dangerous, and often the dangerous part can be handled by a tested dependency (where stdlib should be helping for example)
19:16:31*oddish quit (Ping timeout: 240 seconds)
19:16:40FromDiscord<guzba> its hard to argue against fear, but i would just say that it totally can be done
19:16:43Zevvwhich is exactly my point; use other - proven - primitives.
19:16:59*adigitoleo quit (Ping timeout: 268 seconds)
19:17:25FromDiscord<guzba> i am optimistic that nim 2.0 making --threads:on the default will improve the threading primitive situation
19:17:27Zevvanyway, everyone to it's own. I have found that with threading I'm generally just not smart enough to do it right without spending a humongous amount of mental effort.
19:17:37FromDiscord<guzba> defaults are powerful for sure
19:17:47Zevvthe problem imho is that nim kind of lacks any sane threading model, still.
19:17:58Zevvthe core team points to nim-lang/threading, which is proven broken.
19:18:16Zevvalso, I do not have any proper solutions, so I don't have the right to whine about it of course
19:18:32*oddish joined #nim
19:18:43FromDiscord<guzba> In reply to @Zevv "also, I do not": totally respectable
19:18:46*adigitoleo joined #nim
19:18:52Zevvbut the fact that ARC makes stuff even more fragile than when doing thigns with manual memory is not helping.
19:19:14FromDiscord<guzba> yes i have just manually managed memory in many cases internal to libs because arc/orc are not helpful at all in this context
19:19:18FromDiscord<guzba> so im onboard with the pain
19:19:44ZevvI briefly considered adopting the nim-lang/threading repo and clean it up and add a solid test suite, but I couldn't get myself to go there.
19:20:25FromDiscord<guzba> everything is difficult and in the end open source work needs to be for your own satisfaction so its np to just not feel like doing it imo
19:21:20FromDiscord<Andreas> In reply to @Zevv "but the fact that": hmm, good to know, how about trying lock-free concurrent-data-structures, memory-handling has to be done without any GC, so maybe arenas/pools or RCU or a combination of that..
19:22:43*derpydoo quit (Ping timeout: 268 seconds)
19:22:44Zevvit's a pain to have to fall back to manual memory managent. IMHO nim needs an atomic RC type
19:22:55Zevvyou can build those yourself but they will not act like a regular ref
19:23:09Zevvso you'll need to explicitly handle them
19:23:16FromDiscord<guzba> i agree there it would be very helpful to at least see a canonical example of one that really works
19:23:19Zevvyou can't just assign and move and copy
19:23:36Zevvone what that really works?
19:23:59FromDiscord<guzba> an example of a atomic rc data type that uses nims arc/orc hooks
19:24:26Zevvhttps://github.com/zevv/actors/blob/master/actors/pool.nim#L83-L109
19:24:50Zevvbut using it is a pain because you have to deref[] it all the time
19:25:02Zevvbut yeah, it works.
19:25:24FromDiscord<guzba> still useful to see even so
19:25:25FromDiscord<guzba> cool
19:25:30ZevvI should make a little generic wrapper for that instead of putting it there though
19:27:32FromDiscord<guzba> everything takes effort but a little repo with discussion of how it works and why it needs to be used a certain way could be a useful thing for people to link to and learn from↵ive always learned a lot from relatively focused examples and some good explanation of why
19:28:07FromDiscord<guzba> perhaps it will lead to improvements on ergonomics or something in addition to shared knowledge
19:28:23ZevvI feel it should be part of the language instead.
19:29:09FromDiscord<guzba> a good step toward that is a clear understandable 'what it is' for other folks maybe
19:29:17Zevvdisruptek uses a fork of the default nim stdlib with only one change where the ARC rc value is an atomic. It solves so many problems.
19:29:32Zevvbut yes, there is a performance penelty.
19:29:38Zevvpentaly
19:29:57FromDiscord<Andreas> In reply to @Zevv "pentaly": i thinks it petally
19:30:13Zevvpenalty, damned
19:31:10FromDiscord<Gumbercules> I just manually manage memory when threads are involved
19:31:12FromDiscord<Gumbercules> it's not that bad
19:31:22Zevvthen why use nim at all.
19:31:25FromDiscord<Gumbercules> But I understand the desire for things to "just work" and not to have to resort to that
19:31:29Zevvno seqs, no refs, no tables.
19:31:37Zevvno strings
19:31:40ZevvI might as well go back to C
19:31:44FromDiscord<Gumbercules> no I mean, I still use those
19:31:51FromDiscord<Gumbercules> I just don't use them in the context of multiple threads
19:31:58Zevvsure.
19:32:14FromDiscord<Andreas> In reply to @Zevv "no seqs, no refs,": no, just exclude the shared values from ARC/ORC and have them in a pool
19:32:16FromDiscord<Gumbercules> so like - if I need a data structure that is thread safe i'll write one and manually manage the memory
19:32:24FromDiscord<guzba> imo it is true that manual memory management at the thread boundary is often not a huge thing
19:33:05Zevvanyway, i'm ranting the same rant like an old man; Nim has no good story on how to do threading in 2023; my phone has 20 cores, and as a system language Nim has no solid and friendly way to utilize these. Other languages have gone a long way solving these problems.
19:33:28ZevvI do not want to *think* about threading. I have a compiler to do that work for me.
19:33:30FromDiscord<Gumbercules> well - we're in a much better place than when we only had the refc GC implementation at least
19:33:41FromDiscord<guzba> In reply to @Gumbercules "well - we're in": so much better
19:33:44FromDiscord<guzba> agreed
19:33:50FromDiscord<Gumbercules> but yeah - it's still not ideal by a long shot
19:34:29FromDiscord<Gumbercules> and I don't think it every will be unless Nim's adopts something like a borrow checker
19:34:37FromDiscord<guzba> this is why i want nim 2.0 so bad, even if it isnt a perfect thread solution, it is seriously enormously better than refc default today
19:35:25Zevvtrue; and stuff *can* be done with nim 2.0, but it is really a huge pain in the ass.
19:35:33FromDiscord<Gumbercules> (edit) "every" => "ever"
19:35:44FromDiscord<guzba> i guess im just happy a huge pain in the ass is way better than dont even bother
19:35:46FromDiscord<guzba> haha easy to please
19:36:32FromDiscord<guzba> i think after nim 2.0 stuff is out your ergonomics and compiler wants will become more of a focus in time, that is my estimation
19:37:52Zevvwe'll see. I might be not well informed, but I feel that other than disruptek and me not many people have been going deep into multithreading on nim 2.0 yet.
19:38:20FromDiscord<System64 ~ Flandre Scarlet> In reply to @Zevv "it's a pain to": What is atomic in this case?
19:38:23Zevvof course mratsim, but he is just doing manual memory
19:38:27FromDiscord<Gumbercules> I have been - but I also don't use ref counted memory with threads
19:38:30FromDiscord<Gumbercules> yeah - same
19:38:45FromDiscord<Elegantbeef> Zevv i'm still a bit confused how atomic RCs solve anything
19:38:45ZevvSystem64 ~ Flandre Scarlet: atomic, as in, the RC is an atomic int
19:39:03Zevvbeef: the problem they solve is the nimDecRefLast and friends
19:39:17FromDiscord<Elegantbeef> Yes the ref count is now properly threadsafe, but if you mutate a tree it's still a race condition
19:39:31FromDiscord<Elegantbeef> Ok so it's purely just for ensuring the mm doesnt kick in
19:39:35FromDiscord<guzba> they solve the hand-off but not the other state problem
19:39:55Zevvwell, not just "Does not kick in", it's worse because the RC value becomes undefined
19:40:00*rockcavera quit (Read error: Connection reset by peer)
19:40:03Zevvit can be too high or too low
19:40:20FromDiscord<Elegantbeef> I mean that's what i meant
19:40:24FromDiscord<guzba> i would imagine usually too high since it probably read-dec-write which would mean missing decs
19:40:38Zevvas for moving trees, that is also an unsolved one. I have this little macro that run time checks if a tree is isolated by peeking the RCs in front of the refs, but it's a dirty hack
19:40:40*rockcavera joined #nim
19:40:40*rockcavera quit (Changing host)
19:40:40*rockcavera joined #nim
19:41:16Zevvguzba: it doesn't matter if its' too highr o too low, it's just undefined. it's wrong either way.
19:41:19FromDiscord<firasuke> sequences vs tables for sequences of `string, seq[string]`?
19:41:50FromDiscord<guzba> In reply to @Zevv "<@318284269908918273>: it doesn't matter": its true, no disputing that, though i would take a memory leak over a double-free
19:42:01Zevvand then there is ORC, which happens to be the default mm and makes this not possible at all.
19:42:12Zevvwith ORC, you simply can not move a ref. period.
19:42:47FromDiscord<guzba> if you tag acyclic it appears to accidentlly be move-able in 1.6.x
19:42:57FromDiscord<System64 ~ Flandre Scarlet> Moving a ref?
19:43:03*rockcavera quit (Read error: Connection reset by peer)
19:43:07Zevvmove a ref to another thread.
19:43:09FromDiscord<guzba> `let b = move a`
19:43:12FromDiscord<guzba> or across threads
19:43:15Zevvyeah sure you can go annotate everything acyclic
19:43:22Zevvuntil you actually want to move cyclic data, right
19:43:23FromDiscord<System64 ~ Flandre Scarlet> It's useful
19:43:36*rockcavera joined #nim
19:43:36*rockcavera quit (Changing host)
19:43:36*rockcavera joined #nim
19:47:06Zevvone last thing and then I'll probably drop out: I don't think run time isolating a tree can be properly done at this time as well; I have this little macro that recursively traverses my type to check if nothing in that three gets reffed from elsewhere, but when I have an inherited object type that got converted to a parent type, there is no way for the macro to do that. So I don't think this can be made
19:47:12Zevvproperly safe at this time.
19:47:24*Notxor joined #nim
19:47:49FromDiscord<Elegantbeef> Hmmm you might be able to with RTTI
19:48:06FromDiscord<guzba> it would seem that if traversing the tree is not an atomic operation itself it could be raced even if it could work
19:48:38FromDiscord<System64 ~ Flandre Scarlet> I have the feeling threading is always unsafe
19:48:42FromDiscord<Elegantbeef> Of course one needs to not mutate a tree whilst ensuring isolation
19:48:45Zevvthe assumption is that the sender is the only one reffing anything at the time I check the isolation. The whole thing is built on assumptions.
19:49:01Zevvbeef: how would that work with RTTI
19:49:06FromDiscord<Elegantbeef> Threading is pretty safe assuming you use `Channels`
19:49:09Zevvthis is my - naive - impl: https://github.com/zevv/actors/blob/master/actors/isisolated.nim
19:49:19FromDiscord<Elegantbeef> Nim's RTTI does allow checking fields
19:49:46Zevvsure, but the problem is that I can have an inherited type that is converted to a parent type.
19:50:06Zevvso fieldpairs() will not do the right thing.
19:50:14FromDiscord<Elegantbeef> So you'd recurse the object checking ref count and keeping track of which ref's are ref'd
19:50:27FromDiscord<Elegantbeef> I didnt say field pairs
19:50:28FromDiscord<Elegantbeef> I said RTTI
19:50:33Zevvso how do I use that
19:50:37FromDiscord<Elegantbeef> https://nim-lang.org/docs/typeinfo.html
19:50:39FromDiscord<Elegantbeef> The typeinfo module that is hardly ever used
19:50:51FromDiscord<System64 ~ Flandre Scarlet> Not using threading would solve all problems
19:50:52ZevvI tried it a few times, but I was not having a good time.
19:51:13ZevvSystem64 ~ Flandre Scarlet: except for the problem of having 31 of my 32 cores sitting idle
19:51:14FromDiscord<Elegantbeef> Yea it's fully undocumented and i'm still uncertain if you can get the downcasted type
19:51:22FromDiscord<guzba> In reply to @System64 "Not using threading would": pass on that
19:51:42FromDiscord<Elegantbeef> Not having threading is fine when everyone is rocking a c64
19:51:45Zevvbeef: i'll look into the typeinfo, if I can find the courage
19:51:45FromDiscord<System64 ~ Flandre Scarlet> In reply to @guzba "pass on that": Wdym?
19:52:05FromDiscord<Elegantbeef> In theory it should work assuming you can get the downcasted type
19:52:08*xet7 quit (Quit: Leaving)
19:52:13FromDiscord<System64 ~ Flandre Scarlet> In reply to @Zevv "System64 ~ Flandre Scarlet:": How to make it safe then?
19:52:35ZevvSystem64 ~ Flandre Scarlet: indeed, how to make it safe, excellent question
19:52:35FromDiscord<Elegantbeef> Channels, atomics, locks, manual memory management, ....
19:53:04Zevvpersonally, falling back to manual mm is not acceptable, PR wise
19:53:05FromDiscord<guzba> In reply to @System64 "Wdym?": i am using threads successfully in production right now with nim 1.6.10+ and its something i would not give up↵async is not ideal lets say, and many processes is just odd in its own way↵throwing out threads altogether is not a solution i accept is all
19:53:09FromDiscord<System64 ~ Flandre Scarlet> I guess Java is also unsafe at this level?
19:53:20FromDiscord<guzba> (edit) "In reply to @System64 "Wdym?": i am using threads successfully in production right now with nim 1.6.10+ and its something i would not give up↵async is not ideal lets say, and many ... processes" added "single-threaded"
19:53:40Zevvone selling point of nim 2.0 is that the heap is shared so memory can be moved. But in practice, this is not yet the cased.
19:54:26FromDiscord<guzba> it is the case, just with specific and very sharp caveats is maybe my slightly different perspective
19:55:16Zevv`move` implies refs. but refs are not safe to move. so I say, no, it is not
19:55:34FromDiscord<guzba> `move` string can be a huge deal, could be a many gig buffer
19:55:42FromDiscord<guzba> same for seq etc
19:55:46Zevv`move` anything can be a huge deal.
19:56:00FromDiscord<guzba> refs + cyclic does work, with the same kind of assumptions mentioned for isolation
19:56:06FromDiscord<guzba> (edit) "cyclic" => "acyclic"
19:56:09FromDiscord<guzba> acyclic
19:56:40Zevvhow do you move a acyclic ref without violating the RC data race
19:58:10Zevv(it *can* be done)
19:58:20FromDiscord<guzba> in my experimenting if a ref object has only one owner on one thread, you can move it to another thread
19:58:28FromDiscord<Elegantbeef> Moving the root should all that needs to be done
19:58:31FromDiscord<guzba> yeah
19:59:40Zevvsure, it can be done, I do it as well. but it's just too finicky. I think we all agree, right :)
20:00:00FromDiscord<guzba> yes im not at all trying to dispute the finickyness haha
20:00:00FromDiscord<Elegantbeef> I do not thread pretty much ever so no clue
20:00:27Zevvgood man.
20:00:32FromDiscord<guzba> half-full vs half-empty perspective. i see what i have now and am pleased (move + shared heap), you see what we should have and are less pleased lol
20:00:46Zevvi'm a whiner by nature.
20:00:50FromDiscord<guzba> perhaps 10% full 90% empty
20:00:51FromDiscord<guzba> to be fair
20:00:53FromDiscord<guzba> lolol
20:01:03FromDiscord<guzba> ah its not that bad
20:01:08Zevvalso, I have done multithreading in different languages and tasted the fruit of what is possible
20:01:31FromDiscord<System64 ~ Flandre Scarlet> I'll have to do a game server and seems I'll have to use threading
20:02:18FromDiscord<guzba> async is the much more popular choice today for networking without threading, unless you to offload work to threads↵so maybe you will not need threads at all
20:02:29FromDiscord<guzba> (edit) "async is the much more popular choice today for networking without threading, unless you ... to" added "need"
20:02:44ZevvI am a firm believer in the actor model and in FP, because both these concepts are very good of hiding all the gory details of threading and offer seamles paralellism
20:02:53FromDiscord<Gumbercules> In reply to @Zevv "also, I have done": languages that have the performance characteristics of Nim?
20:03:16FromDiscord<System64 ~ Flandre Scarlet> In reply to @guzba "async is the much": Problem is when you need to run multiple instances of the server
20:03:18*xet7 joined #nim
20:03:27Zevvponylang comes a long way, but the 12 different ref and pointer types and conversion rules do hurt my brain.
20:04:02FromDiscord<guzba> In reply to @System64 "Problem is when you": yeah, its the single-thread + many vm/process versus threads thing, well certainly i hope you find a solution that is productive when you work on that
20:04:12Zevvand given the number of cores in recent hardware, I'd happily give up 50% of my language performance if I can actually utulize these extra cores without effort.
20:05:21FromDiscord<System64 ~ Flandre Scarlet> In reply to @guzba "yeah, its the single-thread": There is 2 approaches↵1) multithread (UNSAFE! risk of Segmentation fault core dumped)↵2) one thread, servers are updated one by one
20:05:22FromDiscord<Gumbercules> I just don't think everyone is in the same boat
20:05:42Zevvanyway, I think with my actors experiment, which is basically CPS on top of N threads, I have proven for myself that things could be possible with nim. Performance is very reasonable, overhead is low.
20:07:34Zevvbut ergonomics is lacking
20:07:38FromDiscord<guzba> In reply to @System64 "There is 2 approaches": if you are not pretty familiar with threads, i do think you'll have less pain with the option 2, especially if youre writing a game which is just so much work as it is↵however option 1 is viable if youre willing to fight for it and maybe age a decade for it
20:08:00Zevvdoing the FUD thing yourself now eh :)
20:08:15FromDiscord<guzba> i never said you were wrong 😇
20:08:25FromDiscord<guzba> just being a counterpint
20:08:29FromDiscord<guzba> (edit) "counterpint" => "counterpoint"
20:15:27FromDiscord<IsaacPaul> I think you can also use https://github.com/mratsim/weave with a scope?
20:15:50Zevvsure, weave is doing just fine, but it's just doing manual memory
20:15:56Zevvno refs for you, just pointer
20:16:22FromDiscord<IsaacPaul> Meh I accidentally sent that because my arm moved against the corner enter key :<
20:16:54FromDiscord<IsaacPaul> It was something I wrote a few hours ago 😅
20:20:01*fallback joined #nim
20:21:41FromDiscord<System64 ~ Flandre Scarlet> In reply to @guzba "if you are not": But I need a database too, common to all instances↵And all instances are in different ports and listen for packets
20:45:12*def- quit (Quit: -)
20:45:56*def- joined #nim
20:48:59*fallback quit (Read error: Connection reset by peer)
20:55:30*rockcavera quit (Read error: Connection reset by peer)
20:55:50*rockcavera joined #nim
20:55:51*rockcavera quit (Changing host)
20:55:51*rockcavera joined #nim
20:57:02FromDiscord<guzba> In reply to @System64 "But I need a": using async+await to do database queries is doable, see nim's redis lib or various postgres sync wrappers↵instances on diff ports listening is all async-able too↵not saying async is correct for you, just that it is an option if youre not eager to use threads↵i personally like threading but this is after many years of working with them in several languages, maybe i have stockholm syndrome or some
20:57:14FromDiscord<guzba> (edit) "sync" => "async"
21:01:34FromDiscord<QuiteQuietQ> talking about Nim 2.0, is it going to have better error messages?
21:07:14*advesperacit quit ()
21:09:39FromDiscord<Elegantbeef> No it's practically no different
21:10:18*def- quit (Quit: -)
21:10:33*def- joined #nim
21:13:19*fallback joined #nim
21:21:28FromDiscord<QuiteQuietQ> is there s plan to have them in the future? or is there someone working on it?
21:22:25FromDiscord<Elegantbeef> "PRs welcome"
21:23:51FromDiscord<Elegantbeef> There have been some changes to errors like the mismatch error
21:27:56FromDiscord<QuiteQuietQ> cool, maybe I will get to it one day, if I will get to like Nim
21:28:09FromDiscord<QuiteQuietQ> at the moment, I am not sure if I want to use it or no
21:32:48FromDiscord<Elegantbeef> It's pretty nice
21:43:07FromDiscord<QuiteQuietQ> it is, but what does not click for me is the use of composite data types like arrays, tuple (anonymous/named), sets and tables, and conversion between them.. the way to do feels inconsistent
21:43:35FromDiscord<QuiteQuietQ> also, I have to get used to using way to much syntactic sugar
21:43:48FromDiscord<Elegantbeef> You do not have to
21:44:01FromDiscord<Elegantbeef> I do not follow the conversion issue
21:56:01FromDiscord<QuiteQuietQ> sent a code paste, see https://play.nim-lang.org/#ix=4rDL
21:56:36FromDiscord<QuiteQuietQ> when Nim offers simplified syntax without the need to write parenthesis, why it is safer in this case?
21:56:40FromDiscord<Elegantbeef> Style insensitivity is what you're talking about first
21:57:31FromDiscord<QuiteQuietQ> ah, so the thing where `o.f()` and `f(o)` is the same... first argument resolution? or sth like that
21:58:02FromDiscord<Elegantbeef> This is a bug
21:58:12FromDiscord<Elegantbeef> Atleast afaik this is a bug
21:58:21FromDiscord<QuiteQuietQ> aha lol
21:58:41FromDiscord<Elegantbeef> `longString.splitLines().pairs` should likely call the `iterator` and error in all cases
21:58:44FromDiscord<QuiteQuietQ> all four are supposed to work?
21:58:51FromDiscord<Elegantbeef> They all should error if you ask me
21:59:08FromDiscord<Elegantbeef> `splitLines` is an iterator there is no `pairs` for it
21:59:26FromDiscord<Elegantbeef> Though this is a limitation of the method call syntax
22:02:32FromDiscord<QuiteQuietQ> that is the thing, it gets modified during compilation somehow↵e.g. `a.f(b)` is converted to `f(a, b)` right? so the parenthesis have to break it
22:02:52FromDiscord<Elegantbeef> Yes that's how it works
22:03:39FromDiscord<Elegantbeef> `splitLines` is an iterator though
22:03:43FromDiscord<Elegantbeef> That's the problem here
22:04:09FromDiscord<Elegantbeef> really you never should use `pairs` imo and just use `std/enumerate` so it's `for i, line in enumerate longstring.splitlines:`
22:05:25FromDiscord<Elegantbeef> This is a problem with iterators in general though
22:05:43FromDiscord<Elegantbeef> You cannot make a iterator that takes a inline iterator
22:09:19FromDiscord<QuiteQuietQ> hm, there is also `func splitLines` I guess that is used outside of for loops
22:09:32FromDiscord<Elegantbeef> Yep
22:09:53FromDiscord<spoon> W, A, S, D, are constants defined in naylib, the code compiles, but nimlsp keeps yelling at me https://media.discordapp.net/attachments/371759389889003532/1088585436626170076/image.png
22:09:57FromDiscord<System64 ~ Flandre Scarlet> In reply to @guzba "using async+await to do": Btw, does Nim have libs for MariaDB/MySQL or SQLite?
22:10:23FromDiscord<spoon> In reply to @System64 "Btw, does Nim have": they're in standard library
22:10:54FromDiscord<spoon> https://nim-lang.org/docs/db_mysql.html↵https://nim-lang.org/docs/db_sqlite.html
22:11:09FromDiscord<System64 ~ Flandre Scarlet> Oh very good!
22:11:41FromDiscord<System64 ~ Flandre Scarlet> The stdlib will always impress me, it's so huge!
22:12:18FromDiscord<Nilts> Can i set a var to nil or should i just use options
22:12:35FromDiscord<QuiteQuietQ> In reply to @Elegantbeef "really you never should": that is another problem for me -- to many basic things "hidden" behind imports↵importing `sequtils`, `strutils`, `strformat`, `tables` in every file gets annoying↵and decrypting an error message when you forget to import something, but still use a proc from there, is frustrating
22:12:54FromDiscord<Elegantbeef> Sure but the same thing happens in any other system language
22:13:10FromDiscord<Elegantbeef> If you do not import a library how is the language supposed to know a symbol exists somewhere
22:13:13FromDiscord<QuiteQuietQ> why wouldn't the utils and formats for strings be available directly, when strings already are? same for sequences
22:14:16FromDiscord<QuiteQuietQ> i mean the difference between accessible things with and without imports↵there is quite a lot accessible without imports, but such things are not much usable for bigger problems
22:15:45FromDiscord<QuiteQuietQ> i thinking mainly composite data types..
22:16:03FromDiscord<QuiteQuietQ> tables from `std/tables` could be accessible without import
22:16:12FromDiscord<QuiteQuietQ> that would be nice
22:16:30FromDiscord<spoon> i mean, same with c where you have to import `string.h` before calling strlen
22:16:43FromDiscord<QuiteQuietQ> unless it means compiling to many unnecessary code
22:17:04FromDiscord<spoon> i do like languages that stay out of your way without having to worry about inputs though
22:17:15FromDiscord<spoon> (edit) "inputs" => "imports"
22:17:56FromDiscord<spoon> i know nim strips the unused functions from the binary, hm
22:18:38FromDiscord<Elegantbeef> Which it does↵(@QuiteQuietQ)
22:18:57FromDiscord<Elegantbeef> Importing a module causes the compiler to parse and semantically analyse libraries
22:19:21FromDiscord<Elegantbeef> Also Nim is a system language, so it does not import everything, just as Rust, Odin, Zig, C, C++ doesnt
22:19:51FromDiscord<Elegantbeef> Say you have a specialised `tables` module that you prefer for whatever reason now you cannot call it `Table`
22:19:51FromDiscord<QuiteQuietQ> got it, and Araq said that compilation time is important to him
22:20:06FromDiscord<spoon> i will credit rust though, they have a ton of stuff available out of the box, but its compilation time sucks lol
22:20:41FromDiscord<QuiteQuietQ> In reply to @spoon "i will credit rust": hm, good point
22:20:59FromDiscord<Elegantbeef> It's not even compile time
22:21:40FromDiscord<QuiteQuietQ> In reply to @Elegantbeef "Also Nim is a": how does Nim's garbage collector comes into this? it is included in a binary?
22:22:07FromDiscord<Elegantbeef> You can manually allocate if you want, it doesnt force you to use it
22:22:08FromDiscord<QuiteQuietQ> (probably dumb question)
22:22:28FromDiscord<Elegantbeef> The GC is enabled for builtin dynamically allocated types
22:22:35FromDiscord<Elegantbeef> For Arc/Orc it's just inserted calls of `=destroy`
22:26:53FromDiscord<QuiteQuietQ> so in the final program there is no GC running? just cleverly inserted `=destroy` calls?
22:27:34FromDiscord<Elegantbeef> Orc has a cycle collector
22:27:36FromDiscord<Elegantbeef> But `arc` doesnt
22:28:46FromDiscord<PunchCake> orc is just better tbh
22:28:56FromDiscord<PunchCake> cycle collector that isnt stop the world
22:30:59*fallback quit (Quit: IRCNow and Forever!)
22:31:29FromDiscord<QuiteQuietQ> 'a' in arc is for automatic, atomic or acyclic?
22:31:37FromDiscord<QuiteQuietQ> and what is orc abbreviation?
22:31:38FromDiscord<Elegantbeef> atomic
22:31:50FromDiscord<Elegantbeef> O represents a cycle
22:32:16FromDiscord<QuiteQuietQ> 😄
22:33:46FromDiscord<spoon> isn't nim arc's whole thing not atomic? `Some people mistake Nim’s ARC for Swift’s ARC, but there is one big difference: ARC in Nim doesn’t use atomic RC.`
22:34:22FromDiscord<spoon> taken from https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html
22:34:26FromDiscord<Elegantbeef> Indeed
22:38:37FromDiscord<QuiteQuietQ> so is it atomic or no?
22:38:47FromDiscord<QuiteQuietQ> i'm confused now
22:38:54FromDiscord<Elegantbeef> No
22:39:21FromDiscord<Elegantbeef> It's not a atomic reference count, it's just an automatic ref count
22:41:49FromDiscord<spoon> telling you, just rename it DARC to avoid confusion and have a cool buzzword for marketing
22:41:55FromDiscord<spoon> :-)
23:05:01FromDiscord<Nilts> How would i make a throttled function? Preferably using the nim js utils.
23:23:44*fallback joined #nim
23:30:47*azimut quit (Ping timeout: 255 seconds)
23:38:26FromDiscord<Gumbercules> In reply to @not logged in "How would i make": Are you referring to rate limiting?
23:38:48FromDiscord<Gumbercules> Or just only being able to call a procedure every so often?
23:39:34FromDiscord<Gumbercules> If it's the latter - just use some global state to track how many times it's been invoked within whatever window you prefer
23:40:11FromDiscord<Gumbercules> Or a variable in the procedure with a global pragma
23:41:07FromDiscord<Nilts> In reply to @Gumbercules "Are you referring to": like this except in nim: https://www.geeksforgeeks.org/javascript-throttling/
23:42:12FromDiscord<Gumbercules> I mean - the code is right there then
23:42:27FromDiscord<Gumbercules> Just port it to Nim 😃
23:42:48FromDiscord<Gumbercules> It should look very similar
23:43:00*Notxor quit (Remote host closed the connection)
23:45:26FromDiscord<QuiteQuietQ> how do you schedule a proc call in Nim without blocking the rest of a program?
23:47:23FromDiscord<Gumbercules> You can use async or threads for concurrency
23:48:02*azimut joined #nim