<< 11-08-2023 >>
00:25:03FromDiscord<Matt> I'm continuing to work on a simple lsm tree kv store
00:25:19FromDiscord<Matt> I currently have a function that does a compaction / merge of the on disk files
00:25:26FromDiscord<Elegantbeef> Chaining together words together does not make it true
00:25:35FromDiscord<Matt> Huh
00:25:54FromDiscord<Matt> I wanted to introduce a background thread that would invoke that compaction on a set interval
00:26:19FromDiscord<Matt> Would it make sense form my LSM type to have a thread property that gets set upon instantiation or is that asking for trouble
00:28:32FromDiscord<elegantbeef> Ah there was a follow up message, the bridge ate it. It's up to you
00:28:42FromDiscord<Matt> All g
00:28:48FromDiscord<Matt> Just some bad timing
00:28:55FromDiscord<Matt> So on second thought I'm not sure I can
00:29:31FromDiscord<Matt> sent a code paste, see https://play.nim-lang.org/#ix=4D7G
00:29:37FromDiscord<Matt> That's what my code looks like for the lsm
00:29:53FromDiscord<Matt> Sorry in advance if it doesn't render in your irc client, I can pastebin / gist it
00:30:21FromDiscord<Elegantbeef> I use matrix so it renders
00:30:30FromDiscord<Matt> sent a code paste, see https://play.nim-lang.org/#ix=4D7H
00:30:36FromDiscord<Matt> And here's what I tried as my type def
00:30:47FromDiscord<Matt> problem is that this is an illegal circular reference
00:31:01FromDiscord<Matt> So I guess my question is
00:31:03FromDiscord<Elegantbeef> Where?
00:31:18FromDiscord<Matt> nim_lsm.nim(21, 6) Error: illegal recursion in type 'LSM'
00:31:38FromDiscord<Matt> Upon introducing that tuple
00:32:02FromDiscord<Elegantbeef> Ah it stores the arg internally
00:32:18FromDiscord<Matt> So my general question is how can I instantiate a background thread for a LSM object that does the compaction, so that it is also managed by the object's lifetime
00:32:33FromDiscord<Elegantbeef> Seperate the LSM from the thread through a data type
00:32:35FromDiscord<Matt> i.e. I don't delete my LSM object later, say in a library, and then the thread wreaks haboc
00:32:45FromDiscord<Matt> 👀 I'm listening
00:32:49FromDiscord<odexine> The code you have as is right now will copy the LSM type as you pass it into the thread
00:32:51FromDiscord<odexine> Is that intended
00:32:54FromDiscord<Matt> No
00:33:00FromDiscord<Matt> Maybe it should be ref
00:33:01FromDiscord<Matt> ?
00:33:14FromDiscord<odexine> If you’re feeling lucky you can use a pointer
00:33:38FromDiscord<Matt> Is there a cleaner way to do it?
00:33:46FromDiscord<Matt> In reply to @odexine "If you’re feeling lucky": Not out of the question
00:33:49FromDiscord<Elegantbeef> sent a code paste, see https://paste.rs/GHRsj
00:34:06FromDiscord<Matt> sent a code paste, see https://play.nim-lang.org/#ix=4D7J
00:34:17FromDiscord<odexine> Locks don’t play well when put into references from what I recall
00:34:31FromDiscord<Elegantbeef> OtherLSMThing should have a `lsm: LSM` field if unclear
00:34:33FromDiscord<Matt> Oh lovely
00:34:44FromDiscord<Matt> In reply to @Elegantbeef "OtherLSMThing should have a": Why is that
00:34:57FromDiscord<Matt> I'm not sure I fully grok the ownership / threading model
00:35:04FromDiscord<Elegantbeef> Cause that object holds teh lsm and the thread
00:36:05FromDiscord<Elegantbeef> I don't see why you could not use a ref with locks, the issue is more destructors are going to get called if you do not disarm the destructor properly
00:36:26FromDiscord<Matt> > more destructors are going to get called if you do not disarm the destructor properly↵?
00:37:19FromDiscord<Elegantbeef> Welcome to Nim threading without atomic ref counting
00:37:48FromDiscord<Elegantbeef> Sharing is hard to do safely you need to know when to use `wasMoved` to stop the GC from attempting to free resources
00:38:57FromDiscord<Matt> Ok
00:39:08FromDiscord<Matt> So without knowing much about nim's gc model right now
00:39:29FromDiscord<Matt> Is this doable? I'm not following from your suggestion
00:40:09FromDiscord<Elegantbeef> Nim's GC model is quite simple now, it calls destructors at end of scope, if you share a reference to a thread you need one thread to not destroy it so you need to call `wasMoved` on one side
00:40:54FromDiscord<Matt> I see
00:41:26FromDiscord<Matt> Is there something like "weakref" in Nim that does this
00:41:40FromDiscord<Elegantbeef> There is a `{.cursor.}` annotation, but it's not a weak ref
00:42:19FromDiscord<Matt> I see
00:42:52FromDiscord<Matt> > But please notice that this is not C++'s weak_ptr, it means the right field is not involved in the reference counting, it is a raw pointer without runtime checks.↵↵So it's just a compiler hint but doesnt come with any safety guarantees
00:43:02FromDiscord<Elegantbeef> Right
00:43:57FromDiscord<litlighilit> using `ord` is safer↵(@heysokam)
00:44:08FromDiscord<Elegantbeef> `ord` doesnt work on sets
00:44:44FromDiscord<heysokam> In reply to @litlighilit "using `ord` is safer": ord is for single enums. i want the underlying value of a set of enums
00:44:48FromDiscord<Matt> So if I do use cursor, how would I check if the object is deallocated inside my background thread so that I can exit when the object is wiped
00:45:22FromDiscord<Elegantbeef> I mean you wouldnt use cursor
00:45:55FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4D7K
00:46:15FromDiscord<Elegantbeef> There is no items for your hashset you did not do `import std/sets`
00:46:44FromDiscord<heysokam> i did add it, though
00:46:57FromDiscord<heysokam> or you mean that the set is empty?
00:46:57FromDiscord<Elegantbeef> In the consuming module?
00:47:12FromDiscord<Elegantbeef> Why would the set being empty give a compile time error
00:47:50FromDiscord<heysokam> In reply to @Elegantbeef "In the consuming module?": its a func, shouldn't the consuming module be the same as the one that contains the func itself? 🤔
00:48:15FromDiscord<heysokam> (edit) "its" => "the union call is inside"
00:48:18FromDiscord<Elegantbeef> The issue is the `sets` module
00:48:26FromDiscord<Elegantbeef> `for item in other.items`
00:48:41FromDiscord<Elegantbeef> `for x in y` does not properly look up symbols
00:48:42FromDiscord<heysokam> yeah, but i don't know why that is failing there
00:48:50FromDiscord<Elegantbeef> It's a bug with implicit items
00:49:14FromDiscord<heysokam> a bug in the lang or in my app?
00:49:38FromDiscord<Elegantbeef> You really like being silly, your app is not "implicit items" is it 😛
00:50:23FromDiscord<Elegantbeef> Inside generics `for x in y` does not look up the proper `items`
00:50:25FromDiscord<heysokam> i don't understand what that means
00:50:49FromDiscord<Elegantbeef> In nim for loops `for x in y` implicitly calls `for x in y.items`
00:50:56FromDiscord<Elegantbeef> The look up is broken inside generic procedures
00:51:24FromDiscord<Elegantbeef> The bug is in the language, if it's still unclear
00:51:43FromDiscord<Matt> @ elegantbeef. Sorry, not following- so as it currently stands if I create a thread object within my LSM type and run a proc on it, deallocating the LSM will stop the thread, right?↵↵However, I can't do what I want because the compiler complains about a circular reference. You suggested a second type and mentioned cursor but I'm not 100% clear on how you suggest using them
00:52:03FromDiscord<Elegantbeef> Deallocating the LSM will not stop the thread
00:52:10FromDiscord<Elegantbeef> I didnt suggest a cursor 😄
00:52:59FromDiscord<heysokam> In reply to @Elegantbeef "The bug is in": shoot, well thats a probl i guess 😔↵any ideas how I could do the same in the meantime?
00:53:26FromDiscord<Matt> In reply to @Elegantbeef "Deallocating the LSM will": Interesting. Do you know if that could be done?
00:53:29FromDiscord<Elegantbeef> Copy the procedure into your own module and put `items`
00:54:16FromDiscord<Matt> wdym
00:54:49FromDiscord<Elegantbeef> Seriously is it this hard to have multiple conversations at once
00:54:49FromDiscord<Elegantbeef> That was for skam
00:54:50FromDiscord<Elegantbeef> sokam even
00:55:36FromDiscord<Matt> I filtered out what they were writing honestly
00:55:55FromDiscord<Elegantbeef> Rude
00:56:53FromDiscord<Matt> Not really
00:57:02FromDiscord<Matt> IM ux is heavy
00:57:12FromDiscord<Matt> especially for multiple technical conversations
00:57:15FromDiscord<Elegantbeef> Ok that was clearly satire
00:57:29FromDiscord<Matt> Guess today's not my day
00:58:15FromDiscord<Elegantbeef> I for the life of me cannot remember how to properly disarm a GC hook
01:01:31FromDiscord<heysokam> sent a code paste, see https://paste.rs/S3Ngb
01:01:50FromDiscord<Elegantbeef> Are you sure you have `sets` in this module?
01:01:54FromDiscord<heysokam> yes i do
01:01:58FromDiscord<heysokam> checked like 5 times
01:02:09FromDiscord<Elegantbeef> did you call `.items` explicitly?
01:02:11FromDiscord<heysokam> now its failing with the `toSeq` implementation
01:02:28FromDiscord<heysokam> (edit) "now its failing with the `toSeq` implementation ... " added "from sequtils"
01:03:50FromDiscord<litlighilit> What if to use `ptr` instead?↵(@Matt)
01:06:13FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4D7P
01:07:03FromDiscord<Elegantbeef> I said what I thought it was
01:07:06FromDiscord<Matt> In reply to @litlighilit "What if to use": looking into it as well
01:07:08FromDiscord<Elegantbeef> Anyway I do not thread so I should not try helping anymore
01:07:36FromDiscord<Elegantbeef> You should be able to use `ref` instead of ptr as long as you ensure you only destroy it from one thread, but that's a complicated matter I guess
01:08:09FromDiscord<Matt> I'll follow up tomorrow - think I've hit the wall for today
01:08:10FromDiscord<Matt> Thank you
01:19:39FromDiscord<litlighilit> Is there a show-case?
01:19:52FromDiscord<Elegantbeef> No we have not got a reproduction
01:21:14FromDiscord<litlighilit> Does it come from an empty set literal?
01:21:39FromDiscord<Elegantbeef> Hashsets do not have a literal
01:24:34FromDiscord<Matt> sent a long message, see http://ix.io/4D7S
01:24:52FromDiscord<Matt> Unexpected markdown, disregard
01:24:57FromDiscord<Matt> open to suggestions from all
01:26:49FromDiscord<Matt> + if anyone knows anything about protect/dispose
01:31:43FromDiscord<arathanis> sent a code paste, see https://play.nim-lang.org/#ix=4D7U
01:32:22FromDiscord<Matt> I also found this: 6-7 years old,t hough
01:32:23FromDiscord<Matt> https://github.com/zielmicha/collections.nim/blob/master/collections/weakref.nim
01:32:44FromDiscord<arathanis> also can you specify the source file in the task without just using `exec "nim c ..."`?
01:32:56FromDiscord<litlighilit> nimble tasks
01:33:09FromDiscord<Elegantbeef> they're not using nimble
01:33:19FromDiscord<Elegantbeef> They're using nim's nimscript tasks
01:33:22FromDiscord<Elegantbeef> I do not know if there's a way to list them arath
01:33:42FromDiscord<arathanis> i was afraid of that, ill keep looking
01:33:55FromDiscord<arathanis> hopefully there is a way but i guess there is always "look at the config.nims file" lmao
01:34:06FromDiscord<Elegantbeef> Oh the docs say make `nim help` print commands
01:34:33FromDiscord<arathanis> god, did i just miss it completely? checking...
01:34:55FromDiscord<Elegantbeef> Yea it does
01:35:17FromDiscord<Elegantbeef> https://nim-lang.org/docs/nims.html#nimscript-as-a-build-tool documented here
01:35:59*sneekyfoxx joined #nim
01:36:03FromDiscord<arathanis> ok i figured it out
01:36:13FromDiscord<arathanis> it show up with `nim help` but not `nim --help`
01:36:27sneekyfoxxquit
01:36:28FromDiscord<arathanis> also its missing a space, the formatting drives me insane
01:36:34*sneekyfoxx quit (Client Quit)
01:36:39FromDiscord<Elegantbeef> No
01:36:40FromDiscord<Elegantbeef> You're here now
01:37:03FromDiscord<Elegantbeef> What's missing a space?
01:37:07FromDiscord<arathanis> sent a long message, see http://ix.io/4D7V
01:38:17FromDiscord<arathanis> In reply to @Elegantbeef "What's missing a space?": oh wait nvm my terminal was jacked up
01:38:30FromDiscord<arathanis> when i did `nim help`
01:38:33FromDiscord<arathanis> it printed the help as
01:38:37FromDiscord<arathanis> `nimbuild build the program`
01:38:44FromDiscord<arathanis> but now its not doing that
01:39:14FromDiscord<arathanis> Beef, is there a way to specify the source file beyond just using `exec "nim c <src>"` in a task?
01:39:35FromDiscord<Elegantbeef> No clue
01:39:50FromDiscord<arathanis> sent a code paste, see https://play.nim-lang.org/#ix=4D7W
01:40:40FromDiscord<Elegantbeef> Certainly not now that I think about it
01:41:04FromDiscord<Elegantbeef> PS use `selfExec`
01:46:11FromDiscord<litlighilit> When it comes to ownership, there is `owned` type in nim↵(@Matt)
01:49:42FromDiscord<Elegantbeef> No there isnt
02:03:09FromDiscord<arathanis> In reply to @Elegantbeef "PS use `selfExec`": so I can invoke `selfExec` to invoke the rest of the command?
02:03:38FromDiscord<arathanis> sent a code paste, see https://play.nim-lang.org/#ix=4D80
02:04:01FromDiscord<Elegantbeef> No clue
02:09:44FromDiscord<litlighilit> if `-d:nimOwnedEnabled`
02:09:52FromDiscord<Elegantbeef> Right and that means nothing
02:10:20FromDiscord<Elegantbeef> `std/isolation` exists and `sink`/`lent` exist
02:11:13FromDiscord<Elegantbeef> owned will be removed eventually
03:16:54FromDiscord<terrygillis> sent a long message, see http://ix.io/4D8f
03:17:22FromDiscord<terrygillis> (edit) "http://ix.io/4D8f" => "http://ix.io/4D8g"
03:19:16FromDiscord<Elegantbeef> This is cause `c` is a `var T` and to make a closure of that `Counter` it needs to be a place that is guaranteed to outlive `later`
03:19:40FromDiscord<Elegantbeef> Nim does not have a borrow checker so this means `c` needs to be `c: ref Counter`
03:21:28FromDiscord<terrygillis> why in this case does inner() not outlive later()?
03:22:28FromDiscord<Elegantbeef> Nim doesnt have a smart checker, it literally just says "this is a closure it cannot capture `var T`"
03:23:12FromDiscord<Elegantbeef> https://play.nim-lang.org/#ix=4D8h
03:23:17FromDiscord<Elegantbeef> gets around the checker in this case
03:23:23FromDiscord<Elegantbeef> Don't use it unless you know it's safe to
03:23:37FromDiscord<terrygillis> Ah I see, so effectively capturing stack allocated reference is banned from Nim right?
03:25:00FromDiscord<Elegantbeef> Yes cause it has no way to ensure it safely
03:25:21FromDiscord<Elegantbeef> It will get a borrow checker eventually, but does not have a non experimental one presently
03:25:45FromDiscord<terrygillis> but why is it compiling here: https://play.nim-lang.org/#ix=4D8i?
03:26:17FromDiscord<terrygillis> (edit) "https://play.nim-lang.org/#ix=4D8i?" => "https://play.nim-lang.org/#ix=4D8i ?"
03:26:38FromDiscord<Elegantbeef> It's copying the variable
03:28:21FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4D8k
03:31:28FromDiscord<terrygillis> that's a bit confusing, like why if I pass a `var T` in a proc then that proc cannot capture it in a closure, but if I declare as a `var` in a proc directly then it would be captured and actually modifiable?
03:32:40FromDiscord<terrygillis> sent a code paste, see https://play.nim-lang.org/#ix=4D8m
03:33:02FromDiscord<terrygillis> sent a code paste, see https://play.nim-lang.org/#ix=nbd
03:34:20FromDiscord<terrygillis> (edit) "https://play.nim-lang.org/#ix=4D8m" => "https://play.nim-lang.org/#ix=4D8n"
03:34:35FromDiscord<terrygillis> (edit) "https://play.nim-lang.org/#ix=4D8n" => "https://play.nim-lang.org/#ix=4D8o"
03:35:37FromDiscord<terrygillis> sorry for constantly editing the message if anyone is bothered
03:36:58FromDiscord<Elegantbeef> I don't know what to say it clearly copies https://play.nim-lang.org/#ix=4D8q
03:42:42*disso-peach joined #nim
03:43:01FromDiscord<terrygillis> In reply to @Elegantbeef "I don't know what": Ok, to clarify, do you mean copy in the sense "copy the reference to that variable" or "copy the value of that variable", because in both the code you sent and my code above, `inner` is clearly capturing the reference to `var counter` and increasing `counter.start` every time it gets called?
03:43:37FromDiscord<Elegantbeef> It's capturing a copied version that is not stack allocated
03:48:05FromDiscord<terrygillis> sent a code paste, see https://paste.rs/ZbhuL
03:48:27FromDiscord<Elegantbeef> Ah this is simple
03:48:28FromDiscord<Elegantbeef> Whenever a procedure creates a closure the variables that are captured are aliase to the scope
03:48:45FromDiscord<Elegantbeef> > Any captured variables are stored in a hidden additional argument to the closure (its environment) and they are accessed by reference by both the closure and its enclosing scope (i.e. any modifications made to them are visible in both places).
03:48:48FromDiscord<Elegantbeef> From the manual
03:49:14NimEventerNew thread by isaiah: What is the best way to learn nim for someone who is fluent with python, see https://forum.nim-lang.org/t/10394
03:49:38FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4D8t
03:49:49FromDiscord<Elegantbeef> Which gives you a nice ergonomic api that just works
03:50:53FromDiscord<Elegantbeef> This is why `for x in 0..3: let z = (proc(): int = x)` doesnt work as expected
03:56:09FromDiscord<Elegantbeef> Well that does but when you store that into a proc that outlives the for loop
03:57:14FromDiscord<terrygillis> I thought as the for loop ends, its scope which includes proc z is dropped entirely?
03:59:00FromDiscord<Elegantbeef> Well like i said it should outlive the for loop
03:59:26FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4D8u
03:59:37FromDiscord<Elegantbeef> now if you call those procs you get a nice unexpected behaviour
03:59:40FromDiscord<terrygillis> ah that one I see
04:01:02FromDiscord<terrygillis> but back to the previous: "it actually aliases counter to inner.env.counter internally" is a bit muddy to me (sorry I'm still a novice). Can you clarify a bit more?
04:01:36FromDiscord<Elegantbeef> closure procedures store an environment with the data they capture
04:02:13FromDiscord<Elegantbeef> when you declare a closure inside of a procedure that captures a variable it aliases that variable to a global environment
04:02:37FromDiscord<terrygillis> a so it is passed in a reference to `var counter` everytime it gets called, right?
04:02:47FromDiscord<terrygillis> (edit) "a" => "ah"
04:02:54FromDiscord<terrygillis> (edit) removed "in"
04:03:06FromDiscord<Elegantbeef> Hidden away from you yes
04:08:04FromDiscord<odexine> Doesn’t Nim have that closure capture proc to fix this
04:08:12FromDiscord<odexine> I didn’t read the whole chat I just got here
04:12:35FromDiscord<terrygillis> sent a code paste, see https://play.nim-lang.org/#ix=4D8x
04:13:59FromDiscord<Elegantbeef> `var Counter` is a might be on a reference or the stack and there is no way to propagate that it's now owned by a closure, there's also no back propagation
04:14:44FromDiscord<Elegantbeef> back propagation to change where it's pointing
04:15:32FromDiscord<Elegantbeef> regardless `var T` cannot be captured cause it's not safe to do such as you need to ensure the resource stays alive as long as the closure exists, in this case it's fine but Nim just applies a wide brush on disallowing it
04:18:11FromDiscord<terrygillis> In reply to @Elegantbeef "regardless `var T` cannot": ah so it's just that the compiler is not smart enough to guarantee that counter will outlive inner so it just ban it for safety concern.
04:19:19FromDiscord<Elegantbeef> Well it requires following the life time of the closure and seeing whether `inner` escapes the scope, so you need a borrow checker
04:19:19FromDiscord<Elegantbeef> we do have `views` but it's experimental
04:20:44FromDiscord<terrygillis> In reply to @Elegantbeef "`var Counter` is a": but I don't understand this really, I thought `var Counter` is kinda a reference to a Counter object on the stack, and googling back propagation gives me some machine learning mouthful.
04:21:14FromDiscord<jakraes> Is there a way to give a value to attributes inherited from a parent object?
04:21:48FromDiscord<jakraes> Like, a game entity has an attribute called HP, and I want the player, which inherits from game entity to have 20 hp by default
04:21:52FromDiscord<Elegantbeef> `var Counter` is a pointer to a `Counter` anywhere
04:22:07FromDiscord<Elegantbeef> It can be in a `seq` a `ref object` a `ref Counter` it can be anywhere
04:22:43FromDiscord<Elegantbeef> back propagation in that there is no way of saying "This now points here" since you do not own the resource that you're making a closure of, you can do it inside of proc cause you own that resource
04:24:23FromDiscord<terrygillis> In reply to @Elegantbeef "It can be in": wait what, so `c: var Counter` will accept a `ref Counter` as an argument?
04:24:41FromDiscord<Elegantbeef> No it'll accept a `Counter` that is from a ref
04:25:13FromDiscord<Elegantbeef> Completely valid code
04:25:14FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4D8y
04:28:04FromDiscord<terrygillis> ah, so is there a way for a proc to actually demand that the argument passed in must be allocated on the stack? (just a curious question)
04:28:24FromDiscord<Elegantbeef> Not without concepts and macros
04:30:40FromDiscord<terrygillis> Thank you very much. Well, for the first time while trying out nim, I encounter something that is as hairy as fighting the rust borrow checker 😭
04:31:14FromDiscord<Elegantbeef> It's not that hairy
04:31:48FromDiscord<Elegantbeef> if you know it's safe to reference you do `let myCounter = counter.addr` if it's not safe and you do not care that it points to the original you do `var counter = counter`
04:34:13FromDiscord<terrygillis> btw does manually dereferencing a ref type with `[]` classify as an unsafe or safe operation?
04:44:33FromDiscord<odexine> Depends if you think dereferencing nil is safe or not
05:05:26*rockcavera quit (Remote host closed the connection)
05:27:37FromDiscord<ajusa> sent a code paste, see https://play.nim-lang.org/#ix=4D8G
05:29:06*advesperacit joined #nim
05:29:30FromDiscord<Elegantbeef> `rss: (Channel,)` 😄
05:29:36FromDiscord<Elegantbeef> But yea there is no inline object
05:30:44FromDiscord<ajusa> no macros that do anything similar which you are aware of beef?
05:31:11FromDiscord<Elegantbeef> I personally have the view that anonymous objects defeat the purpose of objects, so if there I do not know of it
05:33:05FromDiscord<Elegantbeef> Also `Channel` might be wrong it's a generic type
05:33:32FromDiscord<ajusa> ah no this is my own channel type, I'm not importing threads
05:36:05*advesperacit quit (Read error: Connection reset by peer)
05:36:53FromDiscord<Elegantbeef> If anyone has anon objects it'd be metagn, they do cool shit
05:37:37*advesperacit joined #nim
06:22:46FromDiscord<ringabout> Indeed 🤣
06:24:08NimEventerNew Nimble package! mapster - A library to quickly generate functions converting instances of type A to B, see https://github.com/PhilippMDoerner/mapster
06:25:39*ntat joined #nim
06:25:40FromDiscord<Elegantbeef> @Phil\: you forgot to mention which module to import in your examples
06:25:47FromDiscord<Elegantbeef> Literally unusable
06:26:22FromDiscord<Phil> Tfw you realize on the way to work that you left in the dummy tests in the package itself
06:26:24FromDiscord<Elegantbeef> "Oh i'll import 'mapster'.... wait why is my program printing inane shit"
06:27:01FromDiscord<Elegantbeef> And you want mocked procedures, the only mocking we do around here is personal
06:27:24FromDiscord<Phil> Eh, I'll fix it when I'm back, not like my packages actually grow that much of a user base.↵Majority of the time I'm my own user and I have patience
06:27:53FromDiscord<Elegantbeef> Yea I just noticed it so thought I'd annoy you here instead of making an issue
06:28:04FromDiscord<Phil> Fair
06:28:42FromDiscord<Phil> In reply to @Elegantbeef "And you want mocked": If I ever figure out how to deal with generics we shall have those!
06:29:27FromDiscord<Elegantbeef> Such wasted effort 😄
06:29:49FromDiscord<Phil> Eh, agree to disagree
06:53:38*azimut quit (Ping timeout: 240 seconds)
07:08:51*junaid_ joined #nim
07:17:02*junaid_ quit (Remote host closed the connection)
09:06:39FromDiscord<heysokam> is there a way to get a string `"name"` from `name :untyped` input in a template? 🤔
09:07:24FromDiscord<Elegantbeef> Nope
09:07:40FromDiscord<Elegantbeef> `astToStr(name)` will be turned into `astToStr(whatever passed here)`
09:08:20FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#ix=4D9u
09:09:09FromDiscord<heysokam> only the examples depend on vmath and other things, but there are like 15+ so writing `taskRequires` for all of them and all of the libraries gets tiresome quick
09:11:51FromDiscord<heysokam> In reply to @Elegantbeef "Nope": is it possible to do the opposite, and get a string into an untyped word instead? 🤔
09:22:37FromDiscord<Elegantbeef> Make a macro that converts it to an ident
09:24:30FromDiscord<litlighilit> This works if passed a arg from template
09:24:47FromDiscord<System64 ~ Flandre Scarlet> I try to parse an xml file, is it possible to query elements? https://media.discordapp.net/attachments/371759389889003532/1139489576277245952/image.png
09:28:35FromDiscord<litlighilit> sent a code paste, see https://play.nim-lang.org/#ix=4D9x
09:39:09FromDiscord<heysokam> is there a way to revert the effects of a `{.dirty.}` template, but just for one specific symbol?
09:39:22FromDiscord<heysokam> aka the opposite of `.inject.`
09:40:35FromDiscord<litlighilit> {.genSym.}
09:41:51FromDiscord<heysokam> taskRequires doesn't seem to be solving the dependency anyway... so not like the template I made is that useful anyway 😔
09:42:02FromDiscord<heysokam> (edit) "dependency anyway..." => "dependency..."
09:42:33*junaid_ joined #nim
09:42:59FromDiscord<litlighilit> Opp, I find in above example, {.inject.} can be omitted, as the template is {.dirty.}
09:44:58FromDiscord<litlighilit> ? details
09:45:52FromDiscord<heysokam> In reply to @litlighilit "Opp, I find in": yeah i noticed that the template doesn't need to be dirty at all
09:47:33FromDiscord<litlighilit> Also, if you don't use strformat for name, there is no need to inject a temporary symbol like `name_str`
09:48:29FromDiscord<litlighilit> sent a code paste, see https://play.nim-lang.org/#ix=4D9B
09:50:34FromDiscord<Hamid_Bluri> In reply to @sys64 "I try to parse": not sure but this might help you https://nimble.directory/pkg/q
09:52:06FromDiscord<Hamid_Bluri> In reply to @sys64 "I try to parse": this too https://nimble.directory/pkg/nimpath
09:55:36FromDiscord<System64 ~ Flandre Scarlet> the seconds sounds more complex to use
09:56:08FromDiscord<System64 ~ Flandre Scarlet> https://nim-lang.org/docs/xmltree.html#XmlNode↵I use that but seems it's not as easy to use as the JSON one
09:56:20FromDiscord<System64 ~ Flandre Scarlet> https://nim-lang.org/docs/xmlparser.html↵Well that, sorry
09:57:52FromDiscord<Hamid_Bluri> In reply to @sys64 "https://nim-lang.org/docs/xmltree.html#XmlNode I us": why is not easy?
09:58:24FromDiscord<Hamid_Bluri> https://nimble.directory/pkg/nimquery
09:59:14FromDiscord<Hamid_Bluri> sure XML does not have `int`, `float` ,... types but that's not way hard
10:15:44NimEventerNew thread by radekm: Nim 2 and need for try-finally?, see https://forum.nim-lang.org/t/10395
10:16:40FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#ix=4D9I
10:16:58FromDiscord<System64 ~ Flandre Scarlet> It's very easy to navigate through the tree with JSON
10:38:03FromDiscord<terrygillis> sent a code paste, see https://paste.rs/wJXf7
10:39:25FromDiscord<terrygillis> (edit) "https://play.nim-lang.org/#ix=4D9K" => "https://play.nim-lang.org/#ix=4D9L"
10:39:39FromDiscord<terrygillis> (edit) "https://play.nim-lang.org/#ix=4D9L" => "https://play.nim-lang.org/#ix=4D9N"
10:44:34*junaid_ quit (Remote host closed the connection)
10:49:10FromDiscord<terrygillis> sent a code paste, see https://play.nim-lang.org/#ix=4D9P
10:56:56FromDiscord<System64 ~ Flandre Scarlet> Alright so I start to understand how to parse XML
11:05:16FromDiscord<Hamid_Bluri> In reply to @sys64 "Alright so I start": the problem is XML entries can be repeateed unlike JSON object keys
11:05:25FromDiscord<Hamid_Bluri> (edit) "In reply to @sys64 "Alright so I start": the problem is ... XML" added "that"
11:07:21FromDiscord<demotomohiro> In reply to @terrygillis "hi, I'm trying out": `addT`'s first parameter is `TType` but you calls `addT` without `TType` argument.
11:08:22FromDiscord<System64 ~ Flandre Scarlet> In reply to @hamidb80 "the problem is that": XML is like poor HTML
11:09:16FromDiscord<System64 ~ Flandre Scarlet> but it's great for GUIs (XAML and FXML are things)
11:24:32FromDiscord<terrygillis> In reply to @terrygillis "hi, I'm trying out": oops sorry I mistranslated from my code. Here’s my problematic code: https://play.nim-lang.org/#ix=4D9X
11:25:52FromDiscord<terrygillis> The error message from the compiler only shows ‘type mismatch: got 'string' for 'text' but expected 'float'’ but the vscode extension would show the reverse for the code below too, where I pass in the number
11:52:44FromDiscord<litlighilit> use when
12:01:28FromDiscord<litlighilit> Nim is static-typed, one symbol must only has one type.↵↵When nim compiles your code, both `t.floatField = a` and `t.stringField = a` are solved and nimc complains `a` can't be both `float` and `string`↵(@terrygillis)
12:05:02FromDiscord<double_spiral> You probably shouldnt be doing stuff like that in python either, can make your code confusing and hard to keep track of
12:07:12FromDiscord<litlighilit> One small point\:↵↵In addtion, better to use `elif` or `case` (if there're more cases) instead of double `if` or `when` (as they're mutually exclusive.
12:07:44PMunchlitlighilit, case doesn't have a compile-time equivalent unfortunately
12:07:47FromDiscord<litlighilit> Also, maybe using generics or overload would be simpler.
12:09:41FromDiscord<litlighilit> All right, that would requires macros.
12:11:23FromDiscord<litlighilit> I myself came to forget this😅
12:15:45*PMunch_ joined #nim
12:18:21FromDiscord<nervecenter> In reply to @terrygillis "oops sorry I mistranslated": You can use an object variant for this:↵https://nim-lang.github.io/Nim/manual.html#types-object-variants
12:19:02*PMunch quit (Ping timeout: 252 seconds)
12:19:52FromDiscord<terrygillis> In reply to @nervecenter "You can use an": I thought I’m already using object variant?
12:19:55*PMunch_ is now known as PMunch
12:20:18FromDiscord<terrygillis> or am I mistaking something?
12:20:40FromDiscord<nervecenter> Look at the documentation, it must be contained in a `ref`
12:29:00FromDiscord<terrygillis> In reply to @nervecenter "Look at the documentation,": The documentation doesn’t seem to stress specifically that it should be a ref type, and when I’m using it as stack allocated type it does not error. What is the catch here?
12:30:36FromDiscord<odexine> Object variants do not need to be references
12:31:05FromDiscord<odexine> The reason it uses a reference in the example is because the object contains itself
12:34:26FromDiscord<terrygillis> So it’s not that I’m mistaking right?
12:35:23*PMunch quit (Quit: Leaving)
12:39:30FromDiscord<odexine> The mistake is as lit says
12:41:33FromDiscord<terrygillis> In reply to @odexine "The mistake is as": Ah yes, that’s a different one. Also, what is the scope of things in template, as I thought it’s just code substitution
12:42:19FromDiscord<terrygillis> I mean:
12:43:44FromDiscord<terrygillis> sent a code paste, see https://play.nim-lang.org/#ix=4Dab
12:44:33FromDiscord<terrygillis> this thing does not compile, so it's not just substitution
12:44:50FromDiscord<terrygillis> what is at play in templates?
12:51:52FromDiscord<odexine> Templates do not introduce a new scope but it does sanitise variable names
12:52:03*rockcavera joined #nim
12:54:18FromDiscord<terrygillis> so any variables declared inside template would not be accessible from outside, right?
13:10:53FromDiscord<juan_carlos> sent a code paste, see https://play.nim-lang.org/#ix=4Dai
13:17:10FromDiscord<terrygillis> sent a code paste, see https://paste.rs/B3isw
13:19:45FromDiscord<demotomohiro> identifier 'x' in template body is replaced with the identifier in call site.
13:21:01FromDiscord<demotomohiro> https://nim-lang.org/docs/manual.html#templates-hygiene-in-templates
13:26:41FromDiscord<demotomohiro> sent a code paste, see https://play.nim-lang.org/#ix=4Dal
13:44:56FromDiscord<terrygillis> why is this not working as a template?
13:45:07FromDiscord<terrygillis> sent a code paste, see https://play.nim-lang.org/#ix=4Dat
13:45:23FromDiscord<terrygillis> `Error: expression 'true' is of type 'bool' and has to be used (or discarded)`
13:46:23FromDiscord<odexine> No return type on the template
13:47:36FromDiscord<terrygillis> I thought it's just substitution. return type is required like proc too?
13:48:50*lucasta joined #nim
13:50:17FromDiscord<terrygillis> in the manual every example returns `untyped`
14:07:16FromDiscord<litlighilit> By default, template's return type is typed
14:08:43FromDiscord<litlighilit> which means that its body can't have a value
14:11:17FromDiscord<litlighilit> here `untyped` tells nim not to check the value, i.e. whether have a value, so `void`(no value) or any other type is valid↵(@terrygillis)
14:14:23FromDiscord<litlighilit> True and recommended if this improve readability, compared with `untyped`↵(@terrygillis)
14:16:08FromDiscord<litlighilit> [Edit](https://discord.com/channels/371759389889003530/371759389889003532/1139561678489534464): here `untyped` tells nim not to check the value, i.e. whether has a value, so `void`(no value) or any other type is valid
14:33:04*azimut joined #nim
14:59:09FromDiscord<Phil> Alrighty, mapster package cleaned up
15:11:26FromDiscord<terrygillis> why does nim float lose decimal precision at 60 while in c it's 31?
15:11:47qwrimho its corresponds to C double
15:11:55FromDiscord<odexine> Float in Nim is always 64 bits
15:12:11FromDiscord<odexine> No matter the platform
15:12:37FromDiscord<odexine> If you want single size floats use float32
15:15:06FromDiscord<terrygillis> sent a code paste, see https://play.nim-lang.org/#ix=4DaX
15:16:53FromDiscord<terrygillis> sent a code paste, see https://play.nim-lang.org/#ix=4DaY
15:17:25FromDiscord<terrygillis> somewhere it says float can range from 1.175494351 E - 38 to 3.402823466 E + 38
15:17:50FromDiscord<terrygillis> which I don't know how relates to this precision cut-off
15:19:31NimEventerNew thread by Isofruit: Mapster - Because life is too short to map A to B, see https://forum.nim-lang.org/t/10396
15:53:47FromDiscord<litlighilit> It's just due to binary system, ↵like when we use decimal system, we cannot represent 1/3 accurately
15:56:59FromDiscord<litlighilit> If you're comparing with other language like Python, you may wanna say Python can represent 64.1 internally. But it's not true.↵(@terrygillis)
15:59:12FromDiscord<terrygillis> so 64 is not really the floating point precision cut off?
15:59:21FromDiscord<litlighilit> As long as one lang use IEE794, it cannot store some floats as small as 0.1 (in fact it doesn't matter whether it's small)
16:00:05FromDiscord<terrygillis> but the code prints 63.1 as it is while 64.1 gets distorted
16:00:20FromDiscord<terrygillis> why is that?
16:00:26FromDiscord<litlighilit> Round
16:01:40FromDiscord<litlighilit> There is a mechanism inside `represent a float`\: rounding
16:02:22FromDiscord<litlighilit> try `0.4-0.1`
16:02:56FromDiscord<litlighilit> Or `0.4-0.1 == 0.3`
16:07:47FromDiscord<litlighilit> sent a long message, see http://ix.io/4Dba
16:09:24FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=4Dbb
16:10:10FromDiscord<litlighilit> For details, refer to IEE-794.
16:10:29FromDiscord<System64 ~ Flandre Scarlet> Is there a library to load PNGs? Especially color-indexed PNGs
16:11:03FromDiscord<ieltan> pixie ?
16:11:07FromDiscord<arathanis> daaaang. `selfExec` doesn't seem to inherit the command and switches you set
16:11:12FromDiscord<ieltan> In reply to @sys64 "Is there a library": https://github.com/treeform/pixie
16:12:03FromDiscord<System64 ~ Flandre Scarlet> In reply to @ieltan "https://github.com/treeform/pixie": Ah yeah, I have this↵Will read the docs to find out about Color-Indexed PNGs
16:12:54FromDiscord<ieltan> ah, not sure if it support color indexes
16:15:06FromDiscord<System64 ~ Flandre Scarlet> @treeform Does Pixie supports PNGs that use a Palette?
16:17:17FromDiscord<ieltan> Reading pixie source code it seems like it actually implements file formats in pure Nim ? That's so cool !
16:25:47FromDiscord<System64 ~ Flandre Scarlet> would be nice to be able to get a PNG's palette
16:26:07FromDiscord<System64 ~ Flandre Scarlet> but looks like I'll have to use LibPNG or something
16:35:59NimEventerNew thread by mildred: IPv6 compatibility (dual-stack AF_UNSPEC), see https://forum.nim-lang.org/t/10397
16:36:40FromDiscord<exelotl> In reply to @sys64 "would be nice to": NimPNG exists which can do this, and is probably easier than libpng
16:36:48FromDiscord<exelotl> <https://github.com/jangko/nimPNG>
16:37:04*lucasta quit (Quit: Leaving)
16:38:18FromDiscord<exelotl> example where I use it: https://github.com/exelotl/trick/blob/master/src/trick/gfxconvert.nim#L259-L262
16:38:42FromDiscord<System64 ~ Flandre Scarlet> In reply to @exelotl "NimPNG exists which can": Just found thit, will give it a try
17:05:45FromDiscord<treeform> In reply to @sys64 "<@107140179025735680> Does Pixie supports": I don't think so, they are very rare? Try it I don't remember...
17:06:01FromDiscord<treeform> In reply to @ieltan "Reading pixie source code": Yes it does, that's why we wanted pure nim.
17:06:19FromDiscord<odexine> In reply to @treeform "Yes it does, that's": What do you mean wanted pure Nim
17:06:26FromDiscord<odexine> Wanted it for what?
17:08:14FromDiscord<ieltan> Think it's better to have a pure implementation than c bindings
17:25:50FromDiscord<treeform> Yes pure Nim is better then C bindings. Once we get pure Nim version we can optimize it faster then any C code. And we did we have one of the fastest PNG readers, because we have one of the fastests zip implemeantions. Its all really cool to us.
17:26:59*qwr . o O ( technically not true, nim compiles to C code... )
17:27:48FromDiscord<ieltan> Only real flaw is that it's super hard to contribute anything new to the library, you need to have skills™ and reading a spec and implementing it is something most programmers have never done before
17:29:16FromDiscord<treeform> In reply to @qwr ". o O (": We have proven again and again that we can write faster Nim code that people can write C code. Once you have a compiled langage the speed of the code is in smart algorithms > memory allocations > pointer indirection > branch prediction.
17:31:42FromDiscord<treeform> zlib is used by pretty much all software. Its been around for like 30 years. But guzba was just pretty smart about it and wrote zlib in nim that is x1.5 - x2.0 faster.
17:31:47*genr8eofl joined #nim
17:31:52FromDiscord<treeform> https://github.com/guzba/zippy
17:32:24FromDiscord<treeform> Technically the C people can write code just like Nim compiler does. But why don't they?
17:32:37FromDiscord<treeform> We both use C in the end?
17:32:48FromDiscord<treeform> I think large projects are just hard in C so getting anything working at all is a big win.
17:33:06FromDiscord<treeform> While large projects in Nim are much easier, and you can focus your time in hotspots.
17:33:42qwrpretty believable you can beat code hand-written to be more likely to work despite the shoot-your-foot traps in C
17:34:18qwrbut technically you still have then machine generated fast C code :)
17:34:58FromDiscord<treeform> yeah the zlib people could just take our Nim to C output and just copy paste that into their project to be faster...
17:35:11FromDiscord<treeform> (edit) "faster..." => "as fast..."
17:35:35qwrand why - the handwritten C tends to use lot of pointer indirection and OO-like encapsulation thats probably is evaded by nim
17:35:43FromDiscord<treeform> yes
17:35:49FromDiscord<TheUnderName> Hi
17:35:54FromDiscord<treeform> Because stuff is hard in C they try to write it the easy way
17:36:09FromDiscord<ieltan> In reply to @treeform "yeah the zlib people": Might as well just rewrite the actual project in Nim and expose a C API
17:36:27FromDiscord<treeform> Thats why we wrote https://github.com/treeform/genny
17:36:36FromDiscord<treeform> to expose the coolness of Nim to other langs easy
17:37:34FromDiscord<TheUnderName> Nim translates to C?
17:37:57FromDiscord<ieltan> Wow!
17:38:34qwrC is stable interface to multiple compiler backends
17:39:40FromDiscord<treeform> In reply to @TheUnderName "Nim translates to C?": Not always, but most likely when you compile Nim it produces a C file that the C compiler then compiles.
17:39:42qwrthough, Nim also compiles to C++ and javascript
17:40:45FromDiscord<TheUnderName> In reply to @treeform "Not always, but most": What do you mean by "not always"?
17:42:41FromDiscord<treeform> Some times you compile to JavaScript or even more rare run Nim as a script.
17:42:53FromDiscord<treeform> And some times C++, but usually its same compiler...
17:44:12FromDiscord<TheUnderName> Great, but how is Nim different from other languages? Haxe does the same.
17:47:57qwrtreeform: fyi, genny README seems to have typo (its usually called kebab-case, not kabob-case :))
17:48:42FromDiscord<ieltan> In reply to @TheUnderName "Great, but how is": You would need someone who is both fluent in Nim and Haxe to answer that question
17:51:25FromDiscord<TheUnderName> In reply to @ieltan "You would need someone": I have worked a little, especially in managing buffers and reading them
17:53:16FromDiscord<TheUnderName> was a pain in the ass
17:53:37*qwr is not fluent, but read about haxe some time ago, and it is a bit similar in generating code for existing compilers, but haxe seems to be more about "write once, run/integrate into different runtimes/VMs" - it has lot of targets: https://haxe.org/documentation/introduction/compiler-targets.html
17:55:40qwralso, haxe is pretty big, and imho don't fit at all nims lightweight, systems programming niche
17:56:11FromDiscord<jos7388> In reply to @qwr "C is stable interface": I’m convinced C is the new ASM
17:58:41FromDiscord<jos7388> have you seen Beef?
18:00:08FromDiscord<TheUnderName> In reply to @jos7388 "I’m convinced C is": I?
18:02:54FromDiscord<Phil> In reply to @jos7388 "I’m convinced C is": insert link to famous article that C is not a language, it's a compilation target
18:03:33FromDiscord<Phil> https://faultlore.com/blah/c-isnt-a-language/
18:06:10FromDiscord<TheUnderName> In reply to @isofruit "*insert link to famous": Then cpp is not a language xD
18:07:05FromDiscord<Phil> Eh, the article arguments since everbody has to be able to talk to C and everybody talks to each other via C, that C is a protocol (and compilation target) more than a lang
18:07:34FromDiscord<Phil> Can't say the same for C++, nobody sane would want to have 2 separate languages implement ways to talk to each other in C++ specific terms
18:08:53FromDiscord<TheUnderName> In reply to @isofruit "Eh, the article arguments": Let's accept that C is obsolete and people choose Rust instead
18:09:49FromDiscord<Phil> Depends, but I mean from where I stand everything is better than C, even if Rust is a bit harsh on the eyes
18:10:16FromDiscord<Phil> But that is, disclaimer, from the perspective of somebody that rarely, if ever, actually has to deal with memory management
18:11:04FromDiscord<Phil> As my field is web/webdev and perfecting memory moves/copies is not going to be anywhere near as impactful as having decent strategies for optimizing DB useage
18:11:13FromDiscord<odexine> I mean what does it mean for something to be better
18:11:32FromDiscord<odexine> When it comes to these languages we have it’s so reliant on what the user needs
18:11:55FromDiscord<odexine> Is rust better than C when you’re running on an exotic computer?
18:16:42FromDiscord<TheUnderName> sent a code paste, see https://play.nim-lang.org/#ix=4DbA
18:19:06FromDiscord<jos7388> i think rust is kind of ass
18:19:28FromDiscord<jos7388> it's good for procedural stuff
18:19:44FromDiscord<jos7388> but anything where you have loads of retained state flying around or need dynamic linking, it massively overcomplicates stuff
18:20:03FromDiscord<jos7388> that's why UI is in such a rough place in rust
18:21:52FromDiscord<TheUnderName> Each language has its advantages and disadvantages, and it is still difficult and expensive to replace millions of codes with Rust.
18:23:56FromDiscord<TheUnderName> However, C and C++ are much better languages ​​than Rust's ugly syntax:)
18:29:21FromDiscord<jos7388> rust is literally the only language pretending to be a general purpose language where aliasing is impossible
18:29:39FromDiscord<jos7388> that's why i think of it in a separate class
18:32:31FromDiscord<nervecenter> Rust's biggest problem is more than other statically typed languages, and definitely more than Nim, you need to have your spec pre-arranged and your ducks in a row or else refactoring becomes a bit of a nightmare. Between its abstractions, types, and syntax, a lot of work goes into a change to the spec, similar to C++.
18:32:40FromDiscord<nervecenter> I guess they're competing with each other so that's to be expected
18:32:53FromDiscord<nervecenter> Nim is probably the most frictionless static language I've ever used
18:32:57FromDiscord<jos7388> i think the issue is lack of aliasing personally
18:33:15FromDiscord<jos7388> u can't have deep call stacks, because you're locking a shitload of memory via the borrow checker as u make it deeper
18:33:25FromDiscord<jos7388> so anything OOP-like will just never, ever work
18:33:29FromDiscord<jos7388> that's why ECS exists
18:33:37FromDiscord<jos7388> u get row polymorphism
18:33:42FromDiscord<jos7388> to simulate OOP-style polymorphism
18:33:51FromDiscord<jos7388> and ur call stacks don't get deep, instead you work only on dependencies you know upfront
18:33:57FromDiscord<jos7388> (edit) "exists" => "is so popular in Rust"
18:34:09FromDiscord<jos7388> and u pass it off to another "system" which also has a shallow call stack
18:34:24FromDiscord<jos7388> i think there is a way to supplement all of rust's shortcomings by building a framework with those things in mind
18:34:36FromDiscord<jos7388> but i don't know how to do it and nobody seems to have done it yet
18:35:18FromDiscord<ieltan> If you've read the blogpost from Rust ex-BDFL venting about how lifetimes were supposed to be inferred and not explicit, I immediately thought "I think he'd like Nim for this"
18:35:31FromDiscord<nervecenter> Oh wow
18:35:37FromDiscord<nervecenter> That's...a MAJOR fuckup
18:35:48FromDiscord<nervecenter> That would completely change the language
18:35:49FromDiscord<ieltan> Of course if only view types worked lol...
18:36:22FromDiscord<jos7388> why would that change it much though, you still can't violate aliasing rules either way
18:36:28FromDiscord<jos7388> you would still have the same fundamental limitations on what you can and can't write
18:36:42FromDiscord<ieltan> In reply to @nervecenter "That's...a MAJOR fuckup": I don't know, yes it'd change the language, but I don't know if it would have "killed" it's future
18:37:02FromDiscord<System64 ~ Flandre Scarlet> In reply to @treeform "I don't think so,": Oh, woops
18:37:25FromDiscord<ieltan> He was BDFL but even back then it seemed to be very committee'ish
18:37:42FromDiscord<nervecenter> In reply to @ieltan "I don't know, yes": I'm not saying it would've killed it, I'm saying it probably would've been an incredibly nice feature and losing control over the language was a major fuckup
18:37:52FromDiscord<nervecenter> I've seen him complain that it was design by committee from very early on
18:37:59FromDiscord<nervecenter> and how ti changed into something unrecognizable from his concept
18:38:04FromDiscord<nervecenter> (edit) "ti" => "it"
18:38:20FromDiscord<jos7388> it's necessary
18:39:00FromDiscord<jos7388> the language does infer lifetimes already
18:39:09FromDiscord<jos7388> so like, it does what he's saying
18:39:17FromDiscord<nervecenter> He almost wanted it to compete with Haskell or Java/.NET with a near-native but still abstracted runtime, and a bunch of C++ devs seemed to steal the project from him and turn it into a hyper low-level project
18:44:43FromDiscord<ieltan> sent a code paste, see https://paste.rs/VgiHX
18:45:52FromDiscord<TheUnderName> I prefer Nim to Rust :):nim1:
18:46:30FromDiscord<TheUnderName> (edit) ":):nim1:" => "🙂 :nim1:"
18:46:50FromDiscord<jos7388> In reply to @ieltan "I think he really": so basically like inout parameters or something
18:46:53FromDiscord<jos7388> u can't store them in structs
18:46:57FromDiscord<jos7388> its a temp borrow that can't outlive the function
18:47:07FromDiscord<jos7388> or just refs in C++
18:48:14FromDiscord<Phil> Yeah you guys are way deeper in that than I am, I'm barely following
18:48:29FromDiscord<Phil> (edit) "following" => "following... like 30% of that"
18:48:36FromDiscord<ieltan> Well, I'm not in his head but when Nim stabilize view types you should be able to have `lent` part of an object type
18:49:54FromDiscord<ieltan> In reply to @jos7388 "its a temp borrow": Yeah :p
18:50:12FromDiscord<jos7388> whats a view type in nim
18:50:35FromDiscord<Phil> Sounds like the concept orients itself on relational database views
18:51:04FromDiscord<ieltan> https://nim-lang.org/docs/manual_experimental.html#view-types
18:51:56FromDiscord<ieltan> dont use it, it's broken
18:52:02FromDiscord<ieltan> but that's basically the idea
18:53:13FromDiscord<jos7388> i haven't used lent yet, but putting them in structs sounds a lot like borrows in rust no
18:53:14FromDiscord<jos7388> (edit) "no" => "no?"
18:53:23FromDiscord<jos7388> i guess they only have a simple lexical lifetime though, right
18:54:40FromDiscord<ieltan> Yup, but the point I am making is that implicit lifetimes are already there in Nim anyways, just annotate `sink` and `lent` in your procs where it make sense
18:55:33FromDiscord<jos7388> ye i agree
18:55:37FromDiscord<jos7388> i like how in nim it's an optimization though
18:55:42FromDiscord<jos7388> i think rust got it backwards
18:56:05FromDiscord<jos7388> in nim you start with ORC, and then you can optimize it away with other patterns
18:56:12FromDiscord<jos7388> in rust u start with the hardest shit
18:56:20FromDiscord<jos7388> not to mention least flexible
18:56:33FromDiscord<jos7388> it's literally premature optimization imo
18:57:54FromDiscord<Phil> Same conclusion I came to, I just formulate it as nim being very strongly based around opt in for various features
18:58:33FromDiscord<Phil> Like you can use macros, you don't have to.↵You can optimize memory moves/copies etc., you don't have to.↵You can give a hoot about circular data structures, or you stick with ORC and you don't have to
18:58:58FromDiscord<jos7388> yup
18:59:08FromDiscord<jos7388> the one thing i will say is that rust's approach is really good when u apply it at scale
18:59:15FromDiscord<jos7388> like, sure, it's annoying to write certain kinds of programs in rust
18:59:25FromDiscord<jos7388> but when i pick up a rust binary, i know it's going to be a certain way
18:59:35FromDiscord<jos7388> low memory usage, not a lot of memory moving around at all
18:59:48FromDiscord<jos7388> i think it's nice a language like that exists
19:00:02FromDiscord<jos7388> i am just surprised it's so popular? and people are trying to use it for problems that are very hard to solve in that way?
19:02:04FromDiscord<Phil> You'd know more about that than I do, I'm barely wrapping my head around when I see rust stuff as it is
19:02:30FromDiscord<jos7388> i've written a ton of rust, i was very pro-rust for gamedev for a while
19:02:39FromDiscord<jos7388> i had my own 3d engine and a bunch of other stuff
19:02:48FromDiscord<jos7388> but i really value hot reloading, dynamic linking-- things like that
19:02:59FromDiscord<jos7388> rust is very very bad at those things, so i dropped it
19:03:07FromDiscord<jos7388> so now im trying nim.. again
19:03:21FromDiscord<jos7388> my biggest problem with nim was that it wasn't "production ready", was getting tons of internal compiler issues, stuff like that
19:03:24FromDiscord<jos7388> but it's improved so much since then
19:05:13FromDiscord<Phil> I recall the nim survey back when I started and it was focussing on stability and the like, seems like that happened (?)↵There are some limitations I run into, but those are more for new features.↵Stuff like default types for DateTime distinct aliases not working well
19:05:25FromDiscord<Phil> At least that was an issue a couple months back, haven't checked since
19:05:57FromDiscord<Phil> (edit) "types" => "values" | "valuesfor ... DateTimealias" added "fields with" | "aliases" => "alias types"
19:07:32FromDiscord<jos7388> nim has insanely cool features, but kind of sucks at the basics
19:07:39FromDiscord<Festive> How can I take a screenshot in nim?
19:07:45FromDiscord<odexine> In reply to @jos7388 "i am just surprised": Marketing
19:07:51FromDiscord<jos7388> ur right about that.. rust marketing is insane
19:07:53FromDiscord<odexine> Nim doesn’t have that good marketing
19:08:47FromDiscord<Festive> https://github.com/Senketsu/nsu nvm
19:10:52FromDiscord<ieltan> I think it's a strange and ironic world. People don't question why Rust's "exist", you will be told something like:↵"well, considering that PLs exist to solve a niche, Rust can do memory management without GC, that's a big deal for embedded!"↵But then, you see Rust being used in web application where that feature becomes a weakness, or how Rust relies on LLVM, a poor target for embedded hence the irony.
19:11:48FromDiscord<ieltan> But it's true that I like Rust when I don't have to use it, I think it's an especially great language to make tooling in.
19:12:23FromDiscord<jos7388> so true
19:12:35FromDiscord<jos7388> rust is the best shell scripting language of all time
19:12:37FromDiscord<odexine> Unfortunately for me I consider syntax as critical or as significant dealbreakers so rust is pretty much out as something I’d use
19:12:44FromDiscord<jos7388> i actually really like rust syntax
19:12:49FromDiscord<jos7388> but i guess if u grew up on python and friends u would hate it
19:12:59FromDiscord<jos7388> syntax is holding nim back from wider adoption IMO
19:13:13FromDiscord<jos7388> at least from the intended target audience-- people who like nim-like languages probably want c-like syntax
19:13:31FromDiscord<odexine> If ever that happens consider me gone
19:13:38FromDiscord<odexine> The reason I like Nim is because it is not c like
19:13:54FromDiscord<ieltan> Nim has an hard time because it tries to be "the language to rule them all", I think it does that great which is an exploit. But people want to solve their niche and Nim does have enough material covering how it solve those "niches" (because it's not incapable in the least)
19:14:08FromDiscord<ieltan> (edit) "does" => "doesnt"
19:14:25FromDiscord<odexine> Honestly I don’t think languages should change syntax just for popularity sake
19:14:50FromDiscord<odexine> Or not change necessarily, even when picking it shouldn’t
19:15:12FromDiscord<odexine> please note that I might be incoherent because I’m pretty sleep deprived right now sorry
19:15:20FromDiscord<jos7388> i remember reading a post from the nim author who was like "there will be syntax views on nim, so you can just like use any syntax you want"
19:15:24FromDiscord<Phil> In reply to @jos7388 "at least from the": wow if that's the case I'm super weird
19:15:36FromDiscord<odexine> In reply to @jos7388 "i remember reading a": It used to exist yes
19:15:43FromDiscord<odexine> Removed because of disuse and maintenance cost
19:15:51FromDiscord<jos7388> it sounds kind of interesting..
19:15:58FromDiscord<jos7388> but it does sound insane
19:16:07FromDiscord<odexine> Nim really did have a braces syntax skin
19:16:12FromDiscord<odexine> No one used it though
19:16:16FromDiscord<odexine> Ironic
19:16:22FromDiscord<jos7388> In reply to @isofruit "**wow** if that's the": well its just my opinion, but i think every systems lang has brackets at least
19:16:40FromDiscord<odexine> In reply to @jos7388 "well its just my": Correlation causation thing I bet you that
19:16:52FromDiscord<odexine> Maybe I’m not thinking properly right now
19:16:54FromDiscord<jos7388> well people are like you-- they also throw out languages because of syntax
19:16:59FromDiscord<jos7388> and systems devs use brackets
19:17:15FromDiscord<jos7388> so i would guess, that systems lang devs would avoid nim because it's not what they're used to syntactically
19:17:25FromDiscord<jos7388> tbh when i first saw nim i thought it was a scripting language because of the syntax
19:17:44FromDiscord<jos7388> but i actually love the syntax now
19:17:55FromDiscord<odexine> Okay here maybe this is a coherent and sensible thought
19:17:59FromDiscord<Phil> In reply to @jos7388 "well its just my": TBH I never understood the need for those once I realized that every lang has a linter and that'll lead you to unified indentation for code-blocks anyway
19:18:08FromDiscord<ieltan> In reply to @jos7388 "at least from the": I think defining an audience for Nim is hard because Nim "does it all". I often just think saying that Nim is a statically typed python that's a fast as C is a good start. There is an audience for a faster python, look at all these effort made in their community to have more typing (mypy) and have more speed (Mojo)
19:18:17FromDiscord<odexine> Does Nim have to be that popular as to change syntax for the sake of it
19:18:34FromDiscord<odexine> Nim does benefit from being popular yes
19:18:38FromDiscord<ieltan> It should start somewhere
19:18:43FromDiscord<odexine> But is it worth it to switch
19:18:52FromDiscord<ieltan> Rust definitely did not intend to please web developer at the beginning
19:19:06FromDiscord<ieltan> Programming languages eventually evolve and cover more use-cases
19:19:31FromDiscord<jos7388> i think it's worth personally, for gamedev crowd
19:19:33FromDiscord<Phil> Unless the learning material for webdev has significantly improved or the frameworks have made leaps in the meantime in featureset and how simply they provide it, I'd claim it still doesn't
19:19:36FromDiscord<odexine> Yes but how many languages do you see out there switching their block delimitation
19:19:46FromDiscord<jos7388> it's impossible at this point ye
19:19:46FromDiscord<ieltan> In reply to @odexine "Does Nim have to": Imo it's not worth the risk
19:19:49FromDiscord<jos7388> would have to be a dialect or something
19:20:02FromDiscord<odexine> May as well be a whole different language at that point
19:20:05FromDiscord<jos7388> isn't there a nim fork? that's trying to do that?
19:20:23FromDiscord<odexine> There is but they are not abandoning indentation IIRC
19:20:30FromDiscord<odexine> At least no plans to as of now
19:20:40FromDiscord<odexine> Their plans are only right now to improve the compiler backend
19:20:43FromDiscord<ieltan> I have a wishlist of features for Nim that are probably impossible to realize, doesn't mean I must fork it
19:20:51FromDiscord<ieltan> I just do with what I have :p
19:21:53FromDiscord<ieltan> For example, I kinda wish Nim used result/either types for error handling. I know a lot of ink has been spilled over this and it's basically a matter of taste
19:22:15FromDiscord<jos7388> that's something rust nailed IMO
19:22:32FromDiscord<ieltan> In it's ideal form, Nim would do something like how Swift does
19:22:35FromDiscord<requiresupport> `let port_int = cast[int](port)` any idea why I can't do this when I'm getting the port from command line?↵↵`Error: expression cannot be cast to 'int'`
19:23:21*Phytolizer joined #nim
19:23:28FromDiscord<odexine> In reply to @requiresupport "`let port_int = cast[int](port)`": I don’t think that’s the whole snippet, can you provide the code with no changes, or at least minimal changes
19:24:03FromDiscord<that_dude.> Is `port` a string? I'm assuming so because you said it's from the command line. Check out https://nim-lang.org/docs/parseutils.html#parseInt%2CopenArray%5Bchar%5D%2Cint . It's probably what yo uwant
19:24:07FromDiscord<that_dude.> (edit) "yo uwant" => "you want"
19:24:30FromDiscord<odexine> In reply to @ieltan "For example, I kinda": I think there should be a mechanism where one can switch between exceptions and result types as seamlessly as possible
19:24:39Phytolizeris `disarm` still useful for anything? its docs mention --newruntime which sent me on a wild goose chase just to discover it is deprecated (https://nim-lang.org/docs/system.html#disarm.t%2Ctyped)
19:24:57FromDiscord<odexine> Why restrict one to a choice if both can be accommodated for
19:25:05FromDiscord<odexine> In reply to @Phytolizer "is `disarm` still useful": Unlikely
19:25:27Phytolizerthx for the quick answer, maybe i will stop getting distracted by random stuff in system lol
19:26:29*ntat quit (Quit: leaving)
19:28:46FromDiscord<requiresupport> In reply to @that_dude. "Is `port` a string?": Thanks kind soul, works!
19:31:55FromDiscord<ieltan> In reply to @odexine "I think there should": I don't think it's possible Because the semantics are different, in Nim `raise` unwind the stack and exits the program with an error message, in Swift `throw` actually just return an error value.
19:32:15FromDiscord<ieltan> Hope I got that right
19:33:11FromDiscord<jos7388> like it short-circuits the function when u call throw?
19:33:14FromDiscord<jos7388> to just return the error variant
19:33:23FromDiscord<jos7388> does the function have to return a Result<T> type?
19:33:25FromDiscord<ieltan> It returns the error variant
19:33:28FromDiscord<ieltan> No
19:33:32FromDiscord<jos7388> hmm interesting
19:33:38FromDiscord<jos7388> so does it like
19:33:53FromDiscord<jos7388> that sounds cool..
19:35:07FromDiscord<ieltan> Ye it's like exceptions but... it's not
19:36:10FromDiscord<ieltan> You have a `try!` keyword that allow you to mimic unchecked exceptions
19:37:18FromDiscord<ieltan> So if a function returns a error value it will crash
19:37:54FromDiscord<ieltan> There's no stack unwinding
19:38:42FromDiscord<jos7388> it does look pretty cool, i looked it up
19:38:48FromDiscord<jos7388> looks a lot easier to work with than rust's approach
19:38:57FromDiscord<Elegantbeef> You can convert between results and exceptions "seemlessly" it's just not free
19:39:33FromDiscord<ieltan> The biggest win in Swift error handling is that you don't have to wrap your type in a `Result<T>` imo
19:39:57FromDiscord<ieltan> So it doesn't pollute the type of the actual return value that you care about
19:40:43FromDiscord<ieltan> And if you don't care about errors (because you know it won't throw or you're writing one-offs) , you use `try!`
19:40:47FromDiscord<ieltan> It just make so much sense
19:40:55FromDiscord<ieltan> I WANT IT IN NIM
19:40:59FromDiscord<ieltan> 😢
19:42:25FromDiscord<ieltan> I don't know how the `throws` thingy would look like in Nim syntax though
19:43:16Phytolizerlike an annotation or what is that in swift?
19:43:28Phytolizernim has the {.raises: [IOError, ...].} pragma
19:44:08FromDiscord<Elegantbeef> It'd look the same
19:44:23FromDiscord<Elegantbeef> You can write macros to get swift style errors
19:44:40FromDiscord<ieltan> It simply means "this function can throw"
19:44:46FromDiscord<ieltan> Without it, it cannot
19:44:51FromDiscord<ieltan> Simple
19:45:08FromDiscord<Elegantbeef> `proc doThing: int {.throw.}` boom we did it
19:45:17FromDiscord<Elegantbeef> any procedure marked `throw` gets an injected `throw` template
19:46:48FromDiscord<Elegantbeef> How does swift even make an error type or is it a fully runtime polymorphic type?
19:46:52FromDiscord<ieltan> I'll try to make something like that when I get good at macros
19:47:36FromDiscord<Phil> Is there a way to check if 2 symbols count as equal in nim's sense of the word (so `is_potato` and `isPotato` count as equal) ?
19:48:06FromDiscord<Elegantbeef> `eqIdent`
19:48:49FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=4DbN
19:49:23FromDiscord<Phil> so instead of sourceName == targetName which I think is only true for "isPotato" == "isPotato"
19:49:35FromDiscord<Phil> One sec, checking the proc
19:50:50FromDiscord<Phil> Sweet, that does work!
19:54:25FromDiscord<Phil> In reply to @Elegantbeef "`eqIdent`": mapster comes out, same day I'm already 2 patch versions deep
20:17:15FromDiscord<Elegantbeef> But are you using graffiti @Phil ? 😄
20:18:27FromDiscord<Phil> I'm too tired to actually get that reference
20:18:38FromDiscord<Elegantbeef> https://github.com/beef331/graffiti
20:18:41FromDiscord<Elegantbeef> My git tagger
20:19:59FromDiscord<Phil> Ah so basically instead of doing a version bump commit and then doing git tag vX.X.X and git push --tags, I do a version bump commit and grafiti <path-to-nimble> and git push --tags?
20:20:41FromDiscord<Elegantbeef> You don't even need to push tags
20:20:59FromDiscord<Phil> Can it do the version bump commit for me by me specifying minor/major/patch?
20:21:03FromDiscord<Elegantbeef> It does it all, it even tags if you didnt create tags for a specific nimble version tick
20:21:20FromDiscord<Elegantbeef> Nah, that's one thing I wanted to add though
20:21:28FromDiscord<Phil> That would be siiiiiick
20:22:12FromDiscord<Elegantbeef> Thos where I jokingly say "it's like 50 loc, PRs welcome" 😄
20:22:14FromDiscord<Elegantbeef> this even
20:23:48FromDiscord<Phil> If that can be done in 50 loc I'll be impressed
20:24:05FromDiscord<Phil> That includes arg parsing as well as writing to a nimble file
20:24:36FromDiscord<Elegantbeef> I mean it's a single earg
20:24:38FromDiscord<Elegantbeef> arg\
20:25:03FromDiscord<Elegantbeef> I already go over all the git history and create tags for each commit inside a nimble file
20:28:43FromDiscord<Phil> That is a fascinating prospect.↵I shall contemplate that as I drift into snoozin time
20:32:22*nmz joined #nim
20:44:26FromDiscord<jordan4ibanez> I'm feeling very.... Enterprise®
20:44:33FromDiscord<jordan4ibanez> Is there a spell check for nim comments?
20:46:16FromDiscord<jordan4ibanez> In naylib is ``Rectangle()`` putting the rectangle on the heap?
20:46:39FromDiscord<jordan4ibanez> I just have so many questions today for no reason
20:47:12FromDiscord<jos7388> will nim ever get support for cyclic imports?
20:47:22FromDiscord<jos7388> i feel like it makes some of the metaprogramming impossible
20:47:28FromDiscord<jos7388> from a compiler design perspective
20:47:51FromDiscord<Elegantbeef> It's intended to be in 2.x
20:47:57FromDiscord<jos7388> like u can't just do a pre-pass and collect all the types, because those types could be generated using comptime code?? idk
20:47:57FromDiscord<Elegantbeef> Unlikely jordan
20:48:07FromDiscord<jordan4ibanez> I don't mean to brag, but, I just drew a rectangle
20:48:12Phytolizer:O
20:48:29FromDiscord<jordan4ibanez> In reply to @Elegantbeef "Unlikely jordan": How do we do this, I tried creating a new rectangle but it says "nah"
20:48:41FromDiscord<Elegantbeef> What?
20:48:54FromDiscord<jordan4ibanez> I want to dump my garbage onto the heap
20:49:20FromDiscord<jordan4ibanez> sent a code paste, see https://play.nim-lang.org/#ix=4DbZ
20:50:39FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4Dc0
20:50:59FromDiscord<jordan4ibanez> Ohhh, so I have to create a wrapper type perhaps? Hmm
20:51:03Phytolizeryou can
20:51:20FromDiscord<TheUnderName> <a:emoji_3:1137632478807474226>
20:51:23Phytolizere.g. `type RectangleRef = ref Rectangle` and then when you use RectangleRef it will allocate
20:51:44Phytolizeror just `let x = (ref Rectangle)(x: ...)`
20:53:18FromDiscord<Elegantbeef> Yea I was being daft
20:53:29FromDiscord<Elegantbeef> Was thinking about Nim primitives
20:54:28FromDiscord<jordan4ibanez> Oh oh oh I think we can also use that auto translation converter feature!!
20:54:38FromDiscord<TheUnderName> Bot to Bot:trollface:
20:54:50Phytolizeron different platforms no less :)
20:55:04FromDiscord<Elegantbeef> Matric
20:55:18FromDiscord<Elegantbeef> matirc whoops
20:55:20FromDiscord<jordan4ibanez> O my god it works
20:55:25FromDiscord<Elegantbeef> My urge for correctness ruined that
20:55:31Phytolizerlol
20:55:40FromDiscord<TheUnderName> :thinkinghard:
20:56:03FromDiscord<jordan4ibanez> sent a code paste, see https://play.nim-lang.org/#ix=4Dc1
20:56:13FromDiscord<jordan4ibanez> That's amazing
20:56:56FromDiscord<jordan4ibanez> I don't even understand how it's automatically able to infer and deduce and then insert all this metacode but that's downright impressive
20:57:28FromDiscord<Elegantbeef> No you do not cast
20:57:31Phytolizerive not seen converters, i guess that is like c++ operator OtherType()
20:57:35FromDiscord<Elegantbeef> Can we just remove cast
20:57:56Phytolizeryeah casting doesn't seem like the right option there
20:57:59FromDiscord<jordan4ibanez> How do I turn it into a Rectangle without a cast?
20:58:09Phytolizerpostfix [] will dereference
20:58:14FromDiscord<jordan4ibanez> Noice
20:58:16FromDiscord<Elegantbeef> `myRef[]` to dereference
20:58:26FromDiscord<Elegantbeef> Never use cast unless you know what you're doing
20:58:31FromDiscord<Elegantbeef> And I can assure you, you do not know what you're doing
20:59:01Phytolizercan't remember the last time i used cast myself
20:59:23FromDiscord<jordan4ibanez> Now how do I convert the Rectangle into RectangleRef?
20:59:31Phytolizerhttps://play.nim-lang.org/#ix=4Dc2
20:59:36FromDiscord<Elegantbeef> You need to allocate
20:59:59Phytolizeri removed imports and stuff so itd work on the playground
21:00:42FromDiscord<jordan4ibanez> sent a code paste, see https://play.nim-lang.org/#ix=4Dc4
21:00:58Phytolizeryeah that works too
21:01:16FromDiscord<Elegantbeef> that works or what phyto shared
21:03:13FromDiscord<jordan4ibanez> sent a code paste, see https://play.nim-lang.org/#ix=4Dc6
21:04:29Phytolizercast is probably okay there because it is the exact same type with a different name
21:04:36FromDiscord<Elegantbeef> You must not
21:04:51FromDiscord<Elegantbeef> It's probably fine but there is very little reason
21:05:05FromDiscord<Elegantbeef> `Vector2f(x: x.x, y: y.y)` is simple as
21:05:54Phytolizerwould love for cast to be renamed as bitCast or something that makes more clear how dangerous it is
21:06:17FromDiscord<jordan4ibanez> Mhmmm
21:06:21FromDiscord<Elegantbeef> I'd prefer `neverUseThisUnlessYouKnowWhatYou'reDoing`
21:06:35FromDiscord<Elegantbeef> The amount of times people use cast instead of type conversion is too damn high
21:06:36Phytolizeroh haskell has one of those lol
21:06:44PhytolizeraccursedUnutterablePerformIO
21:07:33FromDiscord<toma400> In reply to @Elegantbeef "It's intended to be": Dang, that sounds sick! Will required predefinition of procedures get resolved in the same time? So we can use arbitrary order of procedure declaration?
21:07:49FromDiscord<Elegantbeef> Obviously that'd be a requirement
21:07:54Phytolizeri believe there's already an experimental version of proc order independence
21:08:05FromDiscord<toma400> Heck, that makes me so happy ❤️
21:08:33Phytolizeractually my only contribution so far to the nim compiler was fixing some tooling around the reorder feature lol
21:08:48FromDiscord<Elegantbeef> That code reordering is really lazy
21:08:58FromDiscord<Elegantbeef> Forward declaration is just too easy to use that feature imo
21:09:03FromDiscord<Elegantbeef> It's more clear aswell
21:09:19Phytolizeryeah i only discovered it because i think nimterop translated a c header and injected that pragma
21:12:41FromDiscord<jordan4ibanez> sent a code paste, see https://play.nim-lang.org/#ix=4Dc7
21:13:28Phytolizerit's certainly less likely to result in problems
21:13:33Phytolizer`result =` is redundant here btw
21:13:50FromDiscord<Elegantbeef> `cast` is saying "Compiler I know best"
21:14:05FromDiscord<Elegantbeef> You rarely know best so avoid it unless you actually do
21:15:04FromDiscord<jordan4ibanez> https://tenor.com/view/adventure-time-jake-finn-time-to-learn-learn-gif-4458347
21:18:36FromDiscord<Elegantbeef> PS if that sounds like 'superiority' it's not. I also avoid `cast` 😄
21:19:39FromDiscord<jordan4ibanez> No, no, don't worry, I'm not at all offended or feeling down etc. This happens with learning every lang, I'm just very appreciative that you guys are basically like "HOLD ON THERE PARTNER" because this could have gone very badly
21:21:13FromDiscord<jordan4ibanez> I think these heap elements could be easily bolted into naylib, but the only problem is if raylib goes crazy and then there's a Z component for a rectangle for no reason
21:23:59Phytolizeri certainly used cast in very questionable ways when i was starting out with nim :P
21:26:15FromDiscord<jordan4ibanez> Exactly! I've been programming in java for the last few months so all this little detail when it gets transpiled into C is very important
21:27:26FromDiscord<jordan4ibanez> Unfortunately when I go back into java I already know I'm going to be like "why do I have to write all this?"
21:33:21FromDiscord<Elegantbeef> @.elcritch\: we're cooking with gas now
21:33:23FromDiscord<Elegantbeef> simplescreenrecorder-2023-08-11\_15.31.55.mp4 https://media.discordapp.net/attachments/371759389889003532/1139672940326162602/simplescreenrecorder-2023-08-11_15.31.55.mp4
21:33:46FromDiscord<Elegantbeef> Using nimcall procs across the VM bridge, it's actually pretty sensible
21:34:07FromDiscord<Elegantbeef> And cause I'm using a real `.nim` file for `nicoscript` nimlsp works
21:39:48*advesperacit quit ()
21:40:12FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#ix=4Dcb
21:40:34FromDiscord<Elegantbeef> `tuple[palette: Pallete, data: seq[byte], ble, meh: int]`
21:41:16FromDiscord<System64 ~ Flandre Scarlet> Oh, it's array notation, thanks!
21:41:24FromDiscord<Elegantbeef> It's not array notation 😄
21:41:41FromDiscord<System64 ~ Flandre Scarlet> well I meant↵Between [] like arrays
21:47:38FromDiscord<Elegantbeef> Damn this is even more cool
21:47:41FromDiscord<Elegantbeef> simplescreenrecorder-2023-08-11\_15.46.02.mp4 https://media.discordapp.net/attachments/371759389889003532/1139676536887320676/simplescreenrecorder-2023-08-11_15.46.02.mp4
21:47:48FromDiscord<Elegantbeef> First instance is nimscript, the second instance is a compiled version
21:50:44FromDiscord<jos7388> nice!
21:50:49FromDiscord<jos7388> did you ever get that wasm thing working?
21:51:12FromDiscord<jos7388> after looking into my own wasm stuff i think it's not a good idea
21:51:25FromDiscord<jos7388> mostly because i want hot reload
21:51:29FromDiscord<jos7388> is nimscript good enough?
21:51:30FromDiscord<Elegantbeef> I mean yea I got wasm working
21:51:50FromDiscord<Elegantbeef> Who knows if it's good enough
21:51:59FromDiscord<Elegantbeef> Wasm based plugins gives you HCR
21:52:05FromDiscord<Elegantbeef> Just use nlvm to do it
21:52:35FromDiscord<jos7388> i want to retain state though, and stuff like struct layouts changing, etc seems really problematic with wasm
21:52:54FromDiscord<Elegantbeef> It's the same thing with using system libraries
21:53:02FromDiscord<Elegantbeef> It's an implicit issue with HCR
21:53:03FromDiscord<jos7388> wdym
21:53:11FromDiscord<Elegantbeef> You cannot change the data you can only change the logic
21:53:17FromDiscord<Elegantbeef> Changing the data in anyway can corrupt state
21:53:20FromDiscord<jos7388> ye
21:53:25FromDiscord<jos7388> but with a scripting lang it's not so much an issue
21:53:34FromDiscord<jos7388> since you aren't invalidating struct layouts and stuff
21:53:39FromDiscord<jos7388> so i figure nimscript might be a better target
21:53:40FromDiscord<Elegantbeef> Right, but that's not HCR that's scripting
21:54:02FromDiscord<jos7388> if HCR means hot code reload, i don't see why it wouldn't apply to scripting too
21:54:17FromDiscord<jos7388> you know what i mean?
21:54:27FromDiscord<jos7388> i'm actually working on a scripting lang now that i plan on adding really robust HCR support to
21:54:41FromDiscord<jos7388> as like the main feature
21:57:21FromDiscord<Elegantbeef> Yea the way I'm doing Nimscripts save state is quite questionable
21:57:53FromDiscord<Elegantbeef> Changing global state is generally going to be a challenge unless you use a table based data type like lua
22:02:35FromDiscord<jmgomez> In NUE you can update the global state via NimScript or DLLs, it doesnt care. It just works 😛
22:03:45FromDiscord<Elegantbeef> Right but the global state is not just a struct it's likely a pointer to a RTTI type no?
22:03:58FromDiscord<System64 ~ Flandre Scarlet> https://github.com/jangko/nimBMP↵Oh, it also supports BMP!
22:04:17FromDiscord<jordan4ibanez> sent a code paste, see https://play.nim-lang.org/#ix=4Dcj
22:04:24FromDiscord<Elegantbeef> Yes
22:04:29FromDiscord<jordan4ibanez> I'm relearning thank goodness
22:04:32FromDiscord<Elegantbeef> Why would you want a heap based vector2 though
22:04:34FromDiscord<jordan4ibanez> Thank ya
22:04:46FromDiscord<jordan4ibanez> Long term storage, I've run into stack overflows before with my crazy projects
22:05:07FromDiscord<Elegantbeef> Well maybe rewrite your code to not have recursive allocations
22:05:27FromDiscord<jordan4ibanez> Not recursive, tens of thousands of entities
22:05:41FromDiscord<Elegantbeef> How does stack relate then
22:05:43FromDiscord<Elegantbeef> Make a `seq[T]` and there you go
22:05:45FromDiscord<jmgomez> In reply to @Elegantbeef "Right but the global": Yeah, well Im cheating because Im leveraging on the infra that Unreal already has. Although I have to say that Nim feels better integrated that C++ in what has to do with HR. C++ HR crashes a lot
22:05:59FromDiscord<Elegantbeef> Why would you make your vectors likely the most allocated type a reference
22:06:07FromDiscord<Elegantbeef> This is why Minecraft runs at .2fps
22:06:31FromDiscord<jordan4ibanez> If I put the stack based Vector into a ref object, does that ref object's position point to the stack? Or is it a component of the ref object on the heap?
22:06:48FromDiscord<Elegantbeef> the vector is heap allocated
22:06:54FromDiscord<jordan4ibanez> NOICE
22:06:56FromDiscord<Elegantbeef> Types are not ever concretely stack or heap allocated
22:07:11FromDiscord<Elegantbeef> A reference that contains a value object makes that value object allocated on the heap
22:07:25FromDiscord<Elegantbeef> It's just contiguous in the block of allocated memory
22:07:33FromDiscord<jordan4ibanez> I had this problem in D so I wanted to double check
22:08:03FromDiscord<Elegantbeef> Well that just means you do not understand heap allocations
22:08:11FromDiscord<Elegantbeef> Even in C# a struct inside a class is heap allocated
22:08:39FromDiscord<jordan4ibanez> You'd think that, but it happened
22:08:43FromDiscord<Elegantbeef> When someone says "Is this heap or stack allocated" they generally mean "When used inside of a normal procedure where will the data be"
22:08:54FromDiscord<Elegantbeef> I mean you clearly do not understand heap allocations
22:09:21FromDiscord<Elegantbeef> > If I put the stack based Vector into a ref object, does that ref object's position point to the stack? Or is it a component of the ref object on the heap?↵Is quite clear you do not understand how heap allocated types work
22:09:39FromDiscord<Elegantbeef> It implies all value types are stack allocated and refs must point to them
22:09:53FromDiscord<Elegantbeef> I cannot think of a language where that's true
22:10:41FromDiscord<jordan4ibanez> In D, just like destructors do not work properly in D, I've already went through this when translating JOML (https://github.com/jordan4ibanez/doml) and wanted to ensure the same was not true
22:11:23FromDiscord<jordan4ibanez> Maybe I'm misremembering, it's been a while
22:11:53FromDiscord<Elegantbeef> D is based on C++ and I know in C++ `new T` does not make a struct or classes value fields point to the stack
22:12:12PhytolizerI don't believe that's true in D either
22:12:15FromDiscord<Elegantbeef> They're contiguous allocated to where the pointer points
22:12:29FromDiscord<Elegantbeef> It's clearly not cause it makes no sense
22:13:03FromDiscord<Elegantbeef> There is 0 reason for your heap to point to your stack, it adds pointer indirect, is unsafe, and makes it so you now have an extra word taken up
22:13:13Phytolizera value type can live anywhere, fundamentally speaking. stack or heap
22:13:23FromDiscord<Elegantbeef> Even in static memory 😛
22:13:30Phytolizeryeah
22:13:56FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "This is why Minecraft": Minecraft runs at 2 FPS because Java goofy ahh
22:14:01FromDiscord<Elegantbeef> Well just to highlight how silly that would be, it means any time you heap allocate you could not reverse your stack
22:14:15FromDiscord<Elegantbeef> Which means your stack can only grow
22:16:09*Phytolizer quit (Quit: Client closed)
22:16:59FromDiscord<jordan4ibanez> Oh yeah it's me misremembering! Then I don't even remember which lang that was an issue in? Hmm
22:18:24FromDiscord<jordan4ibanez> How does one make a parameter mutable? If it's not heap allocated, do we have to allocate?
22:18:39FromDiscord<Elegantbeef> `var T`
22:24:11FromDiscord<jordan4ibanez> Thank ya
23:02:54*jmdaemon joined #nim
23:07:34*jmdaemon quit (Ping timeout: 246 seconds)
23:09:18qwrin C++ (and probably D) its fine for pointers to refer into stack. Nim imho generally just doesn't allow making ref out of non-ref value.
23:10:46FromDiscord<Elegantbeef> I mean it's fine in Nim aswell, the thing isnt heap referring to stack as much as forcing all value types on the stack
23:10:46FromDiscord<Elegantbeef> It doesnt make sense to do that
23:12:21qwrnot that it makes sense, but how would you even make ref object out of non-ref object without coping in the nim?
23:12:47FromDiscord<Elegantbeef> The question is wrong
23:13:00FromDiscord<Elegantbeef> you just do `.addr` to get a pointer
23:13:12FromDiscord<Elegantbeef> You cannot make a non ref a ref since a ref is a distinct type of pointer that is automatically managed
23:13:19FromDiscord<Elegantbeef> You need to allocated and move
23:13:51FromDiscord<Elegantbeef> Technically if you use `sink` you can remove copying
23:13:52FromDiscord<demotomohiro> Nim's raw pointer types like `ptr int` can points to stack. C++'s smart pointer like `shared_ptr` or `unique_ptr` can refer only heap as far as I know.
23:15:20qwrok, yes, you still have non-safe pointers also. maybe D also has both, but C has only non-safe ones and in C++ you can build shared_ptr out of classes with constructors/destructors
23:16:14FromDiscord<demotomohiro> You cannot make ref object out of non-ref object without copying in Nim because how stack is managed is different from heap.
23:16:36qwrin nim you normally just won't use the bare pointer unless really needed for interfacing something else (foreign library, hardware etc)
23:16:39FromDiscord<Elegantbeef> Well like I said you can remove any large copying with sink
23:16:53FromDiscord<Elegantbeef> The scary copying happens in `seq[T]` or `string`
23:17:18FromDiscord<Elegantbeef> Yes it still copies arrays and other value types
23:19:34FromDiscord<demotomohiro> Heap memory can be allocated/deallocated at any time but stacks are allocated when a proc is called and deallocatdd when leaving a proc.
23:23:07FromDiscord<Elegantbeef> Anywho view types soon
23:23:18FromDiscord<Elegantbeef> In the year 2034 I guarantee it!
23:25:08FromDiscord<demotomohiro> https://nim-lang.org/docs/manual_experimental.html#view-types
23:25:27FromDiscord<Elegantbeef> Yea, but it's very broken and unusable presently
23:43:10FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://paste.rs/IirTT
23:43:42FromDiscord<Elegantbeef> `bmp.convert[: YourT](bitsPerPixel)` or `convert[T](bmp, bitsPerPixel)`
23:44:07FromDiscord<System64 ~ Flandre Scarlet> Oh alright, thanks