<< 25-08-2023 >>
00:02:19FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4ErI
00:03:01FromDiscord<Elegantbeef> What keyword
00:03:09FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4ErJ
00:03:14FromDiscord<heysokam> In reply to @Elegantbeef "What keyword": `method`
00:03:38FromDiscord<Elegantbeef> Dynamic dispatch requires conversions, invalid conversions raise errors
00:03:42FromDiscord<Elegantbeef> Also do not use `inheritable`
00:03:48FromDiscord<Elegantbeef> it's `type X = object of Y`
00:03:56FromDiscord<Elegantbeef> Also you're not using `ptr T` so methods serve 0 purpose
00:04:15FromDiscord<m4ul3r> For a library, how do I generate nimble docs for all modules - can't seem to figure it out
00:04:24FromDiscord<m4ul3r> (edit) "For a ... library,nim" added "nimble" | "nimble" => "nim"
00:04:35FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4ErK
00:04:38FromDiscord<Elegantbeef> `nim doc --project ./entry.nim`
00:04:45FromDiscord<Elegantbeef> `type X = object of RootObj`
00:04:49*krux02 quit (Remote host closed the connection)
00:04:57FromDiscord<heysokam> In reply to @Elegantbeef "`type X = object": `--mm:none`
00:04:58FromDiscord<Elegantbeef> Read the messages sokam
00:05:05FromDiscord<Elegantbeef> So what?
00:05:09FromDiscord<Elegantbeef> The hell does that matter
00:05:15FromDiscord<Elegantbeef> `RootObj` is just "this is inheritable"
00:05:54FromDiscord<heysokam> thought rootobj was part of the ref issue
00:06:42FromDiscord<heysokam> In reply to @heysokam "also, talking about inheritance.": asked this, but since it wasn't answered I just went bash my head against the trial+error wall
00:07:05FromDiscord<Elegantbeef> Inheritance works with manual memory management but you need to use `ptr`
00:07:16FromDiscord<Elegantbeef> Without pointer indirection methods are 100% pointless
00:07:34FromDiscord<heysokam> kk. but what is raising exceptions there?
00:07:44FromDiscord<Elegantbeef> No clue
00:08:42FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4ErM
00:08:47FromDiscord<Elegantbeef> You're also not using methods properly
00:08:48FromDiscord<Elegantbeef> the base should be annotated `{.base.}`
00:09:27FromDiscord<heysokam> well i tried, and the lsp was saying that the method is not a base or something, and then that baseless methods are deprecated, and i don't understand either
00:09:37FromDiscord<heysokam> so for now i went try fix this first
00:09:44FromDiscord<Elegantbeef> Yea it's the checking
00:10:03FromDiscord<Elegantbeef> disable checking and you no longer get the exception warning
00:10:20FromDiscord<heysokam> what checking?
00:10:28FromDiscord<Elegantbeef> objChecking
00:10:56FromDiscord<Elegantbeef> With `--objChecks:off` it doesnt warn
00:11:16FromDiscord<Elegantbeef> Method dispatching requires checks and if the type information is 100% wrong it errors
00:11:18FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4ErO
00:11:21FromDiscord<Elegantbeef> of course they do
00:11:25FromDiscord<Elegantbeef> They're assertions
00:11:32FromDiscord<Elegantbeef> Or defects rather
00:11:39FromDiscord<heysokam> but its very different if they are assertions or if they are exceptions
00:11:46FromDiscord<heysokam> assertions work on gc:none
00:11:49FromDiscord<Elegantbeef> It's not very different
00:11:51FromDiscord<heysokam> exceptions dont
00:11:52FromDiscord<Elegantbeef> They're defects
00:12:04FromDiscord<heysokam> are defects not still exceptions?
00:12:11FromDiscord<Elegantbeef> Defects use the exception mechanisms but should not be recovered from
00:12:22FromDiscord<Elegantbeef> you of course should be using `--panics:on` so they just kill the program
00:12:24FromDiscord<heysokam> but they still use GCed memory, don't they
00:13:06FromDiscord<Elegantbeef> I mean with `--panics:on` it doesnt matter if they use gc'd memory they hard crash the program
00:13:15FromDiscord<Elegantbeef> There is no try excepting out of them
00:15:59FromDiscord<heysokam> still crashing for me with --objChecks:off
00:16:15FromDiscord<Elegantbeef> Crashing?
00:16:49FromDiscord<heysokam> `Error: '(ref exceptn)(msg: message)' uses GC'ed memory [GcMem]`
00:17:04FromDiscord<heysokam> `--warningAsError:GcMem:on`
00:17:12FromDiscord<Elegantbeef> Cannot reproduce here
00:17:25*disso-peach joined #nim
00:17:40*disso-peach quit (Remote host closed the connection)
00:18:25*disso-peach joined #nim
00:18:38FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4ErP
00:22:27FromDiscord<heysokam> i guess it was missing `base`?
00:22:45FromDiscord<Elegantbeef> No clue using methods here is still pointless
00:22:46FromDiscord<heysokam> no clue why that wasn't working and not it does
00:22:52FromDiscord<Elegantbeef> You need a pointer get runtime polymorphism
00:23:08FromDiscord<heysokam> well im just trying to understand them
00:23:30FromDiscord<heysokam> if you know a decent resource on then let me know, i would rather study than waste my time trial+error'ing 😦
00:23:30FromDiscord<Elegantbeef> They're procedures that emit a case statement to dispatch based off runtime type information
00:23:38FromDiscord<Elegantbeef> There really isnt much to them
00:23:49FromDiscord<Elegantbeef> It's not much different to using a object variant, except you have compiler support
00:24:13FromDiscord<heysokam> ic
00:24:37FromDiscord<heysokam> will use object variants, now that you mention. they almost always fit my usecase a ton better
00:25:19FromDiscord<heysokam> so basically methods create the underlying variant type? is that all they are?
00:30:13FromDiscord<Elegantbeef> No
00:30:16FromDiscord<Elegantbeef> They create a dispatch logic to call the procedures using type information
00:30:32FromDiscord<Elegantbeef> It's just like Java or C# classes and overriding a method there
00:32:13FromDiscord<heysokam> ic ty
00:46:38FromDiscord<.maverk> what does ``format`` function do in nim ?
00:47:22FromDiscord<Elegantbeef> If only there were docs to explain what procedures did
00:47:57FromDiscord<Chronos [She/Her]> Wait you mean we don't have to sacrifice a child every time to ask Lucifer to help me understand what something does in Nim?
00:48:10FromDiscord<Elegantbeef> You don't have to but you do it anyway
00:48:47FromDiscord<Elegantbeef> What's the point in living if you don't chuck a child off a cliff every once iin a while
00:53:03FromDiscord<Chronos [She/Her]> True xD
00:58:21FromDiscord<heysokam> @ElegantBeouf found a small issue in the implementation of the todo template↵cannot be used to work on the same library that contains it, because the tests for it won't pass, since it has new contents of things that are in dev inside the lib 🙈
00:58:36FromDiscord<heysokam> small issue, tbh. i don't mind it. just mentioning it
00:58:45FromDiscord<Elegantbeef> What?
00:59:19FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4ErX
00:59:58FromDiscord<Elegantbeef> You do not realise how unhelpful that is
01:00:00FromDiscord<heysokam> because the todos live in a compiletime seq
01:00:38FromDiscord<heysokam> if you have test that checks for the contents literally, to assert that nothing went wrong... then add something to the list (because its the same library, so same seq) then it doesn't match
01:01:52FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4ErY
01:02:25FromDiscord<heysokam> but just a small thing, doesn't really matter that much, so you can ignore me 🙂
01:02:38FromDiscord<Elegantbeef> Uh huh
01:05:51FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4Es1
01:06:22FromDiscord<Elegantbeef> I mean it's a compile time value if you append to it any check before will not of had those values
01:06:44FromDiscord<heysokam> also, is it possible to get the function name of where the todo is called from?
01:07:27FromDiscord<Elegantbeef> If you use the previously talked about way of getting the procedure name, sure
01:07:34FromDiscord<heysokam> was trying to find what `instantiationInfo()` contains, but didn't find much other than a `magic`
01:07:45FromDiscord<Elegantbeef> https://nim-lang.org/docs/system.html#instantiationInfo%2Cint
01:07:52FromDiscord<Elegantbeef> There is no magic
01:07:54FromDiscord<Elegantbeef> It's a tuple
01:08:21FromDiscord<heysokam> oh! im blind
01:08:26FromDiscord<heysokam> #classic
01:09:05FromDiscord<heysokam> In reply to @Elegantbeef "If you use the": i have 🐠 memory, i do not recall this
01:09:14FromDiscord<heysokam> who was talking about it? I will search
01:11:25FromDiscord<Elegantbeef> https://github.com/beef331/nimtrest/wiki/Code-snippets#get-proc-name
01:14:01FromDiscord<heysokam> ty ✍️
01:17:36FromDiscord<heysokam> why do you need to call for the owner of a dummy proc?
01:18:07FromDiscord<Elegantbeef> You need to call the owner of some symbol declared inside the procedure
01:18:08FromDiscord<Elegantbeef> A proc does not have any initialisation therefore no overhead
01:20:26arkanoiddemotomohiro: late thanks
01:20:48FromDiscord<heysokam> ic
01:21:07FromDiscord<Elegantbeef> Alternatively `type A = distinct void` could be used I guess
01:22:29*lucasta_ joined #nim
01:46:42arkanoidis the "packed" pragma the default behaviour in C?
01:46:52FromDiscord<Elegantbeef> no
01:47:23arkanoidwhat's the alignment? is it aligned to pointer size?
01:47:25FromDiscord<Elegantbeef> Compilers layout structs in a way that makes accessing fields more efficient, packed is optimising for size over speed
01:48:08FromDiscord<etra> isn't struct order guaranteed in C?
01:48:15FromDiscord<etra> (and C++ too I believe)
01:48:26FromDiscord<etra> but yeah with packed in C you also remove alignment I believe
01:48:31FromDiscord<Elegantbeef> Order does not mean alignment garuenteed
01:49:28FromDiscord<etra> I remember fighting with that in Zig because they had packed and that was the only way to assure the field order would remain the same, idk if in Nim there's an intermediary which is not packed but order guaranteed
01:49:35FromDiscord<Elegantbeef> Alignment takes up space so fields of different sizes are offset from eachother. Order inside non packed structs can change the amount of data taken up by an object, this is important for things like `seq[T]`
01:49:41FromDiscord<Elegantbeef> I mean Nim emits C
01:50:02arkanoidhttps://play.nim-lang.org/#ix=4Es9
01:51:20FromDiscord<Elegantbeef> Packing doesnt change field sizes of course
01:51:32FromDiscord<Elegantbeef> packing is hidden
01:51:45arkanoidElegantbeef, not if you do cast
01:51:54FromDiscord<Elegantbeef> What?
01:52:05arkanoidlook at the flags struct field here https://arrow.apache.org/docs/format/CDataInterface.html#structure-definitions
01:52:06FromDiscord<Elegantbeef> cast does not change field sizes
01:52:15arkanoidit is an int64_t
01:52:24FromDiscord<Elegantbeef> So what?
01:54:03arkanoidif you wrap that struct, you end up with a flag field that would naturally be a nim set of size 8 bytes, which nim can't do right now (or better you do0t have control of it)
01:54:28FromDiscord<Elegantbeef> https://github.com/MCRusher/cflags might be interested in this
01:54:52FromDiscord<Elegantbeef> It's technically a bug, but https://play.nim-lang.org/#ix=4Esb works
01:55:06arkanoidbut thanks to packing, if you cast a C struct in memory to nim, it works as the flags field goes from 1 byte to 8
01:55:39FromDiscord<Elegantbeef> Or you could just wrap the type properly and not rely on what I imagine is UB, but I do not know if it rightly is
01:55:55arkanoidUB?
01:56:04FromDiscord<Elegantbeef> Undefined behaviour
01:58:00arkanoidyeah I know that doing flags: int64 is the right thing here. I was just trying to use nim set as I always find a way to not use them lol
01:58:32arkanoidthere's always something that makes me drop set in favor of something else
01:58:50FromDiscord<Elegantbeef> You also can just do `reserved = 64`
01:59:16FromDiscord<Elegantbeef> Or `63` I guess
01:59:33FromDiscord<Elegantbeef> https://play.nim-lang.org/#ix=4Esc is a cleaner way of doing it of course
02:00:59arkanoidare enums with holes stilla thing?
02:01:06FromDiscord<Elegantbeef> Of course
02:01:41arkanoidisn't this UB anyway? I though enum with holes were kind of no-go
02:01:47FromDiscord<Elegantbeef> Nope
02:01:53FromDiscord<Elegantbeef> They're wholly supported
02:03:01arkanoiddamn, this solved the problem, again. Why Elegantbeef always knows a better way
02:04:07arkanoidbut now I want a convincing discussion about where enum with holes went back accepted into the nim enum society
02:04:34FromDiscord<Elegantbeef> They're bad in Nim, but they're sometimes a necessary evil
02:05:34FromDiscord<Elegantbeef> They're bad mainly cause they make things like Nim's bitsets take more memory for no real reason, and make iterating the range more of a pain
02:05:45FromDiscord<Elegantbeef> But in this case you want the bitsets to take more space and likely are not iterating or parsing them
02:07:14arkanoidsure I'm not, but my brain somehow went into no enum with holes mode for a reason, I probably read somewhere about how bad they are
02:07:30arkanoidbut if they are still in nim 2.0, I think they are here to stay somehow
02:08:11FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4Ese
02:08:53FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4Esf
02:09:10FromDiscord<heysokam> yeah i guess
02:09:25FromDiscord<heysokam> but i do need the return
02:09:37arkanoidthanks for the help beef
02:09:41FromDiscord<heysokam> otherwise it can continue and if the last is true it is true (but should stop)
02:09:49FromDiscord<Elegantbeef> put a break in
02:13:41FromDiscord<heysokam> why not just return?
02:14:01FromDiscord<Elegantbeef> Cause of the warning
02:14:13FromDiscord<Elegantbeef> Can also disable the warning for the proc
02:14:26FromDiscord<heysokam> you can do that for specific procs? 🤔
02:14:55FromDiscord<Chronos [She/Her]> Anyone know how good Nim is for memory when it comes to WASM? Wondering how good it'd be for wasm4 (fantasy console stuff)
02:14:59FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4Esg
02:15:00FromDiscord<Elegantbeef> Though since it's a generic that might not work proerly
02:16:38FromDiscord<heysokam> ah gotcha
02:53:46FromDiscord<heysokam> What's the difference between an Effect and an Exception?
02:54:01FromDiscord<heysokam> Is it that Effect's include also Defects, or is it something else?
02:54:33FromDiscord<Elegantbeef> Effects are unrelated to exceptions
02:55:02FromDiscord<Elegantbeef> https://nim-lang.org/docs/manual.html#effect-system
02:56:03FromDiscord<Elegantbeef> I mean they're slightly related but overall they're not apart of it directly, `raises` allows you to disallow exceptions
03:01:09FromDiscord<heysokam> In reply to @Elegantbeef "https://nim-lang.org/docs/manual.html#effect-system": yeah i read that. i also read the 2.0 post about the changes. still don't really understand it
03:01:29FromDiscord<heysokam> as it is often the case with advanced topics in the docs/manual... they are not easily understood by my obtuse brain
03:01:33FromDiscord<Elegantbeef> You can annotate procedures to have effects, and you can disallow effects inside procedures
03:01:48FromDiscord<heysokam> but then what do exceptions have to do with that, if they are not effects?
03:01:59FromDiscord<Elegantbeef> They have no relation
03:02:10FromDiscord<Elegantbeef> effects are addition side effects on a procedure on a type level
03:02:14FromDiscord<heysokam> then why are the literally the second sentence ofthat manual?
03:02:25FromDiscord<Elegantbeef> Cause raises is apart of the effect system
03:02:37FromDiscord<Elegantbeef> `{.raises: [].}` disallows all exceptions from being raised
03:03:13FromDiscord<heysokam> what would `{.raises: [BaseEffect].}` do in contrast to that?
03:03:51FromDiscord<Elegantbeef> Nothing cause raises is apart of exception tracking
03:04:22FromDiscord<heysokam> ?
03:04:27FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4Esn
03:05:56FromDiscord<Elegantbeef> Raises just takes an array of exceptions allowed to be raised
03:07:26FromDiscord<heysokam> Am I understanding correctly that for --mm:none I should probably just `raises: [], tags: []` every proc?
03:07:28FromDiscord<Elegantbeef> Tags are the real effect tracking part
03:07:36FromDiscord<Elegantbeef> Not empty tags
03:07:41FromDiscord<Elegantbeef> Tags are for user defined effects
03:07:57FromDiscord<heysokam> but what are effects for, of not exceptions?
03:08:02FromDiscord<heysokam> (edit) "of" => "if"
03:08:29FromDiscord<Elegantbeef> Like in the above we've disabled the used of any `IO` tagged procedure inside `no_effects_please`
03:08:41FromDiscord<Elegantbeef> Blocking specific operations inside a procedure
03:08:58FromDiscord<heysokam> so you mark them as coming from some module, for example, and disallow the use of that module inside that function?
03:09:08FromDiscord<Elegantbeef> Not from some module
03:09:18FromDiscord<Elegantbeef> Tags are type level sideeffects
03:09:24FromDiscord<heysokam> i meant for example
03:09:31FromDiscord<Elegantbeef> In the above example we stated "readLine has the side effect of IO"
03:09:33FromDiscord<heysokam> since i don't understand effects
03:10:07FromDiscord<Elegantbeef> This means later on we can go "Oh we do not want to allow any procedure that has effects" or with `forbids` we can say "We do not want any procedure that has a specific effect"
03:10:26FromDiscord<Elegantbeef> Effects are wholly for users to use and decide how to use
03:10:42FromDiscord<Elegantbeef> If you want to disable allocations in a procedure it'd make sense to mark all allocating procedures with `alloc` and disable their usage
03:11:22FromDiscord<Elegantbeef> Effects are this magical tool to annotate procedures for certain things that you care about
03:11:44FromDiscord<heysokam> In reply to @Elegantbeef "If you want to": that is a smart one
03:12:08FromDiscord<heysokam> In reply to @Elegantbeef "Effects are this magical": i see, gotta start thinking more like that 🤔
03:12:23FromDiscord<Elegantbeef> Sadly though the stdlib does not use effects much
03:12:46FromDiscord<Elegantbeef> It'd be nifty if `cast` `copyMem` and `moveMem` had `unsafe` or similar
03:12:56FromDiscord<heysokam> definitely
03:13:01FromDiscord<Elegantbeef> Then you could just `{.forbids: [unsafe].}`
03:13:53FromDiscord<Elegantbeef> I personally have not ever used tags myself, but there are some places that it makes sense
03:21:32FromDiscord<heysokam> what is `-d:useMalloc` useful for, btw?↵any benefit to using it?
03:21:50FromDiscord<Elegantbeef> reducing binary size and also using C tooling
03:23:20FromDiscord<heysokam> what does it disable exactly? are the `create` `delete` functions allowed after disabling it?
03:23:53FromDiscord<heysokam> if those were not the names, i meant the ones were you allocate typed pointers safely
03:24:57FromDiscord<odexine> Nothing u I s disabled using that switch
03:25:04FromDiscord<odexine> (edit) "u I s" => "is"
03:25:14FromDiscord<heysokam> also, side question. any way to get information to decide if I should care about `gcsafe` pragma or not for --mm:none?
03:25:30FromDiscord<odexine> It switches out Nim’s internal allocator with Malloy
03:25:33FromDiscord<odexine> Malloc
03:26:01FromDiscord<heysokam> With a Mercurial alloy? interestings :kappa:
03:26:02FromDiscord<Elegantbeef> Mallory the Libc malloc
03:34:06FromDiscord<Elegantbeef> It occurs to me that malloy would not be mercury alloy that'd be hgalloy
03:40:55FromDiscord<odexine> :ChiguPien:
03:43:04FromDiscord<JJ> rolls off the tongue
04:24:44FromDiscord<graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4EsG
04:27:25FromDiscord<Elegantbeef> The borrow pragma is pretty bad at anything really
04:27:37FromDiscord<Elegantbeef> I improved it a bit, but it just has flaws
04:27:48FromDiscord<graveflo> I figured as much. It doesn't seem all that useful either. This is just a gross workaround
04:28:01FromDiscord<Elegantbeef> https://github.com/beef331/nimtrest/blob/master/lender.nim#L222-L242 is just a smarter way of doing it imo
04:28:48FromDiscord<graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4EsH
04:29:01FromDiscord<Elegantbeef> Yea I've talked about a weak distinct
04:29:12FromDiscord<Elegantbeef> The way of doing a weak distinct is to use a converter
04:29:35FromDiscord<graveflo> yea but that is sucky for a bunch of other reasons
04:29:42FromDiscord<graveflo> I'm sure I dont have to explain
04:29:47FromDiscord<Elegantbeef> Right, but it works the least worse
04:30:20FromDiscord<Elegantbeef> A weak distinct would be lovely so make an RFC and PR 😛
04:30:31FromDiscord<Elegantbeef> Oh wait there is a PR
04:30:31FromDiscord<Elegantbeef> RFC\
04:30:44FromDiscord<odexine> Will it be called wistinct
04:31:10FromDiscord<graveflo> In reply to @Elegantbeef "https://github.com/beef331/nimtrest/blob/master/len": Can't tell what im looking at here but I guess I'll do some digging. This isn't a "service side code has to preemptively expose for no reason" type of deal is it? Like can I made `Option` work like this without much trouble
04:31:23FromDiscord<Elegantbeef> https://github.com/nim-lang/RFCs/issues/450 close enough to a weak distinct
04:31:39FromDiscord<graveflo> (edit) "made" => "make"
04:31:53FromDiscord<Elegantbeef> It's a declarative API to emit procedures for a given type
04:32:10FromDiscord<Elegantbeef> Instead of using the proc header you write the code and it emits a procedure that inlines what you wrote
04:32:16FromDiscord<Elegantbeef> Practically what borrow should be
04:32:44FromDiscord<odexine> Kinda funky but I’m just thinking it sure would be nice if we had something like Haskell’s type classes
04:33:25FromDiscord<Elegantbeef> That means nothing to me
04:34:18FromDiscord<odexine> Pretty much just traits IIRC but not runtime I believe? Not too sure what traits are
04:34:27FromDiscord<Elegantbeef> Traits are not runtime
04:34:43FromDiscord<Elegantbeef> Traits are just constrained generics really
04:34:46FromDiscord<odexine> I don’t know what traits are really
04:35:17FromDiscord<Elegantbeef> They're a list of procedures required for a type to match, and inside of the trait implementation only those procedures are usable on that type
04:36:03FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4EsI
04:36:26FromDiscord<odexine> In reply to @Elegantbeef "They're a list of": Sounds like type classes then
04:36:26FromDiscord<Elegantbeef> Whoops `mSelf.get()` but anyway it's not really the most library ready code, just an idea I had eons ago
04:36:33FromDiscord<Elegantbeef> Yea they pretty much are
04:37:52FromDiscord<Elegantbeef> Nim does have half of that of course through everyones least favourite concept
04:38:58FromDiscord<odexine> I know that but I have the feeling that it is lacking somehow, yet I am unsure how
04:39:08FromDiscord<Elegantbeef> It's unchecked is really it
04:39:22FromDiscord<Elegantbeef> Concepts do not constrict you to the contract you declared
04:43:11FromDiscord<Elegantbeef> This circles around to my row typing struggles
04:44:03FromDiscord<Elegantbeef> sent a code paste, see https://paste.rs/4AZLa
05:00:59*advesperacit joined #nim
05:36:28FromDiscord<haoyu233> https://github.com/nim-lang/Nim/pull/19652
05:36:35FromDiscord<haoyu233> When I saw this issue, I remembered a meme I saw earlier
05:36:57FromDiscord<haoyu233> sent a long message, see http://ix.io/4EsQ
05:37:03FromDiscord<haoyu233> https://media.discordapp.net/attachments/371759389889003532/1144505701255880704/9f6886391a554035838f82654adbd18d.gif
05:38:52FromDiscord<haoyu233> (edit) "http://ix.io/4EsQ" => "http://ix.io/4EsR"
05:49:38FromDiscord<pk.kyle> bruh lol
05:51:41*lucasta_ quit (Ping timeout: 260 seconds)
06:05:56*rockcavera quit (Remote host closed the connection)
06:40:38*PMunch joined #nim
06:55:43FromDiscord<ShalokShalom (ShalokShalom)> https://rr-project.org/
06:55:43FromDiscord<ShalokShalom (ShalokShalom)> Does anyone use that?
07:12:38PMunchHmm, haven't seen that before. But certainly looks interesting
07:16:55*ehmry quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
07:19:09*ehmry joined #nim
07:21:34FromDiscord<odexine> Oh I’ve heard of it from Firefox
07:58:22FromDiscord<ShalokShalom (ShalokShalom)> The Julia CTO praises it
07:58:24FromDiscord<ShalokShalom (ShalokShalom)> Julia, the lang
08:03:01*PMunch_ joined #nim
08:03:30FromDiscord<firasuke> ok so I can't confirm my email on the forums, so I deleted my account and now I can't create a new one with the same ID kekw, who can help?
08:04:32*PMunch quit (Ping timeout: 240 seconds)
08:06:49*PMunch joined #nim
08:07:23*PMunch_ quit (Read error: Connection reset by peer)
08:08:33FromDiscord<Phil> I can't even get gdb to work, unless rr is far more idiot-proof I'm not sure on useage
08:08:55FromDiscord<Phil> (edit) "work," => "work well in vscode,"
08:09:19FromDiscord<Phil> I will admit that getting a C-debugging tool me-proof is a bit of a task though
08:10:20*PMunch_ joined #nim
08:10:48FromDiscord<odexine> In reply to @isofruit "I can't even get": You use it alongside the gdb debugger
08:10:55FromDiscord<odexine> It’s not a replacement
08:12:14FromDiscord<Phil> Then oofff as that'd make a proper vscode setup even harder
08:12:56*PMunch quit (Ping timeout: 245 seconds)
08:28:35FromDiscord<haoyu233> sent a code paste, see https://play.nim-lang.org/#ix=4Etb
08:28:56FromDiscord<haoyu233> why `offsetof(ChunkObj, data)` is zero
08:29:50FromDiscord<haoyu233> sent a code paste, see https://play.nim-lang.org/#ix=4Etc
08:30:55FromDiscord<haoyu233> By looking at the generated C code, it should be 1 or something else
08:38:40FromDiscord<Elegantbeef> Cause unchecked arrays have no size
08:39:03FromDiscord<Elegantbeef> Also fields start at offset 0
08:39:26FromDiscord<djazz> This was apparently invalid when using cpp backend and caused a runtime error: `cast[var T](pointerArg).myProc()`↵This works: `cast[ptr T](pointerArg)[].myProc()`
08:39:39FromDiscord<djazz> for a myProc that has first arg as var type
08:39:51FromDiscord<djazz> The joys of wrapping C/C++
08:40:05FromDiscord<djazz> voidstars!
08:40:13FromDiscord<Elegantbeef> likely C++ uses `&` instead of `` causing an issue casting t o`var T` is 'wrong'
08:40:19FromDiscord<djazz> yep
08:40:53FromDiscord<djazz> g++ compiler didnt complain tho
08:41:48FromDiscord<djazz> ran into another issue where the Pico SDK toolchain causes error for conversion from `const char ` to `char ` (cstring). the const variant has no nim equivalent
08:42:00FromDiscord<djazz> https://github.com/nim-lang/Nim/issues/19588 getting the same error
08:42:29FromDiscord<djazz> @ringabout's example fails with cpp backend but only when through pico sdk
08:43:21FromDiscord<djazz> not sure what flag passed to the compiled cause the error whereas nim cpp works
08:43:28FromDiscord<djazz> compiler
08:48:13*xet7 joined #nim
08:48:27*xet7_ quit (Ping timeout: 246 seconds)
08:53:48FromDiscord<djazz> dont want to replace all importc with importcpp heh
08:55:19FromDiscord<djazz> importcpp didnt fix it
08:59:07FromDiscord<djazz> anyway, I could easily change the const char in the c++ header file since it's part of my repo xD
09:00:51FromDiscord<Elegantbeef> Just don't support C++, problem solved
09:02:30FromDiscord<djazz> compiling with cpp backend helped reveal some other compatability issues for my wrapper 😉
09:03:12FromDiscord<Elegantbeef> more reason not to target it, it is creating more work!
09:03:34FromDiscord<djazz> more work now, less headache in the future?
09:03:52FromDiscord<Elegantbeef> Nah just more work
09:07:28FromDiscord<ringabout> In reply to @djazz "<@658563905425244160>'s example fails with": I am not really familiar with C or C++; but perhaps https://github.com/nim-lang/Nim/issues/3720#issuecomment-751622165 provides more information.
09:09:34*kenran joined #nim
09:14:39FromDiscord<haoyu233> In reply to @Elegantbeef "Also fields start at": However, in the generated C code, the offset is 1, which may cause the calculated field address error
09:15:34FromDiscord<haoyu233> I allocated 10 bytes of memory, one occupied by the `dummy` field
09:16:16FromDiscord<haoyu233> So my really available memory is 9 bytes
09:18:24FromDiscord<haoyu233> When I tried to circumvent this problem by adding the size of `offsetof(ChunkObj, data)`, I got the wrong value
09:19:07FromDiscord<Elegantbeef> The dummy field is apart of the collection
09:20:48FromDiscord<Elegantbeef> Nim avoids this by forcing a size of `1`
09:20:50FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4Etm
09:23:21FromDiscord<haoyu233> From the generated C code, you can see that the allocated memory size is not added with sizeof(dummy) https://media.discordapp.net/attachments/371759389889003532/1144562647115780206/image.png
09:23:39FromDiscord<Elegantbeef> The issue isnt the data, the issue is the fact you have an object with only an unchecked array which has no size
09:24:08FromDiscord<Elegantbeef> Nim will insert a dummy value inside a struct with a size of 0 cause all types need atleast a size of 1 to be sensible
09:24:26FromDiscord<Elegantbeef> I was wrong with my initial statement
09:25:10FromDiscord<Elegantbeef> What you want is just a `type MyType = distinct ptr UncheckedArray[char]`
09:25:37FromDiscord<Elegantbeef> You do not want a object as objects are defined as a struct, you just want an array apparently
09:26:09FromDiscord<haoyu233> I can understand the fact that the object size you described is at least 1
09:27:24FromDiscord<haoyu233> But this does not explain why the value of `offsetof(ChunkObj, data)` is 0
09:27:56FromDiscord<Elegantbeef> You found an issue with the offsetOf implementation
09:28:19FromDiscord<haoyu233> sent a code paste, see https://play.nim-lang.org/#ix=4Etc
09:28:30FromDiscord<Elegantbeef> Cool I don't care about C
09:28:35FromDiscord<Elegantbeef> The issue is inside the Nim compiler
09:28:50FromDiscord<Elegantbeef> You found an issue with it, when the object has a dummy field and a unchecked array the offset is incorrect
09:29:41FromDiscord<Elegantbeef> Not that it really matters that much, but it is an issue
09:31:36FromDiscord<haoyu233> The shit code I wrote got me into this problem
09:32:12FromDiscord<Elegantbeef> Right, it's an issue. But given that pretty much no one writes this code it's not a very common issue
09:32:32FromDiscord<Elegantbeef> A object with just an unchecked array is a silly way of writing a distinct or just `ptr UncheckedArray[T]`
09:33:08FromDiscord<Elegantbeef> It does need an issue made of course
09:36:18FromDiscord<haoyu233> Ok, I'll submit the issue later
09:37:48*fallback quit (Ping timeout: 246 seconds)
09:50:33NimEventerNew thread by koistinen: Using asm or intrinsic C functions from Nim, see https://forum.nim-lang.org/t/10439
10:08:45*azimut quit (Ping timeout: 246 seconds)
10:13:38*kenran quit (Ping timeout: 256 seconds)
10:23:03FromDiscord<Phil> Huh, just realized that since prologue uses async for its controllers, you can pretty much use async effortlessly within those
10:23:25FromDiscord<Phil> (edit) "Huh, just realized that since prologue uses async for its controllers, you can pretty much use async ... effortlesslyand" added "await" | "awaiteffortlessly within those ... " added "and don't have to care about dealing with the dispatcher at all"
10:23:39FromDiscord<Phil> Nifty
10:41:05FromDiscord<System64 ~ Flandre Scarlet> is Nim's garbage collector similar to RAII?
10:54:22FromDiscord<ieltan> In reply to @sys64 "is Nim's garbage collector": `orc` is RAII + a cycle collector for leaks
10:54:39FromDiscord<ieltan> Arc is RAII without the cycle collector
10:54:56FromDiscord<System64 ~ Flandre Scarlet> Oh alright!
10:55:10FromDiscord<ieltan> (edit) "leaks" => "cycles"
10:55:18FromDiscord<ieltan> Sorry I meant cycles
10:55:32FromDiscord<ieltan> But in retrospect, ARC will leak if you have cycle so...
10:55:40FromDiscord<ieltan> (edit) "cycle" => "cycles"
10:57:11FromDiscord<System64 ~ Flandre Scarlet> In reply to @ieltan "`orc` *is* RAII +": So that means if I do Nim well enough...↵...I can do C++ / Rust without problems?
10:59:09FromDiscord<ieltan> In reply to @sys64 "So that means if": No because C++ and Rust are more than RAII, but if you do Nim well enough you could be more productive than if you were to write C++ at least while your program runs as fast
10:59:45FromDiscord<ieltan> I'm not sure about Rust though
10:59:46FromDiscord<System64 ~ Flandre Scarlet> Oh alright!
11:00:08FromDiscord<System64 ~ Flandre Scarlet> I always has been afraid of C++
11:00:11FromDiscord<ieltan> What's your use case?
11:00:52FromDiscord<griffith1deadly> In reply to @sys64 "I always has been": c++ is like shooting yourself in the foot, and rust is something to be feared for a lifetime
11:01:24FromDiscord<System64 ~ Flandre Scarlet> I just watched a video about Rust↵and I asked some questions "Are pointers necessary in Rust? Should I care about memory management in Rust?"
11:01:55FromDiscord<odexine> In reply to @griffith1deadly "c++ is like shooting": Haha, lifetime
11:03:37FromDiscord<ieltan> My take on Rust is that it's an excellent language if you plan on making robust tooling or complex applications whereas C++ is a commonly used language for those and you will need to learn it if you want to contribute to existing libraries/apps that use it
11:03:59FromDiscord<System64 ~ Flandre Scarlet> I have some Nim projects↵A synthesizer↵A game↵And a graphics engine
11:05:16FromDiscord<griffith1deadly> nim is a good language, but without at least a basic knowledge of the low-level world of C/C++, it's going to be tight in some cases if you're trying to make a stable and high-performance application, huh
11:07:07FromDiscord<ieltan> I mean, it depends
11:07:31FromDiscord<ieltan> Why would "high-performance application" imply "low-level"?
11:07:40FromDiscord<System64 ~ Flandre Scarlet> In reply to @griffith1deadly "nim is a good": I already did a bit of C, I know what a pointer is and why they are useful
11:08:26FromDiscord<System64 ~ Flandre Scarlet> but pointers can be massive footguns
11:08:36FromDiscord<griffith1deadly> In reply to @ieltan "Why would "high-performance application"": memory management and memory leak repair, I meant. ↵developing a simple but high performance application, I have come across this more than once, and in some cases the leaks are not on my side.
11:10:59FromDiscord<ieltan> Yeah memory leaks are still going to be a thing it seems even though you would think that it's made to prevent them from happening
11:11:04FromDiscord<ieltan> Orc I mean
11:11:32FromDiscord<System64 ~ Flandre Scarlet> avoiding ref types to improve speed
11:12:34FromDiscord<griffith1deadly> you almost always have to sacrifice something, either memory or speed..
11:14:04FromDiscord<Phil> ~~The common choice is who gives a crap about memory and disk space~~
11:14:24FromDiscord<Phil> (edit) "who" => ""who" | "space~~" => "space"~~"
11:14:48FromDiscord<ieltan> The only way I can think of to prevent them is to make sure you don't have cyclic references and implement hooks for your weird objects (like if you're dealing with `ptr/pointer`)
11:14:57FromDiscord<Phil> In reply to @sys64 "avoiding ref types to": That'll only work as long as your object types are small.↵Once the amount of data they carry gets big that might get very meh very quickly
11:14:59FromDiscord<ieltan> I don't think there's much to be done unfortunately
11:15:53FromDiscord<System64 ~ Flandre Scarlet> In reply to @isofruit "That'll only work as": Unless you send back a reference when an user asks something to the graphics engine?
11:15:53FromDiscord<ieltan> In reply to @isofruit "That'll only work as": big objects are passed by ref anyways, might as well make it one
11:16:07FromDiscord<Phil> In reply to @ieltan "big objects are passed": Nim makes that choice under the hood at some point?
11:16:16FromDiscord<ieltan> This is one thing I dont Know if I should like or not
11:16:20FromDiscord<ieltan> In reply to @isofruit "Nim makes that choice": Yeah
11:16:51FromDiscord<ieltan> Idk if this is a good thing tbh
11:17:04FromDiscord<Phil> That seems like a thing you need stats for to evaluate:↵How often does it simplify your life vs. how often does it force you to care about the way nim abstracts it
11:17:43FromDiscord<ieltan> I know it prevent big fat copying happening but I would prefer it to be an explicit optimization, or make it so that it can only be passed by `var` param
11:18:07FromDiscord<Phil> Does it enable unexpected mutation?
11:18:28FromDiscord<ieltan> Ah, I don't think so, it would be pretty freaking bad if it did lol
11:18:37FromDiscord<Phil> In that case I think I'm fine with it
11:19:11FromDiscord<System64 ~ Flandre Scarlet> Is it possible a proc sends back a ref to something?
11:19:28FromDiscord<Phil> My main gripe with ref-types is that you can't make the data behind the ref immutable, if implicit passing by reference on nim's side doesn't suddenly enable prior immutable data to be mutable I'm alright with it
11:19:58FromDiscord<odexine> In reply to @isofruit "My main gripe with": It can’t, you still have to abide by the mutability rules
11:20:01FromDiscord<ieltan> In reply to @sys64 "Is it possible a": do you mean making a proc return `ref T` implicitly?
11:20:58FromDiscord<System64 ~ Flandre Scarlet> In reply to @ieltan "do you mean making": Yeah↵↵Like I have an array that handles palettes that are not ref↵But a proc that returns a ref of the selected palette
11:22:00FromDiscord<ieltan> Sure, just allocate with `new` and return the result contained inside of it
11:22:23FromDiscord<System64 ~ Flandre Scarlet> I will make a copy, no?
11:22:41FromDiscord<Phil> Nope, that will heap allocate and from there on your variable only contains a ref to the heap allocated data
11:23:20FromDiscord<System64 ~ Flandre Scarlet> But what if the data is stack allocated?
11:24:09FromDiscord<odexine> Then you will copy
11:24:22FromDiscord<ieltan> I'm not sure actually. Could `move`ing the stack data into the allocated heap do the trick?
11:24:31FromDiscord<Phil> Using `new` means heap allocation.
11:24:41FromDiscord<Phil> (edit) "allocation." => "allocation (for reference for System64)"
11:25:21FromDiscord<ieltan> Yes, but if the data is initially sitting on the stack you would have to copy it in the heap right?
11:25:34FromDiscord<System64 ~ Flandre Scarlet> And are seqs always heap allocated?
11:25:36FromDiscord<Phil> I would wager so
11:25:44FromDiscord<ieltan> In reply to @sys64 "And are seqs always": Yed
11:25:44FromDiscord<ieltan> Yes
11:25:52FromDiscord<Phil> In reply to @sys64 "And are seqs always": That is correct, but they behave as if they were stack allocated for you
11:26:08FromDiscord<Phil> So the semantics are as if they were stack-allocated
11:26:20FromDiscord<Phil> (edit) "So the semantics are as if they were stack-allocated ... " added "aka the semantics of value-types"
11:26:35FromDiscord<Phil> Same with strings
11:27:13FromDiscord<ieltan> The design of seq is pretty genius imo, I don't know how similar types are implemented in other languages but the way it's done in Nim is neat
11:27:30FromDiscord<odexine> In reply to @ieltan "The design of seq": I think the implementation is pretty standard
11:27:50FromDiscord<ieltan> Ah I see😶‍🌫️
11:29:44FromDiscord<System64 ~ Flandre Scarlet> Is it a good choice to make Tilemap ref ? https://media.discordapp.net/attachments/371759389889003532/1144594453370257540/image.png
11:30:04FromDiscord<System64 ~ Flandre Scarlet> Tilemap is ref↵tilesets is ref
11:30:36FromDiscord<Phil> Given the size I'd make that depend on how you think about Tilemap.↵Should there always be 1 Tilemap and that tilemap is often/almost always the same Tilemap?
11:31:28FromDiscord<Phil> Because value-object-semantics you copy the same thing around a lot so you may have 3+ tilemap instances floating around in a proc if it gets longer.↵Ref-object semantics make sure those are all referring to the same thing
11:31:31FromDiscord<System64 ~ Flandre Scarlet> There is one tilemap per layer↵But the user can swap tilemaps mid-frames
11:32:48FromDiscord<System64 ~ Flandre Scarlet> Same for palettes and tilesets
11:51:03FromDiscord<ieltan> In reply to @griffith1deadly "memory management and memory": Also fwiw I found this forum post that has lots of advice wrt isolating memory leaks↵https://forum.nim-lang.org/t/8251
12:04:33FromDiscord<slazaa> net.
12:05:51*kenran joined #nim
12:09:49*euantorano_ quit (Quit: Connection closed for inactivity)
12:28:39*rockcavera joined #nim
13:56:38*kenran quit (Remote host closed the connection)
13:56:57*kenran joined #nim
14:00:22*lucasta_ joined #nim
14:04:03*PMunch_ quit (Quit: Leaving)
14:04:42*lucasta_ quit (Ping timeout: 246 seconds)
14:15:14FromDiscord<burnysc2> Is there a simpler/shorter syntax to convert a float to uint64? Flooring, rounding, or ceiling doesn't matter to me↵Currently, I use `cast[uint64](toInt(22.4 120))`
14:16:39FromDiscord<System64 ~ Flandre Scarlet> In reply to @burnysc2 "Is there a simpler/shorter": sure↵myFloat.uint64 and that's all!
14:17:15FromDiscord<System64 ~ Flandre Scarlet> for you, it will be (22.4 120).uint64
14:17:34FromDiscord<burnysc2> Thank you, that worked
14:17:41FromDiscord<System64 ~ Flandre Scarlet> you're welcome
14:17:54FromDiscord<System64 ~ Flandre Scarlet> btw cast[T]() is unsafe
14:42:16FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4Eug
14:43:35FromDiscord<heysokam> In reply to @burnysc2 "Is there a simpler/shorter": Never cast↵`toInt(22.4 120).uint64`
14:43:53FromDiscord<heysokam> what you are doing there is storing the bits of the float as they are, which is wildly incorrect for a uint
14:44:54FromDiscord<heysokam> (edit) "cast↵`toInt(22.4" => "cast↵`(22.4"
14:44:59FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=4Euj
14:45:28FromDiscord<heysokam> In reply to @isofruit "Smells like you're using": its from a test
14:45:37FromDiscord<Phil> A classic for that problem is for example dates. can't have a date at compiletime
14:46:23FromDiscord<Phil> I mean that doesn't say much.↵It's calling code somewhere that runs at compiletime, how that code is called I can't predict 😛
14:46:39FromDiscord<heysokam> i don't know either
14:46:58FromDiscord<heysokam> i was using a const from `./cfg` changed it to come from `mylib/cfg` and broke
14:47:12*fallback joined #nim
14:47:13FromDiscord<heysokam> (edit) "i was using a const from `./cfg` changed it to come from ... `mylib/cfg`" added "a const at"
14:47:20FromDiscord<Phil> Without seeing things I can't say anything here
14:47:29FromDiscord<heysokam> well i don't know what to show you
14:47:35FromDiscord<heysokam> i don't know where is the issue
14:47:43FromDiscord<heysokam> i jsut replaced the const with a nother const, and broke
14:48:19FromDiscord<Phil> Do you use readLink anywhere?
14:49:37FromDiscord<Phil> Wait, are you on a mac?
14:50:19FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4Eul
14:50:25FromDiscord<Phil> getAppFilename() that is the thing that explodes
14:50:31FromDiscord<heysokam> its the only one i can think of that was const that requires runtime 🤔
14:50:33FromDiscord<Phil> Because that calls getApplAux
14:50:45FromDiscord<heysokam> yeah forgot about those functions being runtime
14:50:55FromDiscord<heysokam> but the error wasn't helpful lol, i had to blindguess 🙈
14:51:19FromDiscord<Phil> I basically worked just backwards from the os line where stuff got used
14:51:28FromDiscord<Phil> Bit more effort than usual but doable
14:51:54FromDiscord<Phil> But yeah, issue there is that at compiletime various facilities just aren't available =Z
14:51:57FromDiscord<Phil> (edit) "=Z" => "=/"
14:52:11FromDiscord<heysokam> shouldn't that at least give some sort of context, without requiring that ability to work backwards inside the inner workings of the code?
14:52:41FromDiscord<Phil> That'd be a question for internal, I'm not that deep in the compiler
14:54:12*cedb quit (Quit: WeeChat 4.0.3)
14:57:26*fireglow left #nim (puf)
15:23:34FromDiscord<ezquerra> @_araq, I'm trying to buy the kindle version of the new edition of your book. I can see it on the links that you shared in the forum, but as soon as I log in the kindle version disappears and I can only see the paperback edition. I already bought the paperback of the previous edition, that's why I want to buy the kindle version now...
15:23:39FromDiscord<ezquerra> Does anybody else have the same issue?
15:24:05FromDiscord<odexine> Might be a region thing somehow?
15:25:23*lucasta_ joined #nim
15:27:14FromDiscord<_araq> @eqzuerra I recently updated it and gave it a new cover, maybe there are some hiccups because of that
15:27:29FromDiscord<_araq> apart from that, I don't know, sorry.
15:28:38FromDiscord<ezquerra> OK, I'll try again in a little while. If somebody manages to buy that version please let me know
15:30:29FromDiscord<ezquerra> @_araq, could it be that you only uploaded the Kindle version of Germany and the US?
15:30:44FromDiscord<ezquerra> (edit) "of" => "to the" | "US?" => "US amazon stores?"
15:34:04FromDiscord<_araq> I can check but that's quite impossible
15:48:12*lucasta_ quit (Ping timeout: 252 seconds)
15:50:18FromDiscord<heysokam> @pmunch I hadn't used nimlsp since 1.16.12 or something like that↵I love that the tooltips for strformat's `&` are now giving an error notice. Back then they weren't, and its so useful to have them!↵Don't know when that got introduced, but tysm for that 🤘
15:51:16FromDiscord<heysokam> Seems like I have been out of bounds for a while and missed quite a lot of updates 🙂
16:16:57NimEventerNew thread by bsljth: One language to rule them all., see https://forum.nim-lang.org/t/10442
17:07:10FromDiscord<enthus1ast> which matrix client library do you use?
17:16:59*marcus quit (Remote host closed the connection)
17:18:09*marcus joined #nim
17:24:51FromDiscord<ieltan> In reply to @termer "it should absolutely be": Hi! I am curious about your experience with `views`, I've always heard it was buggy as heck
17:24:56*hernan_ is now known as hernan
17:25:05FromDiscord<ieltan> It would be greatly appreciated if you did
17:51:05FromDiscord<Chronos [She/Her]> Hey, question, what issues are there with using async and threading together?
17:53:19FromDiscord<dmisener> Quick question: How do I convert a std/paths Path back into a string?
17:54:22FromDiscord<huantian> should just be $
17:56:13FromDiscord<dmisener> sent a long message, see http://ix.io/4Evf
18:04:02FromDiscord<dmisener> Sorry.. just checked the splitFile code and found the undocumented method "string". So echo path.string works! Obvious in hindsight.
18:04:20FromDiscord<jviega> Isn't the $ in os?
18:04:41FromDiscord<dmisener> Apparently not for Path
18:04:50FromDiscord<jviega> Hmm yeah weird
18:07:48FromDiscord<dmisener> If I define proc `$`(path: Path): string = path.string ↵that work... Looks like it was just missed??\
18:11:03FromDiscord<enthus1ast> mhh $ for path should be in the new std/paths but its not there
18:11:03FromDiscord<enthus1ast> maybe open an github issue about this
18:11:48FromDiscord<enthus1ast> or pr \:)
18:13:34FromDiscord<heysokam> In reply to @dmisener "Quick question: How do": `thepath.string` they are just `distinct string`
18:13:42FromDiscord<heysokam> at least the last time i checked they were just that
18:16:02FromDiscord<heysokam> @dmisener @enthus1ast these are other things I found missing for paths↵https://github.com/heysokam/nstd/blob/master/src/nstd/paths.nim
18:16:50FromDiscord<enthus1ast> yes they are
18:18:00FromDiscord<heysokam> they are "missing" or they are "there"?
18:18:40FromDiscord<enthus1ast> yes they are distinct string
18:20:25FromDiscord<heysokam> In reply to @dmisener "Sorry.. just checked": btw just noticed the `undocumented method "string"` part of this message↵it is not a method, its the type itself. you can do that with any type, it just calls the internal converter of that type↵That's why its not documented, because its a feature of the lang, not exclusive to paths
18:21:10FromDiscord<Chronos [She/Her]> I'm wondering why I have an 'add condition' type and for what it'd be used for tbh
18:21:18FromDiscord<ieltan> In reply to @chronos.vitaqua "Hey, question, what issues": That's actually a pretty good question
18:22:26FromDiscord<enthus1ast> to bad that we not have used the opportunity to have a AbsolutePath and RelativPath type \:)
18:22:29FromDiscord<Chronos [She/Her]> In reply to @ieltan "That's actually a pretty": Yeah, I'm wondering why an async scheduler couldn't work together, I know refc would've made it a major issue but surely arc/orc would work better (even if they have their own challenges)
18:23:39FromDiscord<ieltan> Well, orc/arc has shared heap I think so it can be doable actually
18:24:05FromDiscord<ieltan> It's really a "you gotta know you're doing"
18:24:10FromDiscord<ieltan> thing
18:24:29FromDiscord<Chronos [She/Her]> Yeah
18:24:42FromDiscord<ieltan> There is also isolation that came out but I have no idea how to use it
18:24:53FromDiscord<dmisener> sOkam! - -Thanks for the clarfication
18:27:58FromDiscord<Chronos [She/Her]> Is there any way to check if a proc is asynchronous?
18:31:43termercheck whether it returns a Future
18:36:09NimEventerNew thread by DMisener: Re: std/Paths - Converting Path to string , see https://forum.nim-lang.org/t/10443
18:41:18FromDiscord<Chronos [She/Her]> In reply to @termer "check whether it returns": Aaand how do I do that?-
18:42:02FromDiscord<Chronos [She/Her]> I'm assuming to just run it?
18:48:49termerare you checking at compile time or runtime?
18:48:52termerwhat are you trying to do?
18:50:42FromDiscord<Chronos [She/Her]> sent a code paste, see https://play.nim-lang.org/#ix=4Evp
18:52:11termeryou could create an async concept
18:52:32termertype AsyncProc = concept x: x() is Future
18:52:58termerthen your isAsync can be populated at compile time as "T is AsyncProc"
18:53:36FromDiscord<Chronos [She/Her]> Yeah I can do that, thanks!
18:53:46termerYup, no problem
18:56:11FromDiscord<Chronos [She/Her]> Tbh do I even need a new proc anymore... I think I can remove it since default values
19:06:36*kenran quit (Remote host closed the connection)
19:27:54termerthat works
19:28:48FromDiscord<Chronos [She/Her]> Is there a way to catch all defects and errors? Planning on making it so I can raise an exception after all listeners have fired
19:30:25termertry: except:
19:30:34*junaid_ joined #nim
19:30:35termerThis is deprecated though I think
19:30:46termerI think they both inherit from Exception
19:30:50termeryou can most likely catch Exception
19:35:26FromDiscord<Chronos [She/Her]> Gucci!
19:35:34FromDiscord<Chronos [She/Her]> Wait try and except is deprecated??
19:37:14*junaid_ quit (Remote host closed the connection)
19:38:37termeror wait
19:38:45termerI don't remember if it is
19:39:05termerthere was a short period of time where there was deprecation on catching Exception
19:43:48FromDiscord<juan_carlos> In reply to @chronos.vitaqua "Wait try and except": Naked `except:` without exception is deprecated, like `except OSerror:` etc
19:44:48FromDiscord<jviega> Didn't that get undone??
19:52:09FromDiscord<Chronos [She/Her]> Ah
20:02:38FromDiscord<Chronos [She/Her]> Tbh I don't need to catch exceptions, that's the listeners job, not mine
20:07:02*azimut joined #nim
20:08:41termerChronos What're you doing
20:08:56termerIf you're running a bunch of handlers, you need to think about whether an exception in one should halt any others from working
20:09:17termerSo you should catch all exceptions
20:11:28FromDiscord<Chronos [She/Her]> I'm catching the top level exception and `echo`ing it but I'm not gonna be catching them and waiting for it all to finish to print it in a pretty way, I meant
20:12:06FromDiscord<Chronos [She/Her]> sent a code paste, see https://play.nim-lang.org/#ix=4EvC
20:13:40FromDiscord<Chronos [She/Her]> I was originally going to catch them all and add them to a list and then format it into a cleaner way but, that's more effort than I need to put into it really
20:14:15FromDiscord<juan_carlos> Fire and forget
20:16:24termerIf you have async handlers, just do asyncCheck on them
20:16:30termerassuming you're not waiting for them
20:17:00FromDiscord<ggaast> sent a long message, see http://ix.io/4EvD
20:17:34FromDiscord<Elegantbeef> Eh using mold did not appreciably change compile times in my experience
20:17:48FromDiscord<Elegantbeef> you also really want to do `--gcc.linkerexe="mold"`
20:17:57FromDiscord<ggaast> im on linux
20:18:04FromDiscord<Elegantbeef> Ok and?
20:18:22FromDiscord<ggaast> you also really want to do `--gcc.linkerexe="mold"`
20:18:29FromDiscord<ggaast> sorry
20:18:53FromDiscord<ggaast> figuring up how to use fluffy chat, a bit confusing
20:19:23FromDiscord<Chronos [She/Her]> In reply to @termer "If you have async": That's what I'm doing, but also I'm supporting the calling of async handlers synchronously too
20:19:37FromDiscord<Chronos [She/Her]> Unless asyncCheck works in synchronous procs which is news to me-
20:20:08termerit doesn't work that way lol
20:20:14FromDiscord<ggaast> I thought `exe` in this line refers for windows version, i will try to do it rn
20:20:28FromDiscord<Elegantbeef> No it just refers to an executable
20:20:45FromDiscord<Chronos [She/Her]> In reply to @termer "it doesn't work that": What do you mean? Calling an async event with `waitFor` is blocking, right? Which is the goal of the `fire` proc
20:20:58termeroh wait
20:21:01termerI see what you're saying
20:21:02FromDiscord<Elegantbeef> With how nim does compilation I do not think you can just use the `-f...` way of using mold
20:21:12FromDiscord<Chronos [She/Her]> Sweet :)
20:21:48FromDiscord<Elegantbeef> I used mold on compilation of the Nim compiler and like i said there was no appreciable benefit
20:22:12FromDiscord<Elegantbeef> TCC on the otherhand does give appreciable benefits in some programs
20:22:14FromDiscord<Elegantbeef> But with Nim 2.0 you need to do `--threads:off`
20:22:26FromDiscord<Chronos [She/Her]> Ah I did structure my code weirdly though, supposed to call `waitFor` on the return type of `waitFor`
20:22:38FromDiscord<Chronos [She/Her]> (edit) "`waitFor`" => "`unpackTuple`"
20:23:05FromDiscord<Elegantbeef> Most of the time compiling programs in Nim is spent in Nim presently
20:23:21FromDiscord<Elegantbeef> Hence the desire of an incremental compiler
20:23:57FromDiscord<Phil> In reply to @chronos.vitaqua "Hey, question, what issues": afaik each thread has its own scheduler, so that'd run into limitations.↵Note that I barely have an idea what I'm talking about here as I only recently started actually getting into the basics of async beyond just using the syntax
20:24:25FromDiscord<Elegantbeef> Yes each thread has it's own async runtime, so it's fine as long as you do not attempt to share futures or similar
20:24:34FromDiscord<Elegantbeef> You have to complete a future on the thread that made it
20:24:36FromDiscord<Chronos [She/Her]> In reply to @isofruit "afaik each thread has": Fair enough, though isn't it possible to make them share a scheduler? Or is `PDispatcher` different from that
20:25:01FromDiscord<Phil> ... That sounds possible... but it'd be a shared resource so definitely would require locks
20:25:17FromDiscord<Chronos [She/Her]> I remember being able to set the dispatcher from a (Nim-compiled) shared library to the dispatcher in the application loading the shared libs
20:25:33FromDiscord<Chronos [She/Her]> It barely worked half the time lmao but yeah
20:25:43FromDiscord<Elegantbeef> I seem to remember you had nothing but issues
20:25:49FromDiscord<ggaast> im worring about long comptimes, is it a problem in large scaled apps? I tryed to compile my project with happyx (just big random lib from perspective) and it took 6 seconds.
20:25:49FromDiscord<Chronos [She/Her]> In reply to @Elegantbeef "I seem to remember": Yes xD
20:26:02FromDiscord<Chronos [She/Her]> But it did occasionally
20:26:06FromDiscord<Elegantbeef> I mean there is no way of speeding up Nim's compile times presently
20:26:16FromDiscord<Elegantbeef> You can use TCC and mold, but that's not going to help much
20:26:28FromDiscord<Chronos [She/Her]> The errors where the biggest pain point really
20:26:40FromDiscord<Elegantbeef> It's not like Nim isnt relatively fast compared to Go/Rust though
20:26:52FromDiscord<Elegantbeef> Slow as hell compared to zig/odin though
20:27:08FromDiscord<Chronos [She/Her]> In reply to @Elegantbeef "You can use TCC": Iirc the LLVM project made something called `gold` as a new linker that works way faster but idk how good it actually is
20:27:22FromDiscord<Chronos [She/Her]> Also only works with stuff that LLVM for compilation
20:27:24FromDiscord<Elegantbeef> Sure, but like i said mold doesnt even help much
20:27:53FromDiscord<Elegantbeef> Like the nim compiler was only a few hundred ms faster if i recall correctly
20:28:14FromDiscord<Phil> ... I mean release compiletimes can be as long as they want and thus linker compiletimes are of secondary relevance, debug compiles is where it's at and for those you might as well not do lto
20:28:38FromDiscord<Elegantbeef> "might as well not do lto"
20:28:41FromDiscord<Elegantbeef> What a funny thing to say
20:29:04FromDiscord<Elegantbeef> Why the hell would you enable an optimisation flag for your debug program! 😄
20:29:24FromDiscord<ggaast> Yeah, never \:)
20:29:43FromDiscord<Elegantbeef> "For extra spice I add `--objChecks: off` and randomly tick off `--boundChecks:off` just for added fun"
20:30:41FromDiscord<ezquerra> @_araq FYI I managed to buy the kindle version of the book, but I had to go through the US store
20:30:47FromDiscord<Phil> In reply to @chronos.vitaqua "Fair enough, though isn't": Just double checked with status-nim/chronos: They also don't do shared schedulers, so might either not be a good idea or hit complexity limitations etc.
20:31:21FromDiscord<ggaast> may be there is good hot-reload/bin-patching approach? I really love nim syntax, but perspective of waiting 5+ seconds after "Color" value is not much promicing for me
20:31:34FromDiscord<ggaast> after changing "Color"\\
20:32:01termerwhat does --objChecks do
20:32:01FromDiscord<Phil> I'm not aware of any tbh
20:32:17FromDiscord<Elegantbeef> disables inheritance checks
20:32:44FromDiscord<Elegantbeef> You could make your own plugin system using Wasm/Dlls, you could use nimscript, otherwise there is not
20:33:22FromDiscord<Elegantbeef> Nim's HCR does not work even though it's there
20:33:51FromDiscord<Elegantbeef> image.png https://media.discordapp.net/attachments/371759389889003532/1144731387677659186/image.png
20:33:54FromDiscord<Elegantbeef> Tonnes of control termer
20:34:05FromDiscord<Elegantbeef> All can be used inside pragmas to disable for specific procedures aswell
20:35:16termerare you saying that you can use objects that don't share an inherited ancestor
20:35:35termerI've done raw casting to do hilarious things like untyped maps before
20:35:44FromDiscord<Elegantbeef> No
20:35:58FromDiscord<Elegantbeef> You use it to disable checks for a tree
20:36:17termertype checking in general?
20:36:27termerI'm not clear on what you mean
20:36:45termeror wait
20:36:51termerman, if only this was *documented*
20:37:15FromDiscord<Elegantbeef> That way you can convert a parent to a child or a unrelated child to another child
20:37:15FromDiscord<Elegantbeef> It's all in the same family tree though
20:38:29termerinteresting, though I'm not sure what you could use that for
20:38:55FromDiscord<ggaast> How much time do you spend on comptimes in avarage in your projects?
20:40:12FromDiscord<ggaast> i mean in debug mode
20:40:13FromDiscord<Elegantbeef> Removing the overhead of type checking inside a procedure you know that a type is a specific branch
20:40:23FromDiscord<Elegantbeef> My game takes like 3s to compile
20:40:32FromDiscord<Chronos [She/Her]> In reply to @isofruit "Just double checked with": Hm... Fair enough
20:40:37FromDiscord<Elegantbeef> 5s from a uncached state
20:40:55FromDiscord<Chronos [She/Her]> In reply to @Elegantbeef "You could make your": I used shared libs before, went poorly- Probably because I tried doing a ton of async stuff?
20:41:10FromDiscord<Elegantbeef> No clue you do manic shit so I cannot say much
20:41:18FromDiscord<Chronos [She/Her]> Pffffff
20:41:35FromDiscord<Chronos [She/Her]> I do it for the ✨ d o p a m i n e ✨
20:42:02FromDiscord<Elegantbeef> Well you have to use the NimRTL if you want to use GC across the barrier
20:42:05FromDiscord<Elegantbeef> I doubt you used the RTL which probably didnt help
20:42:11FromDiscord<Elegantbeef> But anyway I'm getting barked at for a walk, so I best go before it pisses down
20:42:18FromDiscord<Chronos [She/Her]> No, I used arc/orc actually
20:42:34FromDiscord<Chronos [She/Her]> Which doesn't use RTL, since only refc needs that afaik
20:42:45FromDiscord<Chronos [She/Her]> In reply to @Elegantbeef "But anyway I'm getting": Fair enough lol, have a good walk with ya dog
20:46:36FromDiscord<Elegantbeef> No the RTL is needed still to share allocator
20:51:24FromDiscord<Chronos [She/Her]> Huh? I... Actually never knew that, that's probably why it went up in flames xD
20:52:58FromDiscord<Chronos [She/Her]> I was told before it wasn't needed which is why I never bothered to figure it out tbh
21:03:45*disso-peach quit (Quit: Leaving)
21:12:18*advesperacit quit ()
21:22:58FromDiscord<Andreas> sent a code paste, see https://play.nim-lang.org/#ix=4EvX
21:23:58FromDiscord<Elegantbeef> Well the second branch is not a ternary
21:24:22FromDiscord<Elegantbeef> to achieve 2 you can do `s += int(a[i] < 50) a[i]` in Nim
21:24:22FromDiscord<Andreas> the third looks like a ternary - second no idea what that is..
21:24:36FromDiscord<Elegantbeef> Second is just C
21:24:53FromDiscord<Elegantbeef> Since C does not have a distinct 'bool' all comparisons are just integers either 0 or 1
21:25:25FromDiscord<Elegantbeef> The third is a ternary yes, so it's not branchless afaik
21:25:38FromDiscord<Andreas> In reply to @Elegantbeef "Second is just C": that legal ? multiplying a bool with a value?
21:25:48FromDiscord<Elegantbeef> Like I said C does not have a bool
21:25:58FromDiscord<Elegantbeef> `1 < 2` is not a bool in C it's an integer
21:26:38FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4Ew3
21:27:16FromDiscord<Elegantbeef> I've never seen anyone use a string constant inside fmt, this is amazing 😄
21:27:59FromDiscord<Elegantbeef> Would Strutils `%` be any cleaner
21:28:00FromDiscord<heysokam> I took it from someone here. its kinda handy for naming things and pre-defining the pattern
21:28:03FromDiscord<arathanis> In reply to @Andreas "that legal ? multiplying": literally stdbool.h https://media.discordapp.net/attachments/371759389889003532/1144745025360629910/image.png
21:31:56FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4Ew6
21:32:39FromDiscord<heysokam> not much of a fan of the %, since names become numbers and they become much harder to track to their corresponding pair
21:37:14FromDiscord<heysokam> sidenote:↵is `varargs[...].join()` not a thing? I thought that varargs were sequences? 🤔
21:37:49FromDiscord<Elegantbeef> What?
21:38:04FromDiscord<Elegantbeef> `varargs[...]`? meaning?
21:38:13FromDiscord<heysokam> any varargs
21:38:29FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4Ew7
21:38:48FromDiscord<Andreas> In reply to @Elegantbeef "`1 < 2` is": thx - thats really amazing :: https://play.nim-lang.org
21:38:49FromDiscord<Elegantbeef> What did you try that failed?
21:39:19FromDiscord<Elegantbeef> And no varargs are not sequences they're open arrays
21:39:25FromDiscord<heysokam> `var msg :string= args.join()`
21:40:29FromDiscord<Andreas> In reply to @arathanis "literally stdbool.h": sure in C booleans are ints, but the nim-code `int( true ) == 1` surprised me..
21:40:47FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4Ew8
21:41:01FromDiscord<Elegantbeef> `int(true)` is a type conversion, what's so suprising?
21:41:14FromDiscord<heysokam> In reply to @Andreas "sure in C booleans": how would you interop with C if that wasn't correct?
21:41:22FromDiscord<heysokam> how would you compile to C even
21:41:53FromDiscord<Andreas> In reply to @heysokam "how would you compile": hey, i don't compile anything - i'm the user here 😉
21:43:16FromDiscord<heysokam> tyty
21:43:17FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4Ew9
21:43:29FromDiscord<Elegantbeef> Ummm acktually `nim c` is 'nim compile' so you do indeed compile!
21:43:52FromDiscord<Elegantbeef> Sokam sometimes it feels like you just drop a wrench on your keyboard and hope code works 😄
21:44:52FromDiscord<jviega> LOL
21:45:42FromDiscord<Andreas> In reply to @heysokam "how would you interop": just, not a everday - variant, but anyway - one more question pls : how come a that a `ternary-expression` as of C or JS is to be considered 'branchless' ? Isnt it simply a disguised `if` - the compiler/cpu has to do same decision ?
21:46:05FromDiscord<Elegantbeef> It's not branchless
21:46:18FromDiscord<Elegantbeef> Sometimes it can be optimised to branchless, but it's not generally branchless
21:46:52FromDiscord<Elegantbeef> like `a ? b : -b` could be done branchless or `a ? true: false`
21:46:53FromDiscord<Andreas> In reply to @Elegantbeef "Sometimes it can be": i totally agree, sourc is here https://en.algorithmica.org/hpc/simd/masking/
21:47:23FromDiscord<Elegantbeef> Right and that's branchless in hindsight
21:47:40FromDiscord<Elegantbeef> Since it's the exact same as the no branch
21:47:59FromDiscord<Elegantbeef> think about it if you know `a[i]` is true and `0` is false that's just `a[i] < 50 a[i]`
21:48:10FromDiscord<Elegantbeef> Since in the case a[i] \> 50 it's 0
21:48:20FromDiscord<Elegantbeef> so the compiler can reason these shortcuts and implicitly write them
21:48:36FromDiscord<Elegantbeef> Simple ternary operations that represent branchless code can be done in a branchless way
21:48:38FromDiscord<heysokam> In reply to @Elegantbeef "Sokam sometimes it feels": truer that truth 😄
21:55:54FromDiscord<Chronos [She/Her]> Do try except statements work for catching code ran with `asyncCheck`?
21:56:26FromDiscord<Chronos [She/Her]> sent a code paste, see https://play.nim-lang.org/#ix=4Ewg
21:56:37FromDiscord<Chronos [She/Her]> (edit) "https://play.nim-lang.org/#ix=4Ewg" => "https://play.nim-lang.org/#ix=4Ewh"
21:56:38FromDiscord<Elegantbeef> I don't imagine so
21:56:42FromDiscord<Chronos [She/Her]> Ignore the `.`
21:56:48FromDiscord<Elegantbeef> Since the `asyncCheck` is not where the code is actually ran
21:57:13FromDiscord<Chronos [She/Her]> In reply to @Elegantbeef "I don't imagine so": Damn, can I make a proc that awaits the future then and run that with asyncCheck to catch any errors?
21:58:10FromDiscord<Elegantbeef> I mean same issue afaik you're not running code at the async check iirc
21:58:39FromDiscord<Andreas> sent a code paste, see https://play.nim-lang.org/#ix=4Ewk
21:58:43FromDiscord<Chronos [She/Her]> sent a code paste, see https://play.nim-lang.org/#ix=4Ewl
21:58:45FromDiscord<Chronos [She/Her]> In reply to @Elegantbeef "I mean same issue": Painful
22:00:26FromDiscord<Chronos [She/Her]> Idk how to solve this- Unless there's a callback for errors...? Probably is tbh
22:00:55FromDiscord<Chronos [She/Her]> >>> Sets a callback on future which raises an exception if the future finished with an error.↵↵This should be used instead of discard to discard void futures, or use waitFor if you need to wait for the future's completion.
22:01:03FromDiscord<Chronos [She/Her]> This is what the docs say so it should be fine?
22:02:50*oisota quit (Quit: Ping timeout (120 seconds))
22:03:09*oisota joined #nim
22:04:24FromDiscord<huantian> you can check it in the future callback but you should probably be handling your errors in the async code
22:04:49FromDiscord<huantian> just do the same thing asyncCheck does but with your own callback
22:07:16FromDiscord<pmunch> In reply to @heysokam "<@392962235737047041> I hadn't used": Not sure this is something that's been added in NimLSP, might just be a nimsuggest feature. In any case I didn't implement it so thank someone else 🙂
22:07:25FromDiscord<Chronos [She/Her]> In reply to @huantian "you can check it": It's for my event system library, so that's not possible if someone makes faulty code really
22:07:33FromDiscord<pmunch> Glad you like NimLSP though
22:08:02FromDiscord<Chronos [She/Her]> How does https://nim-lang.org/docs/locks.html work exactly...? Not sure how to create a lock and correctly wait for the lock to be released
22:12:00FromDiscord<Elegantbeef> 'correctly wait for the lock to be released' you just do `tryAcquire`
22:12:05FromDiscord<Elegantbeef> Or `withLock`
22:15:28FromDiscord<Chronos [She/Her]> Does `withLock` do that automatically for me then?
22:15:36FromDiscord<Chronos [She/Her]> And is it fine to use in async code or is it blocking?
22:17:01FromDiscord<Elegantbeef> 'is locking blocking;
22:17:13FromDiscord<Elegantbeef> If locking wasn't blocking we'd have problems
22:17:48FromDiscord<pmunch> I mean async locks could be cool
22:18:40FromDiscord<Elegantbeef> I don't know might just be my lack of threading/async, but that seems rather pointless
22:19:44FromDiscord<Elegantbeef> "I really need to do work that is thread safe, but I can wait to do it until I get a lock" seems like such a rare situation to me
22:20:18FromDiscord<Elegantbeef> But one could reimplement `withlock` that wraps `tryacquire` in a async sleep loop to make it an async way of getting a lock I guess
22:26:21FromDiscord<burnysc2> sent a code paste, see https://play.nim-lang.org/#ix=4Ewv
22:27:08FromDiscord<griffith1deadly> In reply to @burnysc2 "I'm a bit surprised": why surprised
22:27:55FromDiscord<Elegantbeef> Nim explicitly states that fields are preferred over procedures when used in method call
22:28:19FromDiscord<burnysc2> i just accidently did that and was wondering why my variable wouldnt update (i expected the function call to be executed here)↵turns out i forgot to remove the attibute
22:29:15FromDiscord<burnysc2> In reply to @Elegantbeef "Nim explicitly states that": i mean it is neat, i just didnt expect it↵i suppose i will have to continue reading the manual :)
22:58:55FromDiscord<Andreas> the Cpp-branching-thingy is here -> https://godbolt.org/z/nj74dfGa4 i'm not exctly sure about the ternary beeing not a branch ? ↵sections .L10 - .L12
23:00:21FromDiscord<Elegantbeef> no optimization
23:00:45FromDiscord<Andreas> ok, l3 then
23:06:07FromDiscord<Elegantbeef> Well yea you arent using s
23:06:18FromDiscord<Elegantbeef> https://godbolt.org/z/1jGd9h4Wa
23:06:27FromDiscord<Andreas> s ? whats that ?
23:08:08FromDiscord<Elegantbeef> The variable?
23:14:16FromDiscord<Andreas> In reply to @Elegantbeef "The variable?": does it make sense to send a nim-binary for comparrisson with the Cpp-thinggy ?
23:15:07FromDiscord<System64 ~ Flandre Scarlet> Did someone already written an emulator in Nim?
23:15:08FromDiscord<Elegantbeef> Why send a nim binary, just write nim code 😄
23:15:32FromDiscord<Andreas> In reply to @Elegantbeef "Why send a nim": OMG - thats sweet
23:38:59*FromDiscord quit (Remote host closed the connection)
23:39:12*FromDiscord joined #nim