| 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 |