| 00:01:22 | giaco | exelotl, thanks. I need support for blobs |
| 00:02:01 | FromDiscord | <exelotl> there's also gatabase which claims to be an ORM but I couldn't find where the objects come into it... Seems more like a DSL with connection pooling |
| 00:02:24 | giaco | so far the only db interface I've found that natively support blobs is: https://gulpf.github.io/tiny_sqlite/tiny_sqlite.html |
| 00:02:30 | giaco | but that's not an ORM |
| 00:03:02 | FromDiscord | <exelotl> I think as far as ORMs go Norm is the only one I'd consider using currently, but yeah I guess it doesn't have what you're looking for :( |
| 00:04:42 | * | krux02 quit (Remote host closed the connection) |
| 00:05:43 | giaco | I wonder if I should convert my seq[byte] to string, store it and back. I have no idea if the overhead is negligible or not. What do you think? |
| 00:06:13 | * | u0_a216 quit (Ping timeout: 246 seconds) |
| 00:08:03 | * | u0_a216 joined #nim |
| 00:08:26 | FromDiscord | <ElegantBeef> I mean they're identical storage |
| 00:08:55 | FromDiscord | <ElegantBeef> `cast[string](yourByte)` is all oyu need to do, though i dont know why you would since the written value is identical |
| 00:13:24 | FromDiscord | <exelotl> Would sqlite accept that? Or would you have to encode it as base64? |
| 00:14:54 | * | u0_a216 quit (Ping timeout: 256 seconds) |
| 00:15:33 | FromDiscord | <ElegantBeef> I'd tell you if i knew anything about databases |
| 00:19:19 | * | u0_a216 joined #nim |
| 00:25:45 | * | u0_a216 quit (Ping timeout: 240 seconds) |
| 00:27:47 | * | u0_a216 joined #nim |
| 00:35:01 | * | u0_a216 quit (Ping timeout: 264 seconds) |
| 00:36:23 | * | u0_a216 joined #nim |
| 00:42:32 | * | sagax quit (Quit: Konversation terminated!) |
| 00:45:21 | * | u0_a216 quit (Ping timeout: 256 seconds) |
| 01:00:00 | * | njoseph quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 01:01:07 | * | njoseph joined #nim |
| 01:06:02 | disruptek | there's no significant overhead. |
| 01:11:49 | saem | today i learned about `comm`, that's a fun command. |
| 01:11:54 | leorize | giaco: if you use sqlite then there's ormin too |
| 01:11:57 | leorize | !repo ormin |
| 01:11:58 | disbot | https://github.com/Araq/ormin -- 9ormin: 11Ormin -- An ORM for Nim. 15 129⭐ 17🍴 |
| 01:15:05 | * | Tanger joined #nim |
| 01:20:26 | disruptek | parallel is a fun command. |
| 01:25:10 | * | lritter quit (Ping timeout: 256 seconds) |
| 01:36:04 | saem | that too |
| 01:36:31 | saem | comm is currently helping me find where the heck this enum is being wrapped in a `tyTypeDesc` |
| 01:36:47 | saem | hint: I have no clue still |
| 01:37:38 | saem | crap... so close yet so far. |
| 01:39:16 | * | beatmox quit (Ping timeout: 258 seconds) |
| 01:39:45 | * | qwertfisch quit (Ping timeout: 240 seconds) |
| 01:40:08 | * | vicfred quit (Quit: Leaving) |
| 01:44:48 | * | keyle joined #nim |
| 01:45:50 | FromDiscord | <Anonymous Poet> this might either be a dumb question or impossible: can i run an asynchttpserver and a socket that connects to the server (as a client) from the same nim file? im trying to write a test and it is eluding me |
| 01:49:34 | * | keyle quit (Ping timeout: 260 seconds) |
| 01:49:46 | disruptek | yes. |
| 01:50:04 | saem | Oh I "figured it out" and sadly it doesn't tell me if that's really the right thing to do and whether I should be unpacking it or is there something more significant that's off. |
| 01:50:20 | saem | Really wish those internal API/lifetimes were more clear. :/ |
| 01:50:21 | disruptek | what are you trying to do? |
| 01:50:29 | saem | So pure enums don't show up in suggest |
| 01:50:39 | saem | I got that working, go me -- at least for a test case. |
| 01:51:05 | saem | Let me throw up a branch so it's easier to see. |
| 01:51:29 | FromDiscord | <Anonymous Poet> im trying to write tests for my asynchttpserver pr |
| 01:51:40 | FromDiscord | <Anonymous Poet> ive got two separate files right now that do everything i need |
| 01:51:44 | FromDiscord | <Anonymous Poet> i just ... need to combine them |
| 01:52:23 | FromDiscord | <Anonymous Poet> sent a code paste, see https://play.nim-lang.org/#ix=2LBV |
| 01:52:29 | disruptek | there are existing async tests that do this; i used one to debug async/arc long ago. |
| 01:52:41 | disruptek | but async and i don't get along anymore. |
| 01:52:55 | FromDiscord | <Anonymous Poet> i looked at `tasynchttpserver.nim` and its not helpful because its based on the server returning a response |
| 01:53:04 | FromDiscord | <Anonymous Poet> where what i want is to test the decoding of the request |
| 01:53:07 | disruptek | what a strange concept. |
| 01:53:13 | FromDiscord | <Anonymous Poet> although its totally possible that i missed some tests |
| 01:53:22 | disruptek | that the response indicate the decoding result. |
| 01:53:30 | disruptek | er, /have/ the response ... |
| 01:53:43 | FromDiscord | <Anonymous Poet> i mean, i could ... but that seems more convoluted? |
| 01:53:57 | disruptek | who cares? |
| 01:54:08 | FromDiscord | <Anonymous Poet> people who like readable code 😭 |
| 01:54:26 | disruptek | it doesn't work otherwise at the moment, correct? |
| 01:54:31 | FromDiscord | <Anonymous Poet> i guess ill try that again and maybe itll be less offesnive |
| 01:54:34 | FromDiscord | <Anonymous Poet> ... yes |
| 01:54:35 | disruptek | i would rather have a working test and than unworking test. |
| 01:54:40 | FromDiscord | <Anonymous Poet> i agree with that |
| 01:55:04 | disruptek | my opinion is worthless, but if you link the PR i will thumb it. |
| 01:55:26 | FromDiscord | <Anonymous Poet> ah, right, i remembered the other reason why i didnt do that before |
| 01:55:31 | FromDiscord | <Anonymous Poet> im trying to write from a plain socket |
| 01:55:43 | FromDiscord | <Anonymous Poet> all of the tests use the nim httpclient to get the response back |
| 01:55:57 | disruptek | cps tests are green, except for the purple ones that aren't. |
| 01:56:12 | FromDiscord | <Anonymous Poet> this is the pr, it got merged already, but theres a small issue https://github.com/nim-lang/Nim/pull/16636/files |
| 01:56:13 | disbot | ➥ Add support for Transfer-Encoding: chunked |
| 01:56:17 | disruptek | poet: well, that don't won't hunt. and i think you know that. |
| 01:56:38 | FromDiscord | <Anonymous Poet> sorry, what do you mean? |
| 01:56:58 | disruptek | you can't mix async and sync and expect it to work. |
| 01:57:11 | disruptek | s/don't/dog/ |
| 01:57:13 | FromDiscord | <Anonymous Poet> yeah, ofc |
| 01:57:24 | disruptek | i guess i'm a little more horny than usual. |
| 01:57:31 | disruptek | s/horny/tired/ |
| 01:57:49 | FromDiscord | <Anonymous Poet> close ... |
| 01:57:52 | disruptek | if it's merged, what's the problem? |
| 01:57:56 | FromDiscord | <Anonymous Poet> what if i fork the process? |
| 01:58:02 | disruptek | sure. |
| 01:58:07 | FromDiscord | <Anonymous Poet> oh, the problem is theres a somewhat-but-not-entirely subtle bug |
| 01:58:17 | disruptek | i think you mean creating a thread. |
| 01:58:22 | FromDiscord | <Anonymous Poet> this line `request.body = request.body & chunk` should be `request.body = request.body & chunk[0..<bytesToRead]` |
| 01:58:39 | disruptek | so create a new PR. |
| 01:58:40 | FromDiscord | <Anonymous Poet> otherwise theres extra newlines between all the chunks |
| 01:58:49 | FromDiscord | <Anonymous Poet> right, i will, but i want to add tests to the new pr too |
| 01:59:35 | FromDiscord | <Anonymous Poet> i meant process because i dont know how nim handles async behind the scenes, so having a separate process seems better (more isolation) but thread is preferable if that works |
| 01:59:55 | disruptek | a thread will work, but good lucky getting dom to accept it. |
| 02:00:04 | disruptek | s/lucky/laid/ |
| 02:00:07 | disruptek | s/laid/luck/ |
| 02:00:11 | disruptek | i dunno what my problem is. |
| 02:00:14 | disruptek | well, i do. |
| 02:00:18 | FromDiscord | <Anonymous Poet> hmm, should i come back later? lmao |
| 02:03:03 | FromDiscord | <Anonymous Poet> alternatively, since i have the full request text, do you know if theres a way to feed it straight into the `processRequest` function? |
| 02:03:54 | disruptek | i doubt it. dom doesn't like to make it easy for people to hack his shit until it works. |
| 02:04:27 | disruptek | saem: well? |
| 02:04:59 | saem | This is the change: https://github.com/nim-lang/Nim/compare/devel...saem:saem-nimsuggest-pure-enum-completion-82?expand=1 |
| 02:05:21 | saem | I'm pretty sure the other code is a dead path, but I don't know. |
| 02:05:32 | saem | And the unwrapping seems suspect. |
| 02:05:40 | saem | But it makes completion do the thing. |
| 02:05:51 | disruptek | so remind me what the problem is. |
| 02:07:01 | saem | Currently if you try to nimsuggest after `LogType.deb`, it just barfs all possible suggestions (fallback path). |
| 02:07:38 | saem | The `typ` that shows up there is not the enum itself, but a `tyTypeDesc`, which is wrapping the enum. |
| 02:08:24 | disruptek | so normally you might use something like `skipTypes` which can unwrap types with optional constraints. |
| 02:09:12 | saem | D'oh, I should have read the code for that, didn't realize that's what it meant. |
| 02:09:36 | disruptek | i'm not really reading the context here, but you might find it useful for this sort of thing. |
| 02:09:54 | disruptek | i hate this sort of logic; it's hard to enhance. |
| 02:10:45 | disruptek | oh, yeah, there are skipTypes demos all over this file. 😁 |
| 02:10:52 | saem | I agree, but it's all intuition right now. Feels like a bunch of things should be more flags, than state wrappers. |
| 02:11:19 | disruptek | yes, i would rather more of the compiler was query-based. |
| 02:11:22 | saem | Then have funcs for answer questions which absorb the complex pattern matches. |
| 02:11:33 | disruptek | i think it works much better for a future immutable ast that's /fast/. |
| 02:12:07 | saem | IC basically necessitates that? |
| 02:12:11 | disruptek | this is part of how i want carnac to work in the compiler... we won't just cache the ast, but we will cache the queries against it and their responses. |
| 02:12:25 | disruptek | and carnac automates all of this entirely. |
| 02:12:57 | disruptek | ic /should/ necessitate this, but it doesn't yet; not really. |
| 02:13:37 | disruptek | but i should probably shutup about it. i am no longer intimately familiar with ic, as araq has done a lot of work since i moved on. |
| 02:15:25 | saem | OK, thanks for the pointers... now I gotta see what I should do with this skip types business |
| 02:15:55 | FromDiscord | <ElegantBeef> Jump rope |
| 02:16:40 | disruptek | maybe nothing; it might be irrelevant. but you're not even reaching your code because typ is nil in the logic. |
| 02:19:30 | saem | It isn't, well at some point it's not because I do hit my code -- I hit a breakpoint in the debugger |
| 02:23:15 | saem | ah, so carnac is for memoizing things -- just read the README |
| 02:27:18 | * | beatmox joined #nim |
| 02:28:40 | FromDiscord | <Anonymous Poet> well wtf |
| 02:28:46 | * | qwertfisch joined #nim |
| 02:29:05 | disruptek | yeah, carnac is a simple demo that's actually kinda useful. |
| 02:29:16 | FromDiscord | <Anonymous Poet> i guess theres been a lot of stuff fixed ... i tried compiling my test code after setting `--lib` and my socket thing just works |
| 02:29:21 | FromDiscord | <Anonymous Poet> i mean, yay, but wtf |
| 02:29:21 | disruptek | or, it would be, if the compiler worked. |
| 02:29:53 | disruptek | it's almost like your test works when the lib includes your code. |
| 02:30:46 | FromDiscord | <Anonymous Poet> nope, jk, doesnt work |
| 02:30:50 | FromDiscord | <Anonymous Poet> not sure why it worked that one time |
| 02:31:07 | FromDiscord | <Anonymous Poet> i knew it was too suspicious to just work like that |
| 02:33:16 | FromDiscord | <Anonymous Poet> hm .... i got it to work again ... maybe? further investigation is clearly required |
| 02:35:07 | FromDiscord | <Anonymous Poet> ok, actually, i think i may have an explanation ... as long as after i send the message on the socket, i add a `waitFor asyncSleep(X)` there'll be a context switch so the server can process the request |
| 02:35:26 | FromDiscord | <Anonymous Poet> I think this is acceptable for tests, right? |
| 02:43:39 | * | keyle joined #nim |
| 02:49:05 | * | bacterio quit (Ping timeout: 240 seconds) |
| 02:51:44 | * | bacterio joined #nim |
| 03:00:06 | * | opal joined #nim |
| 03:06:56 | disruptek | yes. |
| 03:07:14 | disruptek | there are easier ways to do it, though, i'm sure. |
| 03:08:10 | * | saem Welp, hopefully this is some bit of progress for nimsuggest (🐌 ) |
| 03:08:16 | saem | https://github.com/nim-lang/Nim/pull/16676/files |
| 03:08:17 | disbot | ➥ fixed nim-lang/nimsuggest#82 pure enum field sug |
| 03:10:56 | * | bacterio quit (Ping timeout: 240 seconds) |
| 03:12:19 | * | u0_a216 joined #nim |
| 03:13:50 | * | abm quit (Quit: Leaving) |
| 03:16:09 | * | u0_a216 quit (Read error: Connection reset by peer) |
| 03:19:19 | * | u0_a216 joined #nim |
| 03:20:34 | saem | This feels like steering a cargo ship with popsicle stick. 🤔 |
| 03:22:47 | FromDiscord | <﷽๖̶̶̶ζ͜͡In> революция |
| 03:22:49 | FromDiscord | <﷽๖̶̶̶ζ͜͡In> революция |
| 03:22:51 | FromDiscord | <﷽๖̶̶̶ζ͜͡In> революция↵революция↵революция |
| 03:22:52 | FromDiscord | <﷽๖̶̶̶ζ͜͡In> революция |
| 03:22:53 | FromDiscord | <﷽๖̶̶̶ζ͜͡In> революция↵революция↵революция |
| 03:22:57 | disruptek | noted. |
| 03:23:53 | disruptek | Error: 'method' is only allowed at top level |
| 03:24:03 | * | muffindrake quit (Ping timeout: 260 seconds) |
| 03:24:13 | disruptek | so... how can i emit more than a single method definition from a macro? |
| 03:24:40 | * | bacterio joined #nim |
| 03:25:40 | * | muffindrake joined #nim |
| 03:26:02 | disruptek | empty room syndrome. |
| 03:34:49 | * | u0_a216 quit (Ping timeout: 246 seconds) |
| 03:39:13 | FromDiscord | <Avatarfighter> no bro |
| 03:39:14 | FromDiscord | <ElegantBeef> godot-nim uses multiple methods inside a DSL |
| 03:39:16 | FromDiscord | <Avatarfighter> no one knows |
| 03:39:36 | FromDiscord | <ElegantBeef> Although i think it doesnt emit the methods as much as modify them |
| 03:43:20 | saem | I've seen an example of that in jsonschema by pmunch |
| 03:52:44 | disruptek | hmm, thanks for the ptr. |
| 03:53:48 | disruptek | nnkMethodDef does not appear in the jsonschema repo. |
| 03:57:48 | saem | Whoops, I also thought they weren't really all that different from procs when it comes to building them up |
| 03:57:50 | disruptek | oh i'm dumb. my testes prevent it from reaching top level. |
| 03:58:00 | disruptek | maybe it's possible after all. |
| 03:58:17 | disruptek | just, y'know, impossible to compose. 🤣 |
| 03:58:26 | saem | Wait... LoL, I might have written/reworked nimsuggest test code that does. |
| 03:58:31 | saem | LoL |
| 03:58:54 | * | u0_a216 joined #nim |
| 03:59:35 | disruptek | yep, i'm stupid. |
| 04:00:27 | disruptek | i think i can do it, i just can't test it. 🤪 |
| 04:05:16 | * | u0_a216 quit (Ping timeout: 246 seconds) |
| 04:06:51 | FromDiscord | <Anonymous Poet> quick question, where is the file for the megatest output? my pr is failing CI with `FAIL: megatest output different!` |
| 04:09:59 | saem | tmegatest? |
| 04:11:02 | FromDiscord | <Anonymous Poet> i couldnt find a file with that name, it seems to be a testament setting? |
| 04:11:43 | saem | oh, looks like a category of tests |
| 04:11:52 | FromDiscord | <Anonymous Poet> yeah |
| 04:12:41 | FromDiscord | <flywind> you should not `echo "ok"` |
| 04:13:35 | FromDiscord | <flywind> `megatest` will join multiple tests into a big file which makes CI faster |
| 04:13:58 | FromDiscord | <Anonymous Poet> ah, ok. I was following what `tasynchttpserver.nim` did |
| 04:13:59 | FromDiscord | <flywind> If you search `failure`, you could find the diff. |
| 04:14:17 | FromDiscord | <Anonymous Poet> i imagine i should get rid of the other echos too |
| 04:14:40 | FromDiscord | <Anonymous Poet> one question though, what do you mean by this? `Please reuse string buffer or something similar.` |
| 04:14:42 | FromDiscord | <flywind> yeah, you could get rid of them |
| 04:14:44 | FromDiscord | <flywind> https://github.com/nim-lang/Nim/blob/bb12d4362e12d7f0d95e9b16e0b50ce9213d5fe9/tests/stdlib/tasynchttpserver.nim#L4 |
| 04:15:40 | * | u0_a216 joined #nim |
| 04:16:04 | FromDiscord | <flywind> I mean don't allocate new memory for string like `request.body = request.body & chunk[0 ..< bytesToRead]` |
| 04:16:11 | FromDiscord | <flywind> see also https://nim-lang.github.io/Nim/testament.html |
| 04:16:21 | FromDiscord | <Anonymous Poet> i think ill stick to making one logical change at a time, wrt tasynchttperserver.nim |
| 04:16:38 | FromDiscord | <Anonymous Poet> ah, gotcha |
| 04:16:40 | * | narimiran joined #nim |
| 04:17:32 | FromDiscord | <Anonymous Poet> is using `request.body.add` more memory efficient than what im doing? in most languages strings are immutable buffers of fixed size, so youd need to realloc and copy either way, no? |
| 04:17:47 | disruptek | yes. |
| 04:18:06 | FromDiscord | <flywind> string is mutable in Nim. |
| 04:18:07 | disruptek | our strings are not immutable buffers. |
| 04:18:28 | FromDiscord | <Anonymous Poet> 😮 |
| 04:18:46 | FromDiscord | <Anonymous Poet> is it amortized growth like c++ vectors? |
| 04:19:05 | disruptek | well, i don't know c++, but it's amortized growth. |
| 04:20:12 | FromDiscord | <Anonymous Poet> on exceeding bounds, itll double the alloc space; same with shrinking (ie. changes occur by a factor of 2 of max capacity) |
| 04:21:45 | disruptek | i think realloc optimization was improved for strings recently, too. |
| 04:21:57 | disruptek | under arc, i mean. |
| 04:22:05 | disruptek | i wasn't really paying close attention. |
| 04:24:54 | FromDiscord | <Anonymous Poet> oh, cool |
| 04:25:53 | * | u0_a216 quit (Ping timeout: 265 seconds) |
| 04:31:32 | leorize | concepts match under one context, switch to another and it stops matching... |
| 04:34:20 | leorize | I'm giving up on concepts until it actually works |
| 04:34:34 | disruptek | is this the new impl? |
| 04:35:08 | leorize | no, still the old one |
| 04:35:12 | leorize | Araq hasn't merged the new one yet |
| 04:35:28 | disruptek | right, well the old one is pretty hard to use successfully. |
| 04:37:48 | leorize | looks like my Any* type won't be `Any` for real anytime soon |
| 04:38:48 | disruptek | araq threatened to merge the new impl; he would probably put them in for ya. |
| 04:52:24 | * | adnan338 joined #nim |
| 04:52:32 | * | adnan338 quit (Client Quit) |
| 04:52:42 | * | adnan338 joined #nim |
| 04:57:20 | * | waleee-cl quit (Quit: Connection closed for inactivity) |
| 05:00:41 | leorize | depends on whether his new impl actually work :P |
| 05:01:18 | disruptek | i thought i was the only one who was tired of alpha-testing the compiler. |
| 05:06:24 | leorize | the compiler has the great attribute of working until I write software with it |
| 05:09:31 | FromDiscord | <Anonymous Poet> does nim have a concept of namespaces, other than modules? |
| 05:09:36 | disruptek | no. |
| 05:09:59 | FromDiscord | <Rika> i believe if it did, UFCS would be useless. |
| 05:10:03 | FromDiscord | <ElegantBeef> Yep |
| 05:10:15 | FromDiscord | <Anonymous Poet> oh, funnily enough its because of UFCS that im asking |
| 05:10:32 | FromDiscord | <ElegantBeef> `thingy.namespace::procedure` is a viable way of keeping it but it's hideous |
| 05:11:03 | FromDiscord | <Rika> and it can prolly be confusing |
| 05:11:24 | FromDiscord | <ElegantBeef> Namespaces arent overly needed since you can control import/export |
| 05:11:25 | FromDiscord | <Anonymous Poet> what if there was a `{. namespaces: "std, my_proj" .}` pragma |
| 05:11:30 | disruptek | throw some emojis in there. |
| 05:11:33 | FromDiscord | <Anonymous Poet> thats a fair point |
| 05:11:49 | FromDiscord | <Anonymous Poet> (edit) "`{." => "`{.push" |
| 05:11:50 | FromDiscord | <ElegantBeef> Opengl here? |
| 05:12:01 | disruptek | who said opengl here? |
| 05:12:03 | FromDiscord | <Rika> i still dont see the need for namespaces |
| 05:12:14 | disruptek | rika: we're talking about opengl here. |
| 05:12:26 | FromDiscord | <ElegantBeef> It just replicates `import module/[a, b, c]; export a, b, c |
| 05:12:26 | FromDiscord | <Rika> lol |
| 05:12:28 | FromDiscord | <ElegantBeef> (edit) "c" => "c`" |
| 05:12:47 | FromDiscord | <Rika> im hella confused now |
| 05:12:57 | FromDiscord | <Anonymous Poet> i think were still on namespaces |
| 05:13:01 | FromDiscord | <ElegantBeef> Saem, Disruptek, and I have an on going joke |
| 05:13:19 | FromDiscord | <ElegantBeef> So half is unrelated said joke, and other half is namespaces |
| 05:13:37 | FromDiscord | <ElegantBeef> Search opengl here and you'll find the origins |
| 05:13:51 | disruptek | what about opengl here? |
| 05:13:55 | FromDiscord | <Rika> oh so its an obscure joke |
| 05:13:57 | FromDiscord | <Rika> got it |
| 05:13:59 | saem | it's here, isn't it? |
| 05:14:02 | saem | opengl |
| 05:14:09 | disruptek | yes, opengl? it's here. |
| 05:14:10 | FromDiscord | <ElegantBeef> Yea it's there ^ |
| 05:14:27 | FromDiscord | <ElegantBeef> Anyway namespaces |
| 05:14:49 | FromDiscord | <ElegantBeef> !repo constructor |
| 05:14:50 | disbot | https://github.com/beef331/constructor -- 9constructor: 11Nim macros to aid in object construction including event programming, and constructors. 15 4⭐ 0🍴 7& 2 more... |
| 05:14:59 | FromDiscord | <ElegantBeef> That does something that replicates namespaces |
| 05:15:19 | FromDiscord | <Rika> when will nim have a better convention for initialize procs other than "put the type name on the proc name"..... |
| 05:15:20 | FromDiscord | <ElegantBeef> you can `import constructor` or `import constructor/construct` for specifiy modules |
| 05:15:22 | * | adnan338 quit (Quit: adnan338) |
| 05:15:53 | disruptek | you can init Foo or new Foo or Foo(). what more do you want? |
| 05:16:35 | FromDiscord | <Anonymous Poet> i guess its interesting that ive used a lot of python recently and i havent felt the need for namespaces there, but its strange to me to write c++ without them |
| 05:16:46 | disruptek | well, |
| 05:16:49 | leorize | luckily you're not writing c++ |
| 05:16:50 | FromDiscord | <Rika> well this aint python nor c++ |
| 05:16:50 | disruptek | ~ninp |
| 05:16:51 | disbot | ninp: 11nim is not python!! |
| 05:16:51 | FromDiscord | <ElegantBeef> Well good thing you arent writting C++ 😄 |
| 05:16:57 | FromDiscord | <Anonymous Poet> rip me |
| 05:17:26 | FromDiscord | <ElegantBeef> Your code might use C++ as an IR, but you clearly are not writing C++ as it isnt traaash |
| 05:17:28 | FromDiscord | <Anonymous Poet> maybe its just a matter of there being just enough control over imports/exports |
| 05:17:44 | disruptek | don't be such a baby. |
| 05:17:51 | FromDiscord | <Anonymous Poet> hm? |
| 05:17:53 | disruptek | this isn't a real problem; it's fud. |
| 05:18:22 | FromDiscord | <Rika> disruptek's a bit abrasive, forgive him xd |
| 05:18:23 | FromDiscord | <Anonymous Poet> i mean, even in python i use explicit imports `from foo import Foo` |
| 05:18:32 | FromDiscord | <ElegantBeef> Sure, but python also doesnt explictly type |
| 05:18:34 | FromDiscord | <Rika> you can do that as well in nim |
| 05:18:51 | disruptek | if you `from foo import Foo` then Foo is unqualified, just as it is in nim. |
| 05:18:51 | FromDiscord | <ElegantBeef> type based overloading isnt a thing when types arent annotated |
| 05:19:00 | * | adnan338 joined #nim |
| 05:19:01 | * | adnan338 quit (Remote host closed the connection) |
| 05:19:16 | FromDiscord | <Anonymous Poet> right, but i dont introduce other symbols into the scope (unexpectedly) |
| 05:19:17 | * | adnan338 joined #nim |
| 05:19:24 | disruptek | neither do we. |
| 05:19:25 | FromDiscord | <Rika> it doesnt matter if you do so |
| 05:19:30 | FromDiscord | <Rika> nim has overloading, python does not |
| 05:19:33 | FromDiscord | <Anonymous Poet> and youve always got `from foo_a import foo as FooA` |
| 05:19:37 | FromDiscord | <ElegantBeef> You import a module, it's knowingly |
| 05:19:44 | FromDiscord | <ElegantBeef> That's just noise |
| 05:19:46 | disruptek | you have that in nim, too, chucklehead. |
| 05:19:49 | leorize | ~imports |
| 05:19:50 | disbot | no footnotes for `imports`. 🙁 |
| 05:19:52 | leorize | ~import |
| 05:19:53 | disbot | no footnotes for `import`. 🙁 |
| 05:19:55 | FromDiscord | <Rika> lol |
| 05:19:56 | FromDiscord | <Anonymous Poet> rip |
| 05:19:57 | disruptek | ~chuckleheads |
| 05:19:57 | disbot | no footnotes for `chuckleheads`. 🙁 |
| 05:20:02 | disruptek | hmm. |
| 05:20:03 | leorize | right, gotta find that post narimiran wrote |
| 05:20:12 | FromDiscord | <Rika> smh disruptek not putting me in that tag smh |
| 05:20:19 | disruptek | ~rika |
| 05:20:19 | disbot | Rika: 11a footnote |
| 05:20:24 | disruptek | lol |
| 05:20:30 | narimiran | ~imports is https://narimiran.github.io/2019/07/01/nim-import.html |
| 05:20:30 | FromDiscord | <flywind> https://narimiran.github.io/2019/07/01/nim-import.html |
| 05:20:31 | disbot | imports: 11https://narimiran.github.io/2019/07/01/nim-import.html |
| 05:20:43 | FromDiscord | <Rika> poet read this 😛 |
| 05:20:44 | narimiran | ~import is https://narimiran.github.io/2019/07/01/nim-import.html |
| 05:20:44 | disbot | import: 11https://narimiran.github.io/2019/07/01/nim-import.html |
| 05:21:29 | disruptek | ~simprot is https://narimiran.github.io/2019/07/01/nim-import.html |
| 05:21:29 | disbot | simprot: 11https://narimiran.github.io/2019/07/01/nim-import.html |
| 05:21:51 | narimiran | are we playing anagram game? |
| 05:22:17 | FromDiscord | <Rika> simp rot |
| 05:22:51 | narimiran | tropism, pro-mist |
| 05:23:38 | FromDiscord | <Rika> protism |
| 05:23:59 | FromDiscord | <Anonymous Poet> that was a nice read |
| 05:24:05 | FromDiscord | <Rika> mropist |
| 05:24:06 | FromDiscord | <Anonymous Poet> didnt know about `except` in imports |
| 05:25:03 | FromDiscord | <Anonymous Poet> the common use case for namespaces in c++, at least as far as what I often hear parroted around, is that you can be 100% sure that there wont be any accidental clashes of function names between your code and any libraries |
| 05:25:17 | FromDiscord | <Anonymous Poet> how does nim address this? |
| 05:25:33 | FromDiscord | <Rika> itll prolly error when you try compiling it |
| 05:25:46 | FromDiscord | <Rika> ambiguous call or smth error |
| 05:25:51 | FromDiscord | <ElegantBeef> Nope |
| 05:26:00 | FromDiscord | <Rika> hm really? |
| 05:26:02 | FromDiscord | <ElegantBeef> Two functions with the same name and parameter types can exist |
| 05:26:08 | FromDiscord | <Anonymous Poet> if it guarantees an error thats ok, im scared of it not doing that |
| 05:26:10 | FromDiscord | <ElegantBeef> Aslong as the parameter names differ it's valid |
| 05:26:15 | FromDiscord | <Anonymous Poet> but using it silently |
| 05:26:22 | FromDiscord | <Rika> OH function name |
| 05:26:25 | FromDiscord | <Rika> i thought funcitons |
| 05:26:30 | FromDiscord | <ElegantBeef> It'll say ambigous call |
| 05:26:45 | FromDiscord | <Rika> yeah if names clash its not ambiguous, nim has overloading |
| 05:26:54 | FromDiscord | <Anonymous Poet> right, so does c++ |
| 05:27:16 | FromDiscord | <Rika> nim will only error out if function name + signature is ambiguous |
| 05:27:22 | FromDiscord | <ElegantBeef> https://play.nim-lang.org/#ix=2LCo |
| 05:27:41 | leorize | well you avoid those stuff like the plague in C++ because C++ people have no idea what the hell is a module |
| 05:27:54 | FromDiscord | <ElegantBeef> C++ 20 has modules 😄 |
| 05:27:56 | FromDiscord | <Anonymous Poet> lets say, for the sake of argument, im writing my own socket implementation |
| 05:27:59 | FromDiscord | <Rika> > 20 |
| 05:28:05 | FromDiscord | <Rika> no fucker is using c++20 |
| 05:28:08 | FromDiscord | <ElegantBeef> I was joking |
| 05:28:28 | FromDiscord | <ElegantBeef> Dont think compilers even support C++ modules yet |
| 05:28:33 | FromDiscord | <Rika> i keep on forgetting everything you say is a joke |
| 05:28:36 | FromDiscord | <teaturtle> ru sure? |
| 05:28:47 | * | u0_a216 joined #nim |
| 05:29:30 | FromDiscord | <Anonymous Poet> so i have my own socket implementation, with an object called `Socket`, but it has maybe different semantics or properties than nim's built-in `Socket`. Someone else writes a socket library that use's nim's built in sockets. A third person consumes both my library, and the other one. What happens? |
| 05:29:41 | FromDiscord | <Anonymous Poet> id expect a compiler error about ambiguous names/types/etc |
| 05:29:46 | leorize | yes |
| 05:29:46 | FromDiscord | <Rika> error since both sockets are ambiguous |
| 05:29:58 | leorize | in Nim each module is a "namespace" |
| 05:30:01 | FromDiscord | <Anonymous Poet> but say that for whatever reason that third person really needed to use both libraries, and couldnt fork them |
| 05:30:04 | FromDiscord | <Anonymous Poet> what should they do? |
| 05:30:09 | FromDiscord | <Rika> they can qualify it |
| 05:30:31 | FromDiscord | <Rika> nim's qualification is possible even when import is unqualified by default |
| 05:30:32 | leorize | nativesockets.Socket vs net.Socket |
| 05:30:33 | FromDiscord | <ElegantBeef> `module.procName` is a valid discriminator |
| 05:30:37 | narimiran | @Anonymous Poet first you say "that was a nice read", and then you ask questions that were answered in the post you allegedly read |
| 05:30:37 | FromDiscord | <Rika> you dont need to force it to enable it |
| 05:30:38 | leorize | it's already a thing in the stdlib btw |
| 05:31:03 | FromDiscord | <Rika> me thinks they skimmed |
| 05:31:22 | FromDiscord | <Anonymous Poet> i swear i read through the whole thing, no skimming |
| 05:31:30 | FromDiscord | <Anonymous Poet> maybe im just tired/thinking in c++ mindset |
| 05:31:34 | * | adnan338 quit (Quit: adnan338) |
| 05:31:43 | FromDiscord | <Rika> maybe its uh |
| 05:31:58 | FromDiscord | <Rika> you're thinking of the same concept but what you read isnt "recognizable" as that concep |
| 05:31:59 | FromDiscord | <Rika> t |
| 05:32:05 | FromDiscord | <Rika> so you dont click them together |
| 05:32:10 | FromDiscord | <Anonymous Poet> but so, if you fully qualify all uses of at least one of the sockets, then you can import both modules plainly? |
| 05:32:19 | saem | maybe it's maybelline |
| 05:32:26 | FromDiscord | <Rika> no i dont think so |
| 05:32:26 | leorize | @Poet you need to qualify both |
| 05:32:30 | FromDiscord | <Rika> you need to qualify both |
| 05:32:31 | FromDiscord | <Rika> yes |
| 05:32:36 | FromDiscord | <ElegantBeef> You can import both and only qualify where you need to either way |
| 05:32:37 | leorize | or you import one of them with `except Socket` |
| 05:32:56 | FromDiscord | <ElegantBeef> Or you can selectively import, or you can qualify one import |
| 05:33:19 | leorize | I'm dealing with this in a library of mine that's reimplementing parts of the stdlib, and it works well afaict |
| 05:33:35 | FromDiscord | <Anonymous Poet> i cant think of any obvious ways to misuse it |
| 05:34:12 | leorize | each Nim module is its own namespace |
| 05:34:26 | FromDiscord | <Anonymous Poet> say theres a custom type `Foo` ... is there any way to finangle the compiler such that you can end up with a `Foo` object without having imported the module where its defined? at least implicitly? |
| 05:35:04 | leorize | yes, you use macro to generate imports to the module that have `Foo` |
| 05:35:17 | leorize | oh wait you would still be making explicit imports then |
| 05:35:21 | FromDiscord | <Anonymous Poet> but the `Foo` type would still be in scope |
| 05:35:24 | FromDiscord | <ElegantBeef> No you cannot |
| 05:35:29 | FromDiscord | <Anonymous Poet> maybe a good concrete example is `options` |
| 05:35:33 | leorize | as in symbol escaping then no, Nim don't have that |
| 05:35:41 | leorize | well we do have `export` |
| 05:35:44 | FromDiscord | <Rika> what about `options`? |
| 05:36:13 | * | u0_a216 quit (Ping timeout: 264 seconds) |
| 05:36:24 | FromDiscord | <Rika> theres a compiler flag to import modules into the file youre compiling as well i believe |
| 05:36:39 | FromDiscord | <ElegantBeef> yes there are `import` and `include` compile flags |
| 05:36:41 | FromDiscord | <Rika> but then thats you putting that there, not the library creator |
| 05:36:51 | FromDiscord | <Rika> so its not implicit |
| 05:36:52 | FromDiscord | <ElegantBeef> But it's still not implicit |
| 05:36:55 | FromDiscord | <ElegantBeef> Damn it |
| 05:36:59 | FromDiscord | <Rika> beef dum dum |
| 05:37:02 | FromDiscord | <Rika> :PPPP |
| 05:37:15 | leorize | well if the library creator put `export` in their library they can introduce symbols from another library into your namespace |
| 05:37:35 | FromDiscord | <Anonymous Poet> so, say I have module `A` that works with options, and module `B` that works on top of module `A`. We'll assume that module `B` compiles. Now say I'm writing module `C`, which directly imports module `B` but not module `A`. Is it possible for a symbol from `A` to be (accidentally) used in `C` if it is not exported by `B`? |
| 05:37:37 | FromDiscord | <ElegantBeef> I still say that's explicit |
| 05:37:38 | leorize | a prime example of this `system`, which imports and exports `system/io` |
| 05:37:41 | FromDiscord | <Rika> yeah but thats still kinda explicit innit |
| 05:37:50 | FromDiscord | <Rika> its even put on the docs |
| 05:37:54 | FromDiscord | <Rika> so id say its explicit |
| 05:38:02 | leorize | @Poet no, that can't happen |
| 05:38:02 | FromDiscord | <Anonymous Poet> (edit) "`A` that works with options," => "`A`," |
| 05:38:06 | FromDiscord | <ElegantBeef> No module B has to export |
| 05:38:09 | FromDiscord | <Rika> accidentally? no |
| 05:38:13 | FromDiscord | <ElegantBeef> If B doesnt export something you do not get it in C |
| 05:38:13 | FromDiscord | <Rika> intentionally? yes |
| 05:38:33 | FromDiscord | <ElegantBeef> `` and `export` are powerful |
| 05:38:36 | FromDiscord | <Anonymous Poet> so `C` needs to either import `A`, or `B` needs to export the relevant symbol from `A` |
| 05:38:40 | FromDiscord | <Rika> yes |
| 05:39:47 | FromDiscord | <Anonymous Poet> then, if there's a collision, that means that either `B` must be exporting the symbol, in which case when you import `B` you can control the name of the symbol in the scope of `C`, OR, `B` does not export the symbol, so `C` needs to import it explicitly from `A`, in which case you can control the name of the symbol in the scope of `C` |
| 05:39:54 | FromDiscord | <Anonymous Poet> and theres no other cases, right? |
| 05:40:26 | FromDiscord | <Rika> maybe an include would be fucky |
| 05:40:41 | leorize | include is, uh, `include` |
| 05:40:45 | leorize | it's in the name :P |
| 05:40:52 | FromDiscord | <Rika> include sounds exactly like how C's include works |
| 05:41:11 | leorize | @Poet yes, that would be the case |
| 05:41:39 | FromDiscord | <Anonymous Poet> TIL about nim's include |
| 05:41:54 | FromDiscord | <Anonymous Poet> gotcha, then if that covers all of the cases, i can see why theres a strong argument for no namespaces |
| 05:42:07 | leorize | you can `import B except A` too iirc, which would avoid A symbols from getting to your namespace even if B is exporting it |
| 05:42:10 | FromDiscord | <Anonymous Poet> you basically cant shoot yourself in the foot |
| 05:42:28 | FromDiscord | <Anonymous Poet> excellent, i strongly believe in idiot-proof design |
| 05:42:45 | disruptek | i don't. |
| 05:42:55 | disruptek | or, rather, i strongly believe in idiots. |
| 05:43:12 | * | u0_a216 joined #nim |
| 05:43:20 | FromDiscord | <Anonymous Poet> do you believe that the power of idiots is always stronger than the power of design? |
| 05:43:24 | FromDiscord | <Rika> i cant believe disruptek believes in me |
| 05:43:37 | FromDiscord | <ElegantBeef> You can attempt to make something idiot proof but then the universe will make a smarter idiot |
| 05:43:39 | disruptek | i say your name, so it must be true. |
| 05:43:57 | disruptek | i'm surrounded by 70,000,000 idiots. |
| 05:44:01 | FromDiscord | <Rika> or an idiot so dumb an underflow happens |
| 05:44:04 | disruptek | it's hard not to believe in them. |
| 05:44:38 | FromDiscord | <iWonderAboutTuatara> can I bring an entire txt file into a multiline string? |
| 05:44:43 | disruptek | yes. |
| 05:44:47 | FromDiscord | <Anonymous Poet> yes |
| 05:44:55 | FromDiscord | <Rika> if you mean copy paste contents into one yeah why not |
| 05:44:56 | FromDiscord | <Anonymous Poet> `staticRead("myfile.txt")` |
| 05:44:58 | FromDiscord | <iWonderAboutTuatara> probably should have asked how |
| 05:45:00 | FromDiscord | <iWonderAboutTuatara> oh thanks |
| 05:45:18 | FromDiscord | <Anonymous Poet> this loads it all at compile time btw |
| 05:45:29 | FromDiscord | <Anonymous Poet> i assume thats what you wanted |
| 05:46:05 | FromDiscord | <iWonderAboutTuatara> also, can I walk through every file in a directory? |
| 05:46:12 | FromDiscord | <Rika> yeah |
| 05:46:15 | leorize | see os.walkDir |
| 05:46:19 | FromDiscord | <Rika> procs for that is in os |
| 05:46:20 | FromDiscord | <Rika> fuck |
| 05:46:25 | FromDiscord | <Rika> damn it leorize |
| 05:46:26 | FromDiscord | <iWonderAboutTuatara> oh walkdir |
| 05:46:27 | FromDiscord | <iWonderAboutTuatara> thanks |
| 05:47:21 | FromDiscord | <Anonymous Poet> hey disruptek, does the irc bridge include discord reaction emojis? |
| 05:47:39 | disruptek | i have no idea. |
| 05:48:03 | FromDiscord | <Anonymous Poet> i just gave your "i have no idea." message a heart - can you see it? |
| 05:48:09 | disruptek | nope. |
| 05:48:35 | FromDiscord | <Anonymous Poet> cool, now we just have to figure out how to communicate only in emojis, and we can ask dumb questions without being roasted 😄 |
| 05:48:45 | disruptek | unlikely. |
| 05:48:55 | FromDiscord | <Anonymous Poet> which part(s)? |
| 05:48:57 | FromDiscord | <ElegantBeef> It also doesnt send the reply system |
| 05:49:12 | FromDiscord | <ElegantBeef> So only inline emojis and normal responses work |
| 05:49:33 | FromDiscord | <Anonymous Poet> oh, good to know about that |
| 05:49:56 | FromDiscord | <Anonymous Poet> what about @ mentions? |
| 05:50:06 | FromDiscord | <Rika> yes |
| 05:50:51 | FromDiscord | <iWonderAboutTuatara> is there a way for me to know the number of files in a dir? |
| 05:51:00 | FromDiscord | <iWonderAboutTuatara> @ mentions work properly across the services yeah |
| 05:51:10 | FromDiscord | <iWonderAboutTuatara> in IRC if you say the person's name it @'s them |
| 05:51:14 | leorize | you iterate through walkDir and count |
| 05:51:25 | FromDiscord | <iWonderAboutTuatara> oh that's unfortunate |
| 05:51:41 | FromDiscord | <iWonderAboutTuatara> ah well, it's all initalization time anyway so speed doesn't matter a whole lot |
| 05:51:42 | FromDiscord | <iWonderAboutTuatara> thanks! |
| 05:52:19 | leorize | any other implementation would still have to do that |
| 05:52:40 | FromDiscord | <Rika> theres no faster way i believe |
| 05:53:01 | leorize | most OS don't expose the number of files afaik, though extended information APIs are sprouting up and might have that info |
| 05:53:53 | leorize | but generally you should never use that number for any purposes |
| 05:53:57 | leorize | due to TOCTOU |
| 05:56:00 | FromDiscord | <Rika> how is toctou usually prevented anyway |
| 05:56:21 | * | qwertfisch quit (Quit: ZNC - http://znc.in) |
| 05:56:31 | leorize | just do it first, handle errors later |
| 05:56:31 | FromDiscord | <ElegantBeef> FOCYOU i think 😄 |
| 05:56:41 | FromDiscord | <iWonderAboutTuatara> oh man |
| 05:56:44 | FromDiscord | <iWonderAboutTuatara> races arae so much fan |
| 05:56:59 | FromDiscord | <iWonderAboutTuatara> love bugfixing due to random races that you weren't expecting at all |
| 05:57:00 | FromDiscord | <iWonderAboutTuatara> great fun |
| 05:57:02 | FromDiscord | <iWonderAboutTuatara> can recommend |
| 05:57:03 | * | qwertfisch joined #nim |
| 05:57:16 | FromDiscord | <Rika> 🏎️ |
| 05:57:17 | leorize[m] | https://github.com/CppCon/CppCon2015/raw/master/Tutorials/Racing%20the%20Filesystem/Racing%20the%20Filesystem%20-%20Niall%20Douglas%20-%20CppCon%202015.pdf |
| 05:57:45 | leorize | ^ that should explains a bit |
| 05:58:04 | leorize | and it's the main reason why I haven't managed to give nim-sys a file system api |
| 05:59:37 | FromDiscord | <iWonderAboutTuatara> glad I don't ahve to do with that |
| 05:59:41 | FromDiscord | <iWonderAboutTuatara> deal |
| 06:01:49 | saem | nim-sys? |
| 06:02:02 | leorize | !repo nim-sys |
| 06:02:02 | disbot | https://github.com/FedericoCeratto/nim-syslog -- 9nim-syslog: 11Nim syslog module 15 16⭐ 5🍴 7& 4 more... |
| 06:02:05 | FromDiscord | <ElegantBeef> Reimpl of io afaik 😄 |
| 06:02:09 | leorize | !repo alaviss/nim-sys |
| 06:02:10 | disbot | https://github.com/alaviss/nim-sys -- 9nim-sys: 11Abstractions for common operating system interfaces 15 1⭐ 0🍴 |
| 06:02:25 | leorize | reimpl of many stdlib components |
| 06:02:29 | FromDiscord | <ElegantBeef> Ah os and io stuffs 😄 |
| 06:02:35 | leorize | focusing on osproc atm |
| 06:03:38 | saem | Cool. Though it's pretty tricky I imagine, not just across platforms, but also a bunch of things really need concurrency to work well. |
| 06:03:52 | disruptek | no shit. |
| 06:05:01 | saem | quiet, you! back to the CPS salt mines. |
| 06:05:16 | disruptek | cps is looking good. |
| 06:05:21 | saem | really is |
| 06:05:23 | * | u0_a216 quit (Read error: Connection reset by peer) |
| 06:05:43 | disruptek | current problem is that i don't see how to do results without my generic hack. |
| 06:06:44 | saem | I need to start reading nim files from the top for imports and types, then bottom up for the rest. |
| 06:06:49 | * | u0_a216 joined #nim |
| 06:07:27 | saem | disruptek: generic hack? that anything to do with keeping the sem info and avoiding copies of nodes and crap you and z were talking about earlier today? |
| 06:08:10 | disruptek | no, the problem is that if all continuations take continuation type C and return type C, then how do you get specific result from a given continuation? |
| 06:08:35 | saem | damn... this morning it was red, now it's green, green is good, unless you're colour blind, but still. |
| 06:08:36 | disruptek | and what does that even look like? |
| 06:09:12 | disruptek | and this is my best effort so far: https://github.com/disruptek/cps/blob/master/experiments/chain.nim |
| 06:09:41 | saem | Ah, so without thinking too hard I'd want C[R] -> C[T]... but then issues, I'm presuming |
| 06:09:47 | disruptek | and when mortals see this it's going to make their little heads spin right off their necks. |
| 06:10:08 | saem | `{.experimental: "dotOperators".}` this can only end well |
| 06:10:26 | disruptek | i think this version doesn't use them. |
| 06:11:15 | disruptek | but look at the bottom. |
| 06:11:38 | saem | don't try to hide five lines down where you sneak in a concept. |
| 06:12:46 | disruptek | we just composed a continuation using "normal" data and an existing "normal" proc. |
| 06:12:48 | * | u0_a216 quit (Read error: Connection reset by peer) |
| 06:13:03 | disruptek | and the type was one that we supplied and impl'd ourselves. |
| 06:13:05 | saem | Oh wow, I didn't realize the whole can just say c.fn is P as some arbitrary type. |
| 06:13:06 | * | u0_a216 joined #nim |
| 06:14:37 | saem | Guess that ends up being an implicit unbound type parameter that a type of that concept must define? |
| 06:14:39 | disruptek | procs have types, yes. |
| 06:15:18 | disruptek | the concept defines it as Pv or Pl, say. |
| 06:15:27 | disruptek | which is Pvar or Plet. |
| 06:16:16 | disruptek | so P[C] is a proc usable against a continuation, either an immutable or mutable continuation. |
| 06:16:54 | disruptek | what we're working on here is `()`(). |
| 06:17:04 | disruptek | the perky-nips operator. |
| 06:17:18 | saem | I'm still not used to types can appear in any order within a type section, keep thing it has be all pre-declared. Got that idea stuck in my head. All makes sense the syntax highlighting had me ignoring P's definition further on. |
| 06:17:41 | disruptek | yeah, that's a nice feature. |
| 06:17:51 | saem | I thought that was the sad balloon operator |
| 06:18:05 | disruptek | it's a little annoying that consts cause you to have to break a type block, but... |
| 06:18:50 | disruptek | it lets us do `let x = continuation()` to reveal the result. |
| 06:18:59 | disruptek | kinda huge. |
| 06:19:06 | disruptek | it's, y'know, what you want. |
| 06:19:16 | disruptek | "run it" |
| 06:19:18 | disruptek | what else? |
| 06:19:36 | * | u0_a216 quit (Ping timeout: 256 seconds) |
| 06:24:47 | saem | OK, enough using github... downloading it locally |
| 06:25:59 | disruptek | what's neat is we can do things like lazy evaluation so elegantly. |
| 06:26:51 | FromDiscord | <mratsim> @disruptek, I already said this multiple times but you do not need to return arbitrary continuations, just return nil or the same continuation type as you were passed |
| 06:27:22 | FromDiscord | <mratsim> to switch to any continuation, you then just store that continuation in a data structure, and pop the one you want |
| 06:27:47 | disruptek | what does that have to do with anything? |
| 06:27:57 | FromDiscord | <mratsim> this emulates stackful coroutine that can switch to any coroutine for example even though our continuations only switch back to the caller |
| 06:28:14 | disruptek | you're telling me i cannot act on an immutable continuation; to me, that's a deal breaker. |
| 06:28:23 | FromDiscord | <mratsim> it has to do with not having to return arbitrary continuation in CPS which significantly ease design and ergonomics |
| 06:28:48 | disruptek | the design is fine and the ergonomics can be solved at higher levels. |
| 06:29:14 | FromDiscord | <mratsim> well last time Ia sked you said that design was what you wanted to nail |
| 06:29:52 | FromDiscord | <mratsim> the 3 primitives I introduce {.resume.}, {.suspend.} and bindCallerContinuation gives you everything you need for continuations at a low-level. |
| 06:30:07 | disruptek | they give /you/ everything /you/ need. |
| 06:30:49 | FromDiscord | <mratsim> create an issue, with a use-case that you think can't be done |
| 06:31:12 | FromDiscord | <mratsim> you can model every control flow with those primitives |
| 06:31:12 | disruptek | what's the point? |
| 06:31:46 | FromDiscord | <mratsim> the point is to have low-level primitives that compose well and can be explained and grasped easily by people. |
| 06:31:57 | saem | huh, lots of ioFailures around rod files, weird... I wonder if that's due to the funny things my branch is doing. |
| 06:32:03 | disruptek | abstractions are made to be written. |
| 06:32:08 | disruptek | saem: nope. |
| 06:32:19 | FromDiscord | <mratsim> this function suspends the caller, this function can resume, and this allows you to store the continuation |
| 06:32:36 | FromDiscord | <mratsim> this is 100% what the continuations need |
| 06:32:41 | FromDiscord | <mattrb> sent a code paste, see https://play.nim-lang.org/#ix=2LCy |
| 06:32:53 | FromDiscord | <mratsim> that's because in the VM everything is runtime |
| 06:33:07 | FromDiscord | <mratsim> so use plain i |
| 06:33:20 | FromDiscord | <mratsim> VM runtime is rest of the code compile-time |
| 06:33:27 | FromDiscord | <Rika> static: for i in... then remove the static() |
| 06:33:45 | disruptek | it's already static; it's a const. |
| 06:33:45 | FromDiscord | <mratsim> ah right |
| 06:33:53 | FromDiscord | <Rika> oh i didnt see that lol |
| 06:33:55 | FromDiscord | <mratsim> block: static: would work |
| 06:33:59 | FromDiscord | <flywind> known issue I think https://github.com/nim-lang/Nim/issues/12172 |
| 06:33:59 | FromDiscord | <mratsim> actually |
| 06:34:01 | disbot | ➥ Error in const block inside proc ; snippet at 12https://play.nim-lang.org/#ix=2Itw |
| 06:34:48 | FromDiscord | <mattrb> Does that work here, or am I missing something? |
| 06:34:58 | FromDiscord | <mratsim> it works here, but you don't need it |
| 06:35:07 | FromDiscord | <mratsim> in a const block everything is in the VM |
| 06:35:21 | FromDiscord | <mattrb> In the example mratsim was helping me look at earlier, the limitation to the approach I wanted seemed to be that `i` wasn't static |
| 06:35:24 | * | adnan338 joined #nim |
| 06:35:24 | FromDiscord | <mratsim> if you want your staticI you need to implement a staticFor that unrolls i at runtime |
| 06:35:27 | * | adnan338 quit (Client Quit) |
| 06:35:36 | * | adnan338 joined #nim |
| 06:36:02 | FromDiscord | <mratsim> there was no technical limitation (maybe ergonomic), macro are in the VM so everything xwas resolved at compile-time |
| 06:36:35 | FromDiscord | <mratsim> sent a code paste, see https://paste.rs/k8J |
| 06:37:31 | FromDiscord | <mattrb> Sure yeah, not trying to imply any technical limitation. I'm sure it's _possible_, but they way that was suggested didn't really reduce the code is all I meant. I'll take a look at staticFor! |
| 06:40:42 | FromDiscord | <mratsim> The code in the proc generated removed the if branches from the proc and inlined only the part of the code that needed to be run at runtime AFAIK |
| 06:40:51 | saem | I wonder if it's a matter of perspective, whether you have a specific continuation and you're chaining that along (more from the outside) vs you got a pile of them and you're trying to figure out what to do next (more from the inside). I can see how suspend, resume, bind, where the type information would be lost (no longer static). |
| 06:42:17 | FromDiscord | <mattrb> This one required duplicating the logic for branchImpl. That proc will end up being something longer, and there will be more args to generate it than just `i`, so I don't think this approach is super extensible to that use-case, unfortunately |
| 06:43:00 | saem | s/where the/is where the |
| 06:43:12 | FromDiscord | <mattrb> This seems like it would require writing a different version of `branchImpl` for each use-case anyway, which is what I'm trying to avoid |
| 06:43:18 | FromDiscord | <mratsim> the type part is orthogonal to the uses and design |
| 06:43:54 | disruptek | i don't agree. |
| 06:44:07 | disruptek | if that were the case, you wouldn't care so much about the type. |
| 06:44:41 | disruptek | feel free to add your thoughts to https://github.com/disruptek/cps/discussions/40 as i have. |
| 06:44:42 | FromDiscord | <mratsim> look at the staticFor code I linked, create your proc and apply "replaceNodes" to replace the instances of i by the static values of i |
| 06:44:56 | * | Zevv quit (Ping timeout: 240 seconds) |
| 06:45:25 | disruptek | saem: composition is everything, basically. |
| 06:45:26 | FromDiscord | <mratsim> I assume when saem talks about type information, he meant Nim type system |
| 06:45:56 | saem | Yes, that's what I mean... I mean you're using concepts so you're in the Nim type system. |
| 06:47:13 | FromDiscord | <mratsim> @disruptek, you talk about thoughts but the only thing you replied to my point is "so what" |
| 06:48:11 | disruptek | well, if you don't want to answer my questions, i will settle for my assumptions. |
| 06:48:54 | FromDiscord | <mratsim> I give you concrete ways to emulate arbitrary return types even if we constrain ourselves in the CPS transform to returning the same continuation type we were passed. |
| 06:49:15 | disruptek | you didn't back up your assertions and some of them are flat out wrong. |
| 06:49:29 | disruptek | what makes you think i believe any of the assertions i cannot immediately disprove? |
| 06:49:41 | disruptek | there's nothing to talk about. |
| 06:49:51 | FromDiscord | <mratsim> so much for a discussion |
| 06:51:37 | disruptek | we currently constrain ourselves in the CPS transform to returning the same continuation type we were passed. i don't need to emulate returning arbitrary types; i already have that. |
| 06:51:59 | FromDiscord | <mratsim> That constraint is not a problem |
| 06:52:07 | FromDiscord | <mratsim> it simplifies the backend, codegen and types |
| 06:52:34 | disruptek | so what? |
| 06:52:39 | FromDiscord | <mratsim> at the scheduler level, those that needs to switch to arbitrary continuations, they just need type erasure |
| 06:52:51 | disruptek | are you so insecure about what you know that you cannot defend any of it? |
| 06:53:12 | disruptek | i asked you to port your type erasure over and you refused. |
| 06:53:18 | disruptek | what more do you want from me? |
| 06:53:26 | disruptek | fork the code and do what you want. it's free. |
| 06:53:43 | FromDiscord | <mratsim> listen, I'm here for technical discussion, you want to attack me personally. Just stop |
| 06:53:51 | disruptek | there's nothing personal about it. |
| 06:54:00 | disruptek | you refuse to answer my questions or back up your assertions. |
| 06:54:02 | FromDiscord | <mratsim> "are you so insecure"? |
| 06:54:12 | disruptek | well, you tell me what the reason is, then. |
| 06:54:27 | FromDiscord | <mratsim> 2 weeks ago you and zevv said that one of the main blocker was ergonomics. |
| 06:54:31 | disruptek | all i can do is assume. |
| 06:55:01 | FromDiscord | <mratsim> We explored type erasure, I said that we can have ref based for ref and JS and union-based for C/C++. |
| 06:55:31 | FromDiscord | <mratsim> This would suit our use-cases, both ergonomic and no GC |
| 06:56:03 | FromDiscord | <mratsim> There are PoC with those, those can be macro-ified, sure but I thought it was more important to then tackle ergonomics |
| 06:56:04 | disruptek | the chain demo was written 5mos ago. i think it's pretty ergonomic, but we can go further. ergonomics are only a blocker because we aren't sure how far to go. |
| 06:56:15 | FromDiscord | <mratsim> what do we show to our users. |
| 06:56:23 | disruptek | whatever we want. |
| 06:56:35 | disruptek | no one, and i mean no one, has commented on the rfc wrt syntax. |
| 06:56:37 | disruptek | not |
| 06:56:37 | disruptek | one |
| 06:56:38 | disruptek | person |
| 06:56:39 | FromDiscord | <mratsim> that's why I focused on those suspend, resume and bindCallerContinuation primitives |
| 06:56:43 | disruptek | no one gives a single fuck. |
| 06:56:55 | disruptek | okay, you're the only person. |
| 06:57:06 | disruptek | my mistake. |
| 06:57:10 | FromDiscord | <mratsim> well I give, and I have been writing and refining research and 2 design documents |
| 06:57:18 | FromDiscord | <mratsim> restarting when I reached a dead-end |
| 06:57:26 | FromDiscord | <mratsim> i;e. pure coroutines without continuations |
| 06:57:39 | FromDiscord | <mratsim> because I wanted to explore the alternatives as well |
| 06:58:06 | FromDiscord | <mratsim> and contrary to what you seem to think I care a lot about ergonomics |
| 06:58:20 | disruptek | i never said you don't care about ergonomics. |
| 06:58:31 | FromDiscord | <mratsim> my examples that required unsafeAddr in Weave are because of Nim limitations |
| 06:58:54 | FromDiscord | <mratsim> you need ptr to modify a var, because you can't capture them in a closure |
| 06:59:26 | FromDiscord | <mratsim> what can I do. I don't want to spend 2 weeks trying to come up with a clever liftLocals because I don't have a solution builtin |
| 06:59:38 | disruptek | you don't have to. |
| 06:59:46 | disruptek | i'm the one who is unemployed, here. |
| 07:02:44 | disruptek | i will produce some immutable iterator tests. you can ensure they continue to pass. |
| 07:04:08 | disruptek | i really only care about the very lowest level of cps. i'm confident we can build whatever abstraction we want on top of it. |
| 07:04:18 | disruptek | i don't care how hard that is for other people to comprehend; no one else needs to understand it. |
| 07:05:23 | FromDiscord | <Varriount> What if you get hit by a bus? |
| 07:05:49 | FromDiscord | <Varriount> Also, which RFC? |
| 07:06:27 | FromDiscord | <mratsim> The really low-level is really the CPS transformation into continuation.↵A proc doesn't change return types in the middle of a call.↵I'm fine with continuations not changing return type. |
| 07:08:31 | FromDiscord | <mratsim> Basically the CPS low-level would provide: CPS transformation of typed proc into series of typed continuations. Type-erasure facilities. API for suspend, resume, store. |
| 07:09:15 | disruptek | disbot: am i lagging or is it you? |
| 07:09:15 | disbot | signs point to yes. |
| 07:09:20 | FromDiscord | <mratsim> Then, nice to have would be hooks for custom logging/stackframes |
| 07:09:26 | disruptek | yes what |
| 07:09:53 | disruptek | !rfc cps |
| 07:09:55 | disbot | https://github.com/nim-lang/RFCs/issues/295 -- 3next steps for CPS 7& 4 more... |
| 07:11:02 | disruptek | anyway, anyone that doesn't grok the lowest level of cps can use the next level. |
| 07:11:20 | disruptek | if they aren't bright enough or are lazy, they can use the level after that. |
| 07:11:39 | disruptek | rika can use the level after that. |
| 07:11:39 | disruptek | and beef, i dunno, maybe he'll be satisfied with async/await. |
| 07:11:43 | FromDiscord | <mratsim> which is why I separated into core and scheduler folders in the repo |
| 07:12:05 | FromDiscord | <mratsim> if you put everything in the same folder it makes it appear more complicated than it really is |
| 07:12:37 | disruptek | we plan to move the scheduler(s) out to their own libraries. |
| 07:13:11 | disruptek | they are only in the repo because i wanted some way to compare performance to async/await for similar operations. |
| 07:13:13 | FromDiscord | <mratsim> yes, but people who read the RFC might think, how, it comes with a scheduler, why, I have mine, or that's too much overhead |
| 07:13:42 | FromDiscord | <Avatarfighter> LMAO BEEF SLANDER |
| 07:14:04 | disruptek | feel free to PR a change to the README. |
| 07:14:04 | disruptek | i don't know how to make it much more clear; i say over and over that it's optional, included, example, etc. |
| 07:14:04 | disruptek | we can have some links to external schedulers. |
| 07:14:30 | disruptek | but, really, people should write their own schedulers. we will give them the tools to do it, if we have to. |
| 07:15:02 | FromDiscord | <ElegantBeef> I dont use async so .... 😄 |
| 07:15:09 | disruptek | see. |
| 07:15:16 | disruptek | satisfied. |
| 07:15:26 | disruptek | look, cps is simple. |
| 07:15:32 | disruptek | it's so simple that you won't believe it. |
| 07:16:15 | saem | The Kotlin talk is really fantastic. |
| 07:16:15 | FromDiscord | <Avatarfighter> i do think that some handholding should be given for cps for less experienced people who want to dabble with cps at a certain level. Just my thought separate from what you guys were talking about. |
| 07:16:17 | disruptek | the hard part is only rewriting nim that's not already cps. |
| 07:16:23 | FromDiscord | <mratsim> I agree, people should write their own scheduler, and it makes the dealing with the "how" 3 lines of code, and only "what to schedule" is left |
| 07:16:47 | disruptek | yes. |
| 07:16:57 | disruptek | but once the rewrite is working, we can make even the rewrite simple. |
| 07:16:59 | FromDiscord | <mratsim> that's not the hard part, that's the tedious part. |
| 07:17:03 | disruptek | and the cps code in the wild won't change. |
| 07:17:10 | disruptek | unless it gets faster. |
| 07:17:14 | FromDiscord | <mratsim> but the stdlib needs an overhaul anyway |
| 07:17:30 | disruptek | and everyone will just write normal nim anyway; it'll just run as cps. |
| 07:17:35 | disruptek | nothing to know. |
| 07:17:45 | disruptek | simple. |
| 07:18:47 | disruptek | fighter: we will do a lot of coaching, i'm sure. |
| 07:19:05 | disruptek | but again, you're not going to need to know anything, really. |
| 07:19:18 | disruptek | that's the whole point: we take the code you wrote and we make it async for you. |
| 07:19:27 | FromDiscord | <mratsim> CPS is not suitable for every use case, we will need flavours.↵For example sequtils/strutils will likely have a CPS flavor for composition (ala Python iterutils), and pure in-place algorithm when you need raw speed, and you compose them via `dup` (which does multiple pass over the data, it only solves ergonomic composition) |
| 07:19:30 | FromDiscord | <Avatarfighter> disruptek: yeah i'm really liking my runs with cps rn I just know that some people might not be as excited to learn |
| 07:19:52 | disruptek | those people can kiss my furry ass. |
| 07:20:01 | FromDiscord | <Avatarfighter> @ElegantBeef |
| 07:20:08 | saem | lucky |
| 07:20:09 | disruptek | you gon' learn, son. |
| 07:20:13 | FromDiscord | <ElegantBeef> What? |
| 07:20:20 | FromDiscord | <Avatarfighter> you may kiss 😛 |
| 07:20:24 | FromDiscord | <ElegantBeef> Kiss what? |
| 07:20:32 | FromDiscord | <Avatarfighter> read above my ping |
| 07:21:15 | FromDiscord | <ElegantBeef> Why am i being targetted? |
| 07:21:32 | FromGitter | <gogolxdong> Is there a web framework supports route injection? |
| 07:21:34 | disruptek | i can't remember the names of all the nimlets. |
| 07:21:34 | FromDiscord | <Avatarfighter> im just teasing, I made a bad joke. My apologies ElegantBeef I didn't mean any harm. |
| 07:21:45 | FromDiscord | <Avatarfighter> nimlets |
| 07:21:48 | FromDiscord | <Avatarfighter> ahah |
| 07:22:30 | FromDiscord | <ElegantBeef> All harm felt |
| 07:22:54 | FromDiscord | <Avatarfighter> 😭 |
| 07:23:10 | FromDiscord | <mratsim> He has a beef with your remark |
| 07:23:15 | disruptek | i lost a pound of raw meat tonight. |
| 07:23:16 | FromDiscord | <Avatarfighter> I know |
| 07:23:31 | FromDiscord | <Avatarfighter> I don't know what's worse though, being called a nimlet or beef's beef |
| 07:23:31 | saem | it's always the last place you look. |
| 07:23:35 | disruptek | not that pound, this was supposed to be dinner. |
| 07:23:48 | disruptek | i have no idea where it fucked off to. |
| 07:23:57 | disruptek | i saw it this afternoon, and this evening, poof. |
| 07:23:58 | disruptek | gone. |
| 07:25:15 | saem | is the CPS library meant to do anything in terms of "operator fusing"? I'm thinking of the streaming/itertools/sequtils case. |
| 07:25:34 | disruptek | nope. |
| 07:26:02 | saem | or is another extension point the rewriting part, so some folks write dispatchers, others write "rewriters"? |
| 07:26:46 | saem | or is the intention to have that sort of thing be orthogonal? |
| 07:27:00 | disruptek | i doubt we will need rewriters. we will need a lot of dispatch, though. |
| 07:27:24 | FromDiscord | <Varriount> Is there any syntax to CPS aside from the macro? Or is it essentially implicit that certain procedures get passed the continuation object? |
| 07:27:31 | disruptek | like, i fully expect that we'll provide some tools for dispatchers and you'll bring your own and have maybe hundreds of different dispatchers in a modest project. |
| 07:28:14 | disruptek | varriount: we create the procs that take the continuation object, so, no; ideally, there's no real syntax. |
| 07:29:03 | disruptek | you can look at the tests to see what that looks like. |
| 07:29:07 | FromDiscord | <Varriount> Sounds like what gevent/eventlet do. |
| 07:29:17 | saem | oh so the dispatcher when "fusing" operations, would simply sequentially call all the operations per item, that's the "fusing", so you're no longer running over the same thing over and over again. |
| 07:29:25 | disruptek | those are heavier. |
| 07:29:44 | disruptek | saem: exactly. |
| 07:30:02 | disruptek | you would compose the function and sink it into a continuation to do the operation. |
| 07:31:19 | saem | then the compiler _should_ be able to do the rest of the optimization on what are ideally pure funcs and can merge/inline those into the least amount of stack frames. |
| 07:31:52 | FromDiscord | <Varriount> Would the final implementation of CPS support all Nim code, or is it only possible to support a subset? |
| 07:33:29 | disruptek | saem: we would probably do that in rewrite, but yes. |
| 07:33:32 | FromDiscord | <Varriount> And how will CPS interact with JavaScript compilation and promises? |
| 07:33:56 | disruptek | varriount: it's an open question as far as which parts we cannot support. we target js. |
| 07:34:19 | disruptek | so, like, we're not sure about supporting mutation of calling params. |
| 07:34:43 | disruptek | once you're inside your proc-that-has-the-cps-pragma, you can mutate all you want. you can mutate globals or other shit in scope. |
| 07:34:53 | disruptek | but the params passed to the proc? i dunno. |
| 07:35:36 | disruptek | we have a test for it and an open issue but it's currently not impl'd. |
| 07:35:39 | FromDiscord | <Varriount> But aside from parameters, any other constructs? |
| 07:36:07 | FromDiscord | <mratsim> > is the CPS library meant to do anything in terms of "operator fusing"? I'm thinking of the streaming/itertools/sequtils case↵I don't agree, you can reimplement all of those in CPS and they compose well and can be async |
| 07:36:16 | FromDiscord | <Varriount> Blocks, for loops, case statements, etc |
| 07:36:20 | disruptek | pretty much. we can probably come up with stuff that'd be hard, but yeah, pretty much anything. |
| 07:36:23 | FromDiscord | <mratsim> @saem |
| 07:36:52 | saem | mratsim: I know, but there is CPS and then there is CPS as implemented in Nim (whenever that's final |
| 07:36:54 | saem | ) |
| 07:36:55 | disruptek | yeah, he gets it. |
| 07:37:05 | * | PMunch joined #nim |
| 07:37:19 | FromDiscord | <mratsim> I think try/except might be tricky, Swift disables suspending within try except, but they use coroutines, try/except can be modeled as CPS so we can overcome that |
| 07:37:47 | disruptek | we already have a try/except impl, both one based on CPS only and one that uses native exceptions. |
| 07:38:23 | FromDiscord | <mratsim> well given that closure iterators are pretty broken with try/finally and defer that's a good argument to replace them |
| 07:38:35 | FromDiscord | <mratsim> it's like the number one issue we have in Chronos |
| 07:38:40 | disruptek | saem: the cps macro probably wouldn't do your fusing for you, but it doesn't have to. |
| 07:39:12 | disruptek | mratsim: we will likely reimpl defer, try/finally, and closure iterators in cps, so... 😉 |
| 07:39:30 | FromDiscord | <mratsim> I already reimplemented closure iterators 😉 |
| 07:39:46 | FromDiscord | <mratsim> coro cover all use-cases of closure iterators. |
| 07:39:54 | disruptek | the compiler version? |
| 07:39:59 | FromDiscord | <mratsim> I just need some nice syntax to create anonymous coroutine |
| 07:40:09 | FromDiscord | <mratsim> well no, it's "as a library" |
| 07:40:13 | FromDiscord | <Varriount> coro? |
| 07:40:14 | saem | disruptek: yeah, I was more asking in the direction of you have folks who use CPS and don't care, folks who write dispatchers because their program has needs, then there are those that write dispatchers for very general cases like libraries, then there are CPS impl authors. Dispatchers are an existing extension point, was wondering if rewriters were one too. |
| 07:40:21 | saem | disruptek: but my question is answered |
| 07:40:22 | disruptek | oh, i mean we will rewrite `fo` and stuff. |
| 07:40:28 | disruptek | oh, i mean we will rewrite `for` and stuff. |
| 07:40:40 | FromDiscord | <mratsim> @Varriount https://github.com/disruptek/cps/blob/mratsim-public-api-proposal/mratsim/ex06_coroutines.nim#L8-L12 |
| 07:41:03 | FromDiscord | <mratsim> @saem, disruptek, Zevv and I have very different needs in terms of dispatchers |
| 07:41:42 | FromDiscord | <mratsim> look at the bottom of this section: https://github.com/weavers-guild/weave-io/blob/master/design/design_2_continuations.md#motivation |
| 07:41:58 | saem | mratsim one thing I noticed is regardless of a fn's return type, if it has an effect like raise, then one way to reason about it is that it has two return types, one being the error case. Presently, the code I've seen so far in the CPS impl is one return type whether that's C or C[R] (the immutable kind), regardless it seems the raise needs to account for both paths... or exceptions being another branch/flow. |
| 07:42:22 | disruptek | saem: so there's an extension point that we call "cpsMagic" that are procs that know about continuations but aren't really rewritten. |
| 07:42:23 | FromDiscord | <mratsim> we can make the dispatcher only care about what to schedule and when, all the "closure" and saving/restoring variable will be taken care of by CPS |
| 07:42:24 | saem | mratsim going back to the limitations you mention in swift being in the same vein. |
| 07:42:30 | FromDiscord | <Varriount> I'm curious though, how does CPS handle intermediate leaf functions pausing the continuation? |
| 07:43:03 | FromDiscord | <Varriount> CPS -> somerandomfunc -> sleep |
| 07:43:06 | FromDiscord | <mratsim> @saem we can reattach the effect (provided Nim compilers gives us hooks) |
| 07:43:17 | FromDiscord | <Varriount> (edit) "CPS" => "Continuation" |
| 07:43:18 | disruptek | if a leaf node falls into a dispatcher, there it sits until the dispatcher awakens it. |
| 07:43:47 | FromDiscord | <mratsim> sleep as a CPS version of sleep or some blocking calls that CPS doesn't know about? |
| 07:44:29 | FromDiscord | <Varriount> But the continuation state has to be associated with the function, doesn't it? And somerandomfunction may not be marked with the cps macro. |
| 07:44:48 | FromDiscord | <mratsim> if it uses CPS code it is marked with CPS tag |
| 07:45:02 | FromDiscord | <Varriount> Sleep as a CPS procedure. |
| 07:45:05 | disruptek | he's talking about function color. |
| 07:45:23 | FromDiscord | <Varriount> What if I pass a closure that calls sleep? |
| 07:45:24 | disruptek | my plan is to sniff that stuff at compile-time. |
| 07:45:44 | disruptek | then it will have effects. |
| 07:45:48 | FromDiscord | <mratsim> the closure suspends and the whole thing goes into your scheduler |
| 07:45:56 | FromDiscord | <mratsim> or anywhere you store the continuation |
| 07:47:14 | FromDiscord | <Varriount> I take it all of the continuation state will need to be allocated on the heap? |
| 07:47:27 | disruptek | saem: cpsMagic lets you play your fusion games without writing any compile-time code, so i think that's a fair solution. we're not fully committed to the concept yet, either. |
| 07:47:42 | disruptek | varriount: not really. |
| 07:47:47 | FromDiscord | <mratsim> it doesn't need to if suspend/resume are always in the same scope. But if you use a scheduler that can resume from anywhere yes |
| 07:47:59 | disruptek | saem: but tell me more about how the rewrite could hook in. |
| 07:48:05 | saem | disruptek: I'm reading the macro now -- simultaneously I'm wondering about the raise parts and cancellation not being explicit. |
| 07:48:18 | FromDiscord | <mratsim> cancellation just means drop the continuation |
| 07:48:28 | FromDiscord | <mratsim> if you don't continue it's cancelled |
| 07:48:36 | disruptek | the raise parts will probably go into the erasure. |
| 07:48:39 | saem | No, it's not proceeded, which is different. |
| 07:48:48 | saem | The effect is the same, but they're not the same. |
| 07:48:55 | FromDiscord | <mratsim> if there are resource to release, you need to use a channel |
| 07:49:10 | FromDiscord | <mratsim> just liek goroutines |
| 07:49:19 | * | u0_a216 joined #nim |
| 07:49:30 | FromDiscord | <Varriount> I'm still doubtful about the performance of final implementation, if the language isn't fairly restricted, but this seems to be working out. |
| 07:49:32 | disruptek | if your continuation is destroyed, that's your explicit cancellation event. |
| 07:49:46 | FromDiscord | <Varriount> (edit) "I'm still doubtful about the performance of ... final" added "the" |
| 07:50:18 | FromDiscord | <mratsim> I hope to make it very efficient |
| 07:50:41 | disruptek | the performance will be roughly the same as closure iterators, since it's basically the same idea; they can compile to a fsm on the stack. |
| 07:50:49 | FromDiscord | <mratsim> we might be able to use LLVM builtins even. |
| 07:51:01 | FromDiscord | <mratsim> closure iterators can use the stack? |
| 07:51:16 | disruptek | currently, we are a little slower than the earlier impl. 😢 |
| 07:51:17 | FromDiscord | <Varriount> Well, they could |
| 07:51:17 | saem | disruptek: does that not rely on the memory management behaviour, in which case the event can arrive at a non-deterministic time later? |
| 07:51:36 | FromDiscord | <mratsim> arc is deterministic |
| 07:51:41 | disruptek | ^ |
| 07:51:42 | FromDiscord | <mratsim> CPS was built with arc |
| 07:51:58 | FromDiscord | <Varriount> The implementation doesn't allow it, but closure iterators could stored on the stack |
| 07:52:04 | FromDiscord | <mratsim> and you can manually memory managed continuations |
| 07:52:11 | saem | I knew CPS was meant to work with it, didn't realize it was mandatory. |
| 07:52:18 | disruptek | it's not. |
| 07:52:20 | FromDiscord | <mratsim> it's not mandatory |
| 07:52:35 | FromDiscord | <mratsim> but other GC is undefined behavior 😉 |
| 07:53:28 | * | u0_a216 quit (Ping timeout: 246 seconds) |
| 07:53:28 | disruptek | the first test i did, we were within 10-15% of closure iterators. |
| 07:53:38 | FromDiscord | <mratsim> regarding stack vs heap, I asked Araq for "heap allocation elision" |
| 07:53:46 | FromDiscord | <Varriount> (edit) I'm still doubtful about the performance of a final implementation that allows mostly unrestricted Nim code, but this seems to be working out. |
| 07:53:59 | FromDiscord | <mratsim> , right now the bottleneck of CPS I would say, is that the transformation is too eager |
| 07:54:18 | FromDiscord | <mratsim> we transform all control flow to CPS even though they don't involve a suspending branch |
| 07:54:23 | disruptek | yeah, it's optimized for correctness. 😁 |
| 07:54:45 | saem | Hmm, I'm wondering if non-explicit cancellation might act as an optimisation fence in some cases -- need to think through more streaming cases, which is what I'm mostly thinking for right now. |
| 07:54:46 | FromDiscord | <mratsim> there is also a benchmark to do between functionc alls/callbacks v state machines |
| 07:55:31 | FromDiscord | <mratsim> @saem: Rust "poll-based" "demande-based" async/await is a lot about making cancellation just dropping the future |
| 07:55:34 | disruptek | saem: it's what you want. it lets you control the behavior. |
| 07:56:18 | FromDiscord | <mratsim> CPS is really about: adding to normal function the capability to suspend themselves and be resumed from that point. |
| 07:57:17 | FromDiscord | <mratsim> or another way to look at it is "unindented callbacks" |
| 07:57:56 | saem | Yeah, I get that. But when you want to do some really fun stuff for streaming, then we're talking about operation fusion and micro-batching. The amount of explicit information available is often (purely intuition here) the limitation in terms of what one can and cannot do. |
| 07:59:13 | FromDiscord | <apollo> hello worl |
| 07:59:15 | FromDiscord | <apollo> (edit) "worl" => "world" |
| 07:59:45 | disruptek | saem: so impl your explicit cancel() {.cpsMagic.} |
| 07:59:53 | disruptek | whatever, dude. 😉 |
| 08:00:17 | saem | I need to finish reading it -- actually I should sleep early morning, blech |
| 08:00:29 | disruptek | yeah. |
| 08:00:41 | FromDiscord | <apollo> where can i post issues that i have? |
| 08:01:15 | saem | github if they're bugs, questions on stackoverflow, the forums, or here. |
| 08:01:47 | FromDiscord | <apollo> so im getting this issue "not all cases are covered" |
| 08:02:05 | FromDiscord | <apollo> im following the nim tutorial on the website |
| 08:02:12 | saem | I'm assuming they're nim related and if they're not, then no matter what disruptek says, he's not a doctor. |
| 08:02:31 | FromDiscord | <apollo> what? |
| 08:02:52 | narimiran | @apollo post your code on https://play.nim-lang.org and share a link with us |
| 08:02:53 | FromDiscord | <ElegantBeef> Post the code |
| 08:03:01 | FromDiscord | <apollo> okay |
| 08:03:15 | saem | you have a case statement I presume and you're not account for all cases. if it's an enum cover all variants, if the type has a big range, like string/int/etc... use an else branch... but without code I'm just guessing. |
| 08:03:16 | FromDiscord | <ElegantBeef> you probably dont have a `else: discard` for your case statement |
| 08:03:17 | FromDiscord | <apollo> the code is rather small |
| 08:03:18 | disruptek | case statements need exhaustive clauses. |
| 08:03:22 | FromDiscord | <apollo> i can post it here |
| 08:03:25 | narimiran | and send us the link to the faulty tutorial example |
| 08:03:33 | saem | No, use the playground, please. |
| 08:03:38 | disruptek | ~paste |
| 08:03:39 | disbot | paste: 11a frowned-upon behavior in chat; please use a service such as https://play.nim-lang.org/ or http://ix.io/ or https://gist.github.com/ and supply us a URL instead. -- disruptek |
| 08:03:42 | FromDiscord | <apollo> sent a code paste, see https://play.nim-lang.org/#ix=2LCR |
| 08:03:43 | FromDiscord | <ElegantBeef> Posting here pushes to the playground |
| 08:03:51 | disruptek | but, y'know, i'm not a doctor. i'm just good with my hands. |
| 08:03:52 | FromDiscord | <ElegantBeef> yea you lack an `else:` |
| 08:03:53 | FromDiscord | <apollo> oh okay my bad sorry |
| 08:04:03 | FromDiscord | <apollo> so an else is always necessary for this |
| 08:04:05 | FromDiscord | <ElegantBeef> yes |
| 08:04:10 | FromDiscord | <ElegantBeef> `else: discard` |
| 08:04:10 | saem | disruptek: going to add that to the things of not to believe. |
| 08:04:15 | FromDiscord | <apollo> i guess thats what it means by "not all cases covered" |
| 08:04:19 | FromDiscord | <ElegantBeef> yes |
| 08:04:22 | FromDiscord | <ElegantBeef> where is the tutorial now? |
| 08:04:22 | FromDiscord | <apollo> thanks |
| 08:04:25 | narimiran | "However, the above code does not compile:" |
| 08:04:34 | FromDiscord | <ElegantBeef> lol |
| 08:04:35 | narimiran | did you read the first sentence below the code sample? |
| 08:04:43 | disruptek | no. |
| 08:04:47 | FromDiscord | <apollo> wait arent these people bot's |
| 08:04:48 | FromDiscord | <apollo> ? |
| 08:04:55 | disruptek | disbot: are you a bot? |
| 08:04:56 | disbot | as i see it, yes. |
| 08:05:00 | disruptek | very good. |
| 08:05:04 | FromDiscord | <ElegantBeef> Those are people through the irc bridge |
| 08:05:43 | FromDiscord | <apollo> whats irc? |
| 08:05:50 | narimiran | bots, mostly |
| 08:06:02 | narimiran | and people who read |
| 08:06:09 | FromDiscord | <apollo> ok |
| 08:06:15 | FromDiscord | <apollo> anyways thanks for the help |
| 08:06:49 | FromDiscord | <ElegantBeef> Internet relay chat for the actual answer, this discord connects to gitter, matrix, and IRC |
| 08:06:55 | FromDiscord | <ElegantBeef> Gives us more chuckleheads |
| 08:07:15 | FromDiscord | <ElegantBeef> Isnt that right dissy? |
| 08:07:20 | FromDiscord | <Varriount> IRC was discord, but from the 1990's |
| 08:07:30 | FromDiscord | <Varriount> (edit) "was" => "is" |
| 08:07:44 | FromDiscord | <apollo> just found nim and got to say the syntax is really something else 0-0 |
| 08:08:00 | FromDiscord | <ElegantBeef> That could be taken 1 of 2 ways 😄 |
| 08:08:30 | FromDiscord | <apollo> :nim3: |
| 08:09:54 | FromDiscord | <ElegantBeef> But yes it's something else, it's good 😄 |
| 08:12:03 | FromDiscord | <apollo> yep its really unique i meant to say |
| 08:12:16 | FromDiscord | <apollo> feels weird coding in it but i hope i get over that soon |
| 08:12:25 | FromDiscord | <ElegantBeef> Well it's a merger of a bunch of languages really |
| 08:12:34 | FromDiscord | <ElegantBeef> Pascal, Oberon, Ada, Python |
| 08:12:43 | FromDiscord | <apollo> which one uses the 'echo' |
| 08:12:58 | FromDiscord | <apollo> yeah i noticed the python indentation |
| 08:13:09 | FromDiscord | <apollo> but i havent worked in any of those other languages you mentioned |
| 08:13:24 | FromDiscord | <ElegantBeef> They're more or less obscure languages |
| 08:14:16 | FromDiscord | <ElegantBeef> I'm guessing echo has it's roots in Unix's `echo` command but no clue |
| 08:14:50 | FromDiscord | <apollo> yeah since im on a linux machine i immediately noticed the echo and was like ohh thats cool |
| 08:15:00 | FromDiscord | <apollo> thought i was writing bash for a minute |
| 08:19:28 | FromDiscord | <mratsim> > Yeah, I get that. But when you want to do some really fun stuff for streaming, then we're talking about operation fusion and micro-batching. The amount of explicit information available is often (purely intuition here) the limitation in terms of what one can and cannot do.↵↵I want to have nanosecond context switches for CPS, similar to what C++ coroutines enable in the papers I linked yesterday |
| 08:20:54 | PMunch | narimiran, ey, we're not all bots |
| 08:21:19 | narimiran | yes, we're programmed to say exactly that |
| 08:21:53 | PMunch | <_< |
| 08:21:58 | FromDiscord | <Rika> Beep hoop |
| 08:22:02 | FromDiscord | <Rika> Boop |
| 08:23:20 | FromDiscord | <apollo> bots |
| 08:26:44 | ForumUpdaterBot | New question by Alex Craft: How to use default generic types in Nim?, see https://stackoverflow.com/questions/65663489/how-to-use-default-generic-types-in-nim |
| 08:27:13 | * | krux02 joined #nim |
| 08:36:59 | FromDiscord | <ElegantBeef> They always have weird questions |
| 08:37:16 | FromDiscord | <ElegantBeef> And i've seen their "opinionated stdlib" and it's something |
| 08:38:00 | FromDiscord | <mratsim> the "Why Nim doesn(t use default value for generic type" is aggressive, but the T = void is a genuine issue that shouldn't compile. |
| 08:38:18 | FromDiscord | <ElegantBeef> Aliasing `values` and `keys` for tables just sends shivers down my spine |
| 08:38:37 | PMunch | "opinionated stdlib"? |
| 08:38:42 | FromDiscord | <ElegantBeef> Yea |
| 08:38:54 | FromDiscord | <ElegantBeef> They're making their own additions to their own stdlib that fits their views |
| 08:39:03 | FromDiscord | <mratsim> but where? |
| 08:39:05 | PMunch | ah |
| 08:39:09 | FromDiscord | <ElegantBeef> Like returning sequences instead of iterators for `values`/`keys` |
| 08:39:15 | FromDiscord | <ElegantBeef> https://github.com/al6x/bon_nim |
| 08:39:17 | PMunch | What? |
| 08:39:22 | PMunch | That's just a bad idea :P |
| 08:39:29 | FromDiscord | <ElegantBeef> Yea they dont like having the `toSeq(iter)` |
| 08:39:58 | FromDiscord | <mratsim> it's empty though |
| 08:40:01 | PMunch | Then write a converter? |
| 08:40:08 | FromDiscord | <Rika> It’s not empty |
| 08:40:09 | FromDiscord | <mratsim> you can't |
| 08:40:14 | FromDiscord | <mratsim> toSeq is a template |
| 08:40:35 | PMunch | Can't you write a converter from iterator(): T to seq[T]? |
| 08:40:40 | FromDiscord | <ElegantBeef> The issue is that you cannot use `iter.templ` |
| 08:40:41 | FromDiscord | <mratsim> toSeq is broken anyway, it doesn't work in templates or generic proc .... |
| 08:41:17 | FromDiscord | <ElegantBeef> I dont like those 4 dots i feel you judging me |
| 08:42:48 | FromDiscord | <mratsim> nop, I'm judging early symbol resolution in generics |
| 08:43:15 | FromDiscord | <ElegantBeef> Ah |
| 08:43:27 | * | u0_a216 joined #nim |
| 08:43:30 | FromDiscord | <mratsim> https://github.com/nim-lang/Nim/issues/8677 |
| 08:43:31 | disbot | ➥ [Meta] Generics/Static early symbol resolution |
| 08:44:09 | FromDiscord | <ElegantBeef> I honestly want very little, late binding statics and iterators as first class 😄 |
| 08:45:12 | * | Zevv joined #nim |
| 08:48:42 | * | haxscramper joined #nim |
| 08:49:31 | * | Vladar joined #nim |
| 08:51:42 | haxscramper | narimiran: yardanico suggested that I should add my pattern matching article to nim blog - I made a PR with it, so could you please look over it when you have time? |
| 08:51:43 | haxscramper | |
| 08:51:43 | haxscramper | |
| 08:51:43 | haxscramper | Also I noticed there is no link to 'contribute' on the nim blog, or it is not |
| 08:51:46 | haxscramper | obvious enough. I remember earlier someone talked about ways to get more |
| 08:51:49 | haxscramper | people to write articles there, and considering that I know how to write articles only because someone explained to me earler, this might be a noticeable roadblocker. |
| 08:51:52 | haxscramper | |
| 08:51:55 | narimiran | haxscramper: will do |
| 08:51:55 | haxscramper | I expected something like "... as well as guest authors. <link to how-to for contribution>" or something like that. |
| 08:51:58 | haxscramper | |
| 08:52:01 | haxscramper | Minor complaint, but I though I should mention this. |
| 08:52:18 | FromDiscord | <mratsim> yep I agree |
| 08:52:32 | FromDiscord | <mratsim> my last article on raytracing was because you ot it from my repo |
| 08:52:44 | FromDiscord | <mratsim> it's better if we have a push model where we submit them |
| 08:52:52 | FromDiscord | <mratsim> with the format, metadata to put |
| 08:53:05 | FromDiscord | <mratsim> and where we put the markdown in the website repo |
| 08:55:07 | haxscramper | There is "his is a guest post by <username>. If you would like to publish articles as a guest author on nim-lang.org then get in touch with us via ..." |
| 08:55:18 | haxscramper | But this is per-article |
| 08:57:41 | haxscramper | narimiran: also - `caseStmtMacros` is still an `experimental`, but I haven't ran into any issues with it whatsoever, except for https://github.com/nim-lang/fusion/pull/33#issuecomment-716140197 |
| 08:57:42 | disbot | ➥ Pattern matching implementation |
| 08:58:17 | haxscramper | And I'm not even sure this is a bug |
| 08:58:38 | haxscramper | Can this flag be enabled by default? |
| 08:58:40 | narimiran | ok. hopefully you're not the only one using it :) |
| 08:59:02 | narimiran | i.e. other people use it, and they found no bugs |
| 08:59:35 | haxscramper | I suppose there is not a lot of people who are using it directly, but I hope I managed to cover most of the edge cases in my unit tests |
| 09:06:49 | * | u0_a216 quit (Ping timeout: 264 seconds) |
| 09:17:51 | * | hnOsmium0001 quit (Quit: Connection closed for inactivity) |
| 09:28:30 | * | Tanger quit (Remote host closed the connection) |
| 09:29:29 | FromDiscord | <flywind> !eval static:↵ let a = MyUint64.high; echo uint64(a) |
| 09:29:31 | NimBot | Compile failed: /usercode/in.nim(1, 13) Error: invalid indentation |
| 09:31:09 | saem | mratsim: I think we need explicit cancellation in CPS so I can call cancel on my brain thinking about CPS instead of falling asleep, thank you. :D |
| 09:31:49 | FromDiscord | <mratsim> you can't cancel a proc that has been started unless you pass a channel that it will check at specific location |
| 09:31:57 | saem | I need to learn to wind down before bed. |
| 09:32:20 | FromDiscord | <mratsim> Just like for regular proc, the scheduler should abstract that. |
| 09:32:24 | saem | Mratsim now you tell me. How an I going to sleep now. :P |
| 09:33:17 | FromDiscord | <mratsim> channel being any synchronization primitives, can be atomics as well or a ptr to a memory location with true false |
| 09:37:06 | saem | So you see the same continuation being handled by more than one dispatcher? |
| 09:43:39 | * | habamax joined #nim |
| 09:54:25 | giaco | correct way to create an array of uint8 from a "ptr uint8" and a "size: uint64"? |
| 09:57:42 | * | abm joined #nim |
| 10:02:43 | * | l1x joined #nim |
| 10:03:14 | PMunch | cast[ptr array[size, uint8]](myPtr)[] |
| 10:03:32 | Zevv | no no no |
| 10:03:58 | PMunch | No? |
| 10:04:03 | Zevv | size is static |
| 10:04:07 | PMunch | Oh wait |
| 10:04:08 | PMunch | Yeah |
| 10:04:21 | Zevv | https://nim-lang.github.io/Nim/manual.html#types-unchecked-arrays |
| 10:10:26 | * | Tanger joined #nim |
| 10:11:25 | giaco | this? var data = cast[ptr UncheckedArray[uint8]](mypointer) |
| 10:15:19 | FromDiscord | <mratsim> yes |
| 10:15:37 | FromDiscord | <mratsim> toOpenArray also but it needs a ptr UncheckedArray first |
| 10:16:58 | giaco | mratsim cool, will toOpenArray copy memory or just type? |
| 10:17:12 | FromDiscord | <mratsim> @saem, While we can have multishot continuations, (running the same continuation multiple times) they cause significant problems with resource management so I think it's best to restricted to one-shot continuations. significant as in, you can allocate once, and free multiple times if the free is in a continuation. |
| 10:17:41 | FromDiscord | <mratsim> also in scheme there are multiple discussions over this in their mailing list and it's probably a design mistake. |
| 10:17:55 | Zevv | mratsim: we still should be able to make a deepcopy and run that, right? |
| 10:17:59 | FromDiscord | <mratsim> they need a "rewind" scheme that reacquire resources at continuation entry |
| 10:18:00 | Zevv | aka, fork() in disruptek-speak |
| 10:18:09 | FromDiscord | <mratsim> you can't deep copy a database connection. |
| 10:18:19 | Zevv | says who. |
| 10:18:25 | Zevv | if the database connection implements a propy =copy |
| 10:18:34 | Zevv | proper |
| 10:18:50 | FromDiscord | <mratsim> you can't deep copy a thread |
| 10:19:02 | FromDiscord | <mratsim> you can't deep copy memory |
| 10:19:02 | Zevv | no, but I can deep copy tons of other things |
| 10:19:19 | Zevv | if it's not deepcopyable, sure, then you can't do it. but if it's deepcopyable, there should be no reason /not/ to be able to |
| 10:19:20 | FromDiscord | <mratsim> sure, but I don't think this is needed right now |
| 10:19:33 | Zevv | neither do I, but I recall that disruptek was fond of it, for some reaso |
| 10:19:55 | FromDiscord | <mratsim> it's a controversial feature in Scheme, it has only a toy use-case after over a decade in their language |
| 10:20:23 | FromDiscord | <mratsim> I think we can deliver CPS with this restriction, and enable it later if we find a compelling reason for |
| 10:20:32 | FromDiscord | <mratsim> and properly analyze the implications |
| 10:20:45 | FromDiscord | <mratsim> we can restrict to supportsCopyMem types for starter |
| 10:20:48 | Zevv | fair enough |
| 10:21:39 | FromDiscord | <mratsim> But I don't want CPS discussion to be derailed by memory management for a feature that didn't see a use-case in the language that implemented continuations a decade ago (or more?) |
| 10:22:44 | FromDiscord | <mratsim> so likely we want to have core features (CPS transforms, storage of the activation frames, compat JS, not pigeon-holing us with the GC) spelled out. |
| 10:23:07 | FromDiscord | <mratsim> and the non-core (multishot continuations, heap allocation elision, ...) |
| 10:23:39 | FromDiscord | <mratsim> and the upper layers (schedulers, asyncstreams, async/await integration). |
| 10:26:45 | * | NimBot joined #nim |
| 10:27:02 | adnan338 | hello, how can I check for OS in the runtime? when defined linux would be a compile time directive, wouldn't it |
| 10:28:49 | * | u0_a216 joined #nim |
| 10:29:39 | FromDiscord | <mratsim> yes |
| 10:29:47 | FromDiscord | <mratsim> binaries are OS specific |
| 10:32:06 | FromDiscord | <mratsim> Unless you go that way: https://justine.lol/cosmopolitan/index.html |
| 10:35:05 | * | keyle quit (Quit: leaving) |
| 10:38:45 | PMunch | Has anyone actually tried to see if they can get that working with Nim? |
| 10:39:59 | Zevv | please don't go there |
| 10:40:03 | Zevv | it's really not worth it |
| 10:43:49 | giaco | why stream module doesn't handle generic byte streams, but only file and string streams? I have a uint8 array, isn't it a stream? |
| 10:44:01 | PMunch | Zevv, I was just curious :P |
| 10:46:24 | PMunch | giaco, there are unfortunately a lot of streams missing.. |
| 10:46:52 | giaco | ok, but logically a generic byte stream comes before ad-hoc streams |
| 10:47:03 | giaco | like strings or other data |
| 10:48:13 | Zevv | PMunch: yeah, I read some old story once about somebody who got curious. That did not end well. |
| 10:48:37 | PMunch | giaco, you'd think wouldn't you, but alas |
| 10:49:09 | PMunch | Zevv, haha :P |
| 10:49:20 | PMunch | giaco, what are you actually trying to do by the way? |
| 10:49:20 | giaco | haha |
| 10:51:57 | Clonkk[m] | You can convert seq[byte] as a string without copying memory and use string stream. You can use Status fast stream as well https://github.com/status-im/nim-faststreams |
| 10:52:02 | giaco | PMunch: well, the short story is that I am dealing with realtime multimedia stream coming from gstreamer, each buffer is a uint8 ptr and I have a parser build with binarylang. To feed that buffer to bianrylang I have to convert it to string first and I don't get why |
| 10:52:22 | Clonkk[m] | * You can convert seq[byte] as a string without copying memory and use string stream (but you have to be careful as playing with memory can be unsafe if you don't know what you're doing). You can use Status fast stream as well https://github.com/status-im/nim-faststreams |
| 10:52:49 | PMunch | binarylang? Is that the new port thing of my binaryparse library? |
| 10:53:12 | PMunch | Clonkk[m], he has a pointer though |
| 10:53:29 | PMunch | You can implement a Stream yourself for a ptr/len combination |
| 10:53:38 | PMunch | It's not terribly difficult |
| 10:54:08 | PMunch | Basically you just need to implement a couple read/write procedures |
| 10:54:16 | PMunch | Oh, and peek |
| 10:54:30 | giaco | you're the author of binaryparse? yeah I tried it when I switched to binarylang. It leverages on this package to build streams but supports file and strings https://github.com/sealmove/bitstreams |
| 10:54:48 | PMunch | Yeah I created binaryparse :) |
| 10:54:51 | Oddmonger | in «typed vs untyped parameters» in the template section of nim manual, what does the first sample ? |
| 10:55:09 | Oddmonger | maybe more a question for the forum, forget it ^^' |
| 10:55:13 | PMunch | binarylang was originally meant to just be a pull request to binaryparse |
| 10:55:36 | PMunch | Oddmonger, typed gives you the AST after the type checking has occured |
| 10:55:53 | PMunch | At this point the code in the block is valid compile-able Nim that has full type information with it |
| 10:56:18 | PMunch | Unlike untyped which is just a representation of the syntax as seen by Nim, without any attempt at actually figuring out what the code is supposed to do |
| 10:56:50 | * | a_b_m joined #nim |
| 10:57:10 | PMunch | But I kept pushing back on features I felt were half-baked or poorly thought through. And by the time it was getting good it was so different that he decided to create a new thing out of it |
| 10:57:14 | Oddmonger | but the code does nothing |
| 10:57:26 | PMunch | Oh, what code are you referring to? |
| 10:57:33 | Oddmonger | declareInt(x) |
| 10:57:37 | PMunch | Link? |
| 10:57:43 | giaco | PMunch: actually I moved to binarylang and there were feature I needed at that time, but then things simplified a lot into my code and now probably I could just switch back seamlessly. Not really sure though |
| 10:57:53 | Oddmonger | excuse me: https://nim-lang.org/docs/manual.html#templates-typed-vs-untyped-parameters |
| 10:58:17 | PMunch | What feature if you don't mind me asking? I still want to add some of the features he proposed into binaryparse |
| 10:59:02 | PMunch | Ah yes Oddmonger, as I said when you use `typed` the code has to be completely and compile-able |
| 10:59:27 | PMunch | `x` in that case is not complete as it isn't declared anywhere (that is what the template is supposed to do) |
| 10:59:37 | * | abm quit (Ping timeout: 256 seconds) |
| 10:59:42 | PMunch | Imagine just putting x in a file by itself, that wouldn't be valid Nim |
| 10:59:57 | Oddmonger | i think i understand, it's like a lazy evaluation ? |
| 11:00:48 | PMunch | Now if you had var x: int before the template then it would work (but obviously give you an error saying that x was already defined when you tried to call the template). |
| 11:00:53 | PMunch | Not quite |
| 11:01:06 | PMunch | The Nim compiler works in steps |
| 11:01:07 | FromDiscord | <mratsim> @giaco, because the stdlib streams modules hasn't been revisited for 10 years, also byte streams should use byte not uint8 |
| 11:01:36 | PMunch | @mratsim, not quite true, I tried to add a byte stream, but the PR got declined |
| 11:01:49 | PMunch | Wouldn't have helped for giaco though, as it was based on seq[byte] |
| 11:01:55 | FromDiscord | <mratsim> also proc foo[T: byte|uint8|char](input: openarray[T]) will match string and seq[byte] |
| 11:02:09 | Oddmonger | need to think about that, but thanks :) |
| 11:02:12 | FromDiscord | <mratsim> @PMunch that's exactly what I'm talking about |
| 11:02:12 | giaco | PMunch: 1) skipping a field or group of field according to previous field (think of protocols like RTP where you have "extension" bit that if it is true you have an addictional field with "extension len" that extends the header) |
| 11:02:24 | FromDiscord | <mratsim> there is no way currently to make streams evolve |
| 11:02:27 | PMunch | But it would be pretty simple to write a PtrStream[T](data: ptr T, len: int) |
| 11:02:53 | PMunch | @mratsim, why not? I just got my socketstream PR accepted |
| 11:03:22 | FromDiscord | <mratsim> byte streams are more fundamental than sockets |
| 11:04:27 | giaco | 2) dynamic subparser, for example change last field parser according to previous field value |
| 11:05:32 | PMunch | Oddmonger, first it parses the text in your file into an abstract syntax tree. This is just a tree representation of your code that matches Nim syntax. Then it runs macros that expect `untyped` on this tree. Then it check if things are actually valid Nim code, not just syntactically similar, by evaluating all the types checking procedure signatures, figuring out generics etc. After that the `typed` macros are run which now have access to a syntax |
| 11:05:32 | PMunch | tree with a lot more information in it. Then everything is turned into C and passed to the C compiler |
| 11:05:41 | PMunch | That is greatly simplified of course |
| 11:06:04 | FromDiscord | <mratsim> yep, it's not true in a generic proc |
| 11:06:35 | PMunch | @giaco, hmm I see. All those are possible with custom parsers, but it's a bit clumsy |
| 11:06:48 | FromDiscord | <mratsim> in a generic proc you get garbage you need to plow through as AST. |
| 11:06:56 | PMunch | I think most of the gripes with binaryparse could be solved by just making it easier to define custom behaviour |
| 11:07:48 | PMunch | @mratsim, garbage? Isn't it just SymChoice and such? |
| 11:08:42 | FromDiscord | <mratsim> you get OpenSymChoice, you get symbols, in becomes contains, array accesses become nnkCall AFAIK |
| 11:09:07 | FromDiscord | <mratsim> and when you work on getImpl(mySymbol) it's a lottery if you will just get T, or something sensible |
| 11:09:36 | giaco | PMunch: sure, with custom parser you can do it, but size of change is actually larger than parsing the stream manually directly. Binarylang saved my quite some code |
| 11:09:38 | FromDiscord | <mratsim> ah and good luck rebuilding types and sifting through getTypeInst, getType and getTypeImpl |
| 11:10:31 | FromDiscord | <mratsim> you also get disappearing type AST, when you call getImpl on a type |
| 11:11:14 | PMunch | @giaco yeah exactly, if binaryparse had better ways of passing simple custom logic it would be neater |
| 11:11:40 | PMunch | Would be very interesting to see a side-by-side of binaryparse vs. binarylang for something like that |
| 11:14:49 | giaco | Clonkk[m]: thanks for the feedback. I'm interested in converting "data: ptr uint8" + "size: uint64" into something I can use as "StringStream" without copy. How would you do it? |
| 11:15:55 | PMunch | I would just create a new Stream |
| 11:16:25 | PMunch | Preferably of course in a package you can put on Nimble and/or PR to stdlib |
| 11:17:00 | FromDiscord | <mratsim> toOpenArrayByte(cast[ptr uncheckedArray[byte]](p), 0, size.int - 1) solves the no copy part. Add a separate index variable to track the current position. |
| 11:17:02 | giaco | PMunch: yeah sadly I went gradually overcomplicating things first, so I switched, then I simplified them losing the actually machinery. |
| 11:17:06 | PMunch | Since you only need reading as well you can implement only the reading parts |
| 11:17:27 | Clonkk[m] | <giaco "Clonkk: thanks for the feedback."> Without copy I'm afraid you can't as is. You can't convert a ptr+len into a seq or string without copy |
| 11:17:35 | FromDiscord | <mratsim> with experimental: views you can store openarray in objects. |
| 11:17:39 | PMunch | @mratsim, they still need a stream to be able to pass it to binarylang |
| 11:17:59 | Clonkk[m] | > <@freenode_giaco:matrix.org> Clonkk: thanks for the feedback. I'm interested in converting "data: ptr uint8" + "size: uint64" into something I can use as "StringStream" without copy. How would you do it? |
| 11:17:59 | Clonkk[m] | * Without copy I'm afraid you can't as is. You can't convert a ptr+len into a seq or string without copy. I thought you already had a ``seq`` as Input. PMunch is correct you need to create stream on pointer. |
| 11:18:00 | FromDiscord | <mratsim> ah, well then custom stream |
| 11:19:06 | Clonkk[m] | * Without copy I'm afraid you can't. You can't convert a ptr+len into a seq or string without copy. I thought you already had a `seq` as Input. PMunch is correct you need to create stream on pointer. |
| 11:20:33 | PMunch | As you can see it's not terribly complicated: https://github.com/nim-lang/Nim/blob/version-1-4/lib/pure/streams.nim#L1128-L1299 |
| 11:20:59 | PMunch | Note that https://github.com/nim-lang/Nim/blob/version-1-4/lib/pure/streams.nim#L1137-L1190 is behind a `when` switch so you can ignore that |
| 11:21:42 | Clonkk[m] | Creating a stream is like 8 proc if i'm not mistaken |
| 11:22:47 | PMunch | There's close, atEnd, setPosition, getPosition, readDataStr, readData, peekData, writeData, and new |
| 11:25:13 | PMunch | Most close is probably just a discard (unless you also want it to free), atEnd, setPosition, and getPosition are one-liners that just update or check the position variable. peek, read, and write are all just memcpy and a little position handling |
| 11:25:36 | PMunch | Or copyMem rather |
| 11:26:01 | * | a_b_m quit (Quit: Leaving) |
| 11:27:41 | * | superbia joined #nim |
| 11:28:04 | superbia | is anyone streaming at the moment? |
| 11:28:22 | * | narimiran quit (Ping timeout: 246 seconds) |
| 11:28:59 | PMunch | Not that I know of |
| 11:30:50 | * | narimiran joined #nim |
| 11:32:16 | giaco | PMunch: I don't feel confident enough to push it to std, but yeah I can try fiddling with StreamObj |
| 11:32:40 | giaco | superbia: what do you mean? |
| 11:34:36 | FromDiscord | <mratsim> He was maybe joking about you streaming |
| 11:34:41 | PMunch | giaco, sometimes people stream themselves programming in Nim |
| 11:35:42 | giaco | oh! interesting, didn't know that. How to follow the feed of these events? |
| 11:42:29 | PMunch | Just keep an eye on this channel pretty much :P |
| 11:42:48 | PMunch | And following people streaming as you find them |
| 11:44:05 | PMunch | I stream here: https://www.twitch.tv/pmunche, and on YouTube: https://www.youtube.com/channel/UCBiDnWzKvyF9tTypc8A0CKw |
| 11:44:24 | Clonkk[m] | <PMunch "giaco, sometimes people stream t"> Next step is sport commentator style applied to programming ? |
| 11:44:33 | PMunch | Haha :P |
| 11:44:40 | FromDiscord | <himu> html template engine for nim suggestions? |
| 11:44:47 | PMunch | I mean I guess that could be interesting for something like a 48 hour hackathon |
| 11:49:14 | FromDiscord | <dom96> 🤔 |
| 11:49:52 | PMunch | Man, I miss doing stuff like that.. |
| 11:50:21 | PMunch | Hopefully vaccine production can ramp up quickly so we can start being social again.. |
| 11:50:38 | superbia | it's technically not vaccine PMunch |
| 11:50:56 | FromDiscord | <dom96> (edit) "🤔" => "Hmmm" |
| 11:51:11 | PMunch | superbia, really? |
| 11:51:14 | superbia | maybe you have seen this https://berthub.eu/articles/posts/reverse-engineering-source-code-of-the-biontech-pfizer-vaccine/ ? |
| 11:51:35 | PMunch | I know there are two kinds, one that is rDNA based and one which is based on more "traditional" vaccine tech |
| 11:52:43 | Zevv | FOSDEM was a bit _too_ social to my liking |
| 11:52:57 | PMunch | "It is 4284 characters long, so it would fit in a bunch of tweets." what a weird comparison :P |
| 11:53:11 | PMunch | Anything can fit in "a bunch of tweets" |
| 11:53:32 | PMunch | Zevv, oh I really like that, in bursts mind you |
| 11:54:42 | superbia | it's what happens outside FOSDEM what makes FOSDEM great |
| 11:55:07 | PMunch | Have you been to FOSDEM superbia? Why haven't we ever met up there :P |
| 11:55:25 | PMunch | This CRISPR stuff is just so amazing, feels so close to coding, but works on DNA |
| 11:55:36 | superbia | You were to handsome for me to even be able to approach you |
| 11:55:45 | PMunch | Haha |
| 11:55:45 | superbia | ya, enjoy :) |
| 11:55:56 | PMunch | Hopefully it will help us nip other diseases in the butt as well |
| 11:56:06 | * | clyybber joined #nim |
| 11:56:50 | PMunch | I mean with stuff like this guy just ordering DIY gene therapy online it's getting pretty wild: https://www.youtube.com/watch?v=aoczYXJeMY4 |
| 11:58:34 | Zevv | PMunch: the waiting in line and then not getting in was not the greatest part |
| 11:58:42 | FromDiscord | <flywind> sent a code paste, see https://play.nim-lang.org/#ix=2LDE |
| 11:58:45 | FromDiscord | <flywind> Should this compile with `arc`? |
| 11:58:45 | PMunch | Zevv, oh yeah that part sucks.. |
| 11:59:16 | PMunch | Would definitely be nice if all the rooms had higher capacities |
| 12:00:42 | FromDiscord | <lqdev> @flywind yeah, why? |
| 12:00:45 | FromDiscord | <flywind> This doesn't compile with `refc` as expected. |
| 12:00:48 | FromDiscord | <lqdev> why not |
| 12:00:53 | FromDiscord | <lqdev> what's the error? |
| 12:01:02 | FromDiscord | <flywind> should use ref object. |
| 12:01:12 | FromDiscord | <lqdev> ah |
| 12:01:16 | FromDiscord | <lqdev> well now i see it :p |
| 12:01:22 | FromDiscord | <flywind> with refc: `Error: unhandled exception: invalid object assignment [ObjectAssignmentDefect]` |
| 12:01:36 | FromDiscord | <lqdev> well then it does compile |
| 12:01:41 | FromDiscord | <lqdev> just throws an error |
| 12:01:47 | FromDiscord | <flywind> arc: print something same with using ref object |
| 12:02:20 | FromDiscord | <flywind> JS backend: compiles but print wrong strings |
| 12:06:55 | * | kinkinkijkin quit (Quit: Connection closed for inactivity) |
| 12:07:07 | FromDiscord | <flywind> The issue https://github.com/nim-lang/Nim/issues/7002#issuecomment-757910155 |
| 12:07:15 | disbot | ➥ Broken method behavior with derived objects ; snippet at 12https://play.nim-lang.org/#ix=2LDJ |
| 12:12:10 | FromDiscord | <mratsim> that can't work on the stack because you need fixed size on the stack |
| 12:12:15 | FromDiscord | <mratsim> @flywind |
| 12:13:10 | FromDiscord | <mratsim> if you make the object bigger than 64-bit so that it requires 2 registers for being passed, I think it will crash with refc as well |
| 12:14:58 | FromDiscord | <flywind> What's right behaviour for `arc`? We should disable it in arc too. Right? |
| 12:15:14 | FromDiscord | <flywind> (edit) "What's ... right" added "the" |
| 12:16:25 | FromDiscord | <mratsim> the right behavior is to make that an error. |
| 12:16:38 | FromDiscord | <flywind> I see, thanks |
| 12:17:04 | FromDiscord | <mratsim> Preventing method on non ref object of RootObj seems reasonable |
| 12:17:16 | FromDiscord | <mratsim> I don't think there is a use-case for methods beyond that. |
| 12:19:53 | FromDiscord | <flywind> > pre-existing, but what's the rationale for high(a: Dollar) being automatically defined for type Dollar = distinct int ? |
| 12:20:02 | FromDiscord | <flywind> Do you think this is reasonable? |
| 12:20:11 | FromDiscord | <flywind> https://github.com/nim-lang/Nim/pull/16681#issuecomment-757893543 |
| 12:20:12 | disbot | ➥ fix #13517 |
| 12:22:11 | FromDiscord | <mratsim> timothee's remark make sense |
| 12:22:32 | FromDiscord | <mratsim> if they want high they should {.borrow.} |
| 12:23:00 | FromDiscord | <flywind> I see, thanks |
| 12:24:37 | FromDiscord | <mratsim> We need to borrow +, -, $ after all |
| 12:24:48 | FromDiscord | <mratsim> I think the only thing we don't need to borrow is == |
| 12:28:03 | FromDiscord | <mratsim> actually we need to borrow it as well |
| 12:32:15 | FromDiscord | <flywind> I see, `high` accepts `Odianal` types which may be the reason. |
| 12:34:15 | FromDiscord | <flywind> not sure whether it is easy to disable it. |
| 12:36:27 | FromDiscord | <mratsim> should distinct of ordinal be ordinal though? |
| 12:36:36 | * | superbia quit (Quit: WeeChat 3.0) |
| 12:36:50 | FromDiscord | <mratsim> distinct cint is used to implement C enums with holes for example, they aren't ordinal |
| 12:38:47 | * | inv2004 joined #nim |
| 12:40:03 | inv2004 | Why check field compare kind of the obj with pwr of 2? |
| 12:40:18 | inv2004 | ((1 &((NU8)1<<((NU)(b__9b0TPEIuSEk5lcmaJoBqmcQ.kind)&7U)))!=0) |
| 12:43:01 | FromDiscord | <exelotl> inv2004 that's how sets work in Nim |
| 12:44:21 | FromDiscord | <exelotl> Are you doing something like `b.kind in {myEnumVal}` ? |
| 12:44:29 | * | Torro joined #nim |
| 12:44:41 | PMunch | Has anyone tried those IngChips BLE things? The ones that have an official Nim SDK? |
| 12:44:53 | FromDiscord | <inv> Not, it is just standard --d:release check to raiseFieldError |
| 12:45:13 | FromDiscord | <inv> (edit) "Not," => "No," |
| 12:45:26 | FromDiscord | <exelotl> Oh, maybe its using sets under the hood then |
| 12:46:05 | ForumUpdaterBot | New thread by Drkameleon: Experimenting with an SQLite-based portable graph DB engine, see https://forum.nim-lang.org/t/7374 |
| 12:46:43 | FromDiscord | <inv> Thx for pointing for it. Do you have idea why the set is here? ... Ah, maybe because case can have multiple values ... letmecheck |
| 12:48:16 | FromDiscord | <exelotl> I'm not sure but it sounds likely :) |
| 12:52:57 | * | adnan338 quit (Ping timeout: 256 seconds) |
| 12:57:59 | * | inv2004_ joined #nim |
| 13:02:01 | * | inv2004 quit (Ping timeout: 264 seconds) |
| 13:13:52 | * | Torro quit (Remote host closed the connection) |
| 13:13:57 | * | T0rr0 joined #nim |
| 13:16:14 | * | T0rr0 left #nim (#nim) |
| 13:16:17 | FromGitter | <gogolxdong> https://www.bilibili.com/video/BV1E54y147xg/ |
| 13:17:35 | * | inv2004_ quit (Quit: Leaving) |
| 13:21:01 | FromGitter | <gogolxdong> Dont know whether you can play, but still sorry for lacking of English version, this GUI application uses wNim + libp2p + miniblink + ffmpeg(WIP) + QUIC(using underlying Go QUIC) |
| 13:22:44 | giaco | PMunch: I'm watching your speech at fosdem. I wish I could speak clearly in public like that. Thanks for that! |
| 13:22:58 | FromDiscord | <mratsim> @gogolxdong that's awesome |
| 13:23:07 | PMunch | giaco, oh cool, which one? |
| 13:23:09 | FromDiscord | <mratsim> We're getting Nim QUIC up to speed |
| 13:23:28 | giaco | Metaprogramming with Nim |
| 13:23:36 | PMunch | Nice |
| 13:23:52 | PMunch | I'm going to record this years FOSDEM talk tonight, for the all-online version |
| 13:24:12 | FromGitter | <gogolxdong> It combines IPFS and http, establishes connection between any two libp2p node all over the world. |
| 13:24:44 | PMunch | So much harder to plan what to say when I don't have an audience. Typically I just improvise and base what I say based on how confused or bored the audience looks |
| 13:25:34 | PMunch | And I've always liked public speaking, what actually made me the most nervous for that presentation was knowing that it was live streamed and recorded :P |
| 13:27:08 | FromGitter | <gogolxdong> GUI crashed after sending filestream. |
| 13:27:18 | FromDiscord | <mratsim> what is ffmpeg for? doing decentralized video? |
| 13:27:30 | FromGitter | <gogolxdong> yes |
| 13:27:53 | FromDiscord | <mratsim> I should really retrain myself in Chinese |
| 13:28:03 | giaco | I actually teach, but when audience is made of students is not the same as presenting to peers. That confrontation makes the quality and confidence of my speech drop by 50% |
| 13:28:25 | * | habamax quit (Ping timeout: 246 seconds) |
| 13:29:06 | FromDiscord | <mratsim> before students or before peers? |
| 13:29:51 | FromGitter | <gogolxdong> Maybe I spoke a bit fast. |
| 13:30:15 | PMunch | Oh yeah for sure! I used to work as a teaching assistant at my university, and that didn't faze me at all. But talking to a room full of peers and knowing that anyone could watch it live and that it would be recorded for prosperity was certainly a bit stressful |
| 13:30:16 | FromDiscord | <mratsim> The main issue with students is, what is their knowledge level, what can I assume? For peers it exists as well but i'm more worried about the one who never stops asking questions and derail the Q&A session. |
| 13:30:45 | FromDiscord | <mratsim> @gogolxdong, no it's pretty clear, and I could easily distinguish the words, it's just that I don't know what they mean :p |
| 13:31:04 | FromGitter | <gogolxdong> haha |
| 13:31:39 | PMunch | @mratsim, that's true. I guess there's also quite a big difference between a 2 hour TA session and a 15 minute presentation |
| 13:32:18 | FromDiscord | <mratsim> I gave an AI course to marketing major in 2019 |
| 13:32:22 | FromDiscord | <mratsim> 3 hours |
| 13:32:22 | FromGitter | <gogolxdong> It's here , https://github.com/gogolxdong/2DeFi I will update all Nim part, without go vendor packages. |
| 13:32:41 | * | hmmm joined #nim |
| 13:32:41 | FromDiscord | <mratsim> we used to vendor go-libp2p-daemon in libp2p |
| 13:32:46 | FromDiscord | <mratsim> it's still there for testing |
| 13:33:22 | * | greenfork joined #nim |
| 13:33:44 | FromGitter | <gogolxdong> hope nim-libp2p will catch up with ARC/ORC |
| 13:34:01 | giaco | With students there's this wall of knowledge that has to be overcome before reaching teacher level, while at a conference it is completely possible to just face show stoppers at minute 1 |
| 13:35:07 | FromDiscord | <Rika> do we have webrtc? or is it time for me to get working on one xd |
| 13:35:13 | FromDiscord | <Rika> a webrtc library |
| 13:35:57 | FromDiscord | <mratsim> a wrapper: https://github.com/TensorTom/nim-webrtc |
| 13:36:41 | FromDiscord | <mratsim> should have submodule the C library and replaced make with {.compile: .c.} though |
| 13:40:22 | greenfork | does anyone know what's the correct passL:"???" flag for Windows if I want to link library with mingw and I have these files: libraylib.a, libraylibdll.a, raylib.dll? so the command is "nim c --passL:"???" myfile.nim" |
| 13:42:44 | FromDiscord | <mratsim> passL:"-Lpath/to/folder -lraylib" |
| 13:43:11 | FromDiscord | <mratsim> or use dynlib |
| 13:43:28 | leorize[m] | you can't link directly to a dll |
| 13:43:38 | FromDiscord | <mratsim> if you want to statically link, use {.link:"foo.a".} |
| 13:43:46 | leorize[m] | either you have an import library or you use dynlib |
| 13:44:11 | FromDiscord | <mratsim> passL:"-Lpath/to/folder -lraylib" would work |
| 13:44:57 | leorize[m] | I doubt it, if you don't have a `raylib.lib` |
| 13:46:24 | greenfork | leorize[m], I can't use dynlib because some files are single header+implementation files which strictly require inclusion with #include in original C |
| 13:47:34 | greenfork | for now I just want to dynamically link 1 dll. my understanding is that raylib.dll is for mingw (gcc) compiler and raylib.lib is for vcc compiler, I'm pretty sure I can get raylib.lib too |
| 13:48:50 | leorize[m] | you can still use dynlib in that case, but if you can get the import library I would recommend that instead |
| 13:48:51 | greenfork | mratsim, thanks, I thought that windows handles path resolution and includes current directory. the problem is that it can't find -lraylib even with raylib.dll in the same folder as exe. I assume one also needs libraylibdll.a to be present, but we will see |
| 13:49:33 | leorize[m] | gcc needs either `.lib` or `.dll.a` |
| 13:49:33 | FromDiscord | <mratsim> you likely need to fix your path |
| 13:49:49 | FromDiscord | <mratsim> LD_LIBRARY_PATH or whatever the equivalent is on windows |
| 13:50:10 | leorize[m] | there's no way around it because windows is kinda weird |
| 13:50:37 | leorize[m] | ld_library_path don't exist on windows |
| 13:50:44 | leorize[m] | nor rpath |
| 13:50:45 | greenfork | leorize[m], there's 1 file distributed as dll and some files are distributed as #include and some files needs to be statically linked. working with dynlib here is tough. one issue is name mangling, other "#included" files need original names |
| 13:51:53 | leorize[m] | then you need the import library |
| 13:52:28 | greenfork | what's "import library"? with "lib"? |
| 13:53:17 | leorize[m] | they are packaged as either `lib` or `dll.a` |
| 13:53:52 | * | Torro joined #nim |
| 13:54:15 | greenfork | I have dll.a. what's my passL flag if I have them in the same folder as exe, just --passL:-lraylib ? |
| 13:55:40 | leorize[m] | you need `-Lpath/to/folder` too since the exe folder is probably not in your linker search path |
| 13:56:11 | greenfork | okay, thank you! I will ask my volunteers to check it |
| 14:04:56 | * | PMunch quit (Ping timeout: 240 seconds) |
| 14:05:18 | FromGitter | <gogolxdong> this client is made for sharing Nim things worldwide. |
| 14:05:20 | * | Tanger quit (Quit: Leaving) |
| 14:06:46 | FromGitter | <gogolxdong> It has a latest working binary daemon and Nim code, as well i18n part, in which I translated most word into English. |
| 14:10:46 | FromDiscord | <apollo> im getting this really confusing error can someone help out? |
| 14:11:29 | FromDiscord | <Rika> sure, hit us |
| 14:11:30 | FromDiscord | <haxscramper> Show code/error |
| 14:11:51 | FromDiscord | <apollo> this is the error message |
| 14:12:05 | FromDiscord | <apollo> and this is the code |
| 14:12:08 | FromDiscord | <apollo> sent a code paste, see https://play.nim-lang.org/#ix=2LEk |
| 14:12:23 | FromDiscord | <apollo> im just learning nim |
| 14:12:26 | FromDiscord | <apollo> sent a code paste, see https://play.nim-lang.org/#ix=2LEl |
| 14:12:28 | FromDiscord | <Rika> missing colon before the last "string" |
| 14:12:30 | FromDiscord | <apollo> and its way of doing functions are abit confusing |
| 14:12:32 | FromDiscord | <Rika> in the first line |
| 14:12:45 | FromDiscord | <Rika> so it should be `proc HelloUser(name: string): string =` |
| 14:13:02 | FromDiscord | <apollo> huh i didnt even notice that :facepalm: |
| 14:13:09 | leorize[m] | found the go user :p |
| 14:13:13 | FromDiscord | <apollo> i feel soo dumb now |
| 14:13:17 | FromDiscord | <apollo> precisely |
| 14:13:22 | FromDiscord | <apollo> thanks rika |
| 14:13:26 | FromDiscord | <Rika> its fine, i feel the compiler should catch that |
| 14:13:40 | FromDiscord | <Rika> but it doesnt rn |
| 14:18:29 | * | PMunch joined #nim |
| 14:19:57 | * | clyybber quit (Quit: WeeChat 3.0) |
| 14:20:11 | FromDiscord | <shadow.> maybe zig lol |
| 14:20:13 | * | u0_a216 quit (Ping timeout: 246 seconds) |
| 14:20:16 | FromDiscord | <shadow.> ah nvm they said precisely |
| 14:20:40 | FromDiscord | <shadow.> also |
| 14:20:48 | FromDiscord | <shadow.> typically camelCase is preferred to PascalCase for proc names |
| 14:21:40 | FromDiscord | <shadow.> im doing a task where im looping through the lines of a txt file and checking if each line is valid using a function ive made. is this suitable for parallelism with something like weave? |
| 14:22:28 | leorize[m] | no |
| 14:22:46 | FromDiscord | <shadow.> ah |
| 14:22:49 | FromDiscord | <shadow.> why's that? |
| 14:22:50 | leorize[m] | since your bottleneck is the act of reading file, which must be serialized |
| 14:22:57 | FromDiscord | <shadow.> hm |
| 14:23:04 | FromDiscord | <shadow.> i read it into memory at once and then use a split iterator |
| 14:23:13 | FromDiscord | <shadow.> most of the time is in the validator function |
| 14:23:20 | leorize[m] | for parsing optimization you should use SIMD instead |
| 14:23:23 | * | kinkinkijkin joined #nim |
| 14:23:38 | FromDiscord | <shadow.> any libraries you know of for that? or somewhere i could read up on it |
| 14:23:52 | leorize[m] | it's infinitely lower overhead compared to threading :p |
| 14:24:22 | leorize[m] | cue @mratsim, he's the expert on high performance computing here |
| 14:24:45 | FromDiscord | <shadow.> fair enough lol |
| 14:24:55 | FromDiscord | <mratsim> I'm not a parsing expert though |
| 14:25:05 | * | hmmm quit (Quit: WeeChat 3.0) |
| 14:25:13 | FromDiscord | <mratsim> strings !=!=!=!= high perf computing 😉 |
| 14:25:27 | FromDiscord | <mratsim> I'm amazed at people who manages to keep the CPU busy with strings |
| 14:25:43 | FromDiscord | <mratsim> they are better dev than me |
| 14:25:55 | FromDiscord | <shadow.> sent a code paste, see https://play.nim-lang.org/#ix=2LEr |
| 14:26:00 | FromDiscord | <shadow.> simple asf, just slow lol |
| 14:26:34 | FromDiscord | <shadow.> i know i could optimize it but im not doing it to be optimized, just wanted to try different libraries in nim for high performance computations i suppose |
| 14:26:42 | FromDiscord | <shadow.> educational lol |
| 14:28:40 | FromDiscord | <mratsim> where does that letters, appear? |
| 14:29:42 | FromDiscord | <mratsim> you should likely use an array[PrintableCharsEnum, int] and dump via a for loop all the letter count in there |
| 14:29:51 | FromDiscord | <shadow.> letters is just a global |
| 14:30:03 | FromDiscord | <mratsim> and then you index that array with your letter |
| 14:30:04 | FromDiscord | <shadow.> it's just like |
| 14:30:10 | FromDiscord | <shadow.> array[26, int] |
| 14:30:12 | FromDiscord | <shadow.> where 26 is a-z |
| 14:30:30 | FromDiscord | <shadow.> it's precomputed into a count-table type thing but yk |
| 14:30:33 | FromDiscord | <shadow.> with an array instead |
| 14:30:37 | FromDiscord | <mratsim> your algorithm is quadratic |
| 14:30:40 | FromDiscord | <shadow.> yep. |
| 14:30:45 | FromDiscord | <shadow.> lmao |
| 14:30:45 | FromDiscord | <mratsim> make it linear |
| 14:30:49 | FromDiscord | <shadow.> hm |
| 14:31:02 | FromDiscord | <mratsim> scan once over the data |
| 14:31:25 | FromDiscord | <shadow.> dont know how i could do it without checking every character though |
| 14:31:45 | FromDiscord | <shadow.> since i have to at one point or another for the computation |
| 14:32:08 | * | hyiltiz quit (Remote host closed the connection) |
| 14:32:36 | FromDiscord | <mratsim> yes you can! |
| 14:33:02 | FromDiscord | <mratsim> scan the word and keep a count in an array or table of all the words you encountered |
| 14:33:27 | FromDiscord | <mratsim> at the end you have the count of all letters in a nice tidy data structure |
| 14:33:36 | FromDiscord | <mratsim> in one pass |
| 14:33:56 | FromDiscord | <shadow.> well yes but i still have to check every character to turn it into that array? |
| 14:33:59 | FromDiscord | <shadow.> and i have to do that for every word |
| 14:34:32 | FromDiscord | <shadow.> OH WAIT |
| 14:34:35 | FromDiscord | <shadow.> i think ik wym lmao |
| 14:34:40 | FromDiscord | <shadow.> just iterate and do += on the array? |
| 14:34:43 | FromDiscord | <mratsim> yep |
| 14:34:46 | FromDiscord | <shadow.> ahh i see |
| 14:34:48 | FromDiscord | <shadow.> so two pass |
| 14:34:50 | FromDiscord | <shadow.> hm lemme try that |
| 14:34:55 | FromDiscord | <mratsim> no it's one pass |
| 14:34:59 | FromDiscord | <mratsim> one pass over the words |
| 14:35:06 | FromDiscord | <mratsim> but 2 stages if you want |
| 14:35:11 | FromDiscord | <shadow.> yeah |
| 14:35:11 | FromDiscord | <mratsim> one O(n) and one O(1) |
| 14:35:16 | FromDiscord | <shadow.> yep |
| 14:35:53 | FromDiscord | <shadow.> simple enough? |
| 14:35:57 | FromDiscord | <shadow.> sent a code paste, see https://play.nim-lang.org/#ix=2LEv |
| 14:36:06 | FromDiscord | <shadow.> kk lemme try that thanks |
| 14:36:24 | * | hyiltiz joined #nim |
| 14:36:58 | FromDiscord | <shadow.> hmm |
| 14:37:16 | FromDiscord | <shadow.> if i turn all the words into `CountMap`'s then iterating letters will be slow right? |
| 14:37:21 | FromDiscord | <shadow.> or do i just iterate all indexes and skip 0's |
| 14:39:44 | FromDiscord | <mratsim> I suggest you use this: https://github.com/mratsim/Arraymancer/blob/master/examples/ex06_shakespeare_generator.nim#L32-L39 |
| 14:40:23 | * | clyybber joined #nim |
| 14:40:28 | FromDiscord | <mratsim> create an array or seq or table that maps printable characters to an integer |
| 14:40:37 | FromDiscord | <mratsim> create the inverse mapping function |
| 14:40:40 | FromDiscord | <shadow.> ahh yeah |
| 14:41:17 | FromDiscord | <mratsim> and then you do inc(countTable[charToIdx[letter]]) |
| 14:41:33 | FromDiscord | <shadow.> yeah |
| 14:41:34 | FromDiscord | <shadow.> ty |
| 14:41:50 | FromDiscord | <shadow.> i suppose i need a good use case for weave to learn it then lol |
| 14:42:31 | FromDiscord | <mratsim> if you want to do a parallel for loop or spawn tasks basically |
| 14:43:10 | FromDiscord | <mratsim> look in the benchmark folders there are plenty of examples (except the overhead ones, the overhead benchmarks are bad reason to use parallelism) |
| 14:43:21 | * | arnetheduck joined #nim |
| 14:43:28 | FromDiscord | <mratsim> (usually because task is to short and so you don't accelerate anything) |
| 14:44:15 | FromDiscord | <shadow.> so would i not be able to loop through the lines in parallel once they're all in memoru? |
| 14:44:20 | * | arnetheduck quit (Client Quit) |
| 14:44:25 | FromDiscord | <shadow.> (edit) "memoru?" => "memory?" |
| 14:44:30 | FromDiscord | <shadow.> not saying i should, just wondering |
| 14:44:36 | FromDiscord | <shadow.> ye lemme look at benchmarks |
| 14:47:26 | FromDiscord | <shadow.> ahh i see so you need to use uncheckedarray if you're going to modify it in parallel? |
| 14:57:36 | leorize | it's just because refc is terrible :P |
| 14:59:04 | FromDiscord | <shadow.> rip |
| 15:12:09 | giaco | in $data[0].uint8, what is the order of execution? [], $, uint8? |
| 15:12:49 | FromDiscord | <exelotl> $((data[0]).uint8) |
| 15:13:24 | giaco | thanks |
| 15:13:24 | * | PMunch quit (Ping timeout: 256 seconds) |
| 15:22:54 | * | hyiltiz quit (Quit: No Ping reply in 180 seconds.) |
| 15:26:32 | * | PMunch joined #nim |
| 15:27:07 | giaco | could you please explain me what's happening here? https://play.nim-lang.org/#ix=2LER |
| 15:27:18 | giaco | I'm converting to string and back a single byte |
| 15:28:57 | PMunch | You're grabbing the first character of $foo aka. "[128]" |
| 15:29:05 | PMunch | And converting that into a uint8 |
| 15:29:22 | PMunch | 91 is the ASCII value for [ |
| 15:30:18 | PMunch | You appear to actually want this: https://play.nim-lang.org/#ix=2LET |
| 15:30:25 | PMunch | giaco ^ |
| 15:32:08 | * | l1x quit (Quit: Connection closed for inactivity) |
| 15:33:51 | FromDiscord | <mratsim> you're spreading misinformation @leorize refc main issue is that it's non-deterministic and that seq and strings uses it by default. |
| 15:34:30 | FromDiscord | <mratsim> the fact that heap allocation kills performance is true for any GC. |
| 15:34:56 | FromDiscord | <mratsim> that said the fact that the heap is thread-local is indeed a problem. |
| 15:36:04 | leorize | it's correct in the context :P but I can see how people may misinterpret it |
| 15:36:19 | giaco | aaah ok, me stupid. Buy how to convert an openArray[uint8] into a string with exactly the same bytes? |
| 15:36:23 | leorize | I'm still waiting for views to mature, that would solve a lot of my api problems |
| 15:36:34 | * | xet7 quit (Quit: Leaving) |
| 15:37:33 | FromDiscord | <mratsim> @giaco, var s = newString(opena.len) then a for loop with char(yourBite) |
| 15:37:33 | FromDiscord | <shadow.> cast or copymem |
| 15:37:37 | FromDiscord | <shadow.> ah wait |
| 15:37:42 | FromDiscord | <shadow.> mratsim's way is more elegant |
| 15:37:42 | FromDiscord | <shadow.> lmao |
| 15:37:46 | FromDiscord | <mratsim> no, you don't cast an openarray |
| 15:37:51 | FromDiscord | <shadow.> ah an openarray |
| 15:37:52 | FromDiscord | <shadow.> i see |
| 15:37:54 | FromDiscord | <mratsim> you can copyMem though |
| 15:37:56 | FromDiscord | <shadow.> yeah |
| 15:38:12 | FromDiscord | <shadow.> var s = newString(opena.len) then copymem by addr ig |
| 15:38:13 | FromDiscord | <mratsim> the for loop should be detected as copymem anyway |
| 15:38:27 | FromDiscord | <shadow.> ah fair enough |
| 15:40:02 | giaco | I should really implement a stream for bytes, sigh |
| 15:47:22 | * | hyiltiz joined #nim |
| 15:48:03 | ForumUpdaterBot | New question by Artem Klevtsov: Can't int array with uint8 type, see https://stackoverflow.com/questions/65670050/cant-int-array-with-uint8-type |
| 15:49:03 | * | hyiltiz quit (Excess Flood) |
| 15:50:46 | * | hyiltiz joined #nim |
| 15:50:46 | * | hyiltiz quit (Changing host) |
| 15:50:46 | * | hyiltiz joined #nim |
| 15:51:18 | * | waleee-cl joined #nim |
| 15:56:05 | giaco | thanks, conversion works |
| 15:57:22 | * | hnOsmium0001 joined #nim |
| 16:05:54 | * | hyiltiz quit (Ping timeout: 260 seconds) |
| 16:08:38 | * | hyiltiz joined #nim |
| 16:13:03 | * | hyiltiz quit (Client Quit) |
| 16:14:06 | * | Torro left #nim ("bye") |
| 16:15:37 | * | krux02 quit (Quit: Leaving) |
| 16:15:56 | leorize | @mratsim is std/atomics fast in non-threading scenario? |
| 16:16:19 | FromDiscord | <mratsim> why would you use them if you don't need to sync threads? |
| 16:16:25 | leorize | I'm not a big fan of splitting my code for threadsafe and non-threadsafe paths |
| 16:17:01 | leorize | my library need to support threading |
| 16:17:08 | FromDiscord | <mratsim> load and store are "zero-cost" on x86, and costly on ARM, Power, MIPS Itanium |
| 16:17:19 | FromDiscord | <mratsim> add/sub are costly everywhere |
| 16:17:35 | FromDiscord | <mratsim> they mean flush cache, sync, do the operation |
| 16:18:06 | leorize | so I still have to split my code paths... |
| 16:18:07 | leorize | thanks |
| 16:18:08 | FromDiscord | <mratsim> compare and swap are more expensive. |
| 16:18:28 | FromDiscord | <mratsim> well, it depends on your bottlenecks |
| 16:18:39 | FromDiscord | <mratsim> if your bottleneck is IO you don't need to care. |
| 16:18:50 | leorize | I'm dealing with file operations |
| 16:18:55 | FromDiscord | <mratsim> they will be plenty fast, they don't incur kernel context switch |
| 16:19:23 | FromGitter | <eagledot> @mratsim hey,active on arraymancer? |
| 16:19:41 | FromDiscord | <mratsim> (unlike locks or condition variable) |
| 16:19:42 | leorize | apparently on Windows the file position has to be handled by the user if you use async io |
| 16:20:32 | FromDiscord | <mratsim> @eagledot: in maintenance mode, I'm too busy with plenty of projects to develop Arraymancer beyond small patches |
| 16:21:06 | FromGitter | <eagledot> @mratsim No i meant active on arraymancer channel? |
| 16:21:29 | FromDiscord | <mratsim> ah, no, Gitter dropped the ball on me so i switched to discord full time |
| 16:21:40 | FromDiscord | <mratsim> I also linked to Discord instead of Gitter this morning |
| 16:21:55 | FromDiscord | <mratsim> I do check the channel from months to months |
| 16:22:05 | FromGitter | <eagledot> Ok ,I suppose have to generate an account on discord !! |
| 16:22:15 | leorize | mratsim: so the file operations will always take the majority of the time so I don't have to care about atomic perf hit? |
| 16:22:18 | leorize | that's good to know |
| 16:22:38 | FromGitter | <eagledot> @Vindaar you there? |
| 16:22:39 | FromDiscord | <mratsim> the kernel context switch due to file IO will flush your cache anyway |
| 16:25:17 | FromDiscord | <Vindaar> Yup, I'm here |
| 16:25:28 | FromDiscord | <mratsim> so yea, Atomics is like 15-20 cycles maybe, and context switch is more like 180 cycles |
| 16:25:40 | FromGitter | <eagledot> @vindaar on arraymancer too? |
| 16:25:53 | FromDiscord | <Vindaar> sure, can hop over there |
| 16:25:55 | FromDiscord | <mratsim> http://ithare.com/infographics-operation-costs-in-cpu-clock-cycles/↵↵@leorize https://media.discordapp.net/attachments/371759389889003532/798226191663628308/part101_infographics_v08.png |
| 16:26:47 | FromDiscord | <mratsim> They pur the kernel call at 1000 😮 |
| 16:26:48 | FromDiscord | <mratsim> put |
| 16:27:20 | FromDiscord | <mratsim> seems like you shouldn't use exceptions in your file IO as well |
| 16:28:13 | leorize | nim exceptions are just `if`s statements nowadays |
| 16:28:48 | leorize | with --exception:goto, which is gonna be the default |
| 16:29:02 | * | lritter joined #nim |
| 16:29:50 | leorize | so basically same overhead as checking for errors |
| 16:29:57 | FromDiscord | <mratsim> anyway, FileIO = kernel call, and they don't get the Futex API like locks and condition variables (Futex: fast user mutex, do most in user-land if you can) |
| 16:30:18 | FromDiscord | <mratsim> so it's 10 to 50 more costly than atomics |
| 16:30:18 | leorize | not sure when will the `ref` requirement for exceptions go away though, probably never |
| 16:33:34 | * | fputs joined #nim |
| 16:34:23 | * | leorize quit (Ping timeout: 240 seconds) |
| 16:36:11 | * | hyiltiz joined #nim |
| 16:36:11 | * | hyiltiz quit (Changing host) |
| 16:36:11 | * | hyiltiz joined #nim |
| 16:41:27 | * | tane joined #nim |
| 16:44:31 | * | leorize joined #nim |
| 16:45:49 | * | mahlon quit (Quit: WeeChat 3.0) |
| 16:46:43 | * | mahlon joined #nim |
| 16:59:06 | * | hyiltiz quit (Quit: No Ping reply in 180 seconds.) |
| 17:00:22 | * | hyiltiz joined #nim |
| 17:04:08 | disruptek | there was talk of rm'ing exceptions as refs but it seems like a tough battle to me. |
| 17:04:23 | disruptek | i think it could be done in the compiler, though. |
| 17:05:18 | FromDiscord | <mratsim> technically Exceptions are all "object of RootObj" not "ref object of RootObj" |
| 17:08:57 | * | daehee joined #nim |
| 17:10:16 | * | haxscramper quit (Ping timeout: 240 seconds) |
| 17:10:30 | daehee | does the httpclient Response object reference the original Request? didn't appear so in the docs, but could someone confirm this. |
| 17:20:57 | * | daehee quit (Quit: Textual IRC Client: www.textualapp.com) |
| 17:21:18 | * | haxscramper joined #nim |
| 17:22:31 | haxscramper | disruptek: I PRed proof-of-concept graphviz export for gram, with some basic documentations. CI fails but probably because I misconfigured dependencies |
| 17:23:14 | haxscramper | If you are good with this implementation I will spend some more time on dependencies/documentation and it is basically done |
| 17:23:37 | FromDiscord | <Avatarfighter> daehee: the Response object does not reference the original request |
| 17:28:52 | disruptek | scramper: i'm not picky; there are a lot of free version numbers left for gram. 😘 |
| 17:29:39 | disruptek | you can read the CI output, right? |
| 17:32:55 | haxscramper | Yes I can, though testes doesn't output reason for compilation failure, hasts is installed correctly etc. (at least I looks like this to me, because otherwise whole test would fail because it can't even `import hasts/graphviz_ast` in `gram`). But again, I haven't looked into this part specifically |
| 17:33:31 | disruptek | --define:release when you build the rest and you'll get compilation errors. |
| 17:33:43 | disruptek | i just added you to the repo so you can push. |
| 17:35:16 | haxscramper | Oh, yes I forgot `--defined:release` when testing |
| 17:37:30 | disruptek | this is super cool, can't wait to see how people use it. 🎉 |
| 17:41:47 | FromGitter | <daehee> AvatarFighter: ok thanks. I'm capturing the HTTP redirect chain, and noticed that the original prepared Request would be a helpful field on the Response object, similar to Go (https://golang.org/pkg/net/http/#Response) and python requests (https://requests.readthedocs.io/en/latest/api/#requests.Response.request) implementations. |
| 17:47:19 | * | clyybber quit (Quit: WeeChat 3.0) |
| 17:48:51 | Zevv | disruptek: where does the symbol 'checkpoinst' come frm |
| 17:52:21 | Zevv | ow wait |
| 17:52:24 | Zevv | it's not you |
| 17:53:16 | FromDiscord | <mratsim> cue in someone who mentions that all function usd should be qualified |
| 17:53:31 | Zevv | disruptek: something is wrong with testes |
| 17:53:47 | Zevv | yes, I'm ready for the puns |
| 17:54:02 | disruptek | my doctor says it will clear up if i stop picking at it. |
| 17:54:12 | Zevv | but tzevv with testes ends up getting 46 kloc, while under unittest it's just 6 kloc |
| 17:54:23 | disruptek | there's no playin' aroun'. |
| 17:54:29 | Zevv | keep'em coming |
| 17:54:47 | disruptek | if you rub them, they get bigger. what can i say? i'm a grower, not a shower. |
| 17:54:55 | Zevv | one more |
| 17:55:08 | disruptek | jeeze. |
| 17:55:17 | Zevv | hehe |
| 17:55:29 | Zevv | anyway, I'm not sure why it blows up like this, but my tests are kind of unusable now |
| 17:55:46 | disruptek | use version <1.1.0. |
| 17:56:02 | disruptek | it's due to check revealing the symbols in its input. |
| 17:56:09 | Zevv | k |
| 17:56:27 | disruptek | testes breaks cps in 1.1.0+ anyway, due to the foreign bindsym. |
| 17:56:36 | disruptek | or, vice-versa, actually. |
| 17:56:37 | Zevv | nice |
| 17:56:57 | disruptek | hence the requires statement in cps.nimble. |
| 17:57:20 | * | hyiltiz quit (Quit: No Ping reply in 180 seconds.) |
| 17:57:34 | * | hyiltiz joined #nim |
| 17:58:27 | disruptek | ironically, the symbol it pukes on is `useColor`, which was added to appease a certain neanderthal who cannot handle color, italics, or emojis. |
| 17:58:52 | FromDiscord | <Daniel> looking at the operation costs, looks like division is costs more than multiplication.....makes me curious, does substitution for division with multiplication make it cheaper on cpu?...for example if i want to divide 30 by 5, instead of that i send to cpu 30 times 0.2 ....would that be cheaper? |
| 17:59:14 | FromDiscord | <Meowz> `conline(int type, const char sf)` would `cstring` work to wrap the second argument? |
| 17:59:47 | disruptek | daniel: the compiler will figure that shit out for you. |
| 17:59:50 | FromDiscord | <Daniel> (edit) removed "is" |
| 18:00:41 | FromDiscord | <mratsim> yes |
| 18:00:59 | FromDiscord | <mratsim> all compiler do that when the divisor is known at compile-time |
| 18:01:19 | FromDiscord | <mratsim> there is a paper about that from 93 iirc |
| 18:01:23 | FromDiscord | <mratsim> by the author of GMP |
| 18:01:29 | FromDiscord | <bark> why is division more expensive than multiplication on floats 🤔 |
| 18:02:00 | FromDiscord | <mratsim> it's all about hardware logic gates |
| 18:04:55 | FromDiscord | <mratsim> apparently this is an optimized hardware floating point division circuit https://media.discordapp.net/attachments/371759389889003532/798251103178981436/unknown.png |
| 18:05:58 | FromDiscord | <mratsim> source: https://digital.library.adelaide.edu.au/dspace/bitstream/2440/37996/10/02whole.pdf |
| 18:06:00 | FromDiscord | <bark> oh so this is not done using consecutive bit shifts |
| 18:06:48 | FromDiscord | <Daniel> its quite interesting how from Abacus we came up with to solutions made of 2 numbers(0,1) |
| 18:26:52 | leorize | disruptek: if you don't wanna make testes configurable you can make the test runner a library |
| 18:27:03 | leorize | then if you find a tests/runner.nim just compile that file and run it |
| 18:27:17 | disruptek | that's an idea, yeah. |
| 18:27:49 | disruptek | or, you supply the path on the cli maybe. |
| 18:28:02 | leorize | that too |
| 18:29:06 | disruptek | i wonder if that defeats the purpose, though. |
| 18:31:25 | disruptek | !repo asynctest |
| 18:31:27 | disbot | https://github.com/markspanbroek/asynctest -- 9asynctest: 11Unit testing of asynchrononous code in Nim 15 0⭐ 0🍴 |
| 18:31:44 | * | Q-Master quit (Ping timeout: 256 seconds) |
| 18:31:56 | disruptek | i don't even. |
| 18:39:54 | * | hyiltiz quit (Quit: hyiltiz) |
| 18:42:01 | * | hyiltiz joined #nim |
| 18:49:55 | ForumUpdaterBot | New thread by B3liever: Can you please explain these benchmark results (and confirm my numbers), see https://forum.nim-lang.org/t/7375 |
| 18:53:52 | * | clyybber joined #nim |
| 19:01:53 | * | jkiesian joined #nim |
| 19:02:27 | * | Q-Master joined #nim |
| 19:02:34 | haxscramper | |
| 19:02:34 | haxscramper | disruptek: I also thought about nimph and your idea for package management, specifically in context of your complaints about nobody switching from nimble (possibly wrong phrasing, but at least that's how it looks to me right now). |
| 19:02:34 | haxscramper | So, if I take nimph, specifically it's readme there are following sections - 'features', 'usage', 'demo', and more usage. There is no 'moving from nimble', 'getting started from scratch', or general description of why this particular approach is superior. |
| 19:02:34 | haxscramper | Same goes for gitnim - 'installatin', 'usage', done. |
| 19:02:37 | haxscramper | Specifically in my case, when I first found nimble but haven't used it because, even though it might seem like an amazing tool overall, I haven't found a simple step-by-step guide how to move from my existing setup, what problems does it have (it works for me /now/, what else I might need?). So, as you said earlier "not better enough". |
| 19:02:51 | haxscramper | This is just some relatively random ideas |
| 19:03:06 | haxscramper | Not really actionable |
| 19:04:13 | PMunch | Does nimph have a build system similar to nimble? |
| 19:04:21 | disruptek | no. |
| 19:04:22 | PMunch | I.e. a Nimble file |
| 19:04:25 | haxscramper | But just general description along the lines of "why do **I** need this, here and now" |
| 19:04:36 | PMunch | Ah, that's for me good enough reason not to switch.. |
| 19:04:40 | haxscramper | Because it is really an amazing tool from what I can tell |
| 19:04:51 | PMunch | I want to run nimble install X and get everything it depends on as well |
| 19:04:59 | disruptek | nimph doctor |
| 19:05:05 | PMunch | Or download a project and do nimble run and it will just grab everything and run it |
| 19:05:20 | * | disruptek shrugs. |
| 19:05:20 | haxscramper | But this /looks/ great, but the problem I don't /exactly/ know how to move from thinking in terms for nimble to nimph terms. |
| 19:05:42 | haxscramper | This does sound a bit uncertain, but I dont' think I can phrase i better |
| 19:06:10 | haxscramper | it* |
| 19:06:29 | leorize | nimph currently just outsource things to nimble when it doesn't know the command iirc |
| 19:07:05 | disruptek | the idea of nimph is that it helps you to make the environment match the configuration you specified such that the compiler can do its thing. |
| 19:07:10 | disruptek | that is all. |
| 19:07:39 | disruptek | you declare your env in a nim.cfg or whatever and nimph will tell you of any problems and fix anything it can fix without your intervention. |
| 19:09:05 | disruptek | nimph goatfucker will run nimble goatfucker for you, yes. |
| 19:09:43 | disruptek | the reason nimph is the future is that it knows how to sniff your git repo quickly and accurately. we don't exploit this all that much today, but we will. |
| 19:09:52 | leorize | have you tried to implement MVS in nimph? |
| 19:10:15 | disruptek | not since i originally wrote it. |
| 19:11:36 | disruptek | scramper: i probably need more demos, but basically, i don't want to use nimph. that's the design goal. it's designed to not be used. |
| 19:11:54 | disruptek | the compiler works well. i don't want another layer between me and the compiler. |
| 19:12:10 | disruptek | nimph just makes sure that the compiler can do its thing. |
| 19:13:02 | leorize | now you just need to write an RFC to fold the package manager into the compiler |
| 19:13:17 | disruptek | i will work on gitnim today. that's the first step. |
| 19:13:43 | leorize | either that or Araq implements compiler plugins so we can experiment with the idea outside of the compiler |
| 19:13:45 | disruptek | scramper: just build it. you can run `nimph` anywhere and it's intructive but non-destructive. |
| 19:14:48 | disruptek | ie. use it alongside nimble. it plays nicely. |
| 19:16:46 | * | D_ quit (Quit: No Ping reply in 180 seconds.) |
| 19:16:57 | disruptek | i used to have an Opinions section that explained why nimph exists but maybe i took it out. |
| 19:17:03 | haxscramper | disruptek: I'm talking more about explaining what is going on in general. And even more specifically following questions: "How I can create nim projects nimph?", "how I add dependencies.", "how do I publish them?" |
| 19:17:03 | haxscramper | |
| 19:17:16 | haxscramper | E.g. most dead-simple question |
| 19:17:19 | disruptek | you use your .nimble file as per usual. |
| 19:17:39 | disruptek | it's a fair question, though, i will update the readme. |
| 19:17:51 | * | D_ joined #nim |
| 19:18:18 | haxscramper | So basically https://documentation.divio.com/how-to-guides/ are not present in readme |
| 19:18:28 | haxscramper | It has a good reference guide |
| 19:18:48 | haxscramper | It might benefit from explanation of reasoning behind, maybe some cool tricks |
| 19:18:50 | disruptek | i think the video shows this. |
| 19:18:59 | disruptek | but like i said, i need to produce some new demos. |
| 19:19:11 | haxscramper | I personally watched video one time |
| 19:19:18 | disruptek | it was easier when i was streaming; people could pop in and watch it work. |
| 19:19:39 | haxscramper | I can't spend all time looking for particular second in the video where it shows somehting, regardless of how great it is |
| 19:21:13 | * | narimiran quit (Ping timeout: 246 seconds) |
| 19:21:51 | disruptek | i understand; you want me to sell you my product that i made for myself, but you want to be spoon fed, wined and dined, on your terms. |
| 19:22:02 | haxscramper | Well |
| 19:22:03 | haxscramper | |
| 19:22:23 | disruptek | if you're satisfied with nimble, use nimble. nimble needs more users. |
| 19:22:35 | haxscramper | I'm not /exactly/ satisfied with nimble |
| 19:22:41 | disruptek | nimph has remained virtually unchanged for a year. it doesn't really need attention. |
| 19:23:01 | haxscramper | But at the same time I don't /exactly/ know how to make nimph useful to me |
| 19:23:13 | disruptek | honestly, that's not my problem. |
| 19:23:16 | haxscramper | Well |
| 19:23:24 | haxscramper | okay, let's stop them |
| 19:23:26 | haxscramper | then* |
| 19:23:29 | disruptek | i am happy to talk about it, but don't make me guess what your problem is with nimble. |
| 19:23:29 | * | narimiran joined #nim |
| 19:24:33 | haxscramper | If you made nimph mostly for yourself then I guess, yes, it doesn't really matter |
| 19:24:47 | haxscramper | I just had an impression you wanted people to start using it |
| 19:24:58 | disruptek | hah, no. i gave up on that. |
| 19:25:06 | disruptek | i also made nimph for araq. |
| 19:25:10 | disruptek | and shashlick. |
| 19:25:18 | haxscramper | alright, just some misunderstaning I guess |
| 19:25:46 | haxscramper | misunderstaning on my side* |
| 19:25:48 | disruptek | but, shashlick got sucked into the bottomless pit of nimble and is now on hiatus. and araq thinks my opinion is only slightly less worthless than my code, so... |
| 19:26:22 | haxscramper | alright, I will then try to implement some of the things I wrote above |
| 19:26:25 | haxscramper | after docgen |
| 19:26:39 | * | PMunch quit (Quit: leaving) |
| 19:27:39 | disruptek | are you talking about gram? |
| 19:27:57 | * | haxscramper left #nim ("ERC (IRC client for Emacs 27.1)") |
| 19:28:04 | * | haxscramper joined #nim |
| 19:28:14 | haxscramper | No, I'm talking about how-to guides for nimph |
| 19:28:24 | haxscramper | gram is just a matter of writing some code |
| 19:28:28 | disruptek | oh, don't worry about it. i will get to it eventually. |
| 19:28:44 | disruptek | it's silly to ask someone who doesn't need/use software to write technical docs for it. |
| 19:29:24 | disruptek | nimph has a much more sophisticated dependency analysis system than nimble. |
| 19:29:47 | disruptek | it knows about tags and what they mean, how they relate to nimble versions, where and where they occurred. |
| 19:30:00 | haxscramper | Well, whatever, though I would say in my experience /the best/ how-to guides can be written by someone how is learning how to use things themselves. |
| 19:30:02 | disruptek | it knows about github, forks, remotes, clones, etc. |
| 19:30:19 | disruptek | it knows how to upgrade/downgrade projects so that all dependencies remain satisfied. |
| 19:30:47 | disruptek | it knows how to work with projects that may have multiple nimblePaths, local deps, not-quite-local deps, and any combination of the same. |
| 19:30:51 | haxscramper | And again - I'm not talking about /techical/ documentation, I'm talking about this spoon-fed, sliced/diced approach that you don't partuclarly seem to be a fond of |
| 19:31:58 | haxscramper | so I said I will look into writing this part |
| 19:32:01 | disruptek | i think the problem i have with "spoon fed" is that i would never presume to tell you how to work. |
| 19:32:15 | disruptek | nimph is a tool. how you wield it is up to you. |
| 19:33:13 | haxscramper | yeah, but just any tool I need to know /at least one/ way to wield it, and I would bet you have something to tell about this? |
| 19:33:38 | disruptek | if you have access to the README.md you can see many examples of usage. |
| 19:33:54 | disruptek | if you don't, you might glean something from `nimph --help` i guess. |
| 19:33:59 | haxscramper | But anyway, this is starting to go in circles, but I think I understand your position on this much better now |
| 19:34:32 | disruptek | nimph is opinionated: the opinion is that package management shouldn't even be a thing. |
| 19:34:45 | disruptek | it's stupid, hateful, terrible business and we should outlaw it. |
| 19:43:50 | FromDiscord | <dom96> Hopefully soon we’ll get lockfiles into nimble. That should improve it significantly. |
| 19:47:15 | leorize | lockfiles require too much compiler changes tbh |
| 19:48:06 | disruptek | weird. |
| 19:48:17 | disruptek | scramper: do you want to drop 1.2 support? i'm fine with that, btw. |
| 19:48:23 | disruptek | from gram, i mean. |
| 19:48:28 | haxscramper | yes |
| 19:48:29 | * | u0_a216 joined #nim |
| 19:48:38 | disruptek | just update the ci in .github |
| 19:48:47 | leorize | we should just move the package manager into the compiler instead of this weird "nimble development requires compiler changes" scheme |
| 19:49:05 | haxscramper | Though I stated to backfix hmisc, but this is easier |
| 19:49:10 | disruptek | i have a new gitnim that works with the dist if you wanna fuck with it. |
| 19:49:29 | disruptek | it's probably a little buggy. |
| 19:49:43 | haxscramper | disruptek: by they way, I remembered you wanted to see pathutils in stdlib |
| 19:49:54 | * | abm joined #nim |
| 19:50:12 | disruptek | yeah, i know you have a paths lib. |
| 19:50:18 | haxscramper | good |
| 19:50:32 | disruptek | maybe i'll use it in ups instead of nimph's stuff. |
| 19:51:07 | haxscramper | It is a bit raw wrt. to API, but it should be usable |
| 19:54:13 | FromDiscord | <dom96> @leorize lock files shouldn’t need any changes to the compiler |
| 19:54:28 | * | u0_a216 quit (Ping timeout: 246 seconds) |
| 19:54:49 | disruptek | i can't even find the lockfiles pr anymore. |
| 19:56:09 | leorize[m] | @dom96 #12104 |
| 19:56:10 | disbot | https://github.com/nim-lang/Nim/pull/12104 -- 3Add changes required by Nimble lock file support |
| 19:57:43 | * | leorize quit (Ping timeout: 240 seconds) |
| 19:58:59 | * | leorize joined #nim |
| 19:59:20 | leorize | is status still working on lock files or have they bailed? |
| 20:00:01 | disruptek | leorize: araq insists that the compiler itself not access the network, so except for that requirement, i agree that the pm should be in the compiler. |
| 20:00:52 | * | leorize quit (Remote host closed the connection) |
| 20:01:06 | FromDiscord | <mratsim> "Hopefully soon", I think I finally understand that `soon` in Nim is in Valve Time (yes I'm also guilty of this). |
| 20:01:19 | * | leorize joined #nim |
| 20:01:26 | leorize | not accessing the network is easy, just assign the task to an external tool |
| 20:01:37 | disruptek | yes. |
| 20:02:02 | leorize | and hey, if that tool have a defined interface to the compiler, then you just invented vendoring :P |
| 20:02:08 | FromDiscord | <mratsim> A new RFC: https://github.com/nim-lang/RFCs/issues/312 |
| 20:02:09 | disbot | ➥ Renaming openarray |
| 20:02:19 | FromDiscord | <mratsim> bikeshed at will |
| 20:03:43 | * | clyybber quit (Quit: WeeChat 3.0) |
| 20:06:11 | leorize | it would also be nice if analysis expands to closure, so that we can capture openArray[T]/var parameters |
| 20:06:21 | leorize | but that's out of scope of your rfc i believe |
| 20:07:08 | * | vicfred joined #nim |
| 20:07:23 | * | waleee-cl quit (Read error: Connection reset by peer) |
| 20:07:43 | * | waleee-cl joined #nim |
| 20:08:17 | haxscramper | disruptek: CI is green, I fixed your suggestions, though `toDotNodeId` converter is still marked as `export` directly, because I don't think it is necessary to abstract it |
| 20:08:42 | disruptek | great, merge that fucker please. |
| 20:09:13 | FromDiscord | <mratsim> @leorize, yeah i want a plain bikeshedding RFC |
| 20:09:28 | FromDiscord | <mratsim> the last part is just to plant ideas in mind for a future RFC 😉 |
| 20:10:48 | disruptek | i guess status doesn't want to help with dist. |
| 20:10:49 | FromDiscord | <Clyybber> why would the compiler need to change for lockfiles |
| 20:11:00 | FromDiscord | <Clyybber> the compiler shouldn't care about package management tbh. |
| 20:11:13 | FromDiscord | <Clyybber> It gets a filesystem with files. That should be plenty enough of information |
| 20:11:49 | disruptek | we already distribute the pm with the compiler. |
| 20:12:28 | FromDiscord | <Clyybber> Yes. But they are perfectly fine seperate |
| 20:12:54 | FromDiscord | <Clyybber> Which is better because it enables diversity for the package managers |
| 20:13:00 | FromDiscord | <Clyybber> otherwise nimph wouldn't exist |
| 20:13:04 | disruptek | yeah, fat lot of good that has done us. |
| 20:13:21 | FromDiscord | <mratsim> @disruptek, dist? |
| 20:13:23 | disruptek | i would rather have no package manager, honestly. |
| 20:13:29 | disruptek | !repo disruptek/dist |
| 20:13:31 | disbot | https://github.com/disruptek/dist -- 9dist: 11a nim distribution 👑 15 14⭐ 0🍴 |
| 20:13:40 | disruptek | neither you or arne accepted my invite. 😢 |
| 20:13:54 | FromDiscord | <Clyybber> disruptek: Exacttly why its great to not merge it into the compiler |
| 20:14:04 | FromDiscord | <mratsim> ah, it's likely that we were drown in mails |
| 20:14:59 | FromDiscord | <mratsim> We do want to improve tooling though, we are reaching the limit of makefiles, and git submodules are also somewhat error prone |
| 20:16:05 | FromDiscord | <Clyybber> @mratsim I added a small comment to the PR, since we will need two kinds of slice types |
| 20:16:12 | FromDiscord | <Clyybber> One that can be copied and one that cannot be |
| 20:16:30 | leorize | Clyybber: no they are not fine separate. The compiler has a different notion of nimbleDir than the package manager |
| 20:16:46 | FromDiscord | <Clyybber> The compiler shouldn't have any notion of nimbleDir IMO |
| 20:16:54 | FromDiscord | <Clyybber> nimble isn't even using nimbleDir anymore |
| 20:17:02 | FromDiscord | <Clyybber> afaik |
| 20:17:02 | leorize | but user experience suffers |
| 20:17:12 | FromDiscord | <Clyybber> How so? |
| 20:17:17 | FromDiscord | <mratsim> @Clyybber isn't the copy/nocopy derived from T? I'm only talking about openarray here |
| 20:17:23 | disruptek | nimble doesn't use nimblePath; it uses nimbleDir, which is a different thing that the compiler doesn't know about. |
| 20:17:44 | leorize | Clyybber: `nimble install` won't give you the "install then you can prototype" experience |
| 20:18:34 | FromDiscord | <Clyybber> Because you have to add it as a dependency? |
| 20:19:03 | FromDiscord | <Clyybber> @mratsim Yeah, but one would still want two kinds of slices because one might want to guarantee that a slice keeps being a view into the original container |
| 20:19:17 | leorize | because I would need a .nimble before I can do any writing is what I mean |
| 20:19:21 | FromDiscord | <Clyybber> and the copyable slice is kind of like a background optimization |
| 20:19:33 | FromDiscord | <Clyybber> leorize: Yeah, understood |
| 20:19:42 | disruptek | leorize: use nimph for your prototyping. 😁 |
| 20:19:47 | FromDiscord | <Clyybber> Seems like thats solved with config file |
| 20:19:58 | leorize | so practically you end up needing to use `nimble c`, `nimble build`, etc. |
| 20:20:15 | FromDiscord | <Clyybber> IMO we just need wildcard support |
| 20:20:17 | leorize | Clyybber: uh, no |
| 20:20:37 | disruptek | what is wildcard support? |
| 20:20:54 | leorize | there's a dependency graph associated with packages |
| 20:20:57 | FromDiscord | <Clyybber> --path:somepathtoanimbledir/ |
| 20:20:58 | FromDiscord | <mratsim> @Clyybber when you copy a pointer, it keeps being a pointer to the original location |
| 20:21:08 | FromDiscord | <Clyybber> @mratsim I am talking about deep copies |
| 20:21:17 | leorize | if the compiler solve it wrong your precious `nim c` stops working |
| 20:21:21 | disruptek | we have that in nimblePath afaik. |
| 20:21:27 | FromDiscord | <mratsim> but openarrays have deepCopy? |
| 20:21:47 | leorize | I don't know what is this weird fascination with not having the package manager in the compiler |
| 20:22:13 | disruptek | it would make more sense if there was a richer api to worry about between the two. |
| 20:22:24 | FromDiscord | <Clyybber> @mratsim Imagine if the regular slice index returned non-copyable views, it would break all kinds of code because the returned slice cannot escape its owner |
| 20:22:33 | FromDiscord | <Clyybber> So to solve that we deep copy the slice whenever needed |
| 20:22:34 | disruptek | then separating them could ensure they stay true to the api. |
| 20:22:49 | FromDiscord | <Clyybber> But we should give the user the option to prevent that |
| 20:22:56 | FromDiscord | <Clyybber> via a non-copyable slice type |
| 20:23:19 | FromDiscord | <Clyybber> leorize: Not a weird fascination. Just a simple seperation of concerns |
| 20:23:29 | FromDiscord | <mratsim> but now openarray can be returned from a proc |
| 20:23:33 | leorize | it's not, really |
| 20:23:42 | FromDiscord | <Clyybber> Its simply easier for the compiler devs if they are given --paths |
| 20:23:51 | FromDiscord | <mratsim> there is no code that would be broken because you couldn't return openarray from a proc |
| 20:24:02 | FromDiscord | <mratsim> at least until experimental:views |
| 20:24:16 | FromDiscord | <Clyybber> @mratsim But we want to change a[0..10] to return a slice |
| 20:24:29 | FromDiscord | <mratsim> that's why it's in stretch goal |
| 20:24:41 | FromDiscord | <Clyybber> Yeah, I just wanted to add it for brevity |
| 20:24:55 | FromDiscord | <Clyybber> Since its something I discussed with cooldome and araq |
| 20:25:10 | leorize | this is kinda like C++ people refusing the idea of modules, which btw, many of them still don't want that, they think their include system is superior because of the same reason |
| 20:25:40 | FromDiscord | <mratsim> tbh I don't understand the difference between a file and a module |
| 20:25:55 | FromDiscord | <Clyybber> leorize: I simply don't understand why the package manager needs more than --path and maybe wildcards |
| 20:26:11 | leorize | because dependency resolution |
| 20:26:39 | disruptek | i just don't want wildcards that allow for gram-1.0 and gram-1.0.0 and gram-2.0.0. |
| 20:26:48 | disruptek | if it's a flat namespace, make it flat. |
| 20:26:49 | leorize | package A requires "B >= 0.5.0 & < 1.0.0", but you have "B 1.2.0" and "B 0.3.0" installed |
| 20:27:09 | leorize | the package manager will resolve the issue and pick the right version |
| 20:27:19 | FromDiscord | <Clyybber> Yes. Problem solved |
| 20:27:23 | leorize | give it to the compiler? it will mash "A" and "B 1.2.0" together |
| 20:27:32 | FromDiscord | <Clyybber> Huh? |
| 20:27:37 | leorize | now your `nim c` doesn't work |
| 20:27:49 | disruptek | leorize: he wants the pm to edit the nim.cfg. |
| 20:28:07 | disruptek | which is not unreasonable as long as /only/ the pm edits the nim.cfg. |
| 20:28:10 | leorize | you have practically the same issue, just with a larger graph |
| 20:28:26 | leorize | "multiple version of the same package" is a feature that's useful |
| 20:28:34 | FromDiscord | <Clyybber> and the compiler supports it |
| 20:28:51 | leorize | semver is stupid in that it believes a "major" bump is just an increment of a number |
| 20:28:51 | FromDiscord | <Clyybber> by simply using the filesystem structure |
| 20:30:16 | leorize | how does the compiler know which version to pick? |
| 20:31:00 | disruptek | as does nimph. |
| 20:31:00 | disruptek | it could exploit the fs structure better by not versioning directories. |
| 20:31:01 | disruptek | really creepy code. |
| 20:31:02 | disruptek | and it doesn't necessarily do the right thing. |
| 20:31:03 | disruptek | ...which is another reason nimph exists. |
| 20:31:17 | disruptek | of particular concern is shadowed versions such that you remove one and suddenly the compiler is using a different version of a dependency; it's a real problem in nimble. |
| 20:31:18 | FromDiscord | <Clyybber> it doesn't. I understand your issue. You want the compiler to understand versions so you don't have to invoke the package manager |
| 20:31:42 | disruptek | i don't. maybe leorize does. |
| 20:32:17 | FromDiscord | <Clyybber> the argument for quick prototyping doesn't hold up IMO |
| 20:32:27 | disruptek | use dist for that. |
| 20:32:33 | FromDiscord | <Clyybber> because once you are specifying which versions you want to use you are out of the quick prototyping stage |
| 20:32:38 | FromDiscord | <Clyybber> and you might as well invoke the PM |
| 20:32:47 | FromDiscord | <Clyybber> but as I said we could simply use the config for that |
| 20:33:45 | FromDiscord | <Clyybber> which could include --path:pathtonimbledirorwhatever/testes-2.0/ |
| 20:34:45 | disruptek | dist or gitnim could generate a series of `--path="$nimbledir/some-1.0/src/"` statements to stdout and you could append it to your cfg, i guess. |
| 20:35:08 | disruptek | then you simply set nimbledir to dist and you're done. |
| 20:35:56 | disruptek | it still breaks when you have multiple nimblePaths defined, though. |
| 20:38:14 | leorize | Clyybber: let me give you a graph: A depends on "B v1.0.0" and "C v1.2.0", C depends on "B v2.0.0". B has a breaking change from v1 -> v2. How is the compiler gonna handle this? |
| 20:39:07 | FromDiscord | <Clyybber> the .cfg of A includes --path:pathToBv1.0.0 and the .cfg of C includes --path:pathToBv2.0.0 |
| 20:39:32 | giaco | I'm building a nim program that shows no external .so with ldd, but requires them at runtime. "strace -e trace=open ./myprogram" doesn't catch them, how can I list all the required libs? |
| 20:39:40 | leorize | Clyybber: `.cfg`s doesn't mix between packages in Nim |
| 20:39:51 | leorize | they don't even mix between modules |
| 20:39:58 | FromDiscord | <Clyybber> What do you mean? |
| 20:40:15 | leorize | the compiler only load the config of the main file |
| 20:40:38 | FromDiscord | <Clyybber> I don't know what you mean |
| 20:41:22 | leorize | I'm telling you why your .cfg scheme doesn't work |
| 20:41:56 | FromDiscord | <Clyybber> Yeah, I don't get why |
| 20:42:08 | FromDiscord | <Clyybber> Are you telling me that only A.cfg will get read? |
| 20:42:19 | FromDiscord | <Clyybber> and not C.cfg? |
| 20:42:35 | leorize | because if you call `nim c file.nim`, only global configs will be read + `file.nim.cfg` and/or `nim.cfg` in the directory |
| 20:44:00 | leorize | package A here can just be something I installed via `nimble install` to try out |
| 20:44:11 | FromDiscord | <Clyybber> Ah, right. I think we need a way to let A.cfg chain C.cfg then |
| 20:44:41 | FromDiscord | <Clyybber> This needs to be implemented in the compiler |
| 20:45:19 | leorize | giaco: you can't, sadly. I'm planning to write an RFC to favor link-time dynamic linking instead of the current runtime dynamic linking |
| 20:45:43 | leorize | a way out could be to use `{.passL.}` to pass the link flag and drop `{.dynlib.}` |
| 20:47:35 | leorize | @Clyybber: well now you got a problem. Some configuration can't be composed between modules. Realistically only `--path` can be composed, which is why our config resolution works the way it is right now. |
| 20:47:51 | leorize | composed safely* |
| 20:48:26 | FromDiscord | <Clyybber> Hmm, you're right |
| 20:48:59 | FromDiscord | <dom96> @dom96 #12104↵↵See my comments in that PR. |
| 20:49:00 | disbot | https://github.com/nim-lang/Nim/pull/12104 -- 3Add changes required by Nimble lock file support |
| 20:49:16 | FromDiscord | <dom96> (edit) "@dom96 #12104↵↵See" => "@leorize See" |
| 20:49:17 | disbot | https://github.com/nim-lang/Nim/pull/12104 -- 3Add changes required by Nimble lock file support |
| 20:50:40 | leorize | @Clyybber so now you need a new format to only specify paths |
| 20:50:44 | FromDiscord | <Clyybber> leorize: Sounds like we need .path :P |
| 20:50:47 | FromDiscord | <Clyybber> yeah :/ |
| 20:50:54 | leorize | and that's assuming that you want the "vendoring" model |
| 20:51:03 | FromDiscord | <dom96> > because I would need a .nimble before I can do any writing is what I mean↵↵Glad I’m not the only one that cares about this |
| 20:51:16 | leorize | as in all deps got installed in one place in the current project |
| 20:51:31 | FromDiscord | <dom96> This is the only reason Nim is aware of Nimble |
| 20:52:32 | FromDiscord | <Clyybber> leorize: They could be installed anywhere as long as your pathconfigs are set up to point at them |
| 20:52:50 | leorize | they can't be global |
| 20:52:57 | FromDiscord | <Clyybber> why not? |
| 20:53:10 | leorize | the reason is simple, upgrades |
| 20:53:59 | FromDiscord | <Clyybber> can you elaborate? |
| 20:54:25 | leorize | let's revisit our A, which requires "B >= 1.5.0 & < 2.0.0" and "C >= 1.2.0 & < 2.0.0", where C requires "B 2.0.0" |
| 20:55:00 | leorize | now you add an another dep into the list, which is "D", that requires "B >= 1.7.0 & < 2.0.0" |
| 20:55:28 | leorize | now you would want to upgrade to "B 1.7.0" for A since it's still compatible |
| 20:56:34 | leorize | what does that mean? you have to rewrite .path for A, globally affecting everything else |
| 20:57:31 | FromDiscord | <Clyybber> you mean rewriting .path for A affects everything else? But everything else also has a .path which takes priority |
| 20:57:47 | leorize | it affects other projects |
| 20:57:57 | leorize | remember, our packages folder is globally shared |
| 20:58:43 | giaco | leorize: thanks |
| 20:59:08 | * | narimiran quit (Ping timeout: 265 seconds) |
| 20:59:09 | FromDiscord | <Clyybber> leorize: Oh, what I meant is for the dependecies to be global not the configs |
| 20:59:14 | FromDiscord | <Clyybber> A would have its own .path |
| 20:59:36 | FromDiscord | <Clyybber> which does not affect anything not part of A |
| 21:00:08 | FromDiscord | <Clyybber> I meant we can point --paths in a .path of A to someGlobalDirForPackages/Bv.1.7.0 |
| 21:01:33 | leorize | say, you're developing "foo" and "bar", where "foo" imports "A", and "E", which requires "B == 1.5.0", but "bar" imports "A" and "D" |
| 21:04:10 | leorize | when you build "bar.nim", "B" need to be upgraded to a newer version for "A", which rewrites A's ".path" |
| 21:04:48 | leorize | now you `nim c foo.nim`, and you can see the problem |
| 21:05:29 | FromDiscord | <Clyybber> but As .path would still be fine for A |
| 21:05:43 | FromDiscord | <Clyybber> since A requires B >= 1.5.0 & < 2.0.0 |
| 21:05:45 | leorize | foo.nim depends on: A, B 1.5.0, B 1.7.0, E |
| 21:05:59 | leorize | the dep tree is now polluted for foo.nim |
| 21:06:44 | FromDiscord | <Clyybber> Why wouldn't foo.nim simply depend on A, B 1.7.0, E now? |
| 21:06:49 | leorize | it should only require "B 1.5.0", but because a previous build of "bar" with "package manager" rewrites "A.path" to refer to "B 1.7.0", "foo.nim" now need both B 1.5.0 and 1.7.0 |
| 21:06:53 | FromDiscord | <Clyybber> oh eh |
| 21:07:10 | leorize | E requires "B == 1.5.0", which "foo.nim" depends on |
| 21:07:11 | FromDiscord | <Clyybber> which part of foo requires B == 1.5.0? |
| 21:07:14 | FromDiscord | <Clyybber> ah |
| 21:07:28 | FromDiscord | <Clyybber> But A doesn't require E ? |
| 21:08:24 | * | u0_a216 joined #nim |
| 21:09:02 | leorize | you can see the dep tree: it's foo -> [A -> [B 1.7.0, C -> B 2.0.0], E -> B 1.5.0] |
| 21:09:43 | leorize | but A is compatible with B 1.5.0, so you would want to only need B 1.5.0 in the build to reduce deps |
| 21:10:47 | FromDiscord | <Clyybber> I see. |
| 21:10:47 | leorize | but if the package manager is not used (our scenario is `nim c foo.nim`), A.path won't be updated to use B 1.5.0 |
| 21:11:07 | FromDiscord | <Clyybber> So it would still compile but pull in unneeded deps |
| 21:11:14 | FromDiscord | <Clyybber> Hmm |
| 21:12:46 | FromDiscord | <Clyybber> So we should actually move all .paths to foo, conceptualy |
| 21:13:03 | leorize | now you need to invoke the package manager to build every single thing |
| 21:13:05 | FromDiscord | <Clyybber> So that foo has .path files that define paths for A, C, and E |
| 21:13:09 | leorize | congrats you invented rust |
| 21:13:17 | leorize | cargo* |
| 21:13:28 | FromDiscord | <Clyybber> But the compiler could read these path files |
| 21:13:51 | leorize | yes but if you don't call the package manager you won't get them to begin with, right? |
| 21:14:42 | FromDiscord | <Clyybber> yeah. So you call the PM once to build your depency tree/config/paths |
| 21:14:49 | FromDiscord | <Clyybber> And then you can use the compiler normally |
| 21:15:13 | FromDiscord | <Clyybber> And they communicate via .paths |
| 21:15:40 | * | u0_a216 quit (Ping timeout: 246 seconds) |
| 21:15:47 | FromDiscord | <Clyybber> Which are basically lockfiles |
| 21:15:49 | FromDiscord | <Clyybber> I guess |
| 21:15:50 | leorize | now, to use packages, you end up calling "nimble c", "nimble whatever" all the time because it would just works™ then |
| 21:16:15 | FromDiscord | <Clyybber> you can do that |
| 21:16:27 | FromDiscord | <Clyybber> or you could do nimble reload/nimble setup or whatever |
| 21:16:31 | FromDiscord | <Clyybber> and then just nim c |
| 21:17:10 | leorize | why do that when `nimble c`, `nimble suggest` do the right thing all the time? |
| 21:17:15 | * | u0_a216 joined #nim |
| 21:17:28 | leorize | you've deprecated the `nim` command into a "please never use" command |
| 21:17:56 | leorize | basically this is how gcc, clang, rustc works |
| 21:18:25 | FromDiscord | <Clyybber> But we have .path/.cfg files |
| 21:18:31 | FromDiscord | <Clyybber> So its different |
| 21:18:41 | leorize | and if we want to modularize the stdlib into a collection of packages, what would happen then? you need to call `nimble` to build every damn thing |
| 21:19:35 | leorize | realistically, what will those files do you when you have to call nimble anyway? |
| 21:20:42 | FromDiscord | <Clyybber> yeah nothing. If you only ever call nimble then nimble could do it the C way and pass the paths as cmdline args |
| 21:21:10 | FromDiscord | <Clyybber> So what you propose is to move this version resolving mechanism into the compiler |
| 21:21:36 | FromDiscord | <Clyybber> Is it also the compilers duty to download packages? |
| 21:22:40 | FromDiscord | <Clyybber> There are just so many ways to do package management |
| 21:22:41 | leorize | it could be, but if you hate the compiler accessing the internet then it's easy to outsource that |
| 21:23:00 | FromDiscord | <Clyybber> I don't feel its a smart idea to put THE ONLY ONE WAY into the compiler |
| 21:23:20 | FromDiscord | <Clyybber> Maybe the compiler needs to have a package manager option then |
| 21:23:31 | FromDiscord | <Clyybber> So that it can call "nimble reload" when invoked |
| 21:23:58 | FromDiscord | <Clyybber> Or package managers should be some kind of compiler plugin |
| 21:25:05 | * | u0_a216 quit (Ping timeout: 240 seconds) |
| 21:25:49 | leorize | I think by this time we should agree that packages are as fundamental of an unit as modules |
| 21:26:03 | leorize | it's everywhere, the moment you use 3rd-party code you have packages |
| 21:26:18 | Zevv | disruptek gave up joining your discussions? |
| 21:26:19 | * | u0_a216 joined #nim |
| 21:26:34 | leorize | so I'd argue that it need first class support the same way we support modules |
| 21:26:39 | FromDiscord | <Clyybber> packages are arbitrary |
| 21:27:10 | FromDiscord | <Clyybber> we can do it on a folder granularity |
| 21:27:24 | FromDiscord | <dom96> Nim already has a concept of a "package" |
| 21:27:31 | FromDiscord | <dom96> but it's something that has grown organically |
| 21:27:37 | FromDiscord | <dom96> and probably could be improved |
| 21:27:46 | FromDiscord | <dom96> A package is any folder with a .nimble file inside it |
| 21:27:56 | FromDiscord | <Clyybber> Yeah, thats fine |
| 21:28:10 | giaco | after Nim in action, is there any other Nim book / long organic prosaic reading that you would recommend? |
| 21:29:10 | FromDiscord | <inv> Are there any smart logic how NIm select kind for field-check or it is just fieldname<=>kind mapping at the moment ? |
| 21:29:28 | FromDiscord | <inv> (edit) "NIm select" => "Nim selects" |
| 21:30:06 | FromDiscord | <Clyybber> leorize: IMO packages should be a first class concept to the PM which then translates these packages into folder/path concepts which are first class for the compiler |
| 21:30:26 | FromDiscord | <Clyybber> This is simple and allows us to exchange the way that packages are handled more easily |
| 21:30:39 | leorize | folders don't have dependency |
| 21:30:59 | FromDiscord | <Clyybber> which is why we translate packages into folder/path concepts |
| 21:31:41 | FromDiscord | <Clyybber> with something similar to timothees prefix path RFC we would have a way to specify dependencies for folders/modules using paths |
| 21:32:14 | disruptek | a directory is a package. |
| 21:32:14 | disruptek | it's just that simple. |
| 21:32:27 | disruptek | i'm at the point where i don't really care anymore as long as the compiler doesn't change in some stupid way that makes it impossible for me to do the right thing. |
| 21:32:47 | disruptek | i have more interesting arguments to make on more interesting software. |
| 21:33:25 | FromDiscord | <Clyybber> We only need to agree on how the PM and the compiler communicate |
| 21:33:41 | disruptek | shashlick established that long ago. |
| 21:34:08 | FromDiscord | <Clyybber> Yes. leorize doesn't like it because it makes nimble c work always |
| 21:34:17 | FromDiscord | <Clyybber> and nim c only work after invoking the PM once |
| 21:34:17 | disruptek | i don't see how. |
| 21:34:25 | * | filcuc_ joined #nim |
| 21:34:26 | FromDiscord | <Clyybber> so he says users will always prefer nimble c |
| 21:34:45 | disruptek | well, nimph can produce the cfg and then the compiler runs. just that simple. |
| 21:34:53 | FromDiscord | <Clyybber> Yep |
| 21:34:58 | disruptek | if users want nimble, they can use nimble. |
| 21:35:10 | FromDiscord | <Clyybber> leorize's point is that they can't use nim c itself |
| 21:35:15 | FromDiscord | <Clyybber> So they will use nimble c |
| 21:35:23 | disruptek | eventually, nimph will also produce your test runner and a builder (or the same thing). |
| 21:35:26 | FromDiscord | <Clyybber> or nimph c |
| 21:35:35 | FromDiscord | <Clyybber> and afterwards they may be able to use nim c too |
| 21:35:36 | disruptek | no, you don't need nimph c. |
| 21:35:49 | FromDiscord | <Clyybber> nimph init/reload/buildDependencyTree or whatever |
| 21:35:59 | disruptek | well what's the solution? you already said you don't want the pm to interface with the compiler. |
| 21:36:15 | disruptek | obviously, it has to run before the compiler if the compiler won't invoke it, right? |
| 21:36:16 | FromDiscord | <Clyybber> Yeah, I don't see a better solution |
| 21:36:21 | FromDiscord | <Clyybber> And its not a real problem |
| 21:36:25 | disruptek | i agree. |
| 21:36:35 | FromDiscord | <Clyybber> It doesn't hurt the user if they run nimble c instead of nim c |
| 21:36:44 | FromDiscord | <Clyybber> but if they want to nim c |
| 21:36:56 | FromDiscord | <Clyybber> then obviously they must first invoke the PM once |
| 21:37:01 | disruptek | nim c /could/ conceivably work with a static .nimph. pragma. |
| 21:37:05 | disruptek | but i wouldn't hold my breath. |
| 21:37:16 | FromDiscord | <Clyybber> what woudl that be? |
| 21:37:42 | FromDiscord | <dom96> IMO the "nimble c" vs "nim c" distinction is a nice one to have |
| 21:37:46 | disruptek | {.nimph: "https://github.com/disruptek/gram#<2.0.0".} |
| 21:38:31 | FromDiscord | <Clyybber> leorize's point is (sorry leorize if I misunderstood you), that the average user doesn't care about the difference between compiler and PM and wether they are seperated |
| 21:38:58 | FromDiscord | <Clyybber> So it would be less confusing for them if there were one right way TM |
| 21:39:07 | FromDiscord | <Clyybber> which would be nim c |
| 21:39:22 | disruptek | sure, well that's clear. |
| 21:39:42 | FromDiscord | <Clyybber> I guess the compiler could read a config option telling him to invoke a PM |
| 21:39:53 | FromDiscord | <Clyybber> so that nim c first calls nimble reload |
| 21:40:04 | disruptek | madness. |
| 21:40:14 | FromDiscord | <Clyybber> yeah, its a bit mad |
| 21:40:20 | disruptek | why don't we just agree that not all users need to use the same workflow. |
| 21:40:36 | FromDiscord | <Clyybber> disruptek: I mean this would be seperate of workflow I suppose |
| 21:40:50 | giaco | I'm a newbie, but I like to nimble c. It would be even better if nimble would install packages in local folder next to nimble file by default instead of ~/.nimble |
| 21:40:51 | FromDiscord | <Clyybber> Users coudld also set it to git --init --recursive |
| 21:40:52 | disruptek | especially when it may, for some users, include software that sucks a big, fat, throbbing, glistening, horse cock. |
| 21:40:54 | FromDiscord | <dom96> Is it really that confusing to learn the difference between `nim c` and `nimble c`? |
| 21:41:14 | leorize | it's not about having to learn them |
| 21:41:24 | FromDiscord | <dom96> giaco: you can enable local deps and have Nimble do this |
| 21:41:25 | disruptek | giaco: see --localdeps option to nimble. |
| 21:41:26 | leorize | it's about "why the hell would I need two different thing?" |
| 21:41:30 | FromDiscord | <lqdev> so i'm in progress of trying to port pan, my animation program, to a newer version of nim and my engine, and i got this strange error: |
| 21:41:39 | FromDiscord | <lqdev> sent a code paste, see https://play.nim-lang.org/#ix=2LHb |
| 21:41:41 | giaco | yeah, that's why I added "by default" |
| 21:42:06 | FromDiscord | <lqdev> and the offending call is generated using `newCall` from a macro |
| 21:42:14 | FromDiscord | <lqdev> problem is, i don't use named parameters anywhere… |
| 21:42:50 | FromDiscord | <dom96> leorize: most people indeed wouldn't need both |
| 21:42:59 | disruptek | giaco: i think if you `mkdir nimbledeps` it defaults to localdeps mode. |
| 21:43:18 | disruptek | i'm not super well-versed on nimble, though. |
| 21:44:38 | disruptek | lqdev: are you using it in a template? |
| 21:44:49 | FromDiscord | <lqdev> no, in a proc |
| 21:45:02 | FromDiscord | <lqdev> i think this may be related to the recent change that proc params are now typed |
| 21:45:02 | leorize | if you add "compiler commands" into nimble, then, uh... did you just invent compiler and package manager in one software? |
| 21:45:12 | FromDiscord | <lqdev> do i need to genSym them now? right now i'm just generating nnkIdents |
| 21:45:50 | FromDiscord | <Clyybber> leorize: Well fork nimble and remove nimble c. Then users can't get confused anymore |
| 21:45:53 | FromDiscord | <lqdev> oh wait |
| 21:46:01 | * | u0_a216 quit (Ping timeout: 265 seconds) |
| 21:46:03 | FromDiscord | <Clyybber> .s/Well/Well one could |
| 21:46:06 | FromDiscord | <lqdev> i'm not generating them, just copying them over from the previous proc's signature |
| 21:46:10 | FromDiscord | <inv> I am confused, why nimble run --d:release abc and nimble --d:release run abc compiles in release, but I definitely see the different |
| 21:46:12 | FromDiscord | <lqdev> that could be the issue but idk |
| 21:46:17 | FromDiscord | <inv> (edit) "I am confused, why nimble run --d:release abc and nimble --d:release run abc compiles in release, but I definitely see the different ... " added "in speed" |
| 21:46:28 | disruptek | lqdev: are you sure you're not passing an identDefs to the proc? |
| 21:46:55 | disruptek | you didn't really give us enough paste to work with, i think. |
| 21:46:57 | FromDiscord | <Clyybber> leorize: And even with nimble c, nimble is basically just passing it over |
| 21:47:05 | leorize | @Clyybber my point is you should never need this arbitrary distinction |
| 21:47:10 | leorize | UX-wise it's terrible |
| 21:47:11 | FromDiscord | <lqdev> disruptek: yeah |
| 21:47:14 | disruptek | yes, it serves only to confuse things. |
| 21:47:31 | FromDiscord | <lqdev> disruptek: this is the macro https://github.com/liquidev/pan/blob/master/src/pan/luaapi.nim#L118 |
| 21:47:54 | FromDiscord | <dom96> leorize: it's how cargo/rustc works too afaik |
| 21:48:13 | disruptek | dom96: well, then it /must/ be the right design. |
| 21:48:50 | disruptek | use repr when composing strings based on symbols. |
| 21:49:08 | disruptek | whatfer gensym reasons. |
| 21:49:48 | disruptek | you need to desem that procedure.name i'll bet. |
| 21:49:54 | FromDiscord | <Clyybber> leorize: I dunno. there are simply multiple ways to do PM. |
| 21:50:14 | disruptek | ident(repr procedure.name) is sufficient. |
| 21:50:15 | FromDiscord | <Clyybber> And we can still patch over the "terrible" UX by providing passthrough PM commands for compiling |
| 21:50:37 | FromDiscord | <dom96> disruptek: not saying it's the right design, but there is merit for it and it works fine for them. |
| 21:50:53 | disruptek | dom96: this is not rust. |
| 21:51:02 | disruptek | i won't argue with you as if it were. |
| 21:51:05 | disruptek | that would be stupid. |
| 21:51:08 | FromDiscord | <Clyybber> disruptek: You agree with dom96 though |
| 21:51:21 | disruptek | it happens from time to time. |
| 21:51:21 | disruptek | he's not a complete idiot. |
| 21:51:23 | leorize | @Clyybber then what's the point of even showing the `nim` command to the user? |
| 21:51:45 | FromDiscord | <Clyybber> leorize: There is none. Depending on your PM |
| 21:51:53 | FromDiscord | <dom96> lol |
| 21:51:59 | FromDiscord | <lqdev> disruptek: de-symming the original proc params' identDefs solved the problem |
| 21:52:04 | FromDiscord | <Clyybber> If your PM does not provide those passthrough commands then there is. |
| 21:52:09 | FromDiscord | <lqdev> stdlib really needs a desym proc or something like that |
| 21:52:21 | disruptek | clyybber: here's the problem: the job that the pm does only needs to be done when the env changes. |
| 21:52:21 | disruptek | ergo, i want to run it only at those times. |
| 21:52:21 | FromDiscord | <Clyybber> @lqdev Got recently added |
| 21:52:27 | disruptek | i want it to manage only those changes. |
| 21:52:28 | FromDiscord | <lqdev> @Clyybber is it in 1.4? |
| 21:52:38 | FromDiscord | <Clyybber> disruptek: Yes, but the PM can figure it out. |
| 21:52:45 | disruptek | of course it can, yes. |
| 21:52:52 | disruptek | but i don't want to run it except at those times. |
| 21:52:55 | FromDiscord | <Clyybber> @lqdev Don't think so |
| 21:53:07 | disruptek | the rest of the time, either the pm will have produced a build program for me, or i will build using the compiler. |
| 21:53:16 | FromDiscord | <Clyybber> Yeah |
| 21:53:23 | disruptek | i plan to ship a package manager with my projects in the future. |
| 21:53:37 | disruptek | it will include testing, ci, performance analysis, everything. |
| 21:53:45 | disruptek | because this shit is fucking ridiculous. |
| 21:54:07 | FromDiscord | <lqdev> @Clyybber where's the proc on devel? looking through macros in devel docs, can't find anything. |
| 21:54:17 | FromDiscord | <Clyybber> Oh, maybe it wasn't merged yet |
| 21:54:36 | disruptek | i think maybe planetis-m authored it but i don't recall. |
| 21:54:54 | disruptek | anyway, you can write your own desym to do the same thing. or steal it from any of my macro-heavy projects. |
| 21:55:25 | FromDiscord | <Nisha|💻⭐> What's a desym?- |
| 21:55:34 | FromDiscord | <Clyybber> disruptek: How is it ridiculous? We basically all agree that theres a conflict between UX and flexibility |
| 21:55:52 | disruptek | nisha: turning a symbol into an identifier. |
| 21:56:07 | disruptek | clyybber: because this is not the useful part of software sharing. |
| 21:56:15 | FromDiscord | <Nisha|💻⭐> Thanks! |
| 21:56:24 | disruptek | none of it adds value. |
| 21:56:32 | FromDiscord | <Clyybber> disruptek: Well it's a discussion. |
| 21:56:43 | FromDiscord | <Clyybber> good UX does add value |
| 21:56:48 | FromDiscord | <Clyybber> flexibility does too |
| 21:56:56 | leorize | @Clyybber: the reason that I'm critical about the "just work without having to declare dependency while prototyping" flow is that if we ever want to turn stdlib into a collection of packages, this is the exact problem |
| 21:57:07 | disruptek | yes, and that's why i'd supply everything you need to test, document, build, install, use my software. |
| 21:57:23 | disruptek | you supply the compiler. i'll supply everything else. |
| 21:57:51 | FromDiscord | <Clyybber> leorize: If the stdlib gets turned into packages they should be treated as packages |
| 21:58:00 | FromDiscord | <Clyybber> So of course you would then need a package manager |
| 21:58:00 | leorize | users want `echo "Hello, world!"` or `import re` to work without declaring dependencies |
| 21:58:14 | disruptek | and they will, with dist. |
| 21:58:15 | FromDiscord | <Clyybber> well then we shouldn't split the stdlib into packages |
| 21:58:37 | disruptek | gitnim now manages the distribution, too. at least, the version in 1.5.1. |
| 21:59:03 | disruptek | though it's probably buggy as fuck. |
| 21:59:11 | leorize | splitting stdlib into packages is realistically the best way to develop it |
| 21:59:24 | FromDiscord | <Clyybber> But if you split it into packages |
| 21:59:27 | leorize | `os` gets a breaking change? release `os 2.0.0` |
| 21:59:48 | FromDiscord | <Clyybber> then its also realistic that users will want to specify dependecies |
| 22:00:02 | disruptek | and they can do. |
| 22:00:12 | FromDiscord | <Clyybber> but things like dist could still provide a fallback |
| 22:00:30 | leorize | they can, but why would they when they are just experimenting? |
| 22:00:52 | FromDiscord | <Clyybber> if they are just experimenting they will use the fallback |
| 22:00:52 | FromDiscord | <dom96> I don't think splitting the stdlib from the language is realistic |
| 22:01:00 | leorize | when they want to turn it into a project they call "nim init-package" and suddenly they got a project dir with all the deps they were using added |
| 22:01:03 | FromDiscord | <dom96> For one thing, the compiler depends on a lot of the stdlib |
| 22:01:19 | disruptek | dom96: that's why i want dist. |
| 22:01:19 | FromDiscord | <Clyybber> leorize: Well, yeah? What else would they want/ |
| 22:01:26 | disruptek | i want to be able to bring modern software into the compiler. |
| 22:01:51 | FromDiscord | <dom96> right... |
| 22:01:55 | FromDiscord | <Clyybber> If I clone a package I would want to knwo what deps it has |
| 22:01:56 | leorize | @Clyybber well I'm telling you why having no-config build is useful |
| 22:02:24 | leorize | if it doesn't have .nimble or whatever, it's not a package |
| 22:02:29 | leorize | simple as that |
| 22:02:38 | disruptek | a package is any directory with a .nim in it. |
| 22:02:42 | disruptek | simple as that. |
| 22:03:20 | FromDiscord | <Clyybber> leorize: Ok, but whats the problem? They can still import re because the global .nim cfg has a fallback |
| 22:03:40 | * | haxscramper quit (Remote host closed the connection) |
| 22:03:55 | FromDiscord | <Clyybber> And once they create a package they can choose to rely on people having the same cfg as them (bad) or they can specify that they actually need re |
| 22:04:49 | leorize | I'm just picking `re` as an arbirtary example |
| 22:04:52 | FromDiscord | <dom96> all packages need some metadata |
| 22:05:09 | disruptek | git provides this. |
| 22:05:24 | leorize | @Clyybber if say, it's arraymancer, which have its own deps |
| 22:05:45 | FromDiscord | <dom96> depending on git is a bad idea |
| 22:06:02 | leorize | then even in "no config" situation the compiler still has to resolve the deps |
| 22:06:27 | FromDiscord | <Clyybber> ah, so the issue is that when you experiment |
| 22:06:33 | FromDiscord | <Clyybber> without creating a package/config |
| 22:06:36 | FromDiscord | <Clyybber> and do import arraymancer |
| 22:06:43 | FromDiscord | <Clyybber> it won't work without the PM |
| 22:06:50 | leorize | yep, it's a completely realistic use case |
| 22:07:05 | leorize | you can say "but dist will bundle it all" |
| 22:07:14 | FromDiscord | <dom96> no you can't |
| 22:07:15 | disruptek | well, it's only true because of histerical reasons. |
| 22:07:32 | FromDiscord | <Clyybber> We can also teach people to use the PM |
| 22:07:32 | leorize | but I say why would you need that when the compiler would be able to resolve all deps correctly? |
| 22:08:19 | disruptek | i don't even know what point you're trying to make. |
| 22:08:31 | disruptek | the deps are already resolved for you in dist. |
| 22:08:32 | FromDiscord | <dom96> The compiler should simply enable a dependency tree to be specified |
| 22:08:33 | disruptek | that's the idea. |
| 22:08:47 | FromDiscord | <dom96> and compile the code using that information |
| 22:08:59 | FromDiscord | <Clyybber> disruptek: Take dist out of the equation for a moment |
| 22:09:04 | disruptek | okay. |
| 22:09:25 | disruptek | all the compiler is trying to do is map strings to files. |
| 22:10:18 | disruptek | dom96: you're not wrong, but it's also not hard to produce a simpler interface. |
| 22:10:23 | FromDiscord | <Clyybber> leorize: So either we teach people to use nimble c for such cases |
| 22:11:09 | FromDiscord | <Clyybber> or we make nim c invoke PM code through some means (plugin?, just calling a configurable command) |
| 22:11:14 | FromDiscord | <Clyybber> or we merge the PM into nim |
| 22:11:27 | FromDiscord | <Clyybber> UX wise 2 and 3 are basically the same |
| 22:11:59 | disruptek | you're missing the fact that we only need the pm when the env changes. |
| 22:12:40 | FromDiscord | <Clyybber> disruptek: Thats for the PM to figure out. It's not relevant here IMO |
| 22:13:03 | FromDiscord | <Clyybber> The PM can always simply do nothing if the env didn't change |
| 22:14:26 | FromDiscord | <Clyybber> With option 2 one could do "import somePkgTHatsNotInMyDeps" |
| 22:14:29 | FromDiscord | <Clyybber> run nim c |
| 22:14:49 | FromDiscord | <Clyybber> and nim c would invoke the PM which could then automatically add somePkgThatsNotInMyDeps to your .nimble |
| 22:14:57 | FromDiscord | <Clyybber> which would be nice for UX |
| 22:14:57 | leorize | a compiler plugin is not out of the question, I heard that IC is supposed to enable external plugins |
| 22:16:11 | FromDiscord | <dom96> at that point there'd be no need for the PM to add it to your .nimble file |
| 22:16:20 | FromDiscord | <Clyybber> why not? |
| 22:16:38 | FromDiscord | <dom96> because the compiler would know what package it needs apparently |
| 22:16:52 | FromDiscord | <Clyybber> No, the compiler does a prepass |
| 22:16:53 | FromDiscord | <dom96> the PM would just need to put it in a lock file |
| 22:17:00 | FromDiscord | <Clyybber> Then tells the PM what it needs |
| 22:17:04 | FromDiscord | <Clyybber> or what it can't find |
| 22:17:10 | FromDiscord | <Clyybber> then the PM adds that |
| 22:17:18 | FromDiscord | <Clyybber> and the compiler continues with the added paths |
| 22:17:26 | FromDiscord | <dom96> huh, that sounds more complex than it's worth |
| 22:17:29 | * | xet7 joined #nim |
| 22:19:39 | FromDiscord | <Clyybber> with a compiler plugin the prepass wouldn't be needed |
| 22:19:56 | FromDiscord | <Clyybber> it wouldn't be strictly needed without a compiler plugin either |
| 22:20:17 | FromDiscord | <Clyybber> but then you would end up invoking the PM executable potentially multiple times |
| 22:21:32 | FromDiscord | <tomck> Can i store arbitrary data in a `string`? Or does it need to be null terminated |
| 22:22:19 | FromDiscord | <ElegantBeef> Nim's strings do not require being null terminated |
| 22:22:35 | FromDiscord | <ElegantBeef> You can store all the characters of the rainbow in them |
| 22:22:39 | * | Vladar quit (Quit: Leaving) |
| 22:23:02 | FromDiscord | <Clyybber> disruptek: a global .cfg with a fallback to dist would solve this, but not magically add somePkgThatsNOtInMyDeps to your .nimble/deps obviously |
| 22:23:30 | FromDiscord | <mratsim> Be careful of what you wish, you will summon ponies |
| 22:23:31 | FromDiscord | <dom96> In any case, we've discussed this a lot already. Here is an issue about this topic https://github.com/nim-lang/nimble/issues/654 |
| 22:23:38 | disbot | ➥ Removing Nim's knowledge of Nimble ; snippet at 12https://play.nim-lang.org/#ix=2LHv |
| 22:23:46 | FromDiscord | <Clyybber> but if you just always invoke nimble c then this is solved too |
| 22:24:06 | FromDiscord | <ElegantBeef> @mratsim so it is true what they say, if you want to know if someone is a bronie just way and they'll tell you |
| 22:24:14 | FromDiscord | <Clyybber> because nimble can invoke the compiler, see if it errors with missing file, add it as a dep, and try again |
| 22:25:26 | FromDiscord | <Clyybber> @dom96 Yeah, but there were some new arguments today |
| 22:26:33 | FromDiscord | <dom96> What were the new arguments? |
| 22:26:57 | disruptek | just leave it the way it is. i run the pm to manage my env. i run the compiler to compile my software. |
| 22:26:57 | FromDiscord | <Clyybber> that nimble and nim should be one because of UX |
| 22:26:57 | disruptek | if users cannot figure that out, they can go work with rust lifetimes. |
| 22:27:04 | FromDiscord | <Clyybber> lol |
| 22:27:34 | * | NimBot joined #nim |
| 22:27:47 | FromDiscord | <dom96> pretty sure that was suggested before |
| 22:27:53 | FromDiscord | <dom96> maybe not in that issue though |
| 22:28:41 | FromDiscord | <dom96> History shows that these kinds of features separate out of the compiler |
| 22:28:48 | FromDiscord | <dom96> nimpretty used to be in the compiler IIRC |
| 22:29:36 | FromDiscord | <Clyybber> In general having a way to get a dependency tree from the compiler is not a bad idea though |
| 22:29:41 | FromDiscord | <Clyybber> And probably already possible |
| 22:30:45 | FromDiscord | <Clyybber> It could at least allow nimble c to automatically add dependencies to .nimble |
| 22:30:53 | FromDiscord | <Clyybber> Which is a small UX improvement |
| 22:30:57 | FromDiscord | <dom96> meh |
| 22:31:05 | FromDiscord | <Clyybber> but its probably not worth it rn |
| 22:31:14 | FromDiscord | <dom96> What's important is for Nimble to be able to tell Nim a tree of paths |
| 22:31:16 | FromDiscord | <Clyybber> I'm torn, so I'm voting for doing nothing RN |
| 22:31:51 | FromDiscord | <dom96> so that a single "compilation unit" can depend on multiple versions of the same package |
| 22:32:23 | FromDiscord | <Clyybber> Yeah. That isn't possible RN |
| 22:32:26 | * | D_ quit (Ping timeout: 264 seconds) |
| 22:33:07 | FromDiscord | <Clyybber> right? |
| 22:40:30 | leorize[m] | dom96 go is the only language that perform this bundling afaik |
| 22:40:51 | FromDiscord | <Clyybber> yeah, I don't know any other either |
| 22:41:47 | leorize[m] | it worked pretty well for them, and any kinks left appear to be because of backward compat |
| 22:42:17 | leorize[m] | you do `go build` and it just works |
| 22:44:47 | * | u0_a216 joined #nim |
| 22:49:21 | leorize | you never once need to learn `goc` or whatever, there is only one `go` and it does everything correctly |
| 22:49:47 | leorize | I think in the UX aspect of PM go nailed it |
| 22:55:33 | FromDiscord | <tomck> sent a code paste, see https://play.nim-lang.org/#ix=2LHB |
| 22:56:01 | * | u0_a216 quit (Ping timeout: 264 seconds) |
| 22:57:34 | FromDiscord | <tomck> The idea is that I could use packetTags in a macro to generate a bit switch statement that'll automatically parse packets, instead of having to make sure that the right tag number is switched to the right type in multiple places, which can lead to subtle bugs |
| 23:00:20 | FromDiscord | <ElegantBeef> Is this for something like an RPC? |
| 23:01:19 | FromDiscord | <tomck> nah this is for gamedev atm, different packets for sharing different kinds of state |
| 23:01:35 | FromDiscord | <ElegantBeef> Well i mean i made this for gamedev https://github.com/beef331/nettyrpc |
| 23:01:45 | FromDiscord | <ElegantBeef> P2P automated packet creation |
| 23:02:56 | FromDiscord | <ElegantBeef> It's semi similar just without manual creation of packets, and uses procedures for generating the serialization logic |
| 23:04:21 | * | tane quit (Quit: Leaving) |
| 23:04:24 | FromDiscord | <tomck> I see, this is some super wizard shit lol, is {.networked.} your own pragma? |
| 23:04:29 | FromDiscord | <ElegantBeef> Yea |
| 23:04:39 | FromDiscord | <tomck> I'll take a look at this after i've slept, too much for night time lol |
| 23:04:48 | FromDiscord | <tomck> thanks though, might end up using this as is |
| 23:05:03 | * | leorize quit (Ping timeout: 240 seconds) |
| 23:05:06 | FromDiscord | <ElegantBeef> What it does is add a packet emitter, and a procedure that gets called from the network client |
| 23:05:48 | FromDiscord | <ElegantBeef> So if you're the local client inside the proc call it sends the information that this procedure got, which then you receive and deserialize invoking it the procedure as non local |
| 23:06:05 | FromDiscord | <dom96> leorize: that is not the impression I got with Go's package management |
| 23:06:26 | FromDiscord | <dom96> There are a lot of criticism about it and many different actual package managers out there for it with differing implementations |
| 23:07:49 | * | xet7 quit (Remote host closed the connection) |
| 23:08:52 | giaco | what could it mean if a program runs correctly with --gc:arc, but goes "SIGSEGV: Illegal storage access. (Attempt to read from nil?)" if compiled with default gc? |
| 23:08:58 | leorize[m] | do you mind sourcing some of the criticisms? |
| 23:09:23 | * | xet7 joined #nim |
| 23:10:25 | * | xace quit (Ping timeout: 264 seconds) |
| 23:11:14 | FromDiscord | <dom96> Maybe I'm not up to date on the latest developments, it seems there were some changes relatively recently |
| 23:11:49 | FromDiscord | <dom96> but when the new vgo stuff was released a lot of people seemed pissed |
| 23:12:01 | * | leorize joined #nim |
| 23:13:15 | leorize[m] | it was a breaking change, someone will be pissed |
| 23:13:32 | leorize[m] | the ecosystem stabilized afaik |
| 23:14:05 | FromDiscord | <ElegantBeef> @tomck sorta want to rewrite that so i'll send you a new impl if i get it done |
| 23:14:06 | FromDiscord | <dom96> Does that mean `dep` is a thing of the past? |
| 23:14:12 | leorize | giaco: can you describe the code you're dealing with? are you doing FFI or anything? |
| 23:14:18 | FromDiscord | <lytedev> is there a reasonable way to go from string to byte seq/array and back? |
| 23:15:14 | mipri | string <> seq[byte] isn't a good idea because strings have, for a less expensive FFI, a guaranteed trailing NUL byte |
| 23:15:30 | leorize | @dom96 yea `mod` is now the thing |
| 23:15:42 | mipri | you can get openArray[byte] from a string with .toOpenArray(), or by passing it to such a parameter, but to go the other way you need to copy |
| 23:15:51 | * | xace joined #nim |
| 23:15:58 | FromDiscord | <lytedev> then why in the world does the base64 module primarily handle strings? |
| 23:16:36 | FromDiscord | <lytedev> encode should return a string and decode should take a string, but that should be it... |
| 23:16:43 | FromDiscord | <ElegantBeef> !eval echo cast[seq[byte]]("hello") |
| 23:16:43 | leorize | @lytedev because someone didn't thought of `openArray[byte]` and/or `openArray[char]` at the time |
| 23:16:45 | NimBot | @[104, 101, 108, 108, 111] |
| 23:16:57 | FromDiscord | <lytedev> ahhh ok |
| 23:17:02 | giaco | leorize yeah, I'm testing gstreamer bindings for nim |
| 23:17:05 | leorize | @lytedev you should open a bug for it |
| 23:17:07 | FromDiscord | <ElegantBeef> Where is the issue with the nul termination? |
| 23:17:09 | FromDiscord | <lytedev> wellp. that should do it. lol thanks |
| 23:17:12 | * | a_b_m joined #nim |
| 23:17:19 | mipri | you can get openArray[byte] from a string with .toOpenArray(), or by passing it to such a parameter, but to go the other way you need to copy |
| 23:17:24 | FromDiscord | <lytedev> @leorize best place to do that is the GitHub repo? |
| 23:17:33 | leorize | ElegantBeef: it's an issue when the string makes its way to FFI |
| 23:17:38 | mipri | string <> seq[byte] isn't a good idea because strings have, for a less expensive FFI, a guaranteed trailing NUL byte |
| 23:17:53 | leorize | @lytedev yep |
| 23:17:58 | FromDiscord | <lytedev> will do - thanks |
| 23:18:01 | FromDiscord | <ElegantBeef> Well i was just asking where it pops up 😄 |
| 23:18:09 | mipri | string -> cstring conversion |
| 23:18:17 | FromDiscord | <dom96> leorize: I wouldn't be surprised though if `go build` is just a thin wrapper around various separate tools which include a binary that deals with package management |
| 23:18:25 | mipri | if strings have a guaranteed trailing NUL byte, then string -> cstring doesn't incur a copy |
| 23:18:36 | mipri | and they do, so it doesn't. But you have to pay for that in other conversions. |
| 23:19:19 | leorize | dom96: in go case it's actually built-in, but that's semantics |
| 23:19:25 | * | abm quit (Ping timeout: 240 seconds) |
| 23:19:46 | leorize | what matters is that there's only one command to do everything |
| 23:20:04 | leorize | there's no `goc` that have seperated flags that you need to learn |
| 23:20:16 | leorize | there's only one `go` |
| 23:20:27 | leorize | prototype? `go build` |
| 23:20:36 | leorize | a package? `go build` |
| 23:20:51 | FromDiscord | <lytedev> https://github.com/nim-lang/Nim/issues/16688 -- issue for base64 and openArray[byte] dealings |
| 23:20:52 | disbot | ➥ The base64 module should deal in openArray[byte] instead of strings |
| 23:20:57 | leorize | compilation to some embedded setup? `go build` |
| 23:20:58 | FromDiscord | <lytedev> thanks for coming to my ted talk |
| 23:22:20 | * | oddp joined #nim |
| 23:23:05 | leorize | dom96: I want to see a future where the `nim` binary could do this too |
| 23:23:10 | * | PMunch joined #nim |
| 23:23:11 | leorize | where `nim c` is all you ever need |
| 23:25:33 | leorize | it makes bootstrapping much easier too tbh |
| 23:25:40 | leorize | you just need `go` to bootstrap |
| 23:26:07 | leorize | compared to `rust` scheme of cargo + rustc needed to even compile rustc |
| 23:30:09 | * | a_b_m quit (Quit: Leaving) |
| 23:42:20 | * | abm joined #nim |
| 23:44:46 | * | filcuc_ quit (Ping timeout: 246 seconds) |
| 23:47:37 | * | jkiesian quit (Ping timeout: 264 seconds) |
