<< 15-04-2019 >>
00:06:33*rnrwashere joined #nim
00:07:37*Snircle joined #nim
00:10:50*rnrwashere quit (Ping timeout: 250 seconds)
01:17:21*I_Right_I quit (Remote host closed the connection)
01:32:25*rnrwashere joined #nim
02:07:05*banc quit (Quit: Bye)
02:17:07*abm quit (Read error: Connection reset by peer)
02:28:08*banc joined #nim
02:40:48*rnrwashere quit (Remote host closed the connection)
02:42:11*[rg] left #nim (#nim)
02:52:26*rnrwashere joined #nim
02:57:24*rnrwashere quit (Ping timeout: 268 seconds)
03:24:58*rockcavera joined #nim
03:31:09*rnrwashere joined #nim
03:43:44*rnrwashere quit (Remote host closed the connection)
03:44:14*rnrwashere joined #nim
04:25:47*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
04:37:39*nsf joined #nim
05:08:11*rnrwashere quit (Remote host closed the connection)
05:08:28*rnrwashere joined #nim
05:10:17*narimiran joined #nim
05:13:46*rnrwashere quit (Remote host closed the connection)
06:01:12*solitudesf joined #nim
06:02:58*krux02 joined #nim
06:59:23*dddddd joined #nim
06:59:51*solitudesf quit (Ping timeout: 255 seconds)
07:00:00*gmpreussner quit (Quit: kthxbye)
07:05:00*gmpreussner joined #nim
07:20:17*shomodj joined #nim
07:20:54*fanta7531 joined #nim
07:23:03leorizeAraq: looks like koch is working with newruntime, but I spotted a memory corruption bug
07:24:22leorizeif you run `./koch temp`, it will error out at the end due to a `setCurrentDir` error, due to the string used was corrupted
07:29:32Araqleorize, problem is that koch.nim is pretty bad test as it's an "interactive" program
07:30:03Araqcan you extract the corruption into a real test case?
07:31:18leorizeI'll try
07:31:19FromGitter<alehander42> Disruptek linguist is in progress still wip
07:31:23FromGitter<alehander42> Linguist
07:31:29FromGitter<alehander42> Languist '
07:31:40FromGitter<alehander42> We are talking on rubykaigi about it
07:32:01FromGitter<alehander42> After several days so there is a nim related talk on a Rubicon
07:32:05FromGitter<alehander42> Rubyconf
07:32:11FromGitter<alehander42> Soon
07:33:19Araqleorize, also valgrind and the clang sanitizers work out of the box with -d:useMalloc
07:34:04Araqand that alone means the --newruntime is doomed to be a success :-)
07:40:22*solitudesf joined #nim
07:46:11*JustASlacker joined #nim
07:56:52*clyybber joined #nim
08:04:09Araqalehander42: what is Linguist?
08:04:54FromGitter<alehander42> So if anybody has any ideas for slides about nim for ruby audience feel free to write me
08:05:02FromGitter<alehander42> Araq
08:05:17FromGitter<alehander42> A general version of py2nim
08:05:38FromGitter<alehander42> Supporting more input/output languages
08:06:22Araqmeh
08:06:50FromGitter<alehander42> https://github.com/metacraft-labs/languist
08:06:50Araqpy2nim is already super hard to do
08:07:16Araqmake it more general and it becomes even harder
08:08:16FromGitter<alehander42> Well hard problems are interesting
08:08:37FromGitter<alehander42> I think applying it for some projects makes sense
08:08:48FromGitter<alehander42> Most libs are harder to translate
08:09:09FromGitter<alehander42> But a lot of tools and Web Apps etc which mostly use stdlib and existing dsls
08:09:18FromGitter<alehander42> Are way more adaptable to translation
08:09:34FromGitter<alehander42> Especially with good rewriting rules mechanism
08:09:58FromGitter<alehander42> With which one can add easily project specific patterns
08:10:15Araqah
08:10:24Araqthat makes sense
08:11:00FromGitter<alehander42> E.g. In fast-rubocop
08:11:26clyybbernim -> befunge when??
08:11:36*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:11:38FromGitter<alehander42> We replace some dsl with invocations of compile time nim dsl
08:12:10FromGitter<alehander42> And parser lib with a treesitter+adapter
08:12:36FromGitter<alehander42> And some other infrastructure and translate the~ 500 checkers
08:12:40FromGitter<alehander42> Based on them
08:13:42FromGitter<alehander42> Most of them are not fully correct translations but a lot of them should leave small manual fixes to be done
08:13:58FromGitter<alehander42> (and eventually most of them should just work but win)
08:14:02FromGitter<alehander42> Wip'
08:15:06*chickendan joined #nim
08:15:11clyybberleorize: Looks like the corruption issue happening to me too.
08:15:30livcdalehander42: wow! Nim is going to be on RubyKaigi?
08:15:48Araqclyybber, btw your cast patch should also be done for tyString
08:16:07AraqI think
08:16:24clyybberAraq: Somehow it works without checking for etyp.kind in {tySequence, tyString}
08:16:41clyybberThe string gets treated like a tySequence somehow.
08:16:56AraqI'm pretty sure that doesn't happen
08:17:15clyybberIt fails with strings without my patch.
08:17:23clyybberSo my patch must have done *something*
08:17:51Araqwell there is source.typ and dest.typ
08:17:58Araqfor every conversion/cast
08:18:13Araqif you cast *to* seq it should work
08:18:22clyybberAh, I got it.
08:19:08Araqbefore I wrote Nim I thought C's "cast" means the compiler/optimizer needs to give up
08:19:40Araqcompletely wrong, lol, the compiler can look at the involved types and continue with what it needs to do
08:20:20clyybbergcc's smart
08:20:31clyybberAraq: Should I send a PR fixing it?
08:20:42Araqwhy do you think I told you? :P
08:20:49clyybber:D
08:21:39Araqand then get this new runtime to work. I'm working on the mover analyser, your job is porting 100_000 lines of Nim code over to the new runtime. Deal?
08:22:47FromGitter<alehander42> Livcd
08:22:54FromGitter<alehander42> Yes indeed
08:23:02FromGitter<alehander42> At least some of the talk
08:23:23FromGitter<alehander42> Zahary and me will talk
08:23:43FromGitter<alehander42> So if you have ideas for slides stuff that would impress ruby politely
08:26:32Araqwell it's Ruby, show some web framework and web benchmark numbers
08:26:52Araqand Ruby's DSLs are nice and can also be done with Nim
08:26:54FromGitter<alehander42> Araq but shouldn't the language require type conversion when it needs to do such logic
08:27:20Araqwhat? this question came out of nowhere
08:27:38Araqwhat's the context?
08:28:35FromGitter<alehander42> You wrote something about cast and compiler giving up
08:29:00FromGitter<alehander42> OK we have benchmarks of our Rubicon prototype not of Web stuff
08:29:18FromGitter<alehander42> But we might show how Web dsls look in Jim
08:29:22FromGitter<alehander42> Jim
08:29:24FromGitter<alehander42> Nim
08:29:41Araqwhat about it? the type conversions can be implicit or explicit, if they are implicit then they are explicit after sem'check, no biggie
08:33:44*kapil____ joined #nim
08:36:26*floppydh joined #nim
08:45:18clyybberAraq: Why are openArray and varargs handled differently in genSomeCast?
08:45:46clyybberI mean special cased as opposed to seqs for example.
08:47:15*shomodj joined #nim
08:51:45Araqbecause openarray is special, it's an unnested (ptr, len) pair
08:52:07*leorize quit (Ping timeout: 240 seconds)
08:53:42*chickendan quit (Ping timeout: 255 seconds)
08:53:55clyybberah, ok.
08:56:39*leorize joined #nim
09:06:05clyybberleorize: Is the corrupion issue an regression?
09:08:13*Vladar joined #nim
09:11:15leorizeclyybber: no idea
09:11:43Araqprobably not, I declared victory when I got 'koch boot -d:release' to run :P
09:18:49ZevvI get "Error: system module needs: nimGCvisit" when doing some experiments with the new runtime. Should I just sit on my hands a few weeks before doing this?
09:19:29AraqZevv, or you fix it
09:19:54Araqit means your code uses something that the newruntime doesn't support and we need at least a better error message
09:20:04AraqI've done first steps for this with system.repr
09:20:16Araqwhere the compiler should now produce a decent error message
09:21:31*shomodj quit (Read error: Connection reset by peer)
09:24:25Zevvok, clear
09:35:16Araqthe stack trace of 'koch temp c --newruntime foo.nim' should give you some hint why the codegen thinks it requires RTTI
09:39:20Zevvyeah, I just figured out it is triggered by a {}.toTable()
09:41:07Araqhuh?
09:41:14Araqso weird :P
09:42:29Zevvoh shoot, that was the other error: `t.destructor != nil`. Well, I'll see how far I can get. Thanks for the hint
09:44:47Araqah that error can't be hard to fix either... bah why is everything so hard
09:50:05*couven92 joined #nim
09:50:32*fredrik92 quit (Quit: Client disconnecting)
09:52:03*shomodj joined #nim
09:52:45*abm joined #nim
10:07:45*chickendan joined #nim
10:11:34clyybberAraq: https://github.com/nim-lang/Nim/pull/11031 is ready.
10:12:42*xet7 joined #nim
10:26:17*lritter joined #nim
10:34:34Araqclyybber, wanna give https://github.com/nim-lang/Nim/issues/11014 a try?
10:35:53*fanta7531 quit (Quit: fanta7531)
10:37:45Zevvjust looking into that one ,but kind of stuck
10:38:11Zevvit is related to tables.nim:enlarge(), but I don't understand why
10:38:53Zevvminimal code to reproduce: var e = initTable[char, bool](); e['a'] = true
10:39:27Araqmaybe it's 'swap' that triggers it?
10:41:27ZevvIf I throw everyting out except "var n: KeyValuePairSeq[A, B]", the error is still there
10:41:38Zevvthat's where I got stuck
10:43:47Araqhmm
10:48:38clyybberAraq: Sure
10:49:17clyybberHow do I pretty print PTypes and PNodes again? I forgot, and using repr reaches the call limit
10:51:46Araqecho $n, " ", $t
10:51:59Araqthere is also debug(x) but that's information overload
10:52:36clyybberthanks
10:53:17*dddddd quit (Remote host closed the connection)
10:56:19*stefanos82 joined #nim
11:03:14*al_ joined #nim
11:03:21*al_ quit (Client Quit)
11:15:04*xet7 quit (Quit: Leaving)
11:32:44krux02clyybber, I wrote `debug` to print as much information as it can find without duplication. That is an overload, but it is also written in a way that minimal changes can reduce the output to what you are really looking for.
11:34:07krux02for example you might want to change ``this.renderSymType = true`` to ``this.renderSymType = false`` in astalgo.nim:602
11:34:42clyybberkrux02: Thank you, debug serves me well :D
11:35:07krux02good to hear
11:35:22krux02you are welcome
11:35:35krux02I try to make the output of debug as easy to understand as possible, but it is verbose
11:38:28krux02The idea behind it is, turning things off that you don't want is easy, trying to ignore the output to filter for what you are actually looking for is doable, fixing ``debug`` to provide information that you actually need when it is not printed at all is hard.
11:38:38krux02so it's verbose by default
11:41:26Araqif I say debug(n) I don't want debug(n.typ), if I need debug(n.typ) guess what I would have typed
12:25:35clyybberAraq: `swap` is not the problem
12:25:50clyybberits the generic type parameters
12:26:51ZevvKeyValuePairSeq
12:26:59Zevv[A,B]
12:29:01clyybberthis is really weird...
12:29:16clyybberseemingly unrelated code happens to create the error in conjunction
12:30:47clyybberZevv: I got a minimal test case:
12:30:49clyybberhttps://hastebin.com/agulanemob.md
12:31:32clyybberThe funny thing is, if you remove `var e = initTable[char]()` it compiles fine.
12:31:34Zevvindeed, I got to something similar.
12:31:38Zevvyes
12:31:57clyybbereven though my enlarge proc doesn't touch `e` in any way
12:32:08clyybberthis is beyond science
12:32:35Zevv11:44 <@Araq> ah that error can't be hard to fi
12:32:39Zevvx
12:33:01Zevvif it's beyond science, give it back to Araq :)
12:33:32clyybberAgree :D
12:33:38clyybberHave fun, Araq.
12:33:45clyybberjk
12:33:52Zevvclyybber: put your snippet in the issue
12:33:55clyybberbut I have no idea how to fix this
12:34:01clyybberZevv: What issue?
12:34:11clyybberThe .toTable one?
12:34:17Zevvyeah
12:34:34Zevv11014
12:37:06clyybberdone.
12:37:23Zevvyou can even replace the body of initTable with discard
12:37:26Zevvand it still barfs
12:37:30clyybberlol
12:37:34clyybberwth
12:39:39*Snircle joined #nim
12:39:54Zevvyou can take out the tuple as well
12:40:20clyybberyou can take out the generic parameter of enlarge out as well.
12:41:25Zevvand the *call* to enlarge
12:41:54*clyybber and Zevv are slowly digging their way to the true core of the universe
12:42:14Zevvhttp://paste.ubuntu.com/p/2y7tgmb9ss/
12:43:05clyybberZevv: Thats exactly where I'm at too :)
12:43:11*narimiran_ joined #nim
12:43:34clyybberwhats funny is that if you call enlarge but replace its body with discard, it works again.
12:43:34Zevvbug golf
12:44:06*narimiran quit (Ping timeout: 255 seconds)
12:51:08clyybberAraq: This is getting weird: https://github.com/nim-lang/Nim/issues/11014
12:51:48clyybberhttps://github.com/nim-lang/Nim/issues/11014#issuecomment-483233954
12:57:07FromGitter<mratsim> seems like a variable assignment bug with generic destructors :P
12:58:25*chickendan left #nim ("Left")
13:01:06clyybbermratsim: Happens with let too, though.
13:01:35FromGitter<mratsim> I meant variable as memor location, not var vs let
13:03:13clyybberoh
13:50:13*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
14:00:36*Cthalupa quit (Ping timeout: 255 seconds)
14:02:06*narimiran_ is now known as narimiran
14:09:08Araqclyybber, check the logic:
14:09:09Araqlet h = sighashes.hashType(orig, {CoType, CoConsiderOwned})
14:09:09Araq var canon = c.graph.canonTypes.getOrDefault(h)
14:09:15Araqin liftdestructors.nim
14:10:19Araqit's only hard if you didn't write the original implementation :P
14:11:17Araqit picks the "wrong" canon type, the one where t.destructor is still 'nil'
14:11:58FromGitter<mratsim> "hard if you didn't write the implementation" is usually synonymous with poorly documented and tested :p
14:13:29Araqyou can document it all you want, in the end nobody reads it
14:13:47Araqlife is too short to read code
14:21:11*Trustable joined #nim
14:23:15FromGitter<alehander42> Life is too short not to read code but I document badly too
14:23:32FromGitter<alehander42> I have no idea how I have mobile net here
14:29:01Araq100_000 LOC is roughly a book with 4000 pages. Nobody reads that.
14:30:07Araqok, maybe 2500 pages, but still
14:30:16FromGitter<alehander42> Eh you can read parts of it
14:30:24FromGitter<alehander42> When you debug or look at the arch
14:30:27Araqwhich parts?
14:30:35FromGitter<alehander42> You never know what would be useful
14:30:42FromGitter<alehander42> I am talking in general
14:30:46FromGitter<alehander42> Which project is this
14:32:01FromGitter<mratsim> I like putting thoughts in my code, especially on datastructures
14:32:04Araqwhat do you think liftdestructors.nim and injectdestructors.nim do? how much better should it be documented given that the code seems to be buggy. Do you think the docs would cover the bugs, aka the situations that escaped the writer of the code?
14:32:30FromGitter<alehander42> Well they should
14:32:55FromGitter<alehander42> Again I am not sure about which project this is
14:33:02FromGitter<alehander42> What is 100kloc
14:33:14FromGitter<mratsim> I didn't read the destructors/newruntime code yet
14:33:56*dddddd joined #nim
14:35:14*I_Right_I joined #nim
14:58:36*JustASlacker quit (Remote host closed the connection)
15:20:14*floppydh quit (Quit: WeeChat 2.4)
15:23:35*xet7 joined #nim
15:41:15clyybberAraq: Huh, I see. Made for some really funny bugs
15:53:07Zevvbut what is the fix
15:53:22Araqcanon the type recursively
16:12:48xaceCould someone clarify if there was a disadvantage to using if expressions rather than a if statement? I seem to have a faint memory of it but can't recall what the answer is
16:13:56clyybberyou can conditionally assign some values to a let variable.
16:14:10WilhelmVonWeinerthat would be weird.
16:14:20Araqthe error messages are often more confusing with if-expressions
16:14:33xaceclyybber: but iirc there was something about if expressions being slower than if-statements ? or if the generated C code is more of a mess or w/e
16:14:45clyybberI don't know, sorry
16:15:52clyybberunless the if expr introduces a copy it shouldn't be any slower tho.
16:17:15*cgfuh joined #nim
16:18:06*abm quit (Quit: Leaving)
16:19:42xacehmm, i have grepped over the chat logs a couple of times now and i cant seem to find it, i guess I am wrong and will continue using if expressions where I see fit
16:20:14*rnrwashere joined #nim
16:21:16FromGitter<mratsim> the generated C code is quite verbose especially if it's not a simple expression. For simple expresson the compiler either generates a CMOV or the same code as if statement but when it complex it sometimes miss opportunities for simplification
16:22:06*NimBot joined #nim
16:22:19Calinouyeah, the readability/compactness benefit of if expressions is usually worth it
16:22:25FromGitter<mratsim> You would have cache/memory locality optimisations to do before that ever begins to be a problem
16:22:26Calinou(same for when expressions, which I've found were possible recently)
16:22:53xace@mratsim: oki, thank you
16:22:54Calinouit also encourages you to use more `let` over `var`, yay for immutability :p
16:23:57xaceCalinou: yeah, i like the liberty the language gives for expressing myself :)
16:24:56xace@mratsim: yeah, that is true... still trying to get a feel for the language, but your explination answers my problem
16:25:46FromGitter<mratsim> in short simple if expression will generate C ternary operator, complex sometimes generate goto iirc.
16:27:23clyybberAraq: `elif canon != orig` is always true...
16:27:34FromGitter<mratsim> also C compilers are quite good at optimising if expressions because there is no min/max operator, all min/max are implemented through ternary macros :P
16:28:01clyybberAraq: Even when they look to be the same, at least afaict from an echo.
16:31:12xace@mratsim: I see, your answer makes more sense now :)
16:36:04*xet7 quit (Quit: Leaving)
16:36:42*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:51:13clyybberAraq: Nevermind
16:56:47*rnrwashere quit ()
16:57:41Araqmratsim: we never generate ?: unless it's hardcoded in the codegen
16:58:10Araqbecause C compilers throw away expressions vs statements and operate on a control flow graph
16:58:15FromGitter<mratsim> I'm pretty sure I found some but I may misremember
16:58:39Araqhardcoded for 'len', sure.
16:59:08Araqinterestingly, the Intel compiler can optimize for(;;) but not the while loops we produce
17:02:55clyybberAraq: So how would I canon recursively? Do I just canon the sons too?
17:03:13Araqbefore it dies with t.destructor == nil
17:06:17clyybberAraq: Why is there `var overwrite`? If they are indeed the same, it can't hurt to overwrite them, can it?
17:06:41clyybberor does that count as an optimization?
17:07:05FromGitter<mratsim> doesn't it produce a nop and then a cmp + jnz at the end of the loop?
17:08:16Araqclyybber, optimization, 'ref' incurs a quite expensive write barrier
17:08:54Araqat least for the default GC that the compiler uses for no other reason than to test this GC thoroughly...
17:09:09*lritter quit (Ping timeout: 252 seconds)
17:09:15Araqmark&sweep is faster and Boehm is faster still, theory vs practice.
17:09:35*lqdev joined #nim
17:10:18clyybberk
17:10:51*lqdev left #nim (#nim)
17:11:08*iLiquid joined #nim
17:11:34*shomodj joined #nim
17:11:57FromGitter<mratsim> that's like matrix multiplication. People are looking for algorithm with less than n^3 complexity, but in practice optimising for memory locality trumps every clever scheme found for matrix sizes that fit on a common PC RAM.
17:12:32iLiquidso I got annoyed by Gitter's unread message handling and how buggy it is, I decided to switch to IRC now (this is liquid600pgm, btw)
17:12:41clyybbersame
17:13:11iLiquiddo you recommend any particularly good IRC clients?
17:13:24iLiquidI'm using Srain currently, but it feels pretty unfinished
17:13:26clyybbermratsim: imagine if processors had a way to reliably hint at what should be put into the L caches.
17:13:33narimiraniLiquid: hexchat does the job
17:13:37clyybberiLiquid I'm using weechat.
17:13:43*rnrwashere joined #nim
17:13:47clyybberiLiquid: Are you on linux?
17:13:51iLiquidyes
17:13:54Araqclyybber, it wouldn't make the caches any bigger
17:14:08clyybberNo, but probably more efficient.
17:14:38clyybberWould also allow to handle very distributed data structures optimally.
17:14:46Araqthere are 'prefetch' instructions anyway
17:15:04*iLiquid left #nim (#nim)
17:15:28*iLiquid joined #nim
17:15:40iLiquidalright, trying out HexChat
17:15:45FromGitter<mratsim> @clyybber They have: https://github.com/numforge/laser/blob/master/laser/compiler_optim_hints.nim#L30-L73
17:16:09clyybbermratsim: Just saw that :D Amazing work
17:16:40FromGitter<mratsim> it's particularly useful on hyperthreaded CPU because those can be executed during instruction pipeline stalls.
17:17:10clyybberThats nice.
17:17:29clyybberAraq: Sadly not on many architectures.
17:17:31Araqtoo bad we have to disable hyperthreading because of Spectre :P
17:17:48FromGitter<mratsim> It's helpful on only specific scenario though. When the hardware predictor doesn't know what to prefetch but you do (for example a binary tree)
17:18:00clyybberYeah, exactly.
17:18:11FromGitter<mratsim> if it's prefetching the next element of an contiguous array it's useless :p
17:18:22clyybberHaha, yeah of course.
17:18:31*iLiquid quit (Remote host closed the connection)
17:18:48*ng0 joined #nim
17:18:57*iLiquid joined #nim
17:19:11*iLiquid quit (Remote host closed the connection)
17:19:22*iLiquid joined #nim
17:19:48*iLiquid quit (Remote host closed the connection)
17:20:25I_Right_II like the choice of algorithm for the random number generator :-)
17:20:41I_Right_Iin the stdlib
17:20:59clyybberI just hope Risc-V gets a good prefetching extension: https://content.riscv.org/wp-content/uploads/2018/07/Shanghai-1350_OpenPrefetch.pdf
17:21:21clyybberBut that could be tricky as some implementations dont even have L2 cache.
17:21:35*daknus joined #nim
17:21:41clyybberI_Right_I: xoroshiro is amazing.
17:21:43*daknus quit (Client Quit)
17:23:21*daknus joined #nim
17:23:30*daknus is now known as iLiquid
17:23:31shashlickiLiquid: do you already use some chat like Slack? Matterbridge works very well for me
17:23:34*iLiquid left #nim (#nim)
17:23:38*iLiquid joined #nim
17:23:48iLiquidnope
17:24:02clyybberdark nuss
17:24:03iLiquidI only use Discord, but integration seems pretty sloppy
17:24:14shashlickI get irc, telegram and gitter all pulled into one place in slack
17:24:50*iLiquid quit (Client Quit)
17:25:04*iLiquid joined #nim
17:25:07shashlickBest part is they added nick clean up so no more FromGitter nonsense
17:25:30shashlickDiscord is already bridged here
17:25:48narimiranshashlick: do you have nick-autocompletion?
17:27:19iLiquidI'll stay with IRC for now
17:27:26I_Right_II don't know why nim hasn't drawn more game developers?
17:27:40shashlick@narimiran: nope, cause everything comes from the matterbridge bot
17:27:49shashlickbut this is what it looks like
17:28:32FromGitter<genotrance> (https://files.gitter.im/nim-lang/Nim/TqeA/image.png)
17:31:12FromGitter<mratsim> @Right, I think game developers are the most represented community though
17:31:29FromGitter<mratsim> I mean, even Beamdog is using Nim for Neverwinter Nights 1 enhanced edition
17:34:12FromDiscord<exelotl> I wrote a Discord bot in Nim that can turn a private Discord server into a personal IRC client, where each Discord channel is mapped to a different IRC channel on a different IRC server
17:34:56FromDiscord<exelotl> But that was back on 0.18 and I still need to update it, and also I got a segfault in the nim discord library when I left it running all day :(
17:38:24*fanta7531 joined #nim
17:45:03*cgfuh quit (Ping timeout: 250 seconds)
17:45:14iLiquidI made a little draft for what static typing will look like in rod: https://termbin.com/rsvy
17:45:18iLiquidany suggestions?
17:46:15iLiquidor opinions?
17:46:51*nsf quit (Quit: WeeChat 2.4)
17:47:03iLiquidI'm still not quite sure if I should allow for user-defined operators or just lock them down to a small set of standard ones
17:47:14I_Right_Imratsim: I can see why. I think for game development nim is the perfect use case. And there's a large amount of game engines and libraries that have nim bindings.
17:56:07*rnrwashere quit (Remote host closed the connection)
17:58:31*rnrwashere joined #nim
17:58:39*cgfuh joined #nim
17:59:25*oculuxe joined #nim
17:59:32*oculux quit (Ping timeout: 246 seconds)
18:04:19AraqiLiquid, seems to be messy and ofc I dislike the Go influences :P
18:05:30Araqand why does the return type lose the ':'?
18:08:07*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:09:28iLiquidI thought the syntax is a little cleaner this way
18:09:42*lritter joined #nim
18:09:53clyybberiLiquid a bit more inconsistent though.
18:10:03Araqeither use ':' or '->' for the return types
18:10:21clyybberAraq: Does this go remotely in the right direction towards fixing the bug?: https://hastebin.com/meditoxexu.php
18:10:51*arecacea1 quit (Remote host closed the connection)
18:10:56Araqclyybber, it's not at all what I have in mind
18:11:03clyybberthought so :D
18:11:10clyybberit also doesn't work :P
18:11:19Araqbut it could be some precondition we need
18:11:39clyybberAraq: Well, atm it segfaults at the sons of RootObj..
18:12:03Araqwell not every type has 'sons'
18:12:10*arecacea1 joined #nim
18:12:33Araqand the type recursions in Nim's compiler always get messy because of 'case objects'
18:13:12clyybberAraq: But in the case the object doesn't have sons, shoulndt the for loop just run 0 times instead of segfaulting?
18:13:37Araqno.
18:13:59Araqthe compiler API is not about crash prevention, it's about making you get it right
18:14:55*I_Right_I quit (Remote host closed the connection)
18:15:55clyybberAraq: Got it. I think it workss
18:16:22clyybberat least the snippet that didn't compile, compiles now...
18:19:47clyybberbut we lose that overwrite optimization, and might possibly do unneccessary work...
18:23:26*narimiran_ joined #nim
18:27:27*narimiran quit (Ping timeout: 255 seconds)
18:29:44clyybberAraq: I have a PR up: https://github.com/nim-lang/Nim/pull/11036
18:30:02clyybberwhat approach *did* you have in mind though?
18:31:25*rnrwashere quit (Remote host closed the connection)
18:32:51*rnrwashere joined #nim
18:36:33*Vladar quit (Remote host closed the connection)
18:43:18*fanta7531 quit (Quit: fanta7531)
18:45:39*rnrwashere quit (Remote host closed the connection)
18:53:37*rockcavera quit (Read error: Connection reset by peer)
18:53:55*rockcavera joined #nim
18:54:02Araqclyybber, as I said, when t.destructor == nil, canon(t) and look it up
18:54:43*rnrwashere joined #nim
18:56:09*rockcavera quit (Remote host closed the connection)
18:56:49*rockcavera joined #nim
18:58:10*crem quit (Ping timeout: 268 seconds)
18:59:39*crem joined #nim
19:17:19*narimiran_ quit (Ping timeout: 264 seconds)
19:22:54clyybberAraq: Ah, ok
19:23:55*lritter quit (Ping timeout: 264 seconds)
19:24:03*I_Right_I joined #nim
19:35:45*nsf joined #nim
19:39:46*ng0 quit (Remote host closed the connection)
19:41:00*ng0 joined #nim
19:41:08*rnrwashere quit (Remote host closed the connection)
19:44:32*[rg] joined #nim
19:45:18*shomodj joined #nim
19:51:00*Trustable quit (Remote host closed the connection)
19:55:04*rnrwashere joined #nim
19:56:41*nsf quit (Quit: WeeChat 2.4)
20:04:16*jjido joined #nim
20:09:28*rnrwashere quit (Remote host closed the connection)
20:12:31*kapil____ quit (Quit: Connection closed for inactivity)
20:12:39*rnrwashere joined #nim
20:22:22clyybberAraq: I tried out some different approaches, and have concluded that the one simply canonalizing all subtypes is probably the best one.
20:22:45clyybberIt's actually faster than checking for t.destructor == nil in my test case.
20:23:31clyybberbut that test case is also fairly small.
20:36:18*onionhammer quit (Quit: WeeChat 1.9.1)
20:50:28*rnrwashe_ joined #nim
20:54:03*rnrwashere quit (Ping timeout: 250 seconds)
20:59:45*rnrwashe_ quit (Remote host closed the connection)
21:06:13*smitop joined #nim
21:16:46*al_ joined #nim
21:17:05*al_ quit (Client Quit)
21:34:25*cgfuh quit (Quit: WeeChat 2.3)
21:38:36*rnrwashere joined #nim
21:42:15*iLiquid quit (Quit: iLiquid)
21:42:57*rnrwashere quit (Ping timeout: 250 seconds)
22:10:34*solitudesf quit (Ping timeout: 268 seconds)
22:28:36*[rg] quit (Quit: Leaving.)
22:29:45*[rg] joined #nim
22:30:05*clyybber quit (Quit: WeeChat 2.4)
22:32:45*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:33:39*krux02 quit (Remote host closed the connection)
23:08:55*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:09:09*stefanos82 quit (Remote host closed the connection)
23:18:30*vlad1777d quit (Remote host closed the connection)
23:20:45*vlad1777d joined #nim
23:21:47*shomodj joined #nim
23:33:12FromDiscord<treeform> For the nim GC, will it ever give back memory back to the operating system (so that other processes could use it)? Or will it just accumulate memory in the `getFreeMem()` region?
23:40:16FromDiscord<treeform> According to this post its a NO: https://forum.nim-lang.org/t/4386#27396
23:40:52FromDiscord<treeform> "Freed" memory goes back to the allocator not the OS.
23:48:08*shomodj quit (Ping timeout: 246 seconds)
23:48:55*ng0 quit (Quit: Alexa, when is the end of world?)