| 00:00:19 | * | Tanger quit (Quit: Leaving) |
| 00:03:28 | mipri | !eval let x = [5, 0, 1, 5]; var n = 0; (for i in 1 .. x.len: n.inc x[^i]); echo n |
| 00:03:30 | NimBot | 11 |
| 00:20:02 | * | D_ quit (Ping timeout: 258 seconds) |
| 00:21:05 | * | D_ joined #nim |
| 00:48:24 | * | hoijui quit (Ping timeout: 244 seconds) |
| 00:52:47 | * | fputs joined #nim |
| 00:55:44 | * | nickster quit (Quit: The Lounge - https://thelounge.chat) |
| 01:02:14 | * | Tanger joined #nim |
| 01:03:49 | * | nickster joined #nim |
| 01:13:17 | * | fputs quit (Read error: Connection reset by peer) |
| 01:39:20 | * | a_b_m quit (Quit: Leaving) |
| 02:01:09 | disruptek | great. |
| 02:12:01 | * | cgfuh quit (Quit: WeeChat 2.9) |
| 02:12:19 | * | cyraxjoe joined #nim |
| 02:19:36 | * | krux02 quit (Remote host closed the connection) |
| 02:50:11 | * | fputs joined #nim |
| 03:41:06 | FromGitter | <deech> When exposing a Nim API that uses `gc:orc` to C do I need to initialize and tear down a GC? |
| 03:44:28 | disruptek | no. |
| 03:46:29 | FromGitter | <deech> I thought orc used some kind of mark-sweep to break up cycles. |
| 03:47:44 | disruptek | it does, but it runs on dead memory when it is freed via the usual arc methodology. |
| 03:50:49 | FromGitter | <deech> Right so in most cases resources are statically tracked but I still need to have a mark-sweep GC spun up just in case, no? `{.acyclic.}` is not the default. |
| 03:51:42 | FromGitter | <deech> I guess I don't get what "runs on dead memory" means ... |
| 03:52:52 | disruptek | orc looks at the memory that is being freed. it tries to break cycles, which allows more memory to be freed. when you notate .acyclic. you are telling the compiler that it need not worry about cycles in that type. |
| 03:53:37 | disruptek | dead memory is memory that is slated for destruction but not yet returned to the allocator. |
| 03:55:37 | disruptek | if you won't have cycles, then orc is simply an easy way to make your program slower. |
| 03:56:00 | FromGitter | <deech> I'll have to let that percolate. I'm still not seeing why you wouldn't need to spin up a GC in case you hit cycles. |
| 03:56:21 | disruptek | i dunno what "spin up a gc" means. |
| 03:57:34 | disruptek | cycles aren't a given, like death and taxes. |
| 03:57:46 | disruptek | they happen as a result of efforts by the programmer. |
| 03:59:20 | * | wasted_youth quit (Quit: Leaving) |
| 03:59:40 | FromGitter | <deech> Like before `arc/orc` if you were exposing a Nim API to C you'd have to `initGC` ( or something like that, I forget exactly now ) before you called an `extern`ed Nim function and the counterpart for stopping the GC when you were done. |
| 04:00:51 | disruptek | sure, but arc/orc are much more elegant. there's no "garbage collector" runtime under arc. |
| 04:01:16 | disruptek | orc is just arc but with a "manual" cycle breaker that runs as dead memory is returned to the allocator. |
| 04:01:51 | disruptek | this is what the code literally compiles to: "manual" memory management with a "manual" cycle collector. |
| 04:02:01 | FromGitter | <deech> Ah good ... so that's where my confusion is ... I thought the cycle breaker needed some kind of GC running inthe background. |
| 04:02:27 | disruptek | i'm glossing over some stuff but this is essentially what's happening. |
| 04:03:34 | disruptek | and, yes, it's awesome and makes ffi much better and people should stop wasting time with the other memory managers. |
| 04:11:05 | FromDiscord | <ElegantBeef> @guzba So i've come back to my build system and the zip archive is just throwing a hissy fit, but the tarball proc works fine |
| 04:11:26 | * | fputs quit (Quit: Leaving) |
| 04:11:46 | FromDiscord | <ElegantBeef> Also the zip archive worked fine from `inim` so clearly we've got the perfect conditions for an issue to arise |
| 04:13:41 | FromDiscord | <ElegantBeef> Hmm have you tested it with `orc`? |
| 04:14:56 | * | spiderstew_ joined #nim |
| 04:15:20 | FromDiscord | <ElegantBeef> Yea switching back to default GC removed the issue |
| 04:15:38 | * | spiderstew quit (Ping timeout: 264 seconds) |
| 04:16:11 | FromDiscord | <guzba> i have not played with it a ton with orc no, just made sure it passed the basic tests |
| 04:16:28 | FromDiscord | <guzba> interesting that tarball works fine, they are very similar |
| 04:16:43 | FromDiscord | <guzba> is this something i may be able to repro? |
| 04:17:17 | * | a_chou joined #nim |
| 04:17:20 | FromDiscord | <ElegantBeef> I mean it's in my shittly developed unity build system, so i can see if i can make a smaller repro example for you |
| 04:17:47 | FromDiscord | <ElegantBeef> @treeform and you, you left some importing of `prints` in the googleapi library |
| 04:18:11 | FromDiscord | <guzba> if you repro can id def work on it asap, otherwise even just opening an issue to remind me would be cool too |
| 04:18:16 | FromDiscord | <ElegantBeef> Yea |
| 04:18:17 | FromDiscord | <guzba> so i dont forget 😮 |
| 04:18:36 | FromDiscord | <ElegantBeef> I've gotta make a PR for treeform's googleapi and your repo, and get this build system posting to the cloud for my friend |
| 04:18:41 | FromDiscord | <ElegantBeef> So i'll try to get to it 😛 |
| 04:18:59 | FromDiscord | <guzba> sounds good |
| 04:20:22 | FromDiscord | <ElegantBeef> Yep got a repro for this folder |
| 04:20:31 | FromDiscord | <ElegantBeef> https://hatebin.com/qogkjaqfaj |
| 04:21:13 | FromDiscord | <ElegantBeef> I can send you the folder directory aswell |
| 04:21:48 | FromDiscord | <guzba> hm, do the contents matter? im wondering if its just putting the zip in the folder being zipped is misbehaving even tho it shouldnt |
| 04:22:14 | FromDiscord | <ElegantBeef> Well i'm going to give you the file i am using aswell so you can test properly |
| 04:22:20 | FromDiscord | <guzba> ok perfect |
| 04:22:36 | FromDiscord | <guzba> yeah if it repros im good to go |
| 04:22:59 | FromDiscord | <ElegantBeef> Pm'd it for you |
| 04:23:07 | FromDiscord | <ElegantBeef> So there we go should be golden for you to have a repro test |
| 04:38:34 | * | a_chou quit (Quit: a_chou) |
| 04:39:12 | * | Tlangir joined #nim |
| 04:40:05 | * | Tanger quit (Ping timeout: 240 seconds) |
| 04:52:35 | FromDiscord | <treeform> @ElegantBeef I released version 0.1.1 of `googleapi` that should not need print. Print is for debuggin anyways. |
| 04:52:58 | FromDiscord | <ElegantBeef> Ah |
| 04:53:03 | FromDiscord | <ElegantBeef> I assume you closed my pr? |
| 04:55:48 | * | rockcavera quit (Remote host closed the connection) |
| 04:56:29 | FromDiscord | <ElegantBeef> Your nimble file points to the wrong `jwt` library not? |
| 04:56:30 | FromDiscord | <ElegantBeef> (edit) "not?" => "no?" |
| 04:58:34 | FromDiscord | <treeform> oh that might be let me check |
| 04:58:41 | * | hnOsmium0001 joined #nim |
| 05:01:30 | FromDiscord | <treeform> I am using I switched to using https://github.com/yglukhov/nim-jwt/ because it works on linux without linking to OpenSSL. |
| 05:01:43 | FromDiscord | <treeform> I am always havving issue with OpenSSL on linux. |
| 05:02:33 | FromDiscord | <treeform> I have updated the nimble file and pushed a new release |
| 05:04:42 | * | Tlangir quit (Read error: Connection reset by peer) |
| 05:06:31 | * | Tanger joined #nim |
| 05:06:57 | FromDiscord | <ElegantBeef> Thank you |
| 05:07:59 | disruptek | you can check it against my google lib, too. |
| 05:08:14 | disruptek | i mean, the jwt impl. |
| 05:09:28 | FromDiscord | <treeform> is it in nimble? |
| 05:09:33 | FromDiscord | <treeform> does it use openSSL? |
| 05:09:44 | FromDiscord | <ElegantBeef> Surprisingly disruptek's googleapi is in nibmle |
| 05:10:55 | FromDiscord | <treeform> disruptek's is more complete, but it's auto generated from API files, I think I could not get it to work last time. |
| 05:11:16 | FromDiscord | <ElegantBeef> Yea i cannot get yours to work from a thread so, take that 😛 |
| 05:11:25 | disruptek | you said it was too complex. |
| 05:11:26 | FromDiscord | <treeform> I would like for some one to teach me how to use OpenSSL on linux without crashing OpenSSL on linux. |
| 05:11:29 | disruptek | it /is/ more complex. |
| 05:12:00 | FromDiscord | <treeform> @ElegantBeef yeah threads are not supported because global state |
| 05:12:14 | FromDiscord | <treeform> it uses async stuff and I think async+threads is kind of not supported... |
| 05:12:21 | FromDiscord | <ElegantBeef> Ugh |
| 05:12:59 | FromDiscord | <ElegantBeef> This is why we cannot have nice things |
| 05:13:56 | FromDiscord | <treeform> My google API is mainly the connector |
| 05:14:02 | disruptek | async+threads is supported; you just have to get your support from dom96. |
| 05:14:04 | FromDiscord | <treeform> I bet you could rewrite the connected to work with your threads |
| 05:14:31 | FromDiscord | <treeform> If you have a token thing going per thread |
| 05:15:24 | FromDiscord | <ElegantBeef> Well each thread is a monitor for a git path that then gets built by unity when it gets a commit |
| 05:15:43 | FromDiscord | <ElegantBeef> So idk how the token thing going per thread would work |
| 05:16:28 | FromDiscord | <treeform> I don't know sounds complex |
| 05:16:41 | FromDiscord | <treeform> Don't have each thread monitor a git path? |
| 05:16:57 | FromDiscord | <treeform> monitor in one thread and upload in one thread? |
| 05:17:09 | * | hyiltiz quit (Quit: hyiltiz) |
| 05:17:31 | FromDiscord | <ElegantBeef> yea i'll probably just add each path to a queue then upload those all on the main thread |
| 05:17:38 | FromDiscord | <ElegantBeef> Since it can be done async |
| 05:17:41 | FromDiscord | <treeform> yeah that can work too |
| 05:18:10 | disruptek | trust me, async is more complex than threads. |
| 05:18:39 | FromDiscord | <ElegantBeef> Or i could always just use the google rest api |
| 05:18:52 | FromDiscord | <ElegantBeef> But meh seems like the async would be easier |
| 05:19:44 | disruptek | you can swap out the transport in my api if you want to make it sync. |
| 05:19:59 | disruptek | actually, i think it's sync/async. i can't remember. |
| 05:20:03 | FromDiscord | <ElegantBeef> I'll try the async + queue first and go from there |
| 05:29:20 | FromDiscord | <ElegantBeef> Who would've thought that wouldnt work 😄 |
| 05:32:55 | * | njoseph quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 05:33:04 | * | njoseph joined #nim |
| 05:36:07 | FromDiscord | <ElegantBeef> Yea seems i'll have to use disruptek's library if it supports sync, or go to rest |
| 05:36:20 | disruptek | they are all rest. |
| 05:37:14 | FromDiscord | <ElegantBeef> Yea i mean manual rest by that |
| 05:40:42 | disruptek | the transport is in a little lib called rest. |
| 05:40:46 | disruptek | !repo disruptek/rest |
| 05:40:47 | disbot | https://github.com/disruptek/rest -- 9rest: 11REST comfort 15 0⭐ 0🍴 |
| 05:41:07 | disruptek | you can just vendor it and change it or whatever. |
| 06:18:20 | * | hyiltiz joined #nim |
| 06:20:59 | * | habamax joined #nim |
| 06:30:07 | * | vicfred quit (Quit: Leaving) |
| 06:38:23 | * | waleee-cl quit (Quit: Connection closed for inactivity) |
| 06:56:56 | * | krux02 joined #nim |
| 07:13:05 | * | vicfred joined #nim |
| 07:13:09 | * | Tanger quit (Remote host closed the connection) |
| 07:17:39 | * | hnOsmium0001 quit (Quit: Connection closed for inactivity) |
| 07:18:34 | * | narimiran joined #nim |
| 07:23:52 | * | vicfred quit (Quit: Leaving) |
| 07:24:47 | * | vicfred joined #nim |
| 07:27:06 | * | Tanger joined #nim |
| 07:39:58 | * | PMunch joined #nim |
| 08:13:13 | * | Tanger quit (Quit: Leaving) |
| 08:22:54 | * | hoijui joined #nim |
| 08:52:05 | Clonkk[m] | ls -l |
| 08:55:05 | PMunch | Documents |
| 08:55:08 | PMunch | Pictures |
| 08:55:12 | PMunch | .bashrc |
| 09:01:51 | idf | thanks for reminding me my ~/ is a mess |
| 09:02:23 | FromDiscord | <lqdev> beat this https://media.discordapp.net/attachments/371759389889003532/801376062344396800/unknown.png |
| 09:02:39 | PMunch | Oh that was by no means representative of my ~/ |
| 09:03:44 | idf | https://0x0.st/-iVd.png i win |
| 09:03:53 | FromDiscord | <lqdev> dang it |
| 09:04:22 | PMunch | I that's why I store all my `test` stuff in /tmp |
| 09:04:23 | FromDiscord | <lqdev> my home speaks of me being a sony fan https://media.discordapp.net/attachments/371759389889003532/801376567745576980/unknown.png |
| 09:07:45 | FromDiscord | <lqdev> PMunch: me too but sometimes i'm too lazy to cd there |
| 09:18:16 | * | EastByte quit (Ping timeout: 240 seconds) |
| 09:18:16 | * | kali_ quit (Ping timeout: 240 seconds) |
| 09:18:16 | * | DrWhax quit (Ping timeout: 240 seconds) |
| 09:18:36 | * | EastByte joined #nim |
| 09:18:55 | * | kali_ joined #nim |
| 09:19:27 | * | idf left #nim ("ERC (IRC client for Emacs 27.1)") |
| 09:20:10 | * | DrWhax joined #nim |
| 09:20:27 | * | idf joined #nim |
| 09:32:26 | * | hoijui quit (Ping timeout: 264 seconds) |
| 09:35:09 | * | jkiesian joined #nim |
| 09:41:53 | * | xet7 joined #nim |
| 09:50:30 | ForumUpdaterBot | New thread by Drkameleon: Ignore part of tuple without warnings, see https://forum.nim-lang.org/t/7403 |
| 09:54:45 | FromDiscord | <ElegantBeef> Nice forum response lq 😄 |
| 09:55:04 | FromDiscord | <lqdev> edited. |
| 09:55:07 | * | Vladar joined #nim |
| 09:55:31 | FromDiscord | <lqdev> idk why but i always forget to add something immediately and edit my post subsequently |
| 09:56:01 | FromDiscord | <ElegantBeef> As do i, although i was just commenting that we basically said the same thing followed with a pragma solution |
| 09:57:20 | FromDiscord | <ElegantBeef> Dont suggest to use `used` there as not using inject breaks tuple unpacking |
| 09:57:37 | FromDiscord | <ElegantBeef> https://play.nim-lang.org/#ix=2MFl |
| 09:57:53 | FromDiscord | <ElegantBeef> https://play.nim-lang.org/#ix=2MFm |
| 09:58:00 | FromDiscord | <ElegantBeef> I assumed so but was uncertain |
| 10:02:58 | FromDiscord | <ElegantBeef> Wonder if it's considered a bug that `_` in templates get's a gensym |
| 10:03:13 | PMunch | I'd say so |
| 10:03:18 | PMunch | It should just be ignored.. |
| 10:03:49 | FromDiscord | <mratsim> `_` is a valid identifier, so it should be gensymmed. |
| 10:04:05 | FromDiscord | <ElegantBeef> It's valid but unusable |
| 10:04:42 | FromDiscord | <mratsim> I declare `const _ = Slice[int]()` (well something similar) in Arraymancer to workaround generic symbol resolution. |
| 10:04:58 | FromDiscord | <mratsim> And it shouldn't collide with _ in tuples |
| 10:05:09 | FromDiscord | <mratsim> or when people do `for _ in 0 ..< 10:` |
| 10:05:13 | FromDiscord | <ElegantBeef> Oh it works for consts |
| 10:05:31 | FromDiscord | <ElegantBeef> That's unusual and i'd argue shouldnt be allowed but meh |
| 10:05:33 | FromDiscord | <mratsim> but if you don't want gensym in template use {.durty.} |
| 10:05:40 | FromDiscord | <mratsim> dirty |
| 10:05:45 | FromDiscord | <ElegantBeef> Ah there |
| 10:05:49 | FromDiscord | <ElegantBeef> A proper solution 😄 |
| 10:06:48 | PMunch | Well I might want the rest to not be dirty |
| 10:06:55 | PMunch | Only the _ to not get gensymed |
| 10:06:55 | FromDiscord | <mratsim> probably we need a "Bestiary of pitfalls and monsters hiding in Nim symbol resolution" |
| 10:07:24 | FromDiscord | <mratsim> if you use something in a generic proc, everything will be gensymmed anyway. |
| 10:08:19 | FromDiscord | <mratsim> but what was your original problem with gensymmed _? |
| 10:09:55 | FromDiscord | <ElegantBeef> The forum post was using it for tuple unpacking in a template |
| 10:10:28 | FromDiscord | <mratsim> Insert Boromir "One shall not tuple unpack" in a template |
| 10:11:14 | FromDiscord | <mratsim> Yeah so here I agree, "_" is already special cased for tuple unpacking, and it has a specific AST node. |
| 10:11:46 | FromDiscord | <mratsim> the "symbolization" pass should skip it. |
| 10:12:44 | FromDiscord | <ElegantBeef> For consistencies sake i really dont think it should ever be the identifier of any accessible variable |
| 10:13:33 | FromDiscord | <mratsim> If you solve generic early symbol resolution, I'm all for it |
| 10:13:53 | FromDiscord | <ElegantBeef> I can barely spell generic early symbol resolution |
| 10:13:56 | FromDiscord | <ElegantBeef> Never mind solve it |
| 10:14:42 | FromDiscord | <mratsim> Otherwise this is the most ergonomic solution to this problem: https://github.com/nim-lang/Nim/issues/6387 |
| 10:14:46 | disbot | ➥ Generics proc + macros: identifier resolution happens before macros ; snippet at 12https://play.nim-lang.org/#ix=2yGv |
| 10:20:03 | FromDiscord | <ElegantBeef> I'm too dumb or tired to even suggest a joke solution |
| 10:20:05 | FromDiscord | <ElegantBeef> Buh bye |
| 10:31:52 | narimiran | if somebody would like to correct and improve my english before we publish it: https://github.com/nim-lang/website/pull/255/files |
| 10:31:54 | disbot | ➥ add "Nim Community Survey 2020 Results" post |
| 10:38:01 | * | cgfuh joined #nim |
| 10:41:00 | idf | https://github.com/nim-lang/website/pull/255/files#diff-bbd1b480084974615e6b7acb4084a32c08147f4fcf36fc19bd17d70c7736b7a6R79 shouldn't it be "we hope that" |
| 10:41:00 | disbot | ➥ add "Nim Community Survey 2020 Results" post |
| 10:43:33 | narimiran | idf: it should :) |
| 10:48:47 | * | Gustavo6046_ joined #nim |
| 10:49:14 | * | Gustavo6046 quit (Ping timeout: 246 seconds) |
| 10:50:56 | * | Gustavo6046_ is now known as Gustavo6046 |
| 11:34:30 | * | cvoxel joined #nim |
| 11:45:48 | * | letto quit (Quit: Konversation terminated!) |
| 11:47:29 | * | letto joined #nim |
| 11:53:37 | * | wasted_youth joined #nim |
| 12:13:12 | * | Torro joined #nim |
| 12:50:30 | * | jkiesian_ joined #nim |
| 12:50:39 | * | jkiesian quit (Remote host closed the connection) |
| 12:50:40 | * | jkiesian_ is now known as jkiesian |
| 12:55:04 | ForumUpdaterBot | New thread by Ggibson: UFCS and templates, see https://forum.nim-lang.org/t/7404 |
| 12:57:51 | * | vicfred quit (Quit: Leaving) |
| 13:01:15 | * | nickster quit (Quit: The Lounge - https://thelounge.chat) |
| 13:12:56 | * | Gustavo6046 quit (Ping timeout: 240 seconds) |
| 13:13:04 | * | Gustavo6046_ joined #nim |
| 13:15:10 | * | Gustavo6046_ is now known as Gustavo6046 |
| 13:19:34 | * | rockcavera joined #nim |
| 13:21:16 | * | jkiesian_ joined #nim |
| 13:23:56 | * | jkiesian quit (Ping timeout: 265 seconds) |
| 13:23:56 | * | jkiesian_ is now known as jkiesian |
| 13:28:25 | FromDiscord | <exelotl> narimiran: "Improving the tooling is very high on a priority list" -> should be on _the_ priority list |
| 13:28:37 | FromDiscord | <exelotl> otherwise seems all good to me :) |
| 13:28:53 | narimiran | @exelotl thanks, fixed! |
| 13:28:59 | narimiran | (not pushed yet) |
| 13:30:20 | * | nickster joined #nim |
| 13:44:35 | * | abm joined #nim |
| 14:29:35 | ehmry | is it possible to get the nimble package name during evaluation of .nimble? |
| 14:31:56 | * | ehmry found it |
| 14:33:45 | * | Kaivo joined #nim |
| 14:35:55 | * | abm quit (Quit: Leaving) |
| 14:36:18 | * | Torro quit (Quit: bye) |
| 14:41:10 | * | hoijui joined #nim |
| 14:43:17 | FromDiscord | <zetashift> Focus on tooling in 2021🤤 |
| 14:49:19 | * | abm joined #nim |
| 14:53:24 | ehmry | is it possible to import extra libraries into a nimble file, or are the imports fixed? |
| 14:53:56 | FromDiscord | <zetashift> I don't think the imports are fixed |
| 14:54:03 | FromDiscord | <zetashift> since there is no such thing as a .lock file |
| 14:55:58 | FromDiscord | <konsumlamm> narimiran: line 6 should be "which we think is a large enough sample", line 16 should be "received separate sets of questions", line 24 should be "but stopped, the most" (i'm pretty sure at least), line 79 should be "We hope that we'll see", line 117 should be "and/or the ["Nim in Action"]" |
| 14:57:49 | narimiran | @konsumlamm thanks! |
| 15:04:59 | FromDiscord | <haxscramper> ehmry: it is possible to import files into nimble files, but you need to hack it around with `fileExists()` |
| 15:05:00 | FromDiscord | <haxscramper> IN_PROGRESS Database pre-exam consultation |
| 15:05:14 | FromDiscord | <haxscramper> https://github.com/haxscramper/hmisc/blob/b7d7684628a82d443fe54b4300ba4be96d7cc059/hmisc.nimble#L23 |
| 15:07:03 | ehmry | haxscramper: thanks |
| 15:10:31 | * | hoijui_ joined #nim |
| 15:15:40 | * | hoijui_ quit (Quit: Leaving) |
| 15:16:00 | * | hoijui_ joined #nim |
| 15:19:05 | * | waleee-cl joined #nim |
| 15:24:57 | * | hoijui_ quit (Ping timeout: 272 seconds) |
| 15:24:59 | * | hoijui quit (Ping timeout: 260 seconds) |
| 15:39:16 | * | habamax quit (Ping timeout: 265 seconds) |
| 15:40:52 | FromDiscord | <zetashift> Ah I misunderstood the question damn |
| 15:58:52 | * | leorize_ quit (Ping timeout: 268 seconds) |
| 16:17:56 | * | hyiltiz quit (Ping timeout: 265 seconds) |
| 16:21:21 | * | cvoxel quit (Ping timeout: 256 seconds) |
| 16:22:21 | * | hyiltiz joined #nim |
| 16:22:21 | * | hyiltiz quit (Changing host) |
| 16:22:21 | * | hyiltiz joined #nim |
| 16:40:37 | FromDiscord | <konsumlamm> can someone tell me why some stdlib modules have a `when not defined(testing) and isMainModule:` section? should that just be a normal test? |
| 16:41:07 | FromDiscord | <haxscramper> it is easier to put testing code together with lbrary |
| 16:41:22 | FromDiscord | <haxscramper> But when it is compiled for documentation it should not be executed |
| 16:41:51 | FromDiscord | <haxscramper> Technically yes, it should be a separate file with tests |
| 16:42:55 | FromDiscord | <haxscramper> At least that's what I would do myself at least |
| 16:43:01 | FromDiscord | <haxscramper> (edit) removed "least" |
| 16:44:01 | FromDiscord | <konsumlamm> what is the `not defined(testing)` in particular doing? is it not a test then and if so, what exactly is it? |
| 16:47:59 | FromDiscord | <haxscramper> Documentation generator works on file-by-file basis, and defines `testing` symbol, like `-d:release` for example (but does so automatically) |
| 16:48:24 | FromDiscord | <haxscramper> This is used to allow user code to differentiate between normal compilation and documentation generator run |
| 16:49:38 | FromDiscord | <haxscramper> So `nim doc` works really similarly to `nim c` for example, but generates documentation instead of executable and defines `testing` when it runs |
| 16:50:18 | FromDiscord | <haxscramper> You could say that `testing` is defined when you compile in documentation mode (like `release` is for release mode, `debug` is for debug mode and so on) |
| 16:50:30 | FromDiscord | <haxscramper> Oh, shut |
| 16:50:46 | FromDiscord | <haxscramper> `testing` != `documentation` |
| 16:50:57 | FromDiscord | <haxscramper> Yes, sorry, this is completely unrelated |
| 16:52:09 | FromDiscord | <haxscramper> major brain malfunction |
| 16:54:37 | FromDiscord | <K-> What is the main reason to use nim over rust or lisp? |
| 16:56:14 | FromDiscord | <haxscramper> over lisp - statically typed, saner syntax, more expressive DSLs |
| 16:56:50 | FromDiscord | <haxscramper> Whole language is not bent over DSL macros |
| 16:57:04 | FromDiscord | <Rika> though those are still common in nim compared to other languages |
| 16:57:39 | FromDiscord | <haxscramper> I mean whole language syntax is not designed around macros, and instead they are just optional addition |
| 16:58:00 | FromDiscord | <K-> Im trying to find out which one to learn - nim, rust or lisp |
| 16:58:05 | FromDiscord | <lqdev> over rust - easier to write, it has less of a learning curve |
| 16:58:09 | FromDiscord | <konsumlamm> over Rust: GC, better macro/template system, custom operators |
| 16:58:21 | disruptek | give me shelter. |
| 16:58:28 | * | Prestige is now known as Prestige_ |
| 16:58:58 | FromDiscord | <haxscramper> I don't think learning lisp has any value really. I only use it for EMACS, and couldn't find any other use for myself |
| 16:59:18 | FromDiscord | <lqdev> i think you pinged the wrong person :p |
| 16:59:26 | FromDiscord | <haxscramper> oh, yes, sorry |
| 16:59:34 | FromDiscord | <K-> I mean, people praise it as the best language there is |
| 16:59:41 | FromDiscord | <lqdev> eh really it's not |
| 16:59:57 | FromDiscord | <lqdev> every language has its followers |
| 17:00:01 | FromDiscord | <lqdev> and evangelists |
| 17:00:04 | FromDiscord | <Rika> rust just has a lot of those |
| 17:00:05 | FromDiscord | <haxscramper> I really don't like that notion of LISP being "that language that makes you 'better programmer'" |
| 17:00:15 | FromDiscord | <Rika> nim's pretty damn tiny so naturally you'd hear less about it |
| 17:00:27 | FromDiscord | <K-> Thats what I keep hearing in fringe circles |
| 17:00:30 | disruptek | it's pretty much true, though. |
| 17:00:38 | FromDiscord | <konsumlamm> most people do that for their favourite language |
| 17:00:51 | FromDiscord | <K-> No one says Java is the language of the gods though |
| 17:00:56 | FromDiscord | <lqdev> imo lisp's syntax is too awkward for real world programming in 2021. the main reason it's surviving seems to be emacs and other software that already uses it |
| 17:01:07 | FromDiscord | <Rika> because its not the trend anymore |
| 17:01:09 | FromDiscord | <lqdev> @K- probably because not many people like java :p |
| 17:01:10 | FromDiscord | <K-> Lisp has crazy evangelists in the deeper linux sphere |
| 17:01:10 | FromDiscord | <Rika> rust is right now |
| 17:01:13 | FromDiscord | <konsumlamm> but it will make you enlightened!11!! |
| 17:01:18 | FromDiscord | <haxscramper> No, like there is a general notion of THE LISP programming language that I encounter over and over again, and I've never really understood what this all about |
| 17:01:34 | FromDiscord | <konsumlamm> ik |
| 17:02:16 | FromDiscord | <konsumlamm> also, LISP is not the same as the lisp language family which is not the same as common lisp (which is what most people actually mean when saying lisp/LISP), technically |
| 17:02:30 | idf | lisp is awesome |
| 17:02:33 | FromDiscord | <K-> Yeah i meant common lisp |
| 17:02:51 | FromDiscord | <K-> Perhaps I will look at Lisp and Rust |
| 17:03:00 | idf | i like scheme more than common lisp |
| 17:03:13 | FromDiscord | <haxscramper> Though it should be noted that I came to nim after lisp |
| 17:03:24 | FromDiscord | <haxscramper> And at the start all my code looked like lisp |
| 17:03:55 | FromDiscord | <K-> Im in a discord where everyone is a free software evangelist and only uses arch/gentoo/void/nix linux and a tiling window manager. They are telling me I will love Lisp because given that I am in sucha discord, I must have a severe case of autism |
| 17:04:20 | FromDiscord | <haxscramper> Well, there are some concepts in lisp that are really great |
| 17:04:28 | FromDiscord | <haxscramper> Like, really good |
| 17:05:05 | FromDiscord | <haxscramper> So spending some time with lisp is worthwhile, but trying to really learn it is not really useful IMO |
| 17:05:15 | FromDiscord | <lqdev> that made me laugh |
| 17:05:25 | disruptek | the problem is that NIH is even more prevelant in cl circles than it is in nim. |
| 17:05:35 | FromDiscord | <K-> Nih? |
| 17:05:41 | disruptek | yes. |
| 17:05:49 | FromDiscord | <lqdev> saying that a language will "enlighten" you is just… don't |
| 17:05:51 | FromDiscord | <konsumlamm> not invented here? |
| 17:05:53 | disruptek | yes. |
| 17:06:13 | FromDiscord | <konsumlamm> isn't CL more like "invented here"? |
| 17:06:16 | FromDiscord | <K-> thats what they actually say tho. They are also very conspiracy theoristy |
| 17:06:19 | disruptek | i totally think languages enlighten. |
| 17:06:47 | FromDiscord | <lqdev> well you can steal some cool ideas from them and maybe advertise it enough in your favorite language's dev group for it to get implemented or something |
| 17:07:10 | FromDiscord | <lqdev> or maybe when you're learning fundamental concepts something just "clicks" |
| 17:07:30 | FromDiscord | <K-> Like in reality. Language is isomorphic to reality |
| 17:07:33 | FromDiscord | <haxscramper> ~trynim is https://nim-by-example.github.io/ and https://play.nim-lang.org/ |
| 17:07:34 | disbot | trynim: 11https://nim-by-example.github.io/ and https://play.nim-lang.org/ |
| 17:07:46 | FromDiscord | <K-> Are thoughts are shaped by the language in which we speak |
| 17:07:55 | FromDiscord | <Rika> languages will teach you new concepts but they wont keep you feeling enlightened past a few months of using it |
| 17:08:09 | FromDiscord | <K-> Our Reality itself is kind of a reflection on the way we think |
| 17:08:33 | FromDiscord | <K-> (edit) "Are" => "Our" |
| 17:09:03 | FromDiscord | <K-> I mean, I would feel suffocation if I had to code in Basic |
| 17:09:09 | FromDiscord | <K-> Because I know OOP |
| 17:09:23 | disruptek | oop sounds cool. |
| 17:09:24 | FromDiscord | <K-> i imagine similar feelings would occur if you had to code in c++ after knowing lisp |
| 17:09:28 | disruptek | maybe i should learn oop next. |
| 17:09:36 | FromDiscord | <lqdev> @K- what languages did you program in in the past? |
| 17:09:41 | FromDiscord | <K-> I started with Java |
| 17:09:50 | FromDiscord | <K-> Then learned C and Python in Uni |
| 17:10:04 | disruptek | functional languages are truly a different paradigm, though. it's not syntax. |
| 17:10:12 | FromDiscord | <lqdev> Nim might be a good next choice if you wanna come a bit closer to the metal |
| 17:10:32 | FromDiscord | <lqdev> you can start high level and learn lower level concepts as you go |
| 17:10:44 | FromDiscord | <haxscramper> No, not really, it is just a matter of getting used. At some point I've been writing ELISP code while working on C++ project, because I needed to hack emacs to do something, and context switching is not that difficult once you get used to it. |
| 17:11:34 | FromDiscord | <K-> I mean, if LISP can do everything that say C++ can do, then it obviously leaves you with more freedom on hoe to solve a problem |
| 17:11:37 | ForumUpdaterBot | New thread by Kobi: Libdill for large scale concurrency, see https://forum.nim-lang.org/t/7405 |
| 17:11:44 | * | vicfred joined #nim |
| 17:11:47 | FromDiscord | <haxscramper> Then I would recommend sticking to nim, because we have OOP (much simpler one), as well as mostly-imperative-code (like C) |
| 17:12:09 | FromDiscord | <konsumlamm> most languages can do everything most other languages can do |
| 17:12:19 | FromDiscord | <haxscramper> And ability to break holes when needed with raw pointers, or even `void` |
| 17:13:34 | FromDiscord | <haxscramper> E.g. the language is mostly about "we give you the tool, but don't force the particular way of using it" |
| 17:13:45 | FromDiscord | <K-> Ah I see |
| 17:13:58 | FromDiscord | <haxscramper> While giving you all nice and simple tooling like `distinct`, OOP, first-class functions |
| 17:14:13 | FromDiscord | <K-> What about rust? |
| 17:14:16 | FromDiscord | <haxscramper> syntactic macros, ref/ptr/value sematics and so on |
| 17:15:47 | FromDiscord | <digitcrusher> there's also scala if you want to upgrade your coding experience whilst still being able to use your java stuff |
| 17:16:04 | FromDiscord | <haxscramper> Comparatively similar, but is more about forcing particular way of writing code, and has less built-in language features |
| 17:16:27 | FromDiscord | <haxscramper> NOTE: But it is not really different in that regard |
| 17:16:39 | FromDiscord | <K-> Tbh, I like Java, but I think its time is running out |
| 17:17:00 | FromDiscord | <haxscramper> Just shifted towards different end of "language dictates how you write code" vs "you decide how to write code" |
| 17:17:30 | FromDiscord | <haxscramper> Like nim is more "programmer-first", while rust is more "language-first". |
| 17:18:04 | FromDiscord | <haxscramper> LISP is programmer-first all the way down, but for me there is just too much flexibility |
| 17:18:32 | FromDiscord | <haxscramper> Java and go for example could be placed on the other end with "language-first" approach to the max |
| 17:18:46 | FromDiscord | <Clyybber> @timotheecour Are you ok with reverting hintAsError until it has an RFC? |
| 17:18:47 | FromDiscord | <K-> This is an interesting way to classify languages |
| 17:18:48 | FromDiscord | <lqdev> rust is generally more focused towards the compiler forcing you to write code it knows is correct |
| 17:18:49 | * | hoijui_ joined #nim |
| 17:18:49 | * | hoijui joined #nim |
| 17:18:55 | FromDiscord | <lqdev> nim is more lenient in that regard |
| 17:19:06 | FromDiscord | <konsumlamm> the most significant difference to rust is the memory management: Nim mostly uses GC, while Rust has the lifetimes, move semantics and the borrow checker (though both allow you to do manual memory management) |
| 17:19:23 | FromDiscord | <haxscramper> we have arc/orc |
| 17:19:34 | FromDiscord | <konsumlamm> orc is a garbage collector |
| 17:19:37 | FromDiscord | <Rika> yall gotta say that gcs arent necessarily bad |
| 17:19:46 | FromDiscord | <Rika> even rarely bad even |
| 17:19:56 | FromDiscord | <konsumlamm> arc is reference counting, so fine |
| 17:20:02 | FromDiscord | <konsumlamm> GC/refcounting |
| 17:20:23 | FromDiscord | <Clyybber> @timotheecour As its not clear that it has any reasonable usecase, how it interacts with other switches (--verbosity:2), how many cans of worms it opens (--hintAsWarning ??), and most importantly the potential damage it can cause to the ecosystem if people start putting it in their configs and then go bother package authors to change their code to work with the newly created dialect) |
| 17:20:31 | FromDiscord | <konsumlamm> did anyone here say that GC is bad? |
| 17:20:43 | FromDiscord | <Rika> its a common implication |
| 17:20:53 | FromDiscord | <konsumlamm> that was not my intention |
| 17:21:00 | FromDiscord | <Rika> i mean to readers |
| 17:21:08 | FromDiscord | <haxscramper> I don't have enough expertise to put footnotes on this, but I suppose it should be noted that ARC is does a lot of work at compile-time |
| 17:21:39 | disruptek | orc is no more or less a garbage collector than arc. |
| 17:22:22 | disruptek | it's extra logic that can be omitted in the ideal case, which is arc. |
| 17:22:59 | FromDiscord | <konsumlamm> orc is arc with cycle detection, no? |
| 17:23:09 | FromDiscord | <lqdev> @K- well generally as a guy who wanted to switch from Java to a new language and tried Rust before anything else i can say that you'll have a really hard time fighting with the compiler not wanting to compile your code |
| 17:23:34 | FromDiscord | <konsumlamm> arc can leak memory (with ref cycles) while orc shouldn't |
| 17:23:54 | disruptek | yes. |
| 17:25:03 | FromDiscord | <mratsim> Nim has lifetime move semantics and a borrow checker as well. |
| 17:25:04 | FromDiscord | <K-> I see |
| 17:25:14 | FromDiscord | <lqdev> orc works on the same principles as arc does, it just has a bit of extra code injected into the destructor to handle the potential case of cycles in your refs |
| 17:25:23 | FromDiscord | <Rika> oh yeah so are we resetting the days without a gc/language/insensitivity/etc argument counter |
| 17:25:26 | FromDiscord | <konsumlamm> fair, but no lifetime annotations afaik |
| 17:25:32 | FromDiscord | <lqdev> yeah |
| 17:25:46 | FromDiscord | <haxscramper> What is `lent` then? |
| 17:25:46 | FromDiscord | <lqdev> imo lifetime annotations only get in the way of solving your problem |
| 17:25:57 | FromDiscord | <konsumlamm> and rust uses this as the main memory management startegy, while in Nim you usually don't need to care about lifetimes |
| 17:26:04 | FromDiscord | <mratsim> in most case those are inferred by the compiler or you need a ref/GC-ed type anyway |
| 17:26:39 | FromDiscord | <mratsim> lent allows a container to "inverse-borrow" their content. |
| 17:27:04 | FromDiscord | <mratsim> it requires the caller to not escape with the lent object |
| 17:27:16 | FromDiscord | <Rika> i think they mean "isnt lent essentially a lifetime annotation" |
| 17:27:55 | * | natrys joined #nim |
| 17:29:24 | FromDiscord | <mratsim> The main difference between Rust and Nim lifetime is that Nim is about scope. The borrowed value needs to be in a scope in which the container is always valid, this gives a minimum lifetime requirements |
| 17:29:44 | FromDiscord | <mratsim> in Rust you can give precise lifetime requirements but I think it might be overkill. |
| 17:29:53 | FromDiscord | <mratsim> especially in terms of ergonomics. |
| 17:29:54 | FromDiscord | <konsumlamm> i think we all know what i meant, we don't need to discuss the precise definitions |
| 17:30:22 | FromDiscord | <Rika> i mean what hax said, not you |
| 17:33:22 | FromDiscord | <konsumlamm> anyway, does anyone know what `when not defined(testing)` is doing in some stdlib modules? |
| 17:34:19 | FromDiscord | <konsumlamm> or in stdlib tests |
| 17:35:02 | * | krux02 quit (Remote host closed the connection) |
| 17:36:06 | * | PMunch quit (Quit: leaving) |
| 17:36:10 | FromDiscord | <mratsim> I assume that testament (Nim test utilities) is defining "testing" or the test suite is defining "testing". |
| 17:37:31 | FromDiscord | <konsumlamm> what's the point of executing a part of a test while not testing though? or if it's not a test, what is it doing there then? |
| 17:38:17 | FromDiscord | <mratsim> no idea, I don't remember seeing when not defined(testing) better ask @Clyybber or linking to the code in question |
| 17:38:39 | * | leorize joined #nim |
| 17:40:50 | leorize | anyone wanna do a small review on my pipe creation api? https://alaviss.github.io/nim-sys/pipes.html |
| 17:41:42 | FromDiscord | <konsumlamm> examples are in `tests/stdlib/tparsecsv.nim` or `lip/pure/marshal.nim` |
| 17:44:09 | * | jkiesian_ joined #nim |
| 17:47:29 | * | jkiesian quit (Ping timeout: 256 seconds) |
| 17:47:30 | * | jkiesian_ is now known as jkiesian |
| 17:48:11 | * | tane joined #nim |
| 17:50:45 | * | jkiesian quit (Remote host closed the connection) |
| 17:51:19 | * | jkiesian joined #nim |
| 17:52:11 | * | jkiesian quit (Remote host closed the connection) |
| 17:55:42 | ForumUpdaterBot | New thread by Miran: Nim Community Survey 2020 Results, see https://forum.nim-lang.org/t/7406 |
| 18:02:25 | disruptek | leorize: add runnable examples. |
| 18:02:47 | leorize | sure |
| 18:03:09 | leorize | I'm running some extra tests and looks like windows have a different idea of how asymmetric pipes work than linux... |
| 18:07:19 | Q-Master | dom96: look at my PR plz https://github.com/nim-lang/Nim/pull/16769 |
| 18:07:20 | disbot | ➥ Added possibility to cancel the futures using complete() and fail() |
| 18:08:21 | * | hoijui_ quit (Ping timeout: 272 seconds) |
| 18:08:21 | * | hoijui quit (Ping timeout: 272 seconds) |
| 18:08:27 | disruptek | leorize: any fresh balls bugs? |
| 18:08:52 | leorize | nope, seems fine |
| 18:10:45 | disruptek | can these grow proper names? tuple[rd: Rd:type, wr: Wr:type] |
| 18:11:44 | disruptek | The generic parameters Rd and Wr dictates the type of the endpoints. --> s/dictates/dictate/ |
| 18:12:43 | disruptek | "Asynchronous pipe endpoints should only be passed to processes that are aware of them." -- no idea what this means. |
| 18:13:30 | FromDiscord | <hamidb80> Hey everyone. I've worked with dynamic languages like python and javascript. But I want to do some stuff with Nim.↵↵What project do you suggest,? |
| 18:13:32 | disruptek | s/dictate/specify/ -- these aren't typeclasses, they are typedefs. |
| 18:14:06 | disruptek | hamidb80: find something simple to do, do it, and then find something harder. |
| 18:17:54 | leorize[m] | disruptek: it's for when you create a pipe to pass to a child process |
| 18:17:58 | FromDiscord | <mratsim> Something that is interesting for you personally so that you get the motivation to see it through |
| 18:18:36 | leorize[m] | most processes won't expect asynchronous stdin/out, and will either not work or experience reduced performance |
| 18:18:52 | FromDiscord | <mratsim> Don't pick something too hard though, if it has a tuto even in other languages that's fine. |
| 18:18:53 | disruptek | so shouldn't that call default to ffInherit? |
| 18:20:41 | disruptek | why isn't the Pipe a proper object type? |
| 18:24:26 | leorize[m] | disruptek: because you only one the pipe to be inherited by a specific process. ffInheritable makes all process inherits it |
| 18:24:43 | disruptek | fair. |
| 18:24:45 | leorize[m] | want* |
| 18:25:31 | leorize[m] | and it's not a proper object type because a pipe is treated as a file universally and has zero special property other than not being seekable |
| 18:26:14 | disruptek | so how do i compose with it? |
| 18:26:58 | leorize[m] | wdym? |
| 18:27:07 | disruptek | all i have is an anonymous tuple that isn't even a typeclass; i have to define my pipe type in every program? |
| 18:28:02 | disruptek | does the order of rd/wr fields matter? how can i inspect it and confirm that i got it right? |
| 18:29:10 | leorize[m] | I follow convention for this one, the first object is always the read end and the second object is always the write end, similar to all OS |
| 18:29:58 | leorize[m] | I don't give it a typed container because there are no use case for it |
| 18:31:17 | leorize[m] | either you want to write to it or you want to read from it, I haven't seen any case where you want both ends in a single process |
| 18:31:36 | * | xet7 quit (Read error: Connection reset by peer) |
| 18:31:42 | * | xet7_ joined #nim |
| 18:32:06 | leorize[m] | as far as pipes goes, you only keep the end you use, so that when the other process close their end of the pipe you get proper notification |
| 18:32:11 | * | xet7_ is now known as xet7 |
| 18:36:56 | leorize[m] | disruptek: but maybe I can give them special distinct types like (Async)PipeRead and (Async)PipeWrite for type safety in the main process, wdyt? |
| 18:37:31 | disruptek | i think that as simple as it is, it's too complex. i would give them their own types. |
| 18:37:52 | disruptek | types are free and quite useful. |
| 18:38:11 | leorize[m] | what kind of types are you thinking about? |
| 18:38:47 | disruptek | like your distincts. but in general i'm anti-tuple. i think it's smelly. |
| 18:39:33 | * | NimBot joined #nim |
| 18:44:24 | leorize[m] | my experiments with typed containers shows rather bad ergonomics |
| 18:50:24 | Oddmonger | why: « var staticvar {.global.} = 0 » is ok, and not « var staticvar:int {.global.} = 0 } ? |
| 18:51:25 | disruptek | the pragma applies to the symbol and not the type. |
| 18:51:43 | disruptek | var staticvar {.global.}: int |
| 18:54:45 | Oddmonger | i see, thank you |
| 19:05:25 | * | wasted_youth quit (Quit: Leaving) |
| 19:09:54 | disruptek | YOU ARE WELCOME ODD MONGER |
| 19:10:22 | * | xet7 quit (Remote host closed the connection) |
| 19:12:20 | Oddmonger | i've heard this sentence, and it was the voice of Shodan ! |
| 19:27:43 | disruptek | shodan is my maiden name. |
| 19:30:59 | * | wasted_youth joined #nim |
| 19:31:13 | leorize | disruptek: why are your tables misaligned? https://github.com/alaviss/nim-sys/runs/1737150175#step:7:153 |
| 19:31:46 | disruptek | probably because rune lengths are wrong; might also be a feature of ci rendering. |
| 19:31:54 | disruptek | rip emoji |
| 19:32:44 | disruptek | are you +1 on the tables, though? |
| 19:34:24 | disruptek | https://github.com/alaviss/nim-sys/runs/1732653750?check_suite_focus=true#step:7:1940 <-- better demo of the problem. |
| 19:36:04 | disruptek | looks fine on the console. |
| 19:36:20 | leorize | I like the tables, looks neat |
| 19:37:27 | disruptek | to run the full suite locally, i just `env GITHUB_ACTIONS=true balls` |
| 19:45:39 | * | krux02 joined #nim |
| 19:52:43 | FromDiscord | <mratsim> @disruptek @Zevv, I have some crypto research to do and implement for the next 2 weeks so can't work on CPS unless somehow I finish that sooner than expected. |
| 19:55:08 | disruptek | it's cool; thanks for the heads-up. |
| 19:56:46 | leorize | I'm dealing with schrodinger async pipes |
| 19:58:25 | leorize | you look at it correctly and it will start queuing |
| 19:58:59 | leorize | at least windows is consistent, it's never async there |
| 19:59:01 | disruptek | leorize: do you have nim code to determine arch as used in choosenim/nightlies? |
| 19:59:05 | disruptek | lol thanks windows. |
| 19:59:44 | disruptek | all i see in nightlies is .sh |
| 19:59:55 | leorize | yea, I wrote nightlies in bash |
| 20:00:05 | disruptek | chucklehead. |
| 20:00:30 | leorize | Nim has hostCPU for the architecture your binary was compiled for |
| 20:00:50 | leorize | for the native one it differs between OS so `uname` is your best bet |
| 20:01:07 | * | disruptek sighs. |
| 20:01:16 | leorize | or wait until sys/process become a thing, but I wouldn't bet on that now |
| 20:01:39 | disruptek | i'm trying to finish gitnim but it seems my time is better spent walking the dog. |
| 20:03:21 | leorize | I believe choosenim does it by calling gcc :P |
| 20:04:26 | leorize | @mratsim async is a lie for anything that is not sockets as far as I can tell. maybe it's just better to spin up a threadpool |
| 20:07:25 | disruptek | i think my solution is to write my own type and then offer a converter to choosenim for legacy support. |
| 20:08:49 | FromDiscord | <mratsim> Everything is a socket though? :p |
| 20:09:11 | FromDiscord | <mratsim> except maybe stdout |
| 20:15:20 | * | cvoxel joined #nim |
| 20:16:04 | * | cvoxel quit (Client Quit) |
| 20:21:54 | * | natrys quit (Quit: natrys) |
| 20:27:43 | * | Rored1980 joined #nim |
| 20:29:04 | * | jjido joined #nim |
| 20:39:40 | leorize | ok, seems like async do work for unix, but the syscall latency is unpredictable... |
| 20:39:57 | * | vicfred_ joined #nim |
| 20:40:25 | leorize | probably because of all the copying caused by closures |
| 20:40:29 | FromDiscord | <Clyybber> leorize: Do you intend to use io_uring for nim-sys? |
| 20:40:40 | leorize | eventually |
| 20:40:45 | FromDiscord | <Clyybber> nice |
| 20:40:45 | leorize | I need cps to work first |
| 20:41:22 | leorize | cps makes writing this stuff ridiculously simple |
| 20:41:31 | leorize | and io_uring makes callbacks even simpler |
| 20:41:43 | FromDiscord | <Clyybber> are you blocked by cps result? |
| 20:41:54 | * | cyraxjoe quit (Quit: No Ping reply in 180 seconds.) |
| 20:41:55 | * | hyiltiz quit (Remote host closed the connection) |
| 20:42:18 | leorize | yea, I will put up with `ref string/ptr UncheckedArray`, but I don't want `ptr int` |
| 20:42:36 | * | vicfred quit (Ping timeout: 256 seconds) |
| 20:42:36 | * | Gustavo6046 quit (Ping timeout: 256 seconds) |
| 20:42:36 | * | Vladar quit (Ping timeout: 256 seconds) |
| 20:42:39 | FromDiscord | <Clyybber> fair |
| 20:42:58 | * | cyraxjoe joined #nim |
| 20:43:00 | * | Vladar joined #nim |
| 20:43:07 | * | hyiltiz joined #nim |
| 20:43:07 | * | hyiltiz quit (Changing host) |
| 20:43:07 | * | hyiltiz joined #nim |
| 20:46:50 | * | Gustavo6046 joined #nim |
| 20:50:23 | FromDiscord | <konsumlamm> @Clyybber do you happen to know why some tests in the stdlib have a `when not defined(testing)` block (for example `tests/stdlib/tparsecsv.nim` or `lib/pure/marshal.nim`) |
| 20:51:30 | FromDiscord | <Clyybber> @konsumlamm Its so that the CI doesn't test it |
| 20:51:52 | FromDiscord | <Clyybber> in marshal.nim that part is a test to be verified by a human basically :) |
| 20:52:01 | Zevv | @lqdev ping |
| 20:52:21 | FromDiscord | <lqdev> yes |
| 20:52:43 | FromDiscord | <lqdev> did my issue on npeg wake you up? :p |
| 20:52:56 | FromDiscord | <konsumlamm> hmm k |
| 20:53:00 | Zevv | is your proposal "completE" for your personal AST purposes? |
| 20:53:11 | Zevv | like, powerful enough to suit all your needs? |
| 20:53:28 | FromDiscord | <lqdev> well totally |
| 20:53:41 | FromDiscord | <lqdev> it's inspired by PEG.js mostly |
| 20:53:48 | FromDiscord | <konsumlamm> is there a reason to not move those tests to the tests directory (in their respective file)? |
| 20:53:49 | Zevv | ah ok, that makes sense |
| 20:53:54 | FromDiscord | <lqdev> but the API had to be adapted to a statically typed language |
| 20:54:00 | FromDiscord | <Clyybber> @konsumlamm No, its just legacy |
| 20:54:04 | FromDiscord | <lqdev> and NPeg's indexed captures |
| 20:54:55 | Zevv | let me try to let this sink in a bit |
| 20:55:19 | FromDiscord | <konsumlamm> kk, ty |
| 20:55:31 | FromDiscord | <lqdev> well i'd have nothing against you rejecting it, it's just a proposal after all |
| 20:55:34 | Zevv | because what I find when building AST that usually I want/need to go two ways |
| 20:55:42 | Zevv | sometimes you match a child that you want to add to a parent |
| 20:56:01 | Zevv | sometimes you match a parent, which you want to have a stuff from your stack in the node |
| 20:56:20 | Zevv | and quite often I find myself swapping things around because they need to go in a different order |
| 20:56:56 | Zevv | and I'm not sure of all these cases would fit this API |
| 20:57:01 | FromDiscord | <lqdev> hm, i've never encountered the second case, could you give an example? |
| 20:57:22 | FromDiscord | <lqdev> i'm having a hard time visualizing it with my sleepy brain |
| 20:58:00 | Zevv | let me see if I can find something concrete |
| 20:59:26 | Zevv | well, like a function call: foo(a, b(0)). You can't build foo without first parsing the subtrees for a and b(0). So these two typically go on my stack. Then when foo() is complete, I pop those off and put them in the node holding foo() |
| 20:59:30 | Zevv | does that make sense? |
| 20:59:44 | Zevv | for me this very naturally matches the stackiness |
| 21:00:22 | FromDiscord | <lqdev> yeah that makes sense |
| 21:01:03 | FromDiscord | <lqdev> here the two args would go into a capture that you can access from the parent |
| 21:01:29 | FromDiscord | <lqdev> that's what `nodes()` is for |
| 21:01:41 | FromDiscord | <Clyybber> would it help if code block captures had a seperate block that gets run when they get backtracked? |
| 21:02:10 | Zevv | I don't think you want a "oh noes undo this" kind of block. |
| 21:02:26 | Zevv | then there should be a block that gets postponed until the commit is certain |
| 21:02:57 | FromDiscord | <Clyybber> you mean a certain block is more useful? |
| 21:02:59 | Zevv | lqdev: so what is nodes() exactly, it's also a stack but maintained by npeg? |
| 21:03:14 | FromDiscord | <lqdev> Zevv: kind of |
| 21:03:16 | Zevv | Clyybber: undoing stuff is messy, why not only do it when you're sure it neets to be done |
| 21:03:32 | Zevv | lqdev: so what unwinds or pops that stack then? |
| 21:03:41 | Zevv | or should it unwind naturally with the grammar? |
| 21:04:02 | FromDiscord | <lqdev> yeah it would unwind naturally when a rule is exited |
| 21:04:08 | Zevv | makes sense... |
| 21:04:36 | Zevv | hmm. you know, my problem is that the parsing part of npeg was really so ridiculously easy to make. The whole IR language compilation and state machine and all, was big fun. |
| 21:04:44 | Zevv | But the captures, dude, that was suffering for me |
| 21:05:17 | FromDiscord | <lqdev> ouch |
| 21:05:36 | FromDiscord | <Clyybber> Zevv: Yeah, but then npeg has to keep all that stuff around until the certain block is run, no? |
| 21:05:40 | FromDiscord | <lqdev> well again it's just a proposal so if you don't feel up to the task or you think it contradicts your design feel free to close it |
| 21:08:45 | Zevv | oh no I'm really not closing it. This is exactly one of the places where NPeg could use improvement |
| 21:08:51 | Zevv | This, and the thing clyybber just mentioned |
| 21:11:16 | * | Rored1980 quit (Quit: Ping timeout (120 seconds)) |
| 21:18:14 | disruptek | clyybber: so did you find the bug in groups? |
| 21:18:41 | * | hnOsmium0001 joined #nim |
| 21:24:24 | leorize | {.borrow.} doesn't work for generics |
| 21:24:30 | leorize | I hate this |
| 21:24:43 | leorize | for typeclass to be precise |
| 21:25:38 | disruptek | how should it work when the symbol is impl for more than one type? |
| 21:26:34 | leorize | dispatch to the right one? |
| 21:28:59 | leorize | disruptek: I might have to scrap the distinct idea |
| 21:29:12 | leorize | I can't borrow operations from files because they are defined with generics |
| 21:31:56 | FromDiscord | <Clyybber> disruptek: I found that the line `h.add "horses"` causes the hang |
| 21:32:07 | FromDiscord | <Clyybber> but am now working on an arc optimization |
| 21:33:27 | FromDiscord | <Clyybber> leorize: You can implement your own poor mans borrow |
| 21:33:33 | * | narimiran quit (Ping timeout: 265 seconds) |
| 21:34:33 | leorize | and litter the codegen? sounds terrible tbh |
| 21:34:49 | disruptek | make it work. |
| 21:35:08 | disruptek | making it work is rarely terrible, unless it's --hintsAsErrors. |
| 21:35:13 | disruptek | then it's truly horribad. |
| 21:35:57 | FromDiscord | <Clyybber> leorize: No, make it generate `proc/template name(a: TheDistinct) = name(a.distinctBase) |
| 21:36:26 | FromDiscord | <Clyybber> No need to copy the proc body, just call the original proc |
| 21:36:44 | leorize | still litter the codegen with all this calls |
| 21:36:52 | FromDiscord | <Clyybber> ? |
| 21:36:54 | leorize | I can do templates though |
| 21:37:05 | leorize | ideally we should get this fixed somehow... |
| 21:37:06 | FromDiscord | <Clyybber> yeah |
| 21:37:13 | FromDiscord | <Clyybber> of course |
| 21:38:20 | FromDiscord | <Clyybber> disruptek: I hate --hintAsErrors but I love nim c --verbosity:2 --hintAsError:Success ... |
| 21:38:40 | FromDiscord | <Clyybber> failure on success just seems poetic |
| 21:39:38 | leorize | operation failed successfully |
| 21:55:08 | FromDiscord | <treeform> does any one know if there is a stdlib function to know if file is still open/valid? |
| 21:55:50 | FromDiscord | <treeform> I can do it with C style posix by `c_fcntl(f, F_GETFD)` it looks like system uses it, but does not expose it... any one run into this? |
| 21:56:21 | leorize | you should never have to check that... |
| 21:56:58 | leorize | I do have one used for testing purposes though: https://github.com/alaviss/nim-sys/blob/master/tests/helpers/handles.nim#L34 |
| 21:57:23 | leorize | but aside from that, you should never have to check if a file is valid |
| 22:08:48 | jjido | ahazh |
| 22:20:25 | FromDiscord | <treeform> leorize, what do you mean I close it manually? This crashes now: `stdout.close(); echo "dump?"` used to do nothing. I need to check now it seems. |
| 22:22:49 | FromDiscord | <treeform> I wish your isValid function was part of stdlib. |
| 22:24:14 | leorize | oh we have error checking for that now |
| 22:26:34 | FromDiscord | <treeform> I think thats's reversed, we used to have error checking for echo-ing to closed stdout and now its a crash. |
| 22:26:49 | FromDiscord | <treeform> Which is probably correct, having a closed stdout is very odd. |
| 22:27:00 | leorize | I would advise you to just crash tbh |
| 22:27:19 | leorize | since that fd is freed you don't know if any of your `open()` calls would fill in the spot |
| 22:27:27 | FromDiscord | <treeform> Its a deamon I need to close stdout to demonize |
| 22:27:44 | leorize | or stop doing that |
| 22:27:55 | FromDiscord | <treeform> it has worked for 2 years sense before 1.0 |
| 22:27:59 | leorize | it's an old idea and everyone is on the supervisor train now :P |
| 22:28:01 | FromDiscord | <treeform> can't argue with time |
| 22:28:41 | FromDiscord | <treeform> I think everyone is on the docker/kubernaties train now. |
| 22:28:47 | FromDiscord | <treeform> I don't want to get on that train. |
| 22:28:58 | leorize | just go with supervision systems |
| 22:28:59 | FromDiscord | <treeform> nim is so easy to just cp and demonzie |
| 22:29:12 | leorize | those are dead simple and work better than any daemonizing scheme |
| 22:29:26 | leorize | on linux systemd get you that for free |
| 22:29:49 | leorize | `systemd-run` even let you spawn a service off the spot without writing a service file |
| 22:30:20 | FromDiscord | <treeform> I think when i started I reviewed several "supervisors" |
| 22:30:25 | FromDiscord | <treeform> but run into issues in all of them |
| 22:30:28 | FromDiscord | <treeform> so I just demonzie |
| 22:30:49 | FromDiscord | <treeform> I think I am just not smart enough to use them |
| 22:31:11 | leorize | they should be better now |
| 22:31:47 | leorize | and you should always use a logger if you intend to work on environments where stdin/stdout might be closed |
| 22:32:18 | leorize | it's easy to toggle logger between: write to file and write to stderr |
| 22:42:42 | * | sagax quit (Ping timeout: 272 seconds) |
| 22:46:59 | FromDiscord | <treeform> yeah but I need to know if stdout is closed to switch to a logger? |
| 22:47:44 | leorize | you perform the daemonize yourself, no? |
| 22:49:35 | leorize | the close() has to be done after fork so you should be aware of that by then |
| 22:55:19 | FromDiscord | <treeform> well yes and no |
| 22:56:06 | FromDiscord | <treeform> the daemonizer starts up and does the "step" but then starts other things which might not know they were demonized. |
| 22:56:40 | FromDiscord | <treeform> See here: https://github.com/treeform/guardmons/blob/master/src/guardmons/daemon.nim |
| 22:57:16 | FromDiscord | <treeform> when I do `daemon foo` ... `foo` might not know that echo was closed. |
| 22:57:33 | leorize | if you daemonize things that are not aware of it, then reopen stdin/stdout as `/dev/null` |
| 22:57:49 | leorize | you don't need to reopen stdin actually, just the output buffers |
| 22:58:34 | leorize | for stdin using a closed pipe might be better |
| 22:58:36 | FromDiscord | <treeform> I had `foo` write out `echo "using logs now"` |
| 22:58:41 | FromDiscord | <treeform> but that started to crash `foo` |
| 22:58:55 | FromDiscord | <treeform> If i remove the echo it works. |
| 22:59:12 | leorize | yea you should reopen stdout as /dev/null |
| 22:59:20 | leorize | that way they can echo all they want |
| 22:59:21 | FromDiscord | <treeform> yeah thats a good tip |
| 23:00:07 | leorize | alternatively use start-stop-daemon, that stuff is super configurable |
| 23:00:28 | leorize | it can daemonize anything, redirect stdout/stderr to files/process |
| 23:02:31 | FromDiscord | <treeform> well basically I have my own start-stop-daemon... |
| 23:03:05 | leorize | the /dev/null trick should do it :P |
| 23:03:13 | leorize | we have reopen() in the stdlib too |
| 23:03:24 | FromDiscord | <treeform> yeah I use it in other palces |
| 23:09:05 | * | krux02 quit (Remote host closed the connection) |
| 23:15:10 | FromDiscord | <robohack> Is it possible to define a type (object) with an array field of unspecified size? The array would be set by calling a proc and passing in an array? Thanks. |
| 23:16:45 | leorize | you can either use a `seq[T]` or if you want low-level there is `ptr UncheckedArray[T]` |
| 23:17:31 | * | tane quit (Quit: Leaving) |
| 23:17:31 | FromDiscord | <robohack> Ok, thanks. I was not aware of UncheckedArray. |
| 23:17:40 | FromDiscord | <treeform> "array field of unspecified size" I think a regular seq is the dynamic array you want. |
| 23:17:53 | FromDiscord | <treeform> UncheckedArray is some thing more advanced |
| 23:20:09 | FromDiscord | <robohack> Yeah, the size of my array will not change at runtime, but I want to have multiple instances of this type containing arrays of differing sizes. I am trying to make a menu object that contains a certain number of menu items. my program will have three menus each with a different number of menu items. |
| 23:20:46 | leorize | then wouldn't generics and the normal `array[I, T]` works? |
| 23:21:34 | disruptek | sometimes i really wonder about you. |
| 23:21:45 | leorize | and seqs are simple enough that there are particularly no overhead if you don't resize |
| 23:22:00 | FromDiscord | <InventorMatt> how come something like this https://play.nim-lang.org/#ix=2MJx wouldn't work for that ? |
| 23:23:11 | leorize | https://play.nim-lang.org/#ix=2MJz <- fixed the compiler crash |
| 23:23:14 | FromDiscord | <robohack> Oh, cool. yeah that looks good. I am familiar with generics in other languages, but fairly inexperienced in nim. |
| 23:23:31 | FromDiscord | <robohack> Thanks all.. |
| 23:23:58 | FromDiscord | <InventorMatt> there really should an error for that instead of a compiler crash |
| 23:27:05 | leorize | it should work instead of crashing like that |
| 23:27:18 | leorize | not sure if the bug is reported though |
| 23:31:13 | FromDiscord | <mratsim> OMG, I hate working with types in macro. And now with nimble not allowing commit pinning I'm stuck :/. Because I need to deserialize something and getTypeInst is so fragile and trying to workaround compiler bugs introduce new issues until you drown in workarounds of workarounds. |
| 23:31:38 | * | Vladar quit (Quit: Leaving) |
| 23:32:56 | disruptek | what do you mean by "nimble not allowing commit pinning"? |
| 23:36:03 | FromDiscord | <mratsim> package = ab123def |
| 23:36:06 | FromDiscord | <mratsim> a git hash |
| 23:37:08 | leorize | you can do that |
| 23:37:12 | FromDiscord | <ElegantBeef> It does through a giturl |
| 23:37:21 | leorize | the format is `<url>#<commit>` |
| 23:37:23 | FromDiscord | <ElegantBeef> `requires "https://github.com/user/pkg#5a54b5e"` example from the readme |
| 23:39:44 | FromDiscord | <mratsim> ohohoh, that's very nice. |
