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:52 | FromDiscord_ | <Rika> Kinda wish nim had something like go report |
01:22:39 | * | Hideki_ quit (Ping timeout: 268 seconds) |
01:26:39 | disruptec | whatsit do? |
01:33:49 | FromDiscord_ | <Rika> Uh, code quality analysis |
01:38:54 | * | krux02 quit (Remote host closed the connection) |
01:40:55 | disruptec | i can do that for ya. |
01:46:48 | leorize | Araq: I don't change much other than adding close-on-exec flags for ioselectors |
01:47:23 | leorize | they aren't supposed to be inherited anyway (you can't access them from outer modules), so no escape hatch for them |
01:48:30 | FromDiscord_ | <Rika> Wait a minute, you aren't disruptek! |
01:48:43 | leorize | so I don't know why it'd be harmful to them? |
01:48:49 | leorize | I don't even change the API |
01:50:39 | * | lritter quit (Quit: Leaving) |
01:55:01 | * | Hideki_ joined #nim |
01:58:20 | disruptec | i'm the kinder, gentler, disruptek. |
02:01:16 | FromDiscord_ | <exelotl> where's disrupteque? The meeting can't start without him |
02:05:54 | * | lritter joined #nim |
02:08:35 | disruptec | it's a myth. |
02:08:47 | disruptec | none of us are unique. |
02:15:30 | * | lritter quit (Quit: Leaving) |
02:19:47 | FromDiscord_ | <DeltaPHC> Gotta reduce this repetition. `type Disrupt[T] = object` |
02:20:47 | disruptek | hmm, yeah. |
02:21:03 | * | disbot is now known as disrupteq |
02:21:08 | disruptek | there we go. |
02:21:13 | disruptec | wee |
02:21:29 | * | Hideki_ quit (Ping timeout: 265 seconds) |
02:21:44 | FromDiscord_ | <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:03 | FromDiscord_ | <Skaruts> proc `readBuffer` is complaining it requires `len: Natural` instead `int literal` |
03:38:07 | FromDiscord_ | <Skaruts> what do? |
03:38:54 | FromGitter | <Varriount> Skaruts: Can you post your code? |
03:39:18 | * | lbart joined #nim |
03:39:27 | FromDiscord_ | <Skaruts> `s = stdin.readBuffer(1)` |
03:40:17 | FromDiscord_ | <Skaruts> `Error: type mismatch: got <File, int literal(1)>` |
03:40:50 | FromDiscord_ | <Skaruts> `but expected one of: proc readBuffer(f: File; buffer: pointer; len: Natural): int` |
03:40:59 | FromDiscord_ | <Skaruts> `but expression '1' is of type: int literal(1)` |
03:41:44 | FromDiscord_ | <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:40 | FromDiscord_ | <Skaruts> actually I'm also missing the buffer parameter there |
03:52:48 | FromDiscord_ | <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:55 | FromDiscord_ | <Skaruts> is there any way to do that? |
04:03:15 | * | endragor joined #nim |
04:18:59 | * | Hideki_ joined #nim |
04:22:36 | disruptek | terminal.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:57 | FromDiscord_ | <Skaruts> ah nice, thanks |
05:04:00 | FromGitter | <hlaaftana> does anyone know any possible reason asyncftpclient would upload corrupted images |
05:05:00 | FromGitter | <hlaaftana> pngs specifically get corrupted no matter what image it is |
05:05:12 | FromDiscord_ | <Rika> what proc |
05:05:25 | FromGitter | <hlaaftana> store() |
05:06:52 | FromDiscord_ | <Rika> the code looks ok |
05:06:57 | FromDiscord_ | <Rika> odd |
05:07:15 | nisstyre | 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:26 | nisstyre | I'm guessing the code is deprecated? |
05:07:59 | FromGitter | <hlaaftana> the up to date docs are at https://nim-lang.org/docs/channels.html and you need --threads:on |
05:08:08 | nisstyre | oh, great thanks |
05:08:18 | nisstyre | google fails me yet again |
05:29:05 | FromGitter | <hlaaftana> figured it out, for images FTP needs to use binary mode, asyncftpclient has no way of setting binary mode/text mode |
05:40:49 | FromGitter | <hlaaftana> yep got it working now, have to send "TYPE I". maybe add a procedure to change modes to asyncftpclient |
05:43:19 | disruptek | ftp is dead. |
05:45:14 | FromDiscord_ | <Skaruts> is there a non-blocking alternative to `terminal.getch`? |
05:45:55 | shashlick | https://github.com/genotrance/snip/blob/master/src/snip/key.nim |
05:50:58 | FromDiscord_ | <Skaruts> thanks |
06:30:01 | * | narimiran joined #nim |
06:43:05 | Yardanico | @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:17 | leorize | Skaruts: 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:07 | FromGitter | <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:18 | FromGitter | <mratsim> @zacharycarter, gcc is installed when you installed mingw32 (which confusingly can be 64-bit) |
08:34:07 | Araq | Yardanico, stalker! :P |
08:34:33 | Yardanico | What happened? :D |
08:34:46 | Araq | somebody starred my repo already |
08:34:56 | Araq | https://github.com/Araq/fosdem2020/tree/master |
08:35:18 | Araq | and my suspicion is that it's you |
08:35:23 | Araq | am I right? |
08:36:40 | Yardanico | Not this time xd |
08:36:50 | Yardanico | But I starred it now anyway |
08:37:00 | FromGitter | <alehander92> i saw it as well |
08:37:00 | narimiran | Araq: you can check it easily: https://github.com/Araq/fosdem2020/stargazers |
08:37:25 | FromGitter | <alehander92> it was on the top of the feed |
08:37:30 | FromGitter | <alehander92> my feed* |
08:39:43 | Araq | well now there is no need for me to give the talk anymore, isn't that nice |
08:40:12 | Araq | maybe somebody can replace my ASCII art diagrams for me |
08:40:13 | Zevv | so, let's find someone to fill your slot then! |
08:40:37 | Araq | or maybe they are really good, it's FOSDEM after all |
08:41:07 | * | ritchie_ quit (Quit: Leaving) |
08:41:29 | Yardanico | does fosdem record all talks? I'd like to watch all Nim talks :P |
08:42:10 | Zevv | they do |
08:42:13 | Zevv | this is 2020 |
08:42:18 | Yardanico | right |
08:43:18 | Zevv | https://video.fosdem.org/ coming to you since 2003 :) |
08:44:09 | FromGitter | <zacharycarter> @mratsim - thanks - yeah I think something just got borked when i was unarchiving the mingw64 download |
08:44:22 | FromGitter | <zacharycarter> but I got things compiling and running - then realized weave isn't going to help with my issue |
08:44:50 | Araq | no, but ARC is going to help you. |
08:45:04 | Araq | because it helps everybody for everything. |
08:45:08 | FromGitter | <zacharycarter> well, not just weave, parallelizing my approach in general |
08:45:10 | FromGitter | <zacharycarter> :D |
08:45:33 | Yardanico | arc is gonna save the humanity |
08:45:36 | FromGitter | <zacharycarter> I think i just need to optimize my pathfinding algo |
08:45:36 | Yardanico | and reduce the entropy |
08:46:18 | Araq | yeah arc makes tea for ya. why not coffee? because it knows better what you really need. |
08:50:01 | FromGitter | <alehander92> Araq becoming a teacher is cool |
08:50:07 | FromGitter | <alehander92> glad for the guy |
08:50:07 | lqdev[m] | then arc is my new fav piece of software. |
08:52:03 | PMunch | Yardanico, they are also uploaded to YouTube |
08:52:12 | Yardanico | very nice |
08:52:25 | Yardanico | although 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:47 | PMunch | That would be nice :) |
09:12:54 | PMunch | The more the merrier |
09:13:10 | FromDiscord_ | <mratsim> When I saw your pathfinding algo, i do think weave is perfect match for parallelizing it |
09:13:40 | PMunch | How many are we who's going to FOSDEM this year by the way? Is anyone keeping count? |
09:13:52 | FromDiscord_ | <mratsim> I made with with tree search algorithms that may or may not spawn more node with unknown balancing in mind |
09:13:55 | FromDiscord_ | <mratsim> Weave* |
09:15:14 | FromDiscord_ | <kodkuce> isent FFOSDEM 1-2 feb? |
09:15:26 | Yardanico | it is |
09:20:55 | * | PMunch quit (Quit: Leaving) |
09:21:43 | * | PMunch joined #nim |
09:24:38 | FromDiscord_ | <kodkuce> "uploaded " got me i thinked its allready online so after ddging was wtf |
09:25:16 | Yardanico | yeah, some nimmers can time travel, but keep it a secret pls :P |
09:26:55 | FromDiscord_ | <Rika> yardanico have you time traveled far enough to find out the discordnim issue? 😛 |
09:28:01 | Yardanico | not yet, im fighting with CERN rn |
09:29:33 | FromDiscord_ | <moigagoo> Hi! I noticed that the official docs support OS dark mode. Looks great! |
09:29:33 | FromDiscord_ | <moigagoo> |
09:29:34 | FromDiscord_ | <moigagoo> Why not include that in the built in doc builder? |
09:41:57 | FromDiscord_ | <Rika> it's on devel only rn afaik |
09:42:08 | FromDiscord_ | <Rika> also arent you the loco guy |
09:42:35 | PMunch | Araq, by the way, any reason why you are using the old logo on your slides? |
09:46:25 | PMunch | Rika, the loco guy? |
09:49:18 | * | floppydh joined #nim |
10:03:10 | Araq | PMunch, I wasn't aware |
10:03:15 | Araq | will see if I can change it |
10:03:32 | Araq | I use 'nim rst2html' to build my slides :P |
10:05:11 | * | ng0 joined #nim |
10:19:53 | PMunch | Yeah I saw, interesting approach but the result looks good |
10:20:01 | PMunch | What do you use to make actual slides out of it? |
10:20:49 | Araq | slidy2 |
10:21:06 | Araq | and a custom nimdoc.cfg |
10:21:54 | PMunch | Hmm, interesting |
10:22:41 | narimiran | PMunch: where can we see the final result? |
10:23:11 | PMunch | narimiran, final result? |
10:23:16 | Yardanico | narimiran: you mean https://github.com/Araq/fosdem2020 ? |
10:23:21 | narimiran | yes |
10:23:37 | narimiran | PMunch: you said "the result looks good", and i've only seen the raw .rst |
10:23:39 | Yardanico | the final result is there :P |
10:23:56 | Yardanico | "chromium move_semantics.html" |
10:24:26 | PMunch | Yeah, `nim c -r build.nim` then open the `move_semantics.html` file |
10:24:31 | narimiran | ah, i see |
10:25:23 | narimiran | Yardanico: i thought it was somehow possible to see it directly from github |
10:28:53 | Yardanico | well yeah you kind can |
10:29:24 | Yardanico | https://htmlpreview.github.io/?https://github.com/Araq/fosdem2020/blob/master/move_semantics.html |
10:29:31 | Yardanico | it's not fully rendered correctly here though |
10:32:58 | Araq | yeah it's not |
10:33:23 | PMunch | Hmm, so Slidy needs internet to work, as it loads the script and stylesheet from links? |
10:33:51 | Araq | for me it also works offline |
10:34:07 | PMunch | Probably because your browser has the files cached |
10:34:20 | PMunch | Try to turn off network and hit Shift+F5 |
10:35:04 | Araq | can't be bothered right now, sorry |
10:36:14 | Araq | https://www.w3.org/Talks/Tools/Slidy2/#(6) |
10:38:04 | PMunch | Of course, it's possible to make it run offline |
10:38:38 | PMunch | Just keep it in mind for the conference :) |
10:39:39 | Araq | why would my browser lose its cache though |
10:39:47 | Araq | or why would I lack wifi |
10:39:48 | FromGitter | <juancarlospaco> All Doc pages are Error 403!: ⏎ https://nim-lang.org/docs/theindex.html ⏎ https://nim-lang.org/docs/manual.html ⏎ https://nim-lang.org/docs/lib.html ⏎ https://nim-lang.org/docs/nep1.html ... [https://gitter.im/nim-lang/Nim?at=5e2ebdf4e177666195d88ee4] |
10:39:59 | Yardanico | rip |
10:40:10 | FromDiscord_ | <Auriel> it happened like a minute ago |
10:40:20 | Araq | sorry, my fault |
10:40:27 | Araq | we're doing a release :P |
10:40:36 | Yardanico | which one? :P |
10:40:42 | narimiran | 1.0.6 |
10:40:46 | Yardanico | oh okay good |
10:42:15 | Araq | lesson: follow the wiki instructions in the right order |
10:43:15 | PMunch | Araq, 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:48 | Araq | it's on github ;-) |
10:44:15 | narimiran | PMunch: please make a backup for Araq too :P :D |
10:44:49 | Yardanico | xd |
10:53:39 | * | abm joined #nim |
10:57:02 | * | chemist69 quit (Ping timeout: 260 seconds) |
10:57:58 | * | chemist69 joined #nim |
11:01:02 | PMunch | Damn it, I'm slipping down the hole of presentation tools again.. |
11:01:58 | Araq | PMunch, use my tool ;-) |
11:02:34 | PMunch | Yeah, I was reading the Slidy slideshow, and it mentioned a couple of others. And off I went :P |
11:02:35 | Araq | I've never looked back to latex/office/powerPoint |
11:02:50 | PMunch | It definitely looks promising |
11:11:20 | * | JustASlacker joined #nim |
11:13:09 | * | Jehan_ joined #nim |
11:22:32 | * | Jehan_ quit (Quit: Leaving) |
11:32:11 | narimiran | ANNOUNCEMENT: version 1.0.6 is available: https://nim-lang.org/blog/2020/01/24/version-106-released.html |
11:39:51 | FromDiscord_ | <Rika> 😮 |
11:40:25 | * | salewski joined #nim |
11:41:49 | salewski | Have just shipped gintro v0.7.0 with --gc:arc support, seems to work. |
11:42:07 | Yardanico | salewski: that's amazing news! |
11:43:12 | salewski | Yes, I am happy indeed. Had some fear that gintro would not work with new memory management |
11:43:24 | salewski | some weeks ago still. |
11:43:36 | Yardanico | does --gc:arc work with --threads:on yet? |
11:45:15 | Araq | yes, I ported channels and did some tests |
11:45:33 | Yardanico | and with --gc:arc there's shared heap as well? |
11:45:38 | Araq | yes |
11:46:40 | Araq | need 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:19 | Zevv | salewski: did you check for leaks? |
12:10:33 | Yardanico | Zevv: I think GTK checks for leaks itself? |
12:10:47 | Zevv | I 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:38 | PMunch | Nice 1.0.6 also have my AVR fixes, just in time for FOSDEM :) |
13:01:11 | Zevv | so, will you put arc in your talk as well? |
13:03:49 | PMunch | In mine? |
13:04:02 | PMunch | I'll have to read up on it in that case :P |
13:04:32 | FromGitter | <alehander92> do you have a talk |
13:04:37 | FromGitter | <alehander92> what is isolate |
13:05:42 | PMunch | alehander92, I have a talk yes |
13:05:57 | PMunch | Araq, mratsim, dom96, and I have talks (sorry guys for the ping) |
13:06:15 | FromDiscord_ | <yewpad> 1.0.6 and Darcula themed documentation wasn't released with it. Yaayyyyy |
13:06:29 | Yardanico | patch are for patches |
13:06:31 | Yardanico | not for features :P |
13:06:35 | Yardanico | welcome to post 1.0 world xdd |
13:06:45 | Yardanico | just /s |
13:07:12 | FromGitter | <alehander92> thats a language, not a document generator |
13:07:35 | FromGitter | <alehander92> why isnt the theme just a custom css file |
13:07:41 | FromGitter | <alehander92> that doesnt need any mainline releases |
13:10:10 | FromDiscord_ | <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:33 | narimiran | there was 1.0.6-beta released/announced 10 days ago |
13:10:36 | FromDiscord_ | <yewpad> so my eyes don't burn away* |
13:10:57 | narimiran | you could have easily go through the backported commits and notice that the theme was missing |
13:11:00 | FromGitter | <alehander92> but i just cant understand why is this hardwired to the compiler release |
13:11:26 | FromDiscord_ | <yewpad> Because the docgen is integrated in the compiler. It is not a separate tool. |
13:11:35 | narimiran | and you can use https://nim-lang.github.io/Nim/lib.html so your eyes don't need to "burn away" |
13:11:46 | Yardanico | although the docs in devel might differ |
13:12:15 | narimiran | Yardanico: but they'll have their precious darcula |
13:12:23 | Yardanico | well I use dark reader extension anyway |
13:12:30 | Yardanico | so I had dark mode in nim docs even before that theme |
13:13:12 | narimiran | but if "dark docs mode was not backported" is the most important issue of 1.0.6, then we did darn good job!! |
13:14:56 | FromDiscord_ | <Rika> i'm kinda annoyed that the doc features are coupled with the version, when it doesnt have to be |
13:15:25 | FromDiscord_ | <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:36 | narimiran | haha |
13:15:48 | * | kungtotte joined #nim |
13:22:10 | FromGitter | <alehander92> yewpad yea sorry i guess it would be there in 8 |
13:22:36 | FromGitter | <zetashift> Ooooh new release congratulations on 1.0.6 whoop |
13:27:13 | * | endragor quit (Remote host closed the connection) |
13:30:48 | FromGitter | <alehander92> 1) 0.8 sorry* |
13:37:50 | * | ptdel joined #nim |
13:40:03 | shashlick | Awesome job folks |
13:47:30 | livcd | oh 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:20 | FromDiscord_ | <mratsim> gone where? |
14:15:46 | * | marmotini_ quit (Ping timeout: 268 seconds) |
14:17:23 | Zevv | away! |
14:25:34 | FromDiscord_ | <moigagoo> @Rika |
14:25:35 | FromDiscord_ | <moigagoo> |
14:25:35 | FromDiscord_ | <moigagoo> > also arent you the loco guy |
14:25:35 | FromDiscord_ | <moigagoo> |
14:25:35 | FromDiscord_ | <moigagoo> Yep, I am 🙂 |
14:26:55 | FromDiscord_ | <moigagoo> @Rika |
14:26:55 | FromDiscord_ | <moigagoo> |
14:26:56 | FromDiscord_ | <moigagoo> > it's on devel only rn afaik |
14:26:56 | FromDiscord_ | <moigagoo> |
14:26:56 | FromDiscord_ | <moigagoo> Does that mean that it's now in Nim 1.0.6? |
14:27:11 | narimiran | devel != 1.0.6 |
14:27:14 | FromDiscord_ | <Rika> nope |
14:27:33 | FromDiscord_ | <Rika> not all things devel are moved into the latest release |
14:27:47 | narimiran | devel (1.1.1) is ahead of 1.0.6, and it is a basis for a future 1.2.0 release |
14:28:19 | FromDiscord_ | <Rika> ~~already at 1.2.0, eh?~~ |
14:28:41 | narimiran | huh? |
14:30:17 | FromDiscord_ | <Rika> nothin, dont mine that |
14:30:19 | FromDiscord_ | <Rika> mind* |
14:45:48 | dom96 | congrats on release bois |
14:46:01 | dom96 | PMunch you making a FOSDEM post on the forum? |
14:53:05 | Yardanico | Araq: 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:32 | Yardanico | well I mean, you won't notice it unles you'll actually need to calculate some string 500k times a second lol |
14:54:03 | Yardanico | https://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:28 | FromGitter | <kristianmandrup> Any good resources for creating binding libs to (client side) JavaScript? |
14:56:30 | * | marmotin_ quit (Remote host closed the connection) |
14:59:25 | PMunch | dom96, about what? |
15:00:33 | dom96 | PMunch reminding people that it's happening? |
15:05:20 | * | marmotini_ joined #nim |
15:05:31 | PMunch | Oh, I forget that others live close enough to not have to order plane tickets and such quite a while in advance :P |
15:06:06 | PMunch | Yeah, I can create a forum post, but possibly not until tomorrow.. |
15:06:15 | * | PMunch quit (Quit: Leaving) |
15:06:41 | Araq | Yardanico, never seen a factor of 4 before |
15:07:04 | Yardanico | well, maybe the design of this lib isn't that good :D |
15:07:06 | Araq | try 'nim cpp' |
15:07:09 | Yardanico | ah okay |
15:09:36 | Yardanico | with -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:42 | Yardanico | hmm, 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:03 | Yardanico | hmm, no real difference |
15:12:17 | * | lritter joined #nim |
15:12:22 | Yardanico | with m&s it's around the same as with default GC |
15:12:45 | Yardanico | with boehm GC it's around 1000ms |
15:19:23 | Araq | *shrug* profile it |
15:19:45 | Yardanico | will 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:47 | Araq | I noticed arc consumes much more memory as Nim's allocator is wasteful for 'alloc' |
15:21:18 | Araq | and memory is slow, I doubt it's the reason for your case though |
15:21:40 | Araq | I'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:41 | nc-x | Araq: what's arbitrary in https://github.com/nim-lang/Nim/pull/13261? |
15:28:42 | disbot | ➥ disallow typedesc in arrays |
15:28:42 | * | sagax joined #nim |
15:29:04 | nc-x | i haven't checked types.typeallowed yet |
15:29:06 | nc-x | but |
15:29:40 | nc-x | https://github.com/nim-lang/Nim/blob/32f0910f11acd88b10422d6dc20477747cda687d/compiler/semstmts.nim#L457 |
15:30:18 | nc-x | code almost similar to my patch already exists |
15:30:30 | nc-x | and 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:34 | leorize | Yardanico: try -d:useMalloc too :P |
15:39:41 | Yardanico | leorize: I tried, it's the same :( |
15:47:52 | Yardanico | well, it seems that with c -d:danger --gc:arc most of the time is spend in a lot of "eqdestroy" calls |
15:48:20 | Yardanico | https://i.imgur.com/fwrbiP4.png |
15:50:28 | Yardanico | part of compiled C code: |
15:50:33 | Yardanico | blob:https://imgur.com/523ad044-563d-4105-b621-56937d885510 |
15:50:42 | Yardanico | sorry https://i.imgur.com/WDaBNHF.png |
15:51:05 | Yardanico | also https://i.imgur.com/OUwxrX4.png is kinda strange |
15:51:54 | Yardanico | full file - https://gist.github.com/Yardanico/19058c4c6c11f9eb810599f73fb45f49 |
15:53:18 | Araq | nc-x: well it was bad before and you made it worse |
15:53:31 | Yardanico | ahh maybe it's due to my code having "template" for a few procs I use |
15:53:34 | Araq | at one point I have to say "stop!" |
15:54:27 | leorize | I'd be worried if template causes your code to be slower :P |
15:56:47 | Yardanico | well I got around 2x faster speed (so still ~2x times slower than default GC) when making procs instead of templates |
15:57:13 | leorize | hmm, can `=destroy` be inlined? |
15:57:23 | Yardanico | the relevant code part is stuff here |
15:57:23 | Yardanico | https://github.com/Yardanico/nim-mathexpr/blob/master/src/mathexpr/expr_eval.nim#L91 |
15:57:38 | Yardanico | all getArg() and getArgs() calls are templates (to type less :D) |
15:57:52 | Yardanico | and then they call the actual proc (and they're dirty templates too) |
15:58:33 | Yardanico | I should probably rewrite that case branch to something else so that I can only call getArgs in one branch once I guess |
15:58:47 | Yardanico | right now it's called in all of these "of" branches |
15:59:10 | leorize | you can compile your code with --expandMacro:getArgs to get the resulting inlining I think |
15:59:58 | Yardanico | well it's a template not a macro ;) |
16:00:00 | * | Vladar joined #nim |
16:00:52 | leorize | iirc that switch work for both |
16:00:53 | Araq | template getArg(): untyped {.dirty.} = |
16:00:53 | Araq | expr.getArgs(1, funcName)[0] |
16:01:07 | Araq | leorize, no only for macros |
16:01:22 | leorize | ah, ok then |
16:01:25 | Yardanico | so 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:31 | Yardanico | Araq: yeah, I understood why it's slow :) |
16:01:37 | Yardanico | just was surprised that it's 4x slower with --gc:arc |
16:02:43 | Araq | well so I am |
16:03:11 | Araq | the C code is much bigger but your icache is likely large enough |
16:03:29 | Araq | and the many seq creations that you do have to be cleaned up either way |
16:03:40 | Araq | arc does it asap, the old GCs do it from time to time |
16:03:49 | Yardanico | ah, makes sense why it's faster the |
16:03:50 | Yardanico | n |
16:04:02 | Araq | no, it makes no sense to me |
16:05:48 | Araq | ah |
16:05:59 | Araq | hmm ok, I think I know |
16:07:26 | Araq | yeah ok, need to think about it |
16:07:35 | Araq | the way we introduce temporaries is stupid crap |
16:08:19 | Araq | you can split up 'parseFactor' further into more smaller procs |
16:08:27 | Araq | and see if makes a difference |
16:08:43 | Araq | but it's definitely something we need to change in the backend |
16:09:27 | leorize | anyone know how components in Karax is supposed to be used? |
16:09:44 | leorize | do I just make one, store them somewhere, then add them to my buildHtml? |
16:09:49 | leorize | basically a custom node? |
16:10:32 | Yardanico | Araq: split up the branches of the "case" to different procs I suppose? |
16:10:42 | leorize | with, uh, manual "dirty" marking so I can save some time to not have to diff them? |
16:10:43 | Araq | no, the case is fine |
16:10:54 | Araq | but in every 'of' branch only do call a helper proc |
16:11:03 | Yardanico | ah, okay |
16:12:04 | Araq | leorize, study experiments/nativenodes.nim |
16:13:17 | Araq | Yardanico, or turn 'getArg' into a proc |
16:13:28 | Araq | yeah start with that. |
16:13:40 | Araq | as a template it's a desaster for the codegen |
16:16:16 | leorize | Araq: 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:38 | leorize | I thought nativenodes are for interfacing with 3rd party code? |
16:16:42 | Araq | leorize, it's been a while but the virtual DOM is stateless |
16:16:58 | Araq | and my attempts to introduce state into it have been clusterfucks |
16:17:12 | Araq | IMO it's a fundamentally flawed idea |
16:17:19 | Yardanico | Araq: 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:20 | Araq | however the real DOM is stateful |
16:17:32 | Yardanico | around 1300ms instead of 2500ms mean time |
16:17:44 | Araq | Yardanico, factor of 2 is a start though |
16:18:23 | Araq | leorize, so for "components" build and use native DOM elements and use 'dthunk' |
16:26:21 | Araq | Yardanico, also move your 'raise ' statements into helper procs |
16:27:12 | Yardanico | Araq: okay, a bit later though. but i'll also move each branch's code into a helper proc like you said |
16:27:21 | Araq | but yeah we need to fix this lol |
16:27:36 | Araq | luckily it's not hard |
16:39:02 | disruptek | give the compiler some hope of optimizing your stuff. |
16:42:51 | Yardanico | Araq: with procs for all branches it's down to ~850ms |
16:42:59 | Yardanico | now I'll also move exceptions to helper procs |
16:44:45 | Yardanico | with two raise statements moved into helpers procs it's down to 750ms |
16:45:09 | Yardanico | https://gist.github.com/Yardanico/46d13ace385c3c0c4e46a84256776301 generated C |
16:45:15 | Yardanico | compiled* :P |
16:48:36 | * | Vladar quit (Quit: Leaving) |
16:51:54 | leorize | Araq: 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:53 | Yardanico | actually with -d:useMalloc it becomes 650ms |
16:59:15 | Yardanico | so 450ms default GC vs 650ms --gc:arc -d:useMalloc |
16:59:19 | Yardanico | much better than before :D |
16:59:47 | zedeus | now try mimalloc |
17:00:01 | Yardanico | how? :P |
17:00:07 | * | Trustable joined #nim |
17:00:18 | zedeus | LD_PRELOAD=/usr/bin/libmimalloc.so myprogram |
17:00:24 | Yardanico | woah |
17:00:33 | Yardanico | i'll try |
17:02:22 | Yardanico | with that it's still the same 650ms, I'm doing "LD_PRELOAD=/usr/lib/mimalloc-1.4/libmimalloc.so ./repl" |
17:03:23 | Yardanico | and it's indeed running, I checked with MIMALLOC_VERBOSE |
17:04:26 | zedeus | interesting |
17:04:47 | Yardanico | mimalloc stats - https://gist.github.com/Yardanico/6673c8683f10c41dbf14da1e9bd9de33 |
17:05:21 | Yardanico | ah let's try the unoptimized version, maybe it'll be better |
17:05:40 | Yardanico | I mean the one without splitting stuff into procs |
17:07:59 | Yardanico | hm, seems to be around the same as without mimalloc |
17:12:20 | leorize | try jemalloc? |
17:13:04 | Yardanico | i 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:39 | disruptek | turn off useMalloc. |
17:14:56 | * | marmotini_ joined #nim |
17:15:29 | Yardanico | disruptek: around 50-70ms more for 1 million iterations :) |
17:15:39 | Yardanico | I mean it's slower without -d:useMalloc :P |
17:15:44 | disruptek | right. |
17:19:31 | * | marmotini_ quit (Ping timeout: 265 seconds) |
17:26:42 | Zevv | ping @clyybber |
17:29:16 | Zevv | also @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:57 | disruptek | Zevv: use a nim.cfg. |
17:30:23 | Zevv | a right. I never do that, but that works of course. You are so smart dude |
17:30:52 | disruptek | no, i just rely upon nim.cfg heavily. |
17:30:59 | leorize | Zevv: there's a way, but I never added an interface for it :P |
17:31:19 | leorize | just edit autoload/nim/suggest.vim for now |
17:31:26 | leorize | there's the extraArgs there |
17:31:31 | Zevv | no way |
17:31:32 | leorize | pass them however you like :P |
17:31:37 | Zevv | that's *too* dirty |
17:32:10 | leorize | you want a better way? copy nimsuggest to the bin/ folder in Nim source |
17:32:26 | FromDiscord_ | <Clyybber> Zevv: Oy |
17:32:27 | Zevv | it already lives there |
17:32:48 | leorize | add that to your path :P it should pick up the stdlib in the compiler source |
17:32:53 | Zevv | clyybber: \o Do you have thoughts about https://github.com/nim-lang/Nim/issues/13240? |
17:32:56 | disbot | ➥ [ARC] segmentation fault ; snippet at 12https://play.nim-lang.org/#ix=28vy |
17:33:18 | Zevv | leorize: 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:49 | Zevv | clyybber: I'd like to give that a try, but I'm not sure if that is within my current powers yet tho |
17:34:00 | FromDiscord_ | <Clyybber> Its a codegen issue I think |
17:34:25 | Zevv | it is. I'm pretty sure my analasys is right, it's more the question on how to solve that. |
17:34:51 | leorize | Zevv: maybe you can patch nim.nvim to take a g:nimsuggest_extra_args array of arguments? |
17:34:56 | leorize | I would merge that :P |
17:34:58 | Zevv | Somehow 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:30 | FromDiscord_ | <Clyybber> Hmm |
17:35:47 | Zevv | leorize: Hm that's a bit too static. environment variable? Or magic vim-style mode line in the code? |
17:36:00 | Zevv | leorize: no, the latter makes no sense with multiple files |
17:36:31 | leorize | Zevv: you know exrc exists, right? :P |
17:36:32 | FromDiscord_ | <Clyybber> Zevv: Is the issue that Thing(...) is memset to zero after add? |
17:36:43 | Zevv | leorize: nope, let me check that |
17:36:59 | Zevv | Clyybber: right. It memzeros const data. |
17:37:08 | Zevv | which might or might not work depending on your system, but it's UB |
17:38:03 | Zevv | But I don't evne understand properly how this works yet, that's part of the problem. |
17:38:22 | Zevv | I see the generated C code, but I don't grok the semantics yet |
17:38:39 | FromDiscord_ | <Clyybber> Zevv: injectdescructors zeroes it out after a bugfix from Ar*q |
17:39:05 | FromDiscord_ | <Clyybber> But thats correct |
17:39:09 | FromDiscord_ | <Clyybber> So the issue is in codege |
17:39:13 | FromDiscord_ | <Clyybber> n |
17:39:34 | Zevv | ok, but then (/me pushing another sample) |
17:40:16 | Zevv | http://ix.io/28vB contradicts. |
17:40:32 | Zevv | Thing is a const. Ergo it should go in romem. but it needs te be zeroed out. Ergo it should be in rwmem |
17:40:58 | FromDiscord_ | <Clyybber> But consts are not zeroed out afaik |
17:41:03 | FromDiscord_ | <Clyybber> lemme try |
17:42:24 | leorize | Zevv: also, with g:nimsuggest_extra_args, you can populate it with getenv() in your config if you'd like |
17:42:39 | leorize | nim.cfg can act on environment variable also, if you're into that |
17:42:53 | disruptek | zevv is kinky like that. |
17:42:59 | FromDiscord_ | <Clyybber> Zevv: yep, not zeroed out or destroyed |
17:43:03 | FromDiscord_ | <Clyybber> which is expected |
17:43:05 | Zevv | leorize: that works, thanks |
17:43:13 | FromDiscord_ | <Clyybber> I think |
17:43:33 | Zevv | Clyybber: it stil boom's on me |
17:43:57 | FromDiscord_ | <Clyybber> Hmm |
17:44:09 | FromDiscord_ | <Clyybber> I think the issue may be that codegen is trying to const evaluate it |
17:44:30 | FromDiscord_ | <Clyybber> which is too late I think |
17:44:39 | FromDiscord_ | <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:52 | leorize | nope |
17:44:54 | Zevv | but 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:02 | FromDiscord_ | <Clyybber> It neednt |
17:45:11 | FromDiscord_ | <Clyybber> I think |
17:45:22 | Zevv | right |
17:45:33 | leorize | @Tak those has to be passed by function pointers anyway, so you can't inline them anyway |
17:45:50 | Zevv | I 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:51 | FromDiscord_ | <Tak> Ok gotcha thanks 🙂 |
17:46:20 | leorize | Zevv: ie you freed your pointer |
17:46:33 | leorize | it 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:37 | FromDiscord_ | <Clyybber> Zevv: I think the proper way to fix it is to try to evaluate `Thing(...)` at compile time |
17:48:16 | FromDiscord_ | <Clyybber> and earlier than in codegen |
17:48:28 | FromDiscord_ | <Clyybber> probably |
17:48:42 | FromDiscord_ | <Clyybber> Maybe I'm overthinking things but I think thats what zah had in mind too |
17:49:48 | Zevv | effectively it is a const in the #13240 version - the codegen handles it the as in the ixo snippet above it seems |
17:49:49 | disbot | https://github.com/nim-lang/Nim/issues/13240 -- 3[ARC] segmentation fault ; snippet at 12https://play.nim-lang.org/#ix=28vy |
17:50:23 | leorize | Zevv: as far as I can understand, the compiler just follow the rules of inserting `eqdestroy` at end of func |
17:50:26 | Zevv | mayb it should simply not get finalized if it is a const |
17:50:34 | leorize | wasMoved() is used to disable the destructor |
17:50:36 | leorize | see https://nim-lang.github.io/Nim/destructors#destructor-removal |
17:50:56 | Zevv | leorize: sure, but can you destruct a const? |
17:51:01 | FromDiscord_ | <Clyybber> Zevv: Another way to fix it is to replicate the logic of the codegen in injectdestructor |
17:51:09 | leorize | Zevv: of course you can't :P |
17:51:17 | Zevv | leorize: so there you have it |
17:51:17 | FromDiscord_ | <Clyybber> lets ask Araq |
17:52:16 | Zevv | so we should let the `const Thing()` live long and happy in const land |
17:52:37 | Zevv | That's what you get from all that casting to void* and ignoring the warnings of the C compiler |
17:52:37 | disruptek | i 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:18 | FromDiscord_ | <Clyybber> disruptek: Eh, that doesn't work |
17:53:25 | disruptek | why not? |
17:53:30 | FromDiscord_ | <Clyybber> How can we point to a destructor in a const? |
17:53:40 | FromDiscord_ | <Clyybber> and then change it? |
17:53:44 | FromDiscord_ | <Clyybber> same problem |
17:53:51 | disruptek | the const can point to a special "const destructor" that breaks. |
17:54:03 | disruptek | so we know why, etc. |
17:54:07 | FromDiscord_ | <Clyybber> seems like a workaround |
17:54:18 | disruptek | no, because it solves the problem elegantly for non-consts. |
17:54:26 | FromDiscord_ | <Clyybber> Which problem? |
17:54:34 | disruptek | the problem of eliding destroys. |
17:55:05 | * | floppydh quit (Quit: WeeChat 2.7) |
17:55:08 | disruptek | why aren't you going to fosdem? |
17:55:43 | Yardanico | what about you? |
17:56:24 | * | abm quit (Quit: Leaving) |
17:58:33 | disruptek | me? |
17:58:35 | Yardanico | you |
17:58:45 | disruptek | i'm going. |
17:58:54 | disruptek | if i can find my passport, i mean. |
18:02:01 | FromDiscord_ | <Clyybber> disruptek: no time : / |
18:02:20 | FromDiscord_ | <Clyybber> disruptek: we elide destroys via zeroing out |
18:02:31 | FromDiscord_ | <Clyybber> I think its faster that way |
18:02:40 | FromDiscord_ | <Clyybber> and makes our objects smaller : ) |
18:02:57 | disruptek | sure, they are smaller, but it's clearly not faster. |
18:03:21 | FromDiscord_ | <Clyybber> disruptek: I think it is |
18:03:38 | FromDiscord_ | <Clyybber> At least the C compiler is more free to optimize stuff |
18:03:38 | disruptek | well, i think it's not. |
18:04:10 | FromDiscord_ | <Clyybber> And then destructors can be inlined |
18:05:00 | FromDiscord_ | <Clyybber> And I think its best to elide as much as possible at compile time |
18:05:02 | disruptek | destructors are O(n) while swapping a ptr is O(1). |
18:05:46 | * | marmotini_ joined #nim |
18:06:07 | leorize | note that nim objects are used for C FFI also |
18:07:27 | FromDiscord_ | <Clyybber> disruptek: But the stuff destrucros zero out are pointers most of the time |
18:08:04 | disruptek | i'm not saying they won't run, i'm saying they will run only once. |
18:11:38 | FromDiscord_ | <Clyybber> Yes, but that is possible with the zero-out approach too |
18:17:42 | disruptek | the 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:39 | FromDiscord_ | <Clyybber> nah we can |
18:19:04 | FromDiscord_ | <Clyybber> sometimes we can't |
18:19:31 | disruptek | let me know what you decide. |
18:19:38 | FromDiscord_ | <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:20 | disruptek | on the contrary, it's not worth performing operations at runtime that are unnecessary. |
18:20:27 | FromDiscord_ | <Clyybber> yes |
18:20:30 | FromDiscord_ | <Clyybber> ideally |
18:20:58 | FromDiscord_ | <Clyybber> you would be able to use everything as an indicator for something being zeroed out |
18:21:16 | FromDiscord_ | <Clyybber> so you could I dunno use the first bit of a pointer or something |
18:21:23 | FromDiscord_ | <Clyybber> but rn that doesn't work |
18:21:39 | FromDiscord_ | <Clyybber> because we assume zeroing out rn |
18:22:50 | FromDiscord_ | <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:37 | Araq | Clyybber: there codegen tries to optimize 'let' to 'const |
18:46:53 | Araq | and this is safe since you cannot mutate a 'let' either |
18:47:06 | Araq | infortunately destructors and wasMoved do mutate |
18:47:28 | Araq | so for the codegen the 'let' is a lie and it should do a deeper analysis. but it doesn't |
18:47:49 | Araq | we can move the logic into injectdestructors |
18:48:11 | Araq | which does know about wasMoved |
18:49:25 | Zevv | so 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:21 | Araq | Clyybber: Yardanico found out my way of using top level temps is terrible for performance |
18:52:37 | Araq | we need to inject destructors based on scoping |
18:53:22 | Zevv | \o/ |
18:53:52 | Araq | GCC is bad at optimizing my way |
18:54:00 | Araq | and probably most other compilers are too |
18:54:28 | * | rockcavera joined #nim |
18:58:05 | FromGitter | <bpr> For FOSDEM slides, I suggest changing "inofficial" to "unofficial". At least to this American reader, inofficial sounds wrong. |
18:58:22 | Araq | thanks |
18:59:18 | FromGitter | <bpr> You're welcome, and thanks for making those slides available. |
18:59:19 | Araq | "inofficial" seems to exist but my dict says it's "rare" |
19:00:08 | FromGitter | <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:58 | FromGitter | <bpr> I wonder if it sounds that way to other denizens of the Anglosphere... |
19:02:52 | disruptek | yep. |
19:07:00 | Araq | bpr: how much do you understand without my speech? |
19:07:27 | Araq | I 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:44 | FromDiscord_ | <Clyybber> Araq: Nice! |
19:17:53 | FromDiscord_ | <Clyybber> Scope based approach is the way to go |
19:17:55 | FromGitter | <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:22 | Araq | ok, good |
19:18:23 | FromDiscord_ | <Clyybber> Will allow us to elide many more wasMoved + destroy pairs |
19:19:33 | FromGitter | <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:29 | disruptek | these slides look great to me. |
19:20:57 | leorize | Araq: re: using dthunk() to do components: how am I supposed to update them? |
19:21:19 | disruptek | they are maybe a little wide. hard for me to tell. |
19:21:42 | Araq | you update the "captured" DOM elements in an event handler |
19:22:13 | Araq | the 'dthunk' wrapper means "use this DOM directly" |
19:22:17 | leorize | you mean using the dom apis directly? |
19:22:43 | Araq | depends but yes |
19:22:46 | leorize | I hoped that I could just have karax help me with the diffing so I can just apply it to Node :P |
19:23:12 | Araq | then why do you have stateful stuff inside |
19:23:23 | Araq | DOM diffing hates hidden state |
19:23:51 | leorize | I have a clock, it ticks |
19:24:30 | Araq | ultimately all this stuff doesn't work well and DOM diffing is the most terrible abstraction inversion that I've ever seen |
19:26:52 | disruptek | Araq: you need to show, somewhere, that you're running these benchmarks with, eg. "21" as an argument. |
19:27:30 | Araq | disruptek, 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:17 | leorize | Araq: I guess something like this: http://ix.io/28w7 is my best bet at making a clock "component"? |
19:42:50 | Araq | doesn't look right |
19:47:45 | leorize | how do you think this should be done? |
19:50:04 | Araq | not at all. |
19:51:14 | Araq | but if you really want to, a component is a Node |
19:51:33 | Araq | and dthunk() does the bridge into VNode land |
19:52:05 | Araq | you can construct the Node via Karax's vnodeToDom() API |
19:52:22 | Araq | as I said, study nativenodes.nim |
19:52:40 | Araq | yes it's only 18 lines. but you need to study them. |
19:53:50 | Araq | and if you're successful, document it well and contribute to Karax |
19:54:15 | leorize | I've given it a good read and my conclusion is that I've to manually modify it :/ |
19:54:37 | leorize | easy for a clock, much more complex for a carousel for example :/ |
19:55:21 | * | tane joined #nim |
19:57:16 | leorize | actually, is there any js stuff that let me replace a node with another without changing the reference? |
19:57:33 | leorize | that'd make things easier since I can render a node from vdom and swap it over when needed |
19:57:37 | leorize | gonna look around a bit |
20:01:19 | Araq | also look into knete.nim which is Karax's API for the DOM, no VDOM involved |
20:02:50 | Araq | it's a bit out of date though |
20:04:50 | Araq | I'm still torn, nothing works really well. |
20:07:00 | Araq | for now pass the state around and don't have it in "components", it works best. |
20:07:58 | FromGitter | <kristianmandrup> I'm looking into how to write JS bindings |
20:08:13 | FromGitter | <kristianmandrup> in Html5Canvas bindings repo |
20:08:16 | FromGitter | <kristianmandrup> ```import dom ⏎ include html5_canvas/rgb``` [https://gitter.im/nim-lang/Nim?at=5e2f4330dc0766704202ed90] |
20:08:34 | FromGitter | <kristianmandrup> I've never seen the `include` before. I thought it was always `import`? |
20:09:26 | FromGitter | <kristianmandrup> Oh :O https://nim-lang.org/docs/manual.html#modules-include-statement |
20:10:02 | FromGitter | <kristianmandrup> So the key is to use the `{.emit}` pragma? |
20:10:09 | FromGitter | <kristianmandrup> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e2f43a01a1c2739e30e2b87] |
20:14:55 | * | NimBot joined #nim |
20:21:17 | leorize | Araq: I figured so |
20:21:30 | leorize | anyway, here's my terrible terrible way to do "components": http://ix.io/28wm |
20:25:39 | FromGitter | <kristianmandrup> @disruptek - your github account is a Nim treasure trove :) |
20:25:47 | disruptek | wut |
20:26:26 | * | narimiran quit (Ping timeout: 240 seconds) |
20:26:36 | FromGitter | <kristianmandrup> Lots of good libraries and utils for the Nim eco-system |
20:26:56 | disruptek | oh, thanks. just things i wanted. |
20:27:19 | disruptek | thoughts on nigel? |
20:28:33 | shashlick | looks fun |
20:28:54 | disruptek | shashlick: i will be depending upon you to shoehorn windows into this somehow. |
20:29:16 | disruptek | even if it's via some shim in the backend layer that builds/runs stuff remotely, etc. |
20:29:48 | shashlick | well, i have had no luck getting a windows env up |
20:29:57 | shashlick | will have to resort to manually setting up a vm now |
20:29:59 | disruptek | don't say that; you're the expert. |
20:31:36 | shashlick | i now have zero windows dev systems so have been completely blocked for the last 3 days |
20:31:41 | Araq | kristianmandrup: for JS interop .emit is the last resort |
20:31:50 | FromGitter | <kristianmandrup> Is this the right approach or not? |
20:31:57 | FromGitter | <kristianmandrup> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e2f48bd34829272793baca1] |
20:32:14 | Araq | wrong |
20:32:22 | Araq | use something like |
20:32:33 | disruptek | shashlick: i mean, do we really need to test on windows? |
20:32:41 | FromGitter | <kristianmandrup> I tried to use approach I found in `Html5Canvas` bindings |
20:32:42 | disruptek | you don't even have a windows machine. |
20:32:59 | Araq | proc testOnly*(name: cstring, fn: proc(done: bool)) {.importcpp: "only".} |
20:33:22 | shashlick | my primary driver is windows but i cannot dev on it |
20:33:31 | disruptek | why not? |
20:33:38 | * | cron quit (Quit: Leaving.) |
20:33:39 | shashlick | IT |
20:33:50 | FromGitter | <kristianmandrup> but in JS it should call `test.only` |
20:33:54 | disruptek | you can't run the code you write? |
20:34:19 | FromGitter | <kristianmandrup> `proc testOnly*(name: cstring, fn: proc(done: bool)) {.importcpp: "test.only".}` ?? |
20:34:23 | shashlick | no cause it can get quarantined as a threat sometimes |
20:34:32 | Araq | ok, so importc: "test.only" |
20:34:48 | FromGitter | <kristianmandrup> @Araq cool :) |
20:35:18 | FromGitter | <kristianmandrup> And `void` return type is implicit? |
20:35:36 | Araq | yeah. and bad style |
20:35:59 | disruptek | and might even break you in later nim. |
20:36:04 | Araq | disruptek, 'nigel' is nice. how can it possibly work? |
20:36:10 | disruptek | how can it not? |
20:36:55 | disruptek | well, i will tell you how it can not work: builds that are not reproducible. |
20:37:11 | Araq | which cloud provider does it run on? |
20:37:14 | disruptek | aws |
20:37:20 | Araq | aww |
20:37:30 | Araq | couldn't resist. |
20:37:50 | Araq | ok, I'm out of questions. |
20:37:59 | disruptek | worst-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:07 | shashlick | who is going to pay |
20:39:25 | disruptek | it costs almost nothing. |
20:39:43 | disruptek | for most usage, it will literally cost nothing. the free tier is quite broad. |
20:44:06 | shashlick | free tier is only a year, anyway, cannot argue $ beyond a point |
20:44:27 | * | xet7 quit (Remote host closed the connection) |
20:45:09 | disruptek | okay, sure. i'll pay for it. i have a good idea of what it's going to cost (again, almost nothing). |
20:45:29 | disruptek | but, the idea is that it's decentralized by design. |
20:45:31 | * | xet7 joined #nim |
20:47:19 | FromGitter | <kristianmandrup> I'd love to use Nim with Micro Frontends as well - using single-spa.js.org |
20:47:25 | disruptek | you 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:51 | FromGitter | <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:29 | disruptek | type !help |
20:52:40 | disruptek | get to know your buddy, disbot |
20:53:27 | disruptek | oh 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:12 | Araq | kristianmandrup: I think nimble can do it |
20:58:26 | Araq | '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:18 | Zevv | ~https://www.reddit.com/r/programming/comments/eunjuv/a_regex_engine_faster_than_pcre_written_in_nim/ |
21:26:20 | disbot | no 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:27 | FromGitter | <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:06 | disruptek | blame shashlick |
21:42:38 | disruptek | kayabaNerve: 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:54 | FromGitter | <kayabaNerve> disruptek: What's that supposed to do? I only added the print statement to verify the function finished :P |
21:47:03 | shashlick | ey |
21:47:13 | FromGitter | <kayabaNerve> Or are you saying just if true: the last line? |
21:48:01 | disruptek | yeah, just curious if the behavior changes. |
21:48:13 | FromGitter | <kayabaNerve> Nope |
21:48:35 | disruptek | how are you calling the async proc? |
21:49:01 | FromGitter | <kayabaNerve> It only errors on its 6th occurrency |
21:49:09 | FromGitter | <kayabaNerve> No idea why 6 |
21:49:15 | FromGitter | <kayabaNerve> I do also have manual Futures floating around |
21:49:30 | FromGitter | <kayabaNerve> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e2f5ae901914e3e045c5f26] |
21:49:35 | FromGitter | <kayabaNerve> Relevant calling code though. |
21:49:50 | FromGitter | <kayabaNerve> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e2f5afe9ad22d5bd5ef16c2] |
21:49:53 | FromGitter | <kayabaNerve> There's the def |
21:52:02 | FromGitter | <kayabaNerve> I'm working on a lot of code in this section right now. This one function didn't change though. |
21:52:18 | FromGitter | <kayabaNerve> I'm trying to think if my manual Futures could be related in any way. |
21:52:30 | disruptek | there's nothing special about "manual" futures. |
21:52:41 | FromGitter | <kayabaNerve> Only thing I can think of :P |
21:52:48 | disruptek | i mean, that's not really a thing. 😉 |
21:53:16 | FromGitter | <kayabaNerve> Futures not created via the async macro but manually initiated and completed via callbacks |
21:53:33 | disruptek | i do it all the time and it's fine. |
21:53:40 | FromGitter | <kayabaNerve> Good to know. |
21:53:55 | FromGitter | <kayabaNerve> Then I have no idea why this is. I'll try devel. |
21:54:03 | disruptek | no special-sauce in .async. but you know as well as i that the exceptions are thorny. |
21:55:34 | FromGitter | <kayabaNerve> I think it's the async generated code which has a under/overflow though |
21:55:50 | FromGitter | <kayabaNerve> I mean, my code finishes yet doesn't continue after await. |
21:56:02 | FromGitter | <kayabaNerve> Question is what I did to trigger it |
21:59:52 | FromDiscord_ | <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:52 | FromDiscord_ | <treeform> @Recruit_main_70007 mouse_event https://github.com/khchen/winim/blob/ebc70132af9c6f00efca9abd317461369dfd486b/winim/inc/winuser.nim#L4425 |
22:29:09 | FromDiscord_ | <treeform> https://stackoverflow.com/a/7967772 |
22:29:39 | FromDiscord_ | <Recruit_main_70007> thanks! |
22:30:10 | FromDiscord_ | <treeform> maybe try SendInput if that does not work... looks like its an old function |
22:30:18 | FromDiscord_ | <treeform> but SendInput requires building your own data structures which is harder |
22:30:56 | FromDiscord_ | <Recruit_main_70007> it worked |
22:31:11 | FromDiscord_ | <treeform> cool |
22:32:31 | * | solitudesf quit (Ping timeout: 265 seconds) |
22:35:44 | FromGitter | <NimStart> @treeform does fidget work? |
22:36:02 | FromGitter | <NimStart> I can compile it, but nothing shows up when I run it |
22:37:25 | FromGitter | <NimStart> with code from figma plugin or minimal example |
22:53:00 | * | ltriant joined #nim |
22:53:48 | FromDiscord_ | <Recruit_main_70007> which ones were the other kernel examples made in nim appart of nimkernel? |
22:56:02 | FromGitter | <NimStart> (https://files.gitter.im/nim-lang/Nim/CBc6/fidget-error.png) |
22:56:09 | FromGitter | <NimStart> (https://files.gitter.im/nim-lang/Nim/I3U3/fidget-error.png) |
22:56:46 | FromGitter | <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:24 | shashlick | Vscode remote ssh is amazing, guess I'm burning ram again |
23:08:43 | disruptek | what is that? |
23:11:41 | shashlick | https://code.visualstudio.com/docs/remote/remote-overview |
23:12:03 | shashlick | Everything works as if locally |
23:12:59 | disruptek | if you can ssh, why can't you just setup a server somewhere? |
23:13:16 | shashlick | That's just Linux |
23:13:29 | shashlick | Which is working fine within docker |
23:13:42 | disruptek | so vscode doesn't really help. |
23:16:10 | disruptek | pro tip: don't try to build llvm on a machine with only 512mb of memory. |
23:16:19 | disruptek | this will not end well, if it ends at all. |
23:16:33 | * | Ven`` joined #nim |
23:17:20 | FromGitter | <zetashift> What does `gensym` means in the context of templates/macros? |
23:17:32 | FromGitter | <zetashift> generated symbol? |
23:17:35 | disruptek | yep. |
23:19:00 | FromDiscord_ | <inv> Hello, probably nim-bug, can I post it here first? |
23:19:04 | disruptek | sure. |
23:19:30 | leorize | also don't try to build rust with less than 4g of ram |
23:19:50 | disruptek | and 2hrs to kill. |
23:20:11 | leorize | this is why I use `earlyoom` |
23:20:26 | leorize | because linux oom killer is horrible |
23:21:33 | FromDiscord_ | <inv> ```nim |
23:21:33 | FromDiscord_ | <inv> --- file #1 --- |
23:21:33 | FromDiscord_ | <inv> proc pemDecoderLoop(pem: string, prc: proc(ctx: pointer, pbytes: pointer, nbytes: int) {.cdecl, noSideEffect, gcsafe.}, ctx: pointer) = |
23:21:33 | FromDiscord_ | <inv> ... |
23:21:33 | FromDiscord_ | <inv> pemDecoderSetdest(addr pemCtx, prc, ctx) |
23:21:34 | FromDiscord_ | <inv> |
23:21:35 | FromDiscord_ | <inv> --- file #2 --- |
23:21:37 | FromDiscord_ | <inv> {.pragma: bearSslFunc, cdecl, gcsafe, noSideEffect.} |
23:21:39 | FromDiscord_ | <inv> proc pemDecoderSetdest*(ctx: ptr PemDecoderContext; dest: proc (destCtx: pointer; |
23:21:41 | FromDiscord_ | <inv> src: pointer; len: int) {.bearSslFunc.}; destCtx: pointer) {.inline.} = |
23:21:41 | FromDiscord_ | <inv> ``` |
23:21:52 | disruptek | inv you know the rules regarding pastes. |
23:21:55 | leorize | ~paste |
23:21:55 | disbot | paste: 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:05 | FromDiscord_ | <inv> oh, sorry, I know, but forgot again 😦 |
23:22:42 | leorize | Yardanico is writing an another discord bot that might save us all from this :P |
23:23:17 | FromDiscord_ | <inv> telegram-irc crossjoin would help better, does not like discord 🙂 |
23:23:21 | disruptek | let me guess, your bearSslFunc doesn't work? |
23:23:55 | leorize | @inv it's proposed, but people on telegram didn't like it |
23:24:21 | FromDiscord_ | <inv> @disruptek, compilation error: Expected cdecl, gcsafe, noSideEffect, but passed is cdecl only. 1 sec |
23:24:48 | FromDiscord_ | <inv> leorize, from telegram-people I heard that irc-people didn't like it 🙂 |
23:25:36 | leorize | *shrug* I heard the story from narimiran :P |
23:25:43 | leorize | well maybe you can propose it on the forums :P |
23:27:13 | FromDiscord_ | <inv> I did it: https://play.nim-lang.org/#ix=28x8 |
23:27:47 | FromDiscord_ | <inv> fix is {.pragma: bearSslFunc, cdecl, gcsafe, noSideEffect.} => {.pragma: bearSslFunc, cdecl.} |
23:27:56 | shashlick | @disruptek it is great to have a full vscode experience on a remote server |
23:27:58 | FromDiscord_ | <inv> But I suppose it is not correct |
23:28:18 | leorize | you should only enforce cdecl tbh |
23:28:20 | disruptek | but shashlick, what about feud? |
23:28:22 | leorize | much more flexible |
23:28:28 | leorize | but that seems to be a walkaround |
23:28:42 | shashlick | Some day, when I have infinite time and zero bugs |
23:28:49 | FromDiscord_ | <inv> leorize? It is not my lib, but why you expect cdecl only? |
23:28:58 | FromDiscord_ | <inv> leorize? It is not my lib, but why do you expect cdecl only? |
23:29:05 | FromDiscord_ | <inv> leorize. It is not my lib, but why do you expect cdecl only? |
23:29:18 | shashlick | Basically I need to put mind share where others aren't already |
23:29:20 | disruptek | WHY WHY WHY |
23:29:36 | shashlick | But feud was a success, we get a plugin system out of it |
23:29:41 | shashlick | I just need to extract it out |
23:29:43 | leorize | @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:46 | FromDiscord_ | <inv> ok, I am pretty sure, that without fix it is correct. |
23:29:52 | disruptek | shashlick: i wonder how arc changes all that. |
23:30:10 | leorize | also please avoid editing discord messages :P |
23:30:22 | leorize | it spams the irc with duplicates of your message |
23:30:37 | disruptek | we do love hearing from you, though. |
23:30:52 | shashlick | Arc should work the same as boehm eventually for feud |
23:31:16 | FromDiscord_ | <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:32 | disruptek | yeah, but with the shared heap you can simplify/omit the shared lib you wrote. |
23:32:06 | shashlick | Ya I removed it anyway, it wasn't needed with boehm but was a good experience |
23:32:26 | leorize | @inv: yea, should be filed as a bug :p |
23:32:34 | leorize | bonus points if you can make a small reproduction sample |
23:32:39 | leorize | which I imagine would be easy :P |
23:32:43 | FromDiscord_ | <inv> leorize, shame on you 🙂 |
23:33:05 | leorize | I was just voicing about how cdecl only would be more flexible :P |
23:33:38 | FromDiscord_ | <inv> I do not care about cdecl or cdecl,gcsafe , because it is my first week with nim 🙂 |
23:35:23 | FromDiscord_ | <inv> Probably where is another package to work with google-docs ? |
23:38:05 | leorize[m] | wdym? |
23:39:21 | leorize[m] | disruptek: iirc you notified me sometime ago for an unsolved bug in nim.nvim. Can I have the details again? |
23:39:58 | leorize[m] | about* |
23:40:00 | disruptek | just that ##[ set highlight but ]## wasn't seeming to terminate it. |
23:48:31 | FromDiscord_ | <inv> will go back in telegram |
23:55:41 | * | disrupteq joined #nim |