<< 27-01-2020 >>

00:03:47*sekao quit (Remote host closed the connection)
00:14:23*Ven`` joined #nim
00:17:30*Ven`` quit (Client Quit)
00:19:29*Jesin quit (Quit: Leaving)
00:31:43*ritchie__ quit (Read error: Connection reset by peer)
00:32:26*ritchie_ joined #nim
00:39:57*gangstacat quit (Ping timeout: 272 seconds)
00:43:28*Jesin joined #nim
00:47:03*gangstacat joined #nim
00:51:39*letto_ joined #nim
00:55:20*letto quit (Ping timeout: 268 seconds)
00:55:26*Hideki_ joined #nim
01:10:10*krux02 joined #nim
01:17:01*Hideki_ quit (Remote host closed the connection)
01:17:37*Hideki_ joined #nim
01:17:52FromDiscord_<Rika> Kinda wish nim had something like go report
01:22:39*Hideki_ quit (Ping timeout: 268 seconds)
01:26:39disruptecwhatsit do?
01:33:49FromDiscord_<Rika> Uh, code quality analysis
01:38:54*krux02 quit (Remote host closed the connection)
01:40:55disrupteci can do that for ya.
01:46:48leorizeAraq: I don't change much other than adding close-on-exec flags for ioselectors
01:47:23leorizethey aren't supposed to be inherited anyway (you can't access them from outer modules), so no escape hatch for them
01:48:30FromDiscord_<Rika> Wait a minute, you aren't disruptek!
01:48:43leorizeso I don't know why it'd be harmful to them?
01:48:49leorizeI don't even change the API
01:50:39*lritter quit (Quit: Leaving)
01:55:01*Hideki_ joined #nim
01:58:20disrupteci'm the kinder, gentler, disruptek.
02:01:16FromDiscord_<exelotl> where's disrupteque? The meeting can't start without him
02:05:54*lritter joined #nim
02:08:35disruptecit's a myth.
02:08:47disruptecnone of us are unique.
02:15:30*lritter quit (Quit: Leaving)
02:19:47FromDiscord_<DeltaPHC> Gotta reduce this repetition. `type Disrupt[T] = object`
02:20:47disruptekhmm, yeah.
02:21:03*disbot is now known as disrupteq
02:21:08disruptekthere we go.
02:21:13disruptecwee
02:21:29*Hideki_ quit (Ping timeout: 265 seconds)
02:21:44FromDiscord_<DeltaPHC> I almost wrote angle brackets there, lol
02:32:35*cron joined #nim
02:48:33*marmotini_ joined #nim
02:51:36*marmotini_ quit (Remote host closed the connection)
03:11:05*theelous3 quit (Read error: Connection reset by peer)
03:15:17*seni quit (Quit: Leaving)
03:27:19*lbart quit (Ping timeout: 258 seconds)
03:38:03FromDiscord_<Skaruts> proc `readBuffer` is complaining it requires `len: Natural` instead `int literal`
03:38:07FromDiscord_<Skaruts> what do?
03:38:54FromGitter<Varriount> Skaruts: Can you post your code?
03:39:18*lbart joined #nim
03:39:27FromDiscord_<Skaruts> `s = stdin.readBuffer(1)`
03:40:17FromDiscord_<Skaruts> `Error: type mismatch: got <File, int literal(1)>`
03:40:50FromDiscord_<Skaruts> `but expected one of: proc readBuffer(f: File; buffer: pointer; len: Natural): int`
03:40:59FromDiscord_<Skaruts> `but expression '1' is of type: int literal(1)`
03:41:44FromDiscord_<Skaruts> first time I'm coming across the `Natural` type
03:45:50*muffindrake quit (Ping timeout: 246 seconds)
03:48:10*muffindrake joined #nim
03:49:40FromDiscord_<Skaruts> actually I'm also missing the buffer parameter there
03:52:48FromDiscord_<Skaruts> either way, I'm looking for a way to detect a key press in the command line, without requiring the user to press enter
03:52:55FromDiscord_<Skaruts> is there any way to do that?
04:03:15*endragor joined #nim
04:18:59*Hideki_ joined #nim
04:22:36disruptekterminal.getch
04:23:31*Hideki_ quit (Ping timeout: 272 seconds)
04:29:13*chemist69 quit (Ping timeout: 272 seconds)
04:30:44*chemist69 joined #nim
04:34:27*rockcavera quit (Remote host closed the connection)
04:35:24*ptdel quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
04:44:16*nsf joined #nim
04:46:57FromDiscord_<Skaruts> ah nice, thanks
05:04:00FromGitter<hlaaftana> does anyone know any possible reason asyncftpclient would upload corrupted images
05:05:00FromGitter<hlaaftana> pngs specifically get corrupted no matter what image it is
05:05:12FromDiscord_<Rika> what proc
05:05:25FromGitter<hlaaftana> store()
05:06:52FromDiscord_<Rika> the code looks ok
05:06:57FromDiscord_<Rika> odd
05:07:15nisstyre what is the status of https://nim-lang.org/0.19.0/channels.html ? It says that the functionality exists in the system module, but I don't see anything.
05:07:26nisstyreI'm guessing the code is deprecated?
05:07:59FromGitter<hlaaftana> the up to date docs are at https://nim-lang.org/docs/channels.html and you need --threads:on
05:08:08nisstyreoh, great thanks
05:08:18nisstyregoogle fails me yet again
05:29:05FromGitter<hlaaftana> figured it out, for images FTP needs to use binary mode, asyncftpclient has no way of setting binary mode/text mode
05:40:49FromGitter<hlaaftana> yep got it working now, have to send "TYPE I". maybe add a procedure to change modes to asyncftpclient
05:43:19disruptekftp is dead.
05:45:14FromDiscord_<Skaruts> is there a non-blocking alternative to `terminal.getch`?
05:45:55shashlickhttps://github.com/genotrance/snip/blob/master/src/snip/key.nim
05:50:58FromDiscord_<Skaruts> thanks
06:30:01*narimiran joined #nim
06:43:05Yardanico@nothratal if you're still here, there's mapIt in sequtils
06:44:22*disruptek quit (Ping timeout: 268 seconds)
06:44:42*disrupteq quit (Ping timeout: 265 seconds)
06:44:59*disruptec quit (Ping timeout: 268 seconds)
06:50:13*disruptek joined #nim
06:51:17leorizeSkaruts: nope, you can try to add it though
06:51:21*disbot joined #nim
07:01:53*cron quit (Quit: Leaving.)
07:37:04*PMunch joined #nim
07:56:14*Vladar joined #nim
07:58:02*solitudesf joined #nim
08:00:00*gmpreussner quit (Quit: kthxbye)
08:04:45*gmpreussner joined #nim
08:16:52*NimBot joined #nim
08:19:13*dddddd quit (Ping timeout: 260 seconds)
08:20:26*Hideki_ joined #nim
08:25:07FromGitter<Varriount> On Linux non-blocking terminal input is relatively easy. On Windows it's... Odd
08:25:14*Hideki_ quit (Ping timeout: 265 seconds)
08:31:18FromGitter<mratsim> @zacharycarter, gcc is installed when you installed mingw32 (which confusingly can be 64-bit)
08:34:07AraqYardanico, stalker! :P
08:34:33YardanicoWhat happened? :D
08:34:46Araqsomebody starred my repo already
08:34:56Araqhttps://github.com/Araq/fosdem2020/tree/master
08:35:18Araqand my suspicion is that it's you
08:35:23Araqam I right?
08:36:40YardanicoNot this time xd
08:36:50YardanicoBut I starred it now anyway
08:37:00FromGitter<alehander92> i saw it as well
08:37:00narimiranAraq: you can check it easily: https://github.com/Araq/fosdem2020/stargazers
08:37:25FromGitter<alehander92> it was on the top of the feed
08:37:30FromGitter<alehander92> my feed*
08:39:43Araqwell now there is no need for me to give the talk anymore, isn't that nice
08:40:12Araqmaybe somebody can replace my ASCII art diagrams for me
08:40:13Zevvso, let's find someone to fill your slot then!
08:40:37Araqor maybe they are really good, it's FOSDEM after all
08:41:07*ritchie_ quit (Quit: Leaving)
08:41:29Yardanicodoes fosdem record all talks? I'd like to watch all Nim talks :P
08:42:10Zevvthey do
08:42:13Zevvthis is 2020
08:42:18Yardanicoright
08:43:18Zevvhttps://video.fosdem.org/ coming to you since 2003 :)
08:44:09FromGitter<zacharycarter> @mratsim - thanks - yeah I think something just got borked when i was unarchiving the mingw64 download
08:44:22FromGitter<zacharycarter> but I got things compiling and running - then realized weave isn't going to help with my issue
08:44:50Araqno, but ARC is going to help you.
08:45:04Araqbecause it helps everybody for everything.
08:45:08FromGitter<zacharycarter> well, not just weave, parallelizing my approach in general
08:45:10FromGitter<zacharycarter> :D
08:45:33Yardanicoarc is gonna save the humanity
08:45:36FromGitter<zacharycarter> I think i just need to optimize my pathfinding algo
08:45:36Yardanicoand reduce the entropy
08:46:18Araqyeah arc makes tea for ya. why not coffee? because it knows better what you really need.
08:50:01FromGitter<alehander92> Araq becoming a teacher is cool
08:50:07FromGitter<alehander92> glad for the guy
08:50:07lqdev[m]then arc is my new fav piece of software.
08:52:03PMunchYardanico, they are also uploaded to YouTube
08:52:12Yardanicovery nice
08:52:25Yardanicoalthough I hope next year I can come to see nim guys in person :P
09:01:40*vesper11 quit (Read error: Connection reset by peer)
09:05:15*vesper11 joined #nim
09:12:47PMunchThat would be nice :)
09:12:54PMunchThe more the merrier
09:13:10FromDiscord_<mratsim> When I saw your pathfinding algo, i do think weave is perfect match for parallelizing it
09:13:40PMunchHow many are we who's going to FOSDEM this year by the way? Is anyone keeping count?
09:13:52FromDiscord_<mratsim> I made with with tree search algorithms that may or may not spawn more node with unknown balancing in mind
09:13:55FromDiscord_<mratsim> Weave*
09:15:14FromDiscord_<kodkuce> isent FFOSDEM 1-2 feb?
09:15:26Yardanicoit is
09:20:55*PMunch quit (Quit: Leaving)
09:21:43*PMunch joined #nim
09:24:38FromDiscord_<kodkuce> "uploaded " got me i thinked its allready online so after ddging was wtf
09:25:16Yardanicoyeah, some nimmers can time travel, but keep it a secret pls :P
09:26:55FromDiscord_<Rika> yardanico have you time traveled far enough to find out the discordnim issue? 😛
09:28:01Yardaniconot yet, im fighting with CERN rn
09:29:33FromDiscord_<moigagoo> Hi! I noticed that the official docs support OS dark mode. Looks great!
09:29:33FromDiscord_<moigagoo>
09:29:34FromDiscord_<moigagoo> Why not include that in the built in doc builder?
09:41:57FromDiscord_<Rika> it's on devel only rn afaik
09:42:08FromDiscord_<Rika> also arent you the loco guy
09:42:35PMunchAraq, by the way, any reason why you are using the old logo on your slides?
09:46:25PMunchRika, the loco guy?
09:49:18*floppydh joined #nim
10:03:10AraqPMunch, I wasn't aware
10:03:15Araqwill see if I can change it
10:03:32AraqI use 'nim rst2html' to build my slides :P
10:05:11*ng0 joined #nim
10:19:53PMunchYeah I saw, interesting approach but the result looks good
10:20:01PMunchWhat do you use to make actual slides out of it?
10:20:49Araqslidy2
10:21:06Araqand a custom nimdoc.cfg
10:21:54PMunchHmm, interesting
10:22:41narimiranPMunch: where can we see the final result?
10:23:11PMunchnarimiran, final result?
10:23:16Yardaniconarimiran: you mean https://github.com/Araq/fosdem2020 ?
10:23:21narimiranyes
10:23:37narimiranPMunch: you said "the result looks good", and i've only seen the raw .rst
10:23:39Yardanicothe final result is there :P
10:23:56Yardanico"chromium move_semantics.html"
10:24:26PMunchYeah, `nim c -r build.nim` then open the `move_semantics.html` file
10:24:31narimiranah, i see
10:25:23narimiranYardanico: i thought it was somehow possible to see it directly from github
10:28:53Yardanicowell yeah you kind can
10:29:24Yardanicohttps://htmlpreview.github.io/?https://github.com/Araq/fosdem2020/blob/master/move_semantics.html
10:29:31Yardanicoit's not fully rendered correctly here though
10:32:58Araqyeah it's not
10:33:23PMunchHmm, so Slidy needs internet to work, as it loads the script and stylesheet from links?
10:33:51Araqfor me it also works offline
10:34:07PMunchProbably because your browser has the files cached
10:34:20PMunchTry to turn off network and hit Shift+F5
10:35:04Araqcan't be bothered right now, sorry
10:36:14Araqhttps://www.w3.org/Talks/Tools/Slidy2/#(6)
10:38:04PMunchOf course, it's possible to make it run offline
10:38:38PMunchJust keep it in mind for the conference :)
10:39:39Araqwhy would my browser lose its cache though
10:39:47Araqor why would I lack wifi
10:39:48FromGitter<juancarlospaco> All Doc pages are Error 403!: ⏎ https://nim-lang.org/docs/theindex.htmlhttps://nim-lang.org/docs/manual.htmlhttps://nim-lang.org/docs/lib.htmlhttps://nim-lang.org/docs/nep1.html ... [https://gitter.im/nim-lang/Nim?at=5e2ebdf4e177666195d88ee4]
10:39:59Yardanicorip
10:40:10FromDiscord_<Auriel> it happened like a minute ago
10:40:20Araqsorry, my fault
10:40:27Araqwe're doing a release :P
10:40:36Yardanicowhich one? :P
10:40:42narimiran1.0.6
10:40:46Yardanicooh okay good
10:42:15Araqlesson: follow the wiki instructions in the right order
10:43:15PMunchAraq, shouldn't happen, but I always like to be extra prepared when I'm doing presentations. Have a back-up on a USB stick if my computer gets stolen or doesn't want to work, make sure that everything runs off-line, etc.
10:43:48Araqit's on github ;-)
10:44:15narimiranPMunch: please make a backup for Araq too :P :D
10:44:49Yardanicoxd
10:53:39*abm joined #nim
10:57:02*chemist69 quit (Ping timeout: 260 seconds)
10:57:58*chemist69 joined #nim
11:01:02PMunchDamn it, I'm slipping down the hole of presentation tools again..
11:01:58AraqPMunch, use my tool ;-)
11:02:34PMunchYeah, I was reading the Slidy slideshow, and it mentioned a couple of others. And off I went :P
11:02:35AraqI've never looked back to latex/office/powerPoint
11:02:50PMunchIt definitely looks promising
11:11:20*JustASlacker joined #nim
11:13:09*Jehan_ joined #nim
11:22:32*Jehan_ quit (Quit: Leaving)
11:32:11narimiranANNOUNCEMENT: version 1.0.6 is available: https://nim-lang.org/blog/2020/01/24/version-106-released.html
11:39:51FromDiscord_<Rika> 😮
11:40:25*salewski joined #nim
11:41:49salewskiHave just shipped gintro v0.7.0 with --gc:arc support, seems to work.
11:42:07Yardanicosalewski: that's amazing news!
11:43:12salewskiYes, I am happy indeed. Had some fear that gintro would not work with new memory management
11:43:24salewskisome weeks ago still.
11:43:36Yardanicodoes --gc:arc work with --threads:on yet?
11:45:15Araqyes, I ported channels and did some tests
11:45:33Yardanicoand with --gc:arc there's shared heap as well?
11:45:38Araqyes
11:46:40Araqneed to do some experiments, an 'isolate' construct seems to be cooler than runtime checking
11:48:10*salewski quit (Quit: WeeChat 2.6)
11:51:02*dddddd joined #nim
12:10:19Zevvsalewski: did you check for leaks?
12:10:33YardanicoZevv: I think GTK checks for leaks itself?
12:10:47ZevvI don't gtk will care about what Nim is leaking
12:22:19*Hideki_ joined #nim
12:26:52*Hideki_ quit (Ping timeout: 260 seconds)
12:59:38PMunchNice 1.0.6 also have my AVR fixes, just in time for FOSDEM :)
13:01:11Zevvso, will you put arc in your talk as well?
13:03:49PMunchIn mine?
13:04:02PMunchI'll have to read up on it in that case :P
13:04:32FromGitter<alehander92> do you have a talk
13:04:37FromGitter<alehander92> what is isolate
13:05:42PMunchalehander92, I have a talk yes
13:05:57PMunchAraq, mratsim, dom96, and I have talks (sorry guys for the ping)
13:06:15FromDiscord_<yewpad> 1.0.6 and Darcula themed documentation wasn't released with it. Yaayyyyy
13:06:29Yardanicopatch are for patches
13:06:31Yardaniconot for features :P
13:06:35Yardanicowelcome to post 1.0 world xdd
13:06:45Yardanicojust /s
13:07:12FromGitter<alehander92> thats a language, not a document generator
13:07:35FromGitter<alehander92> why isnt the theme just a custom css file
13:07:41FromGitter<alehander92> that doesnt need any mainline releases
13:10:10FromDiscord_<yewpad> I'm just saying one could have shipped it with the new release because it is not really a feature but rather indeed a patch for visual reasons. I'm not complaining but I just got hyped when I saw 1.0.6 was released and the Dracula theme didn't come with it. Now I still have to use this ugly ass dark reader extension so my eyes burn away. It's just frustration. Take it with a grain of salt.
13:10:33narimiranthere was 1.0.6-beta released/announced 10 days ago
13:10:36FromDiscord_<yewpad> so my eyes don't burn away*
13:10:57narimiranyou could have easily go through the backported commits and notice that the theme was missing
13:11:00FromGitter<alehander92> but i just cant understand why is this hardwired to the compiler release
13:11:26FromDiscord_<yewpad> Because the docgen is integrated in the compiler. It is not a separate tool.
13:11:35narimiranand you can use https://nim-lang.github.io/Nim/lib.html so your eyes don't need to "burn away"
13:11:46Yardanicoalthough the docs in devel might differ
13:12:15narimiranYardanico: but they'll have their precious darcula
13:12:23Yardanicowell I use dark reader extension anyway
13:12:30Yardanicoso I had dark mode in nim docs even before that theme
13:13:12narimiranbut if "dark docs mode was not backported" is the most important issue of 1.0.6, then we did darn good job!!
13:14:56FromDiscord_<Rika> i'm kinda annoyed that the doc features are coupled with the version, when it doesnt have to be
13:15:25FromDiscord_<yewpad> Funny to see how a rather irrelevant comment expressing frustration quickly evolved into salt. haha
13:15:25*kungtotte quit (Read error: Connection reset by peer)
13:15:36*cgfuh joined #nim
13:15:36narimiranhaha
13:15:48*kungtotte joined #nim
13:22:10FromGitter<alehander92> yewpad yea sorry i guess it would be there in 8
13:22:36FromGitter<zetashift> Ooooh new release congratulations on 1.0.6 whoop
13:27:13*endragor quit (Remote host closed the connection)
13:30:48FromGitter<alehander92> 1) 0.8 sorry*
13:37:50*ptdel joined #nim
13:40:03shashlickAwesome job folks
13:47:30livcdoh salewski is gone :/
14:08:20*Xatenev joined #nim
14:08:44*nsf quit (Quit: WeeChat 2.7)
14:09:03*Xatenev left #nim ("Leaving")
14:11:00*marmotini_ joined #nim
14:12:47*marmotin_ joined #nim
14:14:40*Vladar quit (Quit: Leaving)
14:15:20FromDiscord_<mratsim> gone where?
14:15:46*marmotini_ quit (Ping timeout: 268 seconds)
14:17:23Zevvaway!
14:25:34FromDiscord_<moigagoo> @Rika
14:25:35FromDiscord_<moigagoo>
14:25:35FromDiscord_<moigagoo> > also arent you the loco guy
14:25:35FromDiscord_<moigagoo>
14:25:35FromDiscord_<moigagoo> Yep, I am 🙂
14:26:55FromDiscord_<moigagoo> @Rika
14:26:55FromDiscord_<moigagoo>
14:26:56FromDiscord_<moigagoo> > it's on devel only rn afaik
14:26:56FromDiscord_<moigagoo>
14:26:56FromDiscord_<moigagoo> Does that mean that it's now in Nim 1.0.6?
14:27:11narimirandevel != 1.0.6
14:27:14FromDiscord_<Rika> nope
14:27:33FromDiscord_<Rika> not all things devel are moved into the latest release
14:27:47narimirandevel (1.1.1) is ahead of 1.0.6, and it is a basis for a future 1.2.0 release
14:28:19FromDiscord_<Rika> ~~already at 1.2.0, eh?~~
14:28:41narimiranhuh?
14:30:17FromDiscord_<Rika> nothin, dont mine that
14:30:19FromDiscord_<Rika> mind*
14:45:48dom96congrats on release bois
14:46:01dom96PMunch you making a FOSDEM post on the forum?
14:53:05YardanicoAraq: is it expected for --gc:arc to perform much worse (like 3-4x) when doing stuff like parsing and evaluating a really stupid math expression (string) recursively a few million times?
14:53:32Yardanicowell I mean, you won't notice it unles you'll actually need to calculate some string 500k times a second lol
14:54:03Yardanicohttps://gist.github.com/Yardanico/19f841ce642148f6763b8769729ab366 https://github.com/Yardanico/nim-mathexpr (I know the code isn't the best but it works :P)
14:55:28FromGitter<kristianmandrup> Any good resources for creating binding libs to (client side) JavaScript?
14:56:30*marmotin_ quit (Remote host closed the connection)
14:59:25PMunchdom96, about what?
15:00:33dom96PMunch reminding people that it's happening?
15:05:20*marmotini_ joined #nim
15:05:31PMunchOh, I forget that others live close enough to not have to order plane tickets and such quite a while in advance :P
15:06:06PMunchYeah, I can create a forum post, but possibly not until tomorrow..
15:06:15*PMunch quit (Quit: Leaving)
15:06:41AraqYardanico, never seen a factor of 4 before
15:07:04Yardanicowell, maybe the design of this lib isn't that good :D
15:07:06Araqtry 'nim cpp'
15:07:09Yardanicoah okay
15:09:36Yardanicowith -d:danger I get mean time of 500ms (for 1 mil iterations), with -d:danger --gc:arc it's 2450ms, with cpp and danger and arc its around the same - 2517ms
15:10:42Yardanicohmm, I didn't have a few last commits in devel, I'll try again
15:11:06*cron joined #nim
15:12:01*sagax quit (Remote host closed the connection)
15:12:03Yardanicohmm, no real difference
15:12:17*lritter joined #nim
15:12:22Yardanicowith m&s it's around the same as with default GC
15:12:45Yardanicowith boehm GC it's around 1000ms
15:19:23Araq*shrug* profile it
15:19:45Yardanicowill do a bit later :)
15:19:54*ng0_ joined #nim
15:19:54*ng0_ quit (Changing host)
15:19:54*ng0_ joined #nim
15:20:47AraqI noticed arc consumes much more memory as Nim's allocator is wasteful for 'alloc'
15:21:18Araqand memory is slow, I doubt it's the reason for your case though
15:21:40AraqI'm optimizing it further, there is no reason for this except legacy code
15:23:47*ng0 quit (Ping timeout: 268 seconds)
15:26:50*nsf joined #nim
15:28:02*nc-x joined #nim
15:28:41nc-xAraq: what's arbitrary in https://github.com/nim-lang/Nim/pull/13261?
15:28:42disbotdisallow typedesc in arrays
15:28:42*sagax joined #nim
15:29:04nc-xi haven't checked types.typeallowed yet
15:29:06nc-xbut
15:29:40nc-xhttps://github.com/nim-lang/Nim/blob/32f0910f11acd88b10422d6dc20477747cda687d/compiler/semstmts.nim#L457
15:30:18nc-xcode almost similar to my patch already exists
15:30:30nc-xand i just added an elif branch there
15:31:22*nc-x quit (Remote host closed the connection)
15:36:22*ng0_ is now known as ng0
15:39:34leorizeYardanico: try -d:useMalloc too :P
15:39:41Yardanicoleorize: I tried, it's the same :(
15:47:52Yardanicowell, it seems that with c -d:danger --gc:arc most of the time is spend in a lot of "eqdestroy" calls
15:48:20Yardanicohttps://i.imgur.com/fwrbiP4.png
15:50:28Yardanicopart of compiled C code:
15:50:33Yardanicoblob:https://imgur.com/523ad044-563d-4105-b621-56937d885510
15:50:42Yardanicosorry https://i.imgur.com/WDaBNHF.png
15:51:05Yardanicoalso https://i.imgur.com/OUwxrX4.png is kinda strange
15:51:54Yardanicofull file - https://gist.github.com/Yardanico/19058c4c6c11f9eb810599f73fb45f49
15:53:18Araqnc-x: well it was bad before and you made it worse
15:53:31Yardanicoahh maybe it's due to my code having "template" for a few procs I use
15:53:34Araqat one point I have to say "stop!"
15:54:27leorizeI'd be worried if template causes your code to be slower :P
15:56:47Yardanicowell I got around 2x faster speed (so still ~2x times slower than default GC) when making procs instead of templates
15:57:13leorizehmm, can `=destroy` be inlined?
15:57:23Yardanicothe relevant code part is stuff here
15:57:23Yardanicohttps://github.com/Yardanico/nim-mathexpr/blob/master/src/mathexpr/expr_eval.nim#L91
15:57:38Yardanicoall getArg() and getArgs() calls are templates (to type less :D)
15:57:52Yardanicoand then they call the actual proc (and they're dirty templates too)
15:58:33YardanicoI should probably rewrite that case branch to something else so that I can only call getArgs in one branch once I guess
15:58:47Yardanicoright now it's called in all of these "of" branches
15:59:10leorizeyou can compile your code with --expandMacro:getArgs to get the resulting inlining I think
15:59:58Yardanicowell it's a template not a macro ;)
16:00:00*Vladar joined #nim
16:00:52leorizeiirc that switch work for both
16:00:53Araqtemplate getArg(): untyped {.dirty.} =
16:00:53Araq expr.getArgs(1, funcName)[0]
16:01:07Araqleorize, no only for macros
16:01:22leorizeah, ok then
16:01:25Yardanicoso just for comparasion with the C code file above, this is the same but with default GC - https://gist.github.com/Yardanico/fbdb29c1590ecd01f05558b9971fcc8b
16:01:31YardanicoAraq: yeah, I understood why it's slow :)
16:01:37Yardanicojust was surprised that it's 4x slower with --gc:arc
16:02:43Araqwell so I am
16:03:11Araqthe C code is much bigger but your icache is likely large enough
16:03:29Araqand the many seq creations that you do have to be cleaned up either way
16:03:40Araqarc does it asap, the old GCs do it from time to time
16:03:49Yardanicoah, makes sense why it's faster the
16:03:50Yardanicon
16:04:02Araqno, it makes no sense to me
16:05:48Araqah
16:05:59Araqhmm ok, I think I know
16:07:26Araqyeah ok, need to think about it
16:07:35Araqthe way we introduce temporaries is stupid crap
16:08:19Araqyou can split up 'parseFactor' further into more smaller procs
16:08:27Araqand see if makes a difference
16:08:43Araqbut it's definitely something we need to change in the backend
16:09:27leorizeanyone know how components in Karax is supposed to be used?
16:09:44leorizedo I just make one, store them somewhere, then add them to my buildHtml?
16:09:49leorizebasically a custom node?
16:10:32YardanicoAraq: split up the branches of the "case" to different procs I suppose?
16:10:42leorizewith, uh, manual "dirty" marking so I can save some time to not have to diff them?
16:10:43Araqno, the case is fine
16:10:54Araqbut in every 'of' branch only do call a helper proc
16:11:03Yardanicoah, okay
16:12:04Araqleorize, study experiments/nativenodes.nim
16:13:17AraqYardanico, or turn 'getArg' into a proc
16:13:28Araqyeah start with that.
16:13:40Araqas a template it's a desaster for the codegen
16:16:16leorizeAraq: so I build a dom node, and when I want to update it I just build a new one and let karax do the job?
16:16:38leorizeI thought nativenodes are for interfacing with 3rd party code?
16:16:42Araqleorize, it's been a while but the virtual DOM is stateless
16:16:58Araqand my attempts to introduce state into it have been clusterfucks
16:17:12AraqIMO it's a fundamentally flawed idea
16:17:19YardanicoAraq: well yeah, as I said before when turning them into procs I get 2x faster performance than before (but still 2x slower than default GC) - https://gist.github.com/Yardanico/02cd2dfa6a69aca3b5a70df8eae48056
16:17:20Araqhowever the real DOM is stateful
16:17:32Yardanicoaround 1300ms instead of 2500ms mean time
16:17:44AraqYardanico, factor of 2 is a start though
16:18:23Araqleorize, so for "components" build and use native DOM elements and use 'dthunk'
16:26:21AraqYardanico, also move your 'raise ' statements into helper procs
16:27:12YardanicoAraq: okay, a bit later though. but i'll also move each branch's code into a helper proc like you said
16:27:21Araqbut yeah we need to fix this lol
16:27:36Araqluckily it's not hard
16:39:02disruptekgive the compiler some hope of optimizing your stuff.
16:42:51YardanicoAraq: with procs for all branches it's down to ~850ms
16:42:59Yardaniconow I'll also move exceptions to helper procs
16:44:45Yardanicowith two raise statements moved into helpers procs it's down to 750ms
16:45:09Yardanicohttps://gist.github.com/Yardanico/46d13ace385c3c0c4e46a84256776301 generated C
16:45:15Yardanicocompiled* :P
16:48:36*Vladar quit (Quit: Leaving)
16:51:54leorizeAraq: so afaict, if I want state then I should make a Node then dthunk() it, otherwise just outputing a VNode should be suffice?
16:56:53Yardanicoactually with -d:useMalloc it becomes 650ms
16:59:15Yardanicoso 450ms default GC vs 650ms --gc:arc -d:useMalloc
16:59:19Yardanicomuch better than before :D
16:59:47zedeusnow try mimalloc
17:00:01Yardanicohow? :P
17:00:07*Trustable joined #nim
17:00:18zedeusLD_PRELOAD=/usr/bin/libmimalloc.so myprogram
17:00:24Yardanicowoah
17:00:33Yardanicoi'll try
17:02:22Yardanicowith that it's still the same 650ms, I'm doing "LD_PRELOAD=/usr/lib/mimalloc-1.4/libmimalloc.so ./repl"
17:03:23Yardanicoand it's indeed running, I checked with MIMALLOC_VERBOSE
17:04:26zedeusinteresting
17:04:47Yardanicomimalloc stats - https://gist.github.com/Yardanico/6673c8683f10c41dbf14da1e9bd9de33
17:05:21Yardanicoah let's try the unoptimized version, maybe it'll be better
17:05:40YardanicoI mean the one without splitting stuff into procs
17:07:59Yardanicohm, seems to be around the same as without mimalloc
17:12:20leorizetry jemalloc?
17:13:04Yardanicoi think we're getting too deep right now, it's just a simple math expression evaluator lib, it's not made for high performance :P
17:14:21*marmotini_ quit (Remote host closed the connection)
17:14:39disruptekturn off useMalloc.
17:14:56*marmotini_ joined #nim
17:15:29Yardanicodisruptek: around 50-70ms more for 1 million iterations :)
17:15:39YardanicoI mean it's slower without -d:useMalloc :P
17:15:44disruptekright.
17:19:31*marmotini_ quit (Ping timeout: 265 seconds)
17:26:42Zevvping @clyybber
17:29:16Zevvalso @leorize: is there a way to tell nim.nvim my compiler flags? I often go into the wrong parts of the stdlib because nimsuggest thinks my flags are off - relevant when doing work on the stdlib
17:29:57disruptekZevv: use a nim.cfg.
17:30:23Zevva right. I never do that, but that works of course. You are so smart dude
17:30:52disruptekno, i just rely upon nim.cfg heavily.
17:30:59leorizeZevv: there's a way, but I never added an interface for it :P
17:31:19leorizejust edit autoload/nim/suggest.vim for now
17:31:26leorizethere's the extraArgs there
17:31:31Zevvno way
17:31:32leorizepass them however you like :P
17:31:37Zevvthat's *too* dirty
17:32:10leorizeyou want a better way? copy nimsuggest to the bin/ folder in Nim source
17:32:26FromDiscord_<Clyybber> Zevv: Oy
17:32:27Zevvit already lives there
17:32:48leorizeadd that to your path :P it should pick up the stdlib in the compiler source
17:32:53Zevvclyybber: \o Do you have thoughts about https://github.com/nim-lang/Nim/issues/13240?
17:32:56disbot[ARC] segmentation fault ; snippet at 12https://play.nim-lang.org/#ix=28vy
17:33:18Zevvleorize: no, I mean that the stdlib choices depend on compiler flags. If I do work on gc:arc, I want seq.add to jump to the right seq.add
17:33:31*ptdel quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
17:33:49Zevvclyybber: I'd like to give that a try, but I'm not sure if that is within my current powers yet tho
17:34:00FromDiscord_<Clyybber> Its a codegen issue I think
17:34:25Zevvit is. I'm pretty sure my analasys is right, it's more the question on how to solve that.
17:34:51leorizeZevv: maybe you can patch nim.nvim to take a g:nimsuggest_extra_args array of arguments?
17:34:56leorizeI would merge that :P
17:34:58ZevvSomehow it feels that the thing should stay const - it does not make sense to make it readable, and on ebmedded systems you might want that to go in flash.
17:35:30FromDiscord_<Clyybber> Hmm
17:35:47Zevvleorize: Hm that's a bit too static. environment variable? Or magic vim-style mode line in the code?
17:36:00Zevvleorize: no, the latter makes no sense with multiple files
17:36:31leorizeZevv: you know exrc exists, right? :P
17:36:32FromDiscord_<Clyybber> Zevv: Is the issue that Thing(...) is memset to zero after add?
17:36:43Zevvleorize: nope, let me check that
17:36:59ZevvClyybber: right. It memzeros const data.
17:37:08Zevvwhich might or might not work depending on your system, but it's UB
17:38:03ZevvBut I don't evne understand properly how this works yet, that's part of the problem.
17:38:22ZevvI see the generated C code, but I don't grok the semantics yet
17:38:39FromDiscord_<Clyybber> Zevv: injectdescructors zeroes it out after a bugfix from Ar*q
17:39:05FromDiscord_<Clyybber> But thats correct
17:39:09FromDiscord_<Clyybber> So the issue is in codege
17:39:13FromDiscord_<Clyybber> n
17:39:34Zevvok, but then (/me pushing another sample)
17:40:16Zevvhttp://ix.io/28vB contradicts.
17:40:32ZevvThing is a const. Ergo it should go in romem. but it needs te be zeroed out. Ergo it should be in rwmem
17:40:58FromDiscord_<Clyybber> But consts are not zeroed out afaik
17:41:03FromDiscord_<Clyybber> lemme try
17:42:24leorizeZevv: also, with g:nimsuggest_extra_args, you can populate it with getenv() in your config if you'd like
17:42:39leorizenim.cfg can act on environment variable also, if you're into that
17:42:53disruptekzevv is kinky like that.
17:42:59FromDiscord_<Clyybber> Zevv: yep, not zeroed out or destroyed
17:43:03FromDiscord_<Clyybber> which is expected
17:43:05Zevvleorize: that works, thanks
17:43:13FromDiscord_<Clyybber> I think
17:43:33ZevvClyybber: it stil boom's on me
17:43:57FromDiscord_<Clyybber> Hmm
17:44:09FromDiscord_<Clyybber> I think the issue may be that codegen is trying to const evaluate it
17:44:30FromDiscord_<Clyybber> which is too late I think
17:44:39FromDiscord_<Tak> (Maybe a stupid question) Can you use the {.inline.} pragma on a lambda expression? Like instead of the sugar x => x, using proc? (Sorry to interrupt)
17:44:52leorizenope
17:44:54Zevvbut then again: if it neednt be zeroed out when it is const - why does it needs to be zeroed out when it is *not* a const?
17:45:02FromDiscord_<Clyybber> It neednt
17:45:11FromDiscord_<Clyybber> I think
17:45:22Zevvright
17:45:33leorize@Tak those has to be passed by function pointers anyway, so you can't inline them anyway
17:45:50ZevvI asked Arq, his answer was that "the destructor needs to be disarmed", but that didn't really make sense to me at the time
17:45:51FromDiscord_<Tak> Ok gotcha thanks 🙂
17:46:20leorizeZevv: ie you freed your pointer
17:46:33leorizeit needs to be zeroed so you won't do it again :P
17:47:06*Zevv will study the generated C code before asking more questions
17:47:37FromDiscord_<Clyybber> Zevv: I think the proper way to fix it is to try to evaluate `Thing(...)` at compile time
17:48:16FromDiscord_<Clyybber> and earlier than in codegen
17:48:28FromDiscord_<Clyybber> probably
17:48:42FromDiscord_<Clyybber> Maybe I'm overthinking things but I think thats what zah had in mind too
17:49:48Zevveffectively it is a const in the #13240 version - the codegen handles it the as in the ixo snippet above it seems
17:49:49disbothttps://github.com/nim-lang/Nim/issues/13240 -- 3[ARC] segmentation fault ; snippet at 12https://play.nim-lang.org/#ix=28vy
17:50:23leorizeZevv: as far as I can understand, the compiler just follow the rules of inserting `eqdestroy` at end of func
17:50:26Zevvmayb it should simply not get finalized if it is a const
17:50:34leorizewasMoved() is used to disable the destructor
17:50:36leorizesee https://nim-lang.github.io/Nim/destructors#destructor-removal
17:50:56Zevvleorize: sure, but can you destruct a const?
17:51:01FromDiscord_<Clyybber> Zevv: Another way to fix it is to replicate the logic of the codegen in injectdestructor
17:51:09leorizeZevv: of course you can't :P
17:51:17Zevvleorize: so there you have it
17:51:17FromDiscord_<Clyybber> lets ask Araq
17:52:16Zevvso we should let the `const Thing()` live long and happy in const land
17:52:37ZevvThat's what you get from all that casting to void* and ignoring the warnings of the C compiler
17:52:37disrupteki don't understand why we don't just point to the destructor and then when we want to disarm, just point to a "destructor" that does nothing. just, always have a pointer to the next state.
17:52:40*Zevv ducks
17:53:18FromDiscord_<Clyybber> disruptek: Eh, that doesn't work
17:53:25disruptekwhy not?
17:53:30FromDiscord_<Clyybber> How can we point to a destructor in a const?
17:53:40FromDiscord_<Clyybber> and then change it?
17:53:44FromDiscord_<Clyybber> same problem
17:53:51disruptekthe const can point to a special "const destructor" that breaks.
17:54:03disruptekso we know why, etc.
17:54:07FromDiscord_<Clyybber> seems like a workaround
17:54:18disruptekno, because it solves the problem elegantly for non-consts.
17:54:26FromDiscord_<Clyybber> Which problem?
17:54:34disruptekthe problem of eliding destroys.
17:55:05*floppydh quit (Quit: WeeChat 2.7)
17:55:08disruptekwhy aren't you going to fosdem?
17:55:43Yardanicowhat about you?
17:56:24*abm quit (Quit: Leaving)
17:58:33disruptekme?
17:58:35Yardanicoyou
17:58:45disrupteki'm going.
17:58:54disruptekif i can find my passport, i mean.
18:02:01FromDiscord_<Clyybber> disruptek: no time : /
18:02:20FromDiscord_<Clyybber> disruptek: we elide destroys via zeroing out
18:02:31FromDiscord_<Clyybber> I think its faster that way
18:02:40FromDiscord_<Clyybber> and makes our objects smaller : )
18:02:57disrupteksure, they are smaller, but it's clearly not faster.
18:03:21FromDiscord_<Clyybber> disruptek: I think it is
18:03:38FromDiscord_<Clyybber> At least the C compiler is more free to optimize stuff
18:03:38disruptekwell, i think it's not.
18:04:10FromDiscord_<Clyybber> And then destructors can be inlined
18:05:00FromDiscord_<Clyybber> And I think its best to elide as much as possible at compile time
18:05:02disruptekdestructors are O(n) while swapping a ptr is O(1).
18:05:46*marmotini_ joined #nim
18:06:07leorizenote that nim objects are used for C FFI also
18:07:27FromDiscord_<Clyybber> disruptek: But the stuff destrucros zero out are pointers most of the time
18:08:04disrupteki'm not saying they won't run, i'm saying they will run only once.
18:11:38FromDiscord_<Clyybber> Yes, but that is possible with the zero-out approach too
18:17:42disruptekthe state needs to be stored somewhere. you can store it at runtime, or you can prove the state at compile-time. i thought we had a situation where we simply could not prove state at compile-time, but maybe i'm wrong.
18:18:04*Ven`` joined #nim
18:18:39FromDiscord_<Clyybber> nah we can
18:19:04FromDiscord_<Clyybber> sometimes we can't
18:19:31disrupteklet me know what you decide.
18:19:38FromDiscord_<Clyybber> but it doesn't seem worth it to attach a function pointer to every instance of an object just because we can't elide it once at ct
18:20:20disruptekon the contrary, it's not worth performing operations at runtime that are unnecessary.
18:20:27FromDiscord_<Clyybber> yes
18:20:30FromDiscord_<Clyybber> ideally
18:20:58FromDiscord_<Clyybber> you would be able to use everything as an indicator for something being zeroed out
18:21:16FromDiscord_<Clyybber> so you could I dunno use the first bit of a pointer or something
18:21:23FromDiscord_<Clyybber> but rn that doesn't work
18:21:39FromDiscord_<Clyybber> because we assume zeroing out rn
18:22:50FromDiscord_<Clyybber> in fact when you'd be able to overwrite wasMoved it would be possible to employ your approach using the existing hooks
18:31:08*ptdel joined #nim
18:35:48*sagax quit (Ping timeout: 248 seconds)
18:38:49*marmotini_ quit (Read error: Connection reset by peer)
18:43:57*Pqzcih5 joined #nim
18:46:37AraqClyybber: there codegen tries to optimize 'let' to 'const
18:46:53Araqand this is safe since you cannot mutate a 'let' either
18:47:06Araqinfortunately destructors and wasMoved do mutate
18:47:28Araqso for the codegen the 'let' is a lie and it should do a deeper analysis. but it doesn't
18:47:49Araqwe can move the logic into injectdestructors
18:48:11Araqwhich does know about wasMoved
18:49:25Zevvso http://ix.io/28vB will work as well, we will simply not move/destroy consts
18:51:52*nsf quit (Quit: WeeChat 2.7)
18:52:21AraqClyybber: Yardanico found out my way of using top level temps is terrible for performance
18:52:37Araqwe need to inject destructors based on scoping
18:53:22Zevv\o/
18:53:52AraqGCC is bad at optimizing my way
18:54:00Araqand probably most other compilers are too
18:54:28*rockcavera joined #nim
18:58:05FromGitter<bpr> For FOSDEM slides, I suggest changing "inofficial" to "unofficial". At least to this American reader, inofficial sounds wrong.
18:58:22Araqthanks
18:59:18FromGitter<bpr> You're welcome, and thanks for making those slides available.
18:59:19Araq"inofficial" seems to exist but my dict says it's "rare"
19:00:08FromGitter<bpr> Yes, I checked too before I commented. It's not that I don't get the meaning, but I've always seen it written as unofficial.
19:00:58FromGitter<bpr> I wonder if it sounds that way to other denizens of the Anglosphere...
19:02:52disruptekyep.
19:07:00Araqbpr: how much do you understand without my speech?
19:07:27AraqI expect these slides to be easy enough to follow if you happen to know c++ well :P
19:15:28*letto_ quit (Quit: Konversation terminated!)
19:17:32*letto joined #nim
19:17:44FromDiscord_<Clyybber> Araq: Nice!
19:17:53FromDiscord_<Clyybber> Scope based approach is the way to go
19:17:55FromGitter<bpr> I know C++ moderately well. Not sure what knowing C++ "well" means ;-). I'm also getting more familiar with Rust by use at work. I'm familiar enough with move semantics and rvalue references that the discussion was easy enough to follow, and I bet that is true for most who know the basics of either C++ or Rust.
19:18:22Araqok, good
19:18:23FromDiscord_<Clyybber> Will allow us to elide many more wasMoved + destroy pairs
19:19:33FromGitter<bpr> It will take more time for me to internalize Nim's approach, but that will come with interacting with the compiler, and the docs.
19:20:29disruptekthese slides look great to me.
19:20:57leorizeAraq: re: using dthunk() to do components: how am I supposed to update them?
19:21:19disruptekthey are maybe a little wide. hard for me to tell.
19:21:42Araqyou update the "captured" DOM elements in an event handler
19:22:13Araqthe 'dthunk' wrapper means "use this DOM directly"
19:22:17leorizeyou mean using the dom apis directly?
19:22:43Araqdepends but yes
19:22:46leorizeI hoped that I could just have karax help me with the diffing so I can just apply it to Node :P
19:23:12Araqthen why do you have stateful stuff inside
19:23:23AraqDOM diffing hates hidden state
19:23:51leorizeI have a clock, it ticks
19:24:30Araqultimately all this stuff doesn't work well and DOM diffing is the most terrible abstraction inversion that I've ever seen
19:26:52disruptekAraq: you need to show, somewhere, that you're running these benchmarks with, eg. "21" as an argument.
19:27:30Araqdisruptek, good point
19:34:16*sagax joined #nim
19:39:50*Yardanico quit (Ping timeout: 258 seconds)
19:39:57*Yardanico joined #nim
19:41:17leorizeAraq: I guess something like this: http://ix.io/28w7 is my best bet at making a clock "component"?
19:42:50Araqdoesn't look right
19:47:45leorizehow do you think this should be done?
19:50:04Araqnot at all.
19:51:14Araqbut if you really want to, a component is a Node
19:51:33Araqand dthunk() does the bridge into VNode land
19:52:05Araqyou can construct the Node via Karax's vnodeToDom() API
19:52:22Araqas I said, study nativenodes.nim
19:52:40Araqyes it's only 18 lines. but you need to study them.
19:53:50Araqand if you're successful, document it well and contribute to Karax
19:54:15leorizeI've given it a good read and my conclusion is that I've to manually modify it :/
19:54:37leorizeeasy for a clock, much more complex for a carousel for example :/
19:55:21*tane joined #nim
19:57:16leorizeactually, is there any js stuff that let me replace a node with another without changing the reference?
19:57:33leorizethat'd make things easier since I can render a node from vdom and swap it over when needed
19:57:37leorizegonna look around a bit
20:01:19Araqalso look into knete.nim which is Karax's API for the DOM, no VDOM involved
20:02:50Araqit's a bit out of date though
20:04:50AraqI'm still torn, nothing works really well.
20:07:00Araqfor now pass the state around and don't have it in "components", it works best.
20:07:58FromGitter<kristianmandrup> I'm looking into how to write JS bindings
20:08:13FromGitter<kristianmandrup> in Html5Canvas bindings repo
20:08:16FromGitter<kristianmandrup> ```import dom ⏎ include html5_canvas/rgb``` [https://gitter.im/nim-lang/Nim?at=5e2f4330dc0766704202ed90]
20:08:34FromGitter<kristianmandrup> I've never seen the `include` before. I thought it was always `import`?
20:09:26FromGitter<kristianmandrup> Oh :O https://nim-lang.org/docs/manual.html#modules-include-statement
20:10:02FromGitter<kristianmandrup> So the key is to use the `{.emit}` pragma?
20:10:09FromGitter<kristianmandrup> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e2f43a01a1c2739e30e2b87]
20:14:55*NimBot joined #nim
20:21:17leorizeAraq: I figured so
20:21:30leorizeanyway, here's my terrible terrible way to do "components": http://ix.io/28wm
20:25:39FromGitter<kristianmandrup> @disruptek - your github account is a Nim treasure trove :)
20:25:47disruptekwut
20:26:26*narimiran quit (Ping timeout: 240 seconds)
20:26:36FromGitter<kristianmandrup> Lots of good libraries and utils for the Nim eco-system
20:26:56disruptekoh, thanks. just things i wanted.
20:27:19disruptekthoughts on nigel?
20:28:33shashlicklooks fun
20:28:54disruptekshashlick: i will be depending upon you to shoehorn windows into this somehow.
20:29:16disruptekeven if it's via some shim in the backend layer that builds/runs stuff remotely, etc.
20:29:48shashlickwell, i have had no luck getting a windows env up
20:29:57shashlickwill have to resort to manually setting up a vm now
20:29:59disruptekdon't say that; you're the expert.
20:31:36shashlicki now have zero windows dev systems so have been completely blocked for the last 3 days
20:31:41Araqkristianmandrup: for JS interop .emit is the last resort
20:31:50FromGitter<kristianmandrup> Is this the right approach or not?
20:31:57FromGitter<kristianmandrup> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e2f48bd34829272793baca1]
20:32:14Araqwrong
20:32:22Araquse something like
20:32:33disruptekshashlick: i mean, do we really need to test on windows?
20:32:41FromGitter<kristianmandrup> I tried to use approach I found in `Html5Canvas` bindings
20:32:42disruptekyou don't even have a windows machine.
20:32:59Araqproc testOnly*(name: cstring, fn: proc(done: bool)) {.importcpp: "only".}
20:33:22shashlickmy primary driver is windows but i cannot dev on it
20:33:31disruptekwhy not?
20:33:38*cron quit (Quit: Leaving.)
20:33:39shashlickIT
20:33:50FromGitter<kristianmandrup> but in JS it should call `test.only`
20:33:54disruptekyou can't run the code you write?
20:34:19FromGitter<kristianmandrup> `proc testOnly*(name: cstring, fn: proc(done: bool)) {.importcpp: "test.only".}` ??
20:34:23shashlickno cause it can get quarantined as a threat sometimes
20:34:32Araqok, so importc: "test.only"
20:34:48FromGitter<kristianmandrup> @Araq cool :)
20:35:18FromGitter<kristianmandrup> And `void` return type is implicit?
20:35:36Araqyeah. and bad style
20:35:59disruptekand might even break you in later nim.
20:36:04Araqdisruptek, 'nigel' is nice. how can it possibly work?
20:36:10disruptekhow can it not?
20:36:55disruptekwell, i will tell you how it can not work: builds that are not reproducible.
20:37:11Araqwhich cloud provider does it run on?
20:37:14disruptekaws
20:37:20Araqaww
20:37:30Araqcouldn't resist.
20:37:50Araqok, I'm out of questions.
20:37:59disruptekworst-case scenario, it can still run your tests fast. but, i don't want to run tests at all if i don't have to.
20:39:07shashlickwho is going to pay
20:39:25disruptekit costs almost nothing.
20:39:43disruptekfor most usage, it will literally cost nothing. the free tier is quite broad.
20:44:06shashlickfree tier is only a year, anyway, cannot argue $ beyond a point
20:44:27*xet7 quit (Remote host closed the connection)
20:45:09disruptekokay, sure. i'll pay for it. i have a good idea of what it's going to cost (again, almost nothing).
20:45:29disruptekbut, the idea is that it's decentralized by design.
20:45:31*xet7 joined #nim
20:47:19FromGitter<kristianmandrup> I'd love to use Nim with Micro Frontends as well - using single-spa.js.org
20:47:25disruptekyou can put up to 6mb in each adhoc test -- eg. a playground submission -- or you can combine multiple tests together into a layer, eg. the compiler test suite, and run them all at once.
20:47:51FromGitter<kristianmandrup> Any good Nim tool for generating project/file skeletons, similar to Angular schematics or other "generators"?
20:49:23*filcuc joined #nim
20:52:29disruptektype !help
20:52:40disruptekget to know your buddy, disbot
20:53:27disruptekoh i guess that doesn't work for gitter people.
20:53:55*xet7 quit (Remote host closed the connection)
20:55:00*xet7 joined #nim
20:58:12Araqkristianmandrup: I think nimble can do it
20:58:26Araq'nimble init' maybe.
21:07:03*krux02 joined #nim
21:16:51*filcuc quit (Ping timeout: 272 seconds)
21:25:51*oculuxe joined #nim
21:26:18Zevv~https://www.reddit.com/r/programming/comments/eunjuv/a_regex_engine_faster_than_pcre_written_in_nim/
21:26:20disbotno footnotes for `https://www.reddit.com/r/programming/comments/eunjuv/a_regex_engine_faster_than_pcre_written_in_nim/`. 🙁
21:26:49*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:27:27FromGitter<kayabaNerve> Interesting bug. My async function has its last line a print statement, and it does print. As soon as it returns, an Exception is raised of `over- or underflow`.
21:27:37*oculux quit (Ping timeout: 272 seconds)
21:36:38*tane quit (Quit: Leaving)
21:39:06*Trustable quit (Remote host closed the connection)
21:41:46*cgfuh quit (Quit: WeeChat 2.6)
21:42:06disruptekblame shashlick
21:42:38disruptekkayabaNerve: if true: invoke_your_last_print_statement
21:45:40*zama quit (Read error: No route to host)
21:45:42*zama_ joined #nim
21:45:56*zama_ is now known as zama
21:46:54FromGitter<kayabaNerve> disruptek: What's that supposed to do? I only added the print statement to verify the function finished :P
21:47:03shashlickey
21:47:13FromGitter<kayabaNerve> Or are you saying just if true: the last line?
21:48:01disruptekyeah, just curious if the behavior changes.
21:48:13FromGitter<kayabaNerve> Nope
21:48:35disruptekhow are you calling the async proc?
21:49:01FromGitter<kayabaNerve> It only errors on its 6th occurrency
21:49:09FromGitter<kayabaNerve> No idea why 6
21:49:15FromGitter<kayabaNerve> I do also have manual Futures floating around
21:49:30FromGitter<kayabaNerve> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e2f5ae901914e3e045c5f26]
21:49:35FromGitter<kayabaNerve> Relevant calling code though.
21:49:50FromGitter<kayabaNerve> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e2f5afe9ad22d5bd5ef16c2]
21:49:53FromGitter<kayabaNerve> There's the def
21:52:02FromGitter<kayabaNerve> I'm working on a lot of code in this section right now. This one function didn't change though.
21:52:18FromGitter<kayabaNerve> I'm trying to think if my manual Futures could be related in any way.
21:52:30disruptekthere's nothing special about "manual" futures.
21:52:41FromGitter<kayabaNerve> Only thing I can think of :P
21:52:48disrupteki mean, that's not really a thing. 😉
21:53:16FromGitter<kayabaNerve> Futures not created via the async macro but manually initiated and completed via callbacks
21:53:33disrupteki do it all the time and it's fine.
21:53:40FromGitter<kayabaNerve> Good to know.
21:53:55FromGitter<kayabaNerve> Then I have no idea why this is. I'll try devel.
21:54:03disruptekno special-sauce in .async. but you know as well as i that the exceptions are thorny.
21:55:34FromGitter<kayabaNerve> I think it's the async generated code which has a under/overflow though
21:55:50FromGitter<kayabaNerve> I mean, my code finishes yet doesn't continue after await.
21:56:02FromGitter<kayabaNerve> Question is what I did to trigger it
21:59:52FromDiscord_<Recruit_main_70007> how do i send a click mouse input with winim?
22:00:13*filcuc joined #nim
22:09:56*Pqzcih5 quit (Remote host closed the connection)
22:10:10*Pqzcih5 joined #nim
22:28:52FromDiscord_<treeform> @Recruit_main_70007 mouse_event https://github.com/khchen/winim/blob/ebc70132af9c6f00efca9abd317461369dfd486b/winim/inc/winuser.nim#L4425
22:29:09FromDiscord_<treeform> https://stackoverflow.com/a/7967772
22:29:39FromDiscord_<Recruit_main_70007> thanks!
22:30:10FromDiscord_<treeform> maybe try SendInput if that does not work... looks like its an old function
22:30:18FromDiscord_<treeform> but SendInput requires building your own data structures which is harder
22:30:56FromDiscord_<Recruit_main_70007> it worked
22:31:11FromDiscord_<treeform> cool
22:32:31*solitudesf quit (Ping timeout: 265 seconds)
22:35:44FromGitter<NimStart> @treeform does fidget work?
22:36:02FromGitter<NimStart> I can compile it, but nothing shows up when I run it
22:37:25FromGitter<NimStart> with code from figma plugin or minimal example
22:53:00*ltriant joined #nim
22:53:48FromDiscord_<Recruit_main_70007> which ones were the other kernel examples made in nim appart of nimkernel?
22:56:02FromGitter<NimStart> (https://files.gitter.im/nim-lang/Nim/CBc6/fidget-error.png)
22:56:09FromGitter<NimStart> (https://files.gitter.im/nim-lang/Nim/I3U3/fidget-error.png)
22:56:46FromGitter<NimStart> Now I'm getting this on minimal example
22:58:43*pbb_ joined #nim
23:01:21*pbb quit (Ping timeout: 272 seconds)
23:04:40*pbb_ quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
23:08:09*pbb joined #nim
23:08:24shashlickVscode remote ssh is amazing, guess I'm burning ram again
23:08:43disruptekwhat is that?
23:11:41shashlickhttps://code.visualstudio.com/docs/remote/remote-overview
23:12:03shashlickEverything works as if locally
23:12:59disruptekif you can ssh, why can't you just setup a server somewhere?
23:13:16shashlickThat's just Linux
23:13:29shashlickWhich is working fine within docker
23:13:42disruptekso vscode doesn't really help.
23:16:10disruptekpro tip: don't try to build llvm on a machine with only 512mb of memory.
23:16:19disruptekthis will not end well, if it ends at all.
23:16:33*Ven`` joined #nim
23:17:20FromGitter<zetashift> What does `gensym` means in the context of templates/macros?
23:17:32FromGitter<zetashift> generated symbol?
23:17:35disruptekyep.
23:19:00FromDiscord_<inv> Hello, probably nim-bug, can I post it here first?
23:19:04disrupteksure.
23:19:30leorizealso don't try to build rust with less than 4g of ram
23:19:50disruptekand 2hrs to kill.
23:20:11leorizethis is why I use `earlyoom`
23:20:26leorizebecause linux oom killer is horrible
23:21:33FromDiscord_<inv> ```nim
23:21:33FromDiscord_<inv> --- file #1 ---
23:21:33FromDiscord_<inv> proc pemDecoderLoop(pem: string, prc: proc(ctx: pointer, pbytes: pointer, nbytes: int) {.cdecl, noSideEffect, gcsafe.}, ctx: pointer) =
23:21:33FromDiscord_<inv> ...
23:21:33FromDiscord_<inv> pemDecoderSetdest(addr pemCtx, prc, ctx)
23:21:34FromDiscord_<inv>
23:21:35FromDiscord_<inv> --- file #2 ---
23:21:37FromDiscord_<inv> {.pragma: bearSslFunc, cdecl, gcsafe, noSideEffect.}
23:21:39FromDiscord_<inv> proc pemDecoderSetdest*(ctx: ptr PemDecoderContext; dest: proc (destCtx: pointer;
23:21:41FromDiscord_<inv> src: pointer; len: int) {.bearSslFunc.}; destCtx: pointer) {.inline.} =
23:21:41FromDiscord_<inv> ```
23:21:52disruptekinv you know the rules regarding pastes.
23:21:55leorize~paste
23:21:55disbotpaste: 11a frowned-upon behavior in chat; please use a service such as https://play.nim-lang.org/ or http://ix.io/ or https://gist.github.com/ and supply us a URL instead.
23:22:05FromDiscord_<inv> oh, sorry, I know, but forgot again 😦
23:22:42leorizeYardanico is writing an another discord bot that might save us all from this :P
23:23:17FromDiscord_<inv> telegram-irc crossjoin would help better, does not like discord 🙂
23:23:21disrupteklet me guess, your bearSslFunc doesn't work?
23:23:55leorize@inv it's proposed, but people on telegram didn't like it
23:24:21FromDiscord_<inv> @disruptek, compilation error: Expected cdecl, gcsafe, noSideEffect, but passed is cdecl only. 1 sec
23:24:48FromDiscord_<inv> leorize, from telegram-people I heard that irc-people didn't like it 🙂
23:25:36leorize*shrug* I heard the story from narimiran :P
23:25:43leorizewell maybe you can propose it on the forums :P
23:27:13FromDiscord_<inv> I did it: https://play.nim-lang.org/#ix=28x8
23:27:47FromDiscord_<inv> fix is {.pragma: bearSslFunc, cdecl, gcsafe, noSideEffect.} => {.pragma: bearSslFunc, cdecl.}
23:27:56shashlick@disruptek it is great to have a full vscode experience on a remote server
23:27:58FromDiscord_<inv> But I suppose it is not correct
23:28:18leorizeyou should only enforce cdecl tbh
23:28:20disruptekbut shashlick, what about feud?
23:28:22leorizemuch more flexible
23:28:28leorizebut that seems to be a walkaround
23:28:42shashlickSome day, when I have infinite time and zero bugs
23:28:49FromDiscord_<inv> leorize? It is not my lib, but why you expect cdecl only?
23:28:58FromDiscord_<inv> leorize? It is not my lib, but why do you expect cdecl only?
23:29:05FromDiscord_<inv> leorize. It is not my lib, but why do you expect cdecl only?
23:29:18shashlickBasically I need to put mind share where others aren't already
23:29:20disruptekWHY WHY WHY
23:29:36shashlickBut feud was a success, we get a plugin system out of it
23:29:41shashlickI just need to extract it out
23:29:43leorize@inv: because it doesn't really matter if my callback prints something to stdout, and since it uses raw pointers gcsafe doesn't apply
23:29:46FromDiscord_<inv> ok, I am pretty sure, that without fix it is correct.
23:29:52disruptekshashlick: i wonder how arc changes all that.
23:30:10leorizealso please avoid editing discord messages :P
23:30:22leorizeit spams the irc with duplicates of your message
23:30:37disruptekwe do love hearing from you, though.
23:30:52shashlickArc should work the same as boehm eventually for feud
23:31:16FromDiscord_<inv> leorize, I am not about function itself, more about that it was waiting for gcsafe, and from initial function it was declared, but nim said that no gcsafe was provided
23:31:32disruptekyeah, but with the shared heap you can simplify/omit the shared lib you wrote.
23:32:06shashlickYa I removed it anyway, it wasn't needed with boehm but was a good experience
23:32:26leorize@inv: yea, should be filed as a bug :p
23:32:34leorizebonus points if you can make a small reproduction sample
23:32:39leorizewhich I imagine would be easy :P
23:32:43FromDiscord_<inv> leorize, shame on you 🙂
23:33:05leorizeI was just voicing about how cdecl only would be more flexible :P
23:33:38FromDiscord_<inv> I do not care about cdecl or cdecl,gcsafe , because it is my first week with nim 🙂
23:35:23FromDiscord_<inv> Probably where is another package to work with google-docs ?
23:38:05leorize[m]wdym?
23:39:21leorize[m]disruptek: iirc you notified me sometime ago for an unsolved bug in nim.nvim. Can I have the details again?
23:39:58leorize[m]about*
23:40:00disruptekjust that ##[ set highlight but ]## wasn't seeming to terminate it.
23:48:31FromDiscord_<inv> will go back in telegram
23:55:41*disrupteq joined #nim