<< 19-09-2021 >>
00:11:49FromDiscord<Yardanico> https://github.com/nim-lang/Nim/issues/18863 fun stuff
00:38:24*vicfred joined #nim
00:56:21*vicfred quit (Quit: Leaving)
01:02:55FromDiscord<@bracketmaster-5a708063d73408ce4> I'm trying to do some basic graph traversal in nim, and `c` is clearly a child of `b`, but nim doesn't think so...
01:02:57FromDiscord<@bracketmaster-5a708063d73408ce4> oops
01:03:00FromDiscord<@bracketmaster-5a708063d73408ce4> https://play.nim-lang.org/#ix=3zil
01:03:02FromDiscord<@bracketmaster-5a708063d73408ce4> there
01:03:07FromDiscord<@bracketmaster-5a708063d73408ce4> sent a long message, see https://paste.rs/3dO
01:03:38FromDiscord<Elegantbeef> you're not using a ref object
01:03:44FromDiscord<Yardanico> `object` is a value
01:04:14FromDiscord<Yardanico> "object"s are passed by-value and not references
01:04:45FromDiscord<Yardanico> maybe https://forum.nim-lang.org/t/8426 can help you understand the differences a bit
01:05:17FromDiscord<@bracketmaster-5a708063d73408ce4> heh - I knew that
01:05:29FromDiscord<@bracketmaster-5a708063d73408ce4> thx
01:08:33nrds<Prestige99> @Elegantbeef I don't suppose you have a written guide on concepts, do you? The experimental features page isn't super clear to me
01:08:48FromDiscord<Elegantbeef> I can write one if need be \:D
01:08:50*arkurious quit (Quit: Leaving)
01:09:16FromDiscord<Elegantbeef> Basically old concepts are just a case of for each statement inside of it it needs to return true to pass
01:09:39nrds<Prestige99> I'm trying to use them like interfaces, saying my type will have a proc foo(f: float)
01:10:14FromDiscord<Elegantbeef> Ok so to reference my concept from last night
01:10:25nrds<Prestige99> or rather type T has proc foo(t: T, f: float)
01:10:34FromDiscord<Yardanico> you can't really use them like interfaces because interfaces can be used at runtime (e.g. you can create seq[MyInterface]) but you can't do that with concepts
01:10:43FromDiscord<Yardanico> but if you only need compile-time matching, then concepts will work
01:10:54FromDiscord<Elegantbeef> `concept f` is the same as a variable `var a: Frameable`
01:10:59nrds<Prestige99> Yeah I think compile time would be fine in my case
01:11:05FromDiscord<Elegantbeef> `type F` is the same as `typeof(a)`
01:11:18FromDiscord<Yardanico> btw, if you specifically need something similar to interfaces, you can use https://github.com/yglukhov/iface
01:11:24FromDiscord<Elegantbeef> i guess `var f: Frameable` is more accurate
01:11:31FromDiscord<Elegantbeef> Yardanico shush for a bit please
01:11:48FromDiscord<Yardanico> sure, but I'm trying to help too :P
01:12:22FromDiscord<Elegantbeef> Flooding with unneeded information presently, he's just trying to understand how the concept was used/expand in my example code from last night
01:13:11nrds<Prestige99> Is there any way to enforce a type to implement a concept at compile time?
01:13:16FromDiscord<Elegantbeef> so prestige it's now just a case of `foo(f, 1.0)`
01:13:25FromDiscord<Elegantbeef> I mean you write a procedure for it
01:13:40FromDiscord<Elegantbeef> You cannot enforce a concept match without it matching procedures you defined as "needed"
01:14:02FromDiscord<Elegantbeef> It doesnt make sense to force a match given you're laying out a case of "What i need for this to work"
01:14:45FromDiscord<Elegantbeef> The nice thing is prestige you can handle most math logic with just a generic
01:15:04nrds<Prestige99> Hmm okay
01:15:22FromDiscord<Elegantbeef> Well give you a modifcation that has a generic lerp
01:16:46nrds<Prestige99> iface looks neat too, think it reads better at least
01:16:58FromDiscord<Elegantbeef> It's also not for the same thing though
01:16:59FromDiscord<Yardanico> well new-style concepts are also like that
01:17:18FromDiscord<Elegantbeef> Yea new style concepts also exist which are just proc definitions
01:17:46FromDiscord<Elegantbeef> `proc foo(t: Self, f: float)` would be what you do in a new style concept
01:17:56FromDiscord<Elegantbeef> But they're also more limited...
01:18:05FromDiscord<QueenFuckingAdrielle> does anyone have a parquet reader for nim?
01:18:33FromDiscord<QueenFuckingAdrielle> I'm not really sure how to begin coding that...
01:18:54FromDiscord<Yardanico> there seems to be a C wrapper, not sure how well it works though
01:18:55FromDiscord<Yardanico> https://github.com/emef/nimarrow_glib
01:19:36FromDiscord<QueenFuckingAdrielle> gotcha, what sort of rabbit hole would it be to implement a reader/writer in pure nim?
01:20:03FromDiscord<Yardanico> it's hard to tell, but it's just like implementing any other protocol
01:20:10FromDiscord<QueenFuckingAdrielle> just for parquet, not the entirety of arrow
01:20:31FromDiscord<Yardanico> doesn't look to be too complex
01:20:43FromDiscord<Elegantbeef> Prestige here is an exampl(relies on vmath) for a generic lerp https://play.nim-lang.org/#ix=3zir
01:21:04FromDiscord<QueenFuckingAdrielle> its a decent format, ive been mainly using msgpack,json,csv
01:21:15nrds<Prestige99> Thanks beef :)
01:21:15FromDiscord<Elegantbeef> Aslong as you can do `+`, `-`, `` the lerp will be usable
01:21:16FromDiscord<QueenFuckingAdrielle> but parquet is becoming standard now
01:21:20FromDiscord<Yardanico> you can probably recreate it pretty well from https://github.com/apache/parquet-format/blob/master/src/main/thrift/parquet.thrift
01:21:24FromDiscord<Yardanico> seems to be pretty readable
01:21:29FromDiscord<Gustavo6046> is a floating-point math operator that is immediately used to store an integer variable replaced by an equivalent integer one?
01:21:36FromDiscord<Gustavo6046> for example, `/` is floating point div but `div` is integer
01:22:12FromDiscord<Yardanico> sorry, didn't quite understand the question :P
01:22:26FromDiscord<Gustavo6046> sent a code paste, see https://play.nim-lang.org/#ix=3zis
01:22:27FromDiscord<Elegantbeef> That seems like an optimization that doesnt make sense to do
01:22:36FromDiscord<Elegantbeef> No it shouldnt since `/` returns float
01:22:44FromDiscord<Yardanico> no, that won't work @Gustavo6046
01:22:50FromDiscord<Gustavo6046> but it's only used to set an integer
01:22:54FromDiscord<Gustavo6046> oh
01:23:03FromDiscord<Gustavo6046> implicit cast can differ from the equivalent integer result?
01:23:05FromDiscord<Elegantbeef> but `/` returns float explictly
01:23:07FromDiscord<Elegantbeef> if you want integer division use `div`
01:23:13FromDiscord<Yardanico> In reply to @Gustavo6046 "implicit cast can differ": there are no implicit casts
01:23:17FromDiscord<QueenFuckingAdrielle> yea thats not the most confusing protocol. Do you think my performance would crap out if i subprocessed supported lang script and piped the data over to nim>
01:23:22FromDiscord<Gustavo6046> then what is mynumber set to?
01:23:23FromDiscord<QueenFuckingAdrielle> (edit) "nim>" => "nim?"
01:23:25FromDiscord<Elegantbeef> There is no provided implict type conversion in nim
01:23:32FromDiscord<Gustavo6046> oh
01:23:33FromDiscord<Yardanico> In reply to @Gustavo6046 "then what is mynumber": that code won't
01:23:33FromDiscord<Gustavo6046> compiler error
01:23:33FromDiscord<Elegantbeef> nothing it errors
01:23:37FromDiscord<Yardanico> exactly
01:23:42FromDiscord<Gustavo6046> I figured
01:23:44FromDiscord<Gustavo6046> if it doesn't cast
01:23:46FromDiscord<Gustavo6046> then that is error
01:23:49FromDiscord<Yardanico> in this case you're using `/` proc that takes two integers and returns a float
01:23:49FromDiscord<Gustavo6046> ooooh
01:23:50FromDiscord<Gustavo6046> that explains a lot
01:23:54FromDiscord<Elegantbeef> `std/leniantops `
01:24:00FromDiscord<Yardanico> std/lenientops
01:24:01FromDiscord<Gustavo6046> \:) thanks!
01:24:22FromDiscord<Elegantbeef> Yardanico taking over for rika on being my spell check
01:24:33FromDiscord<Elegantbeef> Hopefully you werent to offended by me telling you to shush \:D
01:24:33FromDiscord<Yardanico> In reply to @QueenFuckingAdrielle "yea thats not the": if there's a python module you can use https://github.com/yglukhov/nimpy which might be faster than doing subprocessing
01:24:49FromDiscord<Yardanico> nah, it's fine :)
01:25:22FromDiscord<QueenFuckingAdrielle> ah okay, thats a good point, I haven't touched nimpy yet. I'll look at that. thnx!
01:26:42*neurocyte013 joined #nim
01:26:42*neurocyte013 quit (Changing host)
01:26:42*neurocyte013 joined #nim
01:29:05*neurocyte01 quit (Ping timeout: 268 seconds)
01:29:05*neurocyte013 is now known as neurocyte01
01:29:12FromDiscord<Elegantbeef> Hopefully that's an ok api prestige i imagine you'd want to manually handle enums and any other values such as strings or objects
01:29:51FromDiscord<Elegantbeef> Cause for enums you'd probably only want to change to the b value in the lerp when the time is \>= 1
01:48:52FromDiscord<QueenFuckingAdrielle> how is the health of the nim community going? been a bit outta touch
01:49:15FromDiscord<Yardanico> "health" as in what?
01:49:35FromDiscord<Yardanico> there haven't been any major events in the nim community lately, everything's going as usual
01:50:10FromDiscord<Elegantbeef> So there are 10 people surrounding a barrel fire
01:54:15FromDiscord<QueenFuckingAdrielle> gotcha, nim is still my favorite language lol just wondernig
01:54:54FromDiscord<QueenFuckingAdrielle> I'm frustrated with the direction of a lot of languages
02:18:16FromDiscord<Anuke> Is it possible to have a template/macro that accepts optional parameters, but with a mandatory untyped block at the end? https://play.nim-lang.org/#ix=3ziG
02:20:47FromDiscord<@bracketmaster-5a708063d73408ce4> ok - why on earth is append sting in nim `&` and not `+`
02:21:46FromDiscord<leorize> because `+` is for math \:p
02:22:52FromDiscord<amadan> In reply to @Anuke "Is it possible to": it works in devel for me↵This PR added the feature https://github.com/nim-lang/Nim/pull/18631
02:23:32FromDiscord<Anuke> nice, I recalled seeing that PR earlier but couldn't find it
02:25:50FromDiscord<Anuke> I'd rather not switch to devel if at all possible (not easy to use on CI), is there some sort of workaround available?
02:27:42FromDiscord<Elegantbeef> Simples it s https://play.nim-lang.org/#ix=3ziM
02:31:03FromDiscord<Elegantbeef> The silence means "anuke didnt like that" 😛
02:32:54FromDiscord<pietroppeter> In reply to @@bracketmaster-5a708063d73408ce4 "ok - why on": One good reason is that + usually denotes a commutative operation and append is not commutative: “a” & “b” != “b” & “a”
02:35:07FromDiscord<Elegantbeef> One could also argue it shows allocations 😛
03:21:49FromDiscord<jakefromstatefarm> Nim is so cool, the fact that it compiles to basically every system is really useful and super neat.
03:35:58FromDiscord<Rika> + can mean non-commutative addition depending on mathematical context
03:36:04FromDiscord<Rika> Still it’s used for math
03:58:56FromDiscord<amadan> In reply to @Anuke "I'd rather not switch": Workaround I've used before is to take in `varargs[untyped` as the only parameter then parse the other parameters from that
03:59:05FromDiscord<amadan> (edit) "`varargs[untyped`" => "`varargs[untyped]`"
03:59:44FromDiscord<amadan> not the cleanest of methods (and someone probably knows a better way) but gets the job done
04:06:01*supakeen quit (Quit: WeeChat 3.2.1)
04:06:31*supakeen joined #nim
04:36:33FromDiscord<pietroppeter> sent a long message, see http://ix.io/3zja
04:51:35nisstyreFor some reason trying to access a slice of a sequence like xs[1..^1] causes my programs to crash with a call depth limit reached error...
04:51:40nisstyreeven though I'm not doing any recursion
04:52:37FromDiscord<Elegantbeef> Code example?
04:53:01nisstyreI think it might be because it's a custom type
04:53:07nisstyreand I defined the $ function
04:53:13nisstyrebut not sure
04:53:34nisstyreI don't have a minimal example that's runnable
04:54:04FromDiscord<Elegantbeef> are you echoing a slice of a cyclical reference type?
04:54:52nisstyrelet me try and make it run outside of this
04:54:54nisstyreit is a ref object
04:55:01nisstyrebut it happens even without echo
04:55:20FromDiscord<Elegantbeef> It being a ref doesnt matter as much as being cyclical
04:56:26nisstyrethis crashes https://play.nim-lang.org/#ix=3zjc
04:56:53nisstyreoh is it the "discard"
04:56:55nisstyremy bad
04:57:12nisstyreI bet that's it
04:57:22FromDiscord<Elegantbeef> What discard?
04:57:27FromDiscord<Elegantbeef> The ones in the typedef?
04:57:28nisstyrein the type
04:57:30nisstyreyeah
04:57:36nisstyrecould that be causing it?
04:57:42FromDiscord<Elegantbeef> No
04:57:50nisstyreany ideas?
04:57:52FromDiscord<Elegantbeef> It's recursively calling `$`
04:58:02nisstyreok so what I thought then
04:58:13FromDiscord<Elegantbeef> You're recursively calling `$fracProgram`
04:58:20nisstyrethat makes sense
04:58:22nisstyreah
04:58:28FromDiscord<Elegantbeef> Remove that proc it works
04:58:30nisstyreyep
04:58:37FromDiscord<Elegantbeef> sequences have a `$` operator built in 😀
04:58:56nisstyreyeah I don't know why I defined that originally
04:59:09FromDiscord<Elegantbeef> you can also call the specific system one by doing `system.`$`(yourSeq)`
04:59:32FromDiscord<Elegantbeef> But yea no point redeclaring it since it's a type alias and not a distinct
05:06:03*pch quit (Read error: Connection reset by peer)
05:06:21*pch joined #nim
05:15:18*max22- joined #nim
06:24:17FromDiscord<cabboose> Hey y'all check out our package
06:24:23FromDiscord<cabboose> https://github.com/shayanhabibi/loony
06:24:47FromDiscord<cabboose> Good luck with it; don't burn your CPUs
06:30:35FromDiscord<Rika> Does CPS async work under ARC?
06:31:36FromDiscord<cabboose> CPS is lower level than async/await; but this queue does work under ARC
06:31:42FromDiscord<cabboose> Works with any ref object
06:32:23FromDiscord<cabboose> Really this queue means theres no limitations with sync/async operations on multi threaded code
06:32:46FromDiscord<cabboose> Disruptek ran 500 million continuations over 24,000 queues successfully
06:32:59FromDiscord<Rika> I know it is
06:33:40FromDiscord<Rika> I ask because such package does not work under ORC and regular async has cyclic objects
06:33:57FromDiscord<Rika> Which is why I ask if async using CPS works without ORC
06:34:17FromDiscord<cabboose> oh nah cps and async gel well together
06:34:18FromDiscord<cabboose> under orc/arc
06:34:29FromDiscord<cabboose> but that queue does not work with any ref object under ORC for some reason
06:34:56FromDiscord<cabboose> for whatever reason the last `=destroy` we would call on an object would just cause a crash
06:35:06FromDiscord<cabboose> whether it was a string or continuation
06:35:22FromDiscord<cabboose> ORC is strange 🤷🏽‍♂️
06:36:04FromDiscord<Rika> I know they gel well together but does async still generate cyclic objects using CPS
06:36:58FromDiscord<cabboose> if it does in the std lib it will with cps
06:39:34NimEventerNew question by SlightlyKosumi: How to instantiate an app with ProcessStartInfo in this winim library, see https://stackoverflow.com/questions/69240927/how-to-instantiate-an-app-with-processstartinfo-in-this-winim-library
07:55:34FromDiscord<dain> at 41:43 in this video: https://youtu.be/QM1iUe6IofM?t=2503↵he proposes a language construct that works like a new scope, but you have to explicitly pass in all of the names you want to be visible. inside the block it doesn't see anything else from the enclosing scope. is it possible to implement this in nim as a macro?
07:59:33FromDiscord<dain> i was thinking something that would walk the AST and replace every name with a gen-symmed version of it except for the ones that get passed in. but maybe there's a cleaner way? also is there a way to distinguish between names that are available at top level vs inner levels? it would suck to have to pass in all of the imported functions you wanted to use as well
07:59:49FromDiscord<dain> (edit) "it" => "itself"
07:59:50FromDiscord<Elegantbeef> That's way to fucking mess
08:02:21FromDiscord<Elegantbeef> https://play.nim-lang.org/#ix=3zjL
08:02:22FromDiscord<Elegantbeef> Here we go did it
08:03:29FromDiscord<Elegantbeef> If you want to ensure you dont use other symbols you can iterate over the entire scope checking if the symbol comes from a var stmt and not equal to the passed symbols
08:03:37FromDiscord<Elegantbeef> Can show that aswell
08:06:08FromDiscord<dain> yeah thats the idea
08:07:40FromDiscord<dain> how do you inspect the current scope?
08:08:02FromDiscord<Elegantbeef> I mean you dont need to you iterate the body
08:08:13FromDiscord<dain> oh
08:08:40FromDiscord<Elegantbeef> Commas i should use
08:08:57FromDiscord<dain> is it possible to check whether a symbol comes from the module level scope?
08:08:57FromDiscord<Elegantbeef> You dont need to inspect the current scope, you just iterate the body looking for any symbol that is a var that wasnt passed in
08:09:10FromDiscord<Elegantbeef> ehhhh maybe?
08:09:20FromDiscord<Elegantbeef> Probably not
08:19:43FromDiscord<Elegantbeef> It's atleast a start https://play.nim-lang.org/#ix=3zjM
08:24:05FromDiscord<Elegantbeef> Ooh can actually solve that case of "does this sym come from inside here" 😀
08:33:01FromDiscord<Elegantbeef> Getting even fancier https://play.nim-lang.org/#ix=3zjR
08:34:41FromDiscord<Elegantbeef> @dain\: i now leave it to you to continue my legacy! 😛
08:37:36FromDiscord<saem> For the most part you can use the owner and walk up the AST in a loop until you hit an sk module, just check for nil and repeats. The latter meaning generic instantiation
08:38:01FromDiscord<dain> In reply to @Elegantbeef "<@225449938258100225>\: i now leave": thanks :)
08:38:33FromDiscord<Elegantbeef> You can get the owner in a macro?
08:38:48FromDiscord<Elegantbeef> Never knew that
08:41:28FromDiscord<impbox [ftsf]> what does ownership mean in nim?
08:41:54FromDiscord<Elegantbeef> In macros?
08:42:29FromDiscord<Elegantbeef> Assuming yes, it tells you what scope owns the symbol i believe be it a procedure, a block stmt, or a module
08:42:51FromDiscord<dain> that's cool
08:43:10FromDiscord<dain> so the macro can look "outside" of itself into where it is being used?
08:43:39FromDiscord<Elegantbeef> Well typed parameters are semantically checked so you have a ton of information
08:43:44FromDiscord<impbox [ftsf]> big if true! nice
08:44:08FromDiscord<Elegantbeef> So if you have a symbol you can check what it's type is as a nimnode and look that up as well
08:44:33FromDiscord<Elegantbeef> So you can go from a variable to at type declaration doing what you will, tons of introspective capabillities
08:44:45FromDiscord<Elegantbeef> As much as saem doesnt like macros they do their job well 😛
08:46:04FromDiscord<Elegantbeef> The macro cache is also pretty powerful for cross module stuffs, or even cross macro invocation stuff
08:46:14FromDiscord<saem> They're bad, mmmmkay.
08:46:48FromDiscord<Elegantbeef> An example of that cross macro invocation stuff https://play.nim-lang.org/#ix=3zdG
08:47:03FromDiscord<Elegantbeef> Scroll to bottom to see the actual use case
08:47:33FromDiscord<Elegantbeef> Basically you can set key frames for a specific field then when you call animate with a float it will handle the "animations"
09:26:49FromDiscord<surajvb> is there a sample snippet to learn about iterating through something equivalent of zipped iterables?
10:03:06*PersonMcGuy joined #nim
10:04:19PersonMcGuyHello, does anyone know the internal structure of a seq? I found a resource showing it once, but I can't seem to find it again. Is it a pointer and a few int fields?
10:05:44PersonMcGuyOh, nevermind. I think I just found what I was searching for.
10:05:47*PersonMcGuy quit (Client Quit)
10:19:29*Vladar joined #nim
10:29:44arfyhi. I just want to check my understanding is correct about the way modules with import and include work. If I have, file A, and I import this into File B, which is, in turn, imported into file C, the public symbols only show up in the scope of file B directly? or do the public symbols go global.
10:30:14arfyif i used include on the other hand, it would be as if i just copy 'n asted the files together.
10:38:25FromDiscord<cabboose> Essentially↵(<@709044657232936960_arfy=5b=49=52=43=5d>)
10:38:52FromDiscord<cabboose> not unless File B exports the symbols of File C by doing `export c`↵(<@709044657232936960_arfy=5b=49=52=43=5d>)
10:39:35FromDiscord<cabboose> often nimble packages top level files are just a list of imports and then exports
10:40:00arfynice.
10:49:00*max22- quit (Ping timeout: 260 seconds)
10:51:41*max22- joined #nim
11:18:57FromDiscord<dom96> cabboose: can CPS beat Httpbeast yet? 🙂
11:20:10FromDiscord<cabboose> Hahaha looking into combining the queue with continuations and io but I don't have a choice since I have windows ;\_;
11:22:01FromDiscord<cabboose> I don't think we have anything to compare the queue to in nim though; i don't think it can be as fast as MPSCs but will be an interesting comparison
11:22:24FromDiscord<dom96> hm, not sure what queues have to do with this
11:22:53FromDiscord<cabboose> Just in general
11:23:01FromDiscord<cabboose> I am excited that it's working is all
11:23:50FromDiscord<cabboose> But as for httpbeast that is yet to be taken to arms! ;)
11:24:05FromDiscord<cabboose> I assume you had seen the loony queue though
11:24:16FromDiscord<dom96> what's the blocker?
11:26:09FromDiscord<cabboose> In reference to challenging you and httpbeast? Because I know nothing about networking and no one else seems to care about making it good for windows but me \:')
11:26:20*max22- quit (Ping timeout: 260 seconds)
11:26:37FromDiscord<dom96> in terms of making a performant http server
11:27:08FromDiscord<dom96> I don't think of it as a challenge to me, rather a challenge to other http servers out there. I want to see Nim at the top
11:29:16FromDiscord<cabboose> Well
11:29:18FromDiscord<cabboose> the short answer is
11:29:22FromDiscord<cabboose> I'm learning as I'm going
11:29:26FromDiscord<cabboose> and I'm a knob at networking things
11:29:56FromDiscord<cabboose> AFAIK multithreading and async IO is quite a PITA everywhere
11:31:49FromDiscord<cabboose> Don't ask me too many smart things; I drank a lot last night and my eyes still bleed looking at words on the screen
11:46:11FromDiscord<Gumber> bleh
11:46:19FromDiscord<Gumber> last sentence made me glad I barely touch the stuff anymore
11:46:32FromDiscord<Gumber> and grateful to wake up not hung over 🙂
11:47:14FromDiscord<Gumber> sorry - not trying to rub it in lol
11:47:15FromDiscord<cabboose> It was a 30th and 10 year high school reunion afterwards; I am in pain
11:47:21FromDiscord<Gumber> ooph
11:47:43FromDiscord<Gumber> I skipped my ten year but I guess my 20th is coming up in 2?
11:47:56FromDiscord<Gumber> probs will skip that too - fuck HS lol
11:48:15FromDiscord<Gumber> In reply to @cabboose "AFAIK multithreading and async": also this is true
11:48:38FromDiscord<Gumber> well maybe not universally - like async IO is quite not the PITA if you're using green threads with a good scheduler
11:48:52FromDiscord<Gumber> like it's not a bad situation with Erlang or Golang or Pony, etc...
11:49:11FromDiscord<Gumber> sharing memory between them becomes triivial
11:49:15FromDiscord<Gumber> because it doesn't happen
11:49:43FromDiscord<Gumber> but in the world of concurrency and Nim where you rely on traditional concurrency primitives
11:49:50FromDiscord<Gumber> the situation is the same as in C or C++ or wherever and it used to be worse
11:50:16FromDiscord<cabboose> Yeah; they have their own overheads though, golang for instance has a bunch of IO threads waiting to do work
11:50:19FromDiscord<Gumber> when you had no option BUT to have a separate runtime with its own GC in every shared library you built with nim
11:50:25FromDiscord<Gumber> oh I'm not saying it's not without cost
11:50:32FromDiscord<Gumber> or complexity
11:50:35FromDiscord<cabboose> mmm
11:50:59FromDiscord<Gumber> but like - typically in those languages you just throw work at a scheduler and don't have to worry about much
11:51:09FromDiscord<Gumber> I think CPS is making things much better for Nim
11:51:22FromDiscord<Gumber> but like they're probably worthless for me for a while
11:51:25FromDiscord<Gumber> because I use the cpp backend
11:51:34FromDiscord<Gumber> last I checked work hadn't started on that yet
11:51:40FromDiscord<Gumber> or at least not in earnest
11:52:09FromDiscord<cabboose> try the MPMC queue; works with any ref object and i'd love to hear how it works on other backends
11:52:13FromDiscord<Gumber> tis okay though - I'm pretty good at multithreaded programming and fibers
11:52:19FromDiscord<Gumber> I'll check it out
11:52:46FromDiscord<Gumber> anyway, back to working on this vulkan renderer
11:53:14FromDiscord<Gumber> got my render graph library all set up, just need to keep writing this C interface and writing glue code and in maybe another day or two I'll have something drawing to the screen xD
11:53:44FromDiscord<cabboose> pain
11:53:48FromDiscord<cabboose> draw pain
11:53:49FromDiscord<Gumber> oh yeah and I went to bed with this error I couldn't figure out damnit... hopefully it was just because I was falling asleep at the keyboard
11:53:59FromDiscord<Gumber> yeah - but I've done a lot of 3d work so it's just Vulkan
11:54:03FromDiscord<Gumber> and all the boilerplate
11:54:11FromDiscord<Gumber> even with vk-bootstrap it's a pain
11:54:34FromDiscord<Gumber> but to make matters worse on myself I picked a rendergraph library written in C++ that uses C++20
11:54:40FromDiscord<Gumber> so I get to wrap it with my own C interface
11:54:48FromDiscord<Gumber> since Nim can't handle C++20/latest
11:55:03FromDiscord<cabboose> shit
11:55:07FromDiscord<cabboose> why even
11:55:13FromDiscord<Gumber> it's better than writing it myself
11:55:24FromDiscord<Gumber> it has like eight dependencies, depends on shit like spir-v cross etc
11:55:32FromDiscord<Gumber> would probably take a couple of months to port
11:55:47FromDiscord<Gumber> just not worth the time and I'd probably end up having to do the same thing elsewhere eventually
11:56:11FromDiscord<Gumber> and if you want to write a performant vulkan renderer
11:56:19FromDiscord<Gumber> you either need to know wtf you're doing (which I don't)
11:56:34FromDiscord<Gumber> or you need to rely on someone smarter than you who does, and use their shit
11:56:47FromDiscord<Gumber> or you can pretend you know what you're doing like the author of Godot
11:56:54FromDiscord<Gumber> (okay I swear, I swear, I'm done xD)
11:57:23FromDiscord<Gumber> but uh yeah, I picked option B and I'm sticking with it - I can write the renderer I just don't know how to architect / design one to be relatively bottleneck-free
11:57:50FromDiscord<Gumber> and I don't to spend three years learning how - so I'm just going to use this guy's rendergraph - it seems pretty baller even if he did pick C++20/latest to write it in
11:57:58FromDiscord<Gumber> they sorry
11:58:18FromDiscord<Gumber> they didn't pick it for ridiculous reasons either - seems like they wanted to use features of C++20 that are actually useful, like spans
11:58:30FromDiscord<Gumber> https://github.com/martty/vuk
12:01:51FromDiscord<haxscramper> Technically nim can handle all of the C++, it is only a matter of how ugly you are willing to go
12:02:13FromDiscord<haxscramper> But if we speak native support we don't even cover C++11 with variadic templates
12:02:17FromDiscord<haxscramper> And OOP etc.
12:03:04FromDiscord<Gumber> well yeah
12:03:17FromDiscord<Gumber> I could patch the stdlib I guess
12:03:41FromDiscord<Gumber> but it seemed like less work to just write a C interface
12:06:02*supakeen quit (Quit: WeeChat 3.2.1)
12:06:31*supakeen joined #nim
12:11:25FromDiscord<dom96> HS reunions, such a US thing
12:11:58FromDiscord<cabboose> Am aus doe
12:12:40FromDiscord<Rika> me in asia with grade school reunions:
12:31:19FromDiscord<Gumber> I don't have much, or really any interest in going to them
12:31:42FromDiscord<Gumber> two of my best friends I went to HS with but they're literally the only people from my HS I talk to
12:32:39FromDiscord<Gumber> might be fun to go back and jone on people but other than that...
12:33:02FromDiscord<Gumber> Australian HS reunions sound fun to me
12:33:25FromDiscord<Gumber> but that's just because everything about Australia sounds fun - except all of the wildlife that can kill you
12:33:47FromDiscord<cabboose> That's the best part though↵(@Gumber aka Zachary Carter)
12:33:51FromDiscord<Rika> australia right now is kinda hectic wrt covid though
12:33:56FromDiscord<cabboose> That's why reunions are so magical
12:33:57FromDiscord<impbox [ftsf]> i think my HS class had a reunion, but i didn't go, happy to never see those people again
12:34:01FromDiscord<Gumber> thank goodness I just had it then!
12:34:44FromDiscord<impbox [ftsf]> @Rika it's the worst it's been here, but it still seems like it's better than a lot of other places in the world wrt covid
12:35:00FromDiscord<Rika> cabboose can you sell me on cps im still trying to understand
12:35:05FromDiscord<Gumber> it's bad here - I think maybe it's getting better than it was in August but ???
12:35:12FromDiscord<Gumber> Rika learn what a continuation is first
12:35:14FromDiscord<Rika> In reply to @impbox "<@!259277943275126785> it's the worst": oh totally eyes the US
12:35:20FromDiscord<Gumber> go read about them
12:35:22FromDiscord<Gumber> in other languages
12:35:26FromDiscord<Gumber> and then you'll start to get it
12:35:30FromDiscord<Rika> i know what continuations are
12:35:32FromDiscord<Gumber> okay
12:35:38FromDiscord<impbox [ftsf]> I think I get CPS now... It basically takes a normal function and turns it into lots of little functions that chain themselves or something
12:35:40FromDiscord<Gumber> so CPS is just a compile time transformation
12:35:43FromDiscord<Rika> ive read the paper so many times
12:35:46FromDiscord<Rika> yes i know
12:35:56FromDiscord<Rika> i mean understand[ the benefits]
12:35:56FromDiscord<Rika> sorry
12:36:02FromDiscord<Gumber> you want to understand the implementation
12:36:03FromDiscord<Gumber> I got you
12:36:08FromDiscord<Rika> god damn it
12:36:09FromDiscord<Gumber> yeah I dunno that shits over my head
12:36:14FromDiscord<impbox [ftsf]> magic
12:36:18FromDiscord<Gumber> exactly
12:36:23FromDiscord<Gumber> for the birds
12:36:31FromDiscord<Gumber> I'm just gonna make my programs go brrrrrrrrrr with it
12:36:39FromDiscord<Gumber> when it works with the cpp backend anyway
12:37:22FromDiscord<Gumber> I took the fibers from my job system and figured out how to replace them with continuatoins
12:37:27FromDiscord<Gumber> (edit) "continuatoins" => "continuations"
12:37:40FromDiscord<Gumber> right before I went on my trip back in June to get married
12:38:22FromDiscord<Gumber> but I'll have to revisit it later - I don't even know if I'm going to end up using that job system in my game - I'll implement some kind of job system just not sure what yet
12:38:36FromDiscord<cabboose> Sure I can sell you on it
12:38:38FromDiscord<Gumber> maybe weave will finally be ready for games and be stable by the time I need one
12:38:40FromDiscord<cabboose> what do you want to do
12:38:47FromDiscord<Rika> just regular async
12:38:51FromDiscord<Gumber> no
12:38:58FromDiscord<Rika> i dont want to really write my own dispatcher...
12:39:08FromDiscord<Rika> i just want to see if it's easy perf gain
12:39:13FromDiscord<cabboose> fair enough
12:39:19FromDiscord<Rika> if not then ill stay
12:39:26FromDiscord<Rika> on regular async i mnea
12:39:27FromDiscord<Rika> mean
12:39:31FromDiscord<Gumber> oh Rika wants async
12:39:32FromDiscord<Gumber> gotcha
12:39:41FromDiscord<cabboose> oh yeah I reckon it definitely is. Do you want multithreaded or single threaded
12:39:54FromDiscord<Rika> i dont know how to mesh threading with async yet
12:40:04FromDiscord<Rika> i would like to know how some day (maybe now)
12:40:19*arkurious joined #nim
12:40:20FromDiscord<Rika> wait im fucking shivering for some reason one moment
12:40:38FromDiscord<Gumber> you have a scheduler running on each thread
12:40:53FromDiscord<Gumber> and the scheduler schedulers work on each cpu
12:40:55FromDiscord<dom96> The only benefit I see is perf improvement and ability to decide where to alloc these continuations
12:41:02FromDiscord<Gumber> or you have a scheduler that schedulers work across them
12:41:06FromDiscord<Gumber> but each one has an event loop
12:41:07FromDiscord<dom96> still waiting to see that perf improvement 🙂
12:41:15FromDiscord<cabboose> me and zevv are looking at a threadpool implementation
12:41:20FromDiscord<Gumber> nice
12:41:22FromDiscord<cabboose> for async multithreading
12:41:28FromDiscord<Gumber> maybe talk to @mratsim
12:41:34FromDiscord<Gumber> oh shit he had dnd on, my bad
12:41:41FromDiscord<Rika> dnd doesnt dispatch notifs
12:41:42FromDiscord<dom96> In reply to @Rika "i dont know how": You can simply run an async loop in each thread (what httpbeast does)
12:42:04FromDiscord<Rika> i get that
12:42:15FromDiscord<Rika> okay
12:42:18FromDiscord<Gumber> yeah I guess closure iterators vs continuations is the thing right
12:42:22FromDiscord<Gumber> are they really faster
12:42:35FromDiscord<Gumber> and I guess the proof will be in the pudding
12:42:41FromDiscord<Gumber> once someone writes something and does some benchmarking
12:42:44FromDiscord<Anuke> In reply to @Elegantbeef "Simples it s https://play.nim-lang.org/#ix=3ziM": The amount of optional parameters looks more like this, so adding overloads for every parameter isn't a great option https://media.discordapp.net/attachments/371759389889003532/889129379098132500/unknown.png
12:43:22FromDiscord<Rika> when i encounter procs with many parameters like that i convert some of them to an object
12:43:40FromDiscord<Rika> like a "SmthOptions" object
12:43:47FromDiscord<Gumber> tuples
12:43:48FromDiscord<Rika> most of the time theyre shared anyway
12:43:53FromDiscord<Gumber> tuples are great for this
12:44:24FromDiscord<Gumber> no overhead of object
12:44:25FromDiscord<Gumber> but anyway
12:45:10FromDiscord<cabboose> @Rika\: give me a day or two to see if we can iron out a implementation for async continuations that doesn't necessarily use the std dispatcher and i'll get back to you
12:45:32FromDiscord<cabboose> otherwise with continuations you would still have to run the dispatcher
12:45:34FromDiscord<Rika> hey wait i didnt mean spend time on smth like that
12:45:37FromDiscord<cabboose> I usually hide it inbetween me doing different continuations
12:45:44FromDiscord<cabboose> I'm already doing it though
12:45:55FromDiscord<Rika> oh if its something you had to do even without me asking then ok
12:46:01FromDiscord<cabboose> yep
12:47:59FromDiscord<Gumber> but wait
12:48:06FromDiscord<Gumber> are continuations going to start being used in the stdlib?
12:48:19FromDiscord<Gumber> like is that the plan?
12:48:48FromDiscord<Rika> afaik
12:48:49FromDiscord<Rika> yes
12:48:57FromDiscord<dom96> there is no plan
12:48:58FromDiscord<Gumber> okay so someone convinced Araq
12:48:59FromDiscord<cabboose> 🤷‍♂️
12:49:03FromDiscord<Gumber> oh okay
12:49:07FromDiscord<cabboose> Nope
12:49:12FromDiscord<Gumber> there is no plan? that sounds ominous
12:49:20FromDiscord<Gumber> I hope there's a plan...
12:49:28FromDiscord<Gumber> a plan for something...
12:49:31FromDiscord<haxscramper> https://github.com/nim-lang/RFCs/issues/295
12:49:36*max22- joined #nim
12:49:37FromDiscord<haxscramper> if you are willinng to dig througgh this
12:49:41FromDiscord<Gumber> thanks
12:50:20FromDiscord<dom96> The only plan as far as I know is: help CPS be implemented and see where it goes
12:50:45FromDiscord<haxscramper> from what I see large problems for CPS is untyped AST being unspecified
12:50:58FromDiscord<haxscramper> Since there is no spec, and compiler does all sort of weird things
12:51:03FromDiscord<dom96> but I know that Araq was trying to push for CPS to be implemented in the compiler as well
12:51:18FromDiscord<haxscramper> I'd rather have speced typed AST
12:51:34FromDiscord<haxscramper> This will benefit everyone
12:51:55FromDiscord<cabboose> Mmmm, I reckon if more people used or wanted those types of changes and made their voices known about it then they would have to make progress on it
12:52:09FromDiscord<cabboose> Haxscramper will start a change.org petition XD
12:52:27FromDiscord<Rika> and get like 5 signatures
12:52:42FromDiscord<haxscramper> Well, current opinon is that typed ast is approximately int he middle of the tetrahedron of pain
12:52:43FromDiscord<dom96> "There are dozens of us".meme.png
12:52:45FromDiscord<cabboose> that's 5 more than what we have now
12:52:50FromDiscord<Gumber> dom96: you know of very few people who use threads because Nim's memory model was terrible for threading for the longest time
12:52:51FromDiscord<haxscramper> generics, types, ast
12:52:58FromDiscord<Gumber> come on now
12:53:10FromDiscord<Gumber> for years were like like - how do we write multithreaded code with Nim
12:53:13FromDiscord<Gumber> and crickets...
12:53:14FromDiscord<dom96> hm? what do you mean?
12:53:32FromDiscord<Gumber> you either had to already know an s ton about computer science and concurrent programming
12:53:45FromDiscord<Gumber> or you had to be Araq and know about the experimental GC's and how channels etc were implemented
12:53:58FromDiscord<Gumber> because it was like a bi-weekly topic for a couple of years in this IRC
12:54:04FromDiscord<Gumber> and then eventually we got arenas
12:54:09FromDiscord<Gumber> and then we got ARC/ORC
12:54:17FromDiscord<Gumber> but for the longest time no one touched threads because spawn never worked
12:54:19FromDiscord<Gumber> parallel never worked
12:54:22FromDiscord<Gumber> threadpool never worked
12:54:27FromDiscord<Gumber> every DLL had its own GC
12:54:32FromDiscord<cabboose> continuations works \:')
12:54:38FromDiscord<Gumber> Nim's multithreading picture was abhorrent
12:54:38FromDiscord<cabboose> with loony \:')
12:54:41FromDiscord<cabboose> \:')
12:54:54FromDiscord<Gumber> so it's a wonder no one used threads and everyone used async - it was the only realistic option for a lot of people
12:55:02FromDiscord<Gumber> but IMO threads are better in every way
12:55:02FromDiscord<dom96> You're implying that I am saying that multithreading was good, but I'm confused where I am saying that
12:55:07FromDiscord<Gumber> no you're saying it's not good
12:55:11FromDiscord<Gumber> I'm saying it is
12:55:21FromDiscord<Gumber> and I use threads all the time
12:55:30FromDiscord<dom96> threading is a necessity 🙂
12:55:36FromDiscord<Rika> well yeah
12:55:47FromDiscord<cabboose> lets get that petition going
12:55:57FromDiscord<cabboose> 👀
12:55:58FromDiscord<Rika> you have 6 signatures now how nice
12:56:03FromDiscord<dom96> but yeah, I've disliked this gc-safety stuff from the beginning
12:56:12FromDiscord<haxscramper> In reply to @Rika "you have 6 signatures": We can write RFC ...
12:56:15FromDiscord<dom96> afaik ORC/ARC is meant to solve this
12:56:21FromDiscord<haxscramper> Well,
12:56:22FromDiscord<Rika> hax im joking ;;;
12:56:25FromDiscord<Gumber> no it's not
12:56:36FromDiscord<Gumber> look sharing memory between threads is not safe at all
12:56:38FromDiscord<dom96> but then I hear that it isn't actually atomic...
12:56:40FromDiscord<Gumber> arc and orc dont' fix that
12:56:45FromDiscord<Gumber> (edit) "dont'" => "don't"
12:56:53FromDiscord<Gumber> they give you a shared heap
12:56:58FromDiscord<Gumber> that isn't thread local
12:57:07FromDiscord<dom96> yeah, and it's playing with pointers again
12:57:09FromDiscord<Gumber> but you still have to use locks and other concurrency primitives
12:57:11FromDiscord<dom96> this is what should be fixed
12:57:22FromDiscord<Gumber> use channels then
12:57:28FromDiscord<cabboose> whispers about CPS and loony
12:57:32FromDiscord<Gumber> or CPS and loony
12:57:35FromDiscord<Rika> cab pls
12:57:35FromDiscord<Gumber> or just use pointers
12:57:45FromDiscord<dom96> I don't want to use pointers
12:57:49FromDiscord<Gumber> 🤷
12:57:52FromDiscord<dom96> I want safety
12:57:59FromDiscord<dom96> there is a reason I don't use C/C++
12:57:59FromDiscord<Gumber> your requirements are diffefrent from mine
12:58:10FromDiscord<Gumber> (edit) "diffefrent" => "different"
12:58:14FromDiscord<dom96> and channels can't be used for everything
12:58:18FromDiscord<dom96> sometimes I need a shared state
12:58:29FromDiscord<Rika> eh what why wouldnt channels be ideal for that
12:58:39FromDiscord<Rika> i mean
12:58:41FromDiscord<Rika> not ideal
12:58:42FromDiscord<Rika> usable
12:59:08FromDiscord<dom96> hm, maybe they would be enough
12:59:11FromDiscord<Gumber> I never claimed channels weren't cumbersome
12:59:14FromDiscord<dom96> just trying to think of some common cases
12:59:21FromDiscord<Gumber> but every abstraction has its cost
12:59:28FromDiscord<dom96> I guess the most common is wanting to share a db connection between threads
12:59:39FromDiscord<Gumber> if you care that much about safety
12:59:45FromDiscord<Rika> wait what why
12:59:47FromDiscord<dom96> but then you could just have a db connection per thread too lol
12:59:52FromDiscord<Rika> idk why youd need to share the connection
12:59:52FromDiscord<Rika> yeah
13:00:13FromDiscord<Gumber> you're waiting around like everyone else for someone to figure out it 🙂 until then we have threads locks mutexes semaphores conditions and pointers
13:00:17FromDiscord<Gumber> and now continuations 🙂
13:00:21FromDiscord<Gumber> oh and closure iterators
13:00:34FromDiscord<Gumber> but threads are great
13:00:59FromDiscord<dom96> I think most programmers just want to go for a shared global variable by default
13:01:09FromDiscord<Gumber> I've used them 100x more than any stdlib async stuff from Nim in the past year or so
13:01:16FromDiscord<dom96> but maybe channels/state per thread is the right mindset
13:01:20FromDiscord<dom96> in that case, we're done lol
13:01:26FromDiscord<dom96> where is our problem? 😛
13:01:46FromDiscord<cabboose> @dom96\: a bit offtopic but do I have to wait for another reviewer to check the nimble pull request for it to be accepted?
13:02:03FromDiscord<Rika> In reply to @dom96 "I think most programmers": a good middleground is to probably make an abstraction that simulates shared state with channels
13:02:17FromDiscord<Rika> ofc still comes with a cost
13:02:52FromDiscord<Gumber> sometimes you have to have a shared state
13:04:28FromDiscord<Gumber> but regardless, memory safety issues are like the last problem I fight on a regular basis
13:04:40FromDiscord<dom96> okay, so can you give an example of when a shared state is necessary?
13:04:42FromDiscord<Gumber> and when I do have to fight them I generally know where they're lurking
13:05:19FromDiscord<Gumber> sure - let's say you have a main thread that is managing a bunch of worker threads and they're spawning closure iterators or continuations
13:05:43FromDiscord<Gumber> you need the closure iterator context or fiber stack or whatever on all threads
13:06:02FromDiscord<Gumber> because you're jumping between them
13:07:14FromDiscord<Gumber> now you could certainly try to copy and synchronize changes to this shared mutable state but you'd be creating more contention trying to synchronize all of the changes between copies
13:07:44FromDiscord<Gumber> not to mention, you are already going to be locking and putting threads to sleep while they wait for work
13:08:11FromDiscord<Gumber> so you already have a very complicated situation with a lot of moving pieces
13:08:44FromDiscord<Gumber> and you'll most likely just make matters worse if you try to distribute copies of this state and synchronize them
13:08:58FromDiscord<Gumber> is it possible? sure
13:09:00FromDiscord<Gumber> is it a good idea? no
13:09:30FromDiscord<dom96> I see, makes sense. Sounds like a very specialised case though, which makes me think that for vast majority of cases shared state isn't necessary and thus making it hard is fine.
13:09:48FromDiscord<Gumber> it's pretty much any work stealing / task scheduling job system out there involving threads
13:10:13FromDiscord<Gumber> like pretty much any thick client application that wants to parallelize work across threads is going to be gunning for something like this
13:10:18FromDiscord<Gumber> lots of little short lived tasks
13:10:23FromDiscord<Gumber> that take very little CPU time
13:10:47FromDiscord<Gumber> games are just one example
13:11:00FromDiscord<Gumber> and they have some unique requirements just because of their reliance on the GPU
13:11:16FromDiscord<Gumber> but I don't think it's as uncommon as one might expect in the world of systems programming
13:11:27FromDiscord<Gumber> there's a really good podcast on this topic by the guys from the machinery if anyone is interested
13:11:58FromDiscord<Gumber> https://anchor.fm/ourmachinery/episodes/S3-EP2-Fiber-Based-Job-Systems-em88k4
13:12:05*arfy waves hi
13:12:13FromDiscord<Gumber> these guys are fucking awesome - if you're not reading their blog or listening to their podcast you should be
13:12:22*arfy randomly notes statement modifiers, as in perl would be nice sometimes.
13:12:44FromDiscord<Rika> ?
13:12:51FromDiscord<Gumber> https://ourmachinery.com/post/ blog is here
13:13:48arfycart.title = title if title.
13:14:12arfyin other words, set the title only if the new variable has a value
13:14:17FromDiscord<Gumber> `cart.title = if title: title else: ""`
13:14:33FromDiscord<Gumber> (edit) "title:" => "title.len > 0:"
13:14:42arfyhuh wait that works?
13:14:44FromDiscord<Gumber> yes
13:14:45FromDiscord<Rika> yes
13:14:46FromDiscord<Gumber> ternary
13:14:50FromDiscord<Gumber> equivalent of a ternary
13:14:59FromDiscord<Rika> if expression technically
13:15:06arfyright
13:15:21FromDiscord<Anuke> How would I get the entire AST of a proc that was not passed into a macro?
13:15:36FromDiscord<Gumber> `dumpAST`
13:15:39FromDiscord<Gumber> but that's a macro
13:15:40FromDiscord<Gumber> so....
13:16:11FromDiscord<Rika> i believe its complicated to get the ast of something outside the macro's scope but i think its possible
13:16:15FromDiscord<Rika> just a bit hard
13:16:43FromDiscord<leorize> @Anuke\: if you have the symbol\: getImpl
13:17:36FromDiscord<Anuke> I have the proc right next to the macro, but I don't have its symbol. Is it possible to look up a symbol?
13:18:21FromDiscord<Rika> is your macro typed
13:19:00FromDiscord<leorize> hmm, what exactly are you trying to do?
13:20:21FromDiscord<Anuke> In reply to @amadan "Workaround I've used before": What I'm trying to do is implement what is mentioned in this comment here. I want a macro that tags varargs[untyped], and calls a proc with optional arguments automatically "filled in". To do this, I want to grab the AST from the proc I want to call, loop through the argument and append them to a `call` if they're not present in the varargs.
13:20:29FromDiscord<Anuke> (edit) "tags" => "takes"
13:20:33FromDiscord<Anuke> tags -> takes
13:20:58FromDiscord<leorize> you need typed
13:21:15*max22- quit (Ping timeout: 260 seconds)
13:21:23FromDiscord<leorize> but if you use typed then it can't sem...
13:21:59FromDiscord<leorize> the other solution is to pass the symbol and the parameters separately
13:22:14FromDiscord<Anuke> But the last argument is a code block that needs to be further transformed by another macro, I don't think that can be typed
13:24:45FromDiscord<Anuke> This is getting really complicated, so I think I'll actually use an object for all the optional arguments instead like Rika suggested, at least until a newer nim version is released
13:24:48FromDiscord<Anuke> thanks anyway
13:25:26FromDiscord<leorize> how about this\: `call_opt foo(a, b)` -\> `call_opt foo, a, b`
13:25:39FromDiscord<leorize> type the first argument only
13:25:58FromDiscord<leorize> so you get the proc symbol, but the rest will be figured out later
13:26:46FromDiscord<leorize> you will be basically redoing sigmatch so maybe it's not worth it
13:33:38*max22- joined #nim
13:39:21FromDiscord<mratsim> In reply to @cabboose "me and zevv are": https://github.com/status-im/nim-taskpools this is Weave simplified
13:39:48Zevvwithout the casting and the raw pointers?
13:39:51FromDiscord<mratsim> less than 1000 loc
13:39:55Zevvbecause that was a total show stopper for me on weave
13:42:05FromDiscord<mratsim> mmm you would have to point me to where you saw this on Weave. I remember raw pointers as workaround to Nim limitations and casting for the custom mempool
13:42:34ZevvI mean the things like `let bufIn = cast[ptr UncheckedArray[float32]](input[0].unsafeAddr)`
14:09:50FromDiscord<Gumber> I have two C++ functions that return pointers to opaque types
14:10:20FromDiscord<Gumber> well they return a std:vector of these types, wrapped in result type
14:10:33FromDiscord<Gumber> the two types are `VkImage` and `VkImageView`
14:10:54FromDiscord<Gumber> when I call the function that is supposed to return the result vector of `VkImageViews` however
14:10:58FromDiscord<Gumber> I get a weird error:
14:11:07FromDiscord<Gumber> sent a code paste, see https://play.nim-lang.org/#ix=3zlq
14:11:27FromDiscord<Gumber> I looked in the generated C++ code and there are some aliases defined for result<std::vector<VkImage>>
14:11:39FromDiscord<Gumber> but nothing for `result<std::vector<VkImageView>>>`
14:11:59FromDiscord<Gumber> sent a code paste, see https://play.nim-lang.org/#ix=3zlt
14:12:13FromDiscord<Gumber> sent a code paste, see https://play.nim-lang.org/#ix=3zlu
14:12:25FromDiscord<Gumber> sent a code paste, see https://play.nim-lang.org/#ix=3zlv
14:12:29FromDiscord<Gumber> `Result[T] {.importcpp: "vkb::detail::Result", header: vkbHeader.} = object`
14:12:48FromDiscord<Gumber> anyone have any idea?
14:12:53FromDiscord<Gumber> the C++ type is defined by a macro
14:13:07FromDiscord<Gumber> sent a code paste, see https://play.nim-lang.org/#ix=
14:13:15FromDiscord<Gumber> `VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkImageView)`
14:13:31FromDiscord<Gumber> I'm calling `get_images()` right before that line and the codegen seems to be fine with that one
14:16:27FromDiscord<Gumber> oh and here's the C++ for `get_images` and `get_image_views`
14:16:48FromDiscord<Gumber> sent a code paste, see https://play.nim-lang.org/#ix=3zlx
14:17:05FromDiscord<Gumber> (edit) "https://play.nim-lang.org/#ix=3zlx" => "https://play.nim-lang.org/#ix=3zly"
14:17:44FromDiscord<Gumber> seems to me like it couldn't construct the `std::vector` for some reason
14:17:57FromDiscord<Gumber> but I have no clue why....
14:18:10FromDiscord<Gumber> maybe I need to make the alised types for it? I dunno let me try that
14:20:40FromDiscord<Gumber> nope, no dice
14:21:25FromDiscord<Gumber> this is making my brain hurt... going to go get coffee
14:32:38FromDiscord<fae> Is the automatic deref experimental feature popular? I don’t see it used in many codebases
14:33:44FromDiscord<fae> Like are there downsides to using it? Does it make code less clear what is a ref and what is not? And if so is that an issue
14:41:27FromDiscord<leorize> it's not frequently used because not many people use ref afaik
14:43:48FromDiscord<fae> If you need to do some type of unsafe casting ref/ptr are your only options right? Since their size is the same
14:43:53FromDiscord<dom96> do you have a link to the docs for this experimental feature?
14:44:24FromDiscord<fae> https://nim-lang.org/docs/manual_experimental.html#automatic-dereferencing
14:45:24FromDiscord<leorize> yea, if you want the unsafe stuff
14:47:21FromDiscord<dom96> the reason you wouldn't use it is because you'd pass the ref to every function
14:47:32FromDiscord<dom96> it's not typical to have some that take the non-ref and some that take the ref
14:48:08FromDiscord<fae> So it’s overall just not a very useful feature
14:48:19FromDiscord<fae> Or at least, a niche one
14:49:44FromDiscord<dom96> yep
14:51:19NimEventerNew Nimble package! loony - Lock-free threadsafe MPMC with high throughput, see https://github.com/shayanhabibi/loony
14:52:50FromDiscord<Gumber> No one has a any ideas for my cpp issue?
14:53:41FromDiscord<Gumber> @haxscramper is probably my only hope
14:55:21FromDiscord<Gumber> Maybe I can just reinterpret cast the result
14:55:34FromDiscord<Gumber> Doubt it tho
15:00:48FromDiscord<deech> Are there any compile time procs for getting the current time? `now()` and `getTime()` use `importc`, I can shell out to `date` but thought I'd ask first.
15:02:45FromDiscord<xflywind> `getTime` can be used with `--experimental:vmopsDanger` at compile time.
15:06:02FromDiscord<deech> `static: echo getTime()` with that flag gives the error: `Error: cannot evaluate at compile time: localInstance`
15:06:27FromDiscord<xflywind> devel?
15:06:54FromDiscord<deech> sent a code paste, see https://play.nim-lang.org/#ix=3zlS
15:09:12NimEventerNew thread by HJarausch: --gc:orc when is it usable (huge compile times), see https://forum.nim-lang.org/t/8439
15:11:44FromDiscord<xflywind> In reply to @deech "`static: echo getTime()` with": It may be a bug.
15:18:31FromDiscord<Yardanico> In reply to @deech "Are there any compile": Yes
15:18:47FromDiscord<Yardanico> CompileTime and CompileDate, although they're constants
15:18:55FromDiscord<Yardanico> and represented as strings
15:20:39FromDiscord<xflywind> this works
15:20:47FromDiscord<xflywind> sent a code paste, see https://play.nim-lang.org/#ix=3zlU
15:22:12FromDiscord<deech> That does work! I wonder why `echo getTime()` doesn't.
15:23:03FromDiscord<xflywind> it call procs uses threadvar variables and `$` is not registered in vmops.
15:23:26FromDiscord<xflywind> (edit) "call procs" => "calls a proc" | "threadvar" => "`threadvar`" | "uses`threadvar`variables and ... `$`proc" added "the" | "uses`threadvar`variables andthe`$` ... is" added "proc"
15:40:23*Gustavo6046 quit (Quit: ZNC 1.8.2 - https://znc.in)
15:42:36FromDiscord<dom96> huh, I could have sworn exporting modules was now a thing
15:43:12FromDiscord<Yardanico> what do you mean? you can export modules by "export module" after importing one, yes
15:43:15FromDiscord<dom96> oh, I just can't do `export dir / module`
15:43:19FromDiscord<dom96> I have to do `export module`
15:43:22FromDiscord<dom96> do we have a bug for this?
15:43:35FromDiscord<Yardanico> is it really a bug though? export works on a module const name symbol
15:43:36FromDiscord<Gumber> It's been like that forever
15:43:39FromDiscord<Gumber> It's not a bug
15:43:56FromDiscord<Gumber> Forever means five years
15:43:59FromDiscord<Gumber> At least
15:44:05FromDiscord<Gumber> Since I joined
15:44:42FromDiscord<dom96> seems like it's something that should be supported at least
15:44:48FromDiscord<Gumber> Why
15:44:56FromDiscord<Gumber> It works as intended
15:45:05FromDiscord<Gumber> I don't see any benefit
15:45:30FromDiscord<dom96> if I end up with two modules of the same name then I'll have to rename one
15:45:33FromDiscord<Gumber> Just adding complexity for the sake of it
15:45:37FromDiscord<Yardanico> In reply to @dom96 "if I end up": of course
15:45:40FromDiscord<Yardanico> export is not related to that at all
15:45:42FromDiscord<Gumber> Yeah
15:45:46FromDiscord<Yardanico> you have to use "import x as y"
15:45:48FromDiscord<Gumber> You have to do that anyway
15:46:02FromDiscord<Gumber> If you want to qualify symbols
15:46:34FromDiscord<dom96> I suppose
15:46:37FromDiscord<fae> You want to export without importing first?
15:46:53FromDiscord<dom96> thinking about `export` taking an identifier rather than a path makes sense
15:47:04FromDiscord<Gumber> yeah it's like you resolve a path and it gets stored in an alias
15:47:13FromDiscord<Gumber> which is how the module is referred to in that compilation unit
15:47:18FromDiscord<Gumber> and then you can also export that symbol if you want
15:47:35FromDiscord<Gumber> I think the way it is designed is the right way
15:47:47FromDiscord<Gumber> the only beef I ever have with Nim imports
15:47:50FromDiscord<dom96> I wonder how easy we could make the error message nicer: "Cannot import dir / module" is far too vague. Should be fairly easy to append "; have you tried `export module`?
15:47:53FromDiscord<haxscramper> Is that correct?
15:47:53FromDiscord<haxscramper> sent a code paste, see https://play.nim-lang.org/#ix=3zm6
15:48:01FromDiscord<Gumber> not exactly hax
15:48:11FromDiscord<Gumber> well I'm not sure really
15:48:17FromDiscord<Gumber> because for Vulkan there's the C++ headers and the C headers
15:48:30FromDiscord<Yardanico> In reply to @dom96 "I wonder how easy": don't really get you there, how is "cannot import dir/module" related to "export module"?
15:48:38FromDiscord<Gumber> let me grab the C++ headers for the Vkimage and VkImageView one sec
15:48:43FromDiscord<dom96> er sorry, s/import/export/
15:48:48FromDiscord<haxscramper> You need to have s simplified model of the API you are trying to interface with, then this can be debugged easier
15:49:01FromDiscord<Gumber> I tried to make one
15:49:03FromDiscord<Gumber> but it compiled
15:49:17FromDiscord<Gumber> okay nevermind
15:49:21FromDiscord<haxscramper> Bane of all C++ interop
15:49:22FromDiscord<Gumber> let me share the example I put together
15:49:24FromDiscord<haxscramper> "it compiled"
15:49:35FromDiscord<Gumber> maybe it will shine some light
15:49:36FromDiscord<Gumber> yeah exactly
15:49:42FromDiscord<Gumber> like I DON'T want it to compile lol
15:49:43FromDiscord<Gumber> https://play.nim-lang.org/#ix=3zlV
15:49:44FromDiscord<Gumber> bad compiler!
15:50:04FromDiscord<Gumber> I tried to make it more concise by omitting all the `Result` crap
15:50:07FromDiscord<Gumber> but it compiled too
15:50:12FromDiscord<Gumber> soo... `Result` is there
15:50:25FromDiscord<Gumber> also in the real C++ code
15:50:35FromDiscord<Gumber> Swapchain is split into a header and implementation file
15:50:42FromDiscord<Gumber> I tried to do that in the `emit` block but it produced errors
15:50:49FromDiscord<haxscramper> wandbox.org allows to have multiple files in different languages
15:50:59FromDiscord<haxscramper> just if you find it more convenient
15:51:00FromDiscord<Gumber> oh shit - will do that next time thanks for the protip
15:51:30FromDiscord<Yardanico> In reply to @haxscramper "wandbox.org allows to have": it also allows for compilation flags (like --gc:orc) which is very useful too :)
15:51:40FromDiscord<Gumber> wowwwww this thing is amazing
15:51:42FromDiscord<haxscramper> also has nimb devel
15:51:49FromDiscord<haxscramper> though not nim packages
15:52:04FromDiscord<Gumber> anyway - yeah I can't figure out wtf is going on
15:52:06FromDiscord<Gumber> or how to fix it
15:52:17FromDiscord<Gumber> I'm offering money to any one who can lol $15 USD via paypal is the current bounty
15:52:51FromDiscord<Gumber> and I can put my code up somewhere but as far as getting it to compile - not going to go through that jungle gym with anyone
15:55:40FromDiscord<haxscramper> I'm looking into it right now
15:55:50FromDiscord<Gumber> and about your question earlier `VkImage` and `VkImageView` are both defined using that macro `VK_DEFINE_NON_DISPATCHABLE_HANDLE` which on my cpu-arch resolves to `#define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef struct object##_T object;`
15:55:53FromDiscord<Gumber> sweet - thank you
15:56:04FromDiscord<haxscramper> I would have to deal with this crap fountain pattern at some point, so I might as well do it right now
15:56:04FromDiscord<Gumber> so they're just pointers to opaque types
15:56:19FromDiscord<Gumber> and make $15
15:56:22FromDiscord<Gumber> in the process
16:04:33federico3@dom96 any feedback on https://github.com/nim-lang/nimble/issues/921 ? It's been a while.
16:06:38FromDiscord<dom96> Really not much feedback to give other than that I support implementing it
16:07:01FromDiscord<haxscramper> https://github.com/nim-lang/RFCs/issues/398
16:07:10FromDiscord<dom96> but I think it overlaps a lot with https://github.com/nim-lang/nimble/issues/80
16:07:33FromDiscord<haxscramper> Well, I will at least link it, though digging throught #398 is nearly impossible unless you want to spend quite some time
16:10:06FromDiscord<haxscramper> @Gumber aka Zachary Carter do you have a full wrappers somewher?
16:10:23FromDiscord<haxscramper> I will try to mimimize them instead
16:15:22FromDiscord<Gumber> yeah
16:15:34FromDiscord<Gumber> well not really
16:15:35FromDiscord<Gumber> full
16:15:43FromDiscord<haxscramper> just thing that fails for you
16:15:52FromDiscord<haxscramper> I need to reproduce your error, nothing more
16:16:10FromDiscord<Gumber> okay let me upload my code one sec
16:16:42FromDiscord<Goel> sent a code paste, see https://play.nim-lang.org/#ix=3zmg
16:16:59FromDiscord<haxscramper> `if rgbaSeq[n] in [alphaA, alphaB]`
16:17:25FromDiscord<haxscramper> idk about hidden overhead wrt. to intermediate array construction
16:22:52FromDiscord<Gumber> https://github.com/zacharycarter/FRAG
16:22:54FromDiscord<Gumber> @haxscramper
16:23:22FromDiscord<Gumber> I'm on windows and use vcc to compile everything
16:23:39FromDiscord<Gumber> I don't know if that's an issue or not
16:24:38FromDiscord<haxscramper> what file I have to compile
16:25:14FromDiscord<Gumber> frag.nim
16:25:18FromDiscord<Gumber> you can just do `nimble install -y`
16:25:33FromDiscord<Gumber> but there's a lot of C++ libraries that need manual compilation atm
16:25:43FromDiscord<Gumber> I can try to write some commands to compile them
16:25:59FromDiscord<Gumber> they're all in `thirdparty`
16:26:43FromDiscord<Gumber> the ones that need building are `vuk` , `glfw` and `shaderc`
16:27:04FromDiscord<Gumber> they're all linked statically
16:27:11FromDiscord<Gumber> and I think all three use cmake
16:27:21FromDiscord<Gumber> `vk-bootstrap` is compiled inside the `vkb.nim` module
16:27:45FromDiscord<Gumber> `vuk.nim` `vkb.nim` and `glfw.nim` have some pragmas that may need modifying
16:27:53FromDiscord<haxscramper> Just so you know ` {.error: "platform not supported!".}` is not really informative, writing what platform is actually supported is more user-friently
16:27:55FromDiscord<Gumber> vulkan SDK also has to be installed on your system and the paths to it have to be correct
16:27:59FromDiscord<haxscramper> I'm being picky here, but still
16:28:04FromDiscord<Gumber> this is all just very fast code
16:28:09FromDiscord<Gumber> it will all be refactored
16:28:44FromDiscord<Gumber> I'm not intending for anyone to use this really either - not anytime soon anyway - it's more just to remind myself that that section is platform specific
16:29:41FromDiscord<Gumber> everything needs to be compiled with `/MTd`
16:30:17FromDiscord<Gumber> I had to go into Visual Studio and right click on the projects that were generated by `vuk`'s `CMakeLists.txt` and adjust them to be so
16:30:42FromDiscord<haxscramper> I'm not on windows so it looks like I'm going to have some troubles compiling this, at least I can't do this without going over all `compile:` etc. things, which I certainly not be doing. So I will just examine wrappers and try to replicate them
16:30:52FromDiscord<Gumber> alrighty
16:31:03FromDiscord<Gumber> yeah that's what I tried with the minimal reproducible example - but maybe you'll have more luck than me
16:32:43FromDiscord<Gumber> if you walk back from https://github.com/zacharycarter/FRAG/blob/master/src/fragpkg/app.nim#L35-L47
16:33:20FromDiscord<Gumber> and more specifically - https://github.com/zacharycarter/FRAG/blob/master/src/fragpkg/app.nim#L54
16:33:33FromDiscord<Gumber> (edit) "https://github.com/zacharycarter/FRAG/blob/master/src/fragpkg/app.nim#L35-L47" => "https://github.com/zacharycarter/FRAG/blob/master/src/fragpkg/app.nim#L35-L60"
16:33:47FromDiscord<Gumber> that's the line that is problematic in the generated C++
16:37:09FromDiscord<Ayy Lmao> Is there a way to do something similar to varargs coercion but with a single value? Ideally not using a converter. So sort of like a converter that only works for a specific function.
16:38:27FromDiscord<haxscramper> https://media.discordapp.net/attachments/371759389889003532/889188697696788550/unknown.png
16:39:30FromDiscord<Gumber> lol
16:39:46FromDiscord<haxscramper> Why in the world each god-damn C++ library feels like I’m tasked with unearthing some kind of dinosaur and piecing it back together using nothing but a hammer and perforator
16:39:55FromDiscord<haxscramper> And five megaton nuke
16:39:57FromDiscord<Gumber> yeah, this is my life
16:39:59FromDiscord<Gumber> for the past few days
16:40:26FromDiscord<Gumber> think I started on this nonsense journey on Thursday last week
16:40:30FromDiscord<haxscramper> Where does `<VkBootstrap.h>` comes from
16:40:34FromDiscord<haxscramper> Is it auto-generated?
16:40:38FromDiscord<Gumber> vk-bootstrap in third party
16:40:50FromDiscord<Gumber> under the src dir
16:40:51FromDiscord<Gumber> of course
16:41:19FromDiscord<Gumber> actually
16:41:25FromDiscord<Gumber> that's probably the sanest library of them all
16:41:29FromDiscord<Gumber> minus the lack of an include dir
16:41:39FromDiscord<Gumber> but I mean, not like that's a hard rule or anything
16:41:52FromDiscord<haxscramper> ah, yes, I got destroyed by git again
16:41:56FromDiscord<haxscramper> cloned non-recursive
16:42:02FromDiscord<Gumber> ah yeah my bad should have warned you
16:42:12FromDiscord<Gumber> also why does C++ just embrace the ever living fuck out of ambiguity?
16:42:27FromDiscord<Gumber> like I always felt that way about C
16:42:37FromDiscord<Gumber> but it's just because of the lack of an ABI and the fact it needs to be that way to be portable
16:42:54FromDiscord<Gumber> C++ has an ABI and isn't portable but it still tries to just give you 10,000 ways to do things
16:43:26FromDiscord<Gumber> and most of the time only like four of them are really practical / useful
16:43:39FromDiscord<Gumber> sometimes more choices / options is not better
16:44:28FromDiscord<haxscramper> Want some `(T1 arg1, T2 arg2, decltype(arg1 + arg2)& result)`
16:45:05FromDiscord<Gumber> https://media.discordapp.net/attachments/371759389889003532/889190368053194823/6KXBnnAAlbCsV5A-4d23dS-FrxjNxyO5FGVMKIL_SCk.mp4
16:46:39FromDiscord<Gumber> In reply to @haxscramper "Want some `(T1 arg1,": I mean that looks like what I need
16:46:54*Gustavo6046 joined #nim
16:47:18FromDiscord<haxscramper> and btw, never, ever use discard when minimizing C++ shit
16:47:27FromDiscord<haxscramper> assign to some garbage, but not discard
16:47:33FromDiscord<Gumber> ah okay
16:47:38FromDiscord<haxscramper> because nim compiler might try to get smart with you
16:48:34FromDiscord<haxscramper> It is not guaranteed to happen, but just a safety precaution
16:49:16FromDiscord<Gumber> here we go
16:49:19FromDiscord<Gumber> https://play.nim-lang.org/#ix=3zmr
16:49:22FromDiscord<Ayy Lmao> Discard isn't safe on c++ functions?
16:49:25FromDiscord<Gumber> I think that might b ethe same error
16:49:29FromDiscord<Gumber> (edit) "b ethe" => "be the"
16:49:34FromDiscord<Gumber> just from GCC
16:49:54FromDiscord<Gumber> In reply to @Ayy Lmao "Discard isn't safe on": it's not that - it's just Nim will generate different C++ when you discard vs assign
16:50:04FromDiscord<Gumber> so when you're trying to track down a Nim cpp codegen issue
16:50:22FromDiscord<Gumber> discarding the result from a C++ function you've bound to, won't produce the same result as if you assigned the result to some variable
16:50:31FromDiscord<Gumber> which is why my minimal reproducible example compiled previously
16:50:41FromDiscord<Gumber> and now that I've fixed it to not discard the results, it isn't compiling anymore
16:50:46FromDiscord<Gumber> so I guess now I've reproduced it
16:50:52FromDiscord<Gumber> just on a different compiler toolchain
16:50:56FromDiscord<Gumber> and cpu arch
16:51:00FromDiscord<Gumber> sorry OS
16:51:11FromDiscord<Gumber> I don't know what cpu-arch the playground is running on
16:52:14FromDiscord<Gumber> but yay that's progress
16:53:39*stkrdknmibalz joined #nim
16:53:41FromDiscord<Gumber> I'm going to get ready to mow the lawn - will have my phone on me. @haxscramper PM me your paypal account email and I'll shoot you over the $15 USD
16:53:49FromDiscord<Gumber> You've already provided me with $15 of help anyway
16:53:57FromDiscord<haxscramper> sent a code paste, see https://play.nim-lang.org/#ix=3zmu
16:54:29FromDiscord<Gumber> I have so many gd chores to do because I was on the couch for like 11 days straight with COVID
16:54:44FromDiscord<Gumber> but it feels good to be able to do chores again lol
16:55:20FromDiscord<haxscramper> Nim should use `--error-format:json` from G++
16:55:29FromDiscord<Gumber> https://tenor.com/view/chefs-kiss-french-chef-perfect-dish-excellent-food-perfection-gif-20341505
16:55:39FromDiscord<Gumber> @dom96 really? can we fix gif embeds?
16:55:42FromDiscord<Gumber> that is lame af
16:55:48FromDiscord<Rika> no
16:55:53FromDiscord<Gumber> that's a discord gif embed
16:55:54FromDiscord<Gumber> not a link
16:55:57FromDiscord<Rika> image embeds are not separate from website embeds
16:56:03FromDiscord<Gumber> yo that is terrible
16:56:09FromDiscord<Gumber> why is discord so bad
16:56:19FromDiscord<Gumber> it's literally one of the worst pieces of software I've used in a while
16:56:22FromDiscord<Rika> i mean
16:56:30FromDiscord<Rika> its w/e
16:56:33FromDiscord<Rika> you get used to it
16:56:36FromDiscord<Gumber> no log files, can't differentiate b/w external links and internal ones
16:56:44FromDiscord<Rika> i dont know any other chat app that distinguishes embeds like that
16:56:45FromDiscord<Gumber> I don't want my software to make me get used to things
16:56:49FromDiscord<Gumber> I want it to do the things it should do
16:56:56FromDiscord<Gumber> I can't imagine it's that difficult
16:57:01FromDiscord<Rika> "discord gifs" are not internal
16:57:05FromDiscord<Rika> theyre from tenor
16:57:05FromDiscord<Gumber> serve them up with some query parameter
16:57:09FromDiscord<Gumber> okay so proxy them
16:57:31FromDiscord<Rika> it's "disable link embeds" not "disable external link embeds"
16:58:54FromDiscord<Rika> w/e
17:00:55FromDiscord<haxscramper> ahhhffs,
17:01:02FromDiscord<haxscramper> `Result` is not default constructible
17:01:46FromDiscord<haxscramper> sent a code paste, see https://play.nim-lang.org/#ix=3zmA
17:01:49FromDiscord<Gumber> crap...
17:02:06FromDiscord<Gumber> In reply to @Rika "it's "disable link embeds"": yeah but that's what I want
17:02:25FromDiscord<Gumber> In reply to @haxscramper "this is not the": yeah the error you quoted is the one I got locally
17:02:51FromDiscord<haxscramper> sent a code paste, see https://play.nim-lang.org/#ix=3zmB
17:02:54FromDiscord<haxscramper> `no matching function for call to ‘Result<std::vector<int> >::Result()’`
17:02:59FromDiscord<haxscramper> waiut a sec
17:03:25FromDiscord<haxscramper> In reply to @Gumber "https://play.nim-lang.org/#ix=3zmr": yes, it is the same one
17:04:13FromDiscord<haxscramper> I need to explicitly handle non-default-constructible types in hcparse, I forgot about that, again
17:06:15FromDiscord<Gumber> oh okay
17:06:44FromDiscord<Gumber> In reply to @haxscramper "I need to explicitly": so does that mean it is indeed a nim codegen bug?
17:06:51FromDiscord<Gumber> or is it like - I can abuse importcpp or something to make it work?
17:08:21FromDiscord<haxscramper> No, it means you need to mark `gget_image_views` as `{.constructor.}` and you can't have globals of type `Result`
17:08:54FromDiscord<haxscramper> Because nim genreates globals as top-level variables, which have to be initialized, but without arguments you can't do this
17:09:02FromDiscord<haxscramper> works
17:09:08FromDiscord<haxscramper> sent a code paste, see https://play.nim-lang.org/#ix=3zmD
17:09:16FromDiscord<haxscramper> sent a code paste, see https://paste.rs/kpa
17:09:33FromDiscord<haxscramper> sent a code paste, see https://play.nim-lang.org/#ix=3zmF
17:09:41FromDiscord<Gumber> fml
17:09:52FromDiscord<Gumber> because a constructor
17:09:56FromDiscord<Gumber> that's not really a constructor
17:10:01FromDiscord<Gumber> makes so much sense
17:10:06FromDiscord<Gumber> I love importcpp
17:10:19FromDiscord<Gumber> okay thank you for solving this for me - I'm now going to bang my head against the wall for a few minutes
17:10:22FromDiscord<haxscramper> But this is still not the same error
17:10:25FromDiscord<Gumber> oh
17:10:34FromDiscord<haxscramper> Yes, we just came up with new unrelated error
17:10:38FromDiscord<Gumber> lolol
17:11:38FromDiscord<haxscramper> sent a code paste, see https://play.nim-lang.org/#ix=3zmG
17:12:05FromDiscord<haxscramper> sent a code paste, see https://play.nim-lang.org/#ix=3zmH
17:12:24FromDiscord<Gumber> okay thanks - I'll give this a go
17:12:27FromDiscord<haxscramper> My guess is that somewhere you mixed types
17:12:32FromDiscord<Gumber> probably
17:12:43FromDiscord<haxscramper> so `get_images` is declared as returning T on the nim side
17:12:50FromDiscord<haxscramper> but in reality it returns Z
17:13:11FromDiscord<haxscramper> but nim genreates `T temp;` and then does `temp = <>`
17:14:03FromDiscord<Gumber> yeah
17:14:22FromDiscord<Gumber> just gotta go through all the layers I guess and figure it out - tried that a few times but to no success
17:14:29FromDiscord<Gumber> okay thanks - again PM me so I can paypal you lol
17:14:43FromDiscord<Gumber> going to take a break and work on the lawn, but I'll be back in a bit and try to continue fixing this crap
18:05:49*neurocyte01 quit (Ping timeout: 252 seconds)
18:24:12*max22- quit (Ping timeout: 245 seconds)
18:32:53FromDiscord<Smarc> sent a code paste, see https://play.nim-lang.org/#ix=3zn5
18:35:09FromDiscord<Recruit_main707> you need to compile with `--threads:on`
18:39:30FromDiscord<Smarc> sent a code paste, see https://play.nim-lang.org/#ix=3zn8
18:40:03FromDiscord<Smarc> nvm, I fucked up
18:40:46FromDiscord<enthus1ast> @dom96\: can you check if i have crashed the forum?
18:40:53FromDiscord<enthus1ast> it seems like it
18:42:43FromDiscord<gerwy> Hi↵is Aporia still good? It seems it wasn't updated in a while and also when i want to build it, it says it cannot import asyncio, which i checked and there is no library like that, maybe it changed the name in the past
18:42:55FromDiscord<gerwy> i guess it could be `asyncdispatch`
18:43:15FromDiscord<enthus1ast> or who else has access to server logs \:)
18:43:15FromDiscord<enthus1ast> i can reproduce this\:
18:43:16FromDiscord<enthus1ast> image.png https://media.discordapp.net/attachments/371759389889003532/889220111515418644/image.png
18:44:22FromDiscord<gerwy> i have access to forum normally
18:44:46FromDiscord<gerwy> (edit) removed "normally"
18:47:38FromDiscord<dom96> In reply to @Gumber "<@!132595483838251008> really? can we": save gif -> reupload and it should work
18:48:06FromDiscord<dom96> enthus1ast: report it on the issue tracker
18:48:23FromDiscord<Yardanico> In reply to @Life Sucks "Hi is Aporia still": it haven't been maintained for a long time, so even after you fix all deprecated/removed code (I did a bit of that in my fork around a year ago) a lot of stuff might still not work
18:48:25FromDiscord<Yardanico> also it relies on gtk2
18:48:33FromDiscord<dom96> In reply to @Life Sucks "Hi is Aporia still": Aporia is quite old by now
18:48:40FromDiscord<gerwy> :<
18:48:47FromDiscord<gerwy> It seemed like a cool project
18:48:47FromDiscord<enthus1ast> should i report a live crash on the issue tracker? @dom96 ?
18:49:16FromDiscord<dom96> sure, there are others already there
18:49:19FromDiscord<dom96> PRs welcome 🙂
18:49:56FromDiscord<enthus1ast> ok
18:50:35FromDiscord<enthus1ast> i mean if someone wants evil to nim project, the forum would be down all the time ;)
18:51:31FromDiscord<dom96> yeah, maybe
18:52:03FromDiscord<dom96> I'd probably just configure nginx to disallow those requests
18:53:00FromDiscord<enthus1ast> in my case its nothing special, i even don't know exactly if i crash it
18:53:10FromDiscord<enthus1ast> it seems like
18:53:25FromDiscord<enthus1ast> maybe you can see it in the server logs
18:53:39FromDiscord<enthus1ast> if it was restarted by systemd?
18:54:11FromDiscord<dom96> I can but not right now
18:54:32FromDiscord<enthus1ast> ok
18:58:10FromDiscord<Smarc> sent a code paste, see https://play.nim-lang.org/#ix=3znh
18:58:34*max22- joined #nim
18:59:22FromDiscord<Yardanico> that library are you using for sounds?
18:59:30FromDiscord<Smarc> slappy
18:59:46FromDiscord<Yardanico> but generally the error is because you're using a global variable in another thread, and nim with the default GC (refc) has thread-local heap
18:59:58FromDiscord<Yardanico> In reply to @Smarc "slappy": does it actually support threading?
19:00:53FromDiscord<Smarc> Hm it doesn't mention it in the readme, so I don't really know..
19:01:24FromDiscord<dom96> Try to avoid globals if possible
19:02:39FromDiscord<Smarc> sent a code paste, see https://play.nim-lang.org/#ix=3znk
19:02:45FromDiscord<Smarc> So I guess slappy is not suited for threading? Is is there some way around?
19:03:37FromDiscord<Yardanico> try using --gc:orc and wrap the code that errors with a {.cast(gcsafe).} block
19:03:52FromDiscord<Yardanico> sent a code paste, see https://play.nim-lang.org/#ix=3znl
19:04:24FromDiscord<Yardanico> see https://nim-lang.org/docs/manual.html#threads-gc-safety
19:04:53FromDiscord<Smarc> same result unfortunately
19:06:47FromDiscord<Yardanico> can you show the code?
19:07:30FromDiscord<enthus1ast> @Smarc maybe give the thread the path to the audio file to play
19:07:39FromDiscord<Smarc> sent a code paste, see https://play.nim-lang.org/#ix=3znm
19:07:40FromDiscord<Yardanico> nonono
19:07:47FromDiscord<Yardanico> you should put the cast inside the proc
19:08:00FromDiscord<Smarc> oh
19:08:06FromDiscord<Yardanico> and compile with --gc:orc
19:09:26FromDiscord<Smarc> It compiles and runs! Thank you for your help guys :)
19:09:43FromDiscord<Yardanico> just be careful, if you use same global variables from different threads at the same time you need locks
19:10:01FromDiscord<Smarc> Although the random offset does not really work out, since the file are a bunch of clicking-sounds and sometimes it (obviously) just plays the ending noise
19:10:13FromDiscord<Smarc> But I did not find a better way to work with an ogg file
19:10:18FromDiscord<dom96> ORC still isn't gc-safe, right?
19:10:27FromDiscord<Yardanico> In reply to @dom96 "ORC still isn't gc-safe,": it depends on what you mean by that
19:10:37FromDiscord<dom96> I'm wondering whether it's safe to do that cast
19:10:39FromDiscord<Yardanico> current gcsafe analysis is incorrect for gc:orc as you can use global variables in different threads, you just need locking
19:10:39FromDiscord<dom96> with ORC
19:10:55FromDiscord<Yardanico> to not read/write same variable from different threads at the same time
19:11:01FromDiscord<Yardanico> arc/orc have a shared heap
19:11:05FromDiscord<dom96> afaik you still cannot because allocs/deallocs aren't atomic
19:11:14FromDiscord<Yardanico> wdym?
19:11:18FromDiscord<Yardanico> it's a shared heap
19:11:29FromDiscord<dom96> you still need to use alloc0 etc. for shared heap
19:11:33FromDiscord<Yardanico> no
19:11:35FromDiscord<dom96> (edit) "alloc0" => "allocShared"
19:11:43FromDiscord<Yardanico> arc/orc with --threads:on use a shared heap by default
19:11:54FromDiscord<dom96> do you have any sources/docs for this?
19:12:35FromDiscord<Yardanico> https://nim-lang.org/docs/gc.html
19:13:05FromDiscord<Yardanico> it has been thoroughly discussed before in forum threads, and it's one of the advantages of arc/orc over refc
19:13:30FromDiscord<Yardanico> https://forum.nim-lang.org/t/6549
19:13:35FromDiscord<Yardanico> "Offers a shared heap. Enabled via --threads:on."
19:14:33FromDiscord<dom96> right, and then there is: https://forum.nim-lang.org/t/6549#43004
19:15:10FromDiscord<Yardanico> yes, so as I said you need to use locks
19:15:15FromDiscord<Yardanico> if you access the same variable from multiple threads
19:15:28FromDiscord<Yardanico> or atomics of course
19:15:37FromDiscord<dom96> what if Nim decrements the ref count outside my lock?
19:17:11FromDiscord<dom96> also I discussed this earlier today which gave me the message that this isn't safe https://irclogs.nim-lang.org/19-09-2021.html#12:56:36
19:17:29FromDiscord<dom96> CC @Gumber aka Zachary Carter
19:17:36FromDiscord<Yardanico> "but you still have to use locks and other concurrency primitives"
19:17:40FromDiscord<Yardanico> as I said, you have to use locks
19:17:57FromDiscord<Gumber> I mean by nature it's unsafe
19:18:08FromDiscord<Gumber> you can never be certain about what is reading or writing to that memory
19:18:17FromDiscord<Gumber> unless you use concurrency primitives to synchronize those actions
19:18:35FromDiscord<Gumber> you also can't be certain about the order in which code will execute in critical sections a lot of time
19:18:53FromDiscord<Gumber> so yeah - sharing memory between threads without thinking about these things will almost always result in data races or dead locks
19:19:05FromDiscord<Gumber> and just slapping on locks isn't going to help unless you understand what you're doing
19:19:20FromDiscord<Gumber> you need to understand how system threads behave and how they're implemented to some degree along with schedulers
19:19:23FromDiscord<Gumber> on the OS
19:19:33FromDiscord<Gumber> and you need to understand about thread contention etc...
19:19:56FromDiscord<Gumber> so there's a lot to learn - I don't know half of it but you have to start somewhere if you want to eventually understand everything about the topic
19:23:27FromDiscord<dom96> we need an article about this
19:23:40FromDiscord<dom96> and possibly a change to Nim so that it gives clearer warnings
19:23:52FromDiscord<Gumber> it's not a specific Nim thing
19:23:53FromDiscord<Gumber> though
19:24:01FromDiscord<dom96> Like: "This is unsafe under --gc:default, but is fine under --gc:orc"
19:24:03FromDiscord<Gumber> it's any language that has the capability to schedule system threads on the OS
19:24:16FromDiscord<Gumber> sharing memory between threads isn't safe on the default gc either
19:24:17FromDiscord<dom96> yes, but I only worry about this gc safety concept
19:24:19FromDiscord<Gumber> only if you use channels
19:24:22FromDiscord<dom96> which most other languages don't have
19:24:33FromDiscord<Gumber> on the default gc every thread has its own local heap
19:26:11FromDiscord<Gumber> so you allocate memory on the thread heap
19:26:27FromDiscord<Gumber> and then if you want another thread to be able to use it you have to pass it to that thread as a pointer or through a channel
19:26:51FromDiscord<Gumber> and it will be copied if it goes through a channel
19:27:08FromDiscord<Gumber> so if you don't pass a ref or a pointer through the channel
19:27:14FromDiscord<Gumber> it will pass a copy of whatever is in memory there
19:27:18FromDiscord<Gumber> now...
19:27:40FromDiscord<Gumber> the GC knows the ref count on the object went up but it isnt' aware it crossed thread boundaries
19:27:56FromDiscord<Gumber> so you need to think about how that could cause issues
19:28:08FromDiscord<Gumber> another thing is - if you have let's say a separate Nim process that you're loading symbols from
19:28:18FromDiscord<Gumber> let's say you compile your Nim code to a shared library (dll on windows) (so on linux)
19:28:36FromDiscord<Gumber> and you're `dlopen` `dlclose` ing symbols from that library
19:28:42FromDiscord<Gumber> like you might do in let's say a plugin architecture
19:28:53FromDiscord<Gumber> each Nim process is going to have it's own runtime and own GC
19:28:59FromDiscord<Gumber> and they're not going to be aware of one another
19:29:12FromDiscord<dom96> okay, I think I see it more clearly now
19:29:15FromDiscord<Gumber> so you could have them stomping on eachother and collecding memory from eachother
19:29:27FromDiscord<Gumber> to mitigate this - Nim had this flag like `-d:useNimRealtimeRTL` or something
19:29:39FromDiscord<Gumber> and it would prevent this situation from happening - but then half the stdlib wouldn't work
19:29:49FromDiscord<Gumber> so yeah - this is the problem summarized as concisely as I can
19:29:52FromDiscord<dom96> so I think still, with arc/orc you need to be careful. It all depends where Nim adds code to inc/dev ref count
19:29:54FromDiscord<dom96> (edit) "inc/dev" => "inc/dec"
19:30:01FromDiscord<Gumber> if your'e passing GC'd refs yes
19:30:09FromDiscord<Gumber> if you're passing pointers
19:30:13FromDiscord<Gumber> you don't need to worry about it
19:30:22FromDiscord<Gumber> and even with GC'd refs you'll need locks etc
19:30:33FromDiscord<Gumber> unless you use channels
19:30:34FromDiscord<dom96> well, you do because your pointer could be freed from under you
19:30:47FromDiscord<Gumber> I mean you don't need to worry about incrementing any ref count
19:30:58FromDiscord<Gumber> your pointer assuming it's not GC traced won't be freed by the runtime
19:31:02FromDiscord<Gumber> you're responsible for freeing it
19:31:12FromDiscord<Gumber> because you allocated it or something you called did
19:31:26FromDiscord<dom96> That's assuming you alloc it yourself, I thought you meant: pass a pointer to a GC ref
19:31:32FromDiscord<Gumber> well yeah
19:31:38FromDiscord<Gumber> but that's not what I meant by pointer
19:31:41FromDiscord<Gumber> I meant raw pointer
19:31:49FromDiscord<Gumber> with a pointer to a GC ref yes you still have to inc and dec ref counts
19:31:58FromDiscord<Gumber> and it gets tricky because when you start nesting objects
19:32:09FromDiscord<Gumber> you need to think about that too
19:32:18FromDiscord<Gumber> IMO unless the runtime has a way to generate all that stuff for you
19:32:21FromDiscord<Gumber> it's way easier to just use pointers
19:32:26FromDiscord<Gumber> and alloc the memory yourself
19:32:31FromDiscord<Gumber> way less of a headache
19:32:31FromDiscord<dom96> right, just forget about pointers
19:32:38FromDiscord<dom96> and any other unsafe Nim features
19:32:42FromDiscord<Gumber> I mean I use them constantly so
19:32:52FromDiscord<Gumber> but I also know what I'm doing 😉
19:32:58FromDiscord<Gumber> most of the time anyway
19:33:14FromDiscord<dom96> if I have a global ref in ARC/ORC then I need to make sure any thread touching it has a lock around it
19:33:24FromDiscord<Gumber> no not necessarily
19:33:51FromDiscord<Gumber> if things are just reading from memory and the underlying memory isn't being touched by any other thread
19:33:55FromDiscord<Gumber> then a lock would just cause issues
19:33:59FromDiscord<Gumber> and contention around the reads
19:34:17FromDiscord<Gumber> see this is why multithreaded programming is hard
19:34:25FromDiscord<Gumber> it's not like a pattern you can just apply everywhere
19:34:27FromDiscord<Gumber> or a few patterns
19:34:43FromDiscord<Gumber> it's like every situation where you want to toss threads at a problem - you really need to think deeply about what's happening at the system level
19:35:00FromDiscord<Gumber> and if you dont' grokk that you're probably not going to be using threads very sucessfully
19:35:09FromDiscord<Gumber> (edit) "dont' grokk" => "don't grok"
19:35:10FromDiscord<dom96> even if you're just reading you're still changing the ref count though afaik
19:35:18FromDiscord<dom96> so you will need a lock
19:35:34FromDiscord<dom96> I don't have a clear idea of when exactly ref counts change though
19:35:40FromDiscord<Gumber> okay in the case where we have a reference counting gc yes
19:35:57FromDiscord<Gumber> and now you're basically doing atomic reference counting
19:36:06FromDiscord<Gumber> 🙂
19:36:53FromDiscord<Gumber> just instead of synchronizing the ref count mutation with a lock
19:36:57FromDiscord<Gumber> you use an atomic
19:37:08FromDiscord<dom96> yeah, and this is imo the source of the unsafety
19:37:11FromDiscord<Gumber> and that gets really really hariy because atomics are implemented with different builtins
19:37:17FromDiscord<dom96> (edit) "imo" => "afaik"
19:37:31FromDiscord<dom96> arc/orc really should support atomic ref counts
19:37:32FromDiscord<Gumber> it's not the source of the unsafety
19:37:36FromDiscord<Gumber> no it shouldn't
19:37:38FromDiscord<Gumber> because it's slow
19:37:41FromDiscord<Gumber> you can add it if you want
19:37:50FromDiscord<Gumber> but I don't want it - I have zero desire for atomic ref counting
19:38:00FromDiscord<Gumber> and would immediately stop game programming with nim it it were added and made mandatory
19:38:13FromDiscord<Gumber> I'd stop using Nim alltogether
19:38:24FromDiscord<Gumber> (edit) "alltogether" => "all together"
19:38:24FromDiscord<dom96> it doesn't necessarily have to be forced on every ref, I'm sure there are some approaches that only apply it to shared memory
19:38:29FromDiscord<Gumber> no
19:38:33FromDiscord<Gumber> I don't want it on any shared memory lol
19:38:39FromDiscord<Gumber> I want control
19:38:44FromDiscord<dom96> well then you can use pointers
19:38:48FromDiscord<Gumber> I dont' want the runtime doing things for me that I don't have say over
19:39:05FromDiscord<Gumber> look arc is useful already without atomic ref counting
19:39:07FromDiscord<Gumber> I say that if youwa nt it
19:39:13FromDiscord<Gumber> add it in via a macro or someting
19:39:16FromDiscord<Gumber> or something in userland
19:39:21FromDiscord<Gumber> don't add it into the language and compiler
19:39:35FromDiscord<Gumber> that's where apple fucked up with Swift
19:39:41FromDiscord<Gumber> well one place anyway
19:39:51FromDiscord<Gumber> also if we just wanted atomic reference counting
19:39:57FromDiscord<Gumber> araq wouldn't have had to spend years figuring out ARC / ORC
19:40:14FromDiscord<dom96> IMO this sort of thing is what makes threading in Nim more complex than in other languages
19:40:22FromDiscord<Gumber> it's not more complex though in other languages
19:40:28FromDiscord<Gumber> other languages just have different concurrency model
19:40:31FromDiscord<Gumber> s
19:40:33FromDiscord<Gumber> Nim isn't trying to win that game and never has
19:40:40FromDiscord<Gumber> Nim isn't pony or erlang
19:40:45FromDiscord<Gumber> and I'm glad for it
19:40:52FromDiscord<Gumber> Nim is like a swiss army knife
19:41:11FromDiscord<Gumber> you start making mandates on the runtime like that and you're going to lose a lot of users and contributors
19:41:23FromDiscord<Gumber> atomic ref counting was avoided exactly because it's slow
19:41:40FromDiscord<Gumber> and araq saw what happened with swift as it was happening
19:41:48FromDiscord<Gumber> you can still achieve memory safety with Nim and ARC/ORC now with threads
19:41:57FromDiscord<Gumber> you just have to use channels
19:42:10FromDiscord<Gumber> or you have to write your program in a way that there are no shared reads or writes
19:42:19FromDiscord<Gumber> so everything is moved / sunk
19:42:31FromDiscord<dom96> I'm fairly sure shared reads/writes is what most programmers expect to be easy
19:42:33FromDiscord<Gumber> it's not like there's no way to achieve gc safety you just have to work at it and it's not necessarily easy
19:42:37FromDiscord<dom96> Right now it isn't easy in Nim and hasn't been ever
19:42:39FromDiscord<Gumber> they are
19:42:43FromDiscord<Gumber> but not when it comes to multithreading
19:42:47FromDiscord<dom96> This is what we need to solve
19:42:51FromDiscord<Gumber> try to write a multithreaded program in C or C++ or Java
19:42:54FromDiscord<Gumber> we don't need to
19:42:56FromDiscord<Gumber> you might need to
19:43:00FromDiscord<Gumber> but a lot of us don't
19:43:15FromDiscord<Gumber> a lot of us I think are perfectly happy with the concurrency scene in Nim right now
19:43:20FromDiscord<dom96> Really?
19:43:21FromDiscord<Gumber> minus the stdlib features not being there
19:43:26FromDiscord<Gumber> as far as the building blocks go? yes
19:43:27FromDiscord<dom96> I feel like everybody is unhappy with it
19:43:29FromDiscord<Gumber> continuation sare very nice
19:43:32FromDiscord<Gumber> (edit) "continuation sare" => "continuations are"
19:43:41FromDiscord<Gumber> I'm not saying the threadpool and spawn and parallel and async are good
19:43:42FromDiscord<Gumber> they're not
19:43:52FromDiscord<Gumber> but that's not because the langauge capabiltieis aren't there to make them good
19:43:53FromDiscord<Gumber> they are
19:43:55FromDiscord<Gumber> just the implementations are bad
19:44:02FromDiscord<dom96> Well I disagree
19:44:06FromDiscord<Gumber> and I'm not trivializing how hard it is to do those things
19:44:12FromDiscord<Gumber> and make good implementations
19:44:16FromDiscord<dom96> The language needs to be better here
19:44:41FromDiscord<Gumber> well I would fight you tooth and nail on a RFC to make atomic ref counting mandatory for the nim runtime
19:44:55FromDiscord<Gumber> and if it happened (which it wouldn't) like I said, the community would be down one member
19:44:56FromDiscord<dom96> I'm not saying that is the solution, just one of many
19:45:10FromDiscord<Gumber> again I don't think there needs to b ea solution
19:45:14FromDiscord<Gumber> delivered by the language
19:45:23FromDiscord<Gumber> and if ther eis one
19:45:25FromDiscord<dom96> Then what do you think needs to be here?
19:45:26FromDiscord<Gumber> it better be opt-in
19:45:41FromDiscord<Gumber> a better implementation of threadpool, spawn, parallel and async
19:45:56FromDiscord<Gumber> maybe not a better implementation of async
19:46:15FromDiscord<Gumber> but maybe some convenience / sugar / renaming to make it more ergonomic and not as confusing
19:46:40FromDiscord<Gumber> asyncdispatch has always been really really confusing to new folks
19:47:49FromDiscord<dom96> better spawn/threadpool won't solve the memory sharing ergonomics
19:47:53FromDiscord<dom96> I believe that needs to improve
19:47:55FromDiscord<Gumber> no but one that works would be nice
19:48:02FromDiscord<dom96> async ergonomics too, stack traces need to be improved a lot
19:48:10FromDiscord<Gumber> I mean look - no one has figured out a magic way to share memory betwene threads in any language
19:48:14FromDiscord<Gumber> that doesn't have a huge runtime cost
19:48:22FromDiscord<Gumber> you're basically saying - I'm going to trade memory safety for a big runtime cost
19:48:28FromDiscord<dom96> I don't mind _some_ runtime cost
19:48:31FromDiscord<Gumber> and make that decision for every user of the language
19:48:32FromDiscord<Gumber> YOU don't
19:48:36FromDiscord<Gumber> but YOU don't own Nim lol
19:48:47FromDiscord<dom96> yeah, I can say the same to YOU 🙂
19:48:52FromDiscord<Gumber> there are a lot of people that write embedded and realtime applications with Nim
19:49:04FromDiscord<dom96> But really it comes down to how big this runtime cost is
19:49:05FromDiscord<Gumber> they're not all going to want some new runtime change like atomic ref counting forced on them
19:49:07FromDiscord<dom96> everything is a tradeoff
19:49:19FromDiscord<Gumber> yeah but you do realize that when people are writing system level stuff
19:49:28FromDiscord<Gumber> and again Nim is billed as "a systems level programming lanaguage"
19:49:34FromDiscord<Gumber> they don't always care about everything being safe
19:49:39FromDiscord<Gumber> if they did - they'd go use Rust
19:49:44FromDiscord<Gumber> and deal with that horseshitg
19:49:48FromDiscord<Gumber> if you want Rust go use Rust lol
19:49:53FromDiscord<Gumber> or Swift
19:49:56FromDiscord<Gumber> I mean - I don't know what to tell you
19:50:13FromDiscord<Gumber> like you're just forgetting about a huge portion of Nim's community
19:50:17FromDiscord<Gumber> and arguably Nim's most advanced users
19:50:27FromDiscord<Gumber> in terms of technical and computing knowledge
19:50:58FromDiscord<Gumber> and you're also talking about a change that would probably break tons of existing code
19:51:10FromDiscord<Gumber> which is why a userland solution is the best
19:51:12FromDiscord<dom96> I think you're reading too much into what I'm saying
19:51:15FromDiscord<Gumber> I'm not
19:51:26FromDiscord<dom96> It's not like me saying this stuff will change anything
19:51:26FromDiscord<Gumber> you're talking about changing the default algorithm for the gc
19:51:30FromDiscord<Gumber> I know it won't
19:51:41FromDiscord<Gumber> but I'm trying to explain to you why the idea is problematic
19:51:44FromDiscord<dom96> and I'm not even saying it should be done
19:51:54FromDiscord<dom96> I don't know what the right approach is
19:51:56FromDiscord<Gumber> you're saying Nim needs something to improve the concurrency situation
19:52:02FromDiscord<Gumber> but I"m saying I don't think Nim needs to change
19:52:09FromDiscord<Gumber> someone needs to write a library or something
19:52:29FromDiscord<Gumber> figure out how to automate the atomic ref counts
19:52:36FromDiscord<Gumber> like patch the compiler or something
19:52:41FromDiscord<Gumber> and make it opt-in only
19:52:43FromDiscord<Gumber> that'd be fine
19:52:53FromDiscord<dom96> At the very least Nim does need to change how it communicates GC safety issues
19:52:56FromDiscord<Gumber> but I imagine you'd get a ton of push back if you tried to mainline it
19:53:14FromDiscord<Gumber> well yeah - and I think there's probably a lot of effort that's already gone into that
19:53:29FromDiscord<Gumber> I think the whole like verification tool dr nim or whatever was kind of working towards that goal
19:53:35FromDiscord<Gumber> static verification tool rather
19:53:43FromDiscord<Gumber> but I'm not sure where it ended up
19:54:01FromDiscord<Gumber> I think something like that would be way more beneficial than ARC/ORC
19:54:11FromDiscord<Gumber> err sorry
19:54:13FromDiscord<Gumber> I mean atomic ref counting
19:54:28FromDiscord<Gumber> something where it can just analyze your program at compile time and be like
19:54:31FromDiscord<Gumber> you have a potential data race here
19:54:47FromDiscord<Gumber> but that's really difficult to do too
19:54:52FromDiscord<Gumber> and I'm sure you can imagine why
20:14:28FromDiscord<QueenFuckingAdrielle> is there proper naming convention for .nim files? snake case, camel case, capitalized... etc
20:14:40FromDiscord<Yardanico> yes
20:14:47FromDiscord<QueenFuckingAdrielle> i found the style guide but i didnt see anything about file names unless im just blind
20:15:14FromDiscord<Yardanico> well generally you either use short single words or snake_case
20:15:23FromDiscord<Yardanico> but no one's stopping you from using camelCase if you want
20:15:32FromDiscord<QueenFuckingAdrielle> okay cool, ive been doing snake case
20:15:34FromDiscord<Yardanico> you can use any name as long as it's a valid nim identifier
20:16:22ehmrysnake case is nice for those that are still using DOS
20:20:09FromDiscord<Gumber> I tend to follow C style conventions when programming in Nim
20:20:14FromDiscord<Gumber> it's difficult though
20:20:19FromDiscord<Gumber> because of Nim's handling of underscores
20:20:24FromDiscord<Gumber> or lacktherof I guess
20:20:47FromDiscord<Gumber> lately I've been migrating to using C++ style mixed with some functional brevity that Nim has which is nice
20:20:51FromDiscord<Gumber> like omitting parens etc
20:20:59FromDiscord<Gumber> I think the most important thing is you should decide on a style and stick to it
20:21:06FromDiscord<Gumber> because Nim has a lot of options for how you can style your code
20:21:20FromDiscord<Gumber> and if you're not consistent you end up with a codebase that isn't at all uniform and looks like it was written while someone was high
20:21:34FromDiscord<QueenFuckingAdrielle> lol
20:21:57FromDiscord<QueenFuckingAdrielle> yea, ive been torn on my programming paradigms as well
20:22:53FromDiscord<QueenFuckingAdrielle> there are so many ways to code with nim, I love it, but now that i have more freedom with it I have to ask myself what i think is good form
20:23:18FromDiscord<Gumber> yeah like I think it all boils down to your personal preferences and wha tother language you program in
20:23:26FromDiscord<Gumber> I came from Java and hated object oriented programming after it
20:23:33FromDiscord<Gumber> I wanted to learn C/C++ so I used Nim kind of as a brdige
20:23:33FromDiscord<QueenFuckingAdrielle> yea i hate oop as well
20:23:35FromDiscord<Gumber> bridge
20:23:41FromDiscord<Gumber> once I learned C I started to code my Nim like I wrote my C
20:23:47FromDiscord<QueenFuckingAdrielle> ah gotcha
20:23:49FromDiscord<Gumber> and now that I interop mostly with C++ and a mix of C
20:24:05FromDiscord<Gumber> I've started adopting C++ style conventions just because it's a bit more idiomatic I feel like given the rest of the Nim community
20:24:26FromDiscord<Gumber> everyone likes the universal function call syntax
20:24:32FromDiscord<QueenFuckingAdrielle> I went java (school only) - > python -> c -> cython -> nim
20:24:35FromDiscord<Gumber> so instead of like the C style where you go like
20:24:48FromDiscord<Gumber> `function(object_function_belongs_to, param_one, param_two);`
20:24:56FromDiscord<Gumber> Nim can also do
20:25:07FromDiscord<Gumber> `object_function_belongs_to.function(param_one, param_two);`
20:25:12FromDiscord<Gumber> like C++ and other OOP languages
20:25:21FromDiscord<Gumber> both are equivalent
20:25:24FromDiscord<QueenFuckingAdrielle> ah gotcha, i def prefer the first
20:25:30FromDiscord<Gumber> I did for a long time too
20:25:37FromDiscord<Gumber> when it comes to naming constants for instance
20:25:54FromDiscord<Gumber> like in C world you see `const int MY_CONSTANT = 1`
20:26:05FromDiscord<QueenFuckingAdrielle> i like objects and functions to be separate, with very simple object types
20:26:07FromDiscord<Gumber> and you will see people declare consts like that in Nim
20:26:30FromDiscord<Gumber> but a lot of people just use `const MyConstant = 1` or `const myConstant = 1`
20:26:42FromDiscord<Gumber> there's no real consistent standard across the community - it's all just individual preference
20:26:45FromDiscord<Gumber> but the important thing is to be consistent
20:26:58FromDiscord<Gumber> and using a tool like nimpretty can at least help with enforcing spacing and things like that
20:27:07FromDiscord<QueenFuckingAdrielle> i think thats good, brings out more innovation.
20:27:12FromDiscord<Gumber> also - just like a protip and something that I think everyone eventually ends up doing
20:27:18FromDiscord<Gumber> don't use four spaces to indent use two
20:27:22FromDiscord<Gumber> and obviously no tabs
20:27:25FromDiscord<Gumber> tabs and Nim don't mix
20:27:28FromDiscord<QueenFuckingAdrielle> yea i use 2 spaces
20:27:39FromDiscord<QueenFuckingAdrielle> i love that about nim
20:27:41FromDiscord<Gumber> some people use four and it's maddening
20:27:49FromDiscord<dom96> In reply to @Gumber "some people use four": yessss
20:27:51FromDiscord<Gumber> like - why do you want so much extra whitespace for your eyes to have to gloss over
20:27:53FromDiscord<QueenFuckingAdrielle> lol yea i think it looks cruddy
20:27:58FromDiscord<Gumber> it's just more strain on the eyes I think
20:28:06FromDiscord<Gumber> if you read from right to left anyway
20:28:11FromDiscord<Gumber> errr
20:28:12FromDiscord<Gumber> left to right sorry
20:28:14FromDiscord<QueenFuckingAdrielle> lol
20:28:16FromDiscord<QueenFuckingAdrielle> yea
20:28:17FromDiscord<Gumber> brain got confused for a sec
20:28:55FromDiscord<QueenFuckingAdrielle> ive been putting off figure out how to use cuda kernels and opencl in this project for the longest time
20:29:03FromDiscord<Gumber> ooph sounds not fun
20:29:03FromDiscord<QueenFuckingAdrielle> ill have to deal with it soon enough haha
20:29:16FromDiscord<Gumber> I'm glad I don't have to mess with CUDA as a game programmer
20:29:23FromDiscord<Gumber> I mean I guess i could if I really wanted to experience pain in life
20:29:28FromDiscord<Gumber> like there are certainly appliactions
20:29:32FromDiscord<Gumber> I could invent or find
20:29:38FromDiscord<QueenFuckingAdrielle> yea, you guys get to have fun with vulkan 😛 jk
20:29:41FromDiscord<Gumber> but it's by no means necessary
20:30:03FromDiscord<Gumber> yeah I'm actually like growing a gray hair right as I type this because of Vulkan and how many gd layers of C and C++ I"m calling in and out of from my nNim code
20:30:08FromDiscord<QueenFuckingAdrielle> i tried learning vulkan and it was the hardest package/api ive ever tried. I just gave up lol
20:30:40FromDiscord<Gumber> I use Vuklan in combination with https://github.com/charles-lunarg/vk-bootstrap and https://github.com/martty/vuk
20:30:55FromDiscord<QueenFuckingAdrielle> i have an indie game I'm working on but its engine based
20:30:58FromDiscord<Gumber> and `vuk` uses a bunch of ther libraries like `spirv-cross` and `shaderc` and `vulkan-memory-allocator` etc...
20:31:05FromDiscord<Gumber> yeah I write / roll all my own tech
20:31:09FromDiscord<Gumber> I mean to a certain point
20:31:12FromDiscord<QueenFuckingAdrielle> nice
20:31:31FromDiscord<Gumber> but I've been doing this for close to sixteen years at this point so....
20:31:33FromDiscord<QueenFuckingAdrielle> im primarily an hpc/deeplearning person
20:31:39FromDiscord<Gumber> ah cool
20:31:47FromDiscord<Gumber> there are some other folks in Nim that are really into that stuff
20:31:55FromDiscord<Gumber> should check out the #science community channel
20:32:00FromDiscord<Gumber> I think those nerds hang out in there
20:32:02FromDiscord<Gumber> (just kidding)
20:32:03*def- quit (Quit: -)
20:32:08FromDiscord<QueenFuckingAdrielle> yea ive met a few, this is a very cool community for it
20:32:09FromDiscord<QueenFuckingAdrielle> lol
20:32:13*def- joined #nim
20:32:25FromDiscord<Gumber> yeah - I've been an active member of the Nim community since like 2015?
20:32:28FromDiscord<Gumber> maybe the tail end of 2014
20:32:33FromDiscord<Gumber> some good people here
20:32:34FromDiscord<Gumber> for sure
20:32:43FromDiscord<Gumber> some really smart one stoo
20:32:53FromDiscord<Gumber> like they will make your head hurt smart
20:32:56FromDiscord<QueenFuckingAdrielle> ive been working on a robotics framework in nim+c+python for like 3 years now
20:33:03FromDiscord<Gumber> (edit) "one stoo" => "ones too"
20:33:11FromDiscord<Gumber> sounds neat
20:33:17FromDiscord<Gumber> yeah Nim is great for embedded stuff too
20:33:29FromDiscord<Gumber> got a whole IoT scene in one channel I think
20:33:30FromDiscord<QueenFuckingAdrielle> yea I had to take a break for some other research consulting i was doing
20:33:38FromDiscord<Gumber> oh yeah - #embedded haha
20:33:43FromDiscord<Gumber> gotcha
20:33:52FromDiscord<QueenFuckingAdrielle> mainly deeplearning+covid research
20:33:56FromDiscord<Gumber> yeah I wish I was more into robotics and FGPAs and deep learning and stuff like that
20:34:07FromDiscord<Gumber> it's just like not enough time in the universe for me to do everything I want / am interested in exploring
20:34:13FromDiscord<Gumber> and games are challenging enough
20:34:16FromDiscord<QueenFuckingAdrielle> yea i hear you lol
20:34:21FromDiscord<Gumber> oh covid research huh?
20:34:23FromDiscord<QueenFuckingAdrielle> i have a million hobbies
20:34:24FromDiscord<Gumber> should have talked to me last week
20:34:26FromDiscord<QueenFuckingAdrielle> yea
20:34:29FromDiscord<Gumber> I would have been a great source of information
20:34:31FromDiscord<Gumber> or data
20:34:39FromDiscord<QueenFuckingAdrielle> ugh oh lol
20:34:44FromDiscord<QueenFuckingAdrielle> how are you doing now?
20:34:45FromDiscord<Gumber> can talk to my wife right now if you want lol
20:34:47FromDiscord<Gumber> she' sin bed with it
20:34:54FromDiscord<Gumber> I'm fine - have some weird ass lingering leftover symptoms
20:35:05FromDiscord<QueenFuckingAdrielle> yea my gf and i both caught it at the same time about a year ago
20:35:08FromDiscord<Gumber> like I feel like my blood pressure is elevated a bit and I have some weird GI issues
20:35:19FromDiscord<Gumber> like I feel bloated all the time
20:35:22FromDiscord<QueenFuckingAdrielle> yep i remember that, screw that
20:35:25FromDiscord<Gumber> but other than that I'm good - there was one day that was scary
20:35:42FromDiscord<Gumber> but I did it to myself - I had a really bad post nasal drip and a dry cough so like not productive at all
20:35:53FromDiscord<Gumber> I woke up and took some dayquick - that was mistake number one
20:36:06FromDiscord<Gumber> the cough supressant made it so I couldn't cough up anything, so my chest was just filling up with mucus
20:36:13FromDiscord<QueenFuckingAdrielle> oh god
20:36:16FromDiscord<Gumber> then when that was wearing off I was like - I need an expectorant
20:36:18FromDiscord<Gumber> some mucienx
20:36:38FromDiscord<Gumber> so I go to the store - parents call me to ask how I"m doing, tell them I'm getting mucinex and they're like oh make sure you get the dm stuff it will help out so much
20:36:48FromDiscord<Gumber> don't really look at it too much get some mucinex DM from the drive through pharmacy thing
20:36:51FromDiscord<Gumber> take that
20:37:00FromDiscord<Gumber> for like an hour or so I can coughs tuff up and life is okay again
20:37:02FromDiscord<mratsim> where am I :?
20:37:06FromDiscord<QueenFuckingAdrielle> yea i stayed away from cough/cold medicine when i had it
20:37:09FromDiscord<Yardanico> is this #main ? 🤔
20:37:10FromDiscord<QueenFuckingAdrielle> lol
20:37:13FromDiscord<Yardanico> i thought it was #covid-discussion
20:37:14FromDiscord<Gumber> but then it starts happening again and I slowly realize I took cough suppressant AGAIN
20:37:19FromDiscord<QueenFuckingAdrielle> lol
20:37:20FromDiscord<Gumber> well we WERE talking about Nim
20:37:22FromDiscord<Gumber> we were the only ones
20:37:28FromDiscord<Gumber> now it's off topic an deveryone wants to have a fit
20:37:37FromDiscord<Yardanico> but you know, if you do a lot of offtopic #offtopic might be better suited
20:37:47FromDiscord<Gumber> you guys are like fair weather admmins / mods
20:37:55FromDiscord<QueenFuckingAdrielle> lol
20:37:57FromDiscord<Gumber> and I'm a mod
20:38:06FromDiscord<Gumber> you made me one!
20:38:21FromDiscord<QueenFuckingAdrielle> I'm just weird goth chick
20:38:24FromDiscord<Gumber> but anyway yeah - long story short (not really) don't take cough supressant if you can't cough stuff up and have covid
20:38:28FromDiscord<QueenFuckingAdrielle> i dont live here
20:38:47FromDiscord<Gumber> and Nim discussion can resume - because I'm going outside to finish mowing the lawn
20:39:01FromDiscord<QueenFuckingAdrielle> good talking tho, catch ya later
20:57:25nrds<Prestige99> Hey @Elegantbeef would you be available to voice chat some point today? Messing around with another implementation of the animation code, would like to poke your brain
20:58:03FromDiscord<Gumber> In reply to @nrds "<Prestige> Hey <@145405730571288577> would": sounds hot
20:58:05FromDiscord<Elegantbeef> Probably
20:58:10FromDiscord<Gumber> I'm kidding, I'm kidding....
20:58:13nrds<Prestige99> Lol
20:58:27FromDiscord<Gumber> I'm a 12 year old trapped in a 36 year old body
20:58:29FromDiscord<Gumber> I apologize
20:58:29FromDiscord<Elegantbeef> We were only going to have a steamy shower with webcams, you'd probably like it
20:58:46nrds<Prestige99> I thought we were doing a hottub stream this time
20:58:56FromDiscord<Elegantbeef> That's next week
20:59:03FromDiscord<Gumber> patience is a virtue
20:59:40FromDiscord<SivadNai> if you can afford to wait
21:01:06FromDiscord<Gumber> next week is the most difficult week of my life
21:01:21FromDiscord<Gumber> also I think I won this thread - https://forum.nim-lang.org/t/8440
21:01:27FromDiscord<Gumber> I'm (carterza)
21:01:55FromDiscord<SivadNai> what does the @ char mean in Nim? (sorry to talk code)
21:02:11FromDiscord<Gumber> it's an operator take an array and create a sequence from it
21:02:28FromDiscord<Gumber> but I mean you could overload it to do whatever you wanted
21:02:41FromDiscord<Gumber> though that's what it's implementation provides by default in the stdlib
21:02:46FromDiscord<haxscramper> `typeof([1,2,3]) is array[3, int]`, `typeof(@[1,2,3]) is seq[int])`
21:03:06FromDiscord<Elegantbeef> `@` is just an operator it can do anything but unary on array turns into seq
21:03:27FromDiscord<SivadNai> okay that makes sense, I was looking at a CLR example in winim with @ Process
21:04:43FromDiscord<SivadNai> I've only seen it with seq before, clearly haven't coded enough
21:04:44*Vladar quit (Quit: Leaving)
21:08:23FromDiscord<Elegantbeef> @dain\: i did add the smart module/type level stuff for use if interested https://play.nim-lang.org/#ix=3znM
21:10:50FromDiscord<dain> thanks
21:11:13FromDiscord<dain> you should write that up somewhere, it seems to be quite obscure
21:11:50FromDiscord<Elegantbeef> Yea i really should make some more written tutorials for macros
21:12:02FromDiscord<Elegantbeef> Or even a vidja
21:14:21FromDiscord<dain> yeah i'm making some notes for how you port the python with statement using a macro
21:14:42FromDiscord<dain> i know there are forum posts about that already but im trying to match python's semantics more closely, and also extend it to do more things
21:14:45FromDiscord<dain> like have a return value
21:15:50FromDiscord<dain> for macros there needs to be more stuff in the topright quadrant from here https://documentation.divio.com/
21:15:58FromDiscord<Elegantbeef> With the use macro one major issue is that nim has an implicit `result` variable so to have a return value with use requires some fancy logic to not have to use return everywhere
21:16:27FromDiscord<Elegantbeef> I agree and i'm probably one of the people to do it given the amount of macros i throw out for people in here 😛
21:17:53FromDiscord<dain> i really like this post and i think there need to be more like it https://nim-lang.org/blog/2021/03/10/fusion-and-pattern-matching.html
21:18:11FromDiscord<dain> except that one is waaay complicated and is also explaining two things at once (pattern matching and macros)
21:18:21FromDiscord<Elegantbeef> Yea all i've got is https://dev.to/beef331/demystification-of-macros-in-nim-13n8
21:18:36FromDiscord<dain> i think it would be good to have a series of posts that are like: here is a feature from language X, and this is how you port it to nim
21:18:48FromDiscord<Elegantbeef> I could do as such
21:18:51FromDiscord<dain> they don't have to be complicated either, it could just be a 4 line template
21:18:56FromDiscord<Elegantbeef> Can you get me a list of features? 😛
21:19:19FromDiscord<dain> ha, well there's the with statement like I said
21:20:08FromDiscord<dain> sent a code paste, see https://play.nim-lang.org/#ix=3znN
21:20:47FromDiscord<Elegantbeef> Was super confused about that case statement for a good second or two 😛
21:20:55FromDiscord<Elegantbeef> You're using matching
21:21:04FromDiscord<dain> yeah
21:21:15FromDiscord<dain> it's easier than wrangling the AST directly
21:22:38FromDiscord<dain> oh also i didn't see an explanation for what gensym is and why you'd use it in the official macro tutorial. would be good to have that explained somewhere
21:22:42FromDiscord<dain> since it's pretty important
21:26:43FromDiscord<Elegantbeef> I'm a simple man
21:26:43FromDiscord<Elegantbeef> Hax i think it's also a writeup of how to do/reason about things
21:26:44FromDiscord<haxscramper> I think I have some other examples
21:26:44FromDiscord<Elegantbeef> Examples of macros are plentiful but why/how is rather limited
21:26:45FromDiscord<haxscramper> If you need some examples↵● elixir-style pattern overloading, https://play.nim-lang.org/#ix=2RnU↵● matching based on ast expressions, https://play.nim-lang.org/#ix=3tBr
21:26:46FromDiscord<haxscramper> Yes, but coming up with idea of what to write about can be challenging
21:26:46FromDiscord<Elegantbeef> I dont disagree
21:26:46FromDiscord<haxscramper> Well, I just dumped links, don't expect me to aactually think about problem at hand
21:26:46FromDiscord<haxscramper> I'm like 0.01% brainpower mode right now
21:26:48FromDiscord<haxscramper> C++ is slowly pushing me out of the "generally sane" area
21:30:47FromDiscord<dain> ya these need to be written up somewhere for ppl to find
21:30:47FromDiscord<leorize> I think there is some docs for gensym in macros but I agree, it doesn't say anything about why you would want it
21:31:01FromDiscord<dain> like a "nim macros cookbook" or something
21:34:31*max22- quit (Quit: Leaving)
22:42:15nrds<Prestige99> Elegantbeef: The point I'm stuck at here (error I'm not sure what it means) https://play.nim-lang.org/#ix=3zo3 - I also was trying out openArray instead of seq but I think that was causing another prob
22:42:18nrds<Prestige99> if you have any insight
22:42:39nrds<Prestige99> (I'm probably overlooking something)
22:44:19FromDiscord<Elegantbeef> You're not properly binding `SomeNumber`
22:44:24FromDiscord<leorize> `T: SomeNumber` instead of repeating it please \:p
22:44:38nrds<Prestige99> I tried that as well, had the same error iirc
22:45:36FromDiscord<Elegantbeef> I swear i'm going to come to your house and burn your PC if you use a named tuple
22:45:49nrds<Prestige99> Lol why? It's easier to type
22:46:11FromDiscord<Elegantbeef> Here you go anyway
22:46:12FromDiscord<Elegantbeef> https://play.nim-lang.org/#ix=3zo4
22:46:27FromDiscord<Elegantbeef> I dont like named tuples since they're just aliases and not technically type safe
22:50:03FromDiscord<Elegantbeef> Also what's the point of exporting `sample`
22:50:04FromDiscord<Elegantbeef> It cannot be accessed as you do not inject it
22:51:35FromDiscord<Elegantbeef> As such you might as well do https://play.nim-lang.org/#ix=3zo7
22:54:04FromDiscord<Elegantbeef> I still dont get why people write proc/template defs like that if there arent many args just hard to read to me
22:56:06nrds<Prestige99> oh the issue was sample had a generic
22:56:36FromDiscord<Elegantbeef> More you used `T` for sample
22:56:41FromDiscord<Elegantbeef> Or... not \:P
22:57:20FromDiscord<Elegantbeef> Yea it was you used `SomeNumber` which was the same as the one above
22:57:37nrds<Prestige99> the generic for sample had to be removed yeah
22:57:53FromDiscord<Elegantbeef> No it didnt need to be removed you needed to bind a different symbol
22:58:27FromDiscord<Elegantbeef> Do to you using `[SomeNumber]` you caused some fucking binding logic
22:58:38nrds<Prestige99> I mean that was the reason why it wasn't compiling
22:58:57nrds<Prestige99> I was doing T: SomeNumber previously but had the same issue, just didn't know why
22:59:12FromDiscord<Elegantbeef> Well it's not due to the generic
22:59:29FromDiscord<Elegantbeef> It's due template binding + your odd binding
22:59:36FromDiscord<Elegantbeef> https://play.nim-lang.org/#ix=3zo8 works for instance
23:00:17FromDiscord<Elegantbeef> It was using `SomeNumber` as a generic name not a type constraint
23:00:49FromDiscord<Elegantbeef> As such `sample[SomeNumber]` was getting a type instead of a generic name/constraint
23:01:09FromDiscord<Elegantbeef> Remember generic parameters arent special they're identifiers like anything else can be any number of letters
23:01:14nrds<Prestige99> Yeah ik
23:01:25nrds<Prestige99> just saying i didnt see it, but that was the issue
23:01:38FromDiscord<Elegantbeef> So then why the fuck were you using SomeNumber as a generic parameter name 😛
23:01:56nrds<Prestige99> unintentional, I was using T: SomeNumber previously
23:02:58nrds<Prestige99> was shifting things around trying to debug
23:03:24FromDiscord<Elegantbeef> Well my proclivities aside it works now so i'll shush and quit jokingly belittling you
23:04:45nrds<Prestige99> thanks for the help, just didn't know where to look cuz the error message was useless
23:05:07FromDiscord<Elegantbeef> Well it's 100% accurate, but yea
23:05:18FromDiscord<Elegantbeef> Doesnt give much information
23:06:17nrds<Prestige99> or a location
23:07:09FromDiscord<Elegantbeef> The issue is on expansion i figure so the error line is the line the template is called on i think
23:07:52FromDiscord<Elegantbeef> Cause until instantiation `SomeNumber` is just a generic param, but on instantiation it's a type i believe
23:15:33FromDiscord<Elegantbeef> Looking sadly it seems there isnt presently any extra information there to really grab
23:48:38*rockcavera joined #nim
23:48:39*rockcavera quit (Changing host)
23:48:39*rockcavera joined #nim