<< 26-03-2019 >>
00:02:16*rnrwashere quit (Ping timeout: 255 seconds)
00:07:54*rockcavera quit (Ping timeout: 250 seconds)
00:30:01*stefanos82 quit (Remote host closed the connection)
00:35:24*krux02 quit (Remote host closed the connection)
00:36:31*sentreen_ quit (Ping timeout: 244 seconds)
00:39:15*rnrwashere joined #nim
00:40:22*sentreen_ joined #nim
00:41:08*noeontheend joined #nim
00:43:33*rnrwashere quit (Ping timeout: 250 seconds)
00:45:55*sentreen_ quit (Ping timeout: 255 seconds)
00:48:49*sentreen_ joined #nim
01:10:02*sentreen_ quit (Ping timeout: 246 seconds)
01:13:20*sentreen_ joined #nim
01:18:06*disruptek quit (Ping timeout: 250 seconds)
01:18:19*disruptek_ joined #nim
01:18:30*rnrwashere joined #nim
01:20:37*disruptek_ is now known as disruptek
01:22:38*sentreen_ quit (Ping timeout: 246 seconds)
01:24:06*enthus1ast quit (Ping timeout: 268 seconds)
01:25:55*sentreen_ joined #nim
01:30:41*sentreen_ quit (Ping timeout: 246 seconds)
01:33:02*sentreen_ joined #nim
01:34:58*lritter quit (Quit: Leaving)
01:39:01*rnrwashere quit (Remote host closed the connection)
01:44:02*disruptek quit (Quit: Bye)
01:45:57*rnrwashere joined #nim
01:47:38*disruptek joined #nim
01:52:19*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
02:14:27*chemist69 quit (Ping timeout: 240 seconds)
02:16:42*chemist69 joined #nim
02:21:29*chemist69 quit (Ping timeout: 250 seconds)
02:22:57*chemist69 joined #nim
02:28:17*a_b_m joined #nim
02:32:33*a_b_m quit (Ping timeout: 245 seconds)
02:32:38*abm quit (Ping timeout: 268 seconds)
02:42:14*seni quit (Quit: Leaving)
02:44:42*rnrwashere quit (Remote host closed the connection)
03:05:58*banc quit (Quit: Bye)
03:17:35FromGitter<Varriount> Zevv: it could be worse. RuneImpl used to be a plain `int`, meaning that it changed size depending on the platform.
03:18:41*noeontheend quit (Ping timeout: 250 seconds)
03:26:56*banc joined #nim
03:42:20*rnrwashere joined #nim
03:54:36*rnrwashere quit (Remote host closed the connection)
03:55:17*rnrwashere joined #nim
04:00:07*rnrwashere quit (Ping timeout: 268 seconds)
04:04:17*dddddd quit (Remote host closed the connection)
04:28:11*chemist69 quit (Ping timeout: 258 seconds)
04:30:09*chemist69 joined #nim
04:35:20*nsf joined #nim
04:54:15*Enki1 joined #nim
04:54:29*Enki1 left #nim ("The Lounge - https://thelounge.chat")
05:43:20*narimiran joined #nim
05:43:59*I_Right_I quit (Remote host closed the connection)
05:52:33*ryukoposting joined #nim
05:52:47ryukopostingquick quick quick everyone post nim code golf https://dailyprog.org/f/14av
05:59:59*leorize joined #nim
06:05:22*ryukoposting quit (Quit: WeeChat 1.6)
06:50:17FromGitter<Varriount> Araq: Since when did Nim have a `stats` module?
07:00:00*gmpreussner quit (Quit: kthxbye)
07:01:13Araqit used to be in math
07:01:17Araqit's quite old stuff
07:04:35*gmpreussner joined #nim
07:06:16*krux02 joined #nim
07:07:54*krux02 quit (Remote host closed the connection)
07:10:32*krux02 joined #nim
07:15:18*PMunch joined #nim
07:19:18*jjido joined #nim
07:21:07FromGitter<mratsim> yeah, it was already there when I started
07:22:20*couven92 joined #nim
07:23:23*Senketsu quit (Ping timeout: 245 seconds)
07:24:49*vlad1777d quit (Ping timeout: 250 seconds)
07:31:51*noonien quit (Quit: Connection closed for inactivity)
07:46:36*solitudesf joined #nim
08:06:07*Vladar joined #nim
08:19:25*kapil____ joined #nim
08:37:02*enthus1ast joined #nim
08:54:52*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:06:04*a_b_m joined #nim
09:14:01ZevvFrom an object NimNode, I can use obj.getTypeImpl to iterate the fields. How can I access any fields the object inherited?
09:15:05Araqobj[1].getTypeImpl or obj[0], something like that
09:15:50ZevvAh, OfInHerit is there, thanks.
09:27:03FromGitter<nigredo-tori> @Araq, is there a good way to pass `NULL` values through `db_sqlite` API now that the strings are not nillable?
09:27:55leorizenigredo-tori: use the `ndb` nimble module
09:28:39leorizesame interface as `db_sqlite`, but with better api for passing data.
09:29:00FromGitter<nigredo-tori> @leorize, thank you.
09:37:49*neceve joined #nim
10:16:10*stefanos82 joined #nim
10:31:44*Skaruts joined #nim
10:33:22*Skaruts is now known as skaruts
10:43:17*chemist69 quit (Ping timeout: 250 seconds)
10:56:36*SoKoS joined #nim
10:57:08*kapil____ quit (Quit: Connection closed for inactivity)
11:00:40SoKoShello just tried out asynchttpserver example from the docs of nim. In the host machine of the server it loads fast but when i try from another device it is really slow eventually it loads thought after a minute or two. Is this normal?
11:02:37Araqno. AntiVir?
11:02:41Araqfirewalls?
11:03:01SoKoSwindows defender firewall is disabled for port 8080
11:03:12SoKoSshould i close that too?
11:04:00SoKoSi am seriously thinking going to linux i am tired of windows not working
11:04:24Araqhttps://nim-lang.org/araq/ownedrefs.html feedback appreciated
11:04:46SoKoSbrb going to boot ubuntu try the example there sorry if i am interupting
11:05:41*SoKoS quit (Quit: Page closed)
11:08:23narimiranfeel free to post your feedbacks to Araq's blog-post here: https://news.ycombinator.com/item?id=19490685 to create some buzz and discussion
11:12:07narimiran...and on reddit: https://old.reddit.com/r/programming/comments/b5odeo/a_new_runtime_for_nim/
11:16:09*SoKoS joined #nim
11:29:18SoKoSyes all good nim in ubuntu is way faster in compiling too. I am certain that windows defender is the problem
11:36:48FromGitter<mratsim> `The required runtime mechanisms easily map to weird, limited targets like webassembly or GPUs.`if your GPU is weird, I'm happy to relieve you of it :P
11:38:52Araqlol
11:39:13FromGitter<mratsim> otherwise, very exciting
11:39:52*FromGitter quit (Remote host closed the connection)
12:01:49*vlad1777d joined #nim
12:20:30*Snircle joined #nim
12:23:40*gangstacat quit (Quit: Ĝis!)
12:25:59*dddddd joined #nim
12:35:38*gangstacat joined #nim
12:39:53*solitudesf quit (Ping timeout: 246 seconds)
12:47:00*Senketsu joined #nim
12:52:37*noonien joined #nim
12:53:49*SoKoS quit (Quit: Page closed)
12:58:59*lritter joined #nim
13:04:24*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
13:38:56*uptime is now known as idletime
13:43:15livcdshould os walkDir work on windows unc path?
13:43:58AraqI think so :-)
13:47:17livcdfor just walkFiles i get an incorrect path back without the one backslash (\) https://glot.io/new/nim
13:47:48narimiranlivcd: your link gives an empty editor
13:48:29livcdooops
13:49:49livcdhttps://glot.io/snippets/faphqta2im
13:53:12Araqso duplicated backslashes cannot be folded into \ ?
13:53:24Araqwasn't aware, no wonder I got it wrong :P
13:54:29livcd:O
13:55:17*Snircle joined #nim
13:57:58*Snircle quit (Client Quit)
14:03:48*nsf quit (Quit: WeeChat 2.4)
14:05:28*sentreen_ quit (Quit: WeeChat 2.3)
14:05:58*sentreen joined #nim
14:21:27shashlickAraq: submitted an issue for the string conflict I mentioned the other day - https://github.com/nim-lang/Nim/issues/10907
14:22:50Araqshashlick, the fix is to remove typedef struct TStringDesc* string; from nimbase.h
14:23:00Araqit's not used anywhere, I think
14:23:16shashlickoh is that the case?
14:23:50*UNIcodeX joined #nim
14:24:59FromDiscord<UNIcodeX> hello all.
14:25:20shashlickwelcome UNIcodeX
14:25:41shashlickAraq: I'll remove it from nimbase.h
14:28:13FromDiscord<UNIcodeX> I am wondering if it were possible to {.exportc.} an iterator, or if that's a compile time construct only at the moment.
14:29:03FromDiscord<UNIcodeX> I had tried doing this yesterday, playing around, and I was able to import a test proc, but not the iterator. The DLL loader complained that the symbol for the iterator did not exist.
14:29:27Araqthe iterator has no C representation that could be exported
14:29:41FromDiscord<UNIcodeX> I was afraid of that. OK. thanks!!
14:34:49*skaruts quit (Ping timeout: 256 seconds)
14:35:54*vegax87 quit (Ping timeout: 268 seconds)
14:43:58*UNIcodeX quit (Quit: Leaving)
14:52:41*PMunch quit (Remote host closed the connection)
14:54:16*vegax87 joined #nim
14:56:31*chimez joined #nim
15:05:31*chimez quit (Quit: chimez)
15:05:36*Vladar quit (Remote host closed the connection)
15:16:52*cgfuh joined #nim
15:28:22*solitudesf joined #nim
15:31:16*Trustable joined #nim
15:38:32*rnrwashere joined #nim
15:43:18*Snircle joined #nim
15:47:04*rnrwashere quit (Ping timeout: 250 seconds)
15:58:09*neceve quit (Remote host closed the connection)
16:01:08*krux02 quit (Remote host closed the connection)
16:05:01shashlickAraq: regarding owned refs, your comment that "why most Nim code runs single threaded" was easily solved by using boehm in my case. is that a good approach for those who prefer sticking to a gc?
16:16:19*vlad1777d quit (Ping timeout: 246 seconds)
16:29:22Araqshashlick, sure but I don't think you know what you're missing without 'owned'
16:31:55shashlicki'll bet, but still trying to understand it 🙂
16:32:32*ikan-keli_ quit (Ping timeout: 245 seconds)
16:39:55*skaruts joined #nim
16:40:55skarutssome_seq = newSeq[int](20)
16:41:24skarutsdoes that mean the sequence is initialized with indices from 0 to 19, or 0 to 20?
16:41:43narimiran20 places, from 0 to 19
16:41:56skarutsthanks
16:47:16livcdhmm i dont think walkDir works with UNC path :O
16:53:06livcdhmm what a shame
16:53:52Araqplease fix it
16:55:49livcdi started to check what is walkDir doing
17:04:27*nsf joined #nim
17:38:49*uvegbot quit (Remote host closed the connection)
17:39:38*uvegbot joined #nim
17:54:46*ikan-keli_ joined #nim
18:18:36*livcd quit (Ping timeout: 250 seconds)
18:48:55*livcd joined #nim
18:53:34*livcd quit (Ping timeout: 255 seconds)
19:11:18*salewski joined #nim
19:12:48salewskiIn the blog post: like "goto" got replaced by "structured control flow" like if and while statements,
19:13:08salewskiI think the wording is not absolutely clean.
19:13:29salewskiBecause we had "if condition then goto..."
19:13:51salewskiso goto is not replaced by if.
19:14:22salewskigoto is replaced by iterations like loop, while, repeat :-)
19:14:32salewskiBye.
19:17:36*salewski quit (Quit: WeeChat 2.3)
19:21:29*sz0 quit (Quit: Connection closed for inactivity)
19:26:11*theelous3_ joined #nim
19:32:10*jjido joined #nim
19:38:19rayman22201Thanks for the blog post Araq. Fun to see things start to come together.
19:38:38rayman22201Somewhat interesting questions from the reddit thread. 1.) How is the reading a "partially constructed object" problem handled: https://old.reddit.com/r/programming/comments/b5odeo/a_new_runtime_for_nim/ejf6dvt/
19:38:43ZevvOften when using object variants I need non-distinct combinations of fields. case 1 needs fields A and B, case 2 A and C and case 3 B and C - but there is no way to express such a thing at this moment, right?
19:39:33rayman22201@Zevv, correct. There was an RFC for this, but nothing has made to the language yet iirc.
19:40:25Zevvhm ok, thanks
19:41:26rayman222012.) How does the type safe dispose deal with sum types? https://old.reddit.com/r/programming/comments/b5odeo/a_new_runtime_for_nim/ejfplmt/
19:46:51Araqrayman22201, what's a partially constructed object?
19:47:14AraqNim has no such notion, objects start with everything binary zero'd
19:50:30Araq2.) it sets the memory to zero.
19:51:39Araqor more generally: it assumed that default(T) exists and dispose(x) also does x = default(T)
19:53:38rayman22201what if a thread reads the value before default(T) has been called? or during the execution of default(T)?
19:53:54rayman22201a different thread than the disposing thread
19:54:39Araqgood question :-)
19:54:48*jasom joined #nim
19:54:59rayman22201"partially constructed object" is a Java thing. You are correct, it does not really apply to Nim. It's more like a "partially written memory" problem lol
19:56:03Araqwell for thread interop you pass an owned ref to the thread and check for RC == 0
19:56:29jasomI would like to improve the random module for cases where threads are in use; is someone already working on this, or should I bang out a prototype of my idea?
19:56:53Araqand then ownership is transferred precisely and thread A cannot free it while B is still reading
19:59:00rayman22201That works if you the RC on. But isn't RC for debug builds only?
19:59:00Araqjasom, please note that the API has overloads that take the state so you can easily use thread local state
19:59:48Araqrayman22201, well yes, but you can simply assume the RC == 0 in a release build and hope for the best
20:00:29Araqalternatively you can use your own unique pointer that lacks the feature of having unowned aliases
20:00:38rayman22201lol. fair enough.
20:00:52AraqI should have stressed that this is what we will do for 'ref'
20:01:43jasomAraq: I have noted this, but there is e.g. nothing like the zero-arity randomize() for coming up with a unique seed, and I think it makes sense to have some sort of TLS for randomization baked in. I'd like to make it easy for e.g. thread pools to have access to random values as parallelizing monte-carlo simulations seems like a sensible use-case.
20:02:08Araqjasom, ok, please go ahead.
20:02:26Araqwrite an RFC or a PR already. Just making sure you know what you're doing.
20:02:50*nsf quit (Quit: WeeChat 2.4)
20:03:05jasomI'm new to nim, so just runningi it by here first :)
20:04:12Araqrayman22201, I also thought about disallowing unowned refs with yet-another-pragma but I didn't want to bring it up. Too many pragmas.
20:06:03rayman22201Understandable. That seems like something that can be added later if there is need anyway, similar to the {.immutable.} pragma.
20:06:14Araqalso we need to write non-trivial programs to see where the real problems pop up. I'm not a fan of fear-based language design.
20:06:48rayman22201This plan definitely seems good enough to start experimenting with.
20:07:00*arecacea1 quit (Remote host closed the connection)
20:07:18*arecacea1 joined #nim
20:07:46Araqin C++ 'const' is unsound during object construction
20:07:51*couven92 quit (Quit: Client disconnecting)
20:08:02Araqiirc. It never comes up in practice.
20:08:17Araqlots of other problems of C++ do come up.
20:09:28rayman22201Yeah. I agree.
20:11:28*a__b__m joined #nim
20:14:19*a_b_m quit (Ping timeout: 246 seconds)
20:18:19Zevvis this an all-or-nothing change, or could a first implementation live alongside the current GC mechanisms? That would make testing and finding problems easier by slowly migrating parts of existing code bases
20:20:25Araqyes and no. I don't want to base the implementation on the current GC as I'm in love with the determinism, makes things so much simpler to stress test.
20:21:31Araqbut for your own code it makes little difference, compile it like before, activate --newruntime and add 'owned'
20:21:35ZevvBut so much harder to test in real life - you couldn't just switch parts of the Nim compiler over to see what it feels like
20:22:15ZevvI mean, having the compiler itself as your non-trivial code base
20:22:45Araqthe plan is still: 1. make 'koch.nim' work with the new runtime.
20:22:54Araq2. make async programs work with the new runtime.
20:23:37Araqthe compiler is beyond hope for migrating to this model in the near future.
20:23:44Zevvhehe
20:24:17AraqI don't have a complete migration plan tbh.
20:24:42Araqbut it doesn't look hard. The stdlib gets 'owned' annotations and can then be used in both modes
20:25:25Araqit's declarative information, the compiler doesn't have to use it.
20:25:53ZevvBut not all existing code just lends itself for a single right 'owned', so there will need to be significant refactoring I guess
20:26:54Araqthat's the question really.
20:27:41Araqevery graph has a spanning tree. You only need to write it down.
20:28:26Araqexception: language interpreters
20:29:31Araqjust read the paper really: https://researcher.watson.ibm.com/researcher/files/us-bacon/Dingle07Ownership.pdf
20:29:39Zevvthanks
20:30:04Araqit's not my design, it's theirs.
20:30:23Araqall I did was combine it with type-safe allocation
20:30:31*Trustable quit (Remote host closed the connection)
20:30:52*livcd joined #nim
20:32:06ZevvWhy is it that papers so often lack publish date
20:33:04ZevvI always need to guess by looking at the dates of the references
20:33:53Araqit's quite new afaict
20:35:13*sealmove joined #nim
20:38:35FromDiscord<allochi> Hi Araq, I have couple of questions/suggestions and you would hate them, may I?
20:39:01Araqer... ok
20:39:09Araqwhat a bizzare introduction
20:39:17FromDiscord<allochi> Haha...
20:39:37FromDiscord<allochi> first I would like to thank you for the great work that you put into Nim
20:40:06Araqyou're welcome.
20:40:11FromDiscord<allochi> I used Nim in production to write crawlers, and it's a language that I use from time to time
20:40:47FromDiscord<allochi> my question is what is the resolution on style insensitivity? I remember there was a discussion about this.
20:41:27FromDiscord<allochi> I couldn't find in the forum what was decided on that.
20:42:14Araqwe got 'nim --styleCheck:error' in the meantime but it isn't yet activated
20:42:19*ng0 joined #nim
20:43:07FromDiscord<allochi> so there is no default behaviour? people still get to choose?
20:43:13*seni joined #nim
20:44:23FromDiscord<allochi> ok, maybe this is not the right way to say it, I mean, the default is insensitivity, and people get to choose otherwise with the flag?
20:44:56Araqeverything in Nim follows our official style guide fwiw
20:45:16FromDiscord<allochi> Ok, now the part that you going to hate me for 😄
20:45:38Araqbut since we cannot stop people from writing under_scores we make it equivalent to underScores
20:46:15*kurisu joined #nim
20:47:05FromDiscord<allochi> I really never liked white-space delimited and python like syntax, it's almost always a problem for me with things like control statements and function definitions...
20:47:37FromDiscord<allochi> I'm going to throw a suggestion here, and please don't take it in a bad way...
20:47:51Araqcurlies? 'end if'?
20:48:03FromDiscord<allochi> end
20:48:07FromDiscord<allochi> like in Julia
20:48:18FromDiscord<allochi> or maybe Ruby
20:48:29FromDiscord<allochi> I would love if you would consider it
20:48:40FromDiscord<allochi> that's all
20:48:44FromDiscord<allochi> 😄
20:49:00FromDiscord<allochi> for me, this is like
20:49:24FromDiscord<allochi> if condition:
20:49:24FromDiscord<allochi> doSomething()
20:49:24FromDiscord<allochi> deleteAllFiles()
20:49:33FromDiscord<allochi> or...
20:49:44FromDiscord<allochi> if condition:
20:49:44FromDiscord<allochi> doSomething()
20:49:44FromDiscord<allochi> deleteAllFiles()
20:49:45FromDiscord<allochi> end
20:49:58FromDiscord<allochi> I think this would help also with nimpretty
20:50:59FromDiscord<allochi> again, I hope I didn't upset you with my enquiries, I like Nim, and I admire you work and thankful for sharing it with us.
20:52:12rayman22201Araq, thinking more about the multithreaded thing from earlier. It is safe for thread A to have a non-owned ref to an owned-ref that is owned by thread B is fine, as long as thread A never does any writes. (I.E. the immutable pragma is thread safe.) Correct?
20:52:28sealmove(*whispering*: this is too fundamental to change now. AST works a certain way)
20:53:08rayman22201Also, lot's of people come to Nim from Python, they would not like this change :-)
20:53:24*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:53:52ZevvUse "#nd" instead of "end", works like a charm
20:53:58rayman22201lol
20:54:14FromDiscord<allochi> I understand that, but alot of people come from python and Nim use proc instead of def
20:54:52FromDiscord<allochi> I can list several things that doesn't look like python in Nim 😃
20:54:57sealmoveallochi: What you are proposing is a MUCH bigger change than just some keyword
20:55:11Zevvallochi: That's no coincedence: Nim is not Python is not Nim
20:55:38shashlickhonestly you can use macros and make any dialect you want
20:55:45*cgfuh quit (Quit: WeeChat 2.3)
20:55:52FromDiscord<allochi> I understand, but I have a reason for that...
20:55:58ZevvWell, that brings you only so far: it is still the Nim parser doin the work
20:56:09sealmovealso, if I am not mistaken the whitespace significance makes Nim's syntax very flexible so you can do more stuff with macros
20:56:40sealmoveif you had to close an `if` with `end`, then syntax would be more limited
20:57:09Araqallochi: personally I would have added 'end' some time ago
20:58:14Araqso I'm not offended by your feature request at all.
20:58:31FromDiscord<allochi> Well, I'm not except in designing programming languages, I just use them, and I thought that something like `end` would but a structure to the code and make it easy to maintain when it's big code base...
20:58:52FromDiscord<allochi> my request comes from me going back to some code I wrote a year ago...
20:59:19FromDiscord<allochi> I found myself lost, and I have to admit I'm more like C style programmer than python...
21:00:03FromDiscord<allochi> so, the reason I suggest this is because I really like Nim and I share what I have in mind
21:00:08AraqI still hope editors catch on and give us indentation vs {} vs 'end' vs 'end X'
21:00:40FromDiscord<allochi> but editors can't figure out logic
21:01:16FromDiscord<allochi> if I make one space mistake and type
21:01:24FromDiscord<allochi> if condition:
21:01:24FromDiscord<allochi> doSomething()
21:01:25FromDiscord<allochi> deleteAllFiles()
21:01:29FromDiscord<allochi> instead of
21:01:33FromDiscord<allochi> if condition:
21:01:33FromDiscord<allochi> doSomething()
21:01:34FromDiscord<allochi> deleteAllFiles()
21:01:35ZevvI feel that in the end these things hardly matter. I have done 30 years of curlys and ends, and always hated python. I thought I hated python because of the indenting, but that ended up not to be true. I'm Nimming for over a year now, and I'm still in love. I just stopped caring about it altogether. Indenting and weird case handling only matter on the surface - your eye and mind just adapt to the new shapes and
21:01:40FromDiscord<allochi> how does the editor know?
21:01:41Zevvflow of code, making these details irrelevant.
21:02:12Araqallochi: how does the editor know when you got the 'end' wrong. same problem
21:02:27FromDiscord<allochi> I would know
21:02:32Araqin fact, I've seen code with curlies where the indentation was correct and the curlies weren't
21:02:49FromDiscord<allochi> I'm not talking about indentation here...
21:03:09FromDiscord<allochi> if I outsource some code, or do code review...
21:03:25FromDiscord<allochi> how do I know what the programmer intended?
21:03:54Araqexactly. You don't. And the redundancy can bite or help.
21:04:21Araqit helps when it agrees with the indentation. It bites when it doesn't and you're left to wonder whether the curlies or the indentation are correct
21:05:15FromDiscord<allochi> Ok, this is a deeper discussion that I don't want to waist your time on, specially that I'm excited about the things that you are doing on the memory level 😉
21:05:31rayman22201soooo.... about threads and shared refs :-P
21:06:52FromDiscord<allochi> but just for the record, I still think that a delimiter would make the code more readable and help in the logic and debugging
21:07:52FromDiscord<allochi> thanks for you time and for listening to me 😃
21:08:09Araqok, and your opinion is valid. But it's not for everybody.
21:08:43Araqunless we do some usability testing we don't have objective facts to sort it out.
21:09:14Araqand Python's popularity is growing so it's not something I lose sleep over.
21:09:25shashlicklanguage syntax is so subjective
21:09:39Araqrayman22201, incorret. the owning thread could free the memory
21:09:48shashlickit's like comparing French with Swahili
21:10:01Araqbefore the thread that borrows is done reading from it
21:11:02rayman22201So the owning thread would have to check RC == 0 before it can call dispose()
21:11:36rayman22201And RC would have to be atomic of course.
21:12:01Araqit seems wiser to check for RC == 0 when you pass the ref to a different thread
21:12:11Araqand not afterwards
21:12:16Araqor anything like that.
21:13:18rayman22201I could see a situation where you would want many reader threads, and a single writer thread for example.
21:17:14rayman22201Strict ownership passing between threads is definitely safe, but it's conservative, in that it does not allow the multi reader case.
21:17:54*krux02 joined #nim
21:18:44jasomTo clarify: there is no way to set a non-zero initial value for a thread-local variable?
21:18:52*jjido joined #nim
21:19:15jasomor can I even not rely on thread-local variables being zero?
21:19:37*narimiran quit (Ping timeout: 244 seconds)
21:20:54Araqyou can rely on zero initialization for thread local variables
21:36:13*vlad1777d joined #nim
21:49:44Araqrayman22201, it's mostly about the memory management. once you can share the memory you still need to use locks on top or atomics
21:50:11Araqyears ago we added .guard to prevent races and locks: <locklevel> to prevent deadlocks
21:50:50Araqthese features are mostly unused. Why? because threading itself is underused in Nim. Why? because the heaps are not shared.
21:52:07*NimBot joined #nim
21:52:14Araqfor me this is the final piece of the puzzle, not the full puzzle
21:59:13sealmoveis this https://github.com/nim-lang/Nim/wiki/Destructors still work studying? or upcoming revision will differ too much?
22:00:25Araqit's reasonably up-to-date
22:05:01sealmoveCan you please explain what the situation will look like afterwards? As I understand it, destructors will look like an extra language feature. So GC code will stay the same, but users can choose a different runtime and work with some extra rules/different reasoning. Is this accurate?
22:05:47sealmoveOf course these new rules will be simpler than Rust's, but will they be *forced* to the user? Or simply an alternative?
22:06:29Araquh that's
22:06:38AraqI don't even know how to start
22:07:26Araq1. there are destructors, they are reasonably stable on devel. You can create shared pointers, your own seqs etc. it works quite well.
22:07:50*livcd quit (Ping timeout: 250 seconds)
22:08:23Araq2. then there are ideas about how the builtin seqs/strings should be destructor based. That's vaporware
22:09:12Araq3. then there are more ideas about how ref should be destructor based.
22:09:51Araq(3) makes things easier than (2) because there is no GC to interop with
22:11:08Araqand the rules about destructor injections are not for the average programmer. You just write the Nim code like before.
22:11:19sealmoveIs it possible to make built-ins destructor-based for effeciency, but still use GC for user's code?
22:11:52Araqyeah, it's all possible but we have to be careful that we don't end up in a combinatorial explosion
22:12:00sealmoveoh so it's all implementation details, no changes in language rules
22:12:29sealmovewhat do you mean combinatorial explosion?
22:12:46Araqthe changes in the language rules would be the 'owned' keyword.
22:13:19Araqthe 'lent' and 'sink' keywords are optimizations.
22:13:28sealmoveah good to know
22:14:17AraqI suck at getting the points across
22:14:33Araqoh well, tomorrow I'll update the *manual*
22:14:48Araqwhich documents what we ended up with.
22:15:05sealmovegreat!! really looking forward to it
22:15:57Araqcombinatorial explosion means that the quality suffers when we allow for too many options
22:15:58FromDiscord<moerm> Hello all
22:16:12Araqhi moerm
22:16:19rayman22201"for me this is the final piece of the puzzle, not the full puzzle" Fair enough. All good points.
22:16:32FromDiscord<moerm> Araq Are you still open (really open) re your article (which I liked a lot) or is it basically decided?
22:17:03AraqI'm always open
22:17:15FromDiscord<moerm> (Oh and: Thanks god that you didn't take the "Pony" route)
22:17:36Araqthe article is a start. Then I will put it into an RFC
22:17:54FromDiscord<moerm> Araq Nice. Because I have an "attack" on you, a quite (but not sooo different) concept that I find simple and elegant
22:18:26Araqbut as I expected it's easy to dismiss it all. We need a prototype implementation or better than prototype before we can start to hate it.
22:18:27FromDiscord<moerm> But please, tell me right away if you are ready to only discuss details of "how" but not the "what"
22:18:48Araqjust say what you have to say. :-)
22:18:56FromDiscord<moerm> Hate? No! I do not hate it at all
22:20:12Araqcome on, I'm curious
22:20:28FromDiscord<moerm> Idea: something like auto-deferred disposal with an explicit "keep" option. Without keep the lifetime of anything on the heap is the current scope. And main silently ignores all keeps and disposes whatever is still alive
22:21:12FromDiscord<moerm> My reasoning is that I basically dislaike all the common routes. They address this or that problem but there's no elegance and it grows and gets more complicated
22:22:05FromDiscord<moerm> Why do devs like stack vars? Because they are self cleaning. And exactly that is what we should strive for heap vars too (except when expressly need with a longer life time)
22:23:24FromDiscord<moerm> Anything referencing a ref or ptr (your "dangling example) is disposed at the end of the proc
22:23:37FromDiscord<moerm> No troubles.
22:23:49Araqsounds like region based memory management
22:23:58FromDiscord<moerm> Plus: Something like your "owned" approach for multithreading
22:24:13FromDiscord<moerm> Yes, it is region based mm but slightly refined
22:24:15sealmovebut... the new rules will be able to do something even more intelligent. If you use the var outside of the scope, then the compiler will know how to adapt. Isn't that the whole idea./
22:24:25*livcd joined #nim
22:24:29Araqdo you know that Ada has a separate data stack for return values?
22:24:51AraqI learned that only recently, that's how you can return variable sized data in Ada
22:25:02FromDiscord<moerm> I'm worried about "can be *usually* (or "mostly") statically verified and I'm worried by the compiler having way too much to do
22:25:18FromDiscord<moerm> Araq Of course I know that (Ada)
22:25:48FromDiscord<moerm> Nope. We can do MORE uing the second stack * grin * e.g. auto deferred cleanup
22:25:55sealmovethe `keep` thing doesn't sound bad, but it sounds like a limited version of lifetime annotation.
22:26:20sealmoveit solve some cases, not all
22:26:24FromDiscord<moerm> If something is "uually" stat.verif. it's worthless. Verif must deliver 100% - at reasonable cost! - or it's worthless
22:27:01FromDiscord<moerm> sealmove nope. It's a "programmers override"
22:27:36FromDiscord<moerm> Araq and, frankly, nice as your approach looks (it really does) I think you'll run into verification problems and high cost
22:27:38Araqmoerm: heaps are complex to verify. Spark doesn't do it and Z3's support for separation logic is limited
22:27:38sealmoveah, you mean keep the idea same, but have option of using `keep` to be more explicit when you want?
22:28:34FromDiscord<moerm> Araq YES they are (difficult to verify). I've played enough ugly games with seperation logic * sigh* It's a pain. -> hence: let's look for elegance, for simplicity
22:29:04sealmovewell, programmer and compiler have to cooperate. both have to figure out stuff, it's all about that balance!
22:29:11*vlad1777d quit (Ping timeout: 250 seconds)
22:29:21sealmoveif you make it too simple for the programmer, it's too hard for the compiler, and vise-versa
22:29:30FromDiscord<moerm> And btw. if played smartly my approach also allows for *easy and elegant* and cheap ref checking
22:29:45Araqwell it's all lipstick on a pig, you don't get elegance with 'ref'. You get it with value based programming and moves.
22:29:56FromDiscord<moerm> seal Pardon my frank words but I'm concentrated on talking wioth *Araq*
22:30:16sealmovemoerm: right, sorry, I'll shut up :p
22:30:33FromDiscord<moerm> Araq nope, I mean anything that references a heap object (let x= someHeapObject)
22:30:56Araqmoerm: I actually have a pretty good idea about how to prove it but I have the nice fallback with runtime checks.
22:31:07FromDiscord<moerm> I've already thought about some implementationconcepts
22:31:18AraqSo the prover can advance independently of the language
22:32:02FromDiscord<moerm> You know what's the best verif? The one that isn't needed *g
22:32:10Araqanyway, write a short article about your idea
22:32:26AraqI doubt it will get the thinking it deserves otherwise
22:32:52FromDiscord<moerm> I'll try my best to find some time to write a small article
22:33:04Araqeven bullet points will help
22:33:11FromDiscord<moerm> And: THANKS for your openness, friendly dictator 😉
22:34:05FromDiscord<moerm> And yes, I'll confess it: I *love* it when Nim pulls ahead of other languages with some smart approach (usually by ou, Araq)
22:34:53Araqlol how about we release v1 and do the --newruntime for v2
22:35:06Araqin the compiler it's name optNimV2 fwiw
22:35:43*stefanos82 quit (Remote host closed the connection)
22:36:05FromDiscord<moerm> I'm not worried. Nim is easily good and interesting enough already for V1 (modula a bit cleaning and some small repairs)
22:36:19Araqyou're right that most of the time the heap is used when it doesn't have to
22:37:25FromDiscord<moerm> Araq I wouldn't even go that far. My point is mainly that we should make the heap to be as eay to use - but still safe. And preferably with a high proof load
22:37:47Araqbut that line of thinking gave us the thread local heaps. "Ok, it needs to be variable sized. But there is no reason to share it ffs"
22:38:04Araq;-)
22:38:06FromDiscord<moerm> And: You are perfectly right and I was grinning when you mentioned Ada's "2nd stack"
22:38:36Araqit's new to me. When I used Ada I didn't know about it.
22:38:54FromDiscord<moerm> I think thread local heaps are a very nice approach.
22:38:57rayman22201Araq, As much as I LOVE the direction you are going with this, I have to second the notion that V1 should probably come first...
22:39:14rayman22201just from a business perspective
22:39:32FromDiscord<moerm> rayman I think that's undisputed und unquestioned anyway
22:39:41Araqfrom a business perspective it's all fucked up.
22:39:56Araqit's like "buy our product because the next version will be so much better"
22:39:58FromDiscord<moerm> We *need* V1 and we seem to be quite close.
22:39:58rayman22201Not true. The newruntime was still up for V1
22:40:07Araq- "ok, I'll just wait..."
22:40:23FromDiscord<moerm> rayman hmmm
22:40:47rayman22201The reason Araq has focused on this is because he wanted to see if the new runtime could be put into V1 iirc. Araq can correct me if I'm wrong.
22:41:12sealmovemacros as plugin and compiler API seem more important than --newruntime imo
22:41:20FromDiscord<moerm> I can understand *both* sides, the one that pushes for V1 - and yes, Nim is good enough as it is now - as well as the one that feels that Nim V! should have the new runtime in V1
22:42:17AraqI'll likely end up with some deadline
22:42:31AraqNim v1 is what we have in June
22:43:10FromDiscord<moerm> Araq I think that what we have *now* can stand quite well next to other languages.
22:43:37Araqrayman22201, well it's also because I have grown to hate the GC
22:43:50FromDiscord<moerm> rayman You see, once V1 is out, it will be very hard to change something as core as heap/ref/ptr without breaking lots of code
22:44:30rayman22201Don't get me wrong. I really want the newruntime. I also hate GC's and love deterministic memory management
22:44:36FromDiscord<moerm> Frankly, I think that a GC - no matter which one - is a crook and not the solution
22:45:12FromDiscord<moerm> Expensive, hard to verify/proof and always some cases slipping through some hole
22:45:32AraqI don't even mind GCs in theory and for Nim's compiler development, it was the right choice. It probably still is.
22:46:01FromDiscord<moerm> I'll try to hurry with my article. One good news is that my model is *really* simple (translation: Probably feasible till June)
22:46:04rayman22201We could also take the Haskell approach. "We will pretend we are a research language and not care about such silly things" :-P
22:46:20FromDiscord<moerm> NO!
22:46:35FromDiscord<moerm> Nim is a *practical* language and I love it for that!
22:46:48rayman22201I did say *pretend*
22:46:52Araqwell you can argue that Nim's multi threading story really is bad enough to justify the delay
22:47:20rayman22201this is true... It is one of the biggest flaws with nim right now.
22:47:32FromDiscord<moerm> Funny btw. We are fumbling and make hifting with memory management since DECADES and we went functional, we tried diverse GC approache and it's still not really satisfying
22:48:05FromDiscord<moerm> rayman Thanks for the "pretend". I was afraid for a moment that you were serious
22:48:47Araqrayman22201, as I said in principle --newruntime is easier than --gc:destructors as it's a unified approach
22:49:03Araqso I'm optimistic we will have a prototype by the end of April
22:49:21Araqyou can look at it today
22:49:25rayman22201I like when Araq is optimistic :-)
22:49:43Araqruntime_v2.nim is 98 lines of code
22:49:55Araqgc.nim is 876
22:50:09Araqif that's not objective progress then I don't know what is
22:52:11FromDiscord<moerm> I agree. We shouldn't worry before mid of may about V1 getting late. And I think Araq ha *earned* some trust
22:53:33FromDiscord<moerm> - away for about 30 mins -
22:54:14shashlickAraq, again the point I raised earlier in a different way - why not standardize on boehm which seems well integrated and performant and stop efforts on gc.nim
22:55:14shashlickit doesn't take away from the newruntime or destructor improvements but provides existing users with a thread friendly route
22:56:21Araqshashlick, wise words, cannot disagree. I do know however, that most language implementations start with Boehm and then use their own GC because of Boehm's impreciseness
22:58:04Araqand IMO sockets and files and channels have become more common, not less. So the argument that they can easily be handled manually doesn't convince me
22:59:49Araqif I lose the general graph handling and gain a mechanism that can close my sockets too I'll happily do the trade and won't look back
23:00:59jasomAny idea why a loop inside of a try/finally seems to have per-iteration overhead? Example here: https://pastebin.com/0kbHRXA4 ; when built with -d:release bar() and baz() have similar performance characteristics, but foo() is repeatably slower.
23:01:32shashlickokay I won't claim to understand all of that but based on my real world experience with feud, i wrong usage of shared memory suddenly works correctly with boehm
23:01:33Araqjasom, use 'nim cpp' for performant try-finally
23:02:21shashlickso for encouraging the use of threads, it seems like a simple route
23:02:42Araqyeah, definitely.
23:03:15shashlickalso I know you have said in the past that you have wasted lots of time debugging gc bugs, i presume that's in the nim native gc and not boehm
23:03:27shashlickso just curious if it can be made the default
23:03:48shashlicklike if you have --threads:on then boehm becomes the default
23:03:59Araqwell crashes in Boehm also existed
23:04:01jasomAraq: interestingly enough, making the body of the try a single function call eliminated the per-iteration overhead (see bar() in my example)
23:04:26Araqjasom, yeah we need to put locals into 'volatile' for try-finally
23:04:36Araqand that kills optimizations
23:04:38jasomoh, that explains it
23:04:58Araqwe need to do that because the C spec is insane
23:05:39Araqshashlick, and when Boehm crashes you have a nice black box and you ignore it and use Nim's native GC...
23:11:19jasomFWIW the non-shared heap was one of the things that attracted me to nim.
23:12:18Araqit was attractive. And then I ported TLSF to Nim to fight the fragmentations.
23:13:02Araqand then I felt that with all this complexity I might as well implement a shared heap
23:13:30Araqand then I noticed that even GPUs have malloc()
23:15:32Araqthread local heaps are nice but they also gave us a .gcsafe effect and the inability to protect anything with locks
23:16:03Araqand I love locks :-)
23:16:32Araq(yeah yeah, so sue me, I love locks)
23:20:21sealmovenim likes locks too
23:20:31sealmovethey can be hidden neatly with macros
23:20:54FromDiscord<moerm> <- loves (smart) locks too
23:21:16sealmovethey are ugly in java but they don't have to be in nim
23:23:17*arecacea1 quit (Read error: Connection reset by peer)
23:23:35*arecacea1 joined #nim
23:26:04*chimez joined #nim
23:27:58*sentreen quit (Quit: WeeChat 2.3)
23:28:07*sentreen joined #nim
23:29:15*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:29:44*solitudesf quit (Ping timeout: 250 seconds)
23:29:54*jjido joined #nim
23:36:33*skaruts quit (Ping timeout: 256 seconds)
23:36:55jasomAraq: only dynamically allocated things can't be protected with locks, right?
23:37:52*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:39:28FromDiscord<moerm> Uhm, why do you think that??
23:39:46*Cthalupa quit (Ping timeout: 246 seconds)
23:40:28Araqjasom: yes.
23:40:30*ng0 quit (Quit: Alexa, when is the end of world?)
23:40:31*Cthalupa joined #nim
23:40:44Araqmoerm: He means that .gcsafe feature.
23:42:09*Daniel70 joined #nim
23:43:34Daniel70https://nim-lang.org/araq/ownedrefs.html
23:43:52Daniel70"Unowned refs are reference counted. When the OWNED ref disappears it is checked that no dangling ref exists; the reference count must be zero."
23:44:11Daniel70Shouldn't it be UNOWNED ???
23:44:33Araqno. why?
23:45:03Daniel70My mistake then
23:45:16Daniel70I'll read it again from the start
23:45:25Araqhttps://researcher.watson.ibm.com/researcher/files/us-bacon/Dingle07Ownership.pdf probably explains it better
23:45:44jasomIf the owner goes away, there better not be any readers left...
23:46:11Araqlook, this is not even my design. I merely found it and consider it the best design so far, all things considered
23:46:33Daniel70Already downloaded from the article link, thanks !!
23:47:55FromDiscord<moerm> The big problem with pony's iso, trn, etc. is that they are just six - but a week has *seven* days!
23:49:09Araqno the big problem with Pony is the actor model.
23:49:47FromDiscord<moerm> You mean *how* they implement it, I guess
23:50:07Araqno the model itself is quite flawed.
23:50:38Araqcan an actor die? if so, what happens to the message that you sent to it? can every message fail?
23:50:40*rnrwashere joined #nim
23:50:58Araqthat's already much more complex than a function call.
23:51:08FromDiscord<moerm> In a way. But still one of the more interesting approaches (albeit not really thought through)
23:51:34Araqyou don't write distributed systems because they are cool. You write them because you have to.
23:51:45FromDiscord<moerm> YES
23:51:59FromDiscord<moerm> But unfotrunately, sometimes one really must
23:52:48FromDiscord<moerm> Btw. another point that has me thinking sometimes: async/await and (OS) callbacks
23:52:53Araqok but then why do you have 10_000 actors on a single machine, seems to me one wrote it because it's cool
23:53:32FromDiscord<moerm> But that pretty much exactly what Pony is marketing on
23:54:05FromDiscord<moerm> I'll put it like thi: There' a reaon why Pony doesn't take off ...
23:54:19FromDiscord<moerm> Too much complexity for something not really needed
23:55:01FromDiscord<moerm> Anyway the whole field of parallelism and concurrency is widely mis- or not well undertood
23:55:06Araqit's too early to tell. But it means I won't steal features from it
23:55:13FromDiscord<moerm> *g
23:55:50FromDiscord<moerm> Not really, Araq. Pony will *not* take off. Not that a killer was needed but Go draw away most potential users
23:55:56*Daniel70 quit (Quit: Page closed)
23:56:22FromDiscord<moerm> (Btw. Go IMO i one of the most overrated languages of all times)
23:57:18AraqThere is much to learn from Go. And I don't like Go at all and find it depressing.
23:58:13FromDiscord<moerm> As for Nim, very frankly, I think the "problem"/situation is very different. Funnily most loving it don't really understand it and basically see it as a mix between "friendly C" and "fast Python". Only quite few (I assume) *really understand the mind-set behind Nim and value it for that.
23:59:05FromDiscord<moerm> Sorry but I disagree. There *seems* to be a lot to learn from Go but actually there is very little. And yes, Go smells (or as you would call it is depressing)
23:59:44FromDiscord<moerm> Anyway, no strong typing -> I don't care *at all* about a language (e.g. Go)
23:59:58federico3Araq: what do you refer to?