<< 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/
19:08:03FromGitter<timotheecour> I think that’s a simple objective way to delimit what goes in stdlib vs what goes in nimble
19:08:27FromGitter<mratsim> No, it delimits what goes into compiler magic vs the rest
19:08:49shashlickdom96: i'd suggest delegating the package acceptance to someone else, and perhaps have a frontend on nimble.directory for submissions
19:08:51FromGitter<alehander42> yeah, a lot of the stdlib is probably not too useful for a compiler
19:09:32FromGitter<alehander42> it's not a good rule
19:09:39FromGitter<mratsim> for stdlib vs nimble, I’m not too sure of what criteria but I guess it’s a function of complexity, maintenance and usefulness
19:09:56FromGitter<alehander42> but overally I agree that we shouldn't put a lot of stuff in the stdlib
19:10:12FromGitter<mratsim> OS stuff definitely shuld be in stdlib
19:10:18FromGitter<alehander42> as solutions can evolve and compete as 3rd party modules first
19:10:24FromGitter<mratsim> oh, and the cost of fragmentation
19:10:47FromGitter<mratsim> I don’t think we risk much fragmentation with math stuff
19:11:00FromGitter<mratsim> but for DB or serialization it’s worth it.
19:11:21FromGitter<alehander42> what is worth it ?
19:11:35FromGitter<mratsim> putting them in stdlib
19:11:42FromGitter<alehander42> ugh
19:11:45FromGitter<timotheecour> well there’s often 1 true nimble package for 1 thing (eg cligen, glob), so fragmentation doesn’t have to be a real issue
19:11:57FromGitter<alehander42> serialization formats and their representation change so often
19:12:02FromGitter<mratsim> so that you don’t have 3 CSV parsers with different formats
19:12:16FromGitter<alehander42> and you have choices between very different nim possible api-s for most of them
19:12:52FromGitter<alehander42> look at serde
19:13:07FromGitter<alehander42> it evolved independently and won against other 3rd party libs
19:13:25FromGitter<alehander42> (I guess? it seems like a 3rd party lib)
19:13:45FromGitter<mratsim> Yeah I think it started as 3rd party
19:14:03FromGitter<mratsim> it won against the official “Encoder/Decoder” API as well
19:14:13FromGitter<alehander42> it just seems very hard to get the best possible api design for many areas from the first try
19:14:22FromGitter<mratsim> that I agree
19:15:11FromGitter<alehander42> so I think that maybe if a 3rd party lib eventually starts to dominate in its area and be very useful in general, it might make sense to include it in stdlib
19:15:27FromGitter<mratsim> This was the serialization story in Rust: https://doc.rust-lang.org/1.1.0/serialize/trait.Encodable.html ⏎ ⏎ —> Encodable/Decodable traits —> rust-serialize 3rd party —> Serde
19:15:30*Vladar quit (Remote host closed the connection)
19:15:39FromGitter<mratsim> rustc-serialize*
19:16:07FromGitter<alehander42> on the other hand you're right about math: math is well understood, so some things might be more ok to be directly builtin
19:16:25FromGitter<alehander42> (but still you have the api thing: imagine how many dsl-s can you have for symbolic math etc)
19:16:31FromGitter<mratsim> math has math.h so we can directly copy-paste
19:16:41FromGitter<timotheecour> the problem is `math` can grow indefinitely, there is no clear boundary of where it stops; hence, nimble package could make more sense
19:16:47FromGitter<mratsim> but take json for example
19:16:55shashlickwell, if you want to be conservative with what goes into the stdlib, the packages landscape needs to get some love too
19:17:06FromGitter<mratsim> math is just math.h from C. Not the kitchen sink
19:17:18FromGitter<timotheecour> well then isPrime is out
19:17:48shashlickin fact, you can move most of the stdlib also into packages and have them pulled on clones/packaging
19:18:12FromGitter<alehander42> my problem with isPrime is : you can add more stuff e.g. https://ruby-doc.org/stdlib-2.5.1/libdoc/prime/rdoc/Prime.html
19:18:20FromGitter<alehander42> it's not obvious where to stop
19:18:43FromGitter<timotheecour> one could imagine also standard nimble extensions of modules in stdlib, eg: `pkg/os2` (or a better name so long it contains originating stdlib module `os`) that would extend `std/os` with more functionality
19:18:46FromGitter<mratsim> I started a number-theory package for primes and integer: https://doc.rust-lang.org/1.1.0/serialize/trait.Encodable.html
19:18:57FromGitter<mratsim> sorry: https://github.com/numforge/number-theory
19:19:13FromGitter<alehander42> @mratsim well, maybe json should be builtin as it's extremely popular
19:19:35FromGitter<alehander42> but still I'd argue that the JsonNode type might be better as some kind of DynamicValue
19:19:36FromGitter<mratsim> though I need to transfer lots of my project euler routines https://github.com/mratsim/nim-project-euler/tree/master/src/lib
19:19:48FromGitter<timotheecour> json should be “in” according to definition of “if it may be used (in future) in compiler sources, it should be in stdlib"
19:19:52FromGitter<alehander42> which can be expected from yaml/toml/other dynamic cases too
19:20:12FromGitter<mratsim> yeah I agree, even CSV parser will find jsonNode useful
19:20:42FromGitter<alehander42> it makes a bit more sense for the stdlib to define standard types/interfaces and expect different 3rd party impls conforming to them
19:21:17FromGitter<mratsim> except when you don’t know the proper interface (like the Serde-story)
19:21:20FromGitter<timotheecour> regarding json, in D, JsonNode (and BsonNode) is a struct (ie value type) , but in Nim, JsonNode and BsonNode are reference types; I’m wondering which design is better
19:21:48FromGitter<alehander42> @mratsim nice! I wanted to do something about symbolic math, but it's a big area and i have no time: maybe eventually wrapping sympy newer c++ engine might be cool
19:25:49*Perkol joined #nim
19:27:34*Vladar joined #nim
19:27:49*Sentreen quit (Ping timeout: 250 seconds)
19:35:51Araqtimotheecour: IMHO the "compiler is a server" model brings too many downsides
19:37:15Araqor to put it differently, it has exactly the same problems as the more traditional "store something to disk" solution
19:37:37FromGitter<timotheecour> well it avoids serialization though
19:38:23FromGitter<timotheecour> can you elaborate on the downsides?
19:39:02Araqyou start with the same problem, a compiler that builds a complex graph of cross module references everywhere and then you would like to recompile only a subgraph and fight with the cross module boundaries that are everywhere and cause serious trouble
19:39:34Araqso you need to untangle this cross ref mess
19:39:50Araqand with a serialization you're at least forced to do it properly
19:39:55FromGitter<timotheecour> @araq did you read https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/ ?
19:40:18Araqwhen you keep it in RAM the chance is high that something points to an outdated module version
19:40:28Araqyes, I read it.
19:40:28FromGitter<timotheecour> it’s quite relevant ; not saying all is applicable to Nim (because to cyclic deps (yet…)) but still some could be
19:40:46AraqI did read it.
19:41:20Araqthings are easier when you design the compiler from scratch with this problem in mind but neither D's nor Nim's compiler did.
19:41:55Araqor maybe both started with a vague idea of that in mind (Nim has an ID mechanism at least)
19:43:03FromGitter<timotheecour> well we already have a notion of transitive closure (IIRC from reading sources) that gets marked as dirty when something is recompiled
19:43:11Araq(and D has the generated interface files)
19:45:41FromGitter<Varriount> Araq: Congrats on the incremental compilation!
19:46:01Araqtoo early, it fails for the compiler itself
19:46:11Araqbut there is hope and progress.
19:46:34FromGitter<alehander42> but it works on smaller programs?
19:54:18*zachk joined #nim
19:55:25*Ven`` joined #nim
19:59:32*Ven`` quit (Client Quit)
20:03:43*Perkol quit (Remote host closed the connection)
20:06:47*nsf quit (Quit: WeeChat 2.3)
20:07:23*zachk quit (Changing host)
20:07:23*zachk joined #nim
20:07:31FromGitter<timotheecour> ya i’m geting `Error: internal error: encodeType: tyForward` when I’m trying it… :-(
20:13:02*rokups quit (Quit: Connection closed for inactivity)
20:21:10Araqalehander42: it works on "hello world"
20:29:59FromGitter<timotheecour> playing a bit with —incremental ; on a hello world (to avoid above internal error), I’m getting: ⏎ 11821 lines compiled; 1.153 sec total; 31.102MiB peakmem; Debug Build with —incremental:on ⏎ Vs: ⏎ 34338 lines compiled; 0.482 sec total; 48.645MiB peakmem; Debug Build with —incremental:off ⏎ => yay! ... [https://gitter.im/nim-lang/Nim?at=5bf5c047ced7003fe164eaf1]
20:31:23FromGitter<timotheecour> I’ve also added `--hint:CC:on --hint:processing:on` to see what gets processed; ⏎ CC: stdlib_system disappears however the modules are still being processed: ⏎ `Hint: strformat [Processing]` etc
20:33:32FromGitter<timotheecour> actually it’s really weird: `--incremental:on` processes MORE modules than `--incremental:off` ⏎ All I’m doing is compiling: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bf5c11ce25cc27405212e46]
20:37:43*PMunch joined #nim
20:52:29Araqwell please note that once the bugs are fixed it's a 50% solution as the full codegen is re-run
20:52:30*PMunch quit (Remote host closed the connection)
20:52:41Araqthe codegen will get its own caching mechanism
20:52:53*PMunch joined #nim
20:53:21*theelous3_ joined #nim
21:13:39FromGitter<alehander42> hey @mratsim , do you know of any libs good for symbolic tranformation of summations?
21:14:05FromGitter<alehander42> e.g. Sum(i in 0 ..< n: n - i)
21:14:53FromGitter<mratsim> no, besides Maple and Mathematica while I was a student I’m not familiar with symbolic computing
21:15:06FromGitter<mratsim> well and my graphing calc as well.
21:15:35FromGitter<mratsim> but this is n*(n+1) / 2
21:15:42*krux02 quit (Remote host closed the connection)
21:16:23FromGitter<alehander42> yes, I know
21:16:30FromGitter<alehander42> but it's not obvious to my computer :(
21:17:27FromGitter<mratsim> I would convert that to some kind of AST and then run a parser for further transofmrations
21:18:38FromGitter<alehander42> as mickens said, if you put a SICP on top of a cpu, it still won't learn lisp by osmosis
21:18:49FromGitter<alehander42> i really love this guy's papers
21:19:27FromGitter<alehander42> oh, it is structured already, I just have to find common algorithms that do it I guess
21:20:05FromGitter<alehander42> I just wondered if there is actually a good general way to generate polynomials from those, but if maple can do it, that's promising
21:20:13FromGitter<mratsim> Here are some links: https://stackoverflow.com/a/39996849
21:20:39FromGitter<mratsim> I think Maple and mathematica are using AST (hopefully not regex :D)
21:21:15FromGitter<alehander42> ah, I see
21:21:28FromGitter<alehander42> no, numerical transormation should be easy indeed
21:21:35*stefanos82 quit (Quit: Quitting for now...)
21:21:54FromGitter<alehander42> I am talking more about ughh expansion?
21:21:58FromGitter<alehander42> not really sure of the term
21:22:00FromGitter<mratsim> Ah, I remember, the keyword is CAS for COmputer Algebra System
21:22:43FromGitter<mratsim> Taylor expension?
21:22:47FromGitter<mratsim> expansion*
21:25:28FromGitter<timotheecour> IIRC the more general way to solve `Sum(epr(n)) =P(n)` where P is a polynomial of fixed max degree (2 in this case)
21:25:49FromGitter<timotheecour> *is to solve...
21:26:19*pwntus quit (Ping timeout: 246 seconds)
21:26:47*pwntus joined #nim
21:26:47FromGitter<mratsim> I remember doing Riemann summations for hours in school >_>, this has a lot of summations: https://en.wikipedia.org/wiki/Divergent_series
21:27:32FromGitter<timotheecour> oh man, fun memories of class prepa...
21:27:55FromGitter<mratsim> yeah exactly
21:29:23FromGitter<alehander42> oh well
21:29:27FromGitter<alehander42> yeah @timotheecour
21:29:37FromGitter<alehander42> I am just not sure if there is a good way to solve this in general
21:30:00FromGitter<alehander42> as the wiki link shows, there are a lot of classes of summations needing different approaches
21:30:28FromGitter<alehander42> basically i was wondering what is blocking automated big O calculation for simple algos
21:30:45FromGitter<alehander42> and this kind of symbolic math is one of the needed ingredients
21:31:15FromGitter<timotheecour> oh i c, that’s ur use case..
21:32:22FromGitter<alehander42> yeah, I guess for a lot of common cases one can even hardcode some simpler logic
21:32:37FromGitter<alehander42> as usually you have simple polynoms as input too
21:35:05*Vladar quit (Remote host closed the connection)
21:40:35FromGitter<timotheecour> well for sure Nim would be an attractive language for symbolic math thanks to ease of writing DSL’s ; maybe wrapping c++ symbolic math libraries in Nim (with a nice Nim DSL shell around it) would be a start; there are a number of choices (some of which were used in `Maple` ), as I’m sure you’ve already seen, eg: ⏎ ⏎ 1) https://en.wikipedia.org/wiki/SymbolicC%2B%2B ⏎ 2)
21:40:35FromGitter... http://viennamath.sourceforge.net/viennamath-example-integration.html ⏎ 3) https://www.sympy.org/en/index.html ... [https://gitter.im/nim-lang/Nim?at=5bf5d0d3fa7bbb3fe0e2b8e5]
21:47:11FromGitter<alehander42> I think https://github.com/symengine/symengine is a good choice
21:49:06FromGitter<alehander42> I don't really have time tho, so I can't commit on that
21:49:31FromGitter<alehander42> I might only wrap/implement a minimum needed for my experiments
21:49:43FromGitter<alehander42> but it's a great project idea
21:50:47FromGitter<timotheecour> actually another use case is for deep learning, ie, computing gradients given math representation of activation function etc, and using a nice DSL
21:51:08shashlickdid anyone have any feedback on nimterop?
21:54:24FromGitter<timotheecour> weird, google doesn’t find it … https://github.com/genotrance/nimterop for others
21:54:43shashlickt
21:54:46shashlicktoo early perhaps
21:55:27FromGitter<timotheecour> what do you mean `not procs` in https://github.com/genotrance/nimterop/issues/1#issuecomment-440342382 ?
21:55:48FromGitter<timotheecour> is that a limitation of nimterop (that could be fixed ) or of tree-sitter ?
21:56:11shashlicknimterop - i've added some support already
21:56:18shashlicknow working on pointers so it will get expanded
21:56:24shashlickcheck out the test
21:59:01FromGitter<timotheecour> i’m curious what are limitations (not of what’s translated (eg procs), but of what sources can be correctly parsed by tree-sitter; I’m thinking of more complex C++ libs eg opencv
21:59:17*sz0 joined #nim
22:01:08shashlicki've been reporting issues as I find them
22:01:18shashlickso it will be a process
22:01:25shashlickbut they have been very prompt with responses
22:01:31shashlickand have made fixes overnight
22:02:03shashlickso i now really believe when I state "Benefit from the tree-sitter community's investment into language parsing" on the README
22:02:16*ghost64 quit (Quit: See you!)
22:02:27FromGitter<timotheecour> i’m very curious how tree-sitter can work without semantic analysis; my IIUC, to correctly parse C++ you kind of need to do semantic analysis
22:02:48shashlickvery well might be - that's why i've been requesting a review of my approach
22:03:20shashlickbut again, i'm limiting my efforts to wrappers only, not outright conversion of code
22:03:35shashlickso as long as we can cover header file grade code, we should be okay
22:04:23FromGitter<timotheecour> but even for header, how will it deal with templates?
22:04:59FromGitter<timotheecour> (c++ templated classes and functions)
22:05:39shashlickit will convert it to its AST
22:05:50shashlicki think it will help me if you can give me an example
22:05:56*ghost64 joined #nim
22:06:17FromGitter<timotheecour> well i’m stuck on install step
22:06:32FromGitter<timotheecour> nimble install 'http://github.com/genotrance/nimtreesitter?subdir=treesitter’ ⏎ system/nimscript.nim(237, 7) Error: unhandled exception: FAILED: nimgen treesitter.cfg
22:06:45FromGitter<alehander42> @timotheecour yeah , there are a lot of uses: i wonder if the nimtorch people thought of that
22:09:09FromGitter<timotheecour> @shashlick I also tried: ⏎ git clone https://github.com/genotrance/nimtreesitter && cd nimtreesitter && nimble develop => fails as no nimble file
22:09:42shashlickwell, the nimble file is in nimtreesitter/treesitter
22:10:31FromGitter<timotheecour> @alehander42 for gradients in deep learning frameworks, there’s also theano, eg: http://deeplearning.net/software/theano/tutorial/gradients.html
22:12:02FromGitter<timotheecour> @shashlick hmmm is that file organization standard? (IIRC the nimble file should be where the package is, so we can `nimble develop` it independently of other packages if we want); but in any case right now even ur instructions in readme don’t work
22:12:27shashlickwell so that's how you can have a repo with multiple packages
22:12:36shashlickeach subdir can have its own nimble develop
22:13:26shashlickworks for me - i think nimgen isn't installing
22:13:36FromGitter<timotheecour> `File doesn't exist: utf8proc_data.c` seems the root cause
22:14:05FromGitter<timotheecour> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bf5d8ada115c91ef7709401]
22:14:44shashlickwhat OS are you on - let me bet MacOSX
22:14:59FromGitter<timotheecour> osx
22:15:24FromGitter<timotheecour> (as u can guess from `/Users/timothee/`)
22:16:15shashlickwhat do you get when you try to install from the local clone
22:16:22shashlicknimtreesitter/treesitter
22:16:48shashlickthere's nothing OS specific
22:17:02shashlickalso, what version of nimgen do you have - nimble path nimgen
22:20:27FromGitter<timotheecour> nimble path nimgen ⏎ /Users/timothee/.nimble/pkgs/nimgen-0.5.0
22:21:21FromGitter<timotheecour> note: it works after i manually did: ⏎ `nimble develop` from: ⏎ $nim_D/nimtreesitter/treesitter_cpp ⏎ $nim_D/nimtreesitter/treesitter_c ⏎ $nim_D/nimtreesitter/treesitter ... [https://gitter.im/nim-lang/Nim?at=5bf5da61b6c07010526849cd]
22:23:14FromGitter<timotheecour> > well so that's how you can have a repo with multiple packages ⏎ ⏎ ya i hadn't realize nimble packages were nested inside subdirs there
22:24:02FromGitter<genotrance> well, you need to do a nimble install on nimterop or the toast binary doesn't get built
22:24:22shashlicki'm just wondering why tree-sitter isn't installing for you from url
22:24:42shashlicki just switched from using strings to enums and i'm still using a lot of RAM, wondering
22:24:59FromGitter<timotheecour> Also this: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bf5db3b958fc53895cbae13]
22:25:57shashlickprobably cause toast isn't built
22:26:23FromGitter<timotheecour> ```you need to do a nimble install on nimterop or the toast binary doesn't get built``` ⏎ ⏎ well i ran `nimble develop` from nimterop root so that shd be enough no? [https://gitter.im/nim-lang/Nim?at=5bf5db8fced7003fe1659b56]
22:27:08shashlicktry toast on the command line
22:27:18shashlicknimble develop claims it doesn't build binaries
22:28:12FromGitter<timotheecour> right right right; it should’ve been `nimble develop + nimble build`; in any case: ⏎ both build and install fail: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bf5dbfca115c91ef770ae6c]
22:29:12FromGitter<genotrance> doesn't look like nimble develop ran nimgen on treesitter either
22:29:30FromGitter<genotrance> have to go to treesitter, treesitter_c and treesitter_cpp and nimble setup
22:30:04shashlickthat's why nimble install is preferred
22:30:19shashlickneed to check on my mac
22:31:20FromGitter<timotheecour> ok done; some progress: now `nimble install` inside nimterop gives: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bf5dcb7c6cf4524d157a4ea]
22:31:48FromGitter<timotheecour> (sorry for spamming everyone about this, but it’s a million times more efficient than through GitHub in that case)
22:32:10shashlickwe could switch to nologs or offtopic if preferred
22:33:05FromGitter<timotheecour> actually logs ARE useful to keep (eg if someone has same error and searches trough logs) but sure how do i join offtopic on gitter?
22:34:23shashlickya i need to probably remove -std=gnu++14 and change it to gnu14 cause you only need --gcc.linkerexe:"g++"
22:35:05shashlickbut basically need to fix this all on mac
22:36:01FromGitter<timotheecour> ok can you please ping me when you want me to re-try?
22:36:18FromGitter<timotheecour> (unless u have a quick fix for that issue)
22:36:32shashlickhttps://gitter.im/nim-lang/twitch is offtopic, but there's no nologs link in gitter
22:36:39shashlickanother alternative is the nimgen group
22:36:54shashlickhttps://gitter.im/nimgen/Lobby
22:37:17shashlickgive me a sec, let me see if I can repro
22:38:56shashlicki just tried nimble install https://github.com/genotrance/nimtreesitter?subdir=treesitter and it just worked fine
22:39:05shashlickare you on devel or some older version?
22:41:23*PMunch quit (Quit: Leaving)
22:56:45*vlad1777d joined #nim
23:02:56dom969 new Nimble packages, wow.
23:03:20FromGitter<kayabaNerve> dom96 Over what time period and is that a lot or a little?
23:04:04dom96well, 9 notifications. 6 new packages
23:04:05dom96Still a lot
23:04:09dom96For one day
23:06:07dom96You guys know of any frameworks for writing GitHub bots?
23:07:53FromDiscord_<treeform> dom86, have you though about site like https://nimble.directory/ but where you can also upload packages and manage them etc...?
23:08:45FromDiscord_<treeform> oops dom96*
23:08:54dom96Of course :)
23:09:08dom96That is still the plan
23:09:15dom96Someone just has to implement it
23:09:27FromDiscord_<treeform> Do you have like a wishlist of features it should have?
23:13:59*kapil____ quit (Quit: Connection closed for inactivity)
23:16:46shashlickhow efficient are enums in terms of storage?
23:17:17FromGitter<alehander42> i guess the smallest possible int ?
23:17:37dom96treeform: Most of the things I want are things that other languages have, for example download stats
23:17:40dom96documentation for the packages
23:17:45dom96good search
23:17:47dom96etc.
23:17:52dom96Nimble.directory already does a lot
23:18:25shashlickdom96: you really need to delegate package acceptance
23:20:07dom96To who?
23:20:25dom96There is plenty of members in nim-lang org already that have access
23:20:32dom96It's a boring job :)
23:20:52shashlickwell, i have 10 more packages I want to submit but it takes a long time
23:20:54FromGitter<alehander42> i think there is value in manually looking at package additions
23:21:30shashlickplus having to keep resolving conflicts
23:28:48dom96make a single PR with all the packages?
23:31:36*ng0 quit (Quit: Alexa, when is the end of world?)
23:33:50shashlickhave 23 packages to push - 19 are treesitter related of course
23:34:07shashlickcan you accept nimzbar meanwhile? i commented on the failure you mentioned