<<21-11-2018>>

00:04:31jaceredarayman22201, ok, thanks
00:14:08*ftsf joined #nim
00:14:43shashlickcan 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:03FromGitter<zetashift> If I have a table with strings as keys, how would I get a random key from that table?
01:42:06FromGitter<zetashift> nvm using a `toSeq` should do the trick
01:55:06*abm quit (Ping timeout: 244 seconds)
01:59:11FromGitter<zetashift> Huh the table.keys iterator doesn't seem to get picked up instead another overloaded method is used
02:02:17FromGitter<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:17FromGitter<kaushalmodi> hello all
05:54:12FromGitter<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:21FromGitter<kaushalmodi> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bf4f30cfa7bbb3fe0dcd72a]
05:54:32FromGitter<kaushalmodi> .. and I cannot recreate that error locally
05:55:41FromGitter<kaushalmodi> and this is a the config.nims: https://github.com/kaushalmodi/nim_config/blob/master/config.nims
06:25:54leorizedo you really need a proc called `dollar`?
06:26:29leorizeI'd imagine putting `` `$` `` in place of `dollar` would work
06:27:55FromGitter<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:35FromGitter<kaushalmodi> leorize: I had already tried that (`` `$` ``), but that didn't work
06:45:33FromGitter<kaushalmodi> apparently `` `$` `` doesn't share the same generic signature as that `dollar` proc
06:45:59FromGitter<kaushalmodi> @GULPF But then that config.nims won't work for Nim 0.19.1 or any older Nim release
06:46:42FromGitter<kaushalmodi> I thought that the ospaths -> os transition would just introduce a deprecation warning, and ospaths would continue to work as before
06:58:28leorizekaushalmodi: `when NimMinor < 19 and NimPath < 9:` ?
06:58:34leorizeNimPatch*
06:59:23FromGitter<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:48leorizeas long as it's in the top level, it's fine
07:00:41FromGitter<kaushalmodi> thanks
07:01:44leorizeoh, and remember to compare the `NimMajor` as well
07:02:42*mech422_ quit (Ping timeout: 252 seconds)
07:31:03FromGitter<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:14FromGitter<kaushalmodi> the config.nims is actually https://github.com/kaushalmodi/hello_musl/blob/master/config.nims (I mislinked it earlier)
07:33:38leorizehow up-to-date is the Nim you used for your Travis jobs?
07:33:51FromGitter<kaushalmodi> devel branch
07:34:32FromGitter<kaushalmodi> from the Travis log: ⏎ ⏎ > ../nim/574cdfc1569ffeef7fa9e6f7c28339edff93cd87/lib/pure/os.nim(754, 14) Error: undeclared identifier: 'Stat'
07:34:33leorizebut how up to date is it?
07:34:44FromGitter<kaushalmodi> it's using that 574.. hash
07:35:02FromGitter<kaushalmodi> so the last commit 9 hrs ago
07:35:36leorizeweird, you can't reproduce it, right?
07:35:50FromGitter<kaushalmodi> yeah, cannot reproduce it locally
07:36:07FromGitter<kaushalmodi> that Stat declaration is wrappen in when linux and when amd64
07:36:27FromGitter<kaushalmodi> so the cpu arch on Travis somehow doesn't enter that when clause
07:38:32FromGitter<kaushalmodi> leorize: https://github.com/nim-lang/Nim/blob/ce05a850a55a651bcdd01e7af9af9702c8af5caf/lib/system/sysio.nim#L318-L328
07:39:08FromGitter<kaushalmodi> I wonder if it's the `not defined(nimscript)` part..
07:39:13leorizeactually
07:39:21leorizethe error is in os.nim
07:39:42leorizeand that proc was annotated with `{.noNimScript.}`
07:40:18leorizeso it should have never been evaluated
07:40:21*stefanos82 joined #nim
07:41:07FromGitter<kaushalmodi> .. but then cloning that same hello_musl repo locally and running `nim musl src/hello_musl.nim` works
07:41:14FromGitter<kaushalmodi> so this error is strange
07:42:13FromGitter<kaushalmodi> Also pinging Araq: Can you look at this import os and Stat issue; nim devel
07:43:12*krux02 joined #nim
07:50:58leorizeyglukhov: your patch make command call syntax works with your threadpool, but breaks the function calling syntax at the same time
07:51:40leorize@yglukhov ^
08:04:50*jjido quit (Remote host closed the connection)
08:54:00FromGitter<gogolxdong> Anyone interested in fulltime Nim job? We are hiring in China.
08:59:31livcdin Shenzhen ?
08:59:41FromGitter<gogolxdong> We already have a Vulkan expert from TaiWan and need at least one proficient at system programming.
08:59:46FromGitter<gogolxdong> Yes.
08:59:56FromGitter<gogolxdong> How do you know?
09:00:29livcdI know everything!!
09:00:43FromGitter<gogolxdong> Amazing!
09:01:13livcdYour github page mentions it :)
09:02:05FromGitter<gogolxdong> I just know there are lots of Europeans in our community.
09:02:12FromGitter<gogolxdong> ah.
09:04:33livcdI would go just for the opportunity to meet sexycyborg :D
09:06:57FromGitter<gogolxdong> if you have her contact
09:08:17livcdI read somewhere it's easy to meet her as she hags around a lot in the area from her videos
09:09:46FromGitter<gogolxdong> well, Shenzhen is large enough to miss her .
09:12:30FromGitter<gogolxdong> don't know much about her, just checked , and not my style.
09:15:37FromGitter<yglukhov> leorize: oops. fixed again.
09:20:21FromGitter<yglukhov> @gogolxdong that's exciting! what are you gonna do?
09:21:44livcdgogolxdong: 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:08leorizeyglukhov: looks like your `spawn` doesn't have the `{.gcsafe.}` requirement. Is that a feature or a bug? :P
09:24:42FromGitter<gogolxdong> QUIC, Merkle DGA, kademlia, bitswap
09:24:46FromGitter<gogolxdong> DAG
09:25:18FromGitter<yglukhov> cool. why would you need vulkan for those? :)
09:25:31FromGitter<gogolxdong> Vulkan for GUI
09:26:17FromGitter<yglukhov> leorize: err... i think it is... got a gist?
09:26:52FromGitter<yglukhov> @gogolxdong I see. cool. best of luck :)
09:27:57*PMunch joined #nim
09:28:02leorizehttps://ptpb.pw/zAgP/nim
09:28:06leorizehere you go
09:28:17FromGitter<yglukhov> leorize: * i think it is a bug :)
09:28:42FromGitter<gogolxdong> thanks for all your wishes.
09:32:14leorizeyglukhov: looks like playing with threads is going to be a bit more painful if that's the case
09:33:23FromGitter<yglukhov> true. but your current code is crashable otherwise.
09:34:22leorizeyea, if you run `crawl` a lot of time
09:34:23FromGitter<mratsim> crashable :P
09:35:37FromGitter<gogolxdong> later for AI, but Nim is throughout.
09:35:42FromGitter<mratsim> string/seq allocation including echo in thread requires setupForeignThreadGC and teardownForeignThreadGC
09:36:24FromGitter<mratsim> and maybe stack traces:off (I need it for OpenMP parallel loop, not sure if Nim does that automatically with threadpools)
09:36:55leorizenot with the threadpool I'm using
09:37:36FromGitter<mratsim> the stack traces will become SIGSEGV anyway :P
09:38:33leorizewaiting for new runtime so that we can just stop worrying about GC for threads :P
09:38:46FromGitter<yglukhov> leorize: fixed gcsafety enforcement
09:40:03*floppydh joined #nim
09:40:06FromGitter<yglukhov> now good luck making your code gcsafe :D
09:40:21FromGitter<mratsim> it’s not that hard to remember setup/teardownForeignTHreadGC once you know about them
09:40:48leorizethe less friction writing parallel code, the better :)
09:41:07*zakora joined #nim
09:41:10FromGitter<mratsim> I agree
09:41:23FromGitter<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:38FromGitter<mratsim> oh, cool
09:42:18*Vladar quit (Remote host closed the connection)
09:42:55FromGitter<mratsim> I was trying to check that but I got stuck in https://github.com/nim-lang/Nim/issues/9489
09:43:21FromGitter<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:31FromGitter<yglukhov> @mratsim i can compile your sample. fixed?
09:47:01FromGitter<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:20FromGitter<mratsim> I had those strande error happening in other more complex macro cases
09:48:26*Vladar joined #nim
09:50:06FromGitter<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:06leorizeI think it should be automated for the openmp iterator
09:51:57FromGitter<mratsim> I don’t know the cost but you most likely don’t work on string or allocate seq when using OpenMP
09:52:40FromGitter<mratsim> unless when using debug echoes
09:53:25leorizethe idea is that the compiler could "magically" detect when GC memory is used and inject the statements accordingly
09:53:59FromGitter<mratsim> that’s mentioned in OpenMP `||` iterator description, PR wanted ;)
10:10:37FromGitter<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:41FromGitter<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:11AraqI broke the build. again.
10:25:16Araqwhy did nobody tell me? :P
10:26:44*kapil____ quit (Quit: Connection closed for inactivity)
10:27:33*ng0 joined #nim
10:41:26leorizeAraq: 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:17Araq # Doesn't work if destructors are not defined, see #9696 <--- this needs to be fixed asap
10:45:27Araqand 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:53FromGitter<yglukhov> Araq: this looks related https://github.com/nim-lang/Nim/issues/5366, no?
10:53:58AraqI doubt it
11:02:15Araqbtw some numbers
11:02:25Araqthe Nim compiler is roughly 2MB of source code
11:03:15Araqthe AST and type graphs are stored in a Sqlite DB that takes 33MB
11:04:19Araqand in RAM these take up 425MB
11:05:00Araqterrible engineering :-)
11:05:13Araqand I blame it all on 'ref'
11:07:17Araqit'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:47FromGitter<mratsim> you are missing the ratio of source code/comment
11:27:03FromGitter<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:41Araqmore comments mean the compiler is even worse at what it does
11:56:50*stefanos82 quit (Quit: Quitting for now...)
12:07:50leorizeAraq: oops, the linked issue should be https://github.com/nim-lang/Nim/issues/9675
12:08:04leorizeI probably messed up the numbers while creating that example
12:10:27FromGitter<zacharycarter> seems like nativesockets is the best module for me to use for this portion of my new project
12:10:47FromGitter<zacharycarter> tried using asyncnet and net - but I already need to switch my sockets b/w blocking and unblocking
12:10:51FromGitter<zacharycarter> so I need nativesockets anyway I believe
12:13:14FromGitter<dom96> @zacharycarter I'm 99% certain you don't need native socks
12:13:21FromGitter<zacharycarter> okay
12:13:30FromGitter<dom96> Where are you having troubles?
12:13:55FromGitter<zacharycarter> it's not necessarily troubles - but I need to create a socket that I can toggle between unblocking and blocking
12:14:07FromGitter<zacharycarter> I see setBlocking in nativesockets
12:14:20FromGitter<zacharycarter> I'm not using the nativesocket object - I'm still using the socket ref object from net
12:14:35FromGitter<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:41FromGitter<zacharycarter> or if that module was really meant to be paired w/ asyncdispatch
12:14:54FromGitter<zacharycarter> I do NOT have an event loop in my program atm
12:15:41FromGitter<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:35FromGitter<zacharycarter> this is the code I have so far - https://github.com/zacharycarter/zeal/blob/compiler_server/src/zealpkg/socket.nim
12:16:55FromGitter<zacharycarter> working on the `accept` proc atm
12:22:11FromGitter<zacharycarter> I plan on creating a non-blocking version of `accept` and a non-blocking version of `read` as well
12:22:18FromGitter<zacharycarter> once I create the blocking version of `read` that is :P
12:22:33FromGitter<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:22FromGitter<zacharycarter> also - I'm trying to avoid exceptions / the handling thereof in my program if possible
12:23:32FromGitter<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:15FromGitter<zacharycarter> not sure if what I'm describing above makes sense or not @dom96
12:44:37*seni quit (Quit: Leaving)
12:57:38FromGitter<zacharycarter> ah maybe I can get away with using asyncdispatch / asyncnet
12:58:07FromGitter<zacharycarter> and just use `poll` and `sleepAsync` without `runForever`
13:03:01*vlad1777d joined #nim
13:08:20FromGitter<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:04PMunchAraq, 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:59dom96_wzacharycarter: async is already non-blocking.
13:46:07dom96_wEverything relies on exceptions
13:46:55FromGitter<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:09FromGitter<zacharycarter> but I will give this a shot with asyncnet/dispatch thanks dom96_w
13:48:35dom96_wFeel free to use nativesockets, just be prepared to reimplement a lot of what async already does :)
13:48:43dom96_wGood for learning, bad for productivity
13:49:57AraqPMunch, fine with me
13:50:08Araqanything that helps LSP is fine with me
13:51:25PMunchWell I was wondering if it should be done differently, or if that is a good way to do it
13:51:50PMunchAnd also if you had any thoughts on how to make it more easily importable
13:52:10Araqwell the better way is to extract what you need from nimsuggest.nim into libsuggest.nim
13:52:18Araqand import that one instead
13:53:03FromGitter<zacharycarter> dom96_w: thanks I will take your advice and not do that ;)
13:53:11PMunchYeah 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:51dom96_wYeah, I would strongly suggest not to do that :)
13:54:13*gangstacat joined #nim
13:54:18dom96_wIt's already enough that nimsuggest effectively embeds all the compiler sources
13:58:15FromGitter<alehander42> in the compiler there was a way to hint
13:58:27FromGitter<alehander42> where should the lineinfo point
13:58:33FromGitter<alehander42> (or in macros .. i don't remember)
13:58:36FromGitter<alehander42> i think it was a pragma
13:58:38FromGitter<alehander42> what was it
13:59:39FromGitter<alehander42> e.g. if you want your expanded macro to have lineinfo == to the callsite
13:59:44PMunchYeah, 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:55PMunchOr anything else that uses nimsuggest for that matter
14:01:44FromGitter<alehander42> my question is more related to inline iterators: they are *inline*, but their lineinfo points to the iterator definition
14:02:27FromGitter<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:47FromGitter<mratsim> doesn’t the for appear in the stack trace as well?
14:03:39FromGitter<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:56FromGitter<alehander42> @mratsim I am talking about the debugging experience
14:05:17FromGitter<alehander42> in for ..: code, you actually never visit the for line
14:05:18*ng0 quit (Remote host closed the connection)
14:05:33FromGitter<alehander42> you visit (usually) system.nim's iterator lines instead
14:08:24FromGitter<alehander42> actually it all depends on the yield:
14:08:44FromGitter<alehander42> so if we just generate a noop `else` with the callsite lineinfo on each yield
14:08:59FromGitter<alehander42> we'll have a reasonable debugging flow
14:09:09FromGitter<alehander42> Araq, should I PR that ?
14:10:04*kapil____ joined #nim
14:12:21FromGitter<narimiran> i like the idea of showing `for` lineinfo
14:13:35*nsf quit (Quit: WeeChat 2.3)
14:16:32Araqalehander42: er ... what?
14:17:36Araqas far as I'm concerned that is "just a bug" in the compiler/codegen
14:17:36FromGitter<alehander42> currently when you step through `for loops`
14:17:52FromGitter<alehander42> so what is the expected behavior
14:18:08Araqthat you don't step into the freaking system.nim code
14:18:14FromGitter<alehander42> oh I agree
14:18:16Araqbut I know it currently does that. and it sucks
14:18:24FromGitter<alehander42> but I suspected that maybe it makes sense
14:18:28FromGitter<alehander42> to step in user-defined iterators
14:18:50Araqhmm well stepping through is different from "it crashes here"
14:19:05Araqunfortunately we often report the wrong line for "it crashes here"
14:19:37FromGitter<alehander42> ah I see, and lineinfo is used for both (debug info and stacktraces)
14:20:06Araqfor stepping through system.nim is correct bug annoying
14:20:25Araqfor user defined iterators it's essential so we might decide to not "fix" that
14:20:43FromGitter<alehander42> yes, but I think my solution adresses that well
14:20:51FromGitter<alehander42> we can still step through the iterators
14:20:58FromGitter<alehander42> but we also hit the actual `for` line
14:21:03*Vladar joined #nim
14:21:11Araqwhat is your solution?
14:21:18FromGitter<alehander42> and overally a better solution for an user is to just gdb-ignore stdlib_system.c
14:21:28FromGitter<alehander42> or system.nim if he doesn't want to step there
14:21:40*revere quit (Ping timeout: 264 seconds)
14:21:50FromGitter<alehander42> to generate a noop line with the `for` lineinfo for each iterator yield
14:22:35*revere joined #nim
14:23:26FromGitter<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:24FromGitter<alehander42> and lineinfo for crashes remains the same, as it's not touched (I guess)
14:38:04*theelous3_ joined #nim
14:42:54AraqI don't understand it
14:43:07Araqhow would it look like in system.nim?
14:45:22FromGitter<alehander42> it doesn't change anything in system.nim
14:45:56FromGitter<alehander42> it just makes the compiler generate noop statement with the original `for lineinfo` after each yield in iterator
14:46:04FromGitter<alehander42> in debugging regime
14:46:18Araqhmmm
14:46:27Araqmight be a good idea
14:46:54FromGitter<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:36FromGitter<yyyc514> anything yet in the way of pub/sub?
15:02:13FromGitter<mratsim> https://github.com/makingspace/cittadino/blob/master/src/cittadino.nim
15:03:27*ng0 joined #nim
15:07:04FromGitter<yyyc514> yeah i found that
15:08:46FromGitter<alehander42> how is it going with your web framework :O
15:09:15FromGitter<yyyc514> working on phoenix like channels now :)
15:09:29FromGitter<yyyc514> keep getting distracted with tangents, like lightweight process model, etc :)
15:09:52FromGitter<mratsim> ah distractions =) that’s how project time inflates :P
15:10:18FromGitter<yyyc514> that was actually not too hard but i'm still stuck on the best way to handle custom message passing
15:10:25FromGitter<alehander42> ah, are you looking for an actors lib
15:11:40FromGitter<alehander42> can you give an example?
15:11:47FromGitter<alehander42> about the message passing
15:12:06FromGitter<yyyc514> https://gist.github.com/yyyc514/462e2b0782d35ae9cbf5cd285677af98 looking for a way to abstract CounterMessage
15:12:33FromGitter<yyyc514> I want to create 1000s of LIPRs but potentially they'd all be able to communicate however they wanted
15:13:51FromGitter<yyyc514> I'd try inheritance but i think the Future makes that all a mess
15:14:17FromGitter<alehander42> isn't it similar to https://hexdocs.pm/phoenix/Phoenix.Socket.Message.html ?
15:15:19FromGitter<yyyc514> no, this i processes :) think broader
15:15:31Araqit's terrible ;-)
15:15:50FromGitter<yyyc514> what is?
15:15:56*theelous3_ quit (Ping timeout: 244 seconds)
15:16:02FromGitter<mratsim> distractions I guess
15:16:08FromGitter<alehander42> i bet on inheritance
15:16:20Araq1000s of processes
15:16:38FromGitter<yyyc514> well i was going to see how well it worked :)
15:16:43Araqyou can only write these systems. you cannot debug them.
15:17:04FromGitter<yyyc514> no easier than you could debug asynchttp :)
15:17:05FromGitter<yyyc514> same diff
15:17:11FromGitter<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:35FromGitter<yyyc514> well right now this is still all single threaded just trying to get the basics working
15:18:14FromGitter<yyyc514> found out the stack is only 333 deep :)
15:18:27FromGitter<alehander42> so you can still have "quasi-actors", but they can be just normal functions operating safely on the same memory
15:18:33FromGitter<yyyc514> when i tried to chain 1000 futures :)
15:18:38FromGitter<alehander42> but maybe that's what pony does? not sure
15:18:58FromGitter<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:27FromGitter<yyyc514> so you them up and they pause waiting to recv a message
15:21:56FromGitter<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:43FromGitter<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:32FromGitter<yyyc514> by sending messages
15:29:37FromGitter<yyyc514> messages go into the inbox
15:29:50FromGitter<yyyc514> and a process calls recv to poll it's inbox, which is a Future, which hooks into the whole async
15:30:33FromGitter<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:47Araqand you immediately lose the debuggability ;-) stuff goes into inboxes and then you wonder *who* and *why* put crappy data in there
15:31:06FromGitter<alehander42> well, this is a tooling problem honestly
15:31:18Araqeverything is always a tooling problem.
15:31:24FromGitter<yyyc514> right, debugging is often hard if you don't build in proper tooling into any system
15:31:34Araqthrowing away the stack traces is a bad start
15:31:45FromGitter<yyyc514> inboxes are a pretty easy concept to test, very functional
15:32:03Araqthe inbox itself, sure, the stuff that ends up in it, no.
15:32:20FromGitter<alehander42> well I don't think it's very hard to log message send/receive indexed by id-s
15:32:26FromGitter<alehander42> in debugging mode
15:32:27Araqbut what do I know, I only worked on "distributed" systems that didn't need to be distributed
15:32:32FromGitter<yyyc514> this isn't the told dynamic vs static argument is it? :)
15:32:38Araqdebugging was terrible.
15:32:44FromGitter<alehander42> and to make a system that lets you step through this
15:34:20FromGitter<yyyc514> anyways i'll see how all this works with pub/sub and channels :)
15:34:25FromGitter<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:44FromGitter<alehander42> debugging async is often hard too in many languages
15:35:01FromGitter<yyyc514> the async macros are crazy magic though :)
15:35:04Araqsure you use async because you have to, not because it's cool
15:35:08FromGitter<yyyc514> but i understand them a lot better having read the generated code
15:35:58FromGitter<alehander42> Araq, well the actor pattern has different +s and -s, it's not always just a cool factor
15:36:07dom96_wthe async macros are actually very simple
15:36:12FromGitter<alehander42> I also think it's overrated for static languages
15:36:29FromGitter<alehander42> but it's still interesting to play with :D
15:36:44Araqthe actor pattern may have advantages but it's as overrated as OOP was in the 90ies
15:37:02Araqand much like OOP, it starts out with "terrible to debug"
15:37:29Araqand then you patch it ("better tooling", "messages must be immutable")
15:37:32FromGitter<alehander42> my point is, if this is the biggest problem with it, it's not an inherent problem
15:37:49FromGitter<alehander42> i think immutable messages is the whole point
15:38:03FromGitter<mratsim> I see actor as just an extension of channels
15:38:11FromGitter<alehander42> after all you pretend you use soooomething like quasi-pure functions
15:38:52FromGitter<mratsim> I thought the stack was millions call deep (and even was changed to billions)
15:39:09FromGitter<mratsim> ah, you mean at runtime?
15:40:15FromGitter<alehander42> talking about tooling, Araq, how can I get the fileinfo of the place where iterator was expanded
15:43:57FromGitter<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:19Araqby asking the right PNode for its .info, alehander42
15:45:40Araqarnetheduck: I wanted to patch nimfind/nimsuggest to do that
15:45:47*PMunch quit (Quit: Leaving)
15:46:04FromGitter<alehander42> @arnetheduck can't we just add it custom sections to the exe currently ?
15:46:18FromGitter<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:26Araqcan an actor die? if so, what happens to the messages in ether that are about to arrive at it?
15:51:25Araqdoes that mean that every 'send' operation can potentially fail?
15:51:49Araqwhat if the inbox is full? start blocking on the 'send' then?
15:53:05Araqhow do you ensure that your producers are not too fast for your consumers to keep up with the work?
15:53:35Araqetc yadda yadda. Your life is happier without an actor model.
15:54:39*Ven`` joined #nim
15:55:22FromGitter<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:27FromGitter<mratsim> Are people enthusiastic about C macros? :P
16:04:20FromGitter<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:22FromGitter<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:05FromGitter<alehander42> @arnetheduck agree, most other new languages have macros too (elixir, julia, crystal etc)
16:06:37Araqalehander42: but you can build distributed systems that don't multiply the "process problem" by a factor of 1000.
16:07:01Araqevery process is a stateful black box.
16:09:19FromGitter<alehander42> actually there are some tools similar to waht I suggested for elixir/erlang e.g. observer, erlyberly etc
16:10:57FromGitter<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:39FromGitter<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:43FromGitter<alehander42> no idea
16:14:09Araqno, my biggest gripe is that it starts with lots of artificial complexity.
16:14:37FromGitter<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:29Araqlots of application domains come to mind that don't have the problem of "what if message passing to a dying actor fails"
16:17:40Araqit'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:25Araqhttp://personales.upv.es/gvidal/german/flops18/paper.pdf
16:20:34FromGitter<zacharycarter> well in erlang / otp - you don't really handle exceptions
16:20:46FromGitter<zacharycarter> you just let processes die
16:20:56FromGitter<zacharycarter> and there is a supervision hierarchy so the VM knows how to start back up what
16:21:07FromGitter<zacharycarter> and yes - you can hot swap code
16:21:17FromGitter<zacharycarter> but I mean - I agree the actor model is complex - look at how complex Pony is
16:21:40FromGitter<alehander42> yes, I finally made it work
16:21:51FromGitter<alehander42> i didn't realize i have to change the line infos of the children too sometimes
16:23:06FromGitter<alehander42> literally 5 loc of course ..
16:23:23FromGitter<alehander42> so obvious now
16:23:52Araqbtw erlang has exceptions, http://erlang.org/doc/reference_manual/errors.html#exceptions
16:25:20Araqbut 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:38FromGitter<zacharycarter> err I just meant you don't really handle them - instead you do what you just described
16:27:24FromGitter<zacharycarter> which I guess in a sense is handling them - just in a different way
16:27:27FromGitter<zacharycarter> :P but whatever
16:28:48*floppydh quit (Quit: WeeChat 2.3)
16:41:50FromGitter<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:43Araqthat was my bad, rebase or make me merge it anyway
16:46:09Araqalehander42: I would try to base the AST on ideas explored by my packedjson project
16:47:17FromGitter<arnetheduck> Araq, I command you to merge it anyway. now.
16:48:13Araqmaybe you should change your nick to Arcturus
16:50:04Araqugh, you removed getStorageLoc
16:50:26Araqshouldn't the codegen use that instead of the terrible field in TLoc that is so easy to get wrong?
16:51:12FromGitter<arnetheduck> "bear guardian"?
16:51:29FromGitter<arnetheduck> well, honestly I would prefer it did, but it doesn't..
16:52:39FromGitter<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:25Araq"bear guardian"? no, because of https://youtu.be/3V1PwpoDqzM?t=84
16:56:54Araqbut yeah, I agree, so ... please let's not remove getStorageLoc but use it instead
16:58:32Araqcan't be hard, with the newish 'lode' field we have the right datastructure for it
17:01:08FromGitter<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:34Araqyes
17:05:14Araqalso...
17:05:16Araqdup*: Rope # duplicated location for precise stack scans
17:05:26Araq^ nowhere used
17:05:39Araqwe can save 8 bytes in every symbol...
17:07:11FromGitter<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:01Araqwell I can tell you it's gonna break something and most likely won't bootstrap
17:08:19Araqbut there is a chance it will be cleaner once it works
17:09:02Araqwe can also leave it and wait for an AST->AST codegen
17:09:03FromGitter<alehander42> so in the ast-case, you'd just have all nodes be indexes in a big seq?
17:10:24Araqthat's a weird way of putting it
17:11:21AraqI'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:57Araqand since I have a linear store behind it, I can write it to disk easily
17:18:44FromGitter<alehander42> so, basically nodes are indexes instead of refs
17:18:55FromGitter<alehander42> node refs*
17:34:52leorizefor some reason the `main` proc in C starts from some random position in system.nim...
17:35:24leorizewhen debugging
17:35:26leorizeis that a bug?
17:38:26*pigmej quit (Ping timeout: 260 seconds)
17:40:09FromGitter<alehander42> usually you're looking for NimMainModule I think
17:40:09*pigmej_ joined #nim
17:40:09FromGitter<alehander42> but it depends if you want to debug the initialization code in any other modules
17:40:55leorizeyea, looks like there's no line info for the "real" `main` proc in C
17:41:17leorizeso 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:09FromGitter<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:45FromGitter<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:46FromGitter<yyyc514> is it common to just use Json when the idea of a dynamic "payload" is needed?
18:35:35FromGitter<tim-st> I like the golang way, they compile the stdlib only once and copy the precompiled code were needed
18:40:51leorizesimilar 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:24FromGitter<tim-st> never used pascal :\
18:54:35FromDiscord_<treeform> wow tons of packages are being added: https://github.com/nim-lang/packages/pulls
18:54:56FromDiscord_<treeform> I guess that is a good thing, but more work for dom merging them in.
18:59:42FromGitter<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:42FromGitter... preserving all state/memory (minus pid)
19:01:24FromGitter<mratsim> REPL work is ongoing: https://github.com/nim-lang/Nim/issues/8927#issuecomment-438252439
19:02:27FromGitter<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:28FromGitter<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:31shashlick@treeform: packages linger for too long in the queue, i have 10+ I need to add but too bored
19:03:32FromGitter<mratsim> @tim-st math is more related to floats while primes are integers
19:04:12FromGitter<tim-st> @mratsim hm, already wondered why some procs dont accept int
19:05:15FromGitter<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:08FromGitter<tim-st> the good thing of the uint32 version is that it is correct and deterministic for all inputs
19:06:24FromGitter<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:56FromGitter<mratsim> stdlib is not used in compiler code otherwise it would be magic ;)
19:07:06FromGitter<timotheecour> not true;
19:07:14FromGitter<timotheecour> see code under compiler/