<< 01-02-2021 >>
00:04:07ForumUpdaterBotNew thread by Domino: Help with macros needed: Creating an if-else statement on runtime., see https://forum.nim-lang.org/t/7456
00:17:25*Gustavo6046 joined #nim
00:23:25*Gustavo6046 quit (Ping timeout: 240 seconds)
00:27:30*Gustavo6046 joined #nim
00:27:59*hmmm quit (Quit: WeeChat 3.0)
00:39:23*krux02 quit (Remote host closed the connection)
00:55:47*Tlangir joined #nim
00:57:21*abm quit (Read error: Connection reset by peer)
00:59:25*Tanger quit (Ping timeout: 240 seconds)
01:02:00*njoseph quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
01:02:25*njoseph joined #nim
01:14:29FromDiscord<iWonderAboutTuatara> Did disruptek get banned?
01:14:40FromDiscord<ElegantBeef> Yes
01:15:16FromDiscord<iWonderAboutTuatara> Oh
01:41:12Prestige:(
02:53:20FromDiscord<ElegantBeef> No clue if you're around pmunch, but since i know you have `strslice` thought you'd might be interested in my toy strutils implementation that uses views 😄 https://github.com/beef331/strviewutils
02:53:41PrestigeHe's offline
02:54:05FromDiscord<ElegantBeef> shame
02:54:07Prestigevery cool though beef
02:54:54PrestigeGoing to make a PR eventually?
02:55:03FromDiscord<ElegantBeef> nah views are buggy
02:55:12Prestigeoh, haha
02:59:36FromDiscord<ElegantBeef> just realized my int testing only ran once
02:59:41FromDiscord<ElegantBeef> So yea new results will be different
03:02:24FromDiscord<ElegantBeef> Ah yea my tests were borked
03:04:44FromDiscord<ElegantBeef> My parseint is 4 times slower 😄
03:14:20*rockcavera joined #nim
03:22:39FromDiscord<ElegantBeef> Bodged the normal parseint impl for my code and now it's faster aswell
03:22:42FromDiscord<ElegantBeef> So yay
03:23:56*D_ joined #nim
03:42:07*mmohammadi9812 quit (Ping timeout: 260 seconds)
03:45:36*mmohammadi9812 joined #nim
03:58:55*muffindrake quit (Ping timeout: 272 seconds)
04:00:38*muffindrake joined #nim
04:12:37*tubs joined #nim
04:12:54*tubs left #nim ("WeeChat 2.9")
04:18:48FromDiscord<Avatarfighter> i just realized i've been using nim 1.2.0
04:18:52FromDiscord<Avatarfighter> on my windows
04:18:57FromDiscord<Avatarfighter> 🤦‍♂️
04:19:10FromDiscord<ElegantBeef> Why is that an issue?
04:20:20FromDiscord<Avatarfighter> its not an issue in it self
04:20:32FromDiscord<Avatarfighter> I was just not expecting it lol
04:36:57*vicfred quit (Quit: Leaving)
04:50:33*spiderstew joined #nim
04:53:21*spiderstew_ quit (Ping timeout: 264 seconds)
05:09:05*zedeus quit (Ping timeout: 240 seconds)
05:09:30*zedeus joined #nim
05:14:17*mmohammadi9812 quit (Ping timeout: 260 seconds)
05:14:47*mmohammadi9812 joined #nim
05:15:42*Gustavo6046_ joined #nim
05:16:04*Gustavo6046 quit (Ping timeout: 246 seconds)
05:17:53*Gustavo6046_ is now known as Gustavo6046
05:19:04*rockcavera quit (Remote host closed the connection)
05:19:33*zedeus quit (Ping timeout: 246 seconds)
05:21:56*zedeus joined #nim
05:26:26*vicfred joined #nim
05:27:39*zedeus quit (Ping timeout: 256 seconds)
05:28:06*zedeus joined #nim
05:39:04*narimiran joined #nim
05:41:20*jjido quit (Quit: Connection closed for inactivity)
05:42:15*njoseph quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
05:42:23*njoseph joined #nim
06:30:06*salazar joined #nim
06:32:21*caesarsalad quit (Ping timeout: 246 seconds)
06:41:25FromDiscord<carpal> the last time I installed nim I was on linux (PopOS) and using apt the larest version was 1.2.6
06:42:51saemThat's why I ended up using choosenim instead when I was on PopOS.
06:44:48FromDiscord<ElegantBeef> Eh choosenim is the way regardless imo
06:45:24saemit'd be nice if it shipped with a working nim-gdb.py, nimgrep, and various other tools.
06:47:05FromDiscord<ElegantBeef> Doesnt it build all the tools?
06:47:16saemNope.
06:48:03saemoh maybe it's been updated and now it has a few more.
06:49:55saema few lesser known tools aren't there, but that's less of an issue.
06:50:46saemI wonder if nim-gdb.py works now.
06:56:56*krux02 joined #nim
07:10:52*waleee-cl quit (Quit: Connection closed for inactivity)
07:15:24ForumUpdaterBotNew thread by Kobi: What are the latest developments in the Nim compiler?, see https://forum.nim-lang.org/t/7457
07:15:29saemSpent the entire weekend looking at sem.
07:16:33saemHopefully my brain will sort some more of that information out.
07:43:04*PMunch joined #nim
07:55:19*lritter joined #nim
08:07:55*caesarsalad joined #nim
08:10:21*salazar quit (Ping timeout: 246 seconds)
08:23:41FromDiscord<Clyybber> saem do you have an example where loss of information happens?
08:29:26*Jjp137 quit (Ping timeout: 264 seconds)
08:30:15*Jjp137 joined #nim
08:32:33FromDiscord<Clyybber> oh, eh reread the issue, foundit
09:01:54*Vladar joined #nim
09:23:36*pietroppeter joined #nim
09:30:15*NimBot joined #nim
09:31:06*FromDiscord quit (Read error: Connection reset by peer)
09:31:43*FromDiscord joined #nim
09:32:21FromDiscord<haxscramper> How I can have default `static[seq[string]]` default argument? I tried just putting `proc staticArg(arg: static[seq[string]] = @[""]) = discard` but it doesn't work.
09:32:27FromDiscord<Goel> sent a long message, see http://ix.io/2NXp
09:32:38*maier joined #nim
09:33:15FromDiscord<haxscramper> You can `open` on any kind of file as long as it exists (for `fmRead`)
09:33:47FromDiscord<haxscramper> And IIRC for `fmReadWrite` it will create new file when writing
09:33:50FromDiscord<Goel> Even a plain text file that has no extension at all?
09:33:58FromDiscord<ElegantBeef> It doesnt care about extension
09:34:04FromDiscord<haxscramper> Yes, even plaintex, `.exe` or whatever
09:34:44FromDiscord<ElegantBeef> If you tell it to open a file and it exists, it'll open it or make it depending on what mode you tell it
09:35:53FromDiscord<Goel> I understand, thanks 👍
09:36:06FromDiscord<haxscramper> Putting `const` for default value does not work either. I can create overload that passes empty sequence - this one works, but then I have two procs which differ only in one argument (and this is annoying because there are a lot of other arguments that have to be copy-pasted)
09:37:17FromDiscord<ElegantBeef> make a version without that param(if it's just one) which calls the original static?
09:37:18FromDiscord<Rika> `static: @[""]`? does that work?
09:37:27FromDiscord<haxscramper> Example code is - https://play.nim-lang.org/#ix=2NXq
09:37:47FromDiscord<Rika> or no colon actually i think
09:38:38FromDiscord<haxscramper> It still treats it as a runtime value `got <seq[string]> but expected 'static[seq[string]]'`
09:38:52FromDiscord<Rika> thats odd
09:39:21FromDiscord<ElegantBeef> https://play.nim-lang.org/#ix=2NXr my dumb solution assuming i was unclear
09:40:08FromDiscord<haxscramper> @ElegantBeef about adding overload
09:40:23FromDiscord<ElegantBeef> Huh?
09:40:33FromDiscord<ElegantBeef> Ah
09:40:39FromDiscord<ElegantBeef> Didnt read that just read after it
09:41:54FromDiscord<ElegantBeef> Oh shit
09:41:56FromDiscord<ElegantBeef> I did it! 😄
09:42:00FromDiscord<ElegantBeef> https://play.nim-lang.org/#ix=2NXr
09:42:45FromDiscord<Rika> nothing changed
09:42:59FromDiscord<ElegantBeef> https://play.nim-lang.org/#ix=2NXu
09:43:25FromDiscord<Rika> well it compiles, but does it work as expected
09:44:02FromDiscord<haxscramper> https://play.nim-lang.org/#ix=2NXw yes it is not just runtime value
09:44:18FromDiscord<Rika> https://play.nim-lang.org/#ix=2NXx
09:44:22FromDiscord<Rika> it can accept runtime though
09:44:45FromDiscord<ElegantBeef> Hey i was just using compiling as a metric
09:45:07FromDiscord<Rika> so you didnt actually do it
09:46:14FromDiscord<haxscramper> Although this might be a bug, because I would expect `static @[""]` be `static[seq[string]]`
09:46:21FromDiscord<haxscramper> !eval echo typeof static @[""]
09:46:24NimBotseq[string]
09:46:46FromDiscord<ElegantBeef> nah `static` should just mean the right hand is evaluated at CT
09:46:59FromDiscord<ElegantBeef> it's using `static:` instead of `static[]`
09:47:51FromDiscord<haxscramper> But shouldn't it produce compile-time constant too, that is just demoted to runtime value?
09:48:06FromDiscord<ElegantBeef> Why would it change the type
09:48:20FromDiscord<ElegantBeef> `const a = static 10`
09:48:25FromDiscord<ElegantBeef> a should be an int
09:48:28FromDiscord<Rika> static isnt exactly a type
09:48:38FromDiscord<Rika> its more of an annotation than a type
09:48:49FromDiscord<ElegantBeef> !eval const a = static 10; echo a.typeof
09:48:52NimBotint
09:49:19FromDiscord<haxscramper> Yes, I meant annotations - something like C++ const qualifiers maybe?
09:49:30FromDiscord<haxscramper> But anyway, looks like the best option is to create overload
09:49:41FromDiscord<ElegantBeef> Could make a macro to do it if you have a lot
09:49:48FromDiscord<haxscramper> ~macro
09:49:50FromDiscord<ElegantBeef> Saves the tedium
09:50:21FromDiscord<haxscramper> Yes, I thought about writing something like python `kwargs` macro
09:52:03FromDiscord<Clyybber> @haxscramper IMO static: @[""] should indeed qualify as static[seq[string]]
09:53:56FromDiscord<ElegantBeef> Doesnt that get funky for static blocks?
09:54:00FromDiscord<Clyybber> why?
09:54:07FromDiscord<ElegantBeef> `const a = static int`
09:54:10FromDiscord<ElegantBeef> (edit) "int`" => "10`"
09:54:25*caesarsalad quit (Ping timeout: 240 seconds)
09:54:26FromDiscord<ElegantBeef> a should be static, or just int
09:54:36FromDiscord<Clyybber> a will be static[int]
09:54:55FromDiscord<ElegantBeef> Does that change any runtime behaviour?
09:55:02FromDiscord<Clyybber> no, why would it?
09:55:16FromDiscord<ElegantBeef> I was just making sure 😄
09:55:19FromDiscord<Clyybber> :)
09:55:37FromDiscord<Clyybber> I don't think it will change anything about the `const a = static: 10` case
09:58:23FromDiscord<Clyybber> Actually just @[""] should work in this case too I think. It's just that we need to check if the arg type is `static`and then request a static value
09:59:00FromDiscord<ElegantBeef> I can barely spell compiler never mind suggest what it should
10:00:18FromDiscord<--HA--> sent a long message, see https://paste.rs/VDj
10:01:18FromDiscord<ElegantBeef> Couldnt you use a filestream, `setPosition(0)` then write your header?
10:02:48FromDiscord<lqdev> you can't insert in a file
10:03:37FromDiscord<lqdev> you will have to read the file, but you read then write the file in chunks
10:04:13FromDiscord<lqdev> you can keep a buffer like `array[1024, char]` or something, read a chunk there, and write the chunk back immediately after reading
10:05:22FromDiscord<--HA--> Writing that way to a file overwrites what is there already. My goal is to add something before the original content of the file.
10:05:59FromDiscord<ElegantBeef> Yea it's 3am and i didnt think through what i suggested
10:06:50FromDiscord<--HA--> I figured it would be some kind of read and write loop. Just wasn't sure what chunks to use. How/why do you pick 1024 @lqdev ? Just because bigger blocks are better than just one byte at a time? Is that better?
10:07:12FromDiscord<ElegantBeef> Pmunch you still about?
10:07:17FromDiscord<lqdev> reading and writing in blocks is faster because you make less syscalls
10:07:34FromDiscord<lqdev> you can choose any block size, 1024 is just a common number
10:11:38FromDiscord<lqdev> @--HA-- http://ix.io/2NXH/nim
10:11:47FromDiscord<--HA--> I see. Does that mean I could make the buffer say 100mb and files smaller than that would be read completly into memory, would that still be a good idea? Because I don't have anything against reading all into memory generally I just want it to be possible to worj if the file turned out bigger than RAM.
10:12:03FromDiscord<lqdev> the stack is usually not that big to hold your entire 100MB
10:12:23FromDiscord<lqdev> and at this size you're approaching the point of diminishing returns
10:12:30PMunch@ElegantBeef, yup
10:12:38FromDiscord<mratsim> @ElegantBeef regarding strviewutils, sometimes openarrays aren't enough and you might need to reverse or skip steps in views. In that case you might want to use StridedViews like i do there: https://github.com/mratsim/constantine/blob/kate-poly-commitment/research/kate/strided_views.nim#L23-L29 would that be useful in fusion?
10:12:41FromDiscord<lqdev> where you mostly use a ton of memory, you could as well just read the entire file
10:13:00FromDiscord<ElegantBeef> Ah mratsim led into what i was going to talk about
10:13:12FromDiscord<ElegantBeef> I know you have strslice, but i've been playing with views and strutils
10:13:24FromDiscord<ElegantBeef> https://github.com/beef331/strviewutils
10:13:27*hmmm joined #nim
10:13:32FromDiscord<ElegantBeef> Same principle just using views
10:13:56hmmmhoooy nimions, what can I do to get a file size?
10:14:07FromDiscord<mratsim> you can sacrifice a goat
10:14:12hmmm:3
10:14:20FromDiscord<ElegantBeef> https://nim-lang.org/docs/os.html#getFileSize%2Cstring
10:14:46hmmmbeefy to the rescue
10:14:52FromDiscord<ElegantBeef> Yea that'd probably be useful mratsim, but the reversing a view isnt overly difficult
10:15:00FromDiscord<mratsim> it's an alloc 😉
10:15:17FromDiscord<mratsim> if the view is not strided
10:15:33FromDiscord<mratsim> you can also repeat a view without allocating
10:15:37FromDiscord<ElegantBeef> Ah, i'm only touching strutils big boy ops that reallocate
10:15:40FromDiscord<mratsim> you make the stride 0
10:15:57FromDiscord<mratsim> how does repeat that does not allocate sound? 😉
10:16:08FromDiscord<--HA--> Thanks lqdev. I'll go with the 1024 byte buffer and see how that works.
10:16:16FromDiscord<ElegantBeef> Nice, but unneeded for my implementation afaik 😄
10:16:26FromDiscord<ElegantBeef> Although my rsplit isnt proper
10:17:13FromDiscord<lqdev> @--HA-- if it's too slow you can try to make the buffer larger like 4096 bytes but usually that's not necessary
10:17:20FromDiscord<mratsim> If you ever want to write a tensor library from scratch, StridedViews are 1-dimensional tensors
10:17:22hmmmbeefy it worked pefectly <3
10:17:39FromDiscord<ElegantBeef> Lol mratsim, methinks you overestimate my knowledge or field of interest 😛
10:18:02FromDiscord<mratsim> you've been online for 8 hours so I figured you were bored 😉
10:18:05PMunch@Elegant, did you want something?
10:18:23FromDiscord<ElegantBeef> Just to show off strviewutils cause i'm a shill of showing off stuff
10:18:51FromDiscord<ElegantBeef> I dont have a problem. ~~I certainly do~~
10:19:45PMunchOh right
10:20:00FromDiscord<ElegantBeef> Though the downside of your View mratsim is that it's not borrow checked right?
10:20:48PMunchWait, what's a view?
10:21:04FromDiscord<ElegantBeef> Nim's borrowchecked borrowing logic
10:21:21FromDiscord<ElegantBeef> https://nim-lang.org/docs/manual_experimental.html#view-types
10:21:58FromDiscord<--HA--> @lqdev open() and the readBytes() writeBytes() on the File type from io is faster than openFileStream() and the read write procs based on that?
10:22:05FromDiscord<lqdev> yes
10:22:40FromDiscord<--HA--> Nice. I don't need anything special from streams so this will be good. Didn't see that File had those at first. Thanks.
10:22:49FromDiscord<lqdev> np
10:22:52FromDiscord<ElegantBeef> Views imo are very promising, since as i've even shown they seem to be very very nice for quickly making Nim faster
10:22:58FromDiscord<ElegantBeef> (edit) "Views imo are very promising, since as i've even shown they seem to be very very nice for quickly making Nim faster ... " added "in certain operations"
10:23:29FromDiscord<ElegantBeef> Though 4raq has said there are issues with them
10:23:53PMunchHmm, what's benchy and how can I get it?
10:24:02PMunchApparently it's not in Nimble
10:24:15FromDiscord<ElegantBeef> https://github.com/treeform/benchy
10:24:45PMunchWhy is it not in Nimble?
10:24:52FromDiscord<ElegantBeef> Do i look like treeform?
10:25:05PMunchWouldn't know, never seen you :P
10:25:40FromDiscord<mratsim> @ElegantBeef it is borrow checked
10:25:41FromDiscord<ElegantBeef> Fine you've probably heard me so "Do i sound like treeform"
10:25:51FromDiscord<mratsim> there is a lent UncheckedArray
10:25:58FromDiscord<mratsim> as a field
10:25:58FromDiscord<ElegantBeef> Ah the `lent unchecked` ensures the entire object doesnt outlive it?
10:26:01FromDiscord<mratsim> yep
10:26:06FromDiscord<ElegantBeef> Damn
10:26:30PMunchHmm, when would I have heard you?
10:26:37FromDiscord<ElegantBeef> nimscripter's video
10:26:39FromDiscord<mratsim> you can put an openarray inside instead of len + ptr UncheckedArray actually and it would work at compile-time
10:26:41PMunchOoh right
10:26:49PMunchHmm, yeah I guess not
10:27:01FromDiscord<mratsim> wow, custom views working in the compiler.
10:27:24Oddmongerwhat is custom view ?
10:27:56FromDiscord<mratsim> view types
10:28:17FromDiscord<mratsim> types that doesn't own their data and so do no copy.
10:28:29FromDiscord<mratsim> alternatively QT and GTK
10:28:42FromDiscord<ElegantBeef> lol
10:29:03Oddmongera pointer ?
10:29:36FromDiscord<ElegantBeef> Practically yes
10:29:36Oddmongerit's a compiler thing , or in nim language itself ?
10:29:55FromDiscord<ElegantBeef> It's in the language
10:30:15Oddmongerok i check the manual then, thanks
10:30:23FromDiscord<ElegantBeef> Well it's experimental
10:30:47FromDiscord<ElegantBeef> But they give you a more ergonomic and safer method of unowned memory
10:31:35FromDiscord<mratsim> I wonder if I can make Weave use views.
10:31:46FromDiscord<ElegantBeef> `let a: lent int = yourVar` gives you an immutable view and `var a: var int = yourVar ` gives you a mutable view for instance, which cannot outlive `yourVar`
10:31:57FromDiscord<ElegantBeef> so you dont get nilptrs, it's safe
10:32:19FromDiscord<mratsim> I wasn't aware of this syntax.
10:32:30FromDiscord<mratsim> that is real strange
10:33:04FromDiscord<ElegantBeef> Think it's one concern of it, could be wrong
10:33:33Oddmongervar a: var int = yourVar , really ?
10:33:39FromDiscord<ElegantBeef> yes
10:33:52Oddmongerso var is of type var
10:34:30FromDiscord<mratsim> I prefer "toView" and "toMView" instead of type coercion
10:34:34FromDiscord<mratsim> easier to grep as well.
10:34:41FromDiscord<ElegantBeef> Yea i think that's better
10:34:57FromDiscord<mratsim> the type can stay but that would just be implementation detail leaking.
10:36:07FromDiscord<ElegantBeef> Like i said 4raq has some issues with it, it's somewhere in the irclogs his reasoning for issues
10:38:55FromDiscord<mratsim> I have to remove concepts from my whole code because their codegen is too broken :/
10:39:10FromDiscord<Clyybber> or you can try to fix it :D
10:39:18FromDiscord<Clyybber> but that looks like a tricky bug
10:39:24FromDiscord<mratsim> no way i'm touching that part in the compiler.
10:39:38FromDiscord<Clyybber> it's tempting
10:40:07FromDiscord<mratsim> I think concepts proc are using a dummy size for their parameters.
10:40:24FromDiscord<mratsim> unless they don't use the same codepath as generics?
10:40:42FromDiscord<Clyybber> but at codegen the size should be resolved
10:41:17FromDiscord<mratsim> I have another reason to dump concepts as well. https://github.com/nim-lang/Nim/issues/13982
10:41:36FromDiscord<mratsim> and also compilation times due to the lack of concept cache.
10:41:37FromDiscord<Clyybber> IC will help with that a bit
10:41:52FromDiscord<Clyybber> the deduplicating part
10:41:57FromDiscord<Clyybber> and eventuall the concept cache
10:42:27FromDiscord<mratsim> I know the dance "VTable will help with that", 😉
10:42:56FromDiscord<lqdev> you'd wanna
10:42:57FromDiscord<Clyybber> heh, I don't know the plans for VTable
10:43:06FromDiscord<mratsim> I have way more code to add and I need to cut down tests every months.
10:43:16FromDiscord<mratsim> because of crazy CI times.
10:43:16FromDiscord<Clyybber> but I don't understand the reason why would we want compiler implemented VTables anyways
10:43:28FromDiscord<mratsim> for interop
10:43:42FromDiscord<mratsim> so that if you do a DLL, you can extend it in a standard way.
10:43:58FromDiscord<Clyybber> I see. So its only for interop
10:44:09FromDiscord<mratsim> it should also work at compile-time I think.
10:45:02FromDiscord<mratsim> you can do a lot of things with object variant but extensible serialization needs concepts/traits/interfaces/VTables
10:45:04FromDiscord<lqdev> i just want stable concepts…
10:45:21FromDiscord<lqdev> vtables are more expensive
10:45:25FromDiscord<mratsim> I just want stable generics
10:45:49FromDiscord<mratsim> The Vtables I'm talking about are the ones that were described in the experimental manual
10:45:49*abm joined #nim
10:46:02FromDiscord<mratsim> those that allows concepts to also work at runtime
10:46:11FromDiscord<mratsim> so it's a complement.
10:46:26FromDiscord<mratsim> just like object / ref object
10:46:30FromGitter<Araq> I just want RFCs that make sense... dunno, like a spec you can follow and implement
10:46:34FromDiscord<mratsim> you have concept / vtref concept
10:46:47FromGitter<Araq> instead of this "just make me a coffee" attitude
10:47:02FromGitter<Araq> where I get to do both design and implementation and bugfixing
10:47:46FromGitter<Araq> a way out of lalala land where you put arbitrary code inside a concept and pretend it means something
10:48:26FromDiscord<mratsim> That isn't fair, we all spend a lot of time finding those bugs and reducing them to minimal examples.
10:48:36FromDiscord<Clyybber> @mratsim I think it's because of lent
10:48:43FromDiscord<Clyybber> The size is correct
10:49:02FromDiscord<mratsim> the first bug is concept only, there is no lent
10:49:17FromDiscord<mratsim> the second bug is trying to workaround the first without having to change my whole codebase.
10:49:41FromDiscord<Clyybber> Ah, should make that more clear I guess
10:49:47ForumUpdaterBotNew thread by Drkameleon: Tracking down hints and silencing them, see https://forum.nim-lang.org/t/7458
10:49:58FromDiscord<mratsim> Also, we're not introducing new RFC for things that don't exist, we are talking about things that are already there and trying to make stable.
10:50:17FromGitter<Araq> and when I point out that `is` inside concepts is `system.is` and we don't have any reason to see it's system.`is` because of the broken syntax then people point out that the other syntax doesn't support feature X
10:51:11FromGitter<Araq> how helpful.
10:51:27FromGitter<Araq> but ok, what's the bug you want me to look into the most?
10:51:48FromDiscord<mratsim> symbol resolution in generics?
10:51:59FromGitter<Araq> issue number?
10:52:16FromDiscord<mratsim> https://github.com/nim-lang/Nim/issues/8677
10:52:48FromGitter<Araq> that's a collection of bugs...
10:53:52FromGitter<Araq> > #5053: .this pragma doesn't work with generics ⏎ ⏎ 'this' pragma is dead.
10:54:11FromGitter<Araq> > #5707: List comprehensions do not work with generic parameter (needs mixin) ⏎ ⏎ list comprehensions are not sugar.collect
10:54:29FromGitter<Araq> > #6387: Generics proc + macros: identifier resolution happens before macros ⏎ ⏎ That's the spec.
10:54:36FromDiscord<mratsim> There is an issue with symbol bindings in generic. There are reference to IRC logs. I think the current sigmatch/semcheck sig* are a minefield.
10:55:16FromDiscord<mratsim> this is also likely related to templates.
10:56:14FromGitter<Araq> "a minefield" is not an actionable bug report. If you say the "spec sucks", we need to see what it should be like. And I've introduced the generic symbol prelookup pass because before we had that, the resulting language was even worse
10:56:22*maier quit (Quit: leaving)
10:56:24FromDiscord<mratsim> We can play whack-a-mole with the inevitable new issues that will popup when people will create `toSeq` or new `strformat` or maybe rethink the AST so that generics/static/typedesc/templates work fine.
10:56:55FromDiscord<Clyybber> there is no need to rethink the AST
10:57:05FromDiscord<Clyybber> we simply need to fix bugs, and those need to be concrete
10:57:44FromGitter<Araq> sometimes it's just a bug and we should fix it and probably should have fixed it sooner.
10:57:59FromGitter<Araq> but sometimes it's how the spec says it should be done
10:58:33FromGitter<Araq> and the spec is an evolution of a simpler spec that was worse, IMHO, ymmv
11:00:07FromGitter<Araq> > #7385: mixin + block expression: works in Generics, not in "normal" proc ⏎ what does a 'mixin' declaration inside a normal proc mean?
11:00:33FromDiscord<mratsim> somehow I missed this one: https://github.com/nim-lang/Nim/issues/5540
11:00:58FromGitter<Araq> > #7632: strformat doesn't work properly inside generics and templates ⏎ ⏎ that's a unique aspect of the way the langauge is embedded inside string literals
11:01:10FromGitter<Araq> this is not a "generics don't work" problem, it's unrelated.
11:01:47FromDiscord<mratsim> It's related, it doesn't work in generics
11:01:51FromDiscord<mratsim> it works in normal proc
11:02:11FromDiscord<mratsim> you can nitpick about the internal but at a high-level that is the issue
11:02:42FromGitter<Araq> it's unlikely then we fix this bug it has much impact on other generic related bugs.
11:02:50FromGitter<Araq> *when
11:02:52FromDiscord<mratsim> I'm tired of dealing with generic sandwiches every other week as well
11:03:17FromDiscord<mratsim> it's all linked to symbol bindings, resolution, visibility
11:03:23FromDiscord<mratsim> it's a huge time sink
11:03:35FromDiscord<Clyybber> yes, but don't conflate it all
11:03:57FromDiscord<Clyybber> from an outside perspective it's easy to think "it's all related/messy"
11:04:02FromDiscord<mratsim> well whatever, I'm going back to doing code, i've said my piece.
11:04:17FromDiscord<Clyybber> but the true relations/interactions only reveal themselves once you are investigating the bug
11:04:35FromGitter<Araq> generic sandwiches ... again, no RFC, no spec solution, and my personal solution wants a working IC implementation first
11:04:56FromDiscord<mratsim> i tried to investigate symbol resolution issues, I used the tracer in sigmatch or something like that
11:05:03FromDiscord<mratsim> I was lost in the control flow
11:05:18FromDiscord<mratsim> there is no way you can dive in without spending a week first to understand that part
11:05:38FromGitter<Araq> I'm not asking you to dive into the compiler's code
11:05:54FromDiscord<mratsim> you complained about you having to do the bugfixing
11:05:55FromGitter<Araq> I'm asking you about actionalbe high priority bugs
11:06:29FromGitter<Araq> no, the bugfixing I don't mind. I mind having no solution ready but (good) complaints about how stuff doesn't work well
11:06:29FromDiscord<mratsim> This is important: https://github.com/status-im/nimbus-eth2/issues/2219
11:06:52FromDiscord<mratsim> for now we just do dumb copy-paste instead of using generics
11:08:10FromDiscord<Clyybber> What is the underlying reason that strformat doesn't work in generics/templates?
11:08:44FromGitter<Araq> we don't expant 'fmt' early enough
11:08:44FromDiscord<mratsim> "undeclared identifier"
11:10:31FromGitter<Araq> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=6017e1a70eed905f1884f0b1]
11:10:35FromGitter<Araq> works.
11:11:15FromGitter<Araq> > for now we just do dumb copy-paste instead of using generics ⏎ ⏎ no idea why. You can always use .dirty templates and explicit instantation IME
11:12:09FromDiscord<Clyybber> Hmm, how would you solve that bug though? I'm not sure if its more correct to expand fmt early
11:13:14FromDiscord<mratsim> I spend almost a week to try to solve that you're free to bang your head on it. Types get lost in macros or typedesc inputs
11:13:48FromDiscord<Clyybber> @mratsim Replies don't translate to gitter I think
11:14:04FromDiscord<mratsim> Why do I need to do things like this to avoid a crash: https://github.com/status-im/nimbus-eth2/commit/ce0f7af862a5319a49e74ef3539d9ad8016e181d#diff-db5b104cb3b226d062424e32e4a6d862585c8f68d90bb0cde2350052c6439443L219
11:14:20FromDiscord<mratsim> and the commit just below is avoiding the same thing to avoid another crash
11:15:20FromDiscord<mratsim> I have the koch temp c out put, somehow the type ends up with a nil ast node ...
11:15:46FromGitter<Araq> bbs, lunch here
11:23:27FromDiscord<Zachary Carter> I was just messing around with asyncdispatch / asynchttpserver while replying to a question on the forum and I'm not sure why I'm seeing the output from this program that I am - https://play.nim-lang.org/#ix=2NY5
11:23:50FromDiscord<Zachary Carter> the first time that the handler is invoked I see `0 1` as expected
11:24:14FromDiscord<Zachary Carter> but then after the second invocation, `1` is printed 6 times
11:25:34FromDiscord<Zachary Carter> I would expect it to be printed 2 more times
11:32:31FromDiscord<Zachary Carter> Maybe I just don't understand something or it's too early for me for this. I'm not using Nim's async so it doesn't matter too much to me, but I found it odd.
11:33:07*pietroppeter quit (Quit: Connection closed for inactivity)
11:36:25FromDiscord<--HA--> Does mkstemp() from posix_utils work on windows and macos? Is there something better to get a temporary file?
11:36:58FromDiscord<Zachary Carter> well I doubt it since it's in `posix_utils`
11:37:38FromDiscord<Zachary Carter> https://docs.microsoft.com/en-us/windows/win32/fileio/creating-and-using-a-temporary-file shows how to do this in Windows
11:39:34FromDiscord<Zachary Carter> it might work with macos, I don't know
12:02:57*liblq-dev quit (Ping timeout: 246 seconds)
12:05:41*caesarsalad joined #nim
12:05:54*liblq-dev joined #nim
12:11:52*rockcavera joined #nim
12:31:08FromDiscord<Meowx> Does the choice of the gc actually affect the performance of my nim code?
12:31:34FromDiscord<Rika> yes
12:31:35FromDiscord<Clyybber> yeah; if you are using `ref` at least
12:32:21FromDiscord<Meowx> So what do you guys prefer for your projects? I've read somewhere that arc isn't that much optimized as the default one yet
12:33:47FromDiscord<--HA--> So I have to write my own os specific function? Nothing in the standard library that I missed for temporary files? If I wanted to make something simple myself asd I understand it the problem would be that between a file exists and a open call theoretically that file could have been created, even though it's unlikely.
12:33:57FromDiscord<Rika> orc usually
12:34:34FromDiscord<Rika> theres a function to get the temp dir, you can prolly just make files there
12:34:56FromDiscord<--HA--> It says someting along the lines of don't use this 😉
12:35:32FromDiscord<Rika> really
12:35:40FromDiscord<Rika> fuck the docs do it anyway xd
12:38:12FromDiscord<lqdev> @Meowx actually it is
12:38:26FromDiscord<lqdev> my scripting lang got a 2.5x speedup just from switching to ARC
12:38:50FromDiscord<lqdev> or was it 2x?
12:38:56FromDiscord<lqdev> i don't remember. still considerable
12:39:19FromDiscord<Meowx> How did you identify that? Just measuring the runtime of your tool?
12:39:44FromDiscord<Meowx> We need some nim-pros which finally code nim-spy 😄
12:45:58FromDiscord<lqdev> @Meowx exactly, i just compiled it with and without ARC and ran it through hyperfine to measure runtime
12:50:51FromGitter<Araq> @mratsim https://github.com/nim-lang/Nim/pull/16900 but please be aware that 'lent T' is not for parameters
12:52:08FromDiscord<mratsim> I know it's not but my experience with static leads me to try anything as a workaround
12:52:36FromDiscord<mratsim> Example: https://github.com/nim-lang/Nim/issues/6343
12:54:05FromGitter<Araq> see my fix. it's hardly a one line change, yet it makes your life so much easier (I hope)
12:55:33FromGitter<Araq> I suppose generic caching for concepts might be similar. but if we conflate simple bugs with overall architectural problems we make the perfect the enemy of the good.
12:56:01FromDiscord<dom96> Weird. How are you doing the requests? Curl?
12:56:05FromDiscord<Clyybber> Agreed, and often bugfixes interact
12:56:12FromDiscord<Clyybber> So that multiple bugs get fixed at once
12:56:29FromDiscord<dom96> (edit)
12:56:48FromGitter<Araq> that means for generic sandwiches we should probably come up with an acceptable workaround until the perfect redesign of generics arrives
12:57:12FromGitter<Araq> because it'll likely end up like my redesign of concepts otherwise, which nobody can use yet
12:58:03FromDiscord<Zachary Carter> Just browser. Maybe that's why
12:58:21FromDiscord<Zachary Carter> I didn't think about the option request
12:58:24FromDiscord<mratsim> I am not conflating simple bugs with architectural problems
12:58:50FromDiscord<Clyybber> Araq: Hmm, I think I have a good solution to the strformat issue
12:59:05FromDiscord<mratsim> I created the meta issues of symbol resolution after collecting over 10 similar issues.
12:59:29FromDiscord<Clyybber> Conceptually we should inject the parameters at the callsite
12:59:41FromDiscord<Clyybber> They would be aliasing symbols
12:59:43FromDiscord<mratsim> I even hinted I clyyber that I think some size wasn't passed properly for concepts.
13:00:28FromGitter<Araq> mratsim: ok well.
13:00:37*Vladar quit (Quit: Leaving)
13:00:55*hmmm quit (Quit: WeeChat 2.8)
13:02:17FromGitter<Araq> still the meta issue is harder to fix and lacking an RFC that proposes a solution.
13:02:58FromDiscord<mratsim> The RFC is, what works in normal proc should work in generics.
13:03:08FromDiscord<mratsim> What you are looking for is a RFC for the internal
13:03:19FromDiscord<mratsim> but that's not a proper RFC per se
13:04:58FromGitter<Araq> inside normal procs we can do overload resolution and then expand exactly the macro that ends up as the winner
13:05:19FromGitter<Araq> inside generic procs that is simply impossible, cannot do overload resolution
13:05:42FromGitter<Araq> hence my push for checking generic proc bodies via concepts.
13:05:54FromGitter<Araq> but the current concept design cannot deliver this feature.
13:06:20FromGitter<Araq> so ... perfect enemy of the good, not much progress with generics.
13:06:37FromDiscord<Clyybber> Araq: WDYT about my proposed approach?
13:06:53FromDiscord<Clyybber> For the strformat issue
13:08:08FromGitter<Araq> I prefer not to think about strformat as it's a bad feature anyway, we need Swift's string interpolation which solves the problem differently. I can write an RFC about it, later.
13:08:31FromDiscord<Clyybber> Sure, it's more about template expansion in general I suppsoe
13:09:50FromDiscord<Clyybber> conceptually instead of walking through the template body trying to replace every param we would now simply inject the params as aliases in a pseudoscope at callsite
13:10:21FromDiscord<mratsim> @Araq, so you agree that we can't just do bug fixing and there are arch reorgs needed to prevent new issues from popping up in the future
13:10:28FromDiscord<Zachary Carter> But then why only one time on the initial request 🧐
13:15:15FromGitter<Araq> mratsim: No, I don't agree. IMHO You need bugfixes moreso than perfect features
13:16:32*hmmm joined #nim
13:17:39FromDiscord<mratsim> You can play whack-a-mole with one design spawning 50+ bugs, or you can fix the design.
13:17:48FromDiscord<mratsim> non-trivial bugs.
13:18:12FromGitter<Araq> with the fixed design we start with 50+ more bugs
13:18:34FromDiscord<mratsim> I have been getting by with imperfect and buggy features, I can work around them. But at one point I have workarounds of workarounds.
13:18:49FromDiscord<Clyybber> @mratsim Can you just say what you think is misdesigned?
13:19:14FromDiscord<mratsim> I think the internal of symbol resolutions are problematic.
13:19:23FromGitter<Araq> workarounds of workarounds are bad, documented workarounds that we have covered by tests and in the manual
13:19:26FromDiscord<Clyybber> heh, but you said internal
13:19:27FromDiscord<mratsim> They are likely the biggest source of ICE
13:19:34FromDiscord<Clyybber> so I'd argue that its not a part of the design
13:19:39FromDiscord<Clyybber> more like organically grown
13:19:48FromDiscord<Clyybber> I think it can be fixed
13:20:06FromDiscord<Clyybber> of course some bugfixes require thinking about the design as a whole
13:20:08FromDiscord<mratsim> At one point you need to pay the technical debt
13:20:21FromDiscord<Clyybber> but IMO the nim compiler is small enough for it to be relatively easy to refactor
13:20:34FromDiscord<mratsim> https://media.discordapp.net/attachments/371759389889003532/805789684650606592/j3ea2qy3h8521.jpg.webp
13:20:41FromGitter<Araq> well that's what I did the last 1-2 months. refactorings
13:21:24FromGitter<Araq> I don't mind refactorings, everybody benefits from these, eventually
13:21:50FromGitter<Araq> but an alternative concept implementation enabling generic code to be sem'checked is not a "refactoring"
13:22:11FromDiscord<Clyybber> yeah
13:22:39FromGitter<Araq> it's adding a new feature so we have 2 concept implementations lying around until in 2 years the old concept impl can go away
13:23:02FromGitter<Araq> however until then the new concept implementation is likely to have bugs too, new features start out as "buggy"
13:23:13FromDiscord<Clyybber> yeah
13:23:34FromDiscord<mratsim> Note that I never said we need to change the high-level usage, unlike your own RFC
13:23:46FromDiscord<mratsim> that means that all the tests that are passing today should keep passing.
13:23:58FromDiscord<Clyybber> the new concepts are not as powerful as the old concepts though, so are unlikely to replace them
13:24:31FromDiscord<mratsim> And I'm not even talkking about concepts, just generic, static, typedesc, auto.
13:24:41FromGitter<Araq> that's an unfair way of putting it, the new concepts are also *much* easier to implement and understand
13:25:05FromDiscord<Clyybber> yeah; I know.
13:27:12*Kaivo joined #nim
13:27:21*nc-x joined #nim
13:27:45nc-xwhat's required to fix the old concepts (apart from small bugs)?
13:28:04FromDiscord<Clyybber> nothing, probably
13:28:08nc-xi think i read somewhere that the main issue was caching symbols or something
13:28:11FromDiscord<Clyybber> but the small bugs are tricky to repro at least
13:28:21FromDiscord<Clyybber> nc-x: Yeah they are not cached right now afaik
13:28:24FromDiscord<haxscramper> Is it possible to get enum field as name when I already have string override? E.g. I have `enField = "Something"` and want to serialize it as `enField` not as `"Something"`
13:28:42FromGitter<Araq> haxcramper: via a macro it should be possible
13:28:58nc-xi have not read the new concepts rfc or used the old concepts, but syntactically atleast i prefer the old ones :D
13:29:24nc-xanyways i would prefer the one which "works"
13:29:31nc-xwe need more araqs
13:29:46FromGitter<Araq> well old styled concepts also have non-trivial compile-time implications
13:30:26FromGitter<Araq> I don't understand how much of this is intrinsic in their design
13:30:44FromDiscord<mratsim> yeah, I will check with generics but the compilation time of recursive concepts is quite high even when I only have like 7 procs per instantiation
13:31:10FromDiscord<mratsim> I suspect term-rewriting macros are also in the same boat
13:31:41nc-xwell maybe someday have a call with mratsim and zah and anybody else associated with concepts and generics and figure things out
13:31:42FromDiscord<mratsim> "open" rewriting/instantiation seems to slow down the compiler (I suppose for it to scan at any point if something actually matches)
13:31:57FromDiscord<mratsim> I'm not associated with, I'm just a power user
13:32:01nc-xi am yet to use these features so i am useless in this discussion
13:33:05FromGitter<Araq> new styled concepts are simple minded checks for the mere existence of some procs inside the current scope
13:34:57FromGitter<Araq> there is not enough going on that could cause bad compile-times.
13:35:01nc-x@mratsim well, i am afraid of your power :D most of the issues regarding static and generics have been found by you i think
13:35:03*nc-x quit (Quit: Ping timeout (120 seconds))
13:35:15*nc-x joined #nim
13:35:17FromDiscord<mratsim> Mwahahahahahaha
13:35:22FromDiscord<mratsim> My power is unrivaled
13:35:35FromGitter<Araq> many of these issues have also been fixed too, but it takes new brains to use them fearlessly
13:35:49FromDiscord<mratsim> static is likely becaue I was the first to try to use them.
13:36:07FromDiscord<mratsim> in strange ways, because Andrea already used them in linalg/neo
13:36:34FromDiscord<mratsim> I think most of the issues I raised with generics happened when I started to use auto/typedesc
13:36:42FromDiscord<mratsim> or with macros
13:36:56FromDiscord<mratsim> like array[N, T] has been working fine.
13:37:15FromGitter<Araq> I have a `static T` bugfix in the works
13:37:32FromGitter<Araq> that might fix another big set of problems at the same time
13:37:37FromDiscord<Clyybber> nice!
13:37:57FromDiscord<mratsim> tbf, I don't have many static blockers anymore.
13:38:07FromDiscord<mratsim> even people on the forum are saying static is stable
13:38:26FromDiscord<mratsim> https://forum.nim-lang.org/t/7455#47269
13:38:44FromGitter<Araq> eventually features can get stable but it's *required* we stop changing their spec
13:39:08FromGitter<Araq> however, intrinsic problems can only be fixed by changing the spec
13:39:13FromDiscord<mratsim> I never asked to change the spec of generics, static, typedesc, auto, concepts
13:39:27FromGitter<Araq> you never wrote a spec for these either :P
13:39:44FromGitter<Araq> not that I'm blaming you. and I don't know if we really have one
13:39:46FromDiscord<mratsim> "This works in procs but not in generics"
13:39:53FromDiscord<mratsim> is the default attitude
13:40:09*mmohammadi9812 quit (Ping timeout: 264 seconds)
13:40:33FromDiscord<mratsim> I can write a spec for threadpools/multithreading runtime.
13:40:41nc-xwell maybe after (ic + no forward declaration required + cyclic dependencies), the next release can be focused on generics/statics/concepts etc.
13:40:44FromDiscord<mratsim> I can try to write a spec for CPS
13:40:55FromGitter<Araq> well that's more of a description of a fundamental misunderstanding of what generic code is. No offenses implied
13:41:04FromDiscord<mratsim> but I can't write a spec for compiler internals especially type resolution :/
13:42:00FromDiscord<mratsim> I can probably spec what getType, getTypeImpl, getTypeInst, typeof on NimNode should return.
13:42:21FromGitter<Araq> that would be awesome, no irony
13:42:23FromDiscord<mratsim> and sameType as well.
13:42:32FromGitter<Araq> because I have no clue what these should return :-)
13:43:11FromDiscord<mratsim> one thing is that they get all funcky when you have a `when x is Foo: myField: FieldType`
13:43:41FromDiscord<mratsim> and that's for generics, because when you have a static enum, it goes super funky
13:48:24*mmohammadi9812 joined #nim
13:51:19FromGitter<Araq> what do you use a static enum for?
13:52:13FromDiscord<mratsim> https://gist.github.com/mratsim/2e29324d9c6064e547790c7579f4607f#file-debug_datatypes-nim-L80-L100
13:52:42FromDiscord<mratsim> Those are static enum: https://github.com/mratsim/constantine/blob/master/constantine/config/curves_declaration.nim#L45-L65
13:53:00FromDiscord<mratsim> they are better than a static object/BigInt actually
13:53:18FromDiscord<mratsim> which was what i tried first and I hit a static showstopper.
13:54:47FromGitter<Araq> "better than" because they trigger fewer compiler procs? because if so, I'm more interested in making the compiler work for your initial design
13:55:07FromGitter<Araq> I don't like workarounds on workarounds either.
13:55:46FromDiscord<mratsim> Because we care about the curve name and attach all parameters to it
13:56:30FromDiscord<mratsim> but it can also be type Curve = object; modulus: BigInt, coefA: int or BigInt, coefB: int or BigInt, family: enum.
13:57:03FromDiscord<mratsim> that would avoid me having to have a codegen macro.
13:57:36FromDiscord<mratsim> though i think the macro is good for codesize/avoiding duplication because there is now only one place where the consts are declared.
14:00:12FromGitter<Araq> so what's that static T blocker?
14:05:46FromDiscord<mratsim> it was fixed in November: https://github.com/nim-lang/Nim/issues/11142
14:06:03FromDiscord<mratsim> it seems like it's also one of the bugs where i tried to dive in the compiler
14:07:33*nc-x quit (Quit: Connection closed)
14:14:26FromGitter<Araq> well I'm about to fix the "Last" static T bug then if you don't mind.
14:15:24FromDiscord<Clyybber> Araq: which one is it?
14:16:31FromGitter<Araq> https://github.com/nim-lang/Nim/issues/8868
14:16:53FromDiscord<Clyybber> nice!
14:20:37FromDiscord<mratsim> I hate when type system bugs manifest in int128: https://github.com/nim-lang/Nim/issues/14989
14:20:52FromDiscord<mratsim> you only get "assert false" fatal
14:21:20FromDiscord<mratsim> also the TRegKind something invalid branch issues
14:21:23FromDiscord<Clyybber> Yeah, it's usually when sizeof isn't yet determined but already gets used
14:21:37FromDiscord<Clyybber> But they can be a lot of things, just failing at the same place
14:21:50FromDiscord<Clyybber> not related to int128 itself though
14:34:49FromDiscord<flywind> `frexp` doesn't return negative zero in my win10 machine, fortunately it seems not the bug of Nim.
14:35:32FromDiscord<flywind> sent a code paste, see https://play.nim-lang.org/#ix=2NYL
14:44:30FromDiscord<Zachary Carter> I think that's because negative zero == zero?
14:46:35FromDiscord<flywind> it's works in linux
14:47:18FromDiscord<flywind> https://play.nim-lang.org/#ix=2NYP
14:47:35PMunchOoh, got an ARC bug: Error: unhandled exception: liftdestructors.nim(501, 14) `t.destructor != nil` [AssertionDefect]
14:47:45FromDiscord<Zachary Carter> 🤷
15:02:44*fredrikhr joined #nim
15:02:45*couven92 joined #nim
15:03:20*fredrikhr quit (Disconnected by services)
15:03:29*couven92 is now known as fredrikhr
15:03:45*couven92 joined #nim
15:06:46*couven92 quit (Client Quit)
15:11:20FromDiscord<mratsim> I thought destructors solved the nil references issues :p
15:21:22*lritter quit (Quit: Leaving)
15:22:08*vicfred_ joined #nim
15:24:13*vicfred_ quit (Client Quit)
15:24:59*vicfred quit (Ping timeout: 256 seconds)
15:30:15*hmmm quit (Quit: WeeChat 3.0)
15:32:56*couven92 joined #nim
15:35:57*fredrikhr quit (Ping timeout: 264 seconds)
15:37:55FromDiscord<no name fits> I'm not really sure where to ask this, but in a programming context, what would you call a db table? It would be a struct of arrays. Would you call it a store? Like if you had a Person table, would the programming equivalent be PersonStore?
15:38:50FromDiscord<no name fits> I also know that using a db is technically programming but I'm really struggling to phrase my question
15:43:03FromDiscord<Rika> you can say its a store yes
15:43:14FromDiscord<Rika> but i guess a mapping would be more appropriate
15:54:29FromDiscord<no name fits> PersonMapping?
15:54:46FromDiscord<no name fits> But that sounds more like a single mapping, was my worry
15:55:20FromDiscord<no name fits> Like if I see PersonMapping I'd expect a single person, not the entire table
15:55:26FromDiscord<no name fits> If that makes sense
16:00:04ForumUpdaterBotNew post on r/nim by doggertron_: Just another user who's discovered Nim., see https://www.reddit.com/r/nim/comments/la6fdz/just_another_user_whos_discovered_nim/
16:00:13*codic quit (Quit: Idle for 30+ days)
16:00:13*dilawar_uchiha[m quit (Quit: Idle for 30+ days)
16:00:13*k0mpjut0r quit (Quit: Idle for 30+ days)
16:00:13*cmc[m] quit (Quit: Idle for 30+ days)
16:00:13*Juno[m] quit (Quit: Idle for 30+ days)
16:02:16FromDiscord<konsumlamm> is it realistic that sequtils will be replaced (or superseded) by something like iterutils (i.e. a version that operators on iterators? or is that left to 3rd party libraries?
16:13:58*waleee-cl joined #nim
16:17:17FromDiscord<zetashift> Definitely not for 1.x, might be a valid RFC for a 2.x Nim thing, but personally I see nothing wrong with making it a 3rd party lib
16:22:36*tane joined #nim
16:44:28FromDiscord<haxscramper> Maybe after https://github.com/nim-lang/Nim/pull/11992 something like that could be added to fusion (maybe)
16:45:54FromDiscord<konsumlamm> is that PR still being worked on?
16:45:57Clonkk[m]Is there a way to use the collapsed notation of openmp when using ``||`` for nested loop ? It generates intermediate C code wetween for loops that prevents OPenMP to compile `` not enough perfectly nested loops before`` ?
16:46:02FromDiscord<konsumlamm> given that its from 2019...
16:46:21FromDiscord<haxscramper> no it is just that is a big PR with lots of changes and
16:46:25*Clonkk[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/KVctadDKiCtbteDIldevCmcN/message.txt >
16:46:26FromDiscord<Clyybber> the features that the PR enables should be enabled without that PR
16:46:32FromDiscord<Clyybber> because its really hacky IMO
16:46:47FromDiscord<Clyybber> static procs already kind of work btw
16:46:50*Clonkk[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/SKQNikxATHqWWZqDgpluMOMd/message.txt >
16:47:08Clonkk[m] * Is there a way to use the collapsed notation of openmp when using `||` for nested loop ? It generates intermediate C code between for loops that prevents OPenMP to compile ` not enough perfectly nested loops before` ?
16:50:13*couven92 quit (Ping timeout: 260 seconds)
16:52:07*a_chou joined #nim
16:54:44FromDiscord<mratsim> there is no way @Clonkk
16:55:23krux02@Clonkk: just a question, I don't know the `||` operator very well. Why don't you use `0 ..< Ny` instead of `0 .. (Ny-1)`
16:55:37Clonkk[m]Because .. is not executed in parallel
16:55:41FromDiscord<mratsim> I tried: https://github.com/numforge/laser/blob/master/benchmarks/transpose/transpose_bench.nim#L145-L167
16:55:56FromDiscord<mratsim> and tried: https://github.com/numforge/laser/blob/master/benchmarks/transpose/transpose_bench.nim#L237-L243
16:56:09FromDiscord<mratsim> In the end I embraced my inner Weaver
16:56:17Clonkk[m]So since you're there @mratsim I'm trying to understand why nested omp_for loop run faster than iterating over a tensor using iterators
16:56:19FromDiscord<mratsim> you should to
16:56:59FromDiscord<mratsim> It's a trick question?
16:57:09FromDiscord<mratsim> no idea :p
16:57:20*Clonkk[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/SzRXhEaFyBbJFqmZQvrerSKC/message.txt >
16:57:37FromDiscord<mratsim> usually OpenMP makes thing run slower and i go on a hunt for falshe sharing, cache invalidation, contention in glibc locks or whatever else
16:57:42Clonkk[m]mpairs takes 4sec to execute, omp by index takes 1s
16:58:10Clonkk[m]Yes, eventually i'll switch to weave but I need to understand it more before I switch the whole app to it
16:58:31FromDiscord<konsumlamm> @mratsim lol, i just now looked up what weave actually means
16:58:52Clonkk[m]Can't understand why a) Nested for loop is not problematic with omp (I assume i must have omp_set_nested(1) enabled by default) and b) Arraymancer iterator are slower
16:59:28FromDiscord<mratsim> @Clonkk I remember exploring this, something called TRIOT in the repo
17:00:11Clonkk[m]I was taking a look at arraymancer/laser/openmp.nim, i'll look into triot
17:00:33FromDiscord<mratsim> there is a bench here: https://github.com/mratsim/Arraymancer/blob/1a2422a1e150a9794bfaa28c62ed73e3c7c41e47/benchmarks/implementation/triot.nim#L150-L177
17:00:46FromDiscord<mratsim> this is Arraymancer current iteration logic
17:00:53saemClyybber basically any proc outside of semexpr itself or semstmtsandgenerics the phenomenon I'm referring to occurs. It's not always a bad thing, there is a reason why context free is advantageous, but there is not enough rules as to how that data should propagate and compose, hence continuous reestablishing things, it's disorienting. Establishing rules for which data should live where, how it can be operated on, and timing
17:00:53saemof those operations (not total order, more like associativity, commutivity, ...) is how to fix it. I just want some level of endorsement that it seems sound so I know I'm not going to hit a social convincing people wall, but principle objections are of course fine.
17:01:38FromDiscord<mratsim> and triot is just a way to generate nested for when max sizes are statically known, I used macros instead to do this: https://github.com/mratsim/Arraymancer/blob/1a2422a1e150a9794bfaa28c62ed73e3c7c41e47/benchmarks/implementation/triot.nim#L14-L18
17:01:55FromDiscord<mratsim> but you can bench Arraymancer internals against triple for loop
17:02:07FromDiscord<mratsim> it's possible that the compiler constant-folded or memcopied stuff away.
17:02:22FromDiscord<mratsim> Anyway the iterators are not parallel
17:03:23FromDiscord<Clyybber> saem: What would change under your proposal concretely? I'm all for simplifying how sem and the like works
17:03:50FromDiscord<mratsim> As you can see there was a factor 5 of difference between the current scheme and strided iteration for strided tensor (it's been 4 years i don't remember well): https://github.com/mratsim/Arraymancer/blob/1a2422a1e150a9794bfaa28c62ed73e3c7c41e47/benchmarks/implementation/triot.nim#L285-L287
17:04:16FromDiscord<mratsim> obviously for contiguous tensors nested for loops are very fast.
17:04:42Clonkk[m]<FromDiscord "<mratsim> Anyway the iterators a"> There are no iterators in parallel ? I assumed it was. It's only contiguous tensor i have that luxury
17:05:02Clonkk[m]<FromDiscord "<mratsim> obviously for contiguo"> I think that should explain it
17:05:05FromDiscord<mratsim> you have map_inline for that
17:05:28FromDiscord<mratsim> parallel iterators would not work with openmp
17:05:34*icebattle joined #nim
17:05:35Clonkk[m]Yes but I need access to the coordinate as well
17:05:44FromDiscord<mratsim> or it would be too much work to debug slowness
17:05:58Clonkk[m]That's why i don't use map-inline.
17:06:35saemClyybber: it depends if you mean, "guess what the far off future looks like" or "what earlier attempts look like". I ask because the intention is to be open to learning more and adapt.
17:08:06FromDiscord<Clyybber> saem: So how I understand it your intention is to use nodeflags more often to store information?
17:08:36FromDiscord<mratsim> Using omp_parallel_chunk you get an offset and a length, is that enough? https://github.com/mratsim/Arraymancer/blob/master/src/arraymancer/laser/tensor/initialization.nim#L79-L86
17:09:16FromDiscord<mratsim> this is the code: https://github.com/mratsim/Arraymancer/blob/master/src/arraymancer/laser/openmp.nim#L293-L325
17:09:21Clonkk[m]I know the dimension so I can always calculate I guess but I was hoping to avoid it
17:09:39Clonkk[m]Thanks ! I'll check that out
17:10:42FromDiscord<mratsim> Alternatively you can recover the coordinates from a raw array index as i do here: https://github.com/mratsim/Arraymancer/blob/master/src/arraymancer/tensor/private/incl_accessors_cuda.nim#L25-L69
17:11:00FromDiscord<mratsim> However it involves a division, which is 50x more expensive than an addition
17:11:20FromDiscord<mratsim> so I don't recommend it unless absolutely necessary (like on a GPU where you just can't do iterators)
17:11:38FromDiscord<mratsim> and it's a division per tensor dimension
17:12:43FromDiscord<Clyybber> saem: One important property that we want to gain/retain eventually is sem(sem(x)) = sem(x)
17:13:13FromDiscord<mratsim> saem(saem(x)) = saem(x)
17:13:19FromDiscord<Clyybber> :D
17:13:26saemClyybber: that's part of it, and I'm slowly clarifying my thinking by taking about it, so first of thanks for this dialogue. :) What I would do is look at the language feature by feature (this is leaning towards a spec as Araq has mentioned before) and break down what the analysis/transforms should be.
17:14:23FromDiscord<Clyybber> Sounds good!
17:14:28saemmratsim: that was awesome, I'm starting my day with a big laugh.
17:14:30Clonkk[m]<FromDiscord "<mratsim> so I don't recommend i"> GPU migration is not on the menu yet. For now it-s too much work for too little benefit
17:15:05Clonkk[m]Maybe when Flambeau is advanced enough 😁
17:15:09saemClyybber: idempotency property is fantastic.
17:15:32FromDiscord<mratsim> You can develop flambeau I think the difficult part are done
17:15:45FromDiscord<mratsim> now people can just add what they need.
17:15:57Clonkk[m]<FromDiscord "<mratsim> You can develop flambe"> The difficult part is me having time and energy to dedicate to it these days
17:16:12FromDiscord<mratsim> I have a lot to do on the cryptography side
17:16:47FromDiscord<mratsim> As I suspected 6 months ago, what I'm workign on is taking off: https://hackmd.io/@zkteam/eccbench
17:17:20FromDiscord<mratsim> and a lot of interest in the field is starting, I was even ask to provide a Rust compat layer today
17:17:33Clonkk[m]Nice
17:18:00FromDiscord<mratsim> and now I need to detect and fix compiler bugs that drop perf by 30% to 2x slower
17:18:20FromDiscord<Clyybber> @mratsim the concepts bug is fixed already
17:18:31FromDiscord<mratsim> yeah I know
17:19:10FromDiscord<mratsim> but I'll change to generics anyway this evening, the CI times are too long and I need to now generate 440000 lines of duplicated proc for small devices.
17:19:26FromDiscord<mratsim> I will test on devel to confirm though.
17:20:04FromDiscord<Clyybber> would be nice to have a testcase to make sure it doesn't regress, but this isn't really testable taht well
17:20:12FromDiscord<Clyybber> unless you inspect the generated C code maybe
17:20:32FromDiscord<mratsim> you can store the address ina global
17:20:43FromDiscord<mratsim> and check within the proc that the address is the same
17:20:52FromDiscord<Clyybber> ah smart!
17:30:04*JJ15 joined #nim
17:34:47FromDiscord<mratsim> The codegen is indeed much cleaner
17:35:34FromDiscord<mratsim> I still have to fix those kind of stuff but I think those are on me https://media.discordapp.net/attachments/371759389889003532/805853862556205096/unknown.png
17:37:06FromDiscord<mratsim> previously it was my whole screen which had movaps and movups (move aligned packed floats and move unaligned packed floats, packed float = 44 = 16 bytes).
17:45:15saemClyybber: l'd start with day the a proc declaration, return type specifically. Then in that execution look at each piece of information required at the end, determine how that information is derived (what analysis/querying) and place that at the appropriate semX proc. So in the case of return type of a proc it should hint that in the node or context, depends if we want to roll it back easily (updating AST should be with
17:45:15saem"final" information). Anything parsing the expression that is in the return type node should either be narrow to the case of a type node or do the analysis up front so semexpr doesn't start from scratch as much. I think semexpr is likely not the thing to use there anyhow.
17:47:21FromDiscord<dom96> > and a lot of interest in the field is starting, I was even ask to provide a Rust compat layer today↵↵Tell them to use Nim 😄
17:47:36FromDiscord<Clyybber> saem: You have to consider someTemplate(...) as a return type
17:48:02FromDiscord<Clyybber> And when expressions etc.
17:48:05*natrys joined #nim
17:48:30FromDiscord<mratsim> The field is growing very fast and Rust is the defacto standard unfortunately.
17:48:39saemClyybber: I know, but it's still a constrained analysis, as in the analysis before hand can narrow all that.
17:49:12FromDiscord<Clyybber> Hmm, not so sure about that. How is it constrained?
17:49:52FromDiscord<mratsim> I would need to reimplement this basically: https://github.com/arkworks-rs
17:50:27FromDiscord<mratsim> also: https://github.com/dusk-network
17:50:48FromDiscord<mratsim> and: https://github.com/dalek-cryptography
17:51:27FromDiscord<mratsim> and: https://github.com/zkcrypto
17:52:03FromDiscord<konsumlamm> what functions do you think are good to demonstrate at the beginning of the math module?
17:53:10*Lord_Nightmare quit (Quit: ZNC - http://znc.in)
17:53:50FromDiscord<mratsim> 1+1?
17:54:25FromDiscord<mratsim> I think you can demo how to write a gaussian RNG
17:54:59FromDiscord<mratsim> https://en.wikipedia.org/wiki/Box%E2%80%93Muller_transform#Implementation
17:55:33FromDiscord<mratsim> It uses Pi, sqrt, cos, sin log.
17:55:38FromDiscord<mratsim> and it's short and actually useful
17:55:46FromDiscord<mratsim> and it's testable
17:56:28saemClyybber whatever expression is on the other side must really in a type, is or is not in a concept, might or might not be generic (implicit generic is another matter), etc...
17:57:07*abm quit (Quit: Leaving)
17:57:24*abm joined #nim
17:57:43saemClyybber those are the constraints, also the outer most expression is limited, it can't be a proc definition only a type decl for instance.
17:57:57FromDiscord<fwsgonzo> vertcore-qt does not give a receiver address, do I have to wait for it to finish synchronizing with the network?
17:59:20*synshroud joined #nim
17:59:23*Lord_Nightmare joined #nim
18:00:12saemClyybber shipping that narrowing info down stream and those later procs looking for it simplifies things. As you can pattern match against a narrower set of circumstances and not lose the plot.
18:00:59FromDiscord<konsumlamm> looks nice
18:01:59FromDiscord<Clyybber> saem: Hmm, not sure if it really simplifies stuff. We already have that approach in some sense and it's a bit confusing: semExpr semExprWithType etc
18:02:13FromDiscord<Clyybber> saem: "must really be a type" for example isn't so easy
18:02:44FromDiscord<Clyybber> because the return type may be a (when ...: bool else: true)
18:03:16FromDiscord<Clyybber> so its cleaner to delegate resolving the whole expression to a semExpr call
18:03:30FromDiscord<Clyybber> and then check that it produced what we need afterwards
18:04:34FromDiscord<Clyybber> but maybe I misunderstood you (brain autocorrected "in" -> "be":)
18:09:55*VijayMarupudi[m] quit (Ping timeout: 244 seconds)
18:09:56*lytedev[m] quit (Ping timeout: 244 seconds)
18:10:27*stisa[m] quit (Ping timeout: 244 seconds)
18:11:19FromDiscord<mratsim> and then "void" makes a splash in your party
18:11:40FromDiscord<mratsim> and to workaround that I use when compiles(foo(void))
18:23:24*VijayMarupudi[m] joined #nim
18:23:27*lytedev[m] joined #nim
18:24:10*stisa[m] joined #nim
18:25:34FromGitter<Araq> `compiles` is another of these things that has no spec and took months to get into today's shape
18:26:01FromGitter<Araq> for example, when you instantiate a generic within `compiles` it must not be remembered
18:26:02FromDiscord<Rika> ngl id have expected years instead of "just" months
18:30:20*synshroud quit (Quit: ZNC 1.8.2 - https://znc.in)
18:30:36FromDiscord<konsumlamm> how would you tests the RNG? just test some hardcoded values or something more elaborate?
18:30:54leorizeyou test the property of the rng
18:31:54FromDiscord<mratsim> @konsumlamm i think for a small demos you can just use CountTable: https://github.com/numforge/laser/blob/master/benchmarks/random_sampling/fenwicktree.nim#L226-L235
18:32:12FromDiscord<mratsim> just put the counts in a table and check visually.
18:32:22FromDiscord<mratsim> otherwise you need to do hypothesis testing
18:32:50FromDiscord<mratsim> https://github.com/mratsim/trace-of-radiance/issues/2
18:33:11FromDiscord<mratsim> I have no ready-made code for hypothesis testing in Nim though.
18:33:42FromDiscord<mratsim> basically it's overkill for demoing std/math :p
18:34:23FromDiscord<mratsim> so counttable is enough (though use an array instead of Counttable to avoid dependencies on an unrelated module.
18:34:49FromDiscord<mratsim> you can use an array['A'..'Z', int] for example
18:35:30FromDiscord<konsumlamm> and then add any assertions? or whats your plan?
18:40:17*leorize quit (Remote host closed the connection)
18:40:48*leorize joined #nim
18:42:21FromDiscord<mratsim> it's just a demo of how to use the math module now?
18:42:33FromDiscord<mratsim> just make it a runnable example so that it compiles.
18:42:44FromDiscord<mratsim> we don't need to actually fully test it
18:42:45FromDiscord<Daniel> is rng ever trully random?
18:42:54FromDiscord<Daniel> (edit) "trully" => "truly"
18:43:01FromDiscord<mratsim> not on a computer
18:43:36FromDiscord<mratsim> computers react deterministically to events. Well if you discount neutrinos
18:44:02FromDiscord<Rika> it can be random on a computer, given an external data source, cant it?
18:44:23FromDiscord<mratsim> that's what RDRAND and the kernel module try to do
18:44:41FromDiscord<mratsim> but you can manipulate those with something called "environmental attacks"
18:45:07FromDiscord<mratsim> you put a hair dryer next to your computer and suddenly if you were relying on your CPU temperature to generate random numbers they are skewed.
18:45:24FromDiscord<mratsim> RNG broken, RSA key easy to break
18:45:29FromDiscord<mratsim> and you can impersonate someone
18:45:34FromDiscord<mratsim> 😄
18:45:44*salazar joined #nim
18:46:40FromDiscord<Avatarfighter> I was under the impression that HRNG/TRNG's provided a close to true randomness as you can with a computer ? Or rather random enough to seed a pseudorandom number generator?
18:46:54FromDiscord<Avatarfighter> (edit) "a" => "as"
18:47:21FromDiscord<mratsim> What are HRNG and TRNG?
18:47:25*caesarsalad quit (Ping timeout: 240 seconds)
18:47:38FromDiscord<Avatarfighter> Hardware random number generator and True tandom number generator
18:47:41FromDiscord<Avatarfighter> https://en.wikipedia.org/wiki/Hardware_random_number_generator
18:48:05FromDiscord<Avatarfighter> I just curious, would those sources be "random enough" for secure processes ?
18:48:11FromDiscord<mratsim> but if they observe thermal noise you can manipulate the noise with a hair dryer
18:48:45FromDiscord<QueenFuckingAdrielle> sent a long message, see http://ix.io/2O0g
18:48:50FromDiscord<mratsim> if your computer is securing millions of dollars people will try to launch prime95 or furmark on it to try to skew the RNG.
18:48:59FromDiscord<QueenFuckingAdrielle> sorry for text wall, no need to answer now if you are busy lol
18:49:06FromDiscord<Avatarfighter> Have you seen these <https://www.idquantique.com/random-number-generation/overview/> mratsim, its really neat
18:49:50FromDiscord<mratsim> I like this: https://www.cloudflare.com/learning/ssl/lava-lamp-encryption/
18:49:56FromDiscord<Avatarfighter> Oh yeah that's so cool
18:50:08FromDiscord<Avatarfighter> I was mindblown when I read that cloudflare had a wall of lava lamps !
18:50:18FromDiscord<QueenFuckingAdrielle> also slide is memory bound, so epyc cpu cache size vs avx 512 is basically the toss up
18:50:27FromDiscord<mratsim> and the league of entropy: https://blog.cloudflare.com/league-of-entropy/
18:51:10FromDiscord<mratsim> @QueenFuckingAdrielle Ah I know about slides, impressive stuff
18:52:48FromDiscord<Avatarfighter> Thanks for the links mratsim, I've always been curious about all things cryptography and this is great 🙂
18:52:52FromDiscord<mratsim> Looking at the algorithm, either it's bounded by hashtable speed or by the actual computation. If it's the hash table you need a more tuned hash table and AVX512 won't help.
18:52:55FromDiscord<QueenFuckingAdrielle> im interested to see what SVE2 ends up like
18:53:30FromDiscord<mratsim> if it's actual computation, AVX512 will help provided you use a well optimized library like Intel oneDNN.
18:53:57FromDiscord<mratsim> but don't buy the i9-9XXX series which is what I have
18:54:13FromDiscord<mratsim> the downclocking is quite severe 600MHz even though my CPU is watercooled
18:54:25FromDiscord<QueenFuckingAdrielle> i was looking at 10980xe for a workstation and then waiting for the next xeon sp w/ pcie 4
18:54:29FromDiscord<mratsim> the 10XXX have 300MHz I think (?)
18:54:41FromDiscord<QueenFuckingAdrielle> we have epycs rn but they are early gen
18:54:45FromDiscord<Rika> mratsim do you think the noise generated by a camera sensor when it is looking at something dark is truly random?
18:55:02FromDiscord<mratsim> i have no idea
18:55:07saemClyybber: I think when is nice because it isn't as context sensitive. With the dot operator issue in t11166 we know it looks like a simple type expression ahead of time, but the tyProxy as the type for the "receiver" is sometimes ok because it seems in some cases that can be resolved and in this one it's an error. But knowing when to differentiate isn't easy to determine.
18:55:40FromDiscord<Avatarfighter> @Rika <https://ieeexplore.ieee.org/abstract/document/8755833>
18:55:41FromGitter<Araq> tyProxy is an alias for tyError and only used as tyError
18:55:48FromDiscord<mratsim> @QueenFuckingAdrielle you can use this to benchmark your FLOPS: https://github.com/Mysticial/Flops/
18:55:52FromGitter<Araq> (to the best of my knowledge)
18:56:14FromDiscord<mratsim> there is a benchmark of my PC and a friend dual Xeon gold in laser repo: https://github.com/numforge/laser/tree/master/benchmarks
18:56:29FromDiscord<QueenFuckingAdrielle> so you recommend using oneDNN? where do you feel arraymancer is at?
18:57:11FromDiscord<mratsim> Unfortunately, it doesn't have enough layers, I have CNN, Linear, GRU the reshaping layers
18:57:26FromDiscord<mratsim> but there is no advanced layer to do say object detection, or Transformers
18:57:29FromDiscord<Rika> @Avatarfighter so basically it is, and the lava lamp idea was totally fuckin overkill?
18:57:35FromDiscord<Rika> lol nice
18:57:47FromDiscord<Avatarfighter> There is no such thing as overkill for the lava lamp
18:57:51FromDiscord<Avatarfighter> that was plain cool !
18:57:53FromDiscord<Avatarfighter> ahah
18:58:04FromDiscord<QueenFuckingAdrielle> so pound for pound, what do you think is faster for simple dense multilayer?
18:58:22FromDiscord<mratsim> alternatively you can use Flambeau, https://github.com/SciNim/flambeau but it uses precompiled libtorch, and you would need to compile libtorch oyurself with oneDNN to use Intel AVX512 features across the board
18:58:27FromDiscord<QueenFuckingAdrielle> we are using a federated learning system
18:58:50FromDiscord<mratsim> how big are your dense layers?
18:59:18saemAraq: yup, thankfully someone left a comment describing that too. ;) I tried to use that information to fix it but ended up trigger other failures. Memory is fuzzy as to the different places I tried. I'll give it another shot tonight, I think the sleep is helping it make sense.
18:59:26FromDiscord<mratsim> because if it's less than 1000x1000 you reach a bottleneck in what you can partition
18:59:46FromDiscord<mratsim> but currently I would buy AMD THreadripper for a perf/cost ratio
18:59:53FromDiscord<QueenFuckingAdrielle> no it is larger than that
19:00:12FromDiscord<mratsim> cache is so so important.
19:00:43FromDiscord<QueenFuckingAdrielle> it varies, depends on the inputs, we are trying to tune model size / granularity rn
19:01:28FromDiscord<QueenFuckingAdrielle> hmm im wondering if avx will be worth it or not.
19:01:55FromDiscord<QueenFuckingAdrielle> i feel like epyc is more of an independent variable at this point
19:02:11FromDiscord<QueenFuckingAdrielle> cache+lanes+cores
19:02:24FromDiscord<QueenFuckingAdrielle> i will have to benchmark then
19:03:24FromDiscord<mratsim> AVX2 is quite fast already
19:03:49FromDiscord<mratsim> the issue with AVX512 is how to feed data fast enough to the CPU given that they can only do 2 load per cycles
19:03:51FromDiscord<QueenFuckingAdrielle> its true, support is more mature as well
19:04:07FromDiscord<mratsim> and AVX512 consumes power and produces heat like crazy
19:04:40FromDiscord<QueenFuckingAdrielle> the though crossed my mind to try to get some of the next gen low power nuc and string them together and do a distributed test, i wish i had the money to spend on that
19:04:45FromDiscord<QueenFuckingAdrielle> be interesting at least
19:05:36FromDiscord<mratsim> I wrote benchmarks for AVX2 and AVX512 here: https://github.com/mratsim/weave/tree/master/benchmarks/matmul_gemm_blas
19:06:02FromDiscord<mratsim> including MKLDNN/oneDNN, my own written from scratch code, OpenBLAS, BLIS
19:06:24FromDiscord<mratsim> MKL is intel specific in terms of optimization (but MKLDNN works on AMD).
19:06:59saemMy present working hypothesis is that as soon as some bit of information is determined it should go in a known place. There should be the fewest number of places (ideal is 1) for determining some information. Building on that, querying a specific type of information and the way it's updated should be consolidated. The repetition I'm presently seeing runs counter to that and so that's why I'm asking if those principles
19:06:59saemresonate and if so would tests+PRs in that direction be welcome?
19:06:59FromDiscord<mratsim> a dense layer is just matrix multiplication
19:07:31FromDiscord<mratsim> what is interesting with MKLDNN is that they fuse the activation layer with the matrix multiplication so the activation becomes zero-cost
19:08:04FromDiscord<mratsim> it's done in a memory-bound part of multiplication so the compute of relu or tanh is cheap
19:08:04FromDiscord<QueenFuckingAdrielle> ah thats cool
19:08:14FromDiscord<mratsim> also it's done when data is hot in cache
19:08:14FromGitter<Araq> saem: yes.
19:08:27FromDiscord<QueenFuckingAdrielle> thats an interesting optimization
19:08:38FromDiscord<mratsim> the fusion is done here: https://github.com/mratsim/weave/blob/master/benchmarks/matmul_gemm_blas/gemm_pure_nim/common/gemm_ukernel_generic.nim#L75-L78
19:08:51FromDiscord<mratsim> I didn't have the time to implement it though
19:09:20FromDiscord<Clyybber> saem: Yeah, that makes sense IMO
19:09:43FromDiscord<QueenFuckingAdrielle> very cool
19:09:53FromDiscord<QueenFuckingAdrielle> that gives me some things to chew on for a bit
19:10:59FromDiscord<mratsim> if you are interesting in over the top optimizations, those are the papers: https://github.com/mratsim/weave/blob/master/benchmarks/matmul_gemm_blas/gemm_pure_nim/common/gemm_tiling.nim#L12-L30
19:11:21FromDiscord<mratsim> example of register level optimizations: https://github.com/mratsim/weave/blob/master/benchmarks/matmul_gemm_blas/gemm_pure_nim/common/gemm_tiling.nim#L111-L146
19:11:43FromDiscord<mratsim> and trying to goad the L1, L2 and TLB cache into playing nicely: https://github.com/mratsim/weave/blob/master/benchmarks/matmul_gemm_blas/gemm_pure_nim/common/gemm_tiling.nim#L292-L313
19:12:14FromDiscord<QueenFuckingAdrielle> nice this is very helpful
19:12:15FromDiscord<mratsim> one thing is that for compute bound workload, hyperthreading will have the 2 siblings core compete for memory boundwidth and flush each other caches
19:12:34FromDiscord<QueenFuckingAdrielle> yea we have run into that already quite a bit
19:12:35FromDiscord<mratsim> also laser/research folder has pelnty of references as well: https://github.com/numforge/laser/blob/master/research/convolution_optimisation_resources.md
19:12:42saemAraq & Clyybber: cool, then I'm good. I'll try and make tiny changes in that direction as needed, with tests that hopefully serve as a spec, just please forgive the fact that it might not look great at first as things settle.
19:13:01FromDiscord<QueenFuckingAdrielle> we were running a large actor system, but it thrashed the eff out of the cache
19:13:37FromDiscord<QueenFuckingAdrielle> we thought some clever out-of-core work would prevent it but it didnt cut it
19:13:48FromDiscord<QueenFuckingAdrielle> sort of like channel bonding for ipc
19:13:51FromDiscord<mratsim> If your runtime is designed for IO it will likely hook into the kernel and then the kernel cache will get into your L1 on syscalls.
19:14:03FromDiscord<mratsim> and poof performance
19:14:53FromDiscord<QueenFuckingAdrielle> gotcha, yea we are still researching, we have a stable version for the actual robotics work
19:15:01FromDiscord<QueenFuckingAdrielle> but we want to optimize it as much as possible
19:15:19FromDiscord<mratsim> well if you need help at one point, feel free.
19:15:26FromDiscord<QueenFuckingAdrielle> mostly just vanilla cuda on stable
19:15:33FromDiscord<QueenFuckingAdrielle> okay cool thnx!
19:15:43FromDiscord<mratsim> I didn't add Cuda support to Weave yet.
19:16:04FromDiscord<mratsim> see: https://github.com/mratsim/weave/issues/133
19:16:10FromDiscord<QueenFuckingAdrielle> gotcha, yea thats a pain im sure
19:16:46FromDiscord<mratsim> basically handles all the streams and events in a runtime with the same abstraction as CPU.
19:17:10FromDiscord<QueenFuckingAdrielle> we are using tflow, tensorrt, and occasionally tensorforce
19:17:32FromDiscord<mratsim> btw, oneDNN has an OpenCL backend now
19:17:36FromDiscord<QueenFuckingAdrielle> we are pretty dependent on the jetson ecosystem for hardware onboard the robot
19:17:41FromDiscord<mratsim> ah i see
19:17:46FromDiscord<QueenFuckingAdrielle> nice i will look into that
19:17:54FromDiscord<QueenFuckingAdrielle> yea model conversion hell...
19:18:09FromDiscord<mratsim> AMD HIP is pretty fun for conversion
19:18:22FromDiscord<mratsim> it's basically sed/cuda/hip/g
19:18:30FromDiscord<mratsim> cudaMalloc becomes hipMalloc
19:18:41FromDiscord<mratsim> and hip can compile on AMD, Cuda, OpenCL
19:18:54FromDiscord<QueenFuckingAdrielle> oh thats awesome
19:19:09FromDiscord<QueenFuckingAdrielle> i wonder if we could pull that in
19:19:19FromDiscord<QueenFuckingAdrielle> thats a huge bottle neck in workflow
19:19:47FromDiscord<QueenFuckingAdrielle> well i gotta get back to work, but thank you for your time!
19:30:30FromDiscord<Meowx> @WitCoffee I guess something is wrong with the current imgui bindings. An old project just renders fine but rebuilding it makes it render in pinkish colors and you can't interact with anything. Using the same cimgui library
19:31:51FromDiscord<WitCoffee> @Meowx I got into some trouble upgrading to the latest 1.80 version, so the bindings are aimed for 1.79
19:33:02FromDiscord<WitCoffee> If you could please verify that the DLL you are generating is for the correct version. If not, try using the C++ backend
19:33:48FromDiscord<WitCoffee> I will upgrade them to the latest version in the following days, just need to find some free time haha
19:35:26FromDiscord<Meowx> So we're talking about the cimgui version right
19:36:13FromDiscord<WitCoffee> Yep, I would usually recommend using the fork, but I needed to upgrade it to generate the bindings (still need to solve some issues)
19:36:37FromDiscord<WitCoffee> So if you could please checkout to the correct tag and build the DLL
19:37:45FromDiscord<WitCoffee> If you want to test if this is indeed the cause, you can use the C++ backend since this staticly links the correct version
19:39:40FromDiscord<Meowx> I gonna try to use the example with a 1.79. I actually would prefer to compile my stuff into c. Currently just rebuilding an older project with the same cimgui (I guess it was 1.79 back then) just leads into: https://prnt.sc/xzobrl
19:40:57FromDiscord<WitCoffee> Yes, using the C++ is just to verify if the issue is indeed with the DLL (my suspicion), using a DLL of 1.79 should fix it with the C backend
19:54:26FromDiscord<Meowx> @WitCoffee 1.79 works. So I actually had to use the correct 1.79 bindings and imgui aswell (makes sense). Git clone just mixed stuff up there I guess
19:55:20*natrys quit (Quit: natrys)
20:03:36*hmmm joined #nim
20:19:51*koltrast_ joined #nim
20:26:01*Jjp137 quit (*.net *.split)
20:26:02*krux02 quit (*.net *.split)
20:26:02*koltrast quit (*.net *.split)
20:26:02*oswin[m] quit (*.net *.split)
20:31:45*krux02 joined #nim
20:33:22*oswin[m] joined #nim
20:42:40FromDiscord<--HA--> I wanted to update a project from nim 1.2.6 to 1.4.2 and I get a few <lent ...> cannot be captured as it would violate memory safety errors. Using -d:nimWorkaround14447 as suggested in the error message does indeed help but I don't know what that does and if and how I should change my code.
20:57:14*liblq-dev quit (Quit: WeeChat 3.0)
20:59:52FromDiscord<--HA--> Hm, could be it happens when using a template inside another one. Like the it ones from sequtils.
21:00:25*narimiran quit (Ping timeout: 240 seconds)
21:00:55leorizeyou would want to look at any piece of code iterating through an array/seq with `for` loops
21:01:36leorizeyou were probably capturing the `lent T` via a closure or smt
21:07:30FromDiscord<zidsal> I'm trying to debug my program to see why tests are failing in visual studio code. I'm doing this on windows with gdb. I've successfully managed to get a breakpoint in. Is there anyway to get the variable tab in visual studio code to display nice readable data? or do I need to strictly use the debug console like in https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html#using-gdb-lldb ?
21:15:12FromDiscord<Recruit_main707> @zidsal it is possible, i have seen it, but i dont know how to do it
21:16:12leorizesaem: has there been any new developments regarding nimsuggest?
21:26:45saemleorize: a few small ones, there is a big quality of life/suggestions related fix in sem that'll impact suggest a lot, but it's a bit tricky chasing down the fix.
21:27:27leorizelet me know if there are any breaking fix so I can patch nim.nvim
21:28:31saemleorize: I'm trying to avoid those like the plague. 😁
21:29:04saemThere are a few which depending upon how much you assumed about the output that could be a bother.
21:29:26saemFor example deprecated symbols are deprioritized.
21:29:57saemI don't remember if I started to introduce more distinctions in the match quality score.
21:30:31FromDiscord<Meowx> Any nimish way to split an sequence to chunks?
21:31:00leorizesaem: the score is so useless that I never used it :P
21:32:01FromDiscord<mratsim> how can that be :/ https://media.discordapp.net/attachments/371759389889003532/805913368765399080/unknown.png
21:35:04*caesarsalad joined #nim
21:35:08*salazar quit (Ping timeout: 265 seconds)
21:35:54FromDiscord<mratsim> seems like I'm stuck with concept because generics don't resolve my types properly :/ https://media.discordapp.net/attachments/371759389889003532/805914345166077972/unknown.png
21:56:46reversem3How do I sample this example https://nim-lang.org/docs/jsffi.html#%25%3D%2CJsObject%2CJsObject
21:57:11reversem3How do I call that jquery proc
22:10:48*PMunch quit (Quit: leaving)
22:15:19*Jjp137 joined #nim
22:21:44FromDiscord<treeform> I am I correct in that Nim stdlib can't format floats with US commas "1,123,232,233.99" using https://nim-lang.org/docs/strformat.html ?
22:22:16*jjido joined #nim
22:25:09*Amun_Ra quit (Ping timeout: 264 seconds)
22:25:50jjidowhat's that comment about disruptek? What did s/he do?
22:27:00FromDiscord<Avatarfighter> jjido: Araq’s decision to ban disruptek was due to disruptek’s constant bullying of dom96, I can find the irc log
22:27:21jjidoah ok
22:27:23FromDiscord<Avatarfighter> https://irclogs.nim-lang.org/30-01-2021.html#12:16:08
22:27:31FromDiscord<Avatarfighter> yeah :/
22:28:37FromDiscord<Avatarfighter> It’s an understandable decision though
22:28:47FromDiscord<Avatarfighter> I just hate that it had to come to that :/
22:29:06FromDiscord<treeform> he was muted for a while because of that and continued?
22:29:31FromDiscord<Avatarfighter> I didn’t know he was muted previously
22:29:50FromDiscord<Avatarfighter> i thought he left bc Ar@q asked him to
22:30:05FromDiscord<treeform> I don't know the full story
22:30:21jjidoNot nice. Hope everything resolves eventually
22:30:51FromDiscord<Avatarfighter> me neither, I just know that previously disruptek had left the IRC
22:31:33*Amun_Ra joined #nim
22:31:48FromDiscord<Clyybber> > I just hate that it had to come to that :/↵Same :(
22:39:40*a_chou quit (Quit: a_chou)
22:46:28jjidoI am interested in CPS, but not sure I can dedicate time to look at it
22:46:52hmmmah don't worry disruptek has tick skin, we'll see him around sooner rather than later. Last time it tooks 2 weeks, but he came back :>
22:46:59jjidomight try to squash a bug there sometime
22:47:04FromDiscord<Avatarfighter> I'm not so sure hmmm
22:48:20hmmmI hope to get him back he has the a very fascinating kind of flair, I think it's good for the community to have him. Diversity is good
22:48:29hmmmjesus my english today
22:48:33hmmmI'll go to sleep lol
22:49:01FromDiscord<Avatarfighter> Don't sweat it 😛
22:49:04FromDiscord<Avatarfighter> Gn o/
22:49:06hmmm<3
22:49:14hmmmbb happy hacking yall
22:49:21*hmmm quit (Quit: WeeChat 3.0)
22:51:47leorizedisruptek is banned from the nim community as a whole from what I can tell
22:52:31leorizewhile I hope that he returns, he might just move on to something else
22:52:45leorizehttps://github.com/disruptek <- his github no longer features the list of Nim stuff he wrote
22:53:54FromDiscord<Avatarfighter> He changed his github bio from nimion as well 😦
22:53:59FromDiscord<Avatarfighter> this sucks
22:56:37ForumUpdaterBotNew thread by RainbowAsteroids: When should I use tuples over objects?, see https://forum.nim-lang.org/t/7460
22:59:23*JJ15 left #nim ("Leaving")
23:00:01*tane quit (Quit: Leaving)
23:03:04*irchaxwell joined #nim
23:07:15*def- quit (Quit: -)
23:07:27*def-- joined #nim
23:07:52*def-- is now known as def-
23:10:18*reki joined #nim
23:10:25*reki quit (Client Quit)
23:22:41FromDiscord<ElegantBeef> it doesnt such that much, it's not like it wasnt preventable
23:23:24krux02yea, I would have prefered if dom96 would have left the community for good.
23:23:45krux02It's not the first valuable community member that we lost because of him.
23:25:05FromDiscord<mratsim> What?
23:25:37FromDiscord<ElegantBeef> You say it's because of dom, but last i checked saying someone makes dogshit software and is actively ruining the community because of it, isnt on dom
23:25:39FromDiscord<mratsim> You shouldn't rant like that out of the blue.
23:25:57FromDiscord<mratsim> that creates a bad atmosphere.
23:26:45krux02well to be honest, the words were not nice. But the contest was honest and reflected very much what I think as well.
23:27:14FromDiscord<mratsim> I don't think either dom or disruptek are making dogshit software either.
23:27:27FromDiscord<Avatarfighter> imho, I'm almost certain a talk would've resolved issues temporarily even if it were just a bandaid. I'm just sad to see a talented developer leaving a language that needs talent to succeed.
23:27:43FromDiscord<mratsim> Dom needs competition to work on what he started, and he started those at a very young age without any experience.
23:28:00FromDiscord<ElegantBeef> 4raq has talked to disruptek even in voice, it apparently hasnt helped much
23:28:11FromDiscord<mratsim> and Disruptek issues is not about code but fighting spirit
23:28:45krux02Well, I also have a fighting spirit. And I can tell you, when it is there, it needs to vent.
23:28:45FromDiscord<Avatarfighter> I'm more afraid that disrupteks comments reflect a bigger issue that he has identified with Nim as a whole.
23:29:02krux02^
23:29:04FromDiscord<ElegantBeef> Care to elaborate?
23:29:41krux02not here, my words would create bad atmosphere
23:30:22FromDiscord<mratsim> but you don't vent on newbies that just joined and asked a genuine question
23:30:36krux02if you come on irc in ##nimobscene though, np to rant a bit
23:30:52FromDiscord<mratsim> I'm going to sleep.
23:31:04FromDiscord<Avatarfighter> @mratsim o7 thank you for the paper btw
23:31:07krux02he didn't vent on newbies, he vent on dom
23:31:13FromDiscord<Avatarfighter> I'm not disruptek, so I don't know what he may have realized but I do know having such talent leave like this is concerning. That's my opinion at least.
23:31:28FromDiscord<mratsim> he vented on newbies last weekend
23:31:30FromDiscord<ElegantBeef> I mean the reason he left was cause he was being as abrasive as always to dom
23:31:42krux02Well, I left Nim as well. I am not a contributor to the compiler anymore.
23:31:53leorize@mratsim care to link? I wasn't aware of this
23:32:42krux02I just care about the technology and the people attached to it. But there are big structural problems in Nim that are not going to be solved with talent.
23:32:55FromDiscord<mratsim> would have to search, but basically someone asking a question and a joke that could have been taken badly.
23:33:08krux02the joke was great
23:33:11leorizethat's not venting...
23:33:11FromDiscord<Avatarfighter> the whitespace joke mratsim /
23:33:14FromDiscord<Avatarfighter> (edit) "/" => "?"
23:33:43FromDiscord<mratsim> anyway, see you tomorrow
23:33:59FromDiscord<Avatarfighter> Enjoy the rest of your night mratsim, sorry for the disturbance.
23:34:02PrestigeI thought he was banned for being mean to dom, his joke was really funny
23:34:10Prestigebefore being mean to dom I mean
23:34:21FromDiscord<mratsim> you don't get ban for one issue
23:34:26Prestigethat, too
23:34:26FromDiscord<mratsim> it's a pile-up
23:34:29FromDiscord<ElegantBeef> His comment about lqdev posting on TMWN?
23:34:35FromDiscord<mratsim> also he already got banned in September
23:34:43FromDiscord<mratsim> so it's second strike.
23:34:49leorizedisruptek is banned because he was insulting dom
23:34:54krux02There was the joke, dom didn't like it, and disruptek vented on dom
23:34:55leorizethe joke has nothing to do with this
23:35:03FromDiscord<konsumlamm> my experience from hanging around here has been that disruptek was constantly being unfriendly/grumpy while dom was quite friendly
23:35:04krux02the joke started it
23:35:26PrestigeYeah that's accurate konsulamm
23:35:35krux02@konsumlamm: I am grumpy as well
23:35:43krux02you get that with age.
23:35:53krux02Dom is young, he will get there eventually.
23:36:04FromDiscord<konsumlamm> well, i don't really see that with you
23:36:56krux02yea, that is because you were not around when I was venting on 4raq quite intensively and often.
23:37:06krux02it was around march I think
23:37:09krux02last year
23:37:20FromDiscord<Clyybber> yeah you are less grumpy now, for the better
23:37:21krux02wasn't active in nim since then
23:37:35Prestigecompiler gripes?
23:37:39FromDiscord<Clyybber> grumpy is not a thing to aspire to be
23:37:41krux02Nope, I am the same person. I just distanced myself from the Nim project and I am over it.
23:38:11krux02grumpy is what you get when you struggle with frustration for years.
23:38:20FromDiscord<konsumlamm> and before someone tries to tell me what disruptek has done for Nim (i only know that he's been working on CPS), that is no excuse
23:38:42leorizewell I think disruptek is friendly, once you look past his jokes that is
23:39:12FromDiscord<ElegantBeef> He also started the IC
23:39:32PrestigeI like him, but it's not great for newcomers I agree
23:39:37krux02ignoring his personality, he was a long running contributor to nim with Opinions that I did care about when I worked on the compiler.
23:39:40leorizeeveryone forgot about disbot? :p
23:39:53Prestigeidk why disbot was banned :(
23:41:02krux02I don't know disbot, or I forgot him. Can't remember
23:41:11FromDiscord<ElegantBeef> Disbot was disrupteks irc bot
23:41:19Prestige^ it's very useful
23:41:27FromDiscord<ElegantBeef> As is most of disrupteks software 😄
23:41:37krux02yea, didn't use much of it.
23:41:52krux02I know him mostly from his comments on github where I valued them.
23:41:57krux02as a compiler developer.
23:42:40leorizedisruptek is also very helpful torwards newcomers tbf
23:42:50FromDiscord<ElegantBeef> Depends on the day
23:43:11FromDiscord<ElegantBeef> Some days he is actually helpful and other days he says something that doesnt answer the question