<< 07-12-2018 >>
00:05:41FromGitter<rayman22201> slightly off topic, but this is damn cool: https://www.youtube.com/watch?v=mOtKD7ml0NU
00:06:10FromGitter<rayman22201> How close to linear types can you get with Nim macros and typedesc?
00:06:27FromGitter<rayman22201> *philosophical question hat
00:31:37*platoff quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:50:32*CcxWrk quit (Ping timeout: 250 seconds)
00:58:49bozaloshtshwhat would be a good way to make an async proc 'atomic'? Meaning that it will wait if another instance of it is running.
00:59:11bozaloshtshthe last word 'running' means 'waiting for a async call within it to finish'
01:06:36*lritter quit (Ping timeout: 252 seconds)
01:07:17*lritter joined #nim
01:08:45*ng0 quit (Quit: Alexa, when is the end of world?)
01:22:09*CcxWrk joined #nim
01:31:02FromGitter<rayman22201> @bozaloshtsh I'm not sure If I understand the question? You can do https://nim-lang.org/docs/asyncdispatch.html#waitFor%2CFuture[T], or check the status of a future with https://nim-lang.org/docs/asyncfutures.html#finished%2C
01:34:21FromGitter<rayman22201> If I understand you correctly, what you are asking kind of defeats the purpose of async. What you really want is something like locks: https://nim-lang.org/docs/locks.html
01:37:27bozaloshtshrayman22201: Here is a more concrete exa
01:37:32bozaloshtshexample*
01:37:59*NimBot joined #nim
01:38:10bozaloshtshA will be called repeatedly, but I don't want any calls to B from separate calls to A to be interleaved.
01:38:57*vlad1777d quit (Remote host closed the connection)
01:39:23bozaloshtshI'm not defeating the purpose of async; I want the event loop to continue running between calls to B, just calls to A have to wait.
01:39:58bozaloshtshlocks don't work because they block the main thread
01:40:33FromGitter<rayman22201> locks won't block the main thread. They will block whatever thread is running B()
01:40:47leorizeyou can just poll until B() is finished
01:41:04*vlad1777d joined #nim
01:41:59bozaloshtshrayman22201: I assume B() is running in the same thread as everything else. I don't use threads, only asyncdispatch which I understand to be single-threaded.
01:42:15bozaloshtshleorize: like asyncdispatch's poll proc? Doesn't that also block the main thread?
01:42:24FromGitter<rayman22201> poll blocks
01:42:38FromGitter<rayman22201> You are going to have to block somehow to get those semantics
01:42:57leorizeyou can set a timeout for `poll()`
01:43:05leorizeit's 500ms by default I think
01:44:56bozaloshtshleorize: where do you propose this poll call be placed? Inside of A?
01:46:25bozaloshtshrayman22201: I don't think so. It can be done with a queue and some async magic
01:46:57FromGitter<rayman22201> A queue is a form of blocking :-P
01:47:05bozaloshtshyeah, but only calls to A are blocked
01:47:16bozaloshtshthat's perfectly fine, I just don't want other things that are happening to be blocked
01:47:45bozaloshtshand ideally, I want this to be baked into the future that A() returns
01:49:56FromGitter<rayman22201> The naive thing you could do would be something like: ⏎ let b_fut = B() ⏎ while (true): ⏎ if(b_fut.finished()): ⏎ ... [https://gitter.im/nim-lang/Nim?at=5c09d1c44808192b03f8b30e]
01:50:17FromGitter<rayman22201> inside of A()
01:51:00bozaloshtshyep, but the while true blocks everything else
01:51:11FromGitter<rayman22201> that's why you sleepAsync
01:51:35FromGitter<rayman22201> that returns control to the event loop. Sorry for the crappy formatting, that sleepAsync is inside the while loop
01:51:37bozaloshtshand if sleepAsync entertains a call to A again?
01:51:50bozaloshtshremember, A is triggered asynchronously as well.
01:52:37FromGitter<rayman22201> hrmmm. yes. you are right. That won't work. You have to make b_fut be "global" or at least keep that as state somewhere
01:52:41bozaloshtshI think the standard library has nothing for me here, I'm going to have to roll my own async lock
01:52:59FromGitter<rayman22201> you are correct, there is nothing built in to Nim for this
01:53:29FromGitter<rayman22201> also, the sleepAsync solution makes it super not performant / bad impl imo
01:54:03FromGitter<rayman22201> You could wrap B() in helper that keeps the state / keeps a queue.
01:55:00FromGitter<rayman22201> You are essentially re-implementing condition variables for async.
01:55:22bozaloshtshrayman22201: yep, it seems that's what I'm doing right now
01:55:34FromGitter<rayman22201> there be dragons 🐉
02:06:18FromDiscord_<Virepri> Ok so, I must be stupid. Is it possible to have variables in a seperate nim file? I'm just not able to figure out how to reference one.
02:06:31FromDiscord_<Virepri> this is my directory structure
02:06:31FromDiscord_<Virepri> https://cdn.discordapp.com/attachments/371759389889003532/520420810331127827/unknown.png
02:06:49FromDiscord_<Virepri> and I'm trying to reference `day1.input`, but it just can't seem to find its existence
02:08:47FromDiscord_<Virepri> like, what _should_ my file structure look like?
02:10:48FromGitter<rayman22201> did you add the `*` character to export the variable? https://nim-lang.org/docs/manual.html#procedures-export-marker
02:11:03FromDiscord_<Virepri> oh
02:11:33FromDiscord_<Virepri> yup, that did it, as a matter of fact
02:11:36FromGitter<rayman22201> lol. np. It's a common mistake.
02:11:46FromDiscord_<Virepri> thanks! Sorry if I ask a buncha dumb questions, I'm just totally new to nim
02:11:58FromGitter<rayman22201> no worries. glad to have you
02:17:57*virepri joined #nim
02:18:17*virepri quit (Remote host closed the connection)
02:19:55*Snircle_ quit (Quit: Textual IRC Client: www.textualapp.com)
02:25:28*theelous3_ quit (Ping timeout: 246 seconds)
02:26:32FromDiscord_<technicallyagd> Does anyone here use https://github.com/zero-functional/zero-functional ?
02:27:12FromDiscord_<technicallyagd> It looks really neat, but I can't get nimsuggest to provide auto-complete for its routines
02:29:12FromDiscord_<technicallyagd> @Virepri Welcome! always glad to see more people start using nim
02:29:39FromDiscord_<Virepri> @technicallyagd ty!
02:35:50bozaloshtshrayman22201: https://hastebin.com/raw/ikevipetaf
02:36:04bozaloshtshthis is what I came up with, and it seems to solve my synchronization problem
02:39:19*zachk quit (Quit: Leaving)
02:41:19*a_chou joined #nim
02:59:57*dddddd quit (Remote host closed the connection)
03:02:11*a_chou quit (Remote host closed the connection)
03:02:30*a_chou joined #nim
03:03:14FromGitter<m4d3bug> How to design the parameters when a function accepts one more key-value pairs in the Nim?
03:07:43*banc quit (Quit: Bye)
03:09:40FromGitter<m4d3bug> such as echo
03:21:41FromDiscord_<technicallyagd> https://nim-lang.org/docs/manual.html#types-varargs
03:21:51FromDiscord_<technicallyagd> do you mean varargs?
03:24:10*banc joined #nim
03:28:14FromGitter<m4d3bug> It seems good choice
03:30:37*a_chou quit (Quit: a_chou)
03:31:22FromDiscord_<technicallyagd> That's how echo does it
03:39:49FromGitter<m4d3bug> what If I need them to consist key-value pairs? @technicallyagd
03:55:25FromGitter<gogolxdong> Is there a way to parse php in Jester?
04:12:28FromDiscord_<technicallyagd> @m4d3bug I am not sure, maybe use tables? https://nim-lang.org/docs/tables.html
04:14:50*vlad1777d quit (Ping timeout: 268 seconds)
04:35:54FromGitter<zacharycarter> sweet
04:36:30FromGitter<zacharycarter> my lock-free work stealing job system is working in my engine :D with bgfx :D
04:42:44FromGitter<zacharycarter> the render thread is tied to the main thread and then I can toss jobs at a scheduler
04:43:27FromGitter<zacharycarter> each job executes on its own thread and I can pass data to jobs as pointers to data living on the shared heap
04:43:44*nsf joined #nim
04:50:34*narimiran joined #nim
04:51:10FromGitter<zacharycarter> https://github.com/zacharycarter/zeal/tree/JobScheduler
04:57:37*endragor joined #nim
05:03:38*lritter quit (Remote host closed the connection)
05:04:30FromGitter<rayman22201> @bozaloshtsh cool. good stuff. It's small but it would be useful as a nimble pkg. Speaking of which, I just discovered there already is a nimble package with a similar implementation by cheatface: https://github.com/cheatfate/asynctools. I always forget about https://nimble.directory/
05:06:37FromGitter<rayman22201> also @zacharycarter congrats. looks like you are making a lot of progress. That's awesome.
05:13:40FromGitter<zacharycarter> thanks!
05:52:22FromGitter<gogolxdong> @zacharycarter Is your hyperHTML going on ?
05:53:43FromGitter<zacharycarter> @gogolxdong - no I haven't been doing much web dev lately
05:54:02FromGitter<zacharycarter> I have to do too much of that at work for it to be fun outside of it
06:06:11FromGitter<xmonader> I wrote down the good, and pain points of using Nim in production https://xmonader.github.io/nim/2018/12/06/nim-good-ok-hard.html as an enduser of the technology
06:09:24narimiran@xmonader do you have twitter? will you post a link there too?
06:10:05bozaloshtshrayman22201: oh, cool, thanks for digging this up. That implementation is quite simple to what I wrote but I can tell that there's been many more hours of debugging behind it.
06:10:15bozaloshtshs/simple/similar/
06:15:12FromGitter<xmonader> @narimiran I do have one @xmonader (not very active) and just posted the link there
06:25:55narimiranretwitted :)
06:26:34FromGitter<xmonader> oh thank you! I hope it doesn't reflect bad on the hard parts though
06:31:20*anamok joined #nim
06:31:22anamokhi
06:31:33anamokHow do you remove a given element from a seq?
06:33:05FromGitter<xmonader> not .delete?
06:33:36FromGitter<xmonader> if by index i guess .delete if by the actual object you should move go table instead of a sequence
06:34:18anamokI want to delete by value
06:34:44bozaloshtshso I'm trying to figure out why my program is so slow
06:34:48leorizeanamok: use `find()` to look for the index then `del()`
06:35:05bozaloshtshI start up nimprof and the stack overflows lol
06:35:10bozaloshtshthis doesn't bode well
06:39:09anamokleorize, if you want to keep the order, use delete()
06:39:40leorizeyep
06:39:45anamokdel() moves the last element to the position of the element you want to delete, thus it's O(1), but the order will mess up
06:39:54leorizeactually, you could also use `sequtils.filterIt`
06:40:46anamokI found what I need: a = @[5, 7, 9] ; a.delete(a.find(5)) ; echo a -> @[7, 9] . Thanks.
06:42:40FromGitter<data-man> @anamok: Something like: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c0a166028907a3c7bdf24f7]
06:45:55*narimiran quit (Ping timeout: 268 seconds)
07:09:35anamokDmitry @data-man: thanks
07:09:46*krux02 joined #nim
07:43:25*stefanos82 joined #nim
07:57:38*stefanos82 quit (Remote host closed the connection)
08:18:07FromGitter<m4d3bug> what is ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c0a2cbf8d4f3a2a7c8387cc]
08:22:59FromGitter<narimiran> @m4d3bug show us your code
08:24:53FromDiscord_<Virepri> is there something akin to a nim tour? I've found it super easy to learn D and golang because of them
08:26:42FromGitter<narimiran> @Virepi: maybe this will do? https://nim-by-example.github.io/getting_started/
08:27:35FromGitter<narimiran> @Virepri ^
08:29:00FromGitter<alehander42> I think @PMunch was working on Nim tour
08:32:36FromGitter<m4d3bug> `````` [https://gitter.im/nim-lang/Nim?at=5c0a30245e409525032ac17b]
08:32:52FromGitter<m4d3bug> @narimiran
08:32:55anamokbye
08:32:58*anamok quit (Remote host closed the connection)
08:34:18FromGitter<narimiran> "Nim to Rust is on the roadmap." https://news.ycombinator.com/item?id=18622233
08:34:18FromGitter<m4d3bug> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c0a308a1e86c308233ce985]
08:34:26FromGitter<narimiran> anybody knows more about it?
08:35:32FromGitter<narimiran> @m4d3bug `array[string,string]` is the problem. the first parameter must be ordinal, e.g. integer
08:36:10FromGitter<narimiran> @m4d3bug maybe you're looking for `strtabs` module?
08:37:36FromGitter<m4d3bug> great
08:39:44FromGitter<alehander42> is today's aoc interesting
08:40:54FromGitter<m4d3bug> but how to use varargs and newStringTable together? @narimiran
08:41:21FromGitter<narimiran> @alehander42 it is (i haven't solved part2 yet, i need to re-do my part1 first)
08:44:07FromGitter<narimiran> @m4d3bug looking at your input, can't you just pass to function `varargs[string]`?
08:44:51livcdnarimiran: early 1st of April ? :D
08:45:18FromDiscord_<Virepri> @narimiran This is actually what I'm currently running off. It gets the job done but I liked the tours because they were very interactive in nature. Idk, maybe I'll build one at some point.
08:45:25FromGitter<m4d3bug> I can't,it is difference parameter
08:47:28FromGitter<m4d3bug> I want to treat them differently in next step
08:48:07FromGitter<m4d3bug> But they are always passed in pairs unknownly
08:48:55livcdNim chooses unreadable symbols %* and $$ over clear names like dumps or loads :( <- yeah I also do not like weird symbols and sigils
08:55:27*Vladar joined #nim
08:58:36*floppydh joined #nim
09:16:54FromGitter<alehander42> this is cool https://github.com/mattaylor/elvis
09:18:24FromDiscord_<technicallyagd> And there I was, writing `toBool` converters
09:18:34FromDiscord_<technicallyagd> This is indeed nice
09:18:59FromGitter<mratsim> toBool converters are the door to C madness `if 0`
09:20:06FromDiscord_<technicallyagd> I know it's dangerous! it's just for AoC
09:39:09FromGitter<alehander42> converters are useful sometimes, toBool sounds dangerous tho
09:40:43*PMunch joined #nim
10:00:18Araqthere are no "sigils", there are unary operators
10:01:06Araqit's fine to not know all this programming jargon, but don't use words you don't understand :P
10:11:52FromGitter<xmonader> Guys I did a quick update on `nim doc` and added it to the good parts with a note on threadpool:on required flag -_-
10:12:45PMunchnarimiran, how did you meassure the time of your day5 aoc run?
10:18:12FromGitter<alehander42> are there any other flow-breaking constructs
10:18:17FromGitter<alehander42> except return, break, continue
10:19:06PMunchquit?
10:19:15PMunchTechnically flow breaking :P
10:19:25PMunchraise can be counted as well I guess
10:20:07PMunchnarimiran[m], optimized my day 5 a bit http://ix.io/1vr3/Nim
10:25:02*dom96_w joined #nim
10:25:25FromGitter<alehander42> eh I hope quit is compiled to something like ugh
10:25:27FromGitter<alehander42> no idea
10:25:33FromGitter<alehander42> probably there is a magic about that
10:25:53FromGitter<alehander42> because there was somethinmg like "dead code after .."
10:26:42PMunchWell I think there is a callback you can set that will always run on quit
10:27:01FromGitter<narimiran> PMunch: i run it 100 times and then divide the measured time by 100 :)
10:27:50FromGitter<alehander42> yeah its nkRaiseStmt too
10:27:59FromGitter<alehander42> in semstmts
10:28:12FromGitter<alehander42> @PMunch yep, no, I was trying to analyze code
10:28:18FromGitter<alehander42> but yeah addQuitProc is cool
10:28:29FromGitter<alehander42> btw I remember yglukhov wanted one for compile time
10:28:42FromGitter<alehander42> (after all the macros are invoked)
10:29:22FromGitter<yglukhov> yes, that would be cool. But I'm not sure about the exact semantics.
10:29:44FromGitter<narimiran> PMunch: i've tried running your code and i get index error
10:29:59FromGitter<yglukhov> What would also be cool is to allow a definition to grow while macros are invoked.
10:30:05FromGitter<mratsim> the only weird thing about addQuitProc is that you need to tag {.noconv.}
10:31:04*Snircle joined #nim
10:31:09FromGitter<narimiran> PMunch here's my input, try it yourself: http://ix.io/1vr5
10:31:20PMunchnarimiran[m], 0.85ms on average over 100 runs. Not bad. That's only for part1 though
10:31:44FromGitter<alehander42> @yglukhov yeah, so you want to have access to a non-invocation code location in a macro
10:32:23FromGitter<alehander42> i wanted that for defining types based on macro invocations too
10:32:40FromGitter<alehander42> but it might be excessive
10:32:41PMunchnarimiran[m], works fine for me. But takes 2.47ms for some reason
10:32:47PMunchWhat's your answer for that one?
10:33:19FromGitter<narimiran> 10132
10:33:30PMunchYeah okay, so it's doing the right thing
10:34:16FromGitter<alehander42> can I add a magic to a method ?
10:34:30FromGitter<narimiran> PMunch: now, why your code raises an error on my computer and works on yours?
10:34:32FromGitter<yglukhov> @alehander42 I wanted that for registries, and constants and strings so that a registry would not require runtime initialization. But types, and even function bodies would be cool too.
10:34:40FromGitter<alehander42> oh yeah i can , thats gonna be coo
10:35:08PMunchnarimiran, Nim version?
10:35:20PMunchAnd what is the error specifically?
10:35:37FromGitter<narimiran> Nim Compiler Version 0.19.9 [Linux: amd64]; Compiled at 2018-11-30
10:35:50FromGitter<narimiran> Error: unhandled exception: index out of bounds [IndexError]
10:36:00FromGitter<narimiran> line 13
10:36:05PMunchHuh, mine is slightly newer, but that shouldn't matter..
10:36:28PMunchWait, line 13?
10:36:44FromGitter<narimiran> yes, line 13. happens on stable too. now i'm updating my devel
10:37:11PMunchHuh, so it seems to jump out of the sequence
10:38:11PMunchThe way it works is that whenever it deletes something it leaves a pointer for how many bytes to skip
10:38:27PMunchThat code is responsible for jumping back through the polymer and finding the first non-deleted thing
10:40:31FromGitter<narimiran> same error on the latest devel
10:42:41FromGitter<alehander42> huh isnt it about steps
10:42:44FromGitter<alehander42> this time
10:44:37PMunchSlight further optimization and now does 100 runs: http://ix.io/1vr6/Nim
10:46:24PMunchalehander42, yes this is still day5 :P
10:47:18PMunchnarimiran, you can try to manually type in a polymer and see if that also fails
10:47:22PMunchA bit easier to debug
10:52:44federico3https://lobste.rs/s/yocd3p/nim_good_ok_hard any reply to this?
10:55:23FromGitter<mratsim> https://www.youtube.com/watch?v=dcUAIpZrwog ? (just joking :P)
10:55:47FromGitter<mratsim> “How do lobsters grow"
11:14:49Araqhttps://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf must read for every programmer
11:19:10ZevvWhere do I find documentation about {.multisync.}?
11:20:22Araqasyncmacro.multisync
11:20:56FromGitter<alehander42> oh finally part 1 done
11:45:15*dom96_w quit (Changing host)
11:45:15*dom96_w joined #nim
11:45:27dom96_wwow, amazed by the negativity around Rust's new website: https://old.reddit.com/r/programming/comments/a3q3e2/rust_131_and_rust_2018/eb92xqh/
11:49:02dom96_wAraq: where is 0.19.2? I generated release notes for it weeks ago
11:54:58*theelous3_ joined #nim
12:07:34livcddom96_w: it reminds me of RoR sites from the old RoR days
12:08:27*platoff joined #nim
12:22:55*theelous3_ quit (Ping timeout: 246 seconds)
12:27:38*dddddd joined #nim
12:29:18*elb_ joined #nim
12:32:15FromGitter<narimiran> idiomatic way of checking if all elements of a container A are in a container B?
12:38:30FromGitter<alehander42> a.allIt(it in b) ⏎ (set(a) - set(b)).card == 0 ⏎ ?
12:39:16FromGitter<alehander42> toSet(a) - toSet(b) *
12:39:39FromGitter<narimiran> ok, my idea was to use all(it)
12:40:15FromGitter<alehander42> probably makes sense to at least toSet b
12:40:21FromGitter<alehander42> if there are many many iterations
12:44:11M379229[m]a.toSet <= b.toSet
12:44:11M379229[m]?
12:45:52FromGitter<narimiran> ok, i'll see what will work best for my case. thanks, guys
12:46:13FromGitter<alehander42> b.toSet.incl(a.toSet) indeed , thank you @M37..
12:46:18FromGitter<alehander42> complicated name.
12:49:00M379229[m]AoC name :)
12:52:39*M379229[m] left #nim ("User left")
12:53:15*stefanos82 joined #nim
12:53:42*M37[m] joined #nim
12:54:47M37[m]Fixed.
12:56:38FromGitter<alehander42> hahaha nice
12:56:39FromGitter<alehander42> sorry
13:00:50M37[m]Nah, you're right. This is better. It's like having a haircut.
13:02:10FromGitter<alehander42> Araq: in `new(stuff)`
13:02:16FromGitter<alehander42> why doesnt it have
13:02:52FromGitter<alehander42> oh I wrote new(Type) pff, the magic mNew is there normally otherwise
13:05:58FromGitter<zacharycarter> @xmonader - FYI - the linking problem is specific to linux
13:06:07FromGitter<zacharycarter> liking dylibs on macOS is simple
13:06:13FromGitter<zacharycarter> and on windows as well
13:13:50*nsf quit (Quit: WeeChat 2.3)
13:25:16*Vladar quit (Remote host closed the connection)
13:37:56*platoff quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:48:46*zahary joined #nim
13:51:46endragorIs it intended that you can no longer import modules in a `static` block? It was allowed before 0.19 and now it errors out with "'import' is only allowed at top level". Importing in static context was a valid use case, I think
13:55:05*PMunch quit (Remote host closed the connection)
13:55:23*PMunch joined #nim
13:56:37PMunchendragor, yeah I was wondering about that myself the other day
13:57:40*vegax87 quit (Ping timeout: 252 seconds)
13:57:52*platoff joined #nim
14:02:16*endragor quit (Remote host closed the connection)
14:22:24*vegax87 joined #nim
14:26:40*vlad1777d joined #nim
14:31:26*floppydh quit (Quit: WeeChat 2.3)
14:42:35*endragor joined #nim
14:47:00*endragor quit (Ping timeout: 246 seconds)
14:52:42*kungtotte quit (Ping timeout: 252 seconds)
14:54:56*vlad1777d quit (Ping timeout: 268 seconds)
14:59:45*platoff quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:04:26*kungtotte joined #nim
15:15:11*PrimHelios joined #nim
15:15:47Araqit is intended, there are no 'static' imports, an import is always a compiletime statement to begin with
15:17:39PMunchYeah but importing in a static block would hide those identifiers from the rest of the scope
15:17:51FromGitter<arnetheduck> for documenting fields and having the tool pick it up, there's the after-the-field style ⏎ ⏎ ```type Object = ⏎ field: int ## here``` ⏎ ⏎ it's a bit constrained space-wise and promotes useless field docs that repeat the field name and not much else - @timotheecour have you been thinking of anything for this? I think there's some alternate style as well doing `##\` which is kind of ugly..
15:17:51FromGitter... [https://gitter.im/nim-lang/Nim?at=5c0a8f1ff4880a60a240232d]
15:18:07PMunchWhich meant you could avoid e.g. identifier collision between compile-time and runtime code
15:18:39Araqthat was never done.
15:18:40FromGitter<arnetheduck> I know you can simply just put the docs whereever you like, but I'm looking for something that has a chance of being picked up by smart tools etc
15:19:01Araqwhat previously happened was that 'static' didn't even open a new scope
15:19:44Araqin the compiler there is one "<imported symbols here>" scope. Not two, not three and they don't nest
15:20:28Araqarnetheduck, field: type ## \
15:20:31Araq## long comment here
15:20:38Araqis what should be used
15:20:56Araqor the new'ish long doc comments
15:21:03Araqfield: type ##[ stuff
15:21:06Araq more
15:21:10Araq]##
15:22:27FromGitter<arnetheduck> @Araq yeah, I've tried using that on occasion but it's kind of hard to remember and ugly.. also, it's a bit strange that it's about the only place where `\` is needed.. any reason why for example `##` on the line following the field isn't used? that seems consistent with other docs
15:23:05FromGitter<arnetheduck> alternatively, `##` indented on the next line would "feel" nim-ish too
15:23:47Araqtrue and maybe we can make the parser accept it
15:24:06Araqin a perfect world somebody cleans up the doc comment mess
15:24:28Araqwould also save 8 bytes per PNode
15:24:45FromGitter<arnetheduck> how so?
15:25:18Araqcurrently it has a 'comment: string' field, that's not required if "doc comments can only occur in certain places in the AST"
15:25:52FromGitter<arnetheduck> ie you'd stick it in `sons`?
15:26:05Araqyup
15:26:56Araqthere are only ~3 node kinds where it occur really, nkIdentDefs, nkEnumField or free standing in an nkStmtList
15:27:16FromGitter<arnetheduck> yeah, that sounds kind of reasonable.. though truth to tell, `sons` is a bit unwieldy to work with at times, hard to remember which node has what information at what index
15:27:31Araqand we already have the "optional stuff is nkEmpty" paradigm
15:28:00Araqit's unwiedly, yes, but it is consistent and easier to handle than
15:28:20Araq"there is nkIdentsTypeValue, nkIdentsValue, nkIdentsType..."
15:30:02*ng0 joined #nim
15:31:15FromGitter<alehander42> yeah, honestly once I wrote a toy compiler with custom fields for each kind and it was very annoying https://github.com/alehander42/roswell/blob/master/ast.nim#L9
15:31:27FromGitter<alehander42> but partly because of the lack of shared fields
15:32:14FromGitter<alehander42> since then I use `children` usually
15:35:32FromGitter<arnetheduck> well, other ast's I've seen tend to use some sort of hierarchy to make that more manageable... I wonder if it would help to have constructors for each node type or something, or maybe sons it behind accessors that would consistently get used throughout the compiler
15:35:52FromGitter<alehander42> but in a patty-like variant macro I'd include both: ⏎ e.g. ⏎ ⏎ ```code paste, see link``` ⏎ ... [https://gitter.im/nim-lang/Nim?at=5c0a935811bb5b25047a7c9c]
15:36:36FromGitter<arnetheduck> I think for nkFuncDef there's a bunch of constants defined (namepos or whatever)
15:36:44FromGitter<alehander42> so the macro will create `init` constructors for each kind and `[]` will work for kinds where the "special" fields are all the same `T`
15:39:10FromGitter<alehander42> basically, its very useful to have the ability to iterate through/index all the "children", and it's nice to have property names for some of them, so automating this in the definitions seems best
15:39:39*krux02 quit (Remote host closed the connection)
15:40:38Araqarnetheduck: yeah, the lack of accessors is biting us, but I'll introduce them soon'ish
15:41:32Araqbecause then I can also play more easily with alternative AST representations in memory, as I keep saying, I want to try an approach inspired by my packedjson project
15:42:12*narimiran joined #nim
15:45:31dom96_wAraq: 0.19.2? What's the status?
15:47:39FromGitter<arnetheduck> neat
16:02:17*Vladar joined #nim
16:03:29*platoff joined #nim
16:13:34*Trustable joined #nim
16:21:31*snowolf quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
16:25:02*PMunch quit (Remote host closed the connection)
16:28:35*Tyresc joined #nim
16:30:23*snowolf joined #nim
16:46:00*rockcavera quit (Remote host closed the connection)
16:50:01*rockcavera joined #nim
17:06:06*hzx joined #nim
17:07:21hzxHey! Is there anything in the osproc that is similar to win32 api ShellExecute?
17:17:47shashlickHow about poEvalCommand
17:21:34PrimHelioswhat does prepending "$" to a variable name do?
17:21:45narimiranPrimHelios: converts it to a string
17:23:17PrimHeliosis there a reason that cmp($someString, "a string") returns non-zero (assuming someString="a string") then?
17:24:10hzxI have no command. I just want to pass the filename to the OS and have it start the associated program. Like ShellExecute with the "open" parameter.
17:27:35PrimHelioshzx: couldn't you use "cmd /C start <filename>"?
17:28:31narimiranPrimHelios: show us a short snippet of your code
17:29:04hzxthanks, it seems to work
17:30:58PrimHeliosnarimiran: huh, weird, it's working now. might've been because i was originally grabbing the string from JSON?
17:31:47narimiranit's hard for me to tell
17:34:37PrimHeliosyeah i understand, trying to find the original code
17:37:04*Nandraj left #nim (#nim)
17:37:40PrimHeliosthis was the original code iirc https://hastebin.com/mebotorufo.md
17:40:42*kungtotte quit (Quit: leaving)
17:43:53*Vladar quit (Remote host closed the connection)
17:45:40FromGitter<alehander42> Araq: if A is ref not nil and B is ref not nil and ⏎ a has a B field and b has a (child<=>parent) ⏎ ⏎ how are we supposed to init them? ⏎ a = A(b: B(a: cant pass a)) [https://gitter.im/nim-lang/Nim?at=5c0ab1c411bb5b25047b4f8a]
17:45:53FromGitter<alehander42> a = A(b: B()) ⏎ a.b = B(a: a) ?
17:46:41FromGitter<alehander42> a = A(b: B(a: A())); a.b.a = a # fixed
17:47:17FromGitter<cabhishek> Hi - Is anyone having trouble comping Nim from devel? Step `sh build_all.sh` fails with error `lib/system.nim(2195, 46) Error: type expected`. Any ideas?
17:47:59FromGitter<alehander42> hm that would be impossible
17:48:10FromGitter<alehander42> the init thing, nvm me @cabhishek
17:48:55*platoff quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:50:33FromGitter<alehander42> hmm I have to just `var a: A` `var b: B` because of the warning escape hatch
17:57:15*nsf joined #nim
18:06:21stefanos82@cabhishek: I fetched the latest updates yesterday and compiled it just fine.
18:15:16FromGitter<cabhishek> @ stefanos82 Ok thanks. Lets take a closer look then :/
18:15:31stefanos82sure thing
18:18:26*dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:23:27stefanos82@cabhishek: try to re-fetch everything from repo under a newly created directory and try to build it again with "sh build_all.sh"
18:34:39FromGitter<citycide> PrimHelios: with JSON you have to use `getStr` and friends to extract the value, otherwise you get a JsonNode
18:34:52FromGitter<citycide> https://nim-lang.org/docs/json.html#dynamically-retrieving-fields-from-json
18:34:59FromGitter<cabhishek> @ stefanos82 yes, sure thing
18:38:51PrimHelioscitycide: Really? It works just fine without getStr /shrug
18:45:05FromGitter<alehander42> why doesnt the A = ref object not nil ⏎ stuff
18:45:12FromGitter<alehander42> syntax actually works o.O
18:45:25FromGitter<alehander42> work*
18:50:27*theelous3_ joined #nim
18:51:44*hzx quit (Quit: Going offline, see ya! (www.adiirc.com))
18:52:17stefanos82thanks to @alehander_42 that reminded me how badly I need to fully understand how Nim works, I share here my future book wish list for Nim: Effective Nim, Nim in Depth, Nim Internals, Microservices in Nim, Compiler Design in Nim, Virtual Machines in Nim, Mastering Nim, Machine Learning and Deep Learning using Nim
18:52:23stefanos82the list could go on and on!
18:52:35narimiranno Fluent Nim?
18:52:49stefanos82*definitely*!
18:52:56narimiran(Fluent Python is one of the best Python books you can read)
18:53:02stefanos82I have read it
18:53:09stefanos82and I planned to read it again
18:53:12stefanos82...and again
18:53:20stefanos82I simply loved it
18:53:30narimiranwell worth it, it is great
18:53:34stefanos82true true
18:54:00stefanos82Design Patterns in Nim
18:54:05stefanos82even the title is sexy lol
18:54:28stefanos82Algorithms in Nim
18:54:34narimiranok, we have titles, now: who is gonna write them?
18:55:02stefanos82the future generation lol
18:55:51FromGitter<zacharycarter> Effective Nim - `Don't write microservices`
18:55:56FromGitter<zacharycarter> done
18:56:06FromGitter<zacharycarter> Microservices in Nim - ``
18:56:08FromGitter<zacharycarter> done
18:56:37stefanos82someone "loves" microservices with a passion :D
18:57:24FromGitter<zacharycarter> microservices are cool until you work with microservices
18:57:27FromGitter<zacharycarter> then they're not so cool
18:58:38stefanos82so, some hate using monolithic apps, others hate microservices, others getting goosebumps and throw desks and chairs just for hearing the word "docker"
18:58:41stefanos82what else?
18:59:15FromGitter<zacharycarter> its not that I hate microservices - I just don't think they make anything simpler
18:59:30FromGitter<zacharycarter> and a well-designed monolith is much better than a bunch of poorly-designed microservices
19:00:07stefanos82don't get me wrong, I'm a monolithic supporter myself :D
19:00:07FromGitter<zacharycarter> and it's easy to end up with a horrible microservice architecture
19:00:27stefanos82yeah, I have read some horror stories from HN comments :S
19:00:36stefanos82always it's the management that mess things up
19:00:59FromGitter<zacharycarter> I think there are enough books about how to do random buzzword topic in language A
19:01:31FromGitter<zacharycarter> plus Nim is very close to C in terms of style - so if you can read C/C++ it's quite easy to figure out how to do something with Nim, just using Nim's ecosystem instead (if support for a topic exists)
19:01:34FromGitter<xmonader> @zacharycarter Well, Linux is a firstclass OS for developers (actually dynamic linking is still the way to go for most of the linux distros)
19:02:09FromGitter<zacharycarter> @xmonader - I know - just pointing out that it's only a linux issue
19:02:25FromGitter<zacharycarter> or an issue on linux
19:02:29FromGitter<zacharycarter> is probably a better way to word that
19:03:25FromGitter<zacharycarter> rather than books - I think we need more libraries to support all of those subjects
19:03:30FromGitter<xmonader> Nim has many unique points and different views on things (definitely seeing compiler design with nim patterns and facilities is something I want to read about) testing and mocking is totally different when it comes to Nim, Effective Nim or Concurrency patterns book is also very much appreciated too
19:03:56FromGitter<zacharycarter> well - you can read about concurrency patterns without reading about Nim
19:04:02FromGitter<zacharycarter> and all of that info still applies
19:04:11FromGitter<zacharycarter> you just have to understand Nim's memory management
19:04:30FromGitter<zacharycarter> nim's concurrency = async or parallelism via threads
19:04:45FromGitter<zacharycarter> and each thread has it's own local heap
19:05:21FromGitter<zacharycarter> there is also a shared heap that can be accessed by all threads - but you need to still be aware of synchronization
19:05:47FromGitter<zacharycarter> so there are locks and conds
19:06:00FromGitter<zacharycarter> and support for atomics
19:06:03FromGitter<xmonader> @zacharycarter did you check the pain points in the last article? I don't want to see ptrs, casting and such while using channels or at least provide us with good reasons to wrap our heads about how to think about it
19:06:15FromGitter<zacharycarter> there are also channels for passing data between threads
19:06:16stefanos82still though I believe the aforementioned list is necessary, if nothing else as an advertisement for the language itself *and* a confirmation that it's not just a new language, but a very well-designed one that can do some serious and professional job as well
19:06:50FromGitter<zacharycarter> you don't need to use pointers with channels
19:06:52FromGitter<xmonader> I used lots of concurrency with Go and goroutines and sync package, it's at least 5x easier (primitives wise) and highly documented
19:06:57FromGitter<zacharycarter> unless you want to avoid the boxing / unboxing
19:07:27FromGitter<zacharycarter> so use async then - don't use threads
19:07:34FromGitter<rayman22201> @xmonader I enjoyed your article. Thank you for writing it. It does seem like a lot of your concerns are related to ecosystem immaturity and providing higher level abstractions?
19:08:04FromGitter<rayman22201> My real question is, if you were to start over from scratch, would you choose Nim again?
19:08:11FromGitter<mratsim> seems fun: https://repl.it/site/blog/multi
19:08:51FromGitter<rayman22201> @mratsim seems good for job interviews? lol
19:09:07FromGitter<zacharycarter> or use async + threads
19:09:35FromGitter<mratsim> Dunno, never did live coding/whiteboard coding for job interviews :P
19:10:04FromGitter<rayman22201> You are lucky. It's terrible. I have been on both sides of whiteboard interviews.
19:10:51FromGitter<xmonader> @zacharycarter channels aren't supposed to be used with spawn and in threads u should pass references (imagine the cluttering in ur head i'm taking reference here and casting there to achieve very minimum) I can live with that IF i know the reasons why, but currently nim assumes you really knows the whole thing inside out to use it
19:11:35FromGitter<xmonader> and what is worse is there's no good starting point or good docs on that
19:12:53FromGitter<zacharycarter> well - my point is - these aren't Nim specific things
19:13:02FromGitter<zacharycarter> or concepts
19:13:23FromGitter<zacharycarter> and there are good starting points and docs - but they're not using Nim as the programming language
19:13:49FromGitter<xmonader> @rayman22201 Thanks, I hope it helps Nim to move forward! ⏎ ⏎ During the development of this very simple app (that took lots of effort) I had doubts from my colleagues like (we really went that far `writing redis client`)? should we drop the whole thing .. our customers want just one binary file they don't want to mess with setup or installing libraries or else... which is also painful
19:13:54FromGitter<zacharycarter> also - you only use spawn with Nim's threadpool, which isn't required for threads
19:15:55FromGitter<xmonader> so my answer to your question is if the static linking is non negotiable I won't be using nim, if the time isn't a factor, i'd rather to give nim another shot, because I really like nim
19:16:02FromGitter<mratsim> @rayman22201 it’s because I wasn’t a dev.
19:16:08stefanos82@xnomader: that's why I prefer Go for concurrency when I have to deal with heavy network stuff
19:17:47FromGitter<xmonader> @zacharycarter I know the concepts too, but I can't do it in some language without bridging that gap, for example from my knowledge in other language primitives i was using spawn with channels, but in the nim way that wasn't correct because channels aren't meant to be used with spawn
19:18:31FromGitter<xmonader> If these things aren't pointed at, explained "heavily" provided with examples. then every one will keep suffering or go to annoy Araq
19:19:09FromGitter<xmonader> If I've to ask then it means the documentation is vague or isn't there, and concurrency is a major selling point for any language
19:20:15narimiran2019 is the year of nim documentation!
19:20:26FromGitter<xmonader> another point `dependency free binary` stated in the nim website, how to achieve that? this exact sentence was one of the reasons I choosed nim for my application and had to do tons of experimentations and tons of questions to the nice people here, and i didn't manage to deliver it.
19:20:42stefanos82not only that @xmonader, there are certain flags that have no documentation with thorough explanation
19:20:48FromGitter<rayman22201> In some ways I feel like Golang spoiled people on both concurrency and dep free dependencies :-P
19:21:05*nsf quit (Quit: WeeChat 2.3)
19:21:11stefanos82that was their objective
19:21:25FromGitter<rayman22201> @narimiran woot +1 to year of nim docs next year!
19:22:05stefanos82basically they had a valid argument: they logged a C++ library that had nothing to do with the binary they were compiling and it was called 35K times
19:22:11FromGitter<zacharycarter> @xmonader - golang goroutines and channels are higher-level abstractions
19:22:14FromGitter<xmonader> @stefanos82 i'm sure they're all useful flags, but I think we should settle on those that matters to `enduser` developers who just want easy to use and to manage
19:22:15narimiranno, seriously, i plan to work on it. but any help from the community is more than welcome
19:22:19FromGitter<zacharycarter> you can implement them in Nim if you want to
19:22:58stefanos82@xmonader: it's from an end-user's point of view that I commented on the flags issue
19:22:59FromGitter<zacharycarter> the reason people pass pointers between channels is to avoid the deepCopying that has to happen otherwise
19:23:50FromGitter<xmonader> @rayman22201 go lang is simple primitive language but sold all of the points correctly, concurrency and static linking? everyone wants that. I wish nim could deliver that easily [it's more expressive and pleasant to work with]
19:24:26FromGitter<zacharycarter> also - unless you need Nim's RT gc
19:24:29FromGitter<zacharycarter> you can use golang's GC
19:24:38FromGitter<zacharycarter> nim does have static inking
19:24:41FromGitter<zacharycarter> linking
19:24:51FromGitter<zacharycarter> I think most of your issues are that you don't understand how to do these things with Nim
19:25:08FromGitter<xmonader> @zacharycarter that's exactly my point, these notes, these points should be written down
19:25:25FromGitter<zacharycarter> well - my point is - if you learn how to do these things with C/C++
19:25:26stefanos82I feel you @xmonader
19:25:32FromGitter<zacharycarter> then you won't have a problem doing them with Nim
19:25:33FromGitter<alehander42> I guess that for people that like channels, maybe some kind of a safer/saner API can be done on top of the existing stuff for concurrency
19:25:43FromGitter<zacharycarter> you're coming from a higher level of understanding
19:25:45FromGitter<xmonader> I spend 2 days getting static linking with pcre, and ssl and i managed to do that. that's not like `go build` and voila
19:25:46FromGitter<zacharycarter> that's your issue
19:25:54stefanos82@zacharycarter: the reason people want to use Nim is because they don't want to deal with or touch C or C++
19:26:03narimiranno, that's nim issue too
19:26:31FromGitter<zacharycarter> you can look at things the opposite way too
19:26:32narimirani don't want to have "oh, you want to do XY in Nim? well, go read C/C++ documentation about it"
19:26:36FromGitter<xmonader> I don't want to touch C++ code nor understand it. I hate the language. If i'm going to an older language i'd just pick pascal
19:26:54FromGitter<zacharycarter> there are probably lot of annoying workarounds you have to do in Go that you can do in Nim - regarding unsafe / lower level features
19:26:57FromGitter<xmonader> @narimiran I'd love to help you out with documentation when everI've time
19:27:11FromGitter<zacharycarter> my point is - you're learning Nim from a higher level of understanding vs a lower level one
19:27:24FromGitter<zacharycarter> I faced many of the same problems you did when learning Nim - I still do
19:27:38FromGitter<zacharycarter> but I figure out the answers by looking at how things are done in C/C++
19:27:44FromGitter<rayman22201> Doc search is still a project I want to work on. I'm very much on board with getting docs in Nim better in all respects.
19:28:32FromGitter<xmonader> @zacharycarter maybe you can help us getting a decent `nim concurrency 101`
19:28:33FromGitter<zacharycarter> narimiran: well you can't expect Nim's docs to explain how to achieve higher level abstractions in Nim
19:28:41narimiransomebody already mentioned solving problems by asking here on IRC. but that solves a problem for that one person. if that was in the documentation, everybody would benefit
19:29:09FromGitter<xmonader> I don't want deep internals I want to fire things and communicate and orchestrate that flow. I want the language to help me with that [not just me]
19:30:34FromGitter<rayman22201> Go solved the static binary problem by just including everything and the kitchen sink with every binary and baking that into their build system. It worked for them, and it's an interesting trade-off, but Nim made different decisions there. (That being said, making a "fat binary" build mode easy to do is maybe something worth maintaining)
19:31:28FromGitter<rayman22201> it's a hard thing to maintain with a small team though
19:31:52FromGitter<rayman22201> Go brute forced it by being a simple language and throwing a lot of money at the problem lol
19:32:11FromGitter<zacharycarter> @xmonader - I'd start by reading something like https://slikts.github.io/concurrency-glossary/
19:34:49FromGitter<zacharycarter> again - you don't have to use pointers with channels
19:34:58FromGitter<zacharycarter> you don't have to use Nim's threadpol module with threads
19:35:18FromGitter<zacharycarter> you don't even have to use channels - but unless you understand the underlying concepts - I don't think you're going to have much success with any of it
19:35:34FromGitter<zacharycarter> at least that's what I've found personally
19:35:38FromGitter<rayman22201> Threadpool always has been half baked. Araq has said so himself. It tried to be too clever and the kinks were never fully worked out.
19:36:04FromGitter<rayman22201> threadpool + spawn
19:36:40FromGitter<xmonader> I'm familiar with the most of that, but you're still not seeing my problems, why the languages are spending efforts on that? compare to crystal for instance almost same age as nim and they focused on channels and spawn it it works beautifully
19:37:08FromGitter<rayman22201> Nim focused on different things
19:37:42FromGitter<rayman22201> the Crystal community is also bigger than Nim (sadly)
19:37:47FromGitter<xmonader> these higher level primitives should work out of the box just fine, yeah you should always provide the low level primitives but don't expect ppl to be using or know how to use that without loads of questions in case of insufficient docs
19:38:32stefanos82we need more test cases around cons and pros of Nim
19:39:03FromGitter<xmonader> @rayman22201 and I appreciate that really, but to make people adapt your language you should sell it to them giving them what they need unless u want it to be a research language
19:39:20FromGitter<zacharycarter> http://web.mit.edu/6.005/www/fa15/classes/19-concurrency/
19:39:22FromGitter<zacharycarter> is another good resource
19:39:49FromGitter<alehander42> @xmonader their concurrency might be nice, but there are many things crystal cant do well at all in which Nim is better
19:39:50FromGitter<zacharycarter> well - the community can also build and provider higher level abstractions
19:40:08FromGitter<alehander42> my point is: there are 20 of "areas" where Nim tries to improve
19:40:11FromGitter<zacharycarter> agreed - Nim can do things that Go and Crystal can not
19:40:17FromGitter<rayman22201> I have to agree with you though @xmonader. Nim has historically had a problem of too many cool features that get to the proof of concept phase but never get the proper testing to be a usable feature by end users. I think this is getting better recently though, with the push to Nim 1.0 and more money behind Nim.
19:41:16FromGitter<alehander42> and sometimes some of those areas might seem less developed, it's inevitable, but this doesn't mean less effort is spent overally for improving the language
19:42:14FromGitter<alehander42> e.g. concurrency: we have async/await, we have channels(?), there are even actor libs: for 1.0 we can hope that one of those works great
19:42:56FromGitter<zacharycarter> channels and threads work fine now tbh
19:43:22FromGitter<zacharycarter> I'm not really sure what the complaint there is - other than the performance hit for the deepCopy - which you can work around at the cost of more complexity
19:43:26*kungtotte joined #nim
19:43:29FromGitter<alehander42> I guess so
19:43:37FromGitter<alehander42> but no, I agree that probably a nicer lib/api might make them a bit easier for users
19:44:41*enthus1ast quit (Ping timeout: 268 seconds)
19:44:50FromGitter<rayman22201> @zacharycarter I think you might be having trouble seeing the forest through the trees here. I think his issue was ease of use / lack of clear documentation. Channels / threads were just an example.
19:45:00FromGitter<alehander42> however I wouldn't blame Nim pre-1.0 on not focusing on channels, if it already focused on async/await: it would be the same as asking elixir or go: "why dont you have nice async/awaitlike libs"
19:45:34FromGitter<alehander42> if people manage to improve/document it even more or build a cool lib on top of it, that would be great
19:46:04FromGitter<xmonader> @zacharycarter the example i got in the post (was based on a search in the forums) not the documentation itself and after asking couple of times here and finally was answered by Araq
19:46:15FromGitter<zacharycarter> @rayman22201 - I'm hearing that but I think the docs on threads and channels are sufficient tbh - there are clear examples and the docs explain that channels are to be used with threads
19:46:35FromGitter<rayman22201> @alehander42 Also very true. It's awesome that Nim can support both (very different) forms of concurrency models. This already makes Nim more powerful than those languages, but as a community, we kind of chose async as the model we like better.
19:46:38FromGitter<xmonader> well, then why was I mislead to use spawn with channels? @zacharycarter
19:46:58FromGitter<zacharycarter> I'm not sure who instructed you to do that / where you read that
19:47:18FromGitter<xmonader> @alehander42 I'd love to see that, i'd love to see people writing more about their daily use of nim and how they fix certain problems they face
19:47:51FromGitter<xmonader> @zacharycarter it was because that's the obvious `choice` same model in countless languages crystal go .. etc
19:47:52FromGitter<zacharycarter> I don't disagree that the docs could use improvement - it's just we need working language / stabilized language features first
19:48:15FromGitter<rayman22201> Y not both? lol
19:48:22narimiranno need to wait with documentation for language to stabilize, IMO
19:48:25FromGitter<zacharycarter> it's hard to do both at the same time
19:48:28FromGitter<zacharycarter> with a moving target
19:48:32FromGitter<zacharycarter> and things in flux
19:48:52FromGitter<zacharycarter> you write docs today - they're out of date tomorrow and then need updating - I'm not say you can't have both
19:49:01FromGitter<zacharycarter> but if you're conflating goroutines with Nim's concurrency primitives
19:49:14FromGitter<zacharycarter> then what you're asking for is Nim to go out of the say to explain the difference between them
19:49:17FromGitter<alehander42> @xmonader me too, but my point was again: the most popular model in nim seems to be async: it's not so surprising that there is not so much info about channels. it's a bit like you going to the crystal channel and saying "why no actor libs"?
19:49:28FromGitter<zacharycarter> and that's asking a lot for a language that hasn't reached maturity yet
19:49:35*zakora joined #nim
19:49:59FromGitter<zacharycarter> and my point still stands - you could go learn about these concepts outside of a nim context
19:50:09FromGitter<zacharycarter> and then you'd have a better understanding of Nim's concurrency model
19:50:14FromGitter<alehander42> so the comparison with "this is the same model in many langs" is not too fair, as it's the main model in those langs
19:50:15FromGitter<xmonader> @alehander42 I didn't know async await was the way to go (they just fixed catching exceptions in it lately correct) ?
19:50:53FromGitter<alehander42> @xmonader I am not sure if it's the way to go, channels *with improved docs* might be equally great, but they seem way more used
19:51:12FromGitter<alehander42> and I think the core team focused a bit more on async (e.g. @dom96 )
19:51:47FromGitter<rayman22201> Yeah, the core team has been all in on async for a while. That hasn't necessarily been well communicated to the rest of the world though.
19:52:03*Vladar joined #nim
19:52:05FromGitter<alehander42> yes, I think the status guys also fix a lot of stuff related to async, not sure if its upstream tho
19:52:11FromGitter<rayman22201> I wouldn't know it if I didn't hang out on gitter all the time.
19:52:23FromGitter<alehander42> but they use it a lot ( @mratsim ? ^)
19:52:42narimiranhttps://github.com/status-im/nim-asyncdispatch2
19:53:04FromGitter<rayman22201> Yeah, the status people have an alternate async runtime even... Though I'm with Dom in that they really should have ported their fixes back to the main-line instead of hard forking like that.
19:53:14FromGitter<xmonader> well, communicating that would be great, having more social impact also would be nice to see article weekly? or even monthly by the core developers telling us updates or even reddit AMA
19:53:36FromGitter<mratsim> the async bugs are raised to the Nim bug tracker
19:53:39FromGitter<xmonader> here's an example of an effort in haskell ⏎ https://a-tour-of-go-in-haskell.syocy.net/en_US/index.html
19:53:54narimiranmonthly-something is one of my ideas for 2019 too
19:54:25FromGitter<rayman22201> @narimiran maybe a personal question, but did you get hired by Nim? are you official?
19:54:28FromGitter<rayman22201> lol
19:54:47FromGitter<mratsim> These are some of the bugs that we needed to hard fork for: ⏎ ⏎ https://github.com/nim-lang/Nim/issues/7758 ⏎ https://github.com/nim-lang/Nim/issues/7197 ⏎ https://github.com/nim-lang/Nim/issues/7193 ... [https://gitter.im/nim-lang/Nim?at=5c0ad007f992693c7a3a7a9b]
19:54:58*platoff joined #nim
19:55:04FromGitter<xmonader> @narimiran It'd be amazing to create a Poll or something asking about the most needed areas to improve
19:55:10narimiran@rayman22201 i'll start in january :)
19:55:22FromGitter<rayman22201> congrats! I'm very jealous lol
19:55:22FromGitter<xmonader> yay! @narimiran congrats!!
19:55:31FromGitter<zacharycarter> congrats narimiran :)
19:55:47FromGitter<rayman22201> I hope I didn't let the cat out of the bag too early :-P
19:56:16narimiran@xmonader: there is the yearly nim survey, and documentation is frequently mentioned. so this is something that bothers a lot of people and we should deal with it
19:56:21narimiranthanks, guys!
19:56:47FromGitter<rayman22201> @mratsim Is there plans to backport fixes for these things / or attempt to merge your hard fork back?
19:56:56narimiranwell, i didn't want to say anything until then, but it has been already mentioned on IRC several days ago so i guess i can talk about it now :)
19:57:25FromGitter<zacharycarter> @xmonader - I'd encourage you to read those resources I linked - it will help you to gain an understanding of Nim's concurrency primitives
19:57:55FromGitter<zacharycarter> goroutines are not threads and go channels are not Nim channels
19:58:14*enthus1ast joined #nim
19:58:20FromGitter<xmonader> @narimiran yeah I took that survey this year do you have roadmap? do you plan to do more social networking too for community feedback
19:58:30FromGitter<zacharycarter> goroutines are an abstraction that golang included in its language design - basically allowing for async / await style coding across a number of threads handled by the language runtime
19:58:38FromGitter<xmonader> @zacharycarter I'll do for sure
19:59:00FromGitter<xmonader> @zacharycarter with the exception of not being limited to one core
19:59:00FromGitter<zacharycarter> also - if you don't want to deal with Nim's memory model - just use a different GC
19:59:27FromGitter<zacharycarter> well yes - that's the `a number of threads` part
20:00:22narimiran@xmonader it is too early to tell exactly what is the plan. i have some ideas about the areas where we can improve when it comes to 'community' (it is hard to put it under one name)
20:00:45FromGitter<alehander42> @narimiran congrats!
20:00:52FromGitter<zacharycarter> Nim has partial support for coroutines - so like green threads or fibers
20:01:01narimiranmy hope is that in one year from now we won't be having the same talks we have today :)
20:01:02FromGitter<zacharycarter> but this only works for windows and linux I think?
20:01:13narimiranthanks @alehander42!
20:01:24FromGitter<zacharycarter> macOS doesn't even have fiber support - you have to use GrandCentralDispatch for context switching
20:01:27FromGitter<alehander42> our new nimirian steve klabnik
20:02:43narimiran:)
20:03:16FromGitter<xmonader> @narimiran I'm sure you will manage to deliver GREAT things
20:03:46FromGitter<zacharycarter> I do want to try to play around with GCD + Nim
20:03:49narimiranno pressure, huh? :D
20:03:59FromGitter<zacharycarter> maybe ressurect the coro module
20:04:06FromGitter<xmonader> @zacharycarter I think writing that down in a blog post or even hosted article on nim website would be amazing to read
20:04:13FromGitter<xmonader> @narimiran not at all, we got your back :)
20:04:54FromGitter<xmonader> you seem very familiar with other languages concepts so bridging that to Nim in simple way would be amazing
20:04:56FromGitter<zacharycarter> @xmonader - I'm neck deep atm in my new game engine - but it features a lock free work-stealing job system written in Nim
20:05:17FromGitter<zacharycarter> once I have the editor working - at least the GUI starting to be rendered - I will write a blog post on it
20:05:25FromGitter<alehander42> work-stealing, is it called mexico, you filthy democrat
20:05:25FromGitter<zacharycarter> or maybe a series talking about the engine architecture
20:05:28FromGitter<zacharycarter> :P
20:05:37FromGitter<rayman22201> https://media.giphy.com/media/l3vR45NrUz168PcNa/giphy.gif
20:05:48FromGitter<rayman22201> Sorry. I couldn't help myself :-P
20:05:51FromGitter<zacharycarter> hahaha
20:05:53FromGitter<xmonader> more interesting things to read in 2019 then :)
20:06:43FromGitter<alehander42> i love mexico, sorry ⏎ sounds very good seriously, what game is it for
20:07:49FromGitter<zacharycarter> I don't really have a game design nailed down yet - but I am leaning towards some sort of strategy game - war based
20:08:21FromGitter<zacharycarter> I really liked Sid Meier's Gettysburg growing up - and I've always liked tactical wwii games and tabletop war games
20:08:27FromGitter<zacharycarter> so something in the strategy vein
20:09:48FromGitter<alehander42> wow so strange to hear sid meyer
20:09:50FromGitter<alehander42> and not civ
20:09:58FromGitter<alehander42> i didnt even know he has other games
20:10:02FromGitter<zacharycarter> :P
20:10:41FromGitter<zacharycarter> civ is great though
20:11:13FromGitter<alehander42> i am a fan too, I even dreamed of a more uh social-heavy civ, like something where you can have way deeper economy/social policies and their effects
20:11:31*narimiran quit (Remote host closed the connection)
20:11:32FromGitter<alehander42> also loving alt history games
20:11:32FromGitter<zacharycarter> that'd be neat
20:14:08FromGitter<zacharycarter> the thing is @xmonader - doing things like lock free multi-threaded job systems still requires relying on things like pointers and atomics if you're going to use Nim's default GC
20:14:29FromGitter<zacharycarter> there really is no getting away from it - you're going to need lock free data structures
20:14:44FromGitter<zacharycarter> so you're going to need atomic operations
20:15:43FromGitter<zacharycarter> https://github.com/zacharycarter/zeal/blob/JobScheduler/src/zealpkg/core/shared_deque.nim - for instance
20:24:22FromGitter<rayman22201> some people want Nim to be a better / faster python, i.e. they don't want to worry about pointers and atomics etc... Some people want Nim to be an easier to use C++ or Rust. The reality is that Nim is somewhere in the middle lol.
20:29:41*wildlander joined #nim
20:30:20kungtotteThere's no reason it can't be both. There are two main things that people like about Python: an extensive library repository and being as easy to write as pseudocode.
20:32:25*UxerUospr joined #nim
20:32:28FromGitter<alehander42> yeah I also think for many applications the kinda-like-python-subset is absolutely enough
20:33:39kungtotteRust is already improving a lot on C++ when it comes to readability, though they still favour special characters in their syntax too much, and of course they have that whole borrow checker thing going on which is quite different from anyone else.
20:40:16*revere quit (Ping timeout: 246 seconds)
20:45:06*revere joined #nim
20:48:37*Vladar quit (Remote host closed the connection)
20:52:24FromGitter<xmonader> @zacharycarter in go i know how to use atomics and my code doesn't seem frightening like the code you sent, maybe it's because you understand the lowlevel parts better, but i don't see myself writing that in general.
20:53:28*revere quit (Ping timeout: 264 seconds)
20:53:28FromGitter<xmonader> @alehander42 I totally agree with that!
20:54:47*matti quit (Ping timeout: 240 seconds)
20:57:22*revere joined #nim
20:58:01dom96narimiran[m]: regarding your question about the forum: just switch the "moderated" users to "user" (as long as they aren't posting spam)
21:04:05*rockcavera quit (Remote host closed the connection)
21:20:34FromGitter<mratsim> @rayman22201 sorry didn’t see. I think most of the issues where fixed as apparently they are closed now. For now there is no plan to merge them back because not enough time and we need to consolidate our transport and P2P needs.
21:21:55FromGitter<rayman22201> That's understandable. It would be nice to reconcile eventually though :-)
21:23:04FromDiscord_<Virepri> kungtotte I honestly dislike Rust's syntax as a whole, despite how much I like golang's syntax
21:30:11*Trustable quit (Remote host closed the connection)
21:32:38*vegax87 quit (Changing host)
21:32:38*vegax87 joined #nim
21:32:38*vegax87 quit (Changing host)
21:32:38*vegax87 joined #nim
21:34:17*UxerUospr quit (Quit: Lost terminal)
21:34:25FromGitter<zacharycarter> @xmonader i dont see any difference from golang atomics. You generally dont need atomic ops unless youre actively avoiding locks
21:34:58FromGitter<zacharycarter> And generally, you dont even need multiple threads, it just adds complexity
21:39:04*zakora quit (Quit: WeeChat 2.2)
21:41:39*kapil____ quit (Quit: Connection closed for inactivity)
21:58:58*vlad1777d joined #nim
22:11:59FromGitter<arnetheduck> @alehander42 I'll take one lib that works over 3 that don't.. the first time I tried channels in a simple app (testament, imagine that - nothing fancy, just a simple channel consumed by a few threads), they crashed on some garbage collection issue - doesn't inspire confidence.. likewise with async - we forked async at status because we have a product to build and can't afford the roundtrip times of coordinating
22:11:59FromGitter... upstreaming and discussing every little bugfix and change - the sources are all there in the open, nothing prevents the community from porting them to upstream if there's interest to do so (I for one believe that the other way around makes more sense, that asyncdispatch is removed from the std lib and moved into its ... [https://gitter.im/nim-lang/Nim?at=5c0af02f3de4e816e22735b0]
22:15:35FromGitter<arnetheduck> forking also gives us the freedom to modify the API at will to fit our needs, again without breaking anything for anybody - once it settles down and we have a working app, again, nothing prevents interested parties to port the changes to upstream
22:18:19FromGitter<alehander42> @arnetheduck I was defending exactly that: its improbable to expect something else than async to work well before 1.0
22:18:38FromGitter<alehander42> and I am also a fan of the "evolve stuff" as 3rd package idea
22:18:54*rockcavera joined #nim
22:19:12FromGitter<alehander42> where the stdlib is the goverment program and 3rd party apis/libs compete in a free market
22:20:10FromGitter<arnetheduck> yeah, I think we're aligned :) stdlib can set the tone for infrastructure so the universal stuff doesn't get fragmented, but the rest..
22:21:09FromGitter<alehander42> yeah, kinda thought a bit more on that distinction after some of your discussions
22:24:04FromGitter<alehander42> well, that's kinda the problem: what is "essential" infrastructure is the thin line (in languages and in the state too )
22:24:05*vlad1777d quit (Remote host closed the connection)
22:24:07FromGitter<rayman22201> @arnetheduck I understand your point, you have products to ship. I get that. But concurrency primitives are kind of core to the language. And the problem with doing massive hard fork on something so core, is that there is little incentive to port it back afterwards. It's silly to assume the community will just magically push it back to mainline eventually. This has happened many times in other domains. The fork
22:24:07FromGitter... rarely gets pushed back. Instead you get a fractured ecosystem.
22:25:18*vlad1777d joined #nim
22:25:19FromGitter<rayman22201> I'm all for many small libs and the free market. But There has to be some "government funded projects" to use @alehander42's analogy.
22:29:15FromGitter<rayman22201> That being said, I completely understand why you forked. Especially considering when Status started using Nim. It was a chicken and egg problem, and you took the "lesser of two evils". And because of that, and the resulting investment from Status, Nim is better in general now.
22:30:10FromGitter<rayman22201> I am going crazy with the analogies today. sorry for any non-native English speakers lol
22:30:40FromGitter<arnetheduck> er, let's not get ahead of ourselves here, it's a fancy socket library .. and I'd argue that it works the other way around - the freestanding libraries are an excellent place to start a language standardization process - this does wonders for quality, it's the ultimate peer review process
22:31:53dom96Nice to see someone sharing my concerns with regards to the asyncdispatch fork
22:33:10FromGitter<rayman22201> I've never seen a successful standardization process work that way @arnetheduck. The free market is good for many things, but not standardization. There is no incentive for that. In free market economics, you need incentive.
22:33:55dom96It's a real shame to see such fragmentization. I'm still not sure why the fork occurred
22:33:58FromGitter<arnetheduck> I guess you're not a C++ programmer :) or a rust programmer :) or a java programmer :)
22:34:02*platoff quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:34:17FromGitter<arnetheduck> or a python programmer :) want me to keep going?
22:34:26dom96Like, what issues did you find with asyncdispatch that couldn't have just been a simple PR?
22:35:51FromGitter<rayman22201> Every single one of those languages has a strong internal standardization process, independent of the wider ecosystem. I don't see your point at all
22:38:42FromGitter<zacharycarter> I think both cases can be argued
22:38:42stefanos82dom96: I have reported the bug. When you are going to PR, can you edit the README as well? it mentions multiple times the use of build_all.sh
22:39:02dom96stefanos82: of course
22:39:11stefanos82awesome
22:39:13FromGitter<zacharycarter> Nim is changing - quite rapidly - if you're building a product on top of Nim and need a stable implementation for a certain feature, hard forking could be a sensible option
22:39:29FromGitter<rayman22201> C++ is a freaking mess of fragmentation. C++ does have Boost as a kind of "blessed" testing ground for new std lib features, but even that is kind of a mess. I want a better world for Nim lol
22:39:42FromGitter<zacharycarter> it's also not an incentive for you - to contribute that hard fork back
22:40:07FromGitter<arnetheduck> each and every single one of those languages has a strong tradition of using freestanding libraries as a breeding ground for standardization - half of the std c++ lib comes from boost which is build from free-market libraries - java is an even better example, they take a successful market library (logging, xml, web frameworks etc etc etc) and put an interface on them so that multiple implementations can coexist -
22:40:08FromGitter... and where do you think python libraries come from?
22:40:30FromGitter<zacharycarter> it does suck that the hard fork occurred - but I agree with @arnetheduck - it's unrealistic to expect a company to wait on a peer-reviewed change management process for their product(s)
22:41:08FromGitter<zacharycarter> and if the community decides asyncdispatch2 is a superior implementation - then why can't that just become the official implementation?
22:41:16FromGitter<zacharycarter> don't we go through this experimentation process anyway with Nim constantly?
22:41:42FromGitter<zacharycarter> some feature of Nim is constantly in an experimental phase or being re-worked and it either makes it into the ecosystem or it doesn't
22:41:50FromGitter<zacharycarter> err language rather
22:41:50dom96arnetheduck: can you explain why you decided to fork?
22:42:33dom96ugh, should testament be rebuilding the compiler?
22:42:38FromGitter<arnetheduck> > likewise with async - we forked async at status because we have a product to build and can't afford the roundtrip times of coordinating upstreaming and discussing every little bugfix and change - the sources are all there in the open, nothing prevents the community from porting them to upstream if there's interest to do so (I for one believe that the other way around makes more sense, that asyncdispatch is removed
22:42:38FromGitter... from the std lib and moved into its own package so it can either be developed in a more agile fashion or wither away unused if it doesn't reach the quality needed for it to be useful) ⏎ ⏎ @dom96
22:43:04dom96argh, I wish you guys would use IRC
22:43:25FromGitter<arnetheduck> > forking also gives us the freedom to modify the API at will to fit our needs, again without breaking anything for anybody - once it settles down and we have a working app, again, nothing prevents interested parties to port the changes to upstream ⏎ ⏎ @dom96
22:43:43dom96Yes, I read that. I want specific reasons why you've decided to fork
22:43:47FromGitter<zacharycarter> we could just consolidate around one chat medium
22:43:50dom96What issues did you run into with asyncdispatch that needed fixing?
22:44:13FromGitter<zacharycarter> and get rid of the bridge
22:44:46FromGitter<arnetheduck> @mratsim listed a bunch earlier up in the chat, but really, those are just examples and not the core reason
22:44:48FromGitter<rayman22201> But I like Gitter. It's easier lol
22:45:01FromGitter<zacharycarter> Gitter could be the medium :P
22:45:23FromGitter<zacharycarter> although I know a lot of people hate gitter
22:45:25FromGitter<alehander42> The bridges are fine
22:45:26FromGitter<rayman22201> I don't want to force everyone to use my preference ;-) free market
22:45:32FromGitter<zacharycarter> I'd be up for just moving everything to discord
22:45:55dom96I mean, I've read the differences listed here: https://github.com/status-im/nim-asyncdispatch2#core-differences-between-asyncdispatch-and-asyncdispatch2
22:46:03dom96But they really don't seem to warrant a hard fork to me
22:46:57FromGitter<alehander42> I feel a part of the problem is async dispatch and asyncdispatch2 are not different libs, 2 is just like a patch fkr the default one, so it doesn't
22:47:25FromGitter<alehander42> Nvm my message got sent while being WIP
22:47:45FromGitter<rayman22201> The most successful hard fork model I have seen is the linux Kernel. Many hardware companies hard fork linux to create new drivers etc..., but the onus is always on the company to patch back to upstream. The community doesn't do it.
22:49:23dom96Really? I would think that's not always the case
22:49:32dom96If something is very valuable the community will step in
22:50:59FromGitter<rayman22201> It's true that it isn't always the case, it's more common in with the kernel than other places though. Linux is also a weird case in that the community and the businesses are often the same people or at least closely aligned.
22:51:26FromGitter<rayman22201> The company want's their drivers in upstream, otherwise nobody will use their hardware.
22:51:41FromGitter<zacharycarter> dom96: an earlier message from @mratsim mentions some issues that he describes as being reasons for the hard fork - nim-lang/Nim#7758 ⏎ nim-lang/Nim#7197 ⏎ nim-lang/Nim#7193 ⏎ nim-lang/Nim#7192 ⏎ nim-lang/Nim#6846 ... [https://gitter.im/nim-lang/Nim?at=5c0af97c5e409525033003cf]
22:51:56FromGitter<arnetheduck> er, linux was the prime driver for git, a tool that exists solely to make forking easy.. hmm..
22:52:45dom96so now that these are all fixed, can we get rid of asyncdispatch2 for the sake of harmonization?
22:53:03dom96(well, almost all, but come on, that last one is surely just a PR away)
22:54:04dom96It honestly pains me to see it. I can't use your amazing packages because they depend on asyncdispatch2
22:54:11dom96It's really a shame
22:54:25FromGitter<rayman22201> that also goes back to my point, where that kind of easy forking is most successful when the community and the enterprise is incentivized to merge back.
22:59:04FromGitter<arnetheduck> @rayman22201 you still haven't answered though how specifically all of c++, java, rust and python have failed to attract quality libraries? you mentioned c++'s vibrant ecosystem of competing alternatives and boost as an extra step which fits C++ well due to the enormous impact adding something to C++ has - for Nim in particular, I'm really glad we gained experimental, which is a nice and lightweight step appropriate
22:59:04FromGitter... for the size of the language and development stage its in - ie more lightweight than c++, but a nod towards the higher bar features have to have before they're worthy of being included
23:00:34FromGitter<rayman22201> I'm all for experimental. Rust does the same, and I think it's a good idea.
23:01:52*martin1_ joined #nim
23:02:29martin1_hi everyone! how can i iterate mutable over a collection of rows in a csv parser?
23:03:31dom96martin1_: What type is your collection?
23:03:57FromGitter<arnetheduck> yeah, and look at how they're seeding their socket lib in - ie they develop tokio and mio completely on the side and slowly let "infrastructure" level features seep into rust as they gain quality
23:05:36FromGitter<rayman22201> That's fair. But both of those projects have core language developers deeply involved in the process. This keeps the communication / merge barrier low. The did not "let the community" merge these features back by themselves.
23:05:54martin1_dom96: it's just a CsvRow (seq[string])
23:06:01FromGitter<rayman22201> Core language devs on the projects, and driving the merging of features back.
23:06:22FromGitter<rayman22201> Status hard forked and seems to have no plans to help seal the rift. That is not what is happening with Rust
23:06:27dom96martin1_: for item in mitems(row): # should work
23:06:38FromGitter<rayman22201> And a similar story is true for Boost and C++
23:07:53martin1_brilliant! thanks!
23:08:35FromGitter<arnetheduck> c++ doesn't have any "core devs" really - it's an open community you can join at any time - in fact, that's where its recent networking library come from as well (standalone -> boost -> std)
23:10:02FromGitter<arnetheduck> rust, likewise - the fact that the core devs work on libraries too has several good side effects: the core devs dogfood the tooling surrounding library management, those that want the latest can choose to use them, the core of the language is stable and of high and consistent quality - win-win...
23:11:32dom96So will, or won't Status eventually try to bridge the gap between asyncdispatch2 and stdlib?
23:12:22FromGitter<rayman22201> The point is that in both of those examples people writing the libraries are driving the merge back to mainline. They didn't just leave it to the community to do so.
23:18:26FromGitter<rayman22201> I'm all for experimenting outside of the std, and slowly merging things in as they stabilize. This is a good model. But that process can't solely belong to the core devs or the community. The feature authors must also share some responsibility here.
23:20:42FromGitter<zacharycarter> well, otherwise I think it should at least be more explicit that you should be wary building on top of the fork
23:22:05FromGitter<zacharycarter> the name of the library is asyncdispatch2 - so people may very well think it's a experimental implementation that may make its way into the stdlib
23:22:29dom96This^
23:22:31FromGitter<zacharycarter> not saying that's not the case - but if it is - I could see the naming causing confusion
23:28:41*elb_ quit (Quit: WeeChat 2.3)
23:29:09FromGitter<zacharycarter> maybe that's exactly why it's named asyncdispatch2 - because their intention all along has been to merge, and cheatfate / status expected us to be ready for a present in the future and we're worried about nothing.
23:29:57FromGitter<zacharycarter> and they really like surprises
23:30:00FromGitter<rayman22201> lol
23:38:59*stefanos82 quit (Remote host closed the connection)
23:42:06*fthe joined #nim
23:43:17fthehi. Just wondering if there's something like argmax/argmin built-in? (index of max/min element of seq/array)
23:44:46FromGitter<rayman22201> `high` and `low` I believe
23:45:16FromGitter<rayman22201> https://nim-lang.org/docs/manual.html#types-array-and-sequence-types
23:47:12FromGitter<mratsim> argmin/max returns the index of the first minimum/maximum value encountered
23:48:09FromGitter<mratsim> argmax exists in Arraymancer: https://github.com/mratsim/Arraymancer/blob/4c114fed3af9298070a1127d26f2cc263692296f/src/tensor/aggregate.nim#L131-L187
23:48:28FromGitter<mratsim> Argmin is just a PR away ;)
23:49:14FromGitter<arnetheduck> er, I think this is spiralling out of control a bit.. @dom96, the simple answer is that we'll do it if we feel it's in our interest to do so - you want to make that more probable? help out and make it a smoother process, for example by porting some of the work... seriously, we took some existing code, adapted it for our use case and kept it open so that the community would benefit should should there be any benefit
23:49:14FromGitter... to be had.. if it's truly better and useful for the larger community, it, or the ideas behind it, will make it to the right place eventually - that's the point of an open development process
23:50:19FromGitter<mratsim> @dom96 I don’t think any of us is closed to contributing back either the whole ad2 or patches to the stdlib. But we need something we can control. Networking is the core of our product.
23:50:56FromGitter<mratsim> Also this is why apart from transport, the {.async.} {.await.} usage is the same.
23:51:17FromGitter<mratsim> @fthe ^ (argmax/argmin)
23:52:16fthe@mratsim: thanks :) I guessed it existed in Arraymancer, as it does in numpy... just wondered if there was something for built-in seqs/arrays
23:52:36FromGitter<arnetheduck> @rayman22201 there's no such thing as responsibility - we're all operating on a consensus model - in such a place, coercive measures such as voting or "should" and "has" have no meaning or place - all you can do is argue your case eloquently and hope that you come to a shared understanding and aligned incentives
23:52:46ftheI do need to get around to trying out arraymancer some time, the README makes it sounds very nice
23:52:47*martin1_ quit (Ping timeout: 240 seconds)
23:52:56FromGitter<rayman22201> sorry @fthe I misread your question lol. Yeah. arraymancer is the way to go for that.
23:53:06FromGitter<mratsim> Given the time I spent on the README I hope so :D
23:53:21FromGitter<arnetheduck> (where "eloquently" most often means "doing the work" or "writing the code" and "being useful to others")
23:53:24FromGitter<mratsim> though I need to get more docs and example out there
23:53:47ftheIt shows :)
23:53:57fthe(the readme I mean, very polished)
23:54:25FromGitter<mratsim> btw, if you need to often loop on collections, be sure to check loop-fusion: https://github.com/numforge/loop-fusion
23:54:44FromGitter<mratsim> Or zero functional if you prefer a functional approach: https://github.com/zero-functional/zero-functional
23:55:00FromGitter<rayman22201> @arnetheduck that's not entirely true. Money plays a big roll. Those "eloquent" things like "doing the work" usually is paid for by somebody. Open Source is still very much controlled by money, despite some of the more idealistic rhetoric about it.
23:55:52FromGitter<mratsim> I would say, in case of Nim, it’s controlled by time.
23:56:05fthecool, I did not know about those. Nim is not super easy to google for, but there does seem to be a food ecosystem of good-quality libs out there
23:56:25FromGitter<mratsim> probably easier than Go, and not sure about Rust :P
23:56:41FromGitter<rayman22201> time = money lol
23:57:02FromGitter<mratsim> I started Arraymancer without money and just time ;)
23:57:11FromGitter<rayman22201> but your time is valuable
23:57:19FromGitter<rayman22201> whether you actually received money for it or not
23:57:42FromGitter<rayman22201> I'm getting into the weeds here with economic theory.
23:58:05FromGitter<mratsim> you still have some margin