| 00:04:31 | jacereda | rayman22201, ok, thanks |
| 00:14:08 | * | ftsf joined #nim |
| 00:14:43 | shashlick | can macros have default values for params? |
| 00:21:32 | * | smt quit (Read error: Connection reset by peer) |
| 00:25:56 | * | shashlick_ quit (Ping timeout: 260 seconds) |
| 00:27:11 | * | shashlick_ joined #nim |
| 00:37:28 | * | ftsf quit (Quit: Leaving) |
| 01:24:47 | * | jacereda quit (Ping timeout: 240 seconds) |
| 01:38:03 | FromGitter | <zetashift> If I have a table with strings as keys, how would I get a random key from that table? |
| 01:42:06 | FromGitter | <zetashift> nvm using a `toSeq` should do the trick |
| 01:55:06 | * | abm quit (Ping timeout: 244 seconds) |
| 01:59:11 | FromGitter | <zetashift> Huh the table.keys iterator doesn't seem to get picked up instead another overloaded method is used |
| 02:02:17 | FromGitter | <zetashift> somehow made it work anyway don't really understand what happened here but oh well |
| 02:05:39 | * | leorize[m] left #nim ("User left") |
| 02:05:51 | * | leorize joined #nim |
| 02:08:19 | * | craigger_ joined #nim |
| 02:09:15 | * | zachk quit (Quit: Leaving) |
| 02:10:21 | * | craigger quit (Ping timeout: 252 seconds) |
| 02:11:11 | * | rockcavera quit (Read error: Connection reset by peer) |
| 02:11:26 | * | rockcavera joined #nim |
| 02:11:26 | * | rockcavera quit (Changing host) |
| 02:11:26 | * | rockcavera joined #nim |
| 02:12:58 | * | masterdonx quit (Ping timeout: 245 seconds) |
| 02:15:47 | * | masterdonx joined #nim |
| 02:28:47 | * | gmpreussner quit (Ping timeout: 240 seconds) |
| 02:49:43 | * | dddddd quit (Remote host closed the connection) |
| 03:05:42 | * | banc quit (Quit: ZNC - http://znc.in) |
| 03:12:47 | * | gmpreussner joined #nim |
| 03:17:38 | * | kapil____ joined #nim |
| 03:22:26 | * | banc joined #nim |
| 03:33:06 | * | sz0 quit (Quit: Connection closed for inactivity) |
| 05:04:01 | * | NimBot joined #nim |
| 05:33:17 | * | nsf joined #nim |
| 05:53:17 | FromGitter | <kaushalmodi> hello all |
| 05:54:12 | FromGitter | <kaushalmodi> I've been on vacation for a while (and 2 more weeks), but couldn't help notice the nightly build failures related to os module and Stat on Travis |
| 05:54:21 | FromGitter | <kaushalmodi> ``` code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bf4f30cfa7bbb3fe0dcd72a] |
| 05:54:32 | FromGitter | <kaushalmodi> .. and I cannot recreate that error locally |
| 05:55:41 | FromGitter | <kaushalmodi> and this is a the config.nims: https://github.com/kaushalmodi/nim_config/blob/master/config.nims |
| 06:25:54 | leorize | do you really need a proc called `dollar`? |
| 06:26:29 | leorize | I'd imagine putting `` `$` `` in place of `dollar` would work |
| 06:27:55 | FromGitter | <GULPF> @kaushalmodi I had that issue as well, fixed it by replacing ospaths with os (which now works in nimscript). I think it's a regression |
| 06:44:35 | FromGitter | <kaushalmodi> leorize: I had already tried that (`` `$` ``), but that didn't work |
| 06:45:33 | FromGitter | <kaushalmodi> apparently `` `$` `` doesn't share the same generic signature as that `dollar` proc |
| 06:45:59 | FromGitter | <kaushalmodi> @GULPF But then that config.nims won't work for Nim 0.19.1 or any older Nim release |
| 06:46:42 | FromGitter | <kaushalmodi> I thought that the ospaths -> os transition would just introduce a deprecation warning, and ospaths would continue to work as before |
| 06:58:28 | leorize | kaushalmodi: `when NimMinor < 19 and NimPath < 9:` ? |
| 06:58:34 | leorize | NimPatch* |
| 06:59:23 | FromGitter | <kaushalmodi> leorize: thanks, let we try that; it didn't occur that I can wrap imports in that |
| 06:59:23 | * | mech422__ joined #nim |
| 06:59:48 | leorize | as long as it's in the top level, it's fine |
| 07:00:41 | FromGitter | <kaushalmodi> thanks |
| 07:01:44 | leorize | oh, and remember to compare the `NimMajor` as well |
| 07:02:42 | * | mech422_ quit (Ping timeout: 252 seconds) |
| 07:31:03 | FromGitter | <kaushalmodi> hmm, I still get that same error even when using import os: https://travis-ci.org/kaushalmodi/hello_musl/jobs/457815106#L718 |
| 07:31:18 | * | jjido joined #nim |
| 07:32:08 | * | Vladar joined #nim |
| 07:32:14 | FromGitter | <kaushalmodi> the config.nims is actually https://github.com/kaushalmodi/hello_musl/blob/master/config.nims (I mislinked it earlier) |
| 07:33:38 | leorize | how up-to-date is the Nim you used for your Travis jobs? |
| 07:33:51 | FromGitter | <kaushalmodi> devel branch |
| 07:34:32 | FromGitter | <kaushalmodi> from the Travis log: ⏎ ⏎ > ../nim/574cdfc1569ffeef7fa9e6f7c28339edff93cd87/lib/pure/os.nim(754, 14) Error: undeclared identifier: 'Stat' |
| 07:34:33 | leorize | but how up to date is it? |
| 07:34:44 | FromGitter | <kaushalmodi> it's using that 574.. hash |
| 07:35:02 | FromGitter | <kaushalmodi> so the last commit 9 hrs ago |
| 07:35:36 | leorize | weird, you can't reproduce it, right? |
| 07:35:50 | FromGitter | <kaushalmodi> yeah, cannot reproduce it locally |
| 07:36:07 | FromGitter | <kaushalmodi> that Stat declaration is wrappen in when linux and when amd64 |
| 07:36:27 | FromGitter | <kaushalmodi> so the cpu arch on Travis somehow doesn't enter that when clause |
| 07:38:32 | FromGitter | <kaushalmodi> leorize: https://github.com/nim-lang/Nim/blob/ce05a850a55a651bcdd01e7af9af9702c8af5caf/lib/system/sysio.nim#L318-L328 |
| 07:39:08 | FromGitter | <kaushalmodi> I wonder if it's the `not defined(nimscript)` part.. |
| 07:39:13 | leorize | actually |
| 07:39:21 | leorize | the error is in os.nim |
| 07:39:42 | leorize | and that proc was annotated with `{.noNimScript.}` |
| 07:40:18 | leorize | so it should have never been evaluated |
| 07:40:21 | * | stefanos82 joined #nim |
| 07:41:07 | FromGitter | <kaushalmodi> .. but then cloning that same hello_musl repo locally and running `nim musl src/hello_musl.nim` works |
| 07:41:14 | FromGitter | <kaushalmodi> so this error is strange |
| 07:42:13 | FromGitter | <kaushalmodi> Also pinging Araq: Can you look at this import os and Stat issue; nim devel |
| 07:43:12 | * | krux02 joined #nim |
| 07:50:58 | leorize | yglukhov: your patch make command call syntax works with your threadpool, but breaks the function calling syntax at the same time |
| 07:51:40 | leorize | @yglukhov ^ |
| 08:04:50 | * | jjido quit (Remote host closed the connection) |
| 08:54:00 | FromGitter | <gogolxdong> Anyone interested in fulltime Nim job? We are hiring in China. |
| 08:59:31 | livcd | in Shenzhen ? |
| 08:59:41 | FromGitter | <gogolxdong> We already have a Vulkan expert from TaiWan and need at least one proficient at system programming. |
| 08:59:46 | FromGitter | <gogolxdong> Yes. |
| 08:59:56 | FromGitter | <gogolxdong> How do you know? |
| 09:00:29 | livcd | I know everything!! |
| 09:00:43 | FromGitter | <gogolxdong> Amazing! |
| 09:01:13 | livcd | Your github page mentions it :) |
| 09:02:05 | FromGitter | <gogolxdong> I just know there are lots of Europeans in our community. |
| 09:02:12 | FromGitter | <gogolxdong> ah. |
| 09:04:33 | livcd | I would go just for the opportunity to meet sexycyborg :D |
| 09:06:57 | FromGitter | <gogolxdong> if you have her contact |
| 09:08:17 | livcd | I read somewhere it's easy to meet her as she hags around a lot in the area from her videos |
| 09:09:46 | FromGitter | <gogolxdong> well, Shenzhen is large enough to miss her . |
| 09:12:30 | FromGitter | <gogolxdong> don't know much about her, just checked , and not my style. |
| 09:15:37 | FromGitter | <yglukhov> leorize: oops. fixed again. |
| 09:20:21 | FromGitter | <yglukhov> @gogolxdong that's exciting! what are you gonna do? |
| 09:21:44 | livcd | gogolxdong: Yeah I am not even interested in the DIY it's just a controversial persona I am occasionally watching. There's also this american guy that's doing haggling in china videos. BTW good luck finding a co-worker! |
| 09:24:08 | leorize | yglukhov: looks like your `spawn` doesn't have the `{.gcsafe.}` requirement. Is that a feature or a bug? :P |
| 09:24:42 | FromGitter | <gogolxdong> QUIC, Merkle DGA, kademlia, bitswap |
| 09:24:46 | FromGitter | <gogolxdong> DAG |
| 09:25:18 | FromGitter | <yglukhov> cool. why would you need vulkan for those? :) |
| 09:25:31 | FromGitter | <gogolxdong> Vulkan for GUI |
| 09:26:17 | FromGitter | <yglukhov> leorize: err... i think it is... got a gist? |
| 09:26:52 | FromGitter | <yglukhov> @gogolxdong I see. cool. best of luck :) |
| 09:27:57 | * | PMunch joined #nim |
| 09:28:02 | leorize | https://ptpb.pw/zAgP/nim |
| 09:28:06 | leorize | here you go |
| 09:28:17 | FromGitter | <yglukhov> leorize: * i think it is a bug :) |
| 09:28:42 | FromGitter | <gogolxdong> thanks for all your wishes. |
| 09:32:14 | leorize | yglukhov: looks like playing with threads is going to be a bit more painful if that's the case |
| 09:33:23 | FromGitter | <yglukhov> true. but your current code is crashable otherwise. |
| 09:34:22 | leorize | yea, if you run `crawl` a lot of time |
| 09:34:23 | FromGitter | <mratsim> crashable :P |
| 09:35:37 | FromGitter | <gogolxdong> later for AI, but Nim is throughout. |
| 09:35:42 | FromGitter | <mratsim> string/seq allocation including echo in thread requires setupForeignThreadGC and teardownForeignThreadGC |
| 09:36:24 | FromGitter | <mratsim> and maybe stack traces:off (I need it for OpenMP parallel loop, not sure if Nim does that automatically with threadpools) |
| 09:36:55 | leorize | not with the threadpool I'm using |
| 09:37:36 | FromGitter | <mratsim> the stack traces will become SIGSEGV anyway :P |
| 09:38:33 | leorize | waiting for new runtime so that we can just stop worrying about GC for threads :P |
| 09:38:46 | FromGitter | <yglukhov> leorize: fixed gcsafety enforcement |
| 09:40:03 | * | floppydh joined #nim |
| 09:40:06 | FromGitter | <yglukhov> now good luck making your code gcsafe :D |
| 09:40:21 | FromGitter | <mratsim> it’s not that hard to remember setup/teardownForeignTHreadGC once you know about them |
| 09:40:48 | leorize | the less friction writing parallel code, the better :) |
| 09:41:07 | * | zakora joined #nim |
| 09:41:10 | FromGitter | <mratsim> I agree |
| 09:41:23 | FromGitter | <yglukhov> @mratsim but you don't need it nim. you need it only in nim function that can be called from a foreign (non nim) thread |
| 09:41:38 | FromGitter | <mratsim> oh, cool |
| 09:42:18 | * | Vladar quit (Remote host closed the connection) |
| 09:42:55 | FromGitter | <mratsim> I was trying to check that but I got stuck in https://github.com/nim-lang/Nim/issues/9489 |
| 09:43:21 | FromGitter | <mratsim> wanted to reimplement parallel reduction in pure Nim: https://github.com/numforge/laser/blob/master/examples/ex05_tensor_parallel_reduction.nim#L53-L73 |
| 09:45:31 | FromGitter | <yglukhov> @mratsim i can compile your sample. fixed? |
| 09:47:01 | FromGitter | <mratsim> maybe the symptoms but I don’t think the error messages are fixed even if they don’t happen with this specific example anymore. cc @timotheecour |
| 09:47:20 | FromGitter | <mratsim> I had those strande error happening in other more complex macro cases |
| 09:48:26 | * | Vladar joined #nim |
| 09:50:06 | FromGitter | <yglukhov> ok. still if you're spawning a thread with either threadpools or `createThread` you don't need to use `setupForeignThreadGC`. if you do it with posix_* or something else nim doesn't know about then you need it |
| 09:50:52 | * | dom96_w joined #nim |
| 09:51:06 | leorize | I think it should be automated for the openmp iterator |
| 09:51:57 | FromGitter | <mratsim> I don’t know the cost but you most likely don’t work on string or allocate seq when using OpenMP |
| 09:52:40 | FromGitter | <mratsim> unless when using debug echoes |
| 09:53:25 | leorize | the idea is that the compiler could "magically" detect when GC memory is used and inject the statements accordingly |
| 09:53:59 | FromGitter | <mratsim> that’s mentioned in OpenMP `||` iterator description, PR wanted ;) |
| 10:10:37 | FromGitter | <gogolxdong> I have setup the QUIC packets and header writer and parser over UDP communication, comes to cryptography now. AEAD_AES_128_GCM specifically to encrypt and decrypt packet regarding QUIC implementation. |
| 10:11:41 | FromGitter | <gogolxdong> reference chrome source code and quic-go at the same time. |
| 10:18:20 | * | rokups joined #nim |
| 10:24:32 | * | theelous3 joined #nim |
| 10:25:11 | Araq | I broke the build. again. |
| 10:25:16 | Araq | why did nobody tell me? :P |
| 10:26:44 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 10:27:33 | * | ng0 joined #nim |
| 10:41:26 | leorize | Araq: what would be the correct way to destroy this kind of recursive type? https://github.com/nim-lang/Nim/issues/9696#issuecomment-440226729 |
| 10:43:17 | Araq | # Doesn't work if destructors are not defined, see #9696 <--- this needs to be fixed asap |
| 10:45:27 | Araq | and since we have a `=destroy` for every generic type T, it cannot be too hard to fix it... |
| 10:46:21 | * | theelous3 quit (Ping timeout: 252 seconds) |
| 10:52:53 | FromGitter | <yglukhov> Araq: this looks related https://github.com/nim-lang/Nim/issues/5366, no? |
| 10:53:58 | Araq | I doubt it |
| 11:02:15 | Araq | btw some numbers |
| 11:02:25 | Araq | the Nim compiler is roughly 2MB of source code |
| 11:03:15 | Araq | the AST and type graphs are stored in a Sqlite DB that takes 33MB |
| 11:04:19 | Araq | and in RAM these take up 425MB |
| 11:05:00 | Araq | terrible engineering :-) |
| 11:05:13 | Araq | and I blame it all on 'ref' |
| 11:07:17 | Araq | it's an anachronism that lures you into all these wrong Java-esque designs |
| 11:07:27 | * | dom96_w quit (Changing host) |
| 11:07:27 | * | dom96_w joined #nim |
| 11:14:59 | * | kapil____ joined #nim |
| 11:26:47 | FromGitter | <mratsim> you are missing the ratio of source code/comment |
| 11:27:03 | FromGitter | <mratsim> I tend to have much more comments than code in Nim :P |
| 11:31:14 | * | kungtotte quit (Quit: WeeChat 2.3) |
| 11:32:08 | * | Vladar quit (Ping timeout: 272 seconds) |
| 11:34:42 | * | Vladar joined #nim |
| 11:45:00 | * | dddddd joined #nim |
| 11:45:41 | Araq | more comments mean the compiler is even worse at what it does |
| 11:56:50 | * | stefanos82 quit (Quit: Quitting for now...) |
| 12:07:50 | leorize | Araq: oops, the linked issue should be https://github.com/nim-lang/Nim/issues/9675 |
| 12:08:04 | leorize | I probably messed up the numbers while creating that example |
| 12:10:27 | FromGitter | <zacharycarter> seems like nativesockets is the best module for me to use for this portion of my new project |
| 12:10:47 | FromGitter | <zacharycarter> tried using asyncnet and net - but I already need to switch my sockets b/w blocking and unblocking |
| 12:10:51 | FromGitter | <zacharycarter> so I need nativesockets anyway I believe |
| 12:13:14 | FromGitter | <dom96> @zacharycarter I'm 99% certain you don't need native socks |
| 12:13:21 | FromGitter | <zacharycarter> okay |
| 12:13:30 | FromGitter | <dom96> Where are you having troubles? |
| 12:13:55 | FromGitter | <zacharycarter> it's not necessarily troubles - but I need to create a socket that I can toggle between unblocking and blocking |
| 12:14:07 | FromGitter | <zacharycarter> I see setBlocking in nativesockets |
| 12:14:20 | FromGitter | <zacharycarter> I'm not using the nativesocket object - I'm still using the socket ref object from net |
| 12:14:35 | FromGitter | <zacharycarter> but I was hoping I'd be able to leverage asyncnet - just not sure if that's doable or would be useful in anyway |
| 12:14:41 | FromGitter | <zacharycarter> or if that module was really meant to be paired w/ asyncdispatch |
| 12:14:54 | FromGitter | <zacharycarter> I do NOT have an event loop in my program atm |
| 12:15:41 | FromGitter | <zacharycarter> also - one slightly related question - is the preferred way to avoid the usage of `nil` using `Option[Socket]` at this point? |
| 12:16:20 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 12:16:35 | FromGitter | <zacharycarter> this is the code I have so far - https://github.com/zacharycarter/zeal/blob/compiler_server/src/zealpkg/socket.nim |
| 12:16:55 | FromGitter | <zacharycarter> working on the `accept` proc atm |
| 12:22:11 | FromGitter | <zacharycarter> I plan on creating a non-blocking version of `accept` and a non-blocking version of `read` as well |
| 12:22:18 | FromGitter | <zacharycarter> once I create the blocking version of `read` that is :P |
| 12:22:33 | FromGitter | <zacharycarter> not sure if there's an easier way to do all of this though |
| 12:22:58 | * | zakora quit (Ping timeout: 245 seconds) |
| 12:23:22 | FromGitter | <zacharycarter> also - I'm trying to avoid exceptions / the handling thereof in my program if possible |
| 12:23:32 | FromGitter | <zacharycarter> and I noticed the net module relies on them heavily it seems |
| 12:25:11 | * | floppydh quit (Ping timeout: 268 seconds) |
| 12:25:13 | * | zakora joined #nim |
| 12:27:09 | * | floppydh joined #nim |
| 12:37:51 | * | ng0 joined #nim |
| 12:42:38 | * | dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 12:43:15 | FromGitter | <zacharycarter> not sure if what I'm describing above makes sense or not @dom96 |
| 12:44:37 | * | seni quit (Quit: Leaving) |
| 12:57:38 | FromGitter | <zacharycarter> ah maybe I can get away with using asyncdispatch / asyncnet |
| 12:58:07 | FromGitter | <zacharycarter> and just use `poll` and `sleepAsync` without `runForever` |
| 13:03:01 | * | vlad1777d joined #nim |
| 13:08:20 | FromGitter | <zacharycarter> doh - yeah and there's `waitFor` definitely think I should be using asyncnet / dispatch |
| 13:09:19 | * | dddddd quit (Ping timeout: 246 seconds) |
| 13:10:18 | * | stefanos82 joined #nim |
| 13:21:31 | * | dddddd joined #nim |
| 13:25:27 | * | Ven`` joined #nim |
| 13:29:04 | PMunch | Araq, any thoughts on this? https://github.com/PMunch/Nim/blob/nimsuggestlib/nimsuggest/nimsuggest.nim#L616 Basically making nimsuggest importable into other Nim projects, like nimlsp. Not quite sure how to properly require that though.. Currently I've just tested it with an absolute path |
| 13:29:17 | * | dom96_w joined #nim |
| 13:41:15 | * | Vladar quit (Ping timeout: 252 seconds) |
| 13:45:37 | * | dom96_w quit (Changing host) |
| 13:45:37 | * | dom96_w joined #nim |
| 13:45:53 | * | Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 13:45:59 | dom96_w | zacharycarter: async is already non-blocking. |
| 13:46:07 | dom96_w | Everything relies on exceptions |
| 13:46:55 | FromGitter | <zacharycarter> well - nativesockets for instance - I think would allow to still handling errors by inspecting FD's I think |
| 13:46:56 | * | gangstacat quit (Quit: Ĝis!) |
| 13:47:09 | FromGitter | <zacharycarter> but I will give this a shot with asyncnet/dispatch thanks dom96_w |
| 13:48:35 | dom96_w | Feel free to use nativesockets, just be prepared to reimplement a lot of what async already does :) |
| 13:48:43 | dom96_w | Good for learning, bad for productivity |
| 13:49:57 | Araq | PMunch, fine with me |
| 13:50:08 | Araq | anything that helps LSP is fine with me |
| 13:51:25 | PMunch | Well I was wondering if it should be done differently, or if that is a good way to do it |
| 13:51:50 | PMunch | And also if you had any thoughts on how to make it more easily importable |
| 13:52:10 | Araq | well the better way is to extract what you need from nimsuggest.nim into libsuggest.nim |
| 13:52:18 | Araq | and import that one instead |
| 13:53:03 | FromGitter | <zacharycarter> dom96_w: thanks I will take your advice and not do that ;) |
| 13:53:11 | PMunch | Yeah that's what I originally did. But it lead to basically copying the entirety of nimsuggest, and it didn't seem very stable.. |
| 13:53:51 | dom96_w | Yeah, I would strongly suggest not to do that :) |
| 13:54:13 | * | gangstacat joined #nim |
| 13:54:18 | dom96_w | It's already enough that nimsuggest effectively embeds all the compiler sources |
| 13:58:15 | FromGitter | <alehander42> in the compiler there was a way to hint |
| 13:58:27 | FromGitter | <alehander42> where should the lineinfo point |
| 13:58:33 | FromGitter | <alehander42> (or in macros .. i don't remember) |
| 13:58:36 | FromGitter | <alehander42> i think it was a pragma |
| 13:58:38 | FromGitter | <alehander42> what was it |
| 13:59:39 | FromGitter | <alehander42> e.g. if you want your expanded macro to have lineinfo == to the callsite |
| 13:59:44 | PMunch | Yeah, making nimsuggest importable as a library seems both more stable and it makes sure that any fixes to nimsuggest will also happen for nimlsp |
| 13:59:55 | PMunch | Or anything else that uses nimsuggest for that matter |
| 14:01:44 | FromGitter | <alehander42> my question is more related to inline iterators: they are *inline*, but their lineinfo points to the iterator definition |
| 14:02:27 | FromGitter | <alehander42> which makes sense on one hand, but on the other in ~50% of the cases it's really better to somehow just use the `for` lineinfo instead |
| 14:02:47 | FromGitter | <mratsim> doesn’t the for appear in the stack trace as well? |
| 14:03:39 | FromGitter | <alehander42> maybe if we had a noop line with for's lineinfo in the beginning of each iterator expansion (but this can be hardly automated) |
| 14:03:59 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 14:04:56 | FromGitter | <alehander42> @mratsim I am talking about the debugging experience |
| 14:05:17 | FromGitter | <alehander42> in for ..: code, you actually never visit the for line |
| 14:05:18 | * | ng0 quit (Remote host closed the connection) |
| 14:05:33 | FromGitter | <alehander42> you visit (usually) system.nim's iterator lines instead |
| 14:08:24 | FromGitter | <alehander42> actually it all depends on the yield: |
| 14:08:44 | FromGitter | <alehander42> so if we just generate a noop `else` with the callsite lineinfo on each yield |
| 14:08:59 | FromGitter | <alehander42> we'll have a reasonable debugging flow |
| 14:09:09 | FromGitter | <alehander42> Araq, should I PR that ? |
| 14:10:04 | * | kapil____ joined #nim |
| 14:12:21 | FromGitter | <narimiran> i like the idea of showing `for` lineinfo |
| 14:13:35 | * | nsf quit (Quit: WeeChat 2.3) |
| 14:16:32 | Araq | alehander42: er ... what? |
| 14:17:36 | Araq | as far as I'm concerned that is "just a bug" in the compiler/codegen |
| 14:17:36 | FromGitter | <alehander42> currently when you step through `for loops` |
| 14:17:52 | FromGitter | <alehander42> so what is the expected behavior |
| 14:18:08 | Araq | that you don't step into the freaking system.nim code |
| 14:18:14 | FromGitter | <alehander42> oh I agree |
| 14:18:16 | Araq | but I know it currently does that. and it sucks |
| 14:18:24 | FromGitter | <alehander42> but I suspected that maybe it makes sense |
| 14:18:28 | FromGitter | <alehander42> to step in user-defined iterators |
| 14:18:50 | Araq | hmm well stepping through is different from "it crashes here" |
| 14:19:05 | Araq | unfortunately we often report the wrong line for "it crashes here" |
| 14:19:37 | FromGitter | <alehander42> ah I see, and lineinfo is used for both (debug info and stacktraces) |
| 14:20:06 | Araq | for stepping through system.nim is correct bug annoying |
| 14:20:25 | Araq | for user defined iterators it's essential so we might decide to not "fix" that |
| 14:20:43 | FromGitter | <alehander42> yes, but I think my solution adresses that well |
| 14:20:51 | FromGitter | <alehander42> we can still step through the iterators |
| 14:20:58 | FromGitter | <alehander42> but we also hit the actual `for` line |
| 14:21:03 | * | Vladar joined #nim |
| 14:21:11 | Araq | what is your solution? |
| 14:21:18 | FromGitter | <alehander42> and overally a better solution for an user is to just gdb-ignore stdlib_system.c |
| 14:21:28 | FromGitter | <alehander42> or system.nim if he doesn't want to step there |
| 14:21:40 | * | revere quit (Ping timeout: 264 seconds) |
| 14:21:50 | FromGitter | <alehander42> to generate a noop line with the `for` lineinfo for each iterator yield |
| 14:22:35 | * | revere joined #nim |
| 14:23:26 | FromGitter | <alehander42> so if you ignore system.nim you see `for .. code1 .. code2 .. for .. code1 .. code2` etc and if you don't you see `iterator code .. for .. code1 .. code2 .. iterator code .. for .. ` etc |
| 14:27:24 | FromGitter | <alehander42> and lineinfo for crashes remains the same, as it's not touched (I guess) |
| 14:38:04 | * | theelous3_ joined #nim |
| 14:42:54 | Araq | I don't understand it |
| 14:43:07 | Araq | how would it look like in system.nim? |
| 14:45:22 | FromGitter | <alehander42> it doesn't change anything in system.nim |
| 14:45:56 | FromGitter | <alehander42> it just makes the compiler generate noop statement with the original `for lineinfo` after each yield in iterator |
| 14:46:04 | FromGitter | <alehander42> in debugging regime |
| 14:46:18 | Araq | hmmm |
| 14:46:27 | Araq | might be a good idea |
| 14:46:54 | FromGitter | <alehander42> I almost did it locally, I am just not sure how can I actually find the original lineinfo |
| 14:55:06 | * | Ven`` joined #nim |
| 14:59:36 | FromGitter | <yyyc514> anything yet in the way of pub/sub? |
| 15:02:13 | FromGitter | <mratsim> https://github.com/makingspace/cittadino/blob/master/src/cittadino.nim |
| 15:03:27 | * | ng0 joined #nim |
| 15:07:04 | FromGitter | <yyyc514> yeah i found that |
| 15:08:46 | FromGitter | <alehander42> how is it going with your web framework :O |
| 15:09:15 | FromGitter | <yyyc514> working on phoenix like channels now :) |
| 15:09:29 | FromGitter | <yyyc514> keep getting distracted with tangents, like lightweight process model, etc :) |
| 15:09:52 | FromGitter | <mratsim> ah distractions =) that’s how project time inflates :P |
| 15:10:18 | FromGitter | <yyyc514> that was actually not too hard but i'm still stuck on the best way to handle custom message passing |
| 15:10:25 | FromGitter | <alehander42> ah, are you looking for an actors lib |
| 15:11:40 | FromGitter | <alehander42> can you give an example? |
| 15:11:47 | FromGitter | <alehander42> about the message passing |
| 15:12:06 | FromGitter | <yyyc514> https://gist.github.com/yyyc514/462e2b0782d35ae9cbf5cd285677af98 looking for a way to abstract CounterMessage |
| 15:12:33 | FromGitter | <yyyc514> I want to create 1000s of LIPRs but potentially they'd all be able to communicate however they wanted |
| 15:13:51 | FromGitter | <yyyc514> I'd try inheritance but i think the Future makes that all a mess |
| 15:14:17 | FromGitter | <alehander42> isn't it similar to https://hexdocs.pm/phoenix/Phoenix.Socket.Message.html ? |
| 15:15:19 | FromGitter | <yyyc514> no, this i processes :) think broader |
| 15:15:31 | Araq | it's terrible ;-) |
| 15:15:50 | FromGitter | <yyyc514> what is? |
| 15:15:56 | * | theelous3_ quit (Ping timeout: 244 seconds) |
| 15:16:02 | FromGitter | <mratsim> distractions I guess |
| 15:16:08 | FromGitter | <alehander42> i bet on inheritance |
| 15:16:20 | Araq | 1000s of processes |
| 15:16:38 | FromGitter | <yyyc514> well i was going to see how well it worked :) |
| 15:16:43 | Araq | you can only write these systems. you cannot debug them. |
| 15:17:04 | FromGitter | <yyyc514> no easier than you could debug asynchttp :) |
| 15:17:05 | FromGitter | <yyyc514> same diff |
| 15:17:11 | FromGitter | <alehander42> I guess in a language like Nim, some way to actually use shared memory for the sended values with compile time guarantees that they're not changed might be better |
| 15:17:35 | FromGitter | <yyyc514> well right now this is still all single threaded just trying to get the basics working |
| 15:18:14 | FromGitter | <yyyc514> found out the stack is only 333 deep :) |
| 15:18:27 | FromGitter | <alehander42> so you can still have "quasi-actors", but they can be just normal functions operating safely on the same memory |
| 15:18:33 | FromGitter | <yyyc514> when i tried to chain 1000 futures :) |
| 15:18:38 | FromGitter | <alehander42> but maybe that's what pony does? not sure |
| 15:18:58 | FromGitter | <yyyc514> the async stuff was actually super easy only 3 LOC to get "recv" to pause so i can run 1000 at a time |
| 15:19:27 | FromGitter | <yyyc514> so you them up and they pause waiting to recv a message |
| 15:21:56 | FromGitter | <yyyc514> i'm thinking to get it super flexible i'm just going to have to make inbox and recv mostly pointers so then the actual processes can just typecast everything |
| 15:27:07 | * | vlad1777d quit (Ping timeout: 272 seconds) |
| 15:27:43 | FromGitter | <alehander42> ok, and how do your processes communicate? (I really haven't done a lot of async stuff in native nim, excuse my lack of knowledge) |
| 15:29:32 | FromGitter | <yyyc514> by sending messages |
| 15:29:37 | FromGitter | <yyyc514> messages go into the inbox |
| 15:29:50 | FromGitter | <yyyc514> and a process calls recv to poll it's inbox, which is a Future, which hooks into the whole async |
| 15:30:33 | FromGitter | <yyyc514> so processes can do anything async, await, etc... and when they wait to recv messages they are effectively suspended until there is a message in their inbox |
| 15:30:47 | Araq | and you immediately lose the debuggability ;-) stuff goes into inboxes and then you wonder *who* and *why* put crappy data in there |
| 15:31:06 | FromGitter | <alehander42> well, this is a tooling problem honestly |
| 15:31:18 | Araq | everything is always a tooling problem. |
| 15:31:24 | FromGitter | <yyyc514> right, debugging is often hard if you don't build in proper tooling into any system |
| 15:31:34 | Araq | throwing away the stack traces is a bad start |
| 15:31:45 | FromGitter | <yyyc514> inboxes are a pretty easy concept to test, very functional |
| 15:32:03 | Araq | the inbox itself, sure, the stuff that ends up in it, no. |
| 15:32:20 | FromGitter | <alehander42> well I don't think it's very hard to log message send/receive indexed by id-s |
| 15:32:26 | FromGitter | <alehander42> in debugging mode |
| 15:32:27 | Araq | but what do I know, I only worked on "distributed" systems that didn't need to be distributed |
| 15:32:32 | FromGitter | <yyyc514> this isn't the told dynamic vs static argument is it? :) |
| 15:32:38 | Araq | debugging was terrible. |
| 15:32:44 | FromGitter | <alehander42> and to make a system that lets you step through this |
| 15:34:20 | FromGitter | <yyyc514> anyways i'll see how all this works with pub/sub and channels :) |
| 15:34:25 | FromGitter | <alehander42> that's a different topic: maybe some things doesn't need to be distributed, this is a design question, the tooling should be good enough for both |
| 15:34:44 | FromGitter | <alehander42> debugging async is often hard too in many languages |
| 15:35:01 | FromGitter | <yyyc514> the async macros are crazy magic though :) |
| 15:35:04 | Araq | sure you use async because you have to, not because it's cool |
| 15:35:08 | FromGitter | <yyyc514> but i understand them a lot better having read the generated code |
| 15:35:58 | FromGitter | <alehander42> Araq, well the actor pattern has different +s and -s, it's not always just a cool factor |
| 15:36:07 | dom96_w | the async macros are actually very simple |
| 15:36:12 | FromGitter | <alehander42> I also think it's overrated for static languages |
| 15:36:29 | FromGitter | <alehander42> but it's still interesting to play with :D |
| 15:36:44 | Araq | the actor pattern may have advantages but it's as overrated as OOP was in the 90ies |
| 15:37:02 | Araq | and much like OOP, it starts out with "terrible to debug" |
| 15:37:29 | Araq | and then you patch it ("better tooling", "messages must be immutable") |
| 15:37:32 | FromGitter | <alehander42> my point is, if this is the biggest problem with it, it's not an inherent problem |
| 15:37:49 | FromGitter | <alehander42> i think immutable messages is the whole point |
| 15:38:03 | FromGitter | <mratsim> I see actor as just an extension of channels |
| 15:38:11 | FromGitter | <alehander42> after all you pretend you use soooomething like quasi-pure functions |
| 15:38:52 | FromGitter | <mratsim> I thought the stack was millions call deep (and even was changed to billions) |
| 15:39:09 | FromGitter | <mratsim> ah, you mean at runtime? |
| 15:40:15 | FromGitter | <alehander42> talking about tooling, Araq, how can I get the fileinfo of the place where iterator was expanded |
| 15:43:57 | FromGitter | <arnetheduck> pretty cool: llvm added support for dumping source code into a binary, in the debug info - this would be the perfect place to store expanded macros so you can step through generated code: https://reviews.llvm.org/rL326102 |
| 15:44:19 | Araq | by asking the right PNode for its .info, alehander42 |
| 15:45:40 | Araq | arnetheduck: I wanted to patch nimfind/nimsuggest to do that |
| 15:45:47 | * | PMunch quit (Quit: Leaving) |
| 15:46:04 | FromGitter | <alehander42> @arnetheduck can't we just add it custom sections to the exe currently ? |
| 15:46:18 | FromGitter | <alehander42> ah this is integrated with other dwarf mechanisms probably |
| 15:49:58 | * | Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 15:50:26 | Araq | can an actor die? if so, what happens to the messages in ether that are about to arrive at it? |
| 15:51:25 | Araq | does that mean that every 'send' operation can potentially fail? |
| 15:51:49 | Araq | what if the inbox is full? start blocking on the 'send' then? |
| 15:53:05 | Araq | how do you ensure that your producers are not too fast for your consumers to keep up with the work? |
| 15:53:35 | Araq | etc yadda yadda. Your life is happier without an actor model. |
| 15:54:39 | * | Ven`` joined #nim |
| 15:55:22 | FromGitter | <arnetheduck> @alehander42 @Araq what's nice is that it gets implemented in the right place at a cross-language level so that there is one working approach instead of each language having its own - ie gdb gets support, editors get support etc.. ie the same need is there for rust macros, c macros, etc etc so the enthusiasm around those languages is leveraged to nims benefit as well.. |
| 16:01:27 | FromGitter | <mratsim> Are people enthusiastic about C macros? :P |
| 16:04:20 | FromGitter | <alehander42> Araq, good questions, but if one really needs a distributed system, he needs to answer them independently on what kind of pattern is being used |
| 16:04:22 | FromGitter | <arnetheduck> well, people that are forced to use them are probably excited about seeing them expanded :) one of my favorite features in eclipse, when working with boost pp |
| 16:05:05 | FromGitter | <alehander42> @arnetheduck agree, most other new languages have macros too (elixir, julia, crystal etc) |
| 16:06:37 | Araq | alehander42: but you can build distributed systems that don't multiply the "process problem" by a factor of 1000. |
| 16:07:01 | Araq | every process is a stateful black box. |
| 16:09:19 | FromGitter | <alehander42> actually there are some tools similar to waht I suggested for elixir/erlang e.g. observer, erlyberly etc |
| 16:10:57 | FromGitter | <alehander42> so your biggest annoyance is that it's hard to analyze/make them safe on compile time? |
| 16:11:30 | * | zakora quit (Quit: WeeChat 2.2) |
| 16:11:39 | FromGitter | <alehander42> I guess at least for erlang, their entire philophy is that they don't care and they can debug+hot swap it or something |
| 16:11:43 | FromGitter | <alehander42> no idea |
| 16:14:09 | Araq | no, my biggest gripe is that it starts with lots of artificial complexity. |
| 16:14:37 | FromGitter | <alehander42> btw offtopic, how would you design the ast today? you said earlier that the ref-thing sucks ⏎ the ast in my pseudo compiler looks kinda similar currently, but I haven't thought about optimizations yet |
| 16:15:29 | Araq | lots of application domains come to mind that don't have the problem of "what if message passing to a dying actor fails" |
| 16:17:40 | Araq | it's like using assembler for the job. Assembler has an "invalid instruction" exception. C doesn't. But C compiles to asm, how is this possible... ;-) |
| 16:19:25 | Araq | http://personales.upv.es/gvidal/german/flops18/paper.pdf |
| 16:20:34 | FromGitter | <zacharycarter> well in erlang / otp - you don't really handle exceptions |
| 16:20:46 | FromGitter | <zacharycarter> you just let processes die |
| 16:20:56 | FromGitter | <zacharycarter> and there is a supervision hierarchy so the VM knows how to start back up what |
| 16:21:07 | FromGitter | <zacharycarter> and yes - you can hot swap code |
| 16:21:17 | FromGitter | <zacharycarter> but I mean - I agree the actor model is complex - look at how complex Pony is |
| 16:21:40 | FromGitter | <alehander42> yes, I finally made it work |
| 16:21:51 | FromGitter | <alehander42> i didn't realize i have to change the line infos of the children too sometimes |
| 16:23:06 | FromGitter | <alehander42> literally 5 loc of course .. |
| 16:23:23 | FromGitter | <alehander42> so obvious now |
| 16:23:52 | Araq | btw erlang has exceptions, http://erlang.org/doc/reference_manual/errors.html#exceptions |
| 16:25:20 | Araq | but yeah, you can simulate "bubble up the stack" by nuking the whole stack instead and let a supervisor look into the problem |
| 16:26:15 | * | nsf joined #nim |
| 16:26:38 | FromGitter | <zacharycarter> err I just meant you don't really handle them - instead you do what you just described |
| 16:27:24 | FromGitter | <zacharycarter> which I guess in a sense is handling them - just in a different way |
| 16:27:27 | FromGitter | <zacharycarter> :P but whatever |
| 16:28:48 | * | floppydh quit (Quit: WeeChat 2.3) |
| 16:41:50 | FromGitter | <arnetheduck> btw, Araq, any idea why this is failing? https://travis-ci.org/nim-lang/Nim/jobs/457773721 looks like the test suite passes but then it goes on, and I think it fails on runnableExamples.. but I don't quite see how that's related to the changes in the branch |
| 16:44:43 | Araq | that was my bad, rebase or make me merge it anyway |
| 16:46:09 | Araq | alehander42: I would try to base the AST on ideas explored by my packedjson project |
| 16:47:17 | FromGitter | <arnetheduck> Araq, I command you to merge it anyway. now. |
| 16:48:13 | Araq | maybe you should change your nick to Arcturus |
| 16:50:04 | Araq | ugh, you removed getStorageLoc |
| 16:50:26 | Araq | shouldn't the codegen use that instead of the terrible field in TLoc that is so easy to get wrong? |
| 16:51:12 | FromGitter | <arnetheduck> "bear guardian"? |
| 16:51:29 | FromGitter | <arnetheduck> well, honestly I would prefer it did, but it doesn't.. |
| 16:52:39 | FromGitter | <arnetheduck> the tloc thing is.. not beautiful. actually, it's the embodiment of all horror stories about spaghetti and the kind of things that makes people go functional after seeing it. |
| 16:56:25 | Araq | "bear guardian"? no, because of https://youtu.be/3V1PwpoDqzM?t=84 |
| 16:56:54 | Araq | but yeah, I agree, so ... please let's not remove getStorageLoc but use it instead |
| 16:58:32 | Araq | can't be hard, with the newish 'lode' field we have the right datastructure for it |
| 17:01:08 | FromGitter | <arnetheduck> ugh, the sheer number of places the storage loc is set is discouraging. I can throw it back in and see what breaks when calling it.. your idea is that `lode.getStorageLoc` should be a viable replacement for `tloc.storage`? |
| 17:02:34 | Araq | yes |
| 17:05:14 | Araq | also... |
| 17:05:16 | Araq | dup*: Rope # duplicated location for precise stack scans |
| 17:05:26 | Araq | ^ nowhere used |
| 17:05:39 | Araq | we can save 8 bytes in every symbol... |
| 17:07:11 | FromGitter | <arnetheduck> well, the "can be faked"-comment on lode doesn't inspire confidence in that it'll turn out significantly different from storage then, no? |
| 17:08:01 | Araq | well I can tell you it's gonna break something and most likely won't bootstrap |
| 17:08:19 | Araq | but there is a chance it will be cleaner once it works |
| 17:09:02 | Araq | we can also leave it and wait for an AST->AST codegen |
| 17:09:03 | FromGitter | <alehander42> so in the ast-case, you'd just have all nodes be indexes in a big seq? |
| 17:10:24 | Araq | that's a weird way of putting it |
| 17:11:21 | Araq | I'd have a tree and nodes inside it backed by a linear storage, every transformation creates a full new tree, no node sharing, no aliasing |
| 17:12:57 | Araq | and since I have a linear store behind it, I can write it to disk easily |
| 17:18:44 | FromGitter | <alehander42> so, basically nodes are indexes instead of refs |
| 17:18:55 | FromGitter | <alehander42> node refs* |
| 17:34:52 | leorize | for some reason the `main` proc in C starts from some random position in system.nim... |
| 17:35:24 | leorize | when debugging |
| 17:35:26 | leorize | is that a bug? |
| 17:38:26 | * | pigmej quit (Ping timeout: 260 seconds) |
| 17:40:09 | FromGitter | <alehander42> usually you're looking for NimMainModule I think |
| 17:40:09 | * | pigmej_ joined #nim |
| 17:40:09 | FromGitter | <alehander42> but it depends if you want to debug the initialization code in any other modules |
| 17:40:55 | leorize | yea, looks like there's no line info for the "real" `main` proc in C |
| 17:41:17 | leorize | so the debugger just wield up some strange position in system.nim to make up for it |
| 17:41:44 | * | Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 17:45:33 | * | derlafff quit (Ping timeout: 250 seconds) |
| 17:48:31 | * | derlafff joined #nim |
| 17:51:47 | * | Trustable joined #nim |
| 17:52:04 | * | nif quit (Quit: ...) |
| 17:52:13 | * | nif joined #nim |
| 17:56:09 | FromGitter | <mratsim> @timotheecour there is a discussion about D incremental compilation in Halide Gitter room: https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/ |
| 17:56:45 | FromGitter | <mratsim> I suppose it’s an example about what not to do as well :P |
| 17:58:35 | * | Ven`` joined #nim |
| 18:04:29 | * | Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 18:06:35 | * | Trustable quit (Remote host closed the connection) |
| 18:20:54 | * | serialdev[m] joined #nim |
| 18:31:05 | * | dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 18:34:46 | FromGitter | <yyyc514> is it common to just use Json when the idea of a dynamic "payload" is needed? |
| 18:35:35 | FromGitter | <tim-st> I like the golang way, they compile the stdlib only once and copy the precompiled code were needed |
| 18:40:51 | leorize | similar to free pascal I believe? |
| 18:45:54 | * | zachcarter joined #nim |
| 18:47:21 | * | zachcarter quit (Client Quit) |
| 18:48:18 | * | zachcarter joined #nim |
| 18:53:24 | FromGitter | <tim-st> never used pascal :\ |
| 18:54:35 | FromDiscord_ | <treeform> wow tons of packages are being added: https://github.com/nim-lang/packages/pulls |
| 18:54:56 | FromDiscord_ | <treeform> I guess that is a good thing, but more work for dom merging them in. |
| 18:59:42 | FromGitter | <timotheecour> @mratsim ya i had read that post (https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/) ; I’m still following the D forum (always some good ideas floating around that are relevant to Nim); regarding that article: `fork` for checkpointing is a nice idea (although not new) that would be super useful for things like a REPL and a debugger, allowing you to rewind while |
| 18:59:42 | FromGitter | ... preserving all state/memory (minus pid) |
| 19:01:24 | FromGitter | <mratsim> REPL work is ongoing: https://github.com/nim-lang/Nim/issues/8927#issuecomment-438252439 |
| 19:02:27 | FromGitter | <tim-st> btw I added a isPrime for types <= uint32 to rosetta code, maybe it's a candidate for `math`: https://www.rosettacode.org/wiki/Miller–Rabin_primality_test#Nim |
| 19:02:28 | FromGitter | <timotheecour> some ideas could be relevant to Nim incremental compilation perhaps; a client server model (where server preserves cached state for a parsed module, taking into account compiler options as hash key) |
| 19:03:31 | shashlick | @treeform: packages linger for too long in the queue, i have 10+ I need to add but too bored |
| 19:03:32 | FromGitter | <mratsim> @tim-st math is more related to floats while primes are integers |
| 19:04:12 | FromGitter | <tim-st> @mratsim hm, already wondered why some procs dont accept int |
| 19:05:15 | FromGitter | <mratsim> for Miller Rabin I’ve implemented that when I learned Nim: https://github.com/mratsim/nim-project-euler/blob/master/src/lib/primes.nim#L32-L105 |
| 19:06:08 | FromGitter | <tim-st> the good thing of the uint32 version is that it is correct and deterministic for all inputs |
| 19:06:24 | FromGitter | <timotheecour> ok this is where we can draw a clear line : probability that `isPrime` is used (at some point in future) in Nim compiler code? very low; therefore it’d be best in a nimble package (isPrime IS useful obviously; it’s just that IMO I like that criterion for what belongs in stdlib) |
| 19:06:56 | FromGitter | <mratsim> stdlib is not used in compiler code otherwise it would be magic ;) |
| 19:07:06 | FromGitter | <timotheecour> not true; |
| 19:07:14 | FromGitter | <timotheecour> see code under compiler/ |