| 00:00:05 | FromDiscord | <exelotl> I really didn't like stdtmpl when I first encountered it but I've warmed to it now lol, it's quite pleasant to use |
| 00:22:26 | FromDiscord | <shadow.> but yeah |
| 00:46:03 | FromDiscord | <Filipe Duarte> I’ve been using R and Python for more than two years for scientific research and Data Science. December 2020, I decided to start learning Nim and have been enjoying it a lot! |
| 00:46:10 | * | hmmm quit (Quit: WeeChat 3.0) |
| 00:50:10 | FromDiscord | <Avatarfighter> @Filipe Duarte welcome to the community hopefully you enjoy us as much as the language 🙂 |
| 00:52:49 | * | krux02 quit (Remote host closed the connection) |
| 00:53:17 | FromDiscord | <shadow.> lmaoo |
| 00:56:23 | * | taprack joined #nim |
| 01:08:56 | * | shu41 joined #nim |
| 01:09:57 | shu41 | hey guys, I am sure this is dumb but how do you get the fields of a ref object? |
| 01:10:38 | shu41 | I get this Error: undeclared field: 'fields' for type tablereader.Record:ObjectType [declared in .. |
| 01:11:49 | shu41 | since iterator.fields and fieldPairs accept object I don't know how to send a ref object |
| 01:12:23 | FromDiscord | <ElegantBeef> `refObjVar[].fields` |
| 01:12:58 | shu41 | for [] I get this Error: undeclared field: 'fields' for type tablereader.Record:ObjectType |
| 01:13:31 | shu41 | for simple access Error: undeclared field: 'fields' for type tablereader.Record |
| 01:14:12 | shu41 | this is the definition of record: type Record = ref object |
| 01:14:22 | shu41 | maybe I am defining it wrong |
| 01:15:52 | FromDiscord | <ElegantBeef> https://play.nim-lang.org/#ix=2Lnq |
| 01:17:00 | shu41 | that is correct thank you ElegantBeef |
| 01:17:06 | FromDiscord | <ElegantBeef> No problem |
| 01:17:27 | shu41 | did not understand the error, I was just trying to echo the result of the iterator im dumb |
| 01:21:44 | shu41 | is there not a way to use map or mapIt? |
| 01:22:54 | FromDiscord | <ElegantBeef> There is an issue with sequtils they only work on openArrays, so you need to convert to a sequence. And there is an issue with `toSeq` since you have to call `toSeq(yourIterator)` 😄 |
| 01:25:11 | FromDiscord | <ElegantBeef> And if you're applying `toSeq`to the result of the `fields` iterator you'll probably run into an issue that the fields arent all a uniform type |
| 01:28:46 | FromDiscord | <shadow.> anyone experiences with raytracers? after adding fuzzy reflection im getting white borders instead of black and im not sure why https://media.discordapp.net/attachments/371759389889003532/797275632106864671/unknown.png |
| 01:29:13 | shu41 | I see, well I am using a single type for all members |
| 01:29:28 | shu41 | tho I got this other issue Error: type mismatch: got <seq[RootObj], string> |
| 01:30:02 | shu41 | let recseq = toSeq(record[].fields) |
| 01:30:49 | shu41 | error in proc add[T](x: var seq[T]; value: sink T) |
| 01:30:53 | FromDiscord | <ElegantBeef> Yea |
| 01:33:20 | FromDiscord | <ElegantBeef> fields is a weird since it can return different types |
| 01:34:44 | shu41 | well I might just loop then |
| 01:34:45 | FromDiscord | <ElegantBeef> https://play.nim-lang.org/#ix=2Lnv this is the best way i can think of doing it |
| 01:35:39 | FromDiscord | <Meowz> khchen isn't on discord is he? |
| 01:35:45 | FromDiscord | <shadow.> (edit) anyone experienced with raytracers? after adding fuzzy reflection im getting white borders instead of black and im not sure why https://media.discordapp.net/attachments/371759389889003532/797275632106864671/unknown.png |
| 01:35:47 | shu41 | yes I'll wrap it like that in a function thank you |
| 01:35:52 | FromDiscord | <shadow.> someone has asked that before lol i forget who |
| 01:36:11 | FromDiscord | <ElegantBeef> Weirdly you're getting some rimlight effect shadow |
| 01:36:18 | FromDiscord | <ElegantBeef> How bad is your raytracing code |
| 01:36:40 | FromDiscord | <ElegantBeef> Put differently, is it readable 😄 |
| 01:38:09 | * | a_chou joined #nim |
| 01:40:38 | * | grfork joined #nim |
| 01:41:57 | FromDiscord | <shadow.> uhh |
| 01:41:59 | FromDiscord | <shadow.> pretty readable yeah |
| 01:42:02 | FromDiscord | <shadow.> im using full variable names |
| 01:42:06 | FromDiscord | <shadow.> instead of .d .f .a .p |
| 01:42:20 | FromDiscord | <shadow.> .direction .fuzz .albedo .point |
| 01:42:20 | FromDiscord | <shadow.> etc |
| 01:42:27 | FromDiscord | <shadow.> i mean the fuzz code is tiny |
| 01:42:38 | FromDiscord | <shadow.> i just added that last line |
| 01:42:40 | FromDiscord | <shadow.> sent a code paste, see https://play.nim-lang.org/#ix=2Lnw |
| 01:42:43 | FromDiscord | <shadow.> and changed this one |
| 01:42:50 | FromDiscord | <shadow.> sent a code paste, see https://play.nim-lang.org/#ix=2Lnx |
| 01:42:56 | * | greenfork quit (Ping timeout: 240 seconds) |
| 01:42:56 | FromDiscord | <shadow.> the rim effect is typically rimshade idk why im getting rimlight lmao |
| 01:43:15 | FromDiscord | <ElegantBeef> just multiply the albedo by the fuzz 😄 |
| 01:43:33 | FromDiscord | <shadow.> where? |
| 01:43:43 | FromDiscord | <shadow.> in the initializer or in the scattering function |
| 01:43:46 | FromDiscord | <ElegantBeef> Uhh |
| 01:43:53 | FromDiscord | <shadow.> scattering calculation |
| 01:43:59 | FromDiscord | <ElegantBeef> I dont do raytracers so i dont know that the process looks like, i'm used to shaders |
| 01:44:03 | FromDiscord | <shadow.> ahh fair fair |
| 01:44:08 | FromDiscord | <shadow.> lemme check mratsim's |
| 01:45:36 | FromDiscord | <shadow.> still rimlighting how odd |
| 01:45:51 | FromDiscord | <ElegantBeef> Well it seems you're adding instead of multiplying your stel |
| 01:45:53 | FromDiscord | <ElegantBeef> (edit) "stel" => "step" |
| 01:46:27 | FromDiscord | <ElegantBeef> if you think about it anywhere with white should be 0 and everything else should be 1 |
| 01:46:43 | FromDiscord | <ElegantBeef> so yea i think you need to do ` (1 - scatterShadow)` |
| 01:47:11 | FromDiscord | <shadow.> `scattered = ray(rec.p, reflected + self.fuzz rng.random_in_unit_sphere(Vec3))` |
| 01:47:13 | FromDiscord | <shadow.> this is mratsims |
| 01:47:32 | FromDiscord | <shadow.> hm |
| 01:47:50 | FromDiscord | <shadow.> `result.fuzz = min(fuzz, 1)↵` |
| 01:47:52 | FromDiscord | <shadow.> same thing |
| 01:55:00 | FromDiscord | <shadow.> i wonder why it's buggin out |
| 02:01:35 | FromDiscord | <shadow.> @mratsim you've any idea? |
| 02:16:53 | disruptek | leorize: this this expected? /Error: Could not find any release named 'latest-version-1-4'. The provided branch (version-1-4) might not be tracked by nightlies, or is being updated./ via setup-nim 0.1.1 |
| 02:17:46 | leorize[m] | yes |
| 02:18:04 | leorize[m] | try a re run, it's about time nightlies release a new build |
| 02:18:16 | disruptek | okay, so there's a blackout window? |
| 02:18:56 | leorize[m] | around 30s while the release is being republished |
| 02:19:08 | disruptek | ah, i just got lucky. 😁 |
| 02:21:37 | * | a_chou quit (Quit: a_chou) |
| 02:23:32 | * | taprack quit (Quit: Lost terminal) |
| 02:23:52 | leorize[m] | yep :p |
| 02:24:34 | * | Tanger joined #nim |
| 02:27:43 | * | opal quit (Ping timeout: 240 seconds) |
| 02:28:48 | * | opal joined #nim |
| 02:28:53 | FromDiscord | <exelotl> is there a way to require an additional .c or .s file to be added to the build in my config.nims? |
| 02:30:05 | FromDiscord | <exelotl> I guess I can add it to a .nim file and then --import the nim file |
| 02:30:44 | * | shu41 quit (Remote host closed the connection) |
| 02:37:03 | * | adnan338 joined #nim |
| 02:37:15 | * | adnan338 quit (Client Quit) |
| 02:37:32 | * | adnan338 joined #nim |
| 02:37:56 | * | Tanger quit (Remote host closed the connection) |
| 02:41:37 | * | adnan338 quit (Read error: Connection reset by peer) |
| 03:13:07 | * | NimBot joined #nim |
| 03:25:15 | disruptek | it's because of people like you that i carry a hammer when i go out in public. |
| 03:29:42 | FromDiscord | <Avatarfighter> lmao |
| 04:12:11 | FromDiscord | <exelotl> don't worry disruptek, I'll be sure to pass --warning[UnusedImport]:off to avoid clogging my users' consoles with annoying messages caused by the --import |
| 04:13:21 | disruptek | it's exactly the kind of shit that my test runner won't support. |
| 04:15:56 | FromDiscord | <exelotl> for real though, what I'm trying to do is guarantee that crt0.s gets added to the build |
| 04:17:20 | FromDiscord | <exelotl> it's absolutely crucial that the file gets compiled and linked, yet it doesn't feel like it's the job of any library to add it, nor is it the user's responsibility |
| 04:18:05 | disruptek | isn't this what the compile pragma is for? |
| 04:18:58 | FromDiscord | <exelotl> yeah exactly, but in what file should I put that compile pragma? |
| 04:19:05 | disruptek | i don't care. |
| 04:21:15 | FromDiscord | <exelotl> so say I put it in mylibrary.nim, but someone wants to only use a small part of my library, so their program only imports mylibrary/helpermodule.nim |
| 04:21:32 | FromDiscord | <exelotl> now their program won't compile because it no longer links crt0 |
| 04:21:49 | leorize[m] | crt0.s? that's your c compiler responsibility |
| 04:22:04 | leorize[m] | and why do you need a custom crt0? |
| 04:24:16 | FromDiscord | <exelotl> GBA homebrew (it's a bare metal target) |
| 04:26:13 | * | spiderstew_ joined #nim |
| 04:28:38 | * | spiderstew quit (Ping timeout: 272 seconds) |
| 04:50:58 | leorize[m] | then shouldn't you configure your gcc to use it? |
| 04:51:07 | leorize[m] | it has to be linked first anyway |
| 04:51:24 | leorize[m] | you can't reliably do that from nim |
| 04:52:33 | FromDiscord | <ElegantBeef> What is the way to remove a variable from scope again, i swear i remember seeing someone do this previously |
| 04:52:37 | * | abm quit (Quit: Leaving) |
| 04:53:36 | disruptek | nah. |
| 04:54:18 | disruptek | this is kinda cool: https://github.com/disruptek/testes/blob/master/docs/demo.svg |
| 04:54:27 | disruptek | where it says "checking some things: r == 3" |
| 04:54:39 | disruptek | note the code block, "check r == 3" |
| 04:55:12 | disruptek | above "checking some things:" you see the symbols from that block /and their values/ when the test failed. |
| 05:03:29 | disruptek | ugh, this feature crashes cps. |
| 05:03:39 | disruptek | well, the compiler, anyway. |
| 05:05:22 | disruptek | no good fucking deed. |
| 05:07:16 | * | rockcavera quit (Remote host closed the connection) |
| 05:10:46 | FromDiscord | <exelotl> leorize: I can use a specs file to ensure that crt0.o is linked first, but the .o file has to exist first.↵My goal is that you can just install arm-none-eabi-gcc, install nim, install my nim package, and that's all you need to compile for GBA with Nim. |
| 05:16:35 | leorize[m] | you can have gcc compile that file on install for you |
| 05:19:19 | leorize[m] | I think if you add an install task you can customize what will be installed |
| 05:19:26 | leorize[m] | see gintro for a package that perform post install stuff |
| 05:19:50 | FromDiscord | <exelotl> I was just wondering about that, but then wouldn't my library would fail to install if you didn't already have arm-none-eabi-gcc ? |
| 05:20:17 | leorize[m] | but I'm not sure if that's worth the hassle, remember that configuration don't compose between packages |
| 05:59:19 | saem | Blah, welp that was a waste of an evening... turns out vs code outline view can either support hierarchy or support symbols outside the document, but not both at the same time... bum |
| 06:08:20 | * | waleee-cl quit (Quit: Connection closed for inactivity) |
| 06:18:28 | * | clemens3 quit (Quit: rebot) |
| 07:00:18 | * | clemens3 joined #nim |
| 07:22:30 | ForumUpdaterBot | New thread by Stefan_Salewski: Suggestions to reduce the number of compiler warnings for rtree module?, see https://forum.nim-lang.org/t/7357 |
| 07:52:23 | * | narimiran joined #nim |
| 08:05:37 | * | ^Q-Master^ quit (Ping timeout: 265 seconds) |
| 08:37:45 | * | Q-Master joined #nim |
| 08:42:49 | * | Q-Master quit (Ping timeout: 264 seconds) |
| 09:09:33 | * | Gustavo6046 quit (Ping timeout: 246 seconds) |
| 09:21:03 | * | Q-Master joined #nim |
| 09:23:01 | * | narimiran quit (Ping timeout: 264 seconds) |
| 09:24:25 | * | krux02 joined #nim |
| 09:46:51 | * | hnOsmium0001 quit (Quit: Connection closed for inactivity) |
| 10:31:25 | * | ofelas joined #nim |
| 10:32:31 | * | habamax joined #nim |
| 10:44:28 | * | hmmm joined #nim |
| 10:49:49 | * | hmmm quit (Ping timeout: 260 seconds) |
| 11:02:24 | * | keyle joined #nim |
| 11:24:30 | FromDiscord | <Meowz> Does anyone have some experience with ba0f3's subhook wrapper? |
| 11:58:37 | * | filcuc joined #nim |
| 12:00:01 | filcuc | is there a reference implementation on how to add support for destructors/arc (optionally remaining backward compatible). The idea is to remove finalizers from my NimQml package. |
| 12:08:32 | * | Vladar joined #nim |
| 12:08:33 | Vladar | join #kui |
| 12:08:45 | Vladar | oops, sorry |
| 12:14:30 | FromDiscord | <mratsim> A wild Vladar appears |
| 12:18:17 | FromDiscord | <zetashift> To make use join kui! |
| 12:35:33 | * | keyle quit (Quit: Lost terminal) |
| 12:36:13 | * | superbia joined #nim |
| 12:37:06 | * | zedeus quit (Quit: zedeus) |
| 12:37:52 | * | filcuc quit (Ping timeout: 246 seconds) |
| 12:38:03 | * | filcuc joined #nim |
| 12:40:37 | FromDiscord | <dom96> oof https://blog.shitiomatic.tech/post/haskell-is-a-bad-programming-language/ |
| 12:40:47 | FromDiscord | <dom96> I think we can learn something from this post |
| 12:43:19 | FromDiscord | <mratsim> > What’s even funnier is people saying that “Haskell doesn’t suck, the development environment does”. Haskell has had 30 years to improve itself and while there’s some headway, growth is ridiculously slow. Guess what? If people can work with C++ and create amazing tools with it, I don’t think that statement makes much sense.↵↵Give me better tools |
| 12:43:32 | FromDiscord | <Rika> ? |
| 12:43:48 | FromDiscord | <haxscramper> docgen |
| 12:44:08 | FromDiscord | <haxscramper> compiler messages too |
| 12:44:16 | FromDiscord | <Rika> oh you mean that |
| 12:44:31 | FromDiscord | <Rika> yeah nimsuggest + docgen + compiler errors are usually the main points i hear |
| 12:44:35 | FromDiscord | <mratsim> sent a long message, see http://ix.io/2LpR |
| 12:44:46 | FromDiscord | <Rika> yeah |
| 12:44:53 | FromDiscord | <haxscramper> I alreay have ~3k words for RFC on compiler errors |
| 12:45:02 | FromDiscord | <haxscramper> And I haven't even proofread it yet |
| 12:45:11 | FromDiscord | <dom96> yep |
| 12:45:11 | FromDiscord | <mratsim> The core Nim language is good and you can be very productive and build complex things already despite the rough edges |
| 12:45:18 | FromDiscord | <dom96> that is the lesson to take from this |
| 12:45:25 | FromDiscord | <haxscramper> docgen can (ans should) be implemented as external tool |
| 12:45:34 | FromDiscord | <dom96> we need to invest in tools |
| 12:45:42 | FromDiscord | <mratsim> btw, I happen to crash the compiler with an success exit code, no error, no message, no nothing, just plain exit :/ |
| 12:45:57 | FromDiscord | <haxscramper> well, it seems like this year we will be doing this finally, at least it looks like this to me |
| 12:46:04 | FromDiscord | <haxscramper> hopefully |
| 12:46:17 | FromDiscord | <dom96> @mratsim is it a quit() at compile-time? lol |
| 12:46:33 | FromDiscord | <dom96> @haxscramper yes, hopefully |
| 12:47:01 | FromDiscord | <dom96> @haxscramper why do we need such a long RFC for this? |
| 12:47:09 | FromDiscord | <haxscramper> because this is a complex problem |
| 12:47:11 | FromDiscord | <dom96> Just copy Rust's approach and improve them |
| 12:47:14 | FromDiscord | <mratsim> It's this: https://github.com/SciNim/flambeau/commit/ec43ff1d8efc85830e6dd804f6c0a58c5b28df2f#diff-a2f8bf8c648b0ad661eb70aa132b260531251d5f97e6201701128f57748e0a46R8 |
| 12:47:20 | FromDiscord | <haxscramper> huh, funny |
| 12:47:37 | FromDiscord | <mratsim> at first I thought it was CRTP, but CRTP works fine. |
| 12:47:43 | FromDiscord | <haxscramper> i mean I also need to address EDSL errors |
| 12:47:43 | FromDiscord | <dom96> 80% of good error messages is just handling all the edge cases |
| 12:47:57 | FromDiscord | <dom96> the rest is setting up a nice foundation to display them well |
| 12:48:13 | FromDiscord | <haxscramper> and also accounting for the fact we have UFCS, macros with embedded DSL, insane amount of codegen |
| 12:48:20 | FromDiscord | <mratsim> Rust approach begins by removing exceptions |
| 12:48:22 | FromDiscord | <dom96> So yes, you can write an RFC for this, but consider the word count of your RFCs too. We don't all have the time to read 3k words 🙂 |
| 12:48:32 | FromDiscord | <haxscramper> I mean, I have tons `static assert` in pattern matching |
| 12:48:44 | FromDiscord | <mratsim> you should use static: doAssert |
| 12:48:51 | FromDiscord | <haxscramper> yes, i do this |
| 12:48:54 | FromDiscord | <haxscramper> This sucks |
| 12:48:58 | FromDiscord | <mratsim> otherwise they aren't checked if compiled without checks |
| 12:49:21 | FromDiscord | <mratsim> also it would be good to have this discussion before DrNim |
| 12:49:37 | FromDiscord | <haxscramper> Error messages should also be maching-readable, because pretty-printing is not a solution for tooling |
| 12:49:47 | FromDiscord | <haxscramper> I can't regex-parse compiler output, this is not an option |
| 12:50:07 | FromDiscord | <haxscramper> Largely this is a list of particular errors with suggestion on fixing them |
| 12:50:13 | FromDiscord | <mratsim> so we have an Error type and a default pretty print? |
| 12:50:22 | FromDiscord | <dom96> DrNim shouldn't even be planned right now |
| 12:50:25 | FromDiscord | <haxscramper> In addition to rust/elm-like errors of course |
| 12:50:32 | FromDiscord | <lqdev> oh really? |
| 12:50:34 | FromDiscord | <dom96> it's yet another feature that will be used by the minority |
| 12:50:40 | FromDiscord | <lqdev> then how am i pulling it off in lint+ |
| 12:50:57 | FromDiscord | <mratsim> In Weave I have specific formatted assert because otherwise I can't know which thread threw what error: https://github.com/mratsim/weave/blob/master/weave/instrumentation/contracts.nim#L93-L103 |
| 12:51:00 | FromDiscord | <dom96> yep |
| 12:51:24 | FromDiscord | <dom96> There isn't much to discuss IMO, just make them better 🙂 |
| 12:51:28 | FromDiscord | <haxscramper> Well, I don't know? If you can regex-parse this https://media.discordapp.net/attachments/371759389889003532/797447445998731264/unknown.png |
| 12:51:34 | FromDiscord | <haxscramper> Good for you I'm amazed |
| 12:51:38 | FromDiscord | <haxscramper> At your regex skills, really |
| 12:51:43 | FromDiscord | <dom96> lol |
| 12:51:47 | FromDiscord | <lqdev> ok this. |
| 12:51:56 | FromDiscord | <lqdev> yeah i agree with you this is bad |
| 12:52:01 | FromDiscord | <haxscramper> I can write like two lines of `sequtils` that generate C++-level of template shit |
| 12:52:02 | FromDiscord | <mratsim> try "items" |
| 12:52:18 | FromDiscord | <haxscramper> Dont' get me started on callback signature mismatch type errors |
| 12:52:23 | FromDiscord | <dom96> the error messages given by Nim have largely been unchanged for like 10 years btw |
| 12:52:23 | FromDiscord | <mratsim> with generic sandwich and "toSeq" you're guaranteed to pull your hair |
| 12:52:24 | FromDiscord | <haxscramper> These are absolutely unreadable |
| 12:52:28 | FromDiscord | <lqdev> try causing a concept mismatch :) |
| 12:52:41 | FromDiscord | <haxscramper> https://media.discordapp.net/attachments/371759389889003532/797447751994179584/unknown.png |
| 12:53:02 | FromDiscord | <mratsim> no need, use toSeq on a hashset from a module that doesn't import sets directly ... |
| 12:53:12 | FromDiscord | <haxscramper> oh, yeah, something |
| 12:53:18 | FromDiscord | <lqdev> i remember like a 10000 lines long error i got from concepts one dat |
| 12:53:32 | FromDiscord | <lqdev> don't remember the exact number but buy it was a frickin' behemoth |
| 12:53:39 | FromDiscord | <lqdev> (edit) "buy" => "boy" |
| 12:53:40 | FromDiscord | <haxscramper> well |
| 12:53:48 | FromDiscord | <lqdev> (edit) "dat" => "day" |
| 12:53:56 | FromDiscord | <dom96> Another reason why concepts should be simplified... |
| 12:54:02 | FromDiscord | <lqdev> gosh, typing on mobile is a chore |
| 12:54:10 | FromDiscord | <dom96> And I'm hopeful Araq will get it done |
| 12:54:16 | FromDiscord | <lqdev> yeah |
| 12:54:25 | FromDiscord | <mratsim> that's not the issue of concepts here |
| 12:54:33 | FromDiscord | <lqdev> but imo fast IC is a bigger priority than new concepts |
| 12:54:57 | FromDiscord | <dom96> If it makes the compiler work better then yes |
| 12:55:00 | FromDiscord | <mratsim> it's the issue of the type system: generics concepts, distincts, static, being a very complex beast that was developed in an organic manner |
| 12:55:12 | FromDiscord | <dom96> if it's just for speed the IC is a silly effort (right now at least) |
| 12:55:14 | FromDiscord | <mratsim> oh, and range and varargs and openarray |
| 12:55:18 | FromDiscord | <dom96> (edit) "the" => "then" |
| 12:55:33 | FromDiscord | <mratsim> We do start to spend a lot of time compiling in Status codebase |
| 12:55:45 | FromDiscord | <lqdev> remember that the Nim IDE experience is hindered greatly by the compiler being slow |
| 12:55:54 | FromDiscord | <lqdev> "slow" |
| 12:56:06 | FromDiscord | <lqdev> slow to recompile your project every 100ms |
| 12:56:28 | FromDiscord | <dom96> I don't think that's the case. Nimsuggest already caches ASTs |
| 12:56:33 | FromDiscord | <mratsim> but why does the IDE needs to recompile |
| 12:56:35 | FromDiscord | <dom96> It just does it in a really poor way |
| 12:56:49 | FromDiscord | <dom96> so you get issues like infinite loops and high memory usage |
| 12:56:54 | FromDiscord | <dom96> it's already fast enough |
| 12:57:03 | FromDiscord | <lqdev> also, my game compiles in about 8s which makes fast prototyping a chore |
| 12:57:14 | FromDiscord | <haxscramper> I couldn't export outline for my RFC draft, but these are main topics that I want to address for compilation errors https://media.discordapp.net/attachments/371759389889003532/797448898507046912/unknown.png |
| 12:57:25 | FromDiscord | <dom96> > We do start to spend a lot of time compiling in Status codebase↵have you measured how long that is spent in the Nim compiler vs. c compiler? |
| 12:57:35 | FromDiscord | <dom96> same question to you lqdev |
| 12:57:50 | FromDiscord | <haxscramper> So these are /mostly/ specific encounters that I wrote down over the course of several months, with couple paragraphs of explanations for each one |
| 12:57:57 | FromDiscord | <lqdev> @dom96 C object files are cached, most time is spent on codegen |
| 12:58:12 | FromDiscord | <zetashift> Didn't Araq write in a RFC/issue that Nim compiler is usually the bottleneck, since C compiler is plenty fast? |
| 12:58:12 | FromDiscord | <lqdev> the C portion takes maybe .5-1s |
| 12:58:15 | FromDiscord | <dom96> @haxscramper those just sound like specific bugs, why do we need to discuss them as part of an RFC? |
| 12:58:22 | FromDiscord | <mratsim> When you have concepts and generics, which are key for serialization and it's only there that we use them, you're codebase gets very slow. |
| 12:58:29 | FromDiscord | <mratsim> (edit) "you're" => "your" |
| 12:58:33 | FromDiscord | <haxscramper> These are not "bugs" |
| 12:58:41 | FromDiscord | <haxscramper> I mean if you have one bad error we have a bug |
| 12:58:42 | FromDiscord | <lqdev> especially because concept instantiations aren't cached! |
| 12:58:50 | FromDiscord | <haxscramper> If all errors are bad |
| 12:58:56 | FromDiscord | <haxscramper> We have a systematic problem |
| 12:59:04 | FromDiscord | <haxscramper> That needs to be adressed in organized way |
| 12:59:05 | FromDiscord | <dom96> @haxscramper bad errors messages are bugs |
| 12:59:22 | FromDiscord | <mratsim> I agree, errors needs some kind of coherent vision |
| 12:59:24 | FromDiscord | <dom96> and yes, there is a systematic problem too |
| 12:59:35 | FromDiscord | <dom96> but you need to set up a system for tackling each specific case |
| 12:59:36 | FromDiscord | <lqdev> @dom96 outlining all bad errors in one RFC and discussing how we can improve them is better imo |
| 12:59:48 | FromDiscord | <mratsim> if people monkey patch errors each in a different way that will be a bazaar |
| 13:00:06 | FromDiscord | <dom96> @lqdev how do you expect people to engage with many tens of different error messages in an RFC setting? |
| 13:00:07 | FromDiscord | <haxscramper> I mean we can't talk about user-friendliness unless we have things like https://forum.nim-lang.org/t/7343 |
| 13:00:08 | FromDiscord | <mratsim> better have a coherent whole |
| 13:00:30 | FromDiscord | <haxscramper> Where new user just got destroyed by this wall of text |
| 13:00:34 | FromDiscord | <lqdev> the question of error machine readability is also a good point that needs to be brought up |
| 13:00:34 | FromDiscord | <mratsim> Maybe we can use a PR for that RFC? |
| 13:00:41 | FromDiscord | <haxscramper> "this is obvious" you might say |
| 13:00:45 | FromDiscord | <mratsim> because with PR we have threads |
| 13:00:57 | FromDiscord | <dom96> > Didn't Araq write in a RFC/issue that Nim compiler is usually the bottleneck, since C compiler is plenty fast?↵I hope Araq showed some benchmarks to back this up 🙂 |
| 13:01:00 | FromDiscord | <haxscramper> I'm aiming for something like error index |
| 13:01:05 | FromDiscord | <haxscramper> rust's error index |
| 13:01:25 | FromDiscord | <haxscramper> error code + example + explanation |
| 13:01:40 | FromDiscord | <zetashift> https://github.com/nim-lang/RFCs/issues/46 uhm, he did give reasoning if that suffices 😛 |
| 13:01:41 | disbot | ➥ Incremental compilation |
| 13:02:04 | FromDiscord | <dom96> of course, you shouldn't just tackle each error as it comes. You need a better mechanism for these errors first. |
| 13:02:14 | FromDiscord | <dom96> But once you do, we should treat each subpar error message as a bug |
| 13:02:24 | FromDiscord | <lqdev> @dom96 i can't benchmark it for you right now as i'm not home but if it was trivial i could just tell you to compile planet overgamma and see how much time is spent on ........ and how much time is spent on CC: |
| 13:02:30 | ForumUpdaterBot | New post on r/nim by justhanginuknow: A few questions about ptr, ref and function parameters, see https://www.reddit.com/r/nim/comments/ktqj22/a_few_questions_about_ptr_ref_and_function/ |
| 13:02:30 | FromDiscord | <haxscramper> Fine by me |
| 13:02:32 | FromDiscord | <dom96> (we already do this, without yet having a better mechanism for showing the errors) |
| 13:02:42 | FromDiscord | <lqdev> unfortunately compiling PO isn't trivial so i'm not tellimg you to do it |
| 13:02:51 | FromDiscord | <lqdev> (edit) "tellimg" => "telling" |
| 13:03:07 | FromDiscord | <dom96> I mean. I can just check one of my projects I guess |
| 13:03:22 | FromDiscord | <lqdev> well it depends on how big the project is |
| 13:03:29 | FromDiscord | <haxscramper> And one important thing that needs to be adressed is support for user-defined error messages, in various DSLs |
| 13:03:43 | FromDiscord | <haxscramper> Because `std/macros.error` is just insufficient |
| 13:04:17 | FromDiscord | <haxscramper> And show me original source code please, not this mess that comes out of `join` or whatever |
| 13:04:42 | FromDiscord | <haxscramper> This is also related to automatic API breakage detection |
| 13:04:52 | FromDiscord | <haxscramper> If I cant' get compilation errors I can't reason about them |
| 13:05:03 | ForumUpdaterBot | New thread by Stefan_Salewski: Calling destructors works fine, see https://forum.nim-lang.org/t/7360 |
| 13:05:33 | FromDiscord | <dom96> 3.78 secs for Stardust without C compiler. 10.6 secs with C compiler. Then 4. 35 secs once the C cache is there. |
| 13:05:39 | FromDiscord | <dom96> (edit) "4. 35" => "4.35" |
| 13:06:05 | FromDiscord | <dom96> So yeah, I suppose the majority is in the Nim compiler. But how much can you actually speed that up with IC. |
| 13:06:15 | FromDiscord | <lqdev> the C cache improves a lot, but a Nim cache would help a lot too |
| 13:06:57 | FromDiscord | <lqdev> and that's what rodfiles are supposed to solve. last time i checked araq-ic6 compilation times weren't much better though |
| 13:07:00 | FromDiscord | <dom96> +1 on that |
| 13:08:09 | FromDiscord | <dom96> The funny thing is that rodfiles aren't a new thing, there was an attempt at this before. I hope it works out better this time. |
| 13:08:27 | FromDiscord | <dom96> But I would still prefer effort to be put into improving the developer experience + package management. |
| 13:10:11 | FromDiscord | <lqdev> i mean IC will solve a lot of existing nimsuggest issues so it's a good first step |
| 13:11:41 | FromDiscord | <dom96> There is a lot of risk involved though and the point is that there are more impactful things that can be done |
| 13:11:55 | FromDiscord | <dom96> For example, a solid compiler-less implementation of nimsuggest |
| 13:12:14 | FromDiscord | <dom96> It might not give 100% semantically correct suggestions, but it can make the job easier for 95% of use cases |
| 13:12:17 | * | superbia quit (Quit: WeeChat 3.0) |
| 13:12:23 | FromDiscord | <dom96> And it's also likely to be far faster and more stable |
| 13:12:31 | FromDiscord | <haxscramper> https://twitter.com/lzsthw/status/1326931878016901120 and we also need to consider that people are coming from different languages, and also make it easier to reiterate on error messages when needed |
| 13:12:48 | FromDiscord | <haxscramper> Rants like this are actually pretty valuable |
| 13:13:21 | FromDiscord | <haxscramper> http://al6x.com/blog/2020/nim-language or thing at the end |
| 13:13:25 | FromDiscord | <dom96> TIL async/await is a Haskell invention https://news.ycombinator.com/item?id=25699961 |
| 13:15:14 | * | Q-Master quit (Ping timeout: 256 seconds) |
| 13:19:20 | FromDiscord | <mratsim> continuations existed in the 70s |
| 13:20:08 | FromDiscord | <dom96> Yes, it's really about where you draw the line |
| 13:20:29 | FromDiscord | <mratsim> https://www.cs.tufts.edu/~nr/cs257/archive/john-reynolds/histcont.pdf |
| 13:20:52 | FromDiscord | <mratsim> Also continuations can represent any monads: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.43.8213&rep=rep1&type=pdf |
| 13:20:59 | FromDiscord | <dom96> async/await specifically was still first present in C# |
| 13:21:24 | FromDiscord | <dom96> but you could argue that Haskell's monads were close enough to be considered the same |
| 13:21:38 | FromDiscord | <mratsim> async/await = continuation + storing the continuation in a scheduler |
| 13:21:57 | FromDiscord | <mratsim> or at least that's my understanding after reading dozens of continuation and coroutines papers |
| 13:22:26 | FromDiscord | <mratsim> that's why I think CPS is important. It reduces the difference between chronos, asyncdispatch, threadpool, weave to just the scheduler |
| 13:22:40 | FromDiscord | <mratsim> strip the scheduler and all is interoperable |
| 13:30:49 | * | filcuc quit (Ping timeout: 264 seconds) |
| 13:31:11 | FromDiscord | <0xc45> sent a code paste, see https://play.nim-lang.org/#ix=2Lqa |
| 13:32:10 | FromDiscord | <mratsim> @0xc45 https://github.com/mratsim/photon-jit/blob/ef1954406d6f23677f702151397fcd6d3889aad3/photon_jit/photon_types.nim#L79-L93 |
| 13:33:16 | FromDiscord | <dom96> > strip the scheduler and all is interoperable↵sounds like a great proposition, but what is it about CPS that makes it interoperable over closure iterators? |
| 13:34:03 | FromDiscord | <mratsim> CPS does the transformation and the closure instead of each scheduler having to do it themselves. |
| 13:34:12 | FromDiscord | <Recruit_main707> what was the reason a socket could get blocked when receiving x bytes, trying to read from it without having anything? |
| 13:34:27 | FromDiscord | <dom96> @mratsim the scheduler doesn't really do much of a transformation though |
| 13:34:29 | FromDiscord | <mratsim> furthermore besides closure iterators, you can represent IO as suspending proc directly |
| 13:34:31 | FromDiscord | <dom96> it just inserts yield calls |
| 13:34:44 | FromDiscord | <dom96> the compiler still does the bulk of the transformation |
| 13:35:17 | FromDiscord | <mratsim> you can reimplement closure iterators on top of continuations: https://github.com/disruptek/cps/blob/mratsim-public-api-proposal/mratsim/ex06_coroutines.nim#L8-L12 |
| 13:35:27 | FromDiscord | <mratsim> this allows a smooth transition |
| 13:35:34 | FromDiscord | <Meowz> @Recruit_main707 since I know you've did some similar stuff. Did you ever worked with a hooking library in nim? |
| 13:35:43 | * | opal quit (Ping timeout: 240 seconds) |
| 13:36:19 | FromDiscord | <mratsim> sent a code paste, see https://play.nim-lang.org/#ix=2Lqd |
| 13:36:20 | FromDiscord | <Recruit_main707> nope, i didnt get that far @Meowz |
| 13:36:29 | * | opal joined #nim |
| 13:37:59 | FromDiscord | <0xc45> Thanks, I'll look into that! |
| 13:38:20 | FromDiscord | <Meowz> Alrighty |
| 13:42:19 | FromDiscord | <dom96> @mratsim what specifically from this do they not allow? |
| 13:43:03 | FromDiscord | <mratsim> the {.suspend.} functions |
| 13:43:07 | FromDiscord | <dom96> resuming closure iterators across different threads? |
| 13:43:30 | * | Q-Master joined #nim |
| 13:43:35 | FromDiscord | <dom96> Actually, you're not even doing that there |
| 13:43:42 | FromDiscord | <mratsim> I am |
| 13:43:43 | FromDiscord | <dom96> Since each scheduled lives in its own thread |
| 13:43:48 | FromDiscord | <dom96> (edit) "scheduled" => "scheduler" |
| 13:44:07 | FromDiscord | <dom96> so you have a scheduler per thread |
| 13:44:17 | FromDiscord | <dom96> exactly how asyncdispatch operates |
| 13:44:57 | FromDiscord | <mratsim> you can have different schedulers on the same threads and pass continuations or coroutines between each other |
| 13:45:35 | FromDiscord | <mratsim> also ioScheduler is asyncdispatch or chronos |
| 13:45:44 | FromDiscord | <mratsim> cpuScheduler is threadpool or Weave |
| 13:46:22 | FromDiscord | <mratsim> but as I'm saying CPS removes all the packing into resumable closures part of any scheduler |
| 13:46:59 | FromDiscord | <mratsim> that's benefit 1, the second is simplifying suspending IO functions. |
| 13:47:09 | FromDiscord | <dom96> I think it's important to be clear what the differences here actually are |
| 13:47:21 | FromDiscord | <dom96> And right now it appears to just be the API that these are exposed under |
| 13:49:13 | FromDiscord | <mratsim> There are 2 things: closure iterators and async/await:↵↵CPS replaces closure iterators, closure iterators are basically coroutines, we can reimplement coroutines with continuations, in my PoC, a coroutine is a continuation with a promise: https://github.com/disruptek/cps/blob/mratsim-public-api-proposal/cps/core/spec.nim#L33-L66 |
| 13:50:08 | PMunch | Are there seriously no-one who knows about the DLL packaging for Nim? https://forum.nim-lang.org/t/7353 |
| 13:50:10 | FromDiscord | <mratsim> Using continuations directly instead of the closure iterators removes redundancy in schedulers, that needs to emulate continuations with closure iterators |
| 13:50:17 | PMunch | It's starting to get a bit critical.. |
| 13:50:37 | PMunch | We're cutting a new release of our project which involves Nim code, and currently it doesn't build |
| 13:50:47 | FromDiscord | <mratsim> ping @Araq |
| 13:50:53 | FromDiscord | <dom96> huh, you're using NIm at work? 😮 |
| 13:50:56 | FromDiscord | <dom96> (edit) "NIm" => "Nim" |
| 13:51:00 | PMunch | Yup |
| 13:51:08 | PMunch | Snuck it in when no-one was looking :P |
| 13:51:27 | * | NimBot joined #nim |
| 13:51:51 | FromDiscord | <dom96> right, but then it's not even about CPS. It's just about exposing continuations in all contexts, which are more generic than closure iterators |
| 13:51:59 | FromDiscord | <dom96> CPS is just a way to implement continuations |
| 13:52:13 | PMunch | We used some software that supported extension by Python code (Unbound DNS server). I made a PR to it to allow it to also support DLLs/.so files so I could rewrite our code in Nim and tell everyone it was now much faster. |
| 13:52:31 | FromDiscord | <dom96> And in fact, we already have a continuations implementation in Nim https://github.com/nim-lang/Nim/blob/devel/lib/pure/coro.nim |
| 13:52:39 | FromDiscord | <mratsim> I would be happy to explore other ways to implement continuations |
| 13:53:12 | Zevv | coro |
| 13:53:17 | FromDiscord | <mratsim> That's not continuations though that's fibers |
| 13:53:23 | Zevv | is not portable, uses large stacks and is slow |
| 13:53:25 | FromDiscord | <mratsim> they need to have their own stack |
| 13:53:39 | FromDiscord | <dom96> @mratsim if you have the time it might be worthwhile to do research on other approaches |
| 13:54:00 | FromDiscord | <dom96> Including how other languages implement continuations |
| 13:54:11 | FromDiscord | <mratsim> you mean i didn't spend enough time or my research is incomplete? https://github.com/weavers-guild/weave-io/blob/master/research/README.md |
| 13:54:12 | Zevv | he did *tons* of that dom96 |
| 13:54:12 | FromDiscord | <dom96> I'd be interested to know how they implement it, if they even do so at all |
| 13:54:13 | Zevv | for weeks |
| 13:54:21 | Zevv | did you go through https://github.com/weavers-guild/weave-io/blob/master/research/README.md ? |
| 13:54:52 | FromDiscord | <dom96> huh? He just suggested exploring "other ways to implement continuations" |
| 13:55:11 | FromDiscord | <dom96> I'm not saying he hasn't done his research on CPS |
| 13:55:25 | FromDiscord | <dom96> I think it would be worthwhile to look into these other ways |
| 13:55:32 | FromDiscord | <mratsim> It has Scheme, Guile, Ocaml, abandoned C++ implementations, C++, Kotlin, failed Java, Rust and Go fibers, unreleased Swift proposals, Python, stackless Python |
| 13:55:52 | FromDiscord | <mratsim> I research them all |
| 13:56:04 | FromDiscord | <mratsim> C# F# as well |
| 13:56:18 | FromDiscord | <mratsim> I scourged the mailing lists for complaints |
| 13:56:31 | FromDiscord | <mratsim> academic papers |
| 13:56:52 | FromDiscord | <mratsim> I watched all the talks I linked in that readme |
| 13:57:05 | FromDiscord | <dom96> I was referring to this |
| 13:57:05 | Zevv | and evne made me watch and read a few! |
| 13:57:13 | FromDiscord | <dom96> Please do this if you have the time and will 🙂 |
| 13:58:05 | FromDiscord | <mratsim> Yes, so CPS is the way to implement continuations for arbitrary languages |
| 13:58:11 | FromDiscord | <mratsim> in particular C and Javascript |
| 13:58:26 | FromDiscord | <mratsim> which are our limitations |
| 13:58:37 | FromDiscord | <mratsim> if we can't represent something in C or Javascript we can't use it. |
| 14:00:13 | FromDiscord | <mratsim> a small explanation of alternatives are here: https://wiki.c2.com/?ContinuationImplementation↵and here: file:///tmp/mozilla_beta0/Clinger1999_Article_ImplementationStrategiesForFir.pdf↵↵But they involve assembly |
| 14:00:29 | FromDiscord | <mratsim> ugh: https://link.springer.com/content/pdf/10.1023/A:1010016816429.pdf |
| 14:00:33 | Zevv | because you need to mess with the stack pointer. |
| 14:00:49 | Zevv | good luck running that in JS |
| 14:02:40 | FromDiscord | <dom96> huh, how are you planning to use coroutines on JS? |
| 14:02:52 | FromDiscord | <mratsim> cps works on JS |
| 14:03:02 | FromDiscord | <zetashift> @PMunch I can't find anything in the commits that might indicate libssl requirements changed, I'm not sure how it got removed but don't people usually just ship their DLLs and the program in one go? |
| 14:03:05 | Zevv | dom96: really, try to spend an evening to understand how this works |
| 14:03:12 | FromDiscord | <dom96> @PMunch: I replied to your forum thread |
| 14:03:17 | Zevv | CPS is almost nothihng. IT is just a transformation |
| 14:03:27 | FromDiscord | <dom96> Zevv: I did. I understand how it works. |
| 14:03:42 | Zevv | ok, cool |
| 14:03:59 | Zevv | but then why do you ask about how it can work on JS |
| 14:04:35 | Zevv | because there is no black magic involved. It is just a transformation chopping a function in multiple functions and passing data around. It is 100% Nim |
| 14:04:42 | FromDiscord | <dom96> Well, I'm thinking about it in terms of the browser which already exposes it's IO through callbacks and promises. |
| 14:04:49 | Zevv | coroutines != async I/O |
| 14:04:55 | FromDiscord | <dom96> I don't really see why you'd want it on the JS target |
| 14:05:10 | Zevv | because all the other benefits coroutines and CPS can bring |
| 14:05:17 | FromDiscord | <mratsim> I certainly want them to work in WASM |
| 14:05:31 | Zevv | coroutines are so much more then a way to schedule I/O |
| 14:05:42 | FromDiscord | <dom96> well, WASM is a different beast altogether |
| 14:06:12 | FromDiscord | <dom96> I doubt you'd run into many limitations there |
| 14:06:45 | FromDiscord | <mratsim> I list several use cases for continuations here: https://github.com/weavers-guild/weave-io/blob/master/design/design_2_continuations.md#motivation |
| 14:07:30 | PMunch | zetashift, which commits? I tried to look in the repo but I couldn't even find where the dlls.zip file comes from. |
| 14:07:32 | FromDiscord | <mratsim> sent a long message, see https://paste.rs/uTG |
| 14:07:52 | PMunch | And dom96 I replied back, where did windeps.zip come from? |
| 14:08:01 | FromDiscord | <mratsim> Basically, continuations are terrific for represention most producer -> consumer workflows |
| 14:08:23 | * | opal quit (Ping timeout: 240 seconds) |
| 14:08:33 | FromDiscord | <zetashift> @PMunch I mean I didn't find any commits! So I don't know how dlls changed, I thought the repo nim-website might give an indication |
| 14:09:00 | FromDiscord | <zetashift> https://nim-lang.org/install_windows.html UNder "other dependencies" |
| 14:09:11 | FromDiscord | <dom96> @mratsim right, well, all I really care about is the IO aspect of this. Everything else seems like fluff to me, I mean why would I use coroutines to serialize forms when 99.9999% of the web just serializes it to JSON or whatever |
| 14:09:14 | FromDiscord | <zetashift> (I think it's been there for a while) |
| 14:09:19 | PMunch | Yeah I also went looking for them, but I couldn't figure out where that dlls.zip file came from.. |
| 14:09:25 | FromDiscord | <dom96> PMunch: they're custom made |
| 14:09:35 | FromDiscord | <dom96> Just a set of DLLs zipped together |
| 14:09:41 | FromDiscord | <mratsim> for fast prototyping. |
| 14:09:58 | PMunch | zetashift, yeah the file itself has existed for a long time, and been linked to on the website. But I've never seen how it's made |
| 14:10:07 | Zevv | dom96: it can be fluff to you, interestingly enough it is one of my #1 missing features since I started in Nim |
| 14:10:16 | * | vicfred joined #nim |
| 14:10:24 | FromDiscord | <dom96> PMunch: imagine Araq downloading a bunch of DLLs and putting them into a zip. That's how it was made 😛 |
| 14:10:25 | FromDiscord | <mratsim> if you only care about IO, just know that we can reimplement closure iterators in terms of CPS. |
| 14:10:26 | PMunch | dom96, so there's no record of why libssl was moved? And where did you find windeps.zip? I can't find a link to that anywhere.. |
| 14:10:44 | * | opal joined #nim |
| 14:10:44 | PMunch | That seems.. Brittle |
| 14:10:51 | FromDiscord | <mratsim> That seems unsafe |
| 14:10:58 | FromDiscord | <dom96> PMunch: I know it from memory. AFAIK dlls was meant to be replaced by it |
| 14:10:59 | leorize[m] | PMunch: Araq never revealed that. I can automate that eventually so we got an open source version, but not now :p |
| 14:11:00 | FromDiscord | <mratsim> and unreproduceable |
| 14:12:08 | * | hmmm joined #nim |
| 14:12:47 | FromDiscord | <dom96> Zevv: from my perspective it's a lot of effort and hype for something that when analysed is going to maybe enable some very niche use cases |
| 14:12:53 | PMunch | leorize[m], well it should at least not change without any mention in the changelog |
| 14:12:59 | FromDiscord | <dom96> (edit) "is" => "seems like it's" |
| 14:13:55 | leorize | oh, that changed when I requested 4raq to update dlls |
| 14:14:02 | FromDiscord | <dom96> Ideally we would have .sha256 sums like we do for releases https://nim-lang.org/download/nim-1.4.2_x64.zip.sha256 |
| 14:14:24 | FromDiscord | <mratsim> "very niche" is very condescending |
| 14:14:30 | leorize | he just say to use windeps instead and I'm not sure what he did to dlls.zip |
| 14:14:38 | FromDiscord | <mratsim> interop between IO and CPU scheduler is not a niche usecase |
| 14:14:52 | FromDiscord | <dom96> It is when that interop is already possible |
| 14:14:55 | leorize | but yea, eventually I'll make nightlies fully reproducible, and that includes dlls |
| 14:14:58 | FromDiscord | <dom96> with what we have today |
| 14:15:09 | FromDiscord | <dom96> Apologies if it comes off condescending, not my intention |
| 14:15:10 | PMunch | leorize, then maybe that file should be linked on the website? |
| 14:15:20 | PMunch | Instead of only dlls.zip |
| 14:15:23 | FromDiscord | <mratsim> There is no way to use closure iterators for CPU scheduling |
| 14:15:39 | FromDiscord | <mratsim> they are just plain wrong, they pollute your cache with GC things |
| 14:15:42 | PMunch | And how is windeps different from dlls? It's not like I'm using dlls on any other platform than Windows.. |
| 14:16:00 | leorize[m] | PMunch: ping Araq I guess |
| 14:16:23 | FromDiscord | <mratsim> How do you pass streams across threads and await them? |
| 14:16:38 | FromDiscord | <mratsim> continuations simplifies that |
| 14:17:01 | FromDiscord | <mratsim> how do you handle low-level sessions and protocols |
| 14:17:11 | FromDiscord | <mratsim> you make them continuations that are suspended and resumed |
| 14:17:23 | FromDiscord | <mratsim> can't use closure iterators in cryptography or kernel mode drivers |
| 14:17:53 | FromDiscord | <mratsim> sure you can use state machines, but state machines needs a codegenerator or they quickly become hairy |
| 14:18:36 | FromDiscord | <dom96> well, let's go back to what prompted this discussiong: |
| 14:18:37 | FromDiscord | <dom96> (edit) "discussiong:" => "discussion:" |
| 14:18:39 | FromDiscord | <dom96> > that's why I think CPS is important. It reduces the difference between chronos, asyncdispatch, threadpool, weave to just the scheduler |
| 14:18:54 | FromDiscord | <dom96> I would argue that the difference is already just the scheduler |
| 14:19:07 | FromDiscord | <dom96> that's all |
| 14:19:12 | FromDiscord | <mratsim> And Futures and Timers, And Streams and everything that comes with them |
| 14:19:48 | FromDiscord | <dom96> You will have the same interoperability problems between asyncdispatch and chronos as you do now |
| 14:20:12 | FromDiscord | <mratsim> that doesn't need to be so. All of that can be represented via something Awaitable that is just "if not foo.isReady(): saveContinuation; foo.get()" |
| 14:21:20 | FromDiscord | <mratsim> this would make switching schedulers easier because there is less associated bagage to switch as well |
| 14:21:44 | FromDiscord | <dom96> okay, so you want to separate the Awaitable concept from these too |
| 14:23:13 | * | waleee-cl joined #nim |
| 14:23:47 | FromDiscord | <mratsim> Also from a theoretical point of view, as I said, continuations have been proven to be able to represent any Monads, and also any control flow. And scheme uses that to extend the language with new concepts when they appear in other languages, including async/await. |
| 14:24:01 | FromDiscord | <mratsim> They are the AST macros of control flow. |
| 14:25:37 | FromDiscord | <dom96> What is also always in my mind is the question of how long implementing this and making it stable will take. 2 months? a year? 5 years? |
| 14:25:57 | Zevv | what does it matter? Is something critical blocked by this? |
| 14:27:48 | Zevv | it's a research project that might bring a lot of good |
| 14:28:00 | Zevv | also it might not, sure |
| 14:28:33 | Zevv | but it's not something the core language is depending on. Not something that is part of the standard lib. |
| 14:30:34 | FromDiscord | <dom96> True, as long as the community is not holding off on investing time in Nim because they are anticipating that this will be a big change. |
| 14:31:56 | FromDiscord | <mratsim> It's not a big change for the transition, you reimplement closure iterators in terms of CPS, and done for step 0 |
| 14:31:58 | Zevv | I don't think anybody is holding off anything. As far as I know, it has just been mratsin, disruptek and a bit of me actually spending time on this. |
| 14:32:30 | Zevv | There have been very few people actually hopping on this train. I can't blame them, it's all pretty abstract |
| 14:32:35 | FromDiscord | <mratsim> the big changes would be for low-level developers of schedulers and IO, then functional programming. |
| 14:32:59 | FromDiscord | <mratsim> and maybe at one point it will flourish into CSP and Actors. |
| 14:33:16 | FromDiscord | <mratsim> ah and it will help streams as well |
| 14:33:42 | FromDiscord | <mratsim> but people using high-level features of Nim won't see a change to their day to day usage. |
| 14:34:13 | FromDiscord | <mratsim> We'll see in the survey why oeple don't invest in Nim but I expect it has to do with developer tools. |
| 14:35:01 | FromDiscord | <mratsim> personally I would love to do more tutorials, docs on how to use Nim for data science or cryptography or multithreading.↵But because I don't have what I expect, I'm just not doing it. |
| 14:36:52 | PMunch | Zevv, I'm eagerly awaiting it, but haven't really read up on what it actually is :P |
| 14:39:08 | FromDiscord | <mratsim> Depending of the talk, it's either glorified callbacks or named gotos |
| 14:39:28 | FromDiscord | <0xc45> sent a code paste, see https://play.nim-lang.org/#ix=2LqF |
| 14:40:44 | FromDiscord | <mratsim> In your code it does discard the return value. But does your called function require arguments?? |
| 14:41:03 | FromDiscord | <mratsim> because the cast assumes that there is no need to pass anything |
| 14:41:53 | FromDiscord | <0xc45> Hmm that's odd. The function does not require arguments (in my case it's just shellcode for launching `calc.exe`) |
| 14:42:05 | FromDiscord | <mratsim> can you put your code in a function |
| 14:42:45 | FromDiscord | <mratsim> otherwise all variables are globals |
| 14:42:51 | FromDiscord | <mratsim> not sure but it might help. |
| 14:43:30 | giaco | war reading "norm" module docs, I've found 'some "Saaam"' line. What is 'some'? |
| 14:43:36 | giaco | *was |
| 14:43:52 | PMunch | `some` is from the `options` module |
| 14:44:06 | PMunch | Basically a value that can either be there or not |
| 14:44:07 | giaco | thanks |
| 14:44:12 | PMunch | Hmm, is there a way to see what would take up memory in my ESP8266 program? |
| 14:45:28 | * | Arrrrrrrr joined #nim |
| 14:47:32 | PMunch | I wrote this pretty simple Sodoku solver for fun http://ix.io/2LqI/nim |
| 14:47:39 | FromGitter | <gogolxdong> How to debug when programme failed `Error: execution of an external program failed: 'C:\Users\asus\nimcache\guiNode_d\guiNode.exe '` |
| 14:47:47 | PMunch | And the linker thing says it takes 32K of RAM |
| 14:48:00 | PMunch | Which is a bit problematic since the thing only has 40K of RAM.. |
| 14:48:15 | FromGitter | <gogolxdong> without more information |
| 14:48:47 | PMunch | @gogolxdong, well that meant a program that you code was calling crashed |
| 14:48:51 | PMunch | Or rather didn't return 0 |
| 14:49:07 | PMunch | Is that the only message? Or do you get the command it tried to run as well? |
| 14:49:52 | FromGitter | <gogolxdong> it's a gui application , crashed after running for a while. |
| 14:50:54 | PMunch | Oh wait |
| 14:51:04 | PMunch | So you ran via Nimble? |
| 14:51:23 | Clonkk[m] | <PMunch "Hmm, is there a way to see what "> You can try using ``nm`` on Linux to see symbol and the size they take |
| 14:51:27 | FromGitter | <gogolxdong> nim r guiNode.nim |
| 14:51:42 | PMunch | Ah, try compiling it, and then running it |
| 14:51:53 | PMunch | That error is from the Nim compiler trying to run your binary |
| 14:52:08 | PMunch | Clonkk[m], you can see how big they are as well? |
| 14:54:46 | PMunch | Hmm, the "Blink" example in C++ takes 27k, so I guess it's just a lot of overhead in the libraries |
| 14:56:10 | FromDiscord | <0xc45> Wrapping it in functions didn't help, unfortunately, encountering the same error as @gogolxdong still. The nim program does hang during execution of the shellcode (which is good), but once the shellcode returns the Nim program exits with that error |
| 14:56:46 | FromGitter | <gogolxdong> nim c -r guiNode.nim it's the same, running for a while and crashed. |
| 14:58:04 | Arrrrrrrr | is this a known bug? mutability in iterators https://wandbox.org/permlink/Rt5ZHPRFrmvLECfG#wandbox-resultwindow-code-body-6 |
| 14:58:33 | FromDiscord | <shadow.> !repo cuda |
| 14:58:33 | disbot | https://github.com/mratsim/Arraymancer -- 9Arraymancer: 11A fast, ergonomic and portable tensor library in Nim with a deep learning focus for CPU, GPU and embedded devices via OpenMP, Cuda and OpenCL backends 15 767⭐ 68🍴 7& 4 more... |
| 14:58:43 | FromDiscord | <shadow.> f |
| 14:58:46 | FromDiscord | <mratsim> !repo nimcuda |
| 14:58:46 | disbot | https://github.com/unicredit/nimcuda -- 9nimcuda: 11Nim bindings for CUDA 15 17⭐ 7🍴 |
| 14:58:54 | FromGitter | <gogolxdong> without any more information, there is no shellcode execution in my code |
| 14:58:57 | FromDiscord | <mratsim> though it uses Cuda 8 iirc |
| 14:59:20 | FromDiscord | <mratsim> @dom96 reproduced a minimal example that makes the Nim compiler bail out without any error: https://github.com/nim-lang/Nim/issues/16655 |
| 14:59:26 | disbot | ➥ importcpp + CRTP: Compiler exit without output or errors ; snippet at 12https://play.nim-lang.org/#ix=2LqO |
| 15:00:41 | FromDiscord | <mratsim> @0xc45 maybe `cast[proc(): cint {.nimcall.}](fn) |
| 15:00:46 | FromDiscord | <mratsim> (edit) "{.nimcall.}](fn)" => "{.nimcall.}](fn)`" |
| 15:01:05 | FromDiscord | <mratsim> it's possible that the return value of your function is overwriting a register |
| 15:01:16 | FromDiscord | <mratsim> so we need to tell Nim that there is a register used for return value |
| 15:01:53 | FromDiscord | <mratsim> and `cast[proc(): cint {.nimcall, discardable.}](fn)` if you want to be able to not check that return value |
| 15:02:11 | FromDiscord | <mratsim> not sure if that applies to your case as well @gogolxdong |
| 15:07:22 | FromDiscord | <0xc45> sent a code paste, see https://play.nim-lang.org/#ix=2Lr1 |
| 15:10:03 | * | opal quit (Ping timeout: 240 seconds) |
| 15:12:05 | FromDiscord | <mratsim> yeah it shouldn't matter |
| 15:12:15 | giaco | is it possible to import/use a C preprocessor macro (#define)? I'm trying to use Gstreamer with nim, but to get raw data I need to comply with this line "We can retrieve the data pointer using the GST_BUFFER_DATA macro and the data size using the GST_BUFFER_SIZE macro in GstBuffer" |
| 15:12:38 | * | opal joined #nim |
| 15:12:45 | FromDiscord | <mratsim> I would run under gdb @0xc45, possible with --debugger:native if you want nim symbols but maybe C symbols are better |
| 15:12:53 | FromDiscord | <mratsim> @giaco, sure |
| 15:13:33 | Zevv | PMunch: you'll be *so* disappointed |
| 15:14:28 | giaco | mratsim, would you share a manual page/keyword to follow? |
| 15:14:31 | FromDiscord | <mratsim> @giaco, here is an example #define macro wrapped in Nim: https://github.com/mratsim/weave/blob/2a1cf88aeef6c37bc772c0fe3cc6f957d6480e37/e04_channel_based_work_stealing/primitives/coz.nim#L21 |
| 15:14:38 | giaco | oh, thanks :D |
| 15:14:52 | FromDiscord | <mratsim> and the definition: https://github.com/mratsim/weave/blob/2a1cf88aeef6c37bc772c0fe3cc6f957d6480e37/e04_channel_based_work_stealing/primitives/coz.h#L79 |
| 15:16:03 | FromDiscord | <0xc45> Thanks, I will try that when I have access to my desktop again. In the meantime, is there some way to tell nim to "ignore any errors in this section of code" or a similar workaround? I know that's horrible practice, but for my program it doesn't really matter at the moment |
| 15:16:22 | FromDiscord | <mratsim> try/finally |
| 15:16:53 | FromDiscord | <mratsim> though here you might have to "import signals" and do something, i'm not sure what kind of errors it is |
| 15:17:13 | FromDiscord | <mratsim> import signals allows you to catch Ctrl+C and SIGSEGV |
| 15:20:31 | FromDiscord | <mratsim> @giaco, it's now part of Nim wiki: https://github.com/nim-lang/Nim/wiki/Lesser-known-Nim-features#wrapping-c-define-macro |
| 15:20:53 | * | fputs joined #nim |
| 15:20:56 | giaco | mratsim thanks a lot |
| 15:22:40 | giaco | It gives me a kind of courage to meet the end of a page named "lesser-known-nim-features", but in reality I still can't write 3 lines without a syntax error :D |
| 15:27:30 | FromDiscord | <shadow.> if i only use macros from a module will it warn `imported and not used` |
| 15:27:34 | FromDiscord | <shadow.> because i'm certainly using macros |
| 15:27:36 | FromDiscord | <shadow.> from the module |
| 15:27:47 | FromDiscord | <Rika> i believe so |
| 15:28:01 | FromDiscord | <shadow.> ahh ok |
| 15:29:28 | FromDiscord | <0xc45> Thanks, no love with those methods as well. Currently thinking that it is because the shellcode calls an exit function that probably kills the current thread. I'll play with different payloads and debuggers at a later point |
| 15:29:49 | FromDiscord | <mratsim> good luck! |
| 15:29:52 | FromDiscord | <0xc45> Thanks a lot for now! +1 on what Giaco said, Nim can be a bit intimidating at times for a newbie but it's great that there are helpful people around 🙂 |
| 15:31:07 | FromDiscord | <mratsim> you're welcome. In general when you need both scripting and low-level, I don't think any language comes close to Nim |
| 15:31:15 | FromDiscord | <mratsim> though I might have rose-colored glasses |
| 15:31:16 | giaco | I really like how it goes from safe and simple to shoot yourself gradually |
| 15:31:40 | FromDiscord | <whisperdev> Can you "slurp" a dll into the Nim binary and use it like that? |
| 15:32:12 | FromDiscord | <mratsim> can't you just link to it or use a .a/.lib static lib? |
| 15:32:29 | FromDiscord | <whisperdev> I dont know |
| 15:32:54 | FromDiscord | <mratsim> {.link: "mylibrary.o".} or {.link: "mylibrary.lib".} or {.link: "mylibrary.a".} |
| 15:32:56 | FromDiscord | <mratsim> done |
| 15:33:12 | FromDiscord | <whisperdev> But this is nix |
| 15:33:19 | FromDiscord | <mratsim> .lib is windows |
| 15:33:37 | FromDiscord | <mratsim> .lib is static library and .dll is dynamic |
| 15:33:44 | PMunch | Zevv, haha let's hope not :P |
| 15:34:03 | FromDiscord | <whisperdev> That's cool I did not know you could do this |
| 15:34:15 | FromDiscord | <mratsim> otherwise maybe {.dynlib: yourlib.dll.} and the dynlibOverride pragma works but I'm not sure |
| 15:34:25 | FromGitter | <gogolxdong> yeah,very help |
| 15:34:31 | FromGitter | <gogolxdong> ful |
| 15:34:53 | FromDiscord | <whisperdev> I just need to figure out how to build fswatch on Windows |
| 15:34:53 | FromGitter | <gogolxdong> made in love |
| 15:34:55 | FromDiscord | <mratsim> https://nim-lang.org/docs/nimc.html#dynliboverride |
| 15:35:13 | FromDiscord | <mratsim> I think there is a repo for helping static builds. |
| 15:35:24 | FromGitter | <gogolxdong> mobile sorry |
| 15:47:03 | * | opal quit (Ping timeout: 240 seconds) |
| 15:53:27 | Zevv | disruptek: ye awake? |
| 15:56:40 | disruptek | yeah. |
| 15:58:21 | disruptek | Zevv: what is up my main man |
| 15:58:33 | * | Gustavo6046 joined #nim |
| 15:58:49 | Zevv | I'm trying to get acquinted with type macro stuff |
| 15:59:00 | Zevv | Nim is taking my types too literally: |
| 15:59:01 | Zevv | nnkLetSection fds: distinct[int32] = sockBind(env_369101674(continuation).port_369101691) |
| 15:59:21 | Zevv | So SocketHandle is a distinct[int32] somewhere |
| 15:59:38 | disruptek | hmm, that shouldn't be hard to fix. |
| 15:59:39 | Zevv | but instead of throwing SocketHandle at me, it gets dissected all the way to distinct[int32] |
| 16:00:12 | disruptek | there's a place where we add inferred types and we're probably unpacking them with the wrong getType call. |
| 16:00:56 | disruptek | there's actually a much bigger problem on the horizon that is demonstrated by testes-1.1.0. |
| 16:01:04 | Zevv | don't tell me |
| 16:01:09 | disruptek | okay. |
| 16:01:13 | FromDiscord | <mratsim> types in macro. You are better men than me. I wish you luck. |
| 16:01:49 | disruptek | the types aren't the hard part; it's the /hidden/ types that are troublesome. |
| 16:01:59 | Zevv | ok, tell me |
| 16:02:15 | disruptek | testes produces a macro now, `check`. |
| 16:03:03 | disruptek | `check x == 3` does the check you expect, but it also emits a comment like `let x: int = 5` when the check fails to show you what value provoked the failure. |
| 16:03:23 | * | opal joined #nim |
| 16:03:28 | Zevv | ok |
| 16:03:43 | disruptek | do produce this output at runtime and with respect for zevv's famously bland --define:testesDry, we bindSym a useColor(): bool predicate. |
| 16:03:49 | disruptek | s/^do/^to/ |
| 16:04:09 | disruptek | cps erases the useColor() bindsym and turns it into an ident. |
| 16:04:21 | disruptek | now, because it's not exported by my testes, it fails compilation. |
| 16:04:28 | Zevv | ok |
| 16:04:36 | disruptek | which reveals a real problem: we cannot blindly desem symbols. |
| 16:04:59 | FromDiscord | <mratsim> but CPS will allow macro to compose 😉 |
| 16:05:31 | disruptek | i dunno what that means. |
| 16:05:38 | Zevv | I was hoping you would say that before me |
| 16:05:50 | disruptek | nailed it. |
| 16:05:59 | disruptek | lemme get some coffee; bbiab. |
| 16:13:39 | * | Arrrrrrrr quit (Quit: Arrrrrrrr) |
| 16:19:30 | * | hmmm quit (Quit: WeeChat 3.0) |
| 16:20:45 | FromDiscord | <haxscramper> What is the best solution to map C++ concepts to nim? Things like `std::forward_iterator_tag` and others |
| 16:20:53 | FromDiscord | <haxscramper> Without going literally insane |
| 16:21:28 | FromDiscord | <haxscramper> Particularly I'm talking about C++ stdlib |
| 16:22:37 | FromDiscord | <haxscramper> Because the only thing that comes to mind is nim concepts, but this will probably just destroy me on spot |
| 16:22:39 | FromDiscord | <mratsim> Weren't they released like 1 month ago? |
| 16:22:52 | FromDiscord | <haxscramper> I'm not talking about C++20 concepts |
| 16:22:59 | FromDiscord | <haxscramper> More like the thing that preceded them |
| 16:23:06 | FromDiscord | <mratsim> !repo nimline |
| 16:23:07 | disbot | https://github.com/sinkingsugar/nimline -- 9nimline: 11Wrapper-less C/C++ interop for Nim 15 74⭐ 3🍴 7& 2 more... |
| 16:23:13 | FromDiscord | <haxscramper> https://en.cppreference.com/w/cpp/iterator/iterator_tags |
| 16:23:17 | FromDiscord | <mratsim> there are iterators wrappers inside |
| 16:24:03 | FromDiscord | <mratsim> Nim's Bar = object of Foo will generate struct Bar: public Foo |
| 16:24:07 | * | narimiran joined #nim |
| 16:24:12 | FromDiscord | <mratsim> so inheritance? |
| 16:25:32 | ForumUpdaterBot | New thread by Alexeypetrushin: Why Nim fails to convert from `float64` to `float`?, see https://forum.nim-lang.org/t/7361 |
| 16:26:06 | FromDiscord | <haxscramper> Well, it's not like there is a better solution |
| 16:26:08 | FromDiscord | <haxscramper> sent a code paste, see https://play.nim-lang.org/#ix=2LrC |
| 16:29:08 | FromDiscord | <haxscramper> IIRC new concept implementation is done and someone needs to review it, right? I think 4arq said something like that a while ago |
| 16:30:53 | FromDiscord | <Digitalcraftsman> sent a code paste, see https://play.nim-lang.org/#ix=2LrE |
| 16:31:11 | FromDiscord | <lqdev> import std/with |
| 16:31:42 | FromDiscord | <lqdev> https://nim-lang.org/docs/with.html |
| 16:32:14 | FromDiscord | <Digitalcraftsman> thank you. I've searched the docs, manual etc. because I knew that it exists. But I wasn't sure where to look specifically. |
| 16:32:41 | disruptek | scramper: new concepts can be tested, but they demand new syntax. |
| 16:32:50 | FromDiscord | <lqdev> yeah lib.rst should get an update someday |
| 16:33:31 | disruptek | i think std/with is underrealized. it should add the first arg to the first call of every subsequent statement. |
| 16:33:32 | FromDiscord | <lqdev> disruptek: wdym new syntax? do you want something different from araq's rfc? |
| 16:33:34 | FromDiscord | <haxscramper> disruptek: if I understand this new syntax vs non-working implementation |
| 16:33:47 | FromDiscord | <haxscramper> So this is fine by me |
| 16:34:08 | disruptek | the impl works, but only with the new syntax. also, the impl may not be complete (ie. it doesn't handle obj fields). |
| 16:34:34 | FromDiscord | <lqdev> yeah object fields would be pretty cool to have |
| 16:35:53 | saem | disruptek: I think we should mostly copy kotlin's with, let, apply, and returning set of functions, just change the names. And yeah, with being used for successive calls makes a lot of sense. |
| 16:36:33 | disruptek | it sorta works that way now, but i think it's just an oversight. |
| 16:36:41 | FromDiscord | <mratsim> too busy to review it :/ |
| 16:37:01 | FromDiscord | <mratsim> the current concepts work for me mostly |
| 16:37:07 | FromDiscord | <mratsim> but where is that new implementation? |
| 16:37:17 | disruptek | araq-concepts branch iirc. |
| 16:37:24 | FromDiscord | <haxscramper> https://github.com/nim-lang/Nim/pull/15251 |
| 16:37:25 | disbot | ➥ new-style concepts implementation, WIP |
| 16:37:27 | disruptek | i can't believe the current concepts work for you. |
| 16:37:44 | FromDiscord | <mratsim> I can't believe I made them work 😉 |
| 16:37:45 | disruptek | they are so broken that i think it's practically a miracle that they work in my code. |
| 16:38:16 | FromDiscord | <mratsim> I manage to create co-recursive concepts to represent algebraic relations. |
| 16:38:24 | disruptek | they work for toy use and if you try to build upon them, pffbt, you're fucked. |
| 16:39:22 | * | vicfred quit (Ping timeout: 246 seconds) |
| 16:39:23 | FromDiscord | <mratsim> I don't think this is toy: https://github.com/mratsim/constantine/blob/master/constantine/tower_field_extensions/tower_common.nim#L26-L39↵↵It solves a big pain point in the corresponding Rust and C++ implementations |
| 16:39:46 | FromDiscord | <mratsim> but that produces hundreds of thousands of lines of duplicated code |
| 16:40:18 | saem | There are many rough spots, it feels like. The docs are the first part. I think updating the docs to what concepts should be, then matching the implementation is the way to go. I hope the new syntax works backwards like that. |
| 16:40:22 | FromDiscord | <lqdev> https://github.com/liquidev/rapid/blob/master/src/rapid/game/tilemap.nim#L357 this tiny motherfucker of a concept caused me more headaches than i would've liked |
| 16:40:31 | disruptek | i can accept that it works, and i have concepts in my code that work, but the algebra is flawed such that it does not work as consistently as other algebras i've used. 😁 |
| 16:41:01 | FromDiscord | <mratsim> https://github.com/mratsim/Arraymancer/blob/master/src/arraymancer/nn_dsl/dsl_types.nim#L63-L68 |
| 16:41:13 | FromDiscord | <mratsim> I was surprised this one worked ^ |
| 16:41:23 | FromDiscord | <mratsim> but debugging when it doesn't is a pain |
| 16:41:34 | disruptek | https://github.com/disruptek/nimph/blob/denimble/nimph/groups.nim#L188 |
| 16:43:42 | disruptek | i expect my use to work, i don't expect your expr syntax to work. |
| 16:43:48 | FromDiscord | <mratsim> this one works and would make it easy to switch to continuations: https://github.com/mratsim/weave/blob/master/weave/datatypes/prell_deques.nim#L11-L20 |
| 16:44:00 | FromDiscord | <mratsim> the expr syntax actually works 😄 |
| 16:44:17 | disruptek | yes, but i don't expect it to work /in the new impl/. |
| 16:44:23 | FromDiscord | <mratsim> ah |
| 16:44:23 | disruptek | just a heads-up. |
| 16:44:35 | FromDiscord | <mratsim> well I mentioned in the RFC that I want this to work |
| 16:44:46 | FromDiscord | <mratsim> or have an alternative |
| 16:45:01 | disruptek | well, i could be wrong, but the idea is to get away from the compiles()-based impl. |
| 16:45:27 | FromDiscord | <mratsim> I'm fine with VTable based inheritance to replace that. |
| 16:46:05 | FromDiscord | <lqdev> speaking of vtables, vtable-based methods when |
| 16:46:06 | FromDiscord | <mratsim> but given that methods are broken with generics, I have no alternative |
| 16:46:14 | FromDiscord | <mratsim> I have to use concepts |
| 16:46:29 | disruptek | i don't know why vtables aren't impl'd, honestly. |
| 16:46:40 | disruptek | probably just was never a paid priority. |
| 16:47:13 | FromDiscord | <mratsim> It's bacause concepts were released but debugging them took too much time |
| 16:47:21 | FromDiscord | <mratsim> so a stop was put until they were more stable |
| 16:47:51 | FromDiscord | <mratsim> and same thing for status |
| 16:47:55 | FromDiscord | <mratsim> sorry static |
| 16:47:58 | * | habamax quit (Ping timeout: 260 seconds) |
| 16:48:14 | FromDiscord | <mratsim> i.e. consolidate the existing features before burdening even more the type system |
| 16:48:27 | disruptek | yes, they are both pretty broken. |
| 16:48:47 | disruptek | i actually had to remove a concept from jason, of all places, to fix it against devel recently. |
| 16:48:58 | disruptek | about as simple an impl as you could think of. |
| 16:48:59 | FromDiscord | <mratsim> We needed static at Status so we spend a lot of time to fix them in 2018. |
| 16:49:11 | * | filcuc joined #nim |
| 16:49:14 | disruptek | for your use-case alone, i guess. |
| 16:49:29 | FromDiscord | <mratsim> No |
| 16:49:39 | FromDiscord | <mratsim> static enum works for everyone |
| 16:49:44 | FromDiscord | <mratsim> static int also |
| 16:49:52 | FromDiscord | <mratsim> static in macros as well |
| 16:50:16 | disruptek | i've found it an absolute crap shoot, but maybe i'm using them wrong. |
| 16:51:05 | FromDiscord | <mratsim> all the stuff here: https://github.com/nim-lang/Nim/issues?q=is%3Aissue+author%3Amratsim+label%3AStatic%5BT%5D+is%3Aclosed from 2018 were stuff we met at Status but are general problems |
| 16:51:08 | disruptek | let's just say i don't consider static a tool i should leave on a lower shelf. i keep it in the back room, under lock and key, in a safe, rigged with dynamite. |
| 16:51:25 | FromDiscord | <mratsim> I assume that's why they don't work in Rust as well |
| 16:51:40 | FromDiscord | <mratsim> you need to design your type system with value as types from the ground up |
| 16:51:46 | saem | I've read your jason concept usage, your barely using them. Well they're used in a lot of places, but the amount that's actually declared is teeny tiny |
| 16:51:56 | disruptek | exactly. |
| 16:52:06 | disruptek | and i had to remove one use. |
| 16:52:28 | saem | I mean, it's a tutorial basically. I learned more about concepts from that then the docs at first. |
| 16:52:40 | disruptek | when i use something like this, i like to think that my use is as simple as can be. |
| 16:53:12 | disruptek | the problem is that concepts are simple to use but hard to master, simply because they cannot compose. |
| 16:53:26 | disruptek | this is a lesson for a lot of language design problems we argue about. |
| 16:54:10 | saem | I believe that, it's when two things try to work together often is where the fun begins. |
| 16:55:03 | disruptek | jason and frosty will probably just become demos of new concepts and cps. |
| 16:55:08 | saem | It's why I think CPS is a big deal, but feel there are some lessons that likely need to be pulled out of it and into the base language to ensure its well enable (purely a hunch) |
| 16:56:15 | disruptek | it's teaching me a lot, definitely. |
| 16:56:45 | disruptek | i hope i'm putting enough of that into my comments but i guess it's easy to overlook stuff. |
| 16:57:04 | disruptek | testes has been instructional, too. they both have this thread-the-needle aspect. |
| 16:59:37 | ForumUpdaterBot | New thread by Alexeypetrushin: Why proc behavior depends if it defined after or before another proc?, see https://forum.nim-lang.org/t/7362 |
| 17:00:04 | saem | By thread-the-needle, you mean the fine line of what can simply be written in the language, versus some deep down fundamental capability that should be part of the language. Learned through these sort of implementations? |
| 17:00:26 | disruptek | nothing that clever. |
| 17:00:58 | * | Zevv quit (Quit: leaving) |
| 17:01:47 | disruptek | more like, the difference between what we believe is possible based on how we understand nim to straddle compile-time/run-time, and what is actually practically achievable with today's impl. |
| 17:02:45 | saem | As in both aspirational and practical simultaneously. |
| 17:02:54 | disruptek | right. |
| 17:03:10 | * | Zevv joined #nim |
| 17:04:00 | disruptek | we're usually right about one of the goal posts -- what we believe is possible -- but often wrong about how to get there using today's code. |
| 17:05:44 | FromDiscord | <mratsim> and how many moles you need to whack that the Nim compilers throw at you |
| 17:06:26 | saem | In regards to concepts, I think I would prefer a lesser version of concepts based on row polymorphism than full blown concepts right now. More structural. For concepts themselves I should look at the new syntax, but I have a hunch it should feel more like generic generics. |
| 17:07:34 | * | haxscramper joined #nim |
| 17:07:37 | saem | Views might give me what I want, but last I read it didn't seem like it. |
| 17:07:45 | giaco | I'm trying to understand this error I'm getting while using gintro library: "nim-1.4.2/lib/core/macros.nim(558, 3) Error: undeclared identifier: 'scnew_sample'". I don't have that identifier in my code, nor is present in gintro library. What does it mean? |
| 17:08:05 | disruptek | probably concatenation of two identifiers. |
| 17:09:22 | FromDiscord | <mratsim> ping ssalewski ^ |
| 17:10:22 | saem | Mratsim: I feel the whack-a-more, currently I'm trying to slowly build up a series of tests that capture behavior as a spec and fixing things along the way for nimsuggest. |
| 17:11:16 | disruptek | nice. |
| 17:11:21 | saem | Well, not currently. Currently I'm lying in bed not wanting to get up |
| 17:14:24 | saem | Understandably, it's steering my towards fixing sempass bugs. The next `con` one and I believe a `sug` one afterwards is like that. I'm just curious what happens as this stays bumping into IC. |
| 17:14:49 | saem | s/stays/starts |
| 17:15:24 | giaco | mratsim yeah I think gintro in editing the original names of the signals |
| 17:16:53 | disruptek | i wouldn't worry about ic yet; this feels like more of an effort to quantify the code before refactoring before switch to ic. to do it easily, you probably have a couple more passes to go. |
| 17:17:06 | * | bacterio quit (Ping timeout: 265 seconds) |
| 17:17:53 | * | bacterio joined #nim |
| 17:19:25 | saem | I know, it's just looking ahead and my brain is a jerk and likes to race ahead regardless of what I tell it to do. |
| 17:20:37 | * | lritter joined #nim |
| 17:22:44 | disruptek | funny, we were just talking about what a jerk your brain is. |
| 17:23:27 | saem | I mean it deserves it |
| 17:23:54 | disruptek | totally. |
| 17:24:00 | saem | It also doesn't let me read any of those messages so it remains immune to criticism |
| 17:24:02 | * | tane joined #nim |
| 17:24:05 | saem | Total jerk |
| 17:24:08 | disruptek | lol |
| 17:24:56 | * | PMunch quit (Ping timeout: 240 seconds) |
| 17:26:35 | saem | The nagging feeling I have is that shoving more of the versioning/caching concepts from nimsuggest into sem and those parts of the compiler would do much of the incremental part of IC, but not the heavy IO and mechanically sympathetic optimizations. So it'd be rod/sqlite agnostic and that could be fun competing priorities. |
| 17:32:15 | saem | Oh well, for now the bugs. |
| 17:32:30 | saem | Well at least the getting up maybe |
| 17:35:23 | FromDiscord | <Anuke> Is there a simple way to export everything in a file w/o `include`, or do I have to write my own macro? |
| 17:38:33 | * | PMunch joined #nim |
| 17:41:49 | FromDiscord | <lqdev> `import module; export module` |
| 17:42:15 | FromDiscord | <Rika> i think they mean make all procs in a module exported |
| 17:42:19 | FromDiscord | <Rika> without putting markers |
| 17:42:25 | FromDiscord | <Anuke> yes, I mean all types/procs/type fields |
| 17:43:03 | FromDiscord | <Anuke> or, to phrase it another way, I have a public module and I don't want to put a star after everything |
| 17:43:13 | FromDiscord | <lqdev> well there isn't a way to do that |
| 17:43:35 | FromDiscord | <lqdev> c'mon, an asterisk is better than `public` or `export` everywhere |
| 17:43:40 | FromDiscord | <lqdev> it's a small price to pay |
| 17:44:44 | FromDiscord | <Rika> i think the issue is putting that star on every proc/field/type |
| 17:44:45 | FromDiscord | <Anuke> absolutely, but it could be even better |
| 17:44:52 | FromDiscord | <Rika> rather than how long the marker is |
| 17:47:01 | disruptek | mratsim: can you PR a patch to cps master to add type erasure only? without deleting everything and going full mutant? |
| 17:47:23 | disruptek | !repo disruptek/grok |
| 17:47:24 | disbot | https://github.com/disruptek/grok -- 9grok: 11spelunking gear 15 0⭐ 0🍴 |
| 17:47:39 | disruptek | see the superstar file within. |
| 17:51:40 | FromDiscord | <treeform> disruptek, with CPS do you stitch back stack traces of cut up functions so that they are understandable? |
| 17:51:44 | ForumUpdaterBot | New thread by Alexeypetrushin: How to write a template to call function with arbitrary number of arguments?, see https://forum.nim-lang.org/t/7363 |
| 17:52:22 | disruptek | the current impl just traces cps trampoline bounces and nothing else. |
| 17:52:44 | disruptek | is the output understandable? yes. |
| 17:53:17 | disruptek | have i tested cpsTrace recently? no. 😉 |
| 17:53:44 | disruptek | i think we're going to fix shadow F and then cut a minor today. |
| 17:54:11 | disruptek | will try to make cpsTrace works in 0.1.0 or just cut it into 0.2.0 if it's too challenging. |
| 17:55:25 | disruptek | how cps handles exceptions is an area of open research, but when type erasure goes in we'll have some new options for exceptions and return values. |
| 17:56:15 | disruptek | the current impl of these features is a little meh. |
| 17:57:46 | * | haxscramper quit (Remote host closed the connection) |
| 18:06:44 | * | hmmm joined #nim |
| 18:11:33 | giaco | I'm trying to find out what "SCA" is in this source code: https://github.com/StefanSalewski/gintro/blob/master/gintro/gimplgobj.nim |
| 18:11:45 | giaco | it seems not declared anywhere |
| 18:15:52 | * | krux02 quit (Remote host closed the connection) |
| 18:16:01 | giaco | is it an internal symbol or something? |
| 18:17:32 | * | krux02 joined #nim |
| 18:18:52 | FromDiscord | <Nisha|💻⭐> Heya everyone |
| 18:19:14 | FromDiscord | <Nisha|💻⭐> Is there a library for ØMQ in Nim? |
| 18:19:25 | disruptek | !repo zmq |
| 18:19:26 | disbot | https://github.com/nim-lang/nim-zmq -- 9nim-zmq: 11Nimrod ZMQ wrapper 15 28⭐ 10🍴 7& 1 more... |
| 18:19:28 | FromDiscord | <mratsim> there is no type erasure in my branch, I decided that it was more important to nail the high-level ergonomic that fiddle with the low-level implementation. |
| 18:19:33 | FromDiscord | <Nisha|💻⭐> Thanks! |
| 18:19:43 | FromDiscord | <mratsim> than fiddle |
| 18:20:01 | FromDiscord | <mratsim> I can always do the type erasure later once we know that the high level work |
| 18:20:19 | disruptek | that's a shame, because that's the part that we agree on. |
| 18:20:34 | FromDiscord | <mratsim> well that's why it's more important to focus on the rest no? |
| 18:21:02 | disruptek | i am. |
| 18:21:08 | FromDiscord | <mratsim> we also agree that CPS is the future |
| 18:22:02 | disruptek | i think i have shadow F solved, i just have some silly defect. |
| 18:22:17 | disruptek | or, at least, i have a temporary hack to work around it. |
| 18:44:50 | Zevv | explain unhide to m,e |
| 18:45:34 | disruptek | if you turn it off, the code doesn't work. 😁 |
| 18:45:47 | disruptek | # FIXME: a nutty hack to rewrite varargs conversions |
| 18:46:05 | Zevv | yeah I can read |
| 18:46:10 | Zevv | but not understand |
| 18:46:15 | disruptek | well, the copies remove the hidden types. |
| 18:46:17 | Zevv | the why |
| 18:46:28 | Zevv | why is them hidden types hidden |
| 18:46:53 | FromDiscord | <mratsim> varargs are tricky because the AST stores them in nnkArg instead of nnkBracket |
| 18:46:58 | disruptek | the problem is that typed notes are typed. |
| 18:47:04 | Zevv | hm I see |
| 18:47:06 | FromDiscord | <mratsim> and varargs typed, explicitly need nnkArg |
| 18:47:16 | FromDiscord | <mratsim> lost half a day on that |
| 18:47:18 | Zevv | who made up this stuff |
| 18:47:34 | disruptek | some chucklehead, no doubt. |
| 18:47:39 | FromDiscord | <mratsim> https://github.com/numforge/loop-fusion/blob/master/loopfusion.nim#L283 |
| 18:47:57 | FromDiscord | <mratsim> I had a nnkBracket here |
| 18:48:12 | FromDiscord | <mratsim> try to reduce the example, change typed to untyped and vice-versa |
| 18:48:18 | FromDiscord | <mratsim> until the light hit me |
| 18:48:44 | disruptek | maybe we can simplify it with this. |
| 18:48:59 | disruptek | but anyway, copying nodes strips the .typ so it can be resem'd. |
| 18:49:04 | FromDiscord | <mratsim> this is the arg of the typed macro here: https://github.com/numforge/loop-fusion/blob/master/loopfusion.nim#L203 |
| 18:49:21 | FromDiscord | <mratsim> there is copyNimTree that doesn't strip |
| 18:49:31 | FromDiscord | <mratsim> copyChildrenTo as well |
| 18:49:38 | FromDiscord | <mratsim> not sure what copyNim does |
| 18:49:42 | FromDiscord | <mratsim> or copy? |
| 18:50:57 | disruptek | copy is the same thing but doesn't copy trees. |
| 18:56:31 | disruptek | /home/adavidoff/git/Nim/compiler/vm.nim(2316) evalMacroCall |
| 18:56:31 | disruptek | /home/adavidoff/git/Nim/compiler/vm.nim(1331) rawExecute |
| 18:56:31 | disruptek | /home/adavidoff/git/Nim/lib/system/fatal.nim(53) sysFatal |
| 18:56:32 | disruptek | Error: unhandled exception: index out of bounds, the container is empty [IndexDefect] |
| 18:56:37 | disruptek | super unhelpful. |
| 18:58:48 | disruptek | it's actually a defect in the compiler; it's assuming that an unrelated exception is an index defect. 🤦 |
| 18:59:05 | grfork | could you advise me on how to make a test which only checks that all files from "examples/" directory are successfully compiled? I want to use testament. What is the general pattern to test for successful compilation in this case? |
| 19:00:02 | * | grfork is now known as greenfork |
| 19:01:38 | greenfork | I think it could be 1 test for per each example which includes it, I hope it is a correct pattern in this case |
| 19:02:07 | Zevv | disruptek: tzevv.nim has been updated with a minimal example |
| 19:02:18 | disruptek | example of what? |
| 19:03:10 | * | bacterio quit (Ping timeout: 256 seconds) |
| 19:03:21 | FromDiscord | <Anuke> How does one get the file a macro is called in, without using NimNodes? `instantiationInfo()` doesn't appear to be valid |
| 19:04:15 | disruptek | shadow F fix is pushed. |
| 19:04:22 | * | bacterio joined #nim |
| 19:04:33 | Zevv | already? |
| 19:04:39 | FromDiscord | <mratsim> @Anuke you use template indirection |
| 19:04:45 | FromDiscord | <mratsim> I think |
| 19:04:48 | disruptek | well, it's a work-around of sorts. |
| 19:05:00 | disruptek | not sure it will survive. |
| 19:05:07 | FromDiscord | <mratsim> there are already a couple of issues and RFC to make instantiationInfo more useful |
| 19:05:15 | disruptek | what is this new red on my screen in tzevv? |
| 19:05:20 | Zevv | the type error |
| 19:05:23 | FromDiscord | <mratsim> I find the lack of FILE really annoying as well |
| 19:05:37 | Zevv | wait what |
| 19:06:04 | Zevv | your fix fixed my bu |
| 19:06:05 | Zevv | g |
| 19:06:17 | disruptek | that's the idea. |
| 19:06:29 | Zevv | yeah but that was _my_ bug |
| 19:06:48 | disruptek | it was? |
| 19:08:05 | FromDiscord | <Anuke> By this, do you mean create a template that defines and invokes a macro? |
| 19:08:24 | FromDiscord | <mratsim> and passes the filename as a static string |
| 19:08:36 | FromDiscord | <Anuke> I see, thanks |
| 19:08:41 | FromDiscord | <exelotl> `with` really should be in sugar alongside dup... |
| 19:10:33 | FromDiscord | <mratsim> yeah std/enumerate should be in iterators with pairs and items |
| 19:10:47 | disruptek | Zevv: what does this new bug mean? we need to rewrite conversions? |
| 19:11:21 | Zevv | I'm am again confused. I had this bug, I just rebased to master and it was fixed. But I'm on a different machine so I was probably not running what I was thinking |
| 19:11:30 | Zevv | something else: Why does compiling tzevv take +30 seconds for me at this time? |
| 19:12:28 | Zevv | with -d:release, that is. And it's the C compiler or linker taking its time |
| 19:13:01 | disruptek | it's 35k lines of c. |
| 19:13:14 | Zevv | yeah I just noticed. |
| 19:13:47 | disruptek | it's usually the frontend that's slow for cps. |
| 19:13:52 | Zevv | from 231 lines of Nim. It's worse then npeg :) |
| 19:13:54 | disruptek | tzevv takes me 17.5s. |
| 19:14:06 | Zevv | good for you |
| 19:14:13 | disruptek | lol |
| 19:14:13 | Zevv | also unacceptable |
| 19:14:39 | disruptek | could also be my testes. |
| 19:15:53 | disruptek | so should we call this 0.1.0? |
| 19:16:12 | disruptek | we don't even have a cpsTrace test do we. |
| 19:16:40 | Zevv | 0.1.0? 1.0.0! |
| 19:17:40 | disruptek | eh it doesn't comingle with my freshest testes. |
| 19:19:04 | FromDiscord | <Avatarfighter> The testes are unsatisfied |
| 19:23:39 | disruptek | hmm, the shim almost works. |
| 19:23:55 | disruptek | it's kinda elegant actually. |
| 19:24:02 | disruptek | 539 proc int(continuation: env_402658462): int {.cpsLift.} = |
| 19:24:03 | disruptek | 540 env_402658462(continuation).result_402658461 |
| 19:24:23 | disruptek | who came up with this? |
| 19:24:26 | disruptek | it's genius. |
| 19:24:43 | FromDiscord | <Avatarfighter> lmao |
| 19:25:00 | FromDiscord | <Avatarfighter> Which intellectual of the high capacity came up with this computer science marvel |
| 19:25:07 | FromDiscord | <Avatarfighter> (edit) "high" => "highest" |
| 19:25:24 | disruptek | right? i would blow this guy if i could. |
| 19:25:31 | FromDiscord | <Avatarfighter> yeah |
| 19:25:36 | FromDiscord | <Avatarfighter> how are the ladies not lined up right now |
| 19:25:42 | disruptek | for reals. |
| 19:31:19 | FromGitter | <StefanSalewski> 17:07:45 giaco I can not guess what this undeclared identifier: 'scnew_sample'" is. Please open issue on gintro issue tracker. |
| 19:33:01 | giaco | Hi StefanSalewski! Thanks for your lib. I'm using it for gstreamer that surely isn't main topic, but it seems to work except for the missing parts. Opening issue right now |
| 19:36:14 | FromGitter | <StefanSalewski> giaco try grep SCA ~/.nimble/pkgs/gintro-0.8.5/gintro/* |
| 19:36:26 | FromGitter | <StefanSalewski> So you learn that SCA is a constant in gisup3.nim |
| 19:36:37 | giaco | yeah, I've found it later on |
| 19:36:53 | giaco | I guess I should add a line to that file to fix missing new-sample signal |
| 19:37:27 | FromGitter | <StefanSalewski> But of course you can not debug it yourself, it is to hard. Try to provide an example with that isue at github issue tracker. |
| 19:38:09 | FromGitter | <StefanSalewski> And tell us if you use mac, windows or linux, and if it is gtk4 or gtk3. |
| 19:39:12 | FromGitter | <StefanSalewski> And GTK version. We had a similar issue years ago when new symbols where introduced for a new windows GTK version. |
| 19:39:47 | FromGitter | <StefanSalewski> Unfortunately I have only Linux, but I can always ask Mr Bassi or Mr Droege. Bye. |
| 19:40:52 | giaco | StefanSalewski, gtk version? Do you mean gstreamer version? I'm using gtkdummy following your note in readme. I'm interested in linux too |
| 19:42:33 | FromGitter | <StefanSalewski> gtkdummy was created only for Mr Demo Hero who wants to use libnice with windows 8.1 without a real gtk install. |
| 19:43:14 | FromGitter | <StefanSalewski> That is really not recommended. When you use Windows, try to install gtk first. |
| 19:44:00 | FromGitter | <StefanSalewski> Foer him its seems to work, but he really only wants to use libnice two connect two computers. |
| 19:44:08 | * | hnOsmium0001 joined #nim |
| 19:44:43 | FromGitter | <StefanSalewski> I dont think that gstreamer can work without a real gtk install. And of course most of us use gtk on Linux. |
| 19:44:55 | giaco | StefanSalewski, I'm developing a command line tool, not really something that requires a gui, but yeah not a problem apt getting gtk |
| 19:45:02 | giaco | here's the issue https://github.com/StefanSalewski/gintro/issues/108 |
| 19:45:07 | disbot | ➥ Gstreamer, appsink element new-sample signal seems missing ; snippet at 12https://play.nim-lang.org/#ix=2LsK |
| 19:45:21 | FromGitter | <StefanSalewski> We have as least one sucessfull gtk windows project, was something to unlock a game. |
| 19:46:50 | FromGitter | <StefanSalewski> Yes please try full gtk install, gstreamer with dummygtk should really not work. |
| 19:47:30 | FromGitter | <StefanSalewski> And let me know your sucess on issue tracker. Bye. |
| 19:47:35 | FromGitter | <StefanSalewski> Logout |
| 19:53:32 | giaco | same identical problem with gtk, thanks for the feedback |
| 20:06:43 | * | opal quit (Ping timeout: 240 seconds) |
| 20:07:50 | * | opal joined #nim |
| 20:13:40 | FromGitter | <StefanSalewski> Yes, I already replied at issue tracker. You are using an invalid signal for an object. |
| 20:14:33 | FromGitter | <StefanSalewski> Each object has only a limited set of valid signal names, like "clicked" for a button. |
| 20:14:39 | * | leorize_ joined #nim |
| 20:15:16 | FromGitter | <StefanSalewski> We can not mixed them arbitrary. And you use casts, which really hate. |
| 20:15:23 | * | leorize quit (Ping timeout: 240 seconds) |
| 20:16:32 | FromGitter | <StefanSalewski> I have to investigate your issue more carefully tomorrow, have to study the C example. I don't know much about gstreamer. |
| 20:16:40 | FromGitter | <StefanSalewski> Logout! |
| 20:29:40 | * | a_chou joined #nim |
| 20:34:02 | * | a_chou quit (Client Quit) |
| 20:36:20 | FromGitter | <StefanSalewski> And for Araq: The issue is not the on the fly bindings generation. |
| 20:36:55 | FromGitter | <StefanSalewski> Issue is that we support only the Gst main module currently. |
| 20:37:39 | FromGitter | <StefanSalewski> And there are many, many modules in /usr/share/gir-1.0. |
| 20:38:42 | FromGitter | <StefanSalewski> One of them seems to have the "new_sample" signal, but it is not the main module . |
| 20:39:18 | FromGitter | <StefanSalewski> Test with /usr/share/gir-1.0 $ cat Gst-1.0.gir | grep "new-sample" # no output |
| 20:39:53 | FromGitter | <StefanSalewski> /usr/share/gir-1.0 $ cat Gs* | grep "new-sample" # some output |
| 20:40:09 | FromGitter | <StefanSalewski> Time to bed, bye. Logout. |
| 20:46:21 | FromDiscord | <irskep> I'm trying to set up vim in vscode after a long time not messing with nim. I have a `config.nims` file that works fine when I build the project, but VSCode doesn't seem to recognize the `nimscript` module identifiers like `put` and `switch`. I haven't changed any VSCode plugin settings. What could be going wrong? |
| 20:47:20 | FromDiscord | <irskep> It looks like maybe `nim check` is the real problem here |
| 20:54:59 | FromDiscord | <enimatek> i use vim for nim, normally i use vscode or intellij but both are very very flaky with nim, with vim the issues are better debuggable and you can (if you are used to vim) customize the 'issue' in vscode there are now 3 nim plugins, where i think the 'second' one works the best, but has a lot of processes that 'crash' evetually, i had te restart vscode each hour or so, did you test all three extensions? |
| 20:56:31 | saem | You can try the one I maintain, I can give you a bit of help with it. The nimscript thing is an issue, but I haven't dug in super deep into that. Might be as simple as setting it as a project in the settings. |
| 20:58:19 | FromDiscord | <irskep> Switching to @saem's does at least get rid of the ugly squiggles, and autocomplete still works, so I guess problem solved for now |
| 20:58:42 | saem | "solved" :D |
| 20:59:54 | saem | Anyone dug around `sigmatch`, specifically `partialMatch and `matchesAux`? I have a dot expression being passed in but when it does the formal parameter matching it seems to ignore the preceeding parameter (thing before the dot). I'm not exactly sure what the semantics for it should be in this part of the code, so some guidance/rubber ducking would be appreciated. |
| 21:00:27 | FromDiscord | <enimatek> yes nimsaem is the one i use in vscode, seems to work best but the nimsuggest process pile up eventually |
| 21:01:29 | saem | enimatek: I strongly recommend setting up the `"nim.project": ["my.nim", "toplevel.nim", "nimfiles.nim"]` |
| 21:08:46 | saem | in lieu of direct sigmatch help, a hint as to what the `Aux` suffix is trying to convey might also be helpful. Presently, it mostly looks like "helper" or "do the actual work" type stuff, wondering if there is more to it. |
| 21:08:51 | disruptek | saem: i dunno about sigmatch but i know the code is pretty crusty. |
| 21:09:21 | saem | disruptek: OK, that makes me feel a bit better about saying OK the code is wrong. :D |
| 21:09:52 | disruptek | it wouldn't take a lot to convince me. |
| 21:10:17 | saem | The only part that's a bit off is that this code is used in the non-suggest sem pass and it works, but I think that's because of a bunch of post-filter that's done in pick best candidate code. |
| 21:11:10 | disruptek | makes some sense. i wish more of the compiler was side-effect free. |
| 21:13:01 | saem | Yeah, clearer life times around what state things are in would be appreciated or even favour using more memory, if possible, where it's possible to avoid mutation. |
| 21:14:07 | saem | Wow, awkward phrasing... that's what I get when most of my attention is staring at the debugger. |
| 21:14:39 | disruptek | strictFuncs and notnil should help a lot, if compiler devs actually use them. |
| 21:21:18 | * | xet7 joined #nim |
| 21:21:41 | saem | Finding those first few parts where you can do some of the easier mechanical transforms that's the hardest part, it's hard to justify them on their own beyond a principle. |
| 21:22:29 | saem | But if the noise doesn't go away it's really hard to act on meaningful stuff. |
| 21:23:03 | saem | I wonder what the appetite for those sorts of changes are. |
| 21:27:03 | * | opal quit (Ping timeout: 240 seconds) |
| 21:34:32 | disruptek | in my experience, slim. |
| 21:35:12 | * | opal joined #nim |
| 21:36:15 | saem | I see, but don't call me Slim. |
| 21:36:25 | disruptek | fair enough. |
| 21:36:31 | * | narimiran quit (Ping timeout: 246 seconds) |
| 21:36:38 | saem | Congrats, you've also dated yourself. |
| 21:36:56 | disruptek | and stop stealing monkeys? |
| 21:37:36 | Prestige | I think disruptek would date himself |
| 21:37:49 | disruptek | if i knew i could get a hand-job at the end of the night. |
| 21:37:53 | disruptek | oh wait. |
| 21:37:59 | Prestige | Haha. |
| 21:38:12 | FromDiscord | <ache of head> 😳 |
| 21:38:24 | disruptek | it's just, we get along so well, i can hardly believe it. |
| 21:38:41 | saem | Just wait until the honeymoon period is over. |
| 21:39:06 | saem | How'd you first meet? |
| 21:39:22 | disruptek | online. |
| 21:40:34 | * | leorize_ is now known as leorize |
| 21:44:18 | saem | How do you slide into your own dms? |
| 21:44:41 | disruptek | gingerly, the first time. go slow and pause frequently. |
| 21:44:51 | saem | sage advice |
| 21:57:18 | FromDiscord | <Avatarfighter> :disruptek: moment |
| 22:21:31 | saem | nothing like settling: https://github.com/nim-lang/Nim/pull/16657 |
| 22:21:32 | disbot | ➥ fixes nim-lang/nimsuggest#103 con dot exprs |
| 22:22:40 | leorize | saem: you figured out an use case for `con`? :P |
| 22:23:41 | saem | Mediocre signature help, yes: https://github.com/saem/vscode-nim/blob/611bdb71a844b2816ec6492d09f0377c10b59203/src/nimvscode/nimSignature.nim#L7 |
| 22:23:42 | leorize | I have never figured out what are you supposed to do with that command |
| 22:24:12 | saem | I think with some more fixes to con and returning ranges and not just prefix positions, good signature help would be easy. |
| 22:24:44 | leorize | yep, I need the range |
| 22:25:43 | leorize | and a break down for the signature would be nice for implementing param template |
| 22:25:44 | saem | I think it's pretty close, I looked at the info code and it is a bit tricky, but it shouldn't be too bad. |
| 22:26:46 | saem | The trick is operators to account for the back ticks, which don't appear when invoked, indexing operators such as `[]`, where the operator len is not really relevant. |
| 22:27:41 | saem | Anyhow, seems doable once I'm more comfortable with more of the compiler. |
| 22:28:18 | giaco | is there any existing abstraction for masking threads into async functions (to move non-async login into async-based programs) |
| 22:28:45 | leorize | saem: can `con` work for command call syntax? |
| 22:29:23 | * | opal quit (Ping timeout: 240 seconds) |
| 22:29:37 | saem | dunno, but I've seen spawn + async used together, giaco. |
| 22:30:31 | saem | leorize: you know what, that might be an easy thing to test and at worst it's an additional check to the conditional I added. |
| 22:30:49 | giaco | saem: thanks |
| 22:31:30 | saem | giaco: that's not a great answer, I'm sure there is something better, and the not nearly complete CPS stuff is trying to help precisely with this, so it's important to many folks. |
| 22:31:36 | * | opal joined #nim |
| 22:32:34 | giaco | saem: sorry but, what CPS stands for? |
| 22:32:58 | saem | giaco: continuation-passing style |
| 22:33:13 | giaco | k thanks |
| 22:33:16 | saem | https://github.com/disruptek/cps#continuation-passing-style it's pretty cool. |
| 22:33:40 | saem | Some folks here are working on it, they're very cool. |
| 22:34:31 | giaco | yeah I wrote some haskell before nim and it is pretty common there |
| 22:35:21 | saem | giaco: there is an example in asyncnet: https://nim-lang.org/docs/asyncnet.html#examples-chat-server that's with a more bare bones threadpool, not sure what the sentiment around spawn is. |
| 22:39:51 | saem | giaco: this is the spawn example: https://github.com/dom96/nim-in-action-code/tree/master/Chapter3/ChatApp |
| 22:39:59 | saem | Now I'll stop spamming you with links. :D |
| 22:40:30 | leorize | saem: during my experimentation with con for nim.nvim, I found that the signature help isn't really reliable |
| 22:40:32 | giaco | please don't, I need them :D |
| 22:41:37 | saem | too late, you're cut off. ;) |
| 22:41:52 | leorize | if you type out a variable/function it will catch on those symbol instead of the outer pro |
| 22:41:57 | leorize | proc call* |
| 22:42:08 | leorize | and also it just doesn't work when your cursor is in the space between `, ` |
| 22:42:12 | saem | yeah, it needs some love, I'm treating this all like the types of queries that need to be supported so I don't want to kill too much. |
| 22:42:21 | leorize | given a fully specified call |
| 22:43:00 | leorize | we really need a newer protocol :P |
| 22:43:12 | leorize | you can't add fields to the current one without breaking older stuff |
| 22:43:19 | saem | I don't disagree about the need, i disagree on the schedule/priority inversion. ;) |
| 22:43:23 | leorize | makes me wonder if we should just write an lsp client instead :P |
| 22:43:33 | saem | You mean LSP server? |
| 22:43:33 | leorize | lsp server* |
| 22:43:46 | saem | yeah.... I looked at that a whole lot. |
| 22:43:55 | saem | I want to, not against it. |
| 22:44:46 | saem | But the "query engine" itself needs much fixing before it can really be useful and the protocol is a hard one to reason about before that's figured out. |
| 22:45:23 | leorize | frankly I'm still waiting for IC to deliver its promises |
| 22:45:44 | saem | I do agree that an LS because the protocol has gone through trial by fire (many other languages) is probably going to hold up to our use cases and likely anticipates them and more. |
| 22:45:47 | leorize | then I can figure if my pie in the sky idea that I outlined in nimsuggest#66 can be implemented |
| 22:46:14 | saem | I agree with 4raq, it can be done now, just needs a bit of punching. |
| 22:46:53 | leorize | (and yes I still want the project file to go away :P) |
| 22:47:30 | saem | I think a query context is a must, I'm not sure going stateless _too_ stateless is the right way to go. |
| 22:48:12 | leorize | my idea is basically "very smart on demand but do best effort when you lack info" |
| 22:48:51 | saem | Hmm, feels too implicit. |
| 22:48:51 | leorize | my experiences with nim.nvim shows that the best effort scheme works 90% of the time, which should be useful for quick edits |
| 22:49:17 | leorize | and that is working with much less data than what the compiler have |
| 22:49:21 | saem | Yeah, but explicit needs to be king, because there are use cases that can't deal with 90%, so as long as we don't preclude those, I'm fine. |
| 22:50:09 | leorize | more context is optional is what I'm striving for |
| 22:50:25 | leorize | if the user need all the fancy stuff you're likely to have the data, which then you can forward to nimsuggest |
| 22:51:04 | leorize | but for the normal use of "just quickly add/remove some code", a stateless impl that works well is appreciated |
| 22:51:10 | saem | Yeah, that seems fine, then we can just argue about what the right default is. :D |
| 22:55:15 | saem | The type of IC we need, putting speed aside for a moment, is more around versions of code, build configs, and all that jazz. If that starts influencing in the various existing data structures and phases, it'll be somewhat more complexity, but I think it'll drive better design that's useful for the regular compiler and other tools as well. |
| 22:56:53 | * | hmmm quit (Quit: WeeChat 3.0) |
| 22:57:03 | * | hnOsmium0001 quit (Quit: Connection closed for inactivity) |
| 22:57:55 | * | Vladar quit (Quit: Leaving) |
| 23:02:12 | giaco | I didn't know "spawn" and it seems great for what I need, but I'm not getting if threadpool's FlowVar is actually awaitable or not. I see that word "await" is present in threadpool module doc page, but not sure if I can simply "var myvar = await myflowvar" in async function |
| 23:07:38 | * | hmmm joined #nim |
| 23:09:15 | saem | leorize: command syntax is borked because the cursor tracking loses the plot me thinks. |
| 23:10:36 | PMunch | leorize, saem, did someone say LSP? |
| 23:10:39 | saem | giaco: in the chat example it's a check and then return control to the dispatcher. |
| 23:10:45 | saem | PMunch: hahaha! |
| 23:11:25 | saem | I've mucked around a bunch with the LSP code base. |
| 23:12:08 | PMunch | Oh neat, found anything? :P |
| 23:12:09 | giaco | saem: in example isReady is used outside an async context |
| 23:12:09 | saem | Testing is such a pain in the ass due to the simple fact that you can't reliably do non-blocking stdio |
| 23:12:29 | Prestige | PMunch: how is lsp atm anyway? Last I checked there were some PRs |
| 23:12:34 | saem | giaco: d'oh, good point |
| 23:12:56 | PMunch | Prestige, well I'm using it every day |
| 23:13:14 | Prestige | Same, I just have that one issue we talked about forever ago |
| 23:13:26 | PMunch | Not a whole lot of work being done on it right now though unfortunately.. |
| 23:14:12 | PMunch | Oh yeah, the changes across files thing is probably still an issue |
| 23:14:20 | saem | PMunch: yeah, there are a bunch of things I want to change, but without a reasonable test harness it hurts. I also burned waaaay too much time on trying to get that whole stupid process supervision thing working. The whole part where you can't kill threads... oof (I focused on testing and reliability) |
| 23:14:22 | PMunch | But I think that's a nimsuggest thing.. |
| 23:14:26 | * | Cadey quit (Quit: WeeChat 3.0) |
| 23:14:36 | giaco | side question: docs says "A project can also have a project-specific configuration file named $project.nim.cfg that resides in the same directory as $project.nim". Been trying in the last minutes but I think I'm not getting what $project is for nim |
| 23:14:58 | PMunch | saem, that is one thing I've really wanted to do, a simple mock LSP client that would allow us to set up some testing |
| 23:15:23 | * | Xe joined #nim |
| 23:15:34 | saem | PMunch: I mean I did a bit there, if you can stand to look at ugly hack together code and abandoned experiments. |
| 23:15:53 | saem | giaco: sorry, you can't get the config to be used or you don't know the point of it? |
| 23:17:02 | PMunch | saem, I'd love to :) |
| 23:17:12 | PMunch | Pretty much what I do at work anyways :P |
| 23:19:40 | giaco | I have a folder with many small independent nim experiments (a.nim, b.nim, ... z.nim) for some of them I need specific commands like --threads:on. So far I've been running manually the compiler for each of them, but now it feels time to use proper cfg for each one. I've been trying to create a.nim.cfg, b.nim.cfg, ... in same folder of nim file or in working directory of the compiler (or both) but they |
| 23:19:42 | giaco | seems not read (Hint line at compile time doesn't list it either) |
| 23:20:46 | * | vicfred joined #nim |
| 23:22:14 | FromDiscord | <ElegantBeef> If the `nim.cfg` file or the `.nims` is next to the nim file to be compiled it should load |
| 23:25:13 | saem | PMunch: this branch has all my half-baked crap, but this showed how to get nimsuggest process management working, I couldn't get rid of certain ambiguities, but it's less error prone than the original and has non-blocking IO IIRC: https://github.com/saem/nimlsp/blob/exp-rework-lsp/src/nimlsppkg/suggest.nim |
| 23:26:34 | giaco | it's it possible to have a separate nim.cfg for each .nim without separating them into folders? |
| 23:26:46 | giaco | *isn't it |
| 23:26:51 | saem | PMunch: I messed around a bunch with project scanning and IIRC fixed some uri encode/decode issues that I found in nimlsp's version. |
| 23:26:53 | saem | https://github.com/saem/nimlsp/blob/exp-rework-lsp/src/nimlsppkg/nimprojscan.nim |
| 23:27:16 | PMunch | saem, ah so you're not using nimsuggest as a library |
| 23:27:53 | saem | PMunch: not entirely true, that was just trying to get that too work because I made the mistake of thinking that was a good idea, when killing threads is a better idea (if the stdlib supported it). |
| 23:27:59 | FromDiscord | <ElegantBeef> It should be possible giaco |
| 23:28:11 | leorize | giaco: nim c file.nim will load `file.nim.cfg` and/or `file.nims` |
| 23:28:32 | leorize | saem: please never kill threads |
| 23:28:48 | leorize | killing threads won't release whatever that thread allocated |
| 23:29:17 | saem | That's why I want something first class, so that's possible (assuming a few caveats). |
| 23:29:40 | PMunch | saem, hmm that should be possible |
| 23:29:51 | PMunch | Running nimsuggest in multiple threads and killing them I mean |
| 23:29:58 | leorize | generally I think the idea of killing a thread is dumb :P |
| 23:30:12 | leorize | if you want that just use processes, they are not that hard |
| 23:30:14 | saem | So is the idea of killing any execution context, then? |
| 23:30:18 | giaco | ok, so I think vscode is playing tricks on me. |
| 23:30:20 | saem | Yes they are |
| 23:30:28 | leorize | (if you wait for long enough so my osproc replacement to complete) |
| 23:30:33 | leorize | for* |
| 23:30:38 | saem | giaco: yes, it could well be, especially if it's my extension, written by a total jerk |
| 23:30:52 | PMunch | I mean it wouldn't be terribly hard to implement some kind of cancellation system |
| 23:31:06 | giaco | :D |
| 23:31:15 | saem | OK, so I got proc management working, except when you realize the amount of protocol work you have to do to get an actual worthwhile experience it's bonkers. |
| 23:31:45 | PMunch | Why do you think I went from procedures to integrating with nimsuggest directly? |
| 23:32:08 | saem | PMunch: it was the right call and thread management is a legit need. :) |
| 23:32:12 | leorize | given that IC is getting active work from Araq, maybe you should look into redoing nimsuggest altoghether? :P |
| 23:32:21 | leorize | gah, my grammar is all over the place |
| 23:32:31 | saem | same, I'm not going to fault you for it. ;) |
| 23:33:23 | saem | Regardless, a totally new nimsuggest would be super duper and all but it'll have the same problem, you want to run tasks, if they misbehave you want to murder them, cancellation is a totally reasonable thing. |
| 23:33:58 | leorize | why would you ever want to run dangerous code in the same process? |
| 23:34:29 | saem | Because you can keep making that argument until that code is on another computer |
| 23:35:02 | leorize | lol |
| 23:35:05 | PMunch | leorize, you can easily write a "malicious" macro that gets evaluated by the nimsuggest thing |
| 23:35:22 | giaco | vscode is running my nim file (F6) with 'nim c -r "/home/giaco/nim/experiments/threadtest.nim"', terminal command line working directory is "/home/giaco/nim". If I write the config file as "/home/giaco/nim/experiments/threadtest.nim.cfg" it is not used. If I move same file to parent dir it doesn't work either. It only works if I rename it to nim.cfg |
| 23:35:45 | leorize | PMunch: not anymore |
| 23:36:08 | leorize | Araq finally implemented a pseudo sandbox to prevent all that stuff |
| 23:36:16 | saem | giaco: which extension are you using exactly, there are more extensions than community members at this point. |
| 23:36:49 | PMunch | leorize, wait really? |
| 23:37:09 | giaco | the one from Konstantin Zaitsev, the most downloaded I think (the first one that popped in extension list) |
| 23:37:21 | leorize | yes, writeFile and staticExec has been banned from executing in nimsuggest |
| 23:38:04 | leorize | in Nim source the mode is referred to as nimcore |
| 23:38:39 | leorize | or something "core", just in case you want to add more restrictions to the VM |
| 23:39:11 | * | NimBot joined #nim |
| 23:40:20 | PMunch | Ooooh right |
| 23:40:23 | saem | PMunch: Here I separated out the language server state and modelled the lifecycles as separate procs so it would be amenable to unit testing. Also assumed that it would be both easier to reason about the protocol and server: https://github.com/saem/nimlsp/blob/exp-rework-lsp/src/nimlsppkg/languageserver.nim#L318 I find the existing code required having to remember lots of context all the time. |
| 23:40:23 | PMunch | That's cool |
| 23:40:59 | saem | giaco: you can try the one I wrote, it might work better, it's the second most popular? |
| 23:41:16 | saem | well, ported more than wrote -- credit where credit is due. |
| 23:41:56 | giaco | why not! +1 for saem |
| 23:44:57 | giaco | saem: yeah, it works |
| 23:45:01 | giaco | thanks! |
| 23:45:40 | saem | \o/ |
| 23:46:06 | giaco | now that you have full control of my machine, please can you fix my adsl? |
| 23:46:27 | saem | yeah... no it's goign to get worse with the botnet. |
| 23:46:39 | giaco | damn, again |
| 23:46:39 | saem | hope you have a gpu, need me more coins |
| 23:48:30 | FromDiscord | <ElegantBeef> Ah that explains why i've been getting a lot of gpu hitches recently |
| 23:48:38 | saem | I'm kinda leaning towards leorize's take, maybe just have nimls or something, make it part of the compiler for now until things settle enough and it can be separated out. |
| 23:49:03 | saem | ElegantBeef: just think of them as little victories |
| 23:49:21 | FromDiscord | <ElegantBeef> I was thinking them more as opengl here |
| 23:49:31 | * | PMunch quit (Ping timeout: 246 seconds) |
| 23:49:33 | leorize | to be fair 4raq is open in taking nimlsp in |
| 23:49:48 | leorize | the compiler should start taking external deps instead of reinventing things |
| 23:50:06 | leorize | well that kinda depends on a good package manager, which we don't have |
| 23:52:28 | saem | package manager or .... https://github.com/disruptek/dist? |
| 23:53:26 | leorize | yes |
| 23:54:15 | saem | I think dist + a collections concept would be pretty awesome. |
| 23:54:20 | leorize | I consider `dist` a side-effect of not having a good package manager |
| 23:54:39 | saem | dist solve a cohesion problem as well. |
| 23:55:39 | leorize | cohesion problem? |
| 23:56:52 | FromDiscord | <exelotl> everything in dist is known to work together |
| 23:56:54 | saem | package managers tend to be a big namespace, it's there if you can publish. dist is that but there are further standards and the things within work together and might even leverage each other. |
| 23:58:20 | leorize | dist is basically how a batteries-included stdlib is implemented everywhere |
| 23:58:38 | leorize | other than Nim |
| 23:58:54 | saem | I think dist is a single collection, which is likely fine, but seeing the conversations go by, I suspect that people will want further collections, where certain things are guaranteed (works with arc, no dynamic allocations, ...) or whatever. |
| 23:59:27 | leorize | and if we have a good package manager `dist` can be implemented as a `.nimble` file with only `requires` |
