<< 07-11-2019 >>
00:00:36*Hideki_ quit (Ping timeout: 268 seconds)
00:04:18*a_b_m quit (Ping timeout: 268 seconds)
00:04:42FromDiscord<krab4t> i feel bad interrupting this conversation, but its not possible to use ` untyped ` in ` templates ` and use ` import ` that file, only ` include ` works?
00:05:19FromDiscord<krab4t> why spiting project to multiple files is so hard in Nim
00:09:39rayman22201krab4t can you show some example?
00:10:52*krux02_ joined #nim
00:13:12*couven92 quit (Quit: Client Disconnecting)
00:13:24FromGitter<mratsim> @brentp open an issue with it in Laser I'll check it out, normally 3 accumulators should be enough because the latency is 3 cycles or 4 cycles for addition (but you can launch 1 every cycle as long as there is no data dependency)
00:13:52*krux02 quit (Ping timeout: 264 seconds)
00:16:26FromGitter<mratsim> I hate when just before sleep I find a super strange compiler bug. I have a variable telling me "cannot instantiate =destroy" for one of its field with a destructor and the way to solve that is to instantiate another dummy variable :/
00:17:32FromDiscord<krab4t> rayman22201 https://pastebin.com/raw/T4BdrsAb
00:23:21*uvegbot joined #nim
00:25:12rayman22201Krab4t did you remember to add the star to export the template?
00:29:32FromDiscord<krab4t> yes, ` Error: undeclared field: 'isNone' `
00:33:22rayman22201From the options module?
00:33:39rayman22201You need to import the options module
00:34:26FromDiscord<krab4t> ` import strutils, parseutils, re, options, typetraits ` :>
00:35:16rayman22201You need to import it in the module you are using the template, (or in the template itself)
00:35:21FromDiscord<krab4t> include works so whatever, should i use ` import ` for splitting files over include in one project?
00:35:36rayman22201You don't understand how templates work
00:36:18FromDiscord<krab4t> agree, vscode extension doesn't help with that either 🙂
00:36:33rayman22201Generally you don't use import, and you don't use import to split a project
00:36:43rayman22201Include
00:37:03rayman22201Bah. Lol 😆
00:37:10disrupteklol
00:37:22FromDiscord<krab4t> what
00:37:24rayman22201Do use import, don't use include lol
00:37:48rayman22201I typed the wrong thing. My fingers were faster than my brain
00:38:05FromDiscord<krab4t> back to typing 100 stars
00:40:06rayman22201It's one character. Would you prefer to type "export" a 100 times? I don't see a problem here.
00:41:33rayman22201And don't tell me "default to public" because that works great for small scripts, but is terrible for maintainable software of any decent size...
00:44:21*xace joined #nim
01:12:32*krux02_ quit (Remote host closed the connection)
01:16:47rayman22201krab4t: sorry for being snarky. Here is a more clear explanation (hopefully): https://gist.github.com/rayman22201/1cfb980293a0a55091a4885f9d39aa5e
01:18:26*uvegbot quit (Ping timeout: 240 seconds)
01:26:07*uvegbot joined #nim
01:27:29*ng0 quit (Quit: Alexa, when is the end of world?)
01:33:04*uvegbot quit (Ping timeout: 264 seconds)
01:36:51*uvegbot joined #nim
01:38:49*druonysus joined #nim
01:38:49*druonysus quit (Changing host)
01:38:49*druonysus joined #nim
01:42:31*druonysus quit (Client Quit)
01:45:46*druonysus joined #nim
01:45:46*druonysus quit (Changing host)
01:45:46*druonysus joined #nim
01:47:20FromGitter<kaushalmodi> Araq: Here's the log from running valgrind: http://ix.io/212I/text
01:48:01FromGitter<kaushalmodi> This error keeps on repeating: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5dc377d1a9f0dc24852bce0e]
01:51:32*druonysus quit (Quit: druonysus)
01:51:39FromDiscord<krab4t> @rayman22201 i got this already thanks
01:51:54rayman22201👍
01:52:23*druonysus joined #nim
01:52:23*druonysus quit (Changing host)
01:52:23*druonysus joined #nim
01:54:40*druonysus quit (Client Quit)
01:55:14*druonysus joined #nim
01:55:14*druonysus quit (Changing host)
01:55:14*druonysus joined #nim
01:58:28*kevin joined #nim
01:58:40*kevin is now known as Guest40599
01:58:58*Guest40599 is now known as kevin-
02:21:38*dddddd quit (Remote host closed the connection)
02:40:18FromGitter<kaushalmodi> I'm going a bit crazy with this GC crash debug ..
02:40:46FromGitter<kaushalmodi> this is the minimal entire Nim code I need to reproduce the crash: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5dc3842da9f0dc24852bce10]
02:41:30FromGitter<kaushalmodi> this proc is exported to a .so and that is then run in a host C application, and that appl crashes if this .so is compiled with default GC
02:41:43FromGitter<kaushalmodi> If I compile with --gc:none, the host application does not crash
02:42:15FromGitter<kaushalmodi> Is that something special needed to be done in pragmas or something for procs that get exported to .so?
02:43:07FromGitter<kaushalmodi> Crash in host C appl: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5dc384bb8fbe1d5faba20045]
02:51:46FromGitter<rayman22201> are you also linking in nimtrl.so?
02:53:24*Hideki_ joined #nim
02:56:41FromDiscord<++x;> `hey guys`
02:56:59FromDiscord<++x;> `last night i had sex and a bubble popped between my leggies`
02:57:01FromGitter<kaushalmodi> @rayman22201 no
02:57:18rayman22201you need to do that
02:57:25*rockcavera quit (Remote host closed the connection)
02:57:28rayman22201nimrtl.so has all the GC procs
02:57:29FromGitter<kaushalmodi> where is nimtrl.so?
02:57:34rayman22201you have to build it
02:57:47FromGitter<kaushalmodi> somebody should have told me all these years!
02:58:00FromGitter<kaushalmodi> instructions please
02:58:05*Hideki_ quit (Ping timeout: 276 seconds)
02:58:07FromDiscord<++x;> `pop my leggies and make me do the splits`
02:58:13rayman22201https://nim-lang.org/docs/nimc.html#dll-generation
02:58:34rayman22201replace `.dll` with `.so`
02:58:36*kevin- quit (Quit: Using Circe, the loveliest of all IRC clients)
02:59:02rayman22201I'm actually surprised you didn't know this @kaushalmodi!
02:59:43FromGitter<kaushalmodi> and all my .so works just fine (except only with --gc:none.. no wonder)
02:59:55*kevin5 joined #nim
03:00:07FromGitter<kaushalmodi> today I sat down to get to the root cause.. and the minimal example reduce to that tiny bit
03:01:23FromGitter<kaushalmodi> so a dummy question..
03:02:03*lritter quit (Ping timeout: 240 seconds)
03:02:20FromGitter<kaushalmodi> 1) I first create nimrtl.so ⏎ 2) Then I ship both nimrtl.so and mylib.so to my team separately?
03:02:31FromGitter<kaushalmodi> can the nimrtl.so not be a part of mylib.so?
03:03:09*lritter joined #nim
03:03:35rayman22201correct. This is because if you were to have mylib1.so and mylib2.so, they both must use the same common nimrtl.so
03:05:03FromGitter<kaushalmodi> what I do is that I have a wrapper libdpi.nim
03:05:13FromGitter<kaushalmodi> in that I import all my Nim libs and pack a single .so
03:05:27FromGitter<kaushalmodi> so theoretically I can just import in the nimrtl too?
03:08:06rayman22201it's fundamentally possible, but the compiler won't let you :/
03:08:19rayman22201nimrtl is condsidered "magic"
03:09:52FromGitter<kaushalmodi> hmm, I am somehow unable to link to libnimrtl.so
03:10:10*oculux quit (Ping timeout: 265 seconds)
03:10:15*oculuxe joined #nim
03:10:44FromGitter<kaushalmodi> I am running `nim c -d:useNimRtl --out:libdpi_64.so --app:lib -d:release libdpi.nim`
03:10:58FromGitter<kaushalmodi> and I have `libnimrtl.so` and `libdpi.nim` in the same directory
03:11:26FromGitter<kaushalmodi> libdpi.so generates fine, but when I do `ldd ./libdpi.so`, I do not see it linked to libnimrlt.so
03:11:37FromGitter<kaushalmodi> (also the same GC based crash still happens)
03:14:20rayman22201warning: I haven't actually used this feature before. We are reaching the limits of my knowledge
03:14:57rayman22201I think @shashlick is probably most familiar with it
03:15:01rayman22201but he is probably sleeping
03:15:41rayman22201I think you may need to call a proc to init the GC at the start of your program
03:16:09FromGitter<kaushalmodi> my Nim lib is not standalone
03:16:17FromGitter<kaushalmodi> I mean, it doesn't run by itself
03:16:34FromGitter<kaushalmodi> it's just a pack of exporc'd procs that are called from the host C appl
03:17:33FromGitter<kaushalmodi> the snippet in https://gitter.im/nim-lang/Nim?at=5dc384110725f61e9c80cd9a is literally the whole Nim code
03:18:16FromGitter<kaushalmodi> but when that proc is called from the host C app (where I link the Nim compiled .so), it crashes
03:20:12rayman22201I understand
03:20:27rayman22201The problem is, all those string operations trigger a GC pass
03:20:30rayman22201but there is no GC
03:21:00rayman22201specifically it attempts to call the GC "mark" proc
03:21:11FromGitter<kaushalmodi> yeah..
03:21:14rayman22201but you haven't included the GC
03:21:23FromGitter<kaushalmodi> now to figure out how to link it
03:21:29rayman22201you have to both include the GC functions, and initialize the GC runtime
03:21:43rayman22201even if you just linked it, that would not be sufficient
03:22:00FromGitter<kaushalmodi> I cannot link both libnimrtl.so and mylib.so (libdpi.so that I referenced above) with the host C app because they both have `NimMain`
03:22:45rayman22201hrmmm... some missing flag I think.
03:23:13rayman22201weird, I thought --app:lib causes the NimMain to not be generated
03:23:17FromGitter<kaushalmodi> I faced this issue before and so I started just importing all my Nim libs and creating just one .so
03:23:28FromGitter<kaushalmodi> no, it does..
03:24:29rayman22201there is some forum post or blog post about this... and I can't remember where it is :-(
03:26:40*uu91 quit (Read error: Connection reset by peer)
03:27:02*uu91 joined #nim
03:27:17FromGitter<kaushalmodi> I couldn't be a first one compiling .so from .nim
03:28:11FromGitter<kaushalmodi> Seems like I am missing out something big, or there's something else special with the way the host C application (systemverilog compiler) uses the .so
03:30:49rayman22201so, the closest thing I can find is to look at what nimpy from yglukhov is doing
03:30:51rayman22201https://github.com/yglukhov/nimpy/blob/master/nimpy.nim#L213
03:31:05FromGitter<kaushalmodi> hmm, actually libnimrtl.so is being used..
03:31:09FromGitter<kaushalmodi> but the crash is the exact same
03:31:14FromGitter<kaushalmodi> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5dc39002bbdf5f17b420b97f]
03:31:46rayman22201you need to do something similar to nimpy
03:32:11rayman22201specifically check if the GC is initialized and call `setupForeignThreadGC`when needed
03:32:20rayman22201and make sure the `stackBottom` is kept correct
03:32:34FromGitter<kaushalmodi> too much jargon!
03:32:51FromGitter<kaushalmodi> need to read up, starting with your nimpy reference
03:33:07FromGitter<kaushalmodi> without libnimrtl, I get: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5dc390733f4ea333f2c531ca]
03:33:11rayman22201lol. you asked for the Dragon, and the dragon is Nim's GC :-P
03:33:33FromGitter<kaushalmodi> so as you see, it's the same crash, so I did not need nimrtlib.so
03:33:56FromGitter<kaushalmodi> may be the issue is about me not doing the fancy GC stuff :)
03:34:19rayman22201Yeah. nimrtllib.so was a red herring. I apologize
03:34:28rayman22201it's the fancy GC stuff that you need :-)
03:34:54rayman22201I was hoping that --nimrtl would do the fancy GC stuff for you, but I guess not :-(
03:35:18*actuallybatman quit (Ping timeout: 265 seconds)
03:36:29rayman22201while I have you, @kaushalmodi. I have a question of my own. I'm trying to use nim-gdb. I would like to set a breakpoint at a specific line in a nim proc, but I can't seem to do that.
03:36:46FromGitter<kaushalmodi> the nimpy example is going into threads stuff (another unknown area for me)
03:36:49rayman22201you have some experience with nim in gdb if IIRC?
03:36:56FromGitter<kaushalmodi> do I really need --threads:on for GC?
03:36:59rayman22201no
03:37:20rayman22201you are going to have extrapolate the GC stuff from the thread stuff
03:37:47FromGitter<kaushalmodi> no, I started learning gdb and used valgrind for the first time just to debug this GC crash
03:37:53rayman22201if you have threads, the GC gets more complicated, but even with a single thread the GC stuff is the same.
03:38:22FromGitter<kaushalmodi> have you looked at the nim-gdb video and the blog post?
03:38:44rayman22201ahh. I forgot about that
03:39:01FromGitter<kaushalmodi> https://internet-of-tomohiro.netlify.com/nim/gdb.en.html
03:39:18FromGitter<kaushalmodi> I have bookmarked that.. still too read
03:39:29rayman22201thank you :D
03:39:37FromGitter<kaushalmodi> I bookmarked it when I had never run gdb ever
03:39:48FromGitter<kaushalmodi> may be if I read it now, I won't be that scared
03:39:49FromGitter<kaushalmodi> :)
03:40:01rayman22201gdb isn't so scary :-)
03:42:42rayman22201looking at your stack trace, I am willing to bet that the first two lines of this function are exactly what you need: https://github.com/yglukhov/nimpy/blob/master/nimpy.nim#L214
03:42:50FromGitter<kaushalmodi> I have a lot of questions about setting up GC init: I will leave the questions here, but I will need to sign off for today
03:43:29rayman22201o/ bye
03:43:31FromGitter<kaushalmodi> 1) how to decide when and where to call that updateStackBottom?
03:43:49FromGitter<kaushalmodi> 1) You said that check that the stackBottom is correct.. I have no idea what it should be
03:44:02FromGitter<kaushalmodi> .. and how do I "init" GC?
03:44:05FromGitter<kaushalmodi> where?
03:44:40FromGitter<kaushalmodi> the host C appl will be simply calling that exportc'd proc.. do I init that GC in there (how?)
03:50:31*druonysus quit (Quit: druonysus)
03:55:45*druonysus joined #nim
03:55:46*druonysus quit (Changing host)
03:55:46*druonysus joined #nim
04:01:14*druonysus quit (Remote host closed the connection)
04:02:28FromDiscord<Bub_Lite_63_Jr> I've been trying to install Nim for a few days, with no luck. Any Zim Gurus awake that might be able to understand why I'm having an installation error?
04:14:14*cyraxjoe joined #nim
04:15:54*MightyJoe quit (Ping timeout: 265 seconds)
04:19:45shashlickplease share some details
04:31:19*kevin5 quit (Ping timeout: 268 seconds)
04:34:12*druonysus joined #nim
04:34:12*druonysus quit (Changing host)
04:34:12*druonysus joined #nim
04:34:54*druonysus quit (Remote host closed the connection)
04:36:51FromDiscord<treeform> Nim is not hard to install?
04:40:08*druonysus joined #nim
04:40:08*druonysus quit (Changing host)
04:40:08*druonysus joined #nim
04:43:57*druonysus quit (Remote host closed the connection)
04:51:46*uu91 quit (Read error: Connection reset by peer)
04:52:10*uu91 joined #nim
04:52:23*chemist69 quit (Ping timeout: 245 seconds)
04:52:36*nsf joined #nim
04:53:06*uu91 quit (Client Quit)
04:54:21*chemist69 joined #nim
05:01:59*GordonBGood joined #nim
05:05:46*druonysus joined #nim
05:05:46*druonysus quit (Changing host)
05:05:46*druonysus joined #nim
05:06:29*druonysus quit (Remote host closed the connection)
05:07:02*uu91 joined #nim
05:07:31*druonysus joined #nim
05:07:31*druonysus quit (Changing host)
05:07:31*druonysus joined #nim
05:08:59FromGitter<zacharycarter> wrote a compile time proc to turn a byte array into a uint32: https://play.nim-lang.org/#ix=213e
05:09:07FromGitter<zacharycarter> endians wouldn't work at compiletime because it cimports some builtin
05:09:23*jwm2241 quit (Ping timeout: 250 seconds)
05:10:37*jwm2241 joined #nim
05:14:53FromGitter<kayabaNerve> @zacharycarter ... why? :P
05:15:03FromGitter<kayabaNerve> Couldn't you just use hex notation
05:18:33*lritter quit (Quit: Leaving)
05:30:01*druonysus quit (Remote host closed the connection)
05:36:36*nif quit (Quit: ...)
05:36:47*nif_ joined #nim
05:39:19*thomasross is now known as Guest3578
05:39:19*thomasross_ joined #nim
05:39:19*Guest3578 quit (Killed (adams.freenode.net (Nickname regained by services)))
05:39:19*thomasross_ is now known as thomasross
05:40:47FromGitter<zacharycarter> I suppose so
05:41:06FromGitter<zacharycarter> C++ lets you do something like - `static const uint32_t kHelloCC = 'HELO';`
05:41:14FromGitter<zacharycarter> but yeah, hex would probably be easier
06:04:06Araqdoes C++ use little or big endian for this? seems to be a crappy feature tbh
06:07:23*kevin joined #nim
06:07:44*kevin is now known as Guest48957
06:20:47FromGitter<zacharycarter> good question - i'll try to dig and figure it out - I know it's supported by gcc but not sure about other compilers - it's definitely not cross platform
06:21:04FromGitter<zacharycarter> I'll just use hex and `fromHex` as that seems much better
06:26:15*narimiran joined #nim
06:26:19*theelous3_ joined #nim
06:26:27*theelous3 quit (Ping timeout: 240 seconds)
06:29:02FromGitter<kayabaNerve> I do everything in big endian simply because bit shifts are big endian no matter the CPU.
06:29:27FromGitter<kayabaNerve> That said, it's amazing to just do a raw pointer cast/memcpy (to make it safe).
06:35:45*solitudesf joined #nim
06:52:05*thomasross quit (Ping timeout: 276 seconds)
06:52:18*thomasross joined #nim
06:55:05*Hideki_ joined #nim
06:59:56*Hideki_ quit (Ping timeout: 268 seconds)
07:07:07*Guest48957 quit (Remote host closed the connection)
07:07:17*uu91 quit (Read error: Connection reset by peer)
07:07:37*uu91 joined #nim
07:07:49*kevin joined #nim
07:08:03*kevin is now known as Guest24903
07:11:12*Guest24903 is now known as Kevin
07:11:55*Kevin is now known as Guest3139
07:20:10*Guest3139 is now known as Kevin-
07:20:41Kevin-isn't Nim compile to wasm possible ?
07:21:06FromGitter<kayabaNerve> Yes, via emscripten.
07:22:44Araqnlvm can also do it
07:23:57Kevin-thanks
07:24:14FromGitter<kayabaNerve> https://github.com/Jipok/Nim-SDL2-and-Emscripten
07:24:18FromGitter<kayabaNerve> https://github.com/Feneric/nim-wasm-helpers
07:25:57FromGitter<kayabaNerve> There's two links about it (there's also some Git issues around). First is a dated repo compiling Nim SDL2 code to ASM.js/WASM and the second is a more recent repo which sets up a VM for the work. I'm not suggesting setting up a VM, but it should contain the relevant scripts.
07:28:27FromGitter<zacharycarter> I had some zengine examples running with webassembly
07:28:42FromGitter<zacharycarter> it's pretty easy via emscripten
07:30:03Kevin-I think wasm will popular in near future
07:30:42FromGitter<zacharycarter> I heard that somewhere a few years ago :P
07:30:51Kevin-and Nim compile wasm was cool 👑
07:31:09FromGitter<zacharycarter> but in all seriousness, I hope JavaScript dies a slow painful death, sooner rather than later
07:31:56Kevin-I don't like Javascript totally
07:32:22*snwmzr joined #nim
07:32:28Kevin-still working on it but don't like :P
07:33:03FromGitter<zacharycarter> well yeah, same here, in fact I'm writing JS right now at work adding functionality to some react app Supercell wrote that we use
07:33:25FromGitter<zacharycarter> but that doesn't mean I like it! :P
07:34:31Kevin-someday I deleted node_modules and feel better :D
07:37:37*PMunch joined #nim
07:39:22FromGitter<zacharycarter> :D
07:41:44FromGitter<funcmike_twitter> Hello, where can I find progress report on new runtime (destructors)?
07:43:01*letto quit (Quit: Konversation terminated!)
07:44:27*letto joined #nim
07:46:02GordonBGoodfuncmike_twitter: unless Araq chips in, it seems it's too early for a progress report on "--newruntime"/"--gc:destructors" (two separate things) as they are still in fairly rough development form...
07:46:37GordonBGoodBut "--gc:destructors" is likely to hit the big time before "--newruntime"
07:46:49GordonBGoodAnything specific you would like to know?
07:47:26FromGitter<zetashift> What is the difference between destructors and newruntime?
07:47:56Araqdestructors: C++ with shared_ptr done right
07:48:04Araqnewruntime: C++ with unique_ptr done right.
07:50:51GordonBGoodzetasguft: --newruntime is pretty complex: in short ``owned`` ref's that get destroyed when they go out of scope as per a paper by Bacon/Dingle - started from about here https://github.com/nim-lang/RFCs/issues/144
07:51:34GordonBGood^ the beginning of the long answer on --newruntime
07:53:48AraqGordonBGood: it's not as bas as you claim IMO, simple programs I try with --gc:destructors do work
07:54:03*theelous3_ quit (Ping timeout: 240 seconds)
07:54:11GordonBGoodYes, me, too, for simple programs
07:54:59GordonBGoodBut we aren't ready for "big time" until it works for everything we can throw at the common GC's like --gc:boehm
07:55:26livcdThis channel is much more active during the EU time. Unbelievable how everything is so quiet when one is in Asia
07:56:24GordonBGoodYeah, I'm in Asia, too, need to wait to after 2 pm or get up in the middle of the night to chat with most ppl
07:56:55livcdGordonBGood can i Q ?
07:57:08GordonBGoodQ awqy
07:57:32GordonBGoodThailand
07:59:04Kevin-I'm in Asia too
08:00:00*gmpreussner quit (Quit: kthxbye)
08:02:52FromGitter<kayabaNerve> I actually don't mind JS. I used to use Node all the time.
08:03:07FromGitter<kayabaNerve> I also don't see WASM as the superior alternative.
08:04:42*gmpreussner joined #nim
08:06:56FromGitter<zacharycarter> JS is pretty terrible
08:07:18FromGitter<alehander92> maybe its kinda fine with a type checker and some overlay
08:07:26FromGitter<alehander92> like nim / elm / typescript
08:08:21FromGitter<alehander92> but wasm is better for many things
08:08:39FromGitter<kayabaNerve> I never learned Typescript, ngl.
08:08:51*jjido joined #nim
08:09:08FromGitter<alehander92> well, its good
08:09:09FromGitter<kayabaNerve> I've been forced to move to Python which I absolutely hate. It's such a horrible language.
08:09:15FromGitter<alehander92> hm, have you used mypy
08:09:18FromGitter<kayabaNerve> I use it with two type checkers.
08:09:21FromGitter<alehander92> otherwise i loved python
08:09:28FromGitter<kayabaNerve> Yeah, PyRight, MyPy, and PyLint.
08:09:30FromGitter<alehander92> it was one of my first fav languages
08:09:51FromGitter<alehander92> i was so happy that my first "official" it job was python
08:09:54FromGitter<kayabaNerve> All of them pass too. I write amazingly clean Python code.
08:10:02FromGitter<alehander92> hm, which of them is best
08:10:07FromGitter<kayabaNerve> But it's also a horrible language I despise.
08:10:11FromGitter<alehander92> what do you dislike?
08:10:18FromGitter<kayabaNerve> Eh. PyLint is code cleanliness, not type checking.
08:10:29GordonBGoodalehandler92: Fable/F3 -> JS?
08:10:35GordonBGood^F#
08:10:48FromGitter<kayabaNerve> I prefer PyRight over MyPy. It generally covers more bugs although it does have a few false positives :/ I probably encounter one every 3 weeks.
08:10:57FromGitter<kayabaNerve> They do quickly respond to issues though.
08:11:10FromGitter<kayabaNerve> One of things I hate is import
08:11:31FromGitter<kayabaNerve> Without path manip, you can only import files (in the same project) which are next to you or below you.
08:11:43FromDiscord<minierolls> does anyone here have experience with winlean
08:11:56FromGitter<kayabaNerve> You have to set your code up as a package, run it with the namespace package flag, or use path manipulation to enable importing from anywhere in the project.
08:11:59FromDiscord<minierolls> wondering specifically about one function, readConsoleInput
08:12:07FromGitter<alehander92> GordonBGood maybe, i just never used it
08:12:35FromGitter<zacharycarter> `But it's also a horrible language I despise` - how do you like / not mind JS but despise Python?
08:12:39FromGitter<alehander92> @kayabaNerve well, its a bit annoying
08:12:46FromGitter<alehander92> but its not a dealbreaker imo
08:13:05FromGitter<kayabaNerve> I can look past the lack of type safety.
08:13:19FromGitter<alehander92> it pushes you to some module hierarchy
08:13:31FromGitter<zacharycarter> so what makes Python worse than JavaScript then?
08:13:32FromGitter<alehander92> which is not so bad: even when i do import ../../stuff
08:13:38FromGitter<alehander92> i feel a bit strange here
08:13:44FromGitter<alehander92> but i do it a lot i admit
08:13:47FromGitter<kayabaNerve> ... uhhhh you can't do that in Python without path manip
08:13:52FromGitter<alehander92> i know
08:13:54FromGitter<kayabaNerve> Yeah
08:14:07FromGitter<kayabaNerve> There's a reason I run my code as a namespace package.
08:14:17FromGitter<alehander92> well, you can easily write a function or something
08:14:21FromGitter<alehander92> which wraps import
08:14:40FromGitter<alehander92> but no idea how well it works with type checkers
08:14:49FromGitter<kayabaNerve> @zacharycarter Import system, *init* files, 2.7/3.0 split, type unsafety, snake casing, inconsistent naming/casing...
08:15:08GordonBGoodalehandler92: Fable/F# is something like a more complex Elm but without the restrictions, mutability/OOP are options if you need/want them
08:15:18FromGitter<kayabaNerve> The only one of those issues with JS has is type unsafety, which I can look past.
08:15:26FromGitter<zacharycarter> yeah well - all of those things you'll see in JS as well
08:15:45FromGitter<kayabaNerve> My favorite example of inconsistency in Python are hex(int) and bytes.hex()
08:15:48FromGitter<alehander92> i like this_case , i admit that the lib might have some older naming issues but are passable , type unsafety is better than javascript: it uses strong typing at least
08:15:52FromGitter<zacharycarter> JS has weak typing which is arguably worse than no typing
08:16:00FromGitter<alehander92> and mypy etc should be kinda similar to typescript
08:16:13FromGitter<alehander92> but i admit i can see your point
08:16:19FromGitter<alehander92> i think you'll like ruby
08:16:23FromGitter<kayabaNerve> Python doesn't have typing at runtime without manual isinstance/of checks.
08:16:30FromGitter<kayabaNerve> Even type hints are discarded.
08:16:47FromGitter<zacharycarter> and as far as import systems / init files go - those are all third party in the JS world which is terrible because you end up with solutions like npm
08:16:50FromGitter<zacharycarter> which is absolute garbage
08:16:58FromGitter<zacharycarter> and babel / webpack
08:17:03FromGitter<kayabaNerve> JS doesn't have an import system I mind, never had init files, doesn't have a 2.7/3.0 split, does have type unsafety, generally isn't snake cased, and has far less inconsistency IMO
08:17:15FromGitter<kayabaNerve> I hate JS's package ecosystem.
08:17:17FromGitter<zacharycarter> it does have init files - RC files
08:17:31FromGitter<alehander92> @kayabaNerve well .. dynamic languages dont have runtime typing, not sure about your point
08:17:34FromGitter<zacharycarter> err wait config files, not in it files
08:17:36FromGitter<zacharycarter> init files
08:17:40FromGitter<alehander92> usually there exist third party libs for that too
08:17:43FromGitter<kayabaNerve> The only comparable thing I've seen to an init file is a package.json file
08:17:45FromGitter<zacharycarter> trust me - python may be a mess but JS is too
08:17:57FromGitter<zacharycarter> yes and in package.json files you can find horrors
08:17:59FromGitter<kayabaNerve> My issue with Python isn't that the root has an init file; it's that every single folder does.
08:18:09FromGitter<zacharycarter> well, that is dumb / annoying yes
08:18:10FromGitter<kayabaNerve> Yeah but there isn't a package.json in every single folder.
08:18:15FromGitter<zacharycarter> it can be if you want it to be
08:18:22FromGitter<kayabaNerve> They wouldn't do anything
08:18:36FromGitter<kayabaNerve> Namespace Packages should've been packages.
08:19:06FromGitter<alehander92> GordonBGood yeah i imagine it as ocaml
08:19:41FromGitter<alehander92> i think python is passable
08:19:53FromGitter<alehander92> those issues are easy to get a workaround for
08:20:02FromGitter<alehander92> and it has some consistency + ok metaprogramming
08:20:03FromGitter<kayabaNerve> I understand JS's detractions. I'm just saying I like writing servers in NodeJS. I won't comment on frontend JS though as I've never been a frontend dev and I consider most frontend tech to be f*ed.
08:20:29FromGitter<kayabaNerve> I believe Python is horrible all around for several reasons, and only one of those reasons exists in JS IMO (the typing).
08:20:57FromGitter<kayabaNerve> @alehander92 Yeah, I use three separate checkers and run in a non-default setup (namespace packages via -m)
08:21:27FromGitter<kayabaNerve> Those are my workarounds :P
08:21:32FromGitter<kayabaNerve> Nim is great though
08:21:50FromGitter<alehander92> but i'd say some things are missing in javascript
08:22:01FromGitter<kayabaNerve> I'm only using Python because I need to test my protocol with a second system. I don't trust Nim to test Nim.
08:22:03FromGitter<alehander92> weaker metaprogramming, almost no stdlib
08:22:10FromGitter<kayabaNerve> I wouldn't trust C to test C either.
08:22:17FromGitter<alehander92> worse syntax
08:22:35FromGitter<alehander92> i use python to script gdb mostly
08:22:36FromGitter<alehander92> these days
08:22:39FromGitter<kayabaNerve> The NodeJS stdlib is good enough. Again, I'm a backend dev :P
08:22:51FromGitter<alehander92> and it's fine, i like the fact its kinda similar to nim at least syntactically
08:22:56FromGitter<kayabaNerve> I'm not referring at all to frontend JS. I consider all frontend tech horrible.
08:23:06FromGitter<alehander92> but i admit i need to start using mypy again
08:23:07FromGitter<kayabaNerve> Yeah, I don't mind Python's structure.
08:23:25FromGitter<kayabaNerve> *and PyRight and PyLint?
08:23:32FromGitter<alehander92> well, i dont see so much need
08:23:38FromGitter<alehander92> for three type checkers :P
08:23:44FromGitter<kayabaNerve> *2 and a linter
08:23:47FromGitter<alehander92> i mean, i am currently doing ok with 0
08:23:54FromGitter<alehander92> "kinda" ok
08:23:58FromGitter<kayabaNerve> Again. PyLint is cleanliness. PyRight and MyPy and type checkers.
08:24:12FromGitter<alehander92> yes *
08:24:20FromGitter<alehander92> i planned doing a python backend similar to the javascript one for nim
08:24:22GordonBGoodalehandler92: Fable/F# is much better than OCaml as in easier to use once you adapt to Functional Programming
08:24:26FromGitter<alehander92> but i realized this is too much
08:24:26FromGitter<kayabaNerve> I do prefer PyRight to MyPy though. Much better output, covers more things, occasionally has a false positive.
08:24:34GordonBGoodwhich is also needed for OCaml
08:24:57FromGitter<kayabaNerve> I wonder if you could do Nim to Python without an AST.
08:25:00GordonBGoodFable/F# is much more consistent syntax
08:25:12FromGitter<kayabaNerve> Eh. You need one for variable syntax/macros.
08:25:14GordonBGoodBetter type handling
08:25:19FromGitter<alehander92> alehander92: interesting, i am fine with nim for frontend for now, i am interested in functional for systems tuff mostly
08:25:28FromGitter<alehander92> @kayabaNerve well it doesnt make sense imo
08:25:34FromGitter<alehander92> we already have the compiler frontend
08:25:37FromGitter<alehander92> its easier
08:25:43FromGitter<alehander92> to reuse it
08:25:50FromGitter<kayabaNerve> It was a random thought, not a suggestion :P
08:26:12FromGitter<alehander92> but its better to improve nim so it can be used instead of python
08:26:17FromGitter<alehander92> yeah :P
08:26:31FromGitter<alehander92> i also plan on patching gdb directly with some c/nim based code
08:26:44FromGitter<alehander92> and seeing if that's somehow efficient
08:26:46FromGitter<kayabaNerve> Though I do support more Nim compilers. I at least a 100% nlvm which works on all three major kernels.
08:26:58FromGitter<kayabaNerve> *at least want
08:27:44FromGitter<kayabaNerve> `~95% of all upstream tests - most failures can be traced to the standard library and compiler relying on C implementation details - see skipped-tests.txt for an updated list of issues`
08:27:51FromGitter<kayabaNerve> `platforms: linux/x86_64, wasm32 (pre-alpha!)`
08:28:03*solitudesf quit (Ping timeout: 240 seconds)
08:29:25FromGitter<kayabaNerve> I question why they added wasm before Mac tbh. Maybe lack of dev hardware?
08:30:59*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:31:05GordonBGoodI've converted to Nim because one can output JS for frontends, asm.js or WASM for "better" web pages, hative for just about every platform including iOS and Android
08:31:11FromGitter<alehander92> GordonBGood: interesting, i am fine with nim for frontend for now, i am interested in functional for systems tuff mostly (i somehow replied to myself)
08:31:24FromGitter<alehander92> @kayabaNerve wasm /llvm is good yes
08:31:31FromGitter<alehander92> which project is this
08:31:39FromGitter<zetashift> I found that @alehander92 at yourself weird lool
08:31:45*lbart quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
08:32:12*lbartoletti joined #nim
08:35:34*lbartoletti is now known as lbart
08:38:08FromGitter<alehander92> you gotta keep that convo going
08:41:04FromDiscord<++x;> He
08:41:06FromDiscord<++x;> He
08:41:06FromDiscord<++x;> He
08:41:07FromDiscord<++x;> He
08:41:23GordonBGoodalehandler92: I use FP forms of code when I can, even in Nim if it doesn't impact performance (depending where it is in the code)
08:41:45FromDiscord<++x;> You guys need to go to sleep
08:42:44FromDiscord<++x;> I always like to tickle my feet
08:42:46FromGitter<alehander92> its 10 40 am
08:43:09FromGitter<kayabaNerve> LLVM is great. I really don't have an opinion on WASM.
08:43:15FromDiscord<++x;> Sometimes i even tickle my hands
08:43:16FromGitter<alehander92> GordonBGood i also like to do that: thats why i hope we get inline iterator chaining sooner
08:43:23FromDiscord<++x;> Just to get the nerves rushing
08:43:28FromDiscord<++x;> Pumping the blood
08:43:42FromGitter<kayabaNerve> The project I quoted is NLVM. It's not 100% compatible or usable on Windows, Mac, and Linux.
08:44:04FromGitter<alehander92> ah yeah we can always ask @arnetheduck
08:44:25FromGitter<alehander92> i guess they have priority for wasm currently
08:44:41FromGitter<alehander92> so probably thats why its linux, wasm before mac
08:45:08GordonBGoodalehandler92: In some ways, F# would be my favorite language if it output efficient native code, but it likely never will, being tied to DotNet including Core
08:45:20*thomasross quit (Remote host closed the connection)
08:45:21FromGitter<alehander92> narimiran also likes f# a lot
08:45:24narimiranyep
08:45:27FromGitter<alehander92> i also preferred going with ocaml
08:45:31FromGitter<alehander92> because of the .net thing
08:45:36GordonBGoodBut Alphonsa has done an incredible job adapting it to output JS through Babel
08:45:45*thomasross joined #nim
08:45:46narimiranyeah, i'm now giving ocaml a try
08:45:56GordonBGoodOh, Net's not so bad - open source now
08:46:16*floppydh joined #nim
08:46:59GordonBGoodF#/Fable is like a grown up OCcaml, but don't output native code, unfortunately
08:47:23narimiranocaml and F# are very similar, but i still like F# more (it feels/looks more elegant), and i might give it another try when .net core matures a bit more and i can use it more easily on linux
08:47:40Kevin-I refer to Kotlin also except Nim
08:48:04Kevin-dotnet core on linux look good ?
08:48:15Kevin-I never try it before
08:48:34narimiranKevin-: people keep saying that for .net core 3, but my experience was with 2.x
08:48:38FromGitter<alehander92> yeah .net isnt so bad, but i started getting used to native compilers
08:48:52GordonBGoodKotlin is definitely an immense improvement over Java, but which somebody made a "F# for the JVM" instead
08:49:05narimiranocaml's utop is an excellet REPL, btw
08:49:16FromGitter<alehander92> many people really like clojure btw, but i admit its pretty different kind of lang
08:49:17PMunchGordonBGood, have you tried Clojure?
08:49:42GordonBGoodNow we're up to stable DotNet 3.0, with continuing support guarantees
08:49:49GordonBGoodAPI guarantees
08:49:56PMunchClojure is really nice, but the JVM is just too big of a limitation for some things
08:50:12Araqdid Ocaml get this new improved syntax skin?
08:50:20FromGitter<alehander92> reason?
08:50:38PMunchThere was this little language: https://github.com/pixie-lang/pixie which looked really promising, but ultimately it just fizzled out
08:50:46FromGitter<alehander92> ah yeah thats another javascript replacement i forgot
08:50:49FromGitter<alehander92> https://reasonml.github.io/
08:51:10GordonBGoodYes, I did most "kind-of" FP languages, including a bit of List, a lot of Scheme, some Racket, and finally Clojure a few years ago. Clojure is dynamic typing...
08:51:50FromGitter<alehander92> yes it is but it has core.typing iirc
08:52:00FromGitter<alehander92> core.typed *
08:52:17GordonBGoodOne can get used to nesting round brackets everywhere with the help of a good editor, but still...
08:52:42PMunchYeah, I looked at some of my old Clojure code and had to scroll horizontally..
08:53:03PMunchUgh, wrapping this C code is so horrible.. Why couldn't nimterop just work..
08:53:06FromGitter<alehander92> i remember i did some clojure in uni as well, it seemed ok
08:53:15FromGitter<alehander92> but i also dont like lisps so much now
08:53:25FromGitter<alehander92> when i found out you can have good metaprogramming with other syntaxes
08:53:45PMunchSo easy to mess up a type and have alignment issues when I do this manually..
08:54:14GordonBGoodalehandler92: yeah, dynamic typing, and the whole concept of "everything is a list" somehow seems totally wrong to me now
08:54:39FromGitter<alehander92> well, you can have typed lisps
08:54:55GordonBGoodYeah Typed Racket, for instance
08:55:10FromGitter<alehander92> the list idea is cool , but i'd see it in two ways: homoiconity and lists everywhere
08:55:23FromGitter<alehander92> and homoiconity can be almost done with other syntax iirc
08:55:48GordonBGoodBut that's JIT'ed/interpreted and slower than something like Gambit Scheme, which is "kind of" native code
08:56:01FromGitter<alehander92> well, i remember some very optimized schemes
08:56:15FromGitter<alehander92> which i think only did full inference
08:56:18GordonBGoodGambit Scheme is a tad slow due to handling daynaic typing
08:56:26FromGitter<alehander92> so it should be possible in principle
08:56:48FromGitter<alehander92> you can always write lisp like you write c with similar "types" and produce fast code
08:57:10GordonBGoodpossible in principle doesn't mean done in practice; most lispers love their dynamic typing
08:57:27FromGitter<alehander92> yeah
08:58:28GordonBGoodalehandler92: faster, but almost never quite as fast as something like Nim; under the covers they are almost always dealing with the "any" supertype
08:59:28Araqthe Lisps I studied were mostly like C's restrict keyword
08:59:53Araq"optimizer you can assume an array of ints here" but it's not a type system, no checking was done
09:00:58PMunchI can't shake the feeling that a type functional language would be very possible to optimise really wel
09:01:22PMunchThe promises of a functional language means you can assume a lot more than you can in a procedural one
09:01:48*GordonBGood quit (Read error: Connection reset by peer)
09:01:59FromGitter<alehander92> well, many of them are
09:02:04FromGitter<alehander92> i wouldnt even say lisp is functional
09:02:18FromGitter<alehander92> because afaik many of the lisps use imperative stuff
09:02:28FromGitter<alehander92> compared to haskell/ocaml/etc
09:03:42FromGitter<alehander92> but i guess coding very close to the hardware might be still harder with such style
09:05:06*GordonBGood joined #nim
09:05:28FromGitter<funcmike_twitter> How is refc gc different from Swifts arc gc?
09:05:48AraqPMunch: yes and no, look at Haskell's deforestation optimization
09:06:31Araqbut optimizing complex immutable data structures into mutable ones turned out to be very difficult
09:08:00AraqI personally don't see the benefits but that's just me. for example, I don't need to keep the history around of the bytecode that my peephole optimizer worked on
09:08:28GordonBGoodalehandler92: yes, List's are said to be functional, and one can write mostly pure FP with discipline, but most List programmers don't worry too much about it when it suits them
09:09:01Araqor take the "count words in a file" example, there is no reason to use an "immutable" count table for this, it's masochism.
09:10:17Araqfuncmike_twitter: it's "deferred" meaning that the stack refs are not counted for more speed. it's also thread local
09:10:32GordonBGoodF# encourages "pure" by not making mutability so accessible generally, but when doing things like working with contents of arrays, it's mutabilitity all the way
09:10:37Araqso the remaining refcount operations are not atomic.
09:10:52AraqGordonBGood: yes, I noticed ;-)
09:12:04Araqmutability is fine when you restrict it a little, ideally via a unique path to the data
09:12:33GordonBGoodHaskell (and it's cousins) might be said to be the only "pure" FP language, but one can still mutate by manipulating type classes through monads
09:12:40Kevin-where can we use Lisp for ?
09:13:15FromGitter<mratsim> Status is recruiting a Clojure dev at the moment and CLojure is very Lispy
09:13:24FromGitter<mratsim> we also hire Nim devs ;)
09:14:27FromGitter<mratsim> AFAIK games often used Lisp or Lua as an embedded scriptinglanguage
09:14:36FromGitter<funcmike_twitter> @Araq: what about cycle detection and mutlicore with refc?
09:14:43GordonBGoodKevin: "We" as in "Nim ppl" probably won't use List very much, but Clojure is likely the most practical "Lispy" out there as long as your product can run on the JVM
09:15:45Araqfor cycle detection we use a backup mark&sweep GC. Multicore with refc is in the works, see my RFC about it, funcmike_twitter
09:17:39GordonBGoodfuncmike_twitter: just to fill you in: Araq is talking what --gc:destructors will give us, and the RFC is: https://github.com/nim-lang/RFCs/issues/177
09:17:55PMunchWell the benefit of immutability is more because it's easier to reason about. I get a result from you, and I know that it won't change. I can keep that copy for as long or as short as I like, and I know that it won't change. There's just something nice about that
09:18:05PMunchThat was to Araq by the way :P
09:19:00FromGitter<mratsim> atomic refcounting is a clutch though, if you need to share a whole data structure between threads your scalability will be *severely* limited
09:19:01Araqthat's very hand-wavy, who knows if you just described the lack of aliasing
09:19:16FromGitter<mratsim> persistent data structure included
09:19:25GordonBGoodWhen that becomes default, life with Nim will be beautiful, only improved further when --newruntime (whatever that will become) comes into its own
09:19:35FromGitter<funcmike_twitter> Ok thx
09:19:56Araqmratsim: I'm aware of the performance problems but I'm out of ideas
09:20:10FromGitter<mratsim> it's fine to provide it
09:20:24Araqtasks rely on closures and refs and inheritance and we must be able to share them
09:20:45Araqinside the task you can do the crazy custom seqs stuff avoiding 'ref' altogether
09:21:00FromGitter<mratsim> then the community will write some shared hash table for example. But others will write article on how to approach a parallel problem
09:21:20Araqhere is how I see it:
09:22:18*GordonBGood_ joined #nim
09:22:20Araqrefcounting is a pretty bad algorithm when you have many shortlived, pointer heavy things. but the hardware hates pointer heavy things and they are already slow.
09:23:01*GordonBGood_ quit (Client Quit)
09:23:04Araqat least refcounting is independent of the involved heap sizes, so as you make your object bigger in attempt to please your caches
09:23:24*GordonBGood_ joined #nim
09:23:31Araqrefcounting fewer, bigger objects starts to be a good strategy
09:23:46*GordonBGood_ quit (Client Quit)
09:23:57FromGitter<funcmike_twitter> So my last question for now is :) which gc (stable) should i use for starting with Nim, with async and multicore support - possibly better then Gos gc - with manual memory mgmt capabilities?
09:24:20*GordonBGood_ joined #nim
09:24:21FromGitter<mratsim> boehm
09:24:30Araqstart with the default GC and async, use something like httpbeast for multicore
09:24:31*GordonBGood_ quit (Client Quit)
09:24:48*GordonBGood quit (Read error: Connection reset by peer)
09:24:51FromGitter<mratsim> manual memory management is always possible with any GC
09:24:55Araqif you need a shared heap use boehm until --gc:destructors is ready
09:24:58FromGitter<mratsim> just don't use ref
09:25:30Araqmratsim: ref is a building block, you can use fewer refs but avoiding it altogether is neither wise nor required
09:25:31FromGitter<mratsim> (and seq and strings until destructors land but well it's hard to avoid them)
09:25:33*a_b_m joined #nim
09:25:55FromGitter<mratsim> I meant don't use a ref types where you don't want GC operations
09:26:06*GordonBGood joined #nim
09:26:29FromGitter<mratsim> I mix and match ref and raw pointers freely in my high performance libraries depending on my use-case.
09:26:54Araqmratsim: yeah but you don't *start* with this ;-)
09:27:17Araqyou do this once you understand all the details and *if* you need it
09:27:18FromGitter<mratsim> of course
09:28:02*a_b_m quit (Client Quit)
09:28:29GordonBGoodmratsim, it's really hard to eliminate ref's if your code uses closures - you can emulate closures using pointers but it's not easy
09:29:19Araqit's actually easier then you would think with the undocumented .liftLocals transformation, but yeah, better not go there
09:30:03GordonBGoodAraq, wow, that sounds tempting (but I better not go there) ;)
09:32:04FromGitter<mratsim> OK, so by the way, when you have your threading API RFC I have some topics I want covered: ⏎ ⏎ 1) waiting on a local barrier object ⏎ 2) exportc name: I want JIT-ed code to be able to hook into the Nim multithreading capability ⏎ 3) being able to switch scheduler: real-time system will want a latency optimised runtime with early tasks first instead of a throughput optimized runtime ...
09:32:04FromGitter... [https://gitter.im/nim-lang/Nim?at=5dc3e4942f8a0343574f4efd]
09:33:01FromGitter<mratsim> @GordonBGood, yeah I know, I need to emulate closures for my runtime :/ for now I ask the dev to pass all arguments to the spawn call and they are deep-copied
09:33:21FromGitter<mratsim> but I can't replicate the "parallel" block or OpenMP syntax for for-loop that way
09:34:04FromGitter<mratsim> and ideally I don't introduce a closure for tasks, just {.nimcall.} + a serialized closure environment
09:34:47FromGitter<mratsim> see: https://github.com/mratsim/weave/blob/master/picasso/workstealing_types/sync_types.nim#L59-L60
09:35:56*uu91 quit (Ping timeout: 240 seconds)
09:37:03*uu91 joined #nim
09:37:15*fredrik92 is now known as couven92
09:37:39*Vladar joined #nim
09:42:42GordonBGoodwith --gc:destructors, there is no deepCopy :)
09:42:57GordonBGoodYes, I've done something the same when I've needed to do so
09:43:22FromGitter<mratsim> now with liftLocals you have my attention :P
09:44:18GordonBGoodmratsim, we aren't supposed to go there :) but there is a whole compiler file dedicated to that macro ;)
09:44:34GordonBGood^that pragma
09:45:17*Hideki_ joined #nim
09:45:40GordonBGoodbut it's only 72 lLOC
09:47:47FromGitter<alehander92> what does it do
09:48:57FromGitter<mratsim> It would be nice to be able to replace this OpenMP syntax: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ and now the runtime can transform the for loop into a proc that takes x, y, len as parameter and the x, y, len are serialized. [https://gitter.im/nim-lang/Nim?at=5dc3e889e1c5e915084b88ae]
09:49:52GordonBGoodand a file ../tests/fields/tfields.nim that shows how its used
09:51:04GordonBGoodalehandler92: it appears to lift the pragmas arguments, including and/or limited to the proc arguments to which it is applied as a proc pragma
09:51:40Araqmratsim: I guess I'm only good at giving you the building blocks aka --gc:destructors/newruntime
09:51:59Araqthe rest is better done by you
09:52:43Araqbut I might give you a rawthreads.nim file, a tiny wrapper over what the OS provides
09:56:04GordonBGoodAraq: isn't that what what the current threads.nim already provides - a fairly think wrapper over the OS thread implementation?
09:56:17GordonBGood^fairly thin
09:58:50*tklohna joined #nim
10:00:20*thomasross quit (Remote host closed the connection)
10:00:44*thomasross joined #nim
10:01:41FromGitter<mratsim> the current threads.nim is enough
10:01:56*MarderIII joined #nim
10:02:34GordonBGoodI would worry to go "thinner" than threads.nim would be platform dependent
10:02:34FromGitter<mratsim> Ideally that's what the compiler/standard library should be about. There is only one you (well only one me as well).
10:03:25FromGitter<mratsim> provides building blocks, a standard API. I build my runtime, later someone else builds a latency optimized runtime for audio and embedded
10:03:39FromGitter<mratsim> anyone can choose between both seemlessly, and everyone is API
10:04:02FromGitter<mratsim> bonus, we have a stable C API for those and those can be used as a library.
10:04:19FromGitter<mratsim> (even though my main use case would be JITTed parallel code)
10:04:46FromGitter<mratsim> s/happy/API
10:05:01FromGitter<mratsim> well the other way around, but you catch my drift
10:06:16*azed joined #nim
10:18:13*snowolf quit (Ping timeout: 245 seconds)
10:19:29GordonBGoodAraq: the other day you said that we are moving toward no RTTI "except where we must use it"; I've been thinking about that and wonder what cases "we must use it"?
10:20:09GordonBGoodref UncheckedArray[T], which has no size?
10:20:43GordonBGood^no implicit size
10:23:55FromGitter<alehander92> interesting, i have to try it
10:27:37AraqGordonBGood: everywhere where C++ has to use a virtual destructor
10:29:25GordonBGoodAraq, which for us is: not seq, not string, ref/ptr to certain types?
10:29:49Araqinheritable objects. that's it
10:31:55GordonBGoodAh, so any object that is of RootObj or is of such
10:33:03Araqyup
10:33:19Araqwhich is usually the foundation for a Task[T] type ;-)
10:34:11FromGitter<alehander92> started reading a
10:34:15Araqyou want a single interface to an object that contains a variable number of captured variables, you need something like inheritance and virtual destruction
10:34:18FromGitter<alehander92> ffast-math comment about unrolling on hacker news
10:34:23FromGitter<alehander92> started sounding a bit familiar
10:34:34FromGitter<alehander92> saw "Nim" , looked at the name: mratsim
10:34:35FromGitter<alehander92> of course
10:35:06GordonBGoodRootObj start with some minimum base RTTI and each inheritited object type must be "nested" to refer back to levels of RTTI above
10:35:13GordonBGoodAraq: Okay, got it
10:35:34Araqwill they ever fix HN's site not to suck for everything?
10:35:50FromGitter<alehander92> they have many clients
10:35:56narimiranAraq: they did, and it is called lobste.rs :P
10:36:18FromGitter<alehander92> its almost like a hello world in "write a custom simple website client "
10:36:20GordonBGoodand see its use for unknkown numbers of coptures/interface fields
10:36:55Araqmost real forum software doesn't derail into an indentation mess
10:38:19Araqit's fine I guess, it's for hackers, hackers don't understand good UIs or why you can control a server via a mouse even though the machine itself has no mouse attached to it.
10:39:05FromGitter<alehander92> i am trying to do ui this week araq its really hard dont laugh at me
10:48:51*Hideki_ quit (Ping timeout: 265 seconds)
10:49:02*Kevin- quit (Remote host closed the connection)
10:56:54*uu91 quit (Read error: Connection reset by peer)
10:57:13*uu91 joined #nim
10:59:28*uu91 quit (Read error: Connection reset by peer)
11:00:20*uu91 joined #nim
11:03:37Araqhttps://github.com/nim-lang/Nim/pull/12619 the future is here
11:04:33*Vladar quit (Quit: Leaving)
11:05:24narimiran`when version <= (NimMajor, NimMinor): body`
11:05:28FromGitter<kayabaNerve> `since`
11:05:29narimiranummm, `>=`?
11:05:34FromGitter<kayabaNerve> Yeah, that seems backwards to me too lol
11:09:15Araqthink about it
11:11:57FromGitter<alehander92> we can have a removed: (after, after)
11:12:01FromGitter<alehander92> or something like that
11:12:52narimiranAraq: i am thinking about it and to me `<=` is wrong. e.g. something will be available for 1.1, 1.0, 0.20, but not for 1.2, 1.3?
11:13:01Araqwell I tested it
11:13:02FromDiscord<Chiqqum_Ngbata> Is since supposed to be removedSince or availableSince ?
11:13:02narimiranaaaaaaaaa
11:13:06narimirani seee
11:13:29narimiranwho writes conditionals like that? pfffft
11:14:18FromGitter<alehander92> i still dont get it
11:14:34narimiran`when (NimMajor, NimMinor) >= version` is the way i would do it, as it is more clear to me
11:14:54FromGitter<alehander92> but i still dont get it
11:14:56narimiranso: `since` is available since, @Chiqqum_Ngbata
11:15:04FromGitter<alehander92> isn't (1, 0) <= (1, 1)
11:15:15FromGitter<alehander92> so this means that the new procedure would be available in 1.0
11:15:17FromGitter<alehander92> but not in 1.1
11:15:21narimirannope
11:15:31FromGitter<alehander92> huh
11:15:40narimirane.g. you have some proc annotated with `{.since 1.5}`
11:15:45FromGitter<alehander92> is (1, 0) <= (1, 1) false
11:15:49narimiranthis is `version`
11:16:00narimiranyour Nim at this point is 1.0
11:16:19narimiranso `version` is not less than (NimMajor, NimMinor). it is not available to you
11:16:36FromGitter<alehander92> but no
11:16:41FromGitter<alehander92> version *is* 1.5
11:16:50FromGitter<alehander92> its a variable based on the pragma
11:16:53narimiranyeah
11:17:05*MarderIII quit (Ping timeout: 268 seconds)
11:17:48FromGitter<alehander92> ah i see
11:18:00narimiran(Araq is probably reading this discussion and laughing at us :))
11:18:24FromGitter<alehander92> ok, i need to eat
11:18:28FromGitter<alehander92> sorry
11:18:41narimiranis that why? then i'm off to lunch too :)
11:19:08FromGitter<alehander92> i guess you can still have until: (1, 5) for deprecation
11:19:13FromGitter<alehander92> iirc somebody had that idea before
11:19:24narimiranwe have "deprecated since"
11:20:36FromGitter<alehander92> after my thorough mathematical jounery with `since` i am not so sure anymore
11:20:50FromGitter<alehander92> i am going to just let math people deal with this stuff
11:23:08FromDiscord<arnetheduck> nlvm/wasm/llvm: I don't have a mac and even if I did, I don't have any interest to maintain it - will take patches - we experiment with wasm at status so I use nlvm as a playground to try things out sometimes (works pretty well) - I believe it would generally serve nim to drop the JS backend and go full wasm instead, in terms of focusing effort and reducing complexity @kayabaNerve @alehander92
11:24:59FromGitter<alehander92> its ridicilously early in costa rica man
11:25:43FromGitter<alehander92> how much of the stdlib is supported in wasm btw
11:36:33FromGitter<mratsim> what are you doing in costa rica Alexander?
11:39:03*MarderIII joined #nim
11:41:07*MarderIII quit (Remote host closed the connection)
11:41:48*MarderIII joined #nim
11:45:32*Vladar joined #nim
11:49:19FromGitter<alehander92> sorry, i was making an uneducated guess about arne's location
11:50:10*ng0 joined #nim
11:50:34*rockcavera joined #nim
11:50:45*solitudesf joined #nim
11:59:44*azed quit (Quit: WeeChat 2.6)
12:02:47*MarderIII quit (Ping timeout: 276 seconds)
12:05:13*azed joined #nim
12:09:50*Hideki_ joined #nim
12:13:06*azed quit (Quit: WeeChat 2.6)
12:14:29*Hideki_ quit (Ping timeout: 276 seconds)
12:17:05*MarderIII joined #nim
12:17:23*MarderIII quit (Max SendQ exceeded)
12:18:17*MarderIII joined #nim
12:18:27FromGitter<zetashift> So what exactly is the difference between `method` and `proc`. I don't know much about dispatch and stuff, but a difference is that method is binded at runtime and proc at compile time?
12:25:04FromDiscord<Rika> yes
12:26:56*MarderIII quit (Quit: Leaving)
12:44:48*thomasross_ joined #nim
12:44:48*thomasross is now known as Guest90065
12:44:48*Guest90065 quit (Killed (orwell.freenode.net (Nickname regained by services)))
12:44:48*thomasross_ is now known as thomasross
12:49:50*thomasross quit (Remote host closed the connection)
12:50:18*thomasross_ joined #nim
12:50:18*thomasross_ is now known as thomasross
12:59:20*nsf quit (Quit: WeeChat 2.6)
13:10:20*thomasross quit (Remote host closed the connection)
13:10:44*thomasross joined #nim
13:14:22FromGitter<alehander92> awesome example @deech
13:14:34FromGitter<alehander92> the type providers-like sample thing
13:14:44FromGitter<alehander92> ops this is from the forum https://www.youtube.com/watch?v=ElHi2h9Ho6M
13:17:27*eys joined #nim
13:30:03*adriano` joined #nim
13:36:21FromDiscord<Kiloneie> Are there only 3 ways of calling procedures or are there more ? https://play.nim-lang.org/#ix=2154
13:36:58Araqyou can also use named parameters
13:37:15Araqand you can put stuff in backticks
13:38:43narimiranhey @Kiloneie! i was wondering earlier today where have you gone and what happened to you and your videos
13:39:43FromDiscord<Kiloneie> Let's just say i got bored, and played way too many games D:
13:40:00FromDiscord<Kiloneie> Gotta work overtime now <.<
13:40:14FromDiscord<Kiloneie> Video views kept actually growing, so that's nice.
13:40:26*adriano` quit (Ping timeout: 265 seconds)
13:42:52FromDiscord<Kiloneie> Gaming for me is... well it's fun when im getting better and winning, when im not, im like what am i doing with my life... i don't think i can make anything out of that on YT or Twitch i just suck at talking.
13:43:25FromGitter<kaushalmodi> Araq: Yesterday, I boiled down the minimal reproducible example for that crash with GC enabled, to this: https://play.nim-lang.org/#ix=2158
13:44:18Araqkaushalmodi: that means you didn't setup the stack handling properly, I think
13:44:20FromGitter<kaushalmodi> I tried using the compiled .so of that snippet with and without libnimrtl.so, but saw the same crash
13:44:27FromGitter<kaushalmodi> Araq: How do I do that?
13:44:59FromGitter<kaushalmodi> here's the crash when using libnimrtl.so: https://gitter.im/nim-lang/Nim?at=5dc38ff83f4ea333f2c531c8
13:45:27*krux02 joined #nim
13:45:27FromGitter<kaushalmodi> here's the same crash when I do not use libnimrtl.so" https://gitter.im/nim-lang/Nim?at=5dc39052a4541815c8a352a1
13:45:32FromGitter<zacharycarter> could always combine gaming and Nim
13:45:55FromGitter<alehander92> Kiloneie thats why you should upload them from time to time imo, when you have several prepared, you can than rest more
13:46:02FromGitter<alehander92> and views might still keep coming
13:46:37FromGitter<zacharycarter> I just can't stand watching video tutorials - I can read / scan documents faster than folks can talk.
13:46:53FromDiscord<Kiloneie> yeah i know
13:47:13FromGitter<zacharycarter> If the video has a table of contents, that's slightly better, but still overall textual tutorials are so much nicer. Unless there's a lot of visual interaction required for the given subject.
13:47:23FromDiscord<Kiloneie> i got frustrated with the amount of work it went into every video
13:47:37FromDiscord<Kiloneie> idk lots of people prefer video
13:47:53FromDiscord<Kiloneie> i do as well as long as the subject is difficult for me, otherwise like you said
13:48:15narimiranheh, when was it when we told you you need to keep the frequency down? and you were like "naah, guys, i'll be fine" :D
13:48:30FromDiscord<Kiloneie> i do it intentionally very slow and step by step, because i know some people will get lost at any time
13:48:44FromDiscord<Kiloneie> xD
13:49:17FromDiscord<Kiloneie> I gotta do something else other than watch YT or play games when not working on videos, that's the big one
13:49:19AraqI enjoy videos and articles fwiw
13:49:21FromGitter<kaushalmodi> Araq: In summary, I am compiling a .so from Nim code and using it in a host C application (not related to Nim). The .so only has exportc'd procs which are called from the host app. So how do I init the GC on the Nim side? Can I see an example of that somewhere?
13:49:43Araqyou need to call NimMain or similar, it's exported for you
13:50:54FromDiscord<Kiloneie> Like how the deceased YouTuber once said TotalBiscuit to his followers when some said that it should be like a job and all, it really shouldn't if you want to keep doing it.
13:51:50FromGitter<kaushalmodi> Araq: OK, I need to map the signature of NimMain to SystemVerilog too then.. looking up its signature..
13:54:13*Hideki_ joined #nim
13:55:18*Hideki_ quit (Remote host closed the connection)
13:55:50FromGitter<kaushalmodi> Araq: I was able to call NimMain from SV side.. but that did not help prevent the crash
14:03:45*ng0 quit (Remote host closed the connection)
14:04:11*disbot quit (Remote host closed the connection)
14:04:54*ng0 joined #nim
14:24:13*disruptek frowns.
14:24:18PMunchHow do I free a pointer that I get from a C call in Nim ?
14:25:17*disbot joined #nim
14:25:23disruptekany way you want.
14:26:02disruptekdisbot: do me a favor and just hang out in here; don't disconnect randomly.
14:26:02disboton it. 👍
14:26:09disrupteklol okay
14:26:56PMunchdisruptek, helpful..
14:27:09PMunchI think something else might be going on here though..
14:27:19shashlick@PMunch you can wrap free
14:27:36disruptekbad things happen after you free it?
14:28:38FromGitter<mratsim> the C library should provide you with a free or delete function
14:28:39PMunchWell, it seems like bad things are happening no matter what I do..
14:28:50disruptekstory of my life.
14:28:53PMunchHaha
14:29:12FromGitter<alehander92> ansi_c ?
14:29:28FromGitter<alehander92> lib/system/ansi_c wraps malloc free etc
14:29:28disrupteki wouldn't free anything until you know memory corruption isn't the cause.
14:29:57PMunchalehander42, oh neat
14:30:07PMunchWell I have no idea what's going on..
14:30:08FromGitter<alehander92> i am 92 now !
14:30:17FromGitter<alehander92> i have to make a bot.
14:30:35FromGitter<alehander92> gdb it
14:30:43FromGitter<alehander92> watchpoints are a good tool
14:30:45FromGitter<mratsim> You should call it HAL
14:30:50FromGitter<mratsim> HAL92
14:31:18FromGitter<alehander92> no, i have my own bot names arthur clarke
14:31:31FromGitter<kaushalmodi> Anyone? Can I see an example how NimMain from a linked Nim compiled .so is called in an external program?
14:34:19PMunchI think it's called by _init()
14:34:54FromGitter<kaushalmodi> My .so only has exported procs
14:35:16FromGitter<kaushalmodi> So from the host C appl I need to call "something" to init the GC
14:35:36FromGitter<kaushalmodi> I called the auto-exported NimMain, but that didn't make any difference
14:35:39PMunchdlopen will call _init in a dynlib before it returns
14:35:44*dddddd joined #nim
14:35:48Araqkaushalmodi: just a sec please
14:35:55PMunchWhich I believe is set up to call NimMain
14:36:11PMunchOr maybe not :P
14:36:15FromGitter<kaushalmodi> Araq: OK
14:36:27PMunchThis should really be documented better somewhere..
14:37:45FromGitter<mratsim> Nim DLL usage really needs a blog post and/or an good doc/tuto
14:38:09Araqkaushalmodi: please check if NimMain ends up calling initStackBottomWith()
14:38:27PMunchI'd love to write one, but I haven't been able to piece together enough information to know exactly what's going on..
14:39:10PMunchI mean, I am writing a so/dll right now that will be loaded by a C program. It works, but I have no idea if the GC is running properly..
14:40:26*GordonBGood quit (Ping timeout: 240 seconds)
14:40:56FromGitter<kaushalmodi> Araq: How do I check that? Are there some debug functions I can call from the host C appl to verify that?
14:41:19AraqI would inspect the generated C code
14:42:04FromGitter<kaushalmodi> I'm away from the PC for few minutes (in a meeting), but last I checked, NimMain in see was probably calling that stack function
14:42:20FromGitter<kaushalmodi> Will paste a snippet of the generated NimMain soon
14:42:28FromGitter<alehander92> PMunch you should really run it under a debugger imo
14:43:32PMunchalehander92, ugh that would be a pain to set up..
14:44:14FromGitter<mratsim> with —debugger:native, and breakpoint you should be able to use it
14:44:28Araqso ... I checked the produced code
14:45:18PMunchmratsim, how do I set a breakpoint in a dynlib before it is loaded?
14:45:33Araqand you don't have to call NimMain at all!
14:45:39AraqNIM_POSIX_INIT does it for you
14:45:48PMunchYeah, that's what I thought
14:46:07PMunchWhich is why I don't
14:46:26PMunchBut since that's not actually documented anywhere I wasn't sure if the GC was even running at all
14:46:30Araqnim c -d:useNimRtl --app:lib tests/dll/server.nim
14:46:31FromDiscord<Chiqqum_Ngbata> What effect would calling NimMain() have
14:46:50*thomasross quit (Remote host closed the connection)
14:46:51Araqis what the testsuite uses and the tests are green on all major OSes
14:46:57PMunchWhat happens if you don't have -d:useNimRtl but it's the only Nim code that would run?
14:47:01Araqand the tests cover the GC
14:47:14*thomasross joined #nim
14:47:16FromGitter<kaushalmodi> Araq: then how do I proceed with that issue?
14:47:27AraqPMunch: then it should work too but it's pretty much unsuported, can't test everything
14:47:34PMunchA C program loading a Nim dynlib is what I'm doing. And I don't use -d:nimrtl
14:47:38Araqkaushalmodi: do you use -d:useNimRtl?
14:47:48FromGitter<kaushalmodi> I tried with and without, same crash
14:47:55FromGitter<kaushalmodi> (see the above gdb backtraces)
14:48:13FromGitter<kaushalmodi> one goes up to the markSweep.. proc in librlt
14:48:32FromGitter<kaushalmodi> another goes into the gc.nim packed as part of the .so compiled without nimrtl
14:48:53FromGitter<kaushalmodi> Araq: backtraces at https://gitter.im/nim-lang/Nim?at=5dc41fb4a9f0dc24852bce75
14:49:42Araqdoes the C code use threads?
14:51:42FromGitter<alehander92> PMunch i think there was a way to add a breakpoint inline
14:51:46FromGitter<alehander92> maybe if you just add an interrupt
14:51:48*Hideki_ joined #nim
14:51:49FromGitter<alehander92> with inline assembly
14:51:51FromGitter<alehander92> this might work
14:52:16FromGitter<alehander92> https://stackoverflow.com/questions/3634124/why-does-int-3-generate-a-sigsegv-in-64-bit-instead-of-stopping-the-debugger
14:53:04FromGitter<kaushalmodi> Araq: I think, yes
14:53:12PMunchOh wait, now everything works fine. I had just imported the C procedure wrong -_-
14:53:18FromGitter<kaushalmodi> the host C app probably uses threads
14:53:27FromGitter<alehander92> https://stackoverflow.com/a/49079078
14:53:30FromGitter<alehander92> maybe a better one
14:53:37Araqthen you need to call setupForeignThreadGC() in your .exportc proc
14:53:40FromGitter<kaushalmodi> it's a full blown commercial applicaton
14:53:48FromGitter<alehander92> ah good: still interesting to notice one can do similar thing to javascript's `debugger`
14:53:57FromGitter<kaushalmodi> Araq: do I call that in each exported proc?
14:54:08Araqyes
14:54:14FromGitter<kaushalmodi> thanks, let me try that
14:54:16Araqat least it can't hurt
14:56:59*Hideki_ quit (Ping timeout: 276 seconds)
14:57:50FromGitter<Vindaar> maybe also check what @yglukhov does in nimpy? https://github.com/yglukhov/nimpy/blob/master/nimpy.nim#L213-L219 and https://github.com/yglukhov/nimpy/blob/master/nimpy.nim#L994-L1009
14:57:50*luis_ joined #nim
14:58:20PMunchalehander42, tried with {.emit: """__breakpoint(42);""".} and that crashes with an unassigned error on runtime :S
14:58:26FromGitter<kaushalmodi> @Vindaar I looked at that yest when rayman pointed it out
14:58:33FromGitter<kaushalmodi> but it is related to --threads:on
14:58:38PMunchOh wait, that was for ARM..
14:58:44FromGitter<kaushalmodi> does it mean I need to compile my .so with --threads:on?
14:58:53FromGitter<kaushalmodi> (some many new revelations today)
14:59:21Araqyeah, in fact, you do need --threads:on
14:59:31FromGitter<Vindaar> ok, I'm pretty cluesless on this too :)
14:59:44FromGitter<kaushalmodi> oh boy.. I forsee a big rabbit hole
15:00:01FromGitter<kaushalmodi> both threads and gc are foreign to me.. will try it out though
15:02:26PMunchalehander92, {.emit: """raise(SIGTRAP);""".} and an {.emit: """#include <signal.h>""".} worked like a charm with --debugger:native
15:03:59PMunchWould be neat if this was a nimble module with all the portable versions
15:04:08*ponyrider quit (Read error: Connection reset by peer)
15:04:23FromGitter<kaushalmodi> Araq: now I have http://ix.io/215v/nim and compiled with --threads:on, but the same crash
15:04:23disbot^ play at https://play.nim-lang.org/#ix=215v 😏
15:05:20PMunchdisruptek, maybe we could have a !playground command to your bot that turns the last ix.io link into a playground link instead?
15:05:35PMunchA lot of Nim code snippets doesn't really make sense to run in the playground :P
15:06:12Araqkaushalmodi: what's your CPU/OS?
15:06:21disruptekit's as much for us as it is for a newbie posting links.
15:06:22FromGitter<kaushalmodi> 64-bit RHEL 6.8
15:07:16Araqkaushalmodi: .exportc, cdecl
15:07:20shashlickIt's not a callback is it?
15:07:36Araqbut apart from that I'm running out of ideas, this should work :-(
15:08:28*luis_ quit (Ping timeout: 264 seconds)
15:08:33shashlickWhy do you need to setup foreign gc - it's being called by pure C
15:09:33FromGitter<kaushalmodi> Araq: sorry, that also did not help.. here's the full bt from valgrind: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5dc433adbbdf5f17b420b9fc]
15:10:25FromGitter<kaushalmodi> I see many of these.. is that concerning?: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5dc433e13f4ea333f2c53234]
15:15:15FromGitter<alehander92> PMunch nice
15:15:22FromGitter<alehander92> i cant believe i havent used it much
15:16:17FromGitter<alehander92> you can even start such a program and attach to it with `attach -p `
15:16:25FromGitter<alehander92> from what i read
15:17:40FromGitter<alehander92> currently you can use `raise` from posix
15:18:16FromGitter<alehander92> and SIGTRAP as well
15:18:54FromGitter<alehander92> so maybe you can do it without emit at least, but yeah we can do a `breakpoint()` experimental api
15:19:10FromGitter<kaushalmodi> Araq: In the backtrace, I see `/lib64/libpthread-2.12.so`
15:19:30FromGitter<kaushalmodi> Is there some pthread version dependency/mismatch that could be causing this?
15:20:09*PMunch quit (Quit: Leaving)
15:21:08FromGitter<kaushalmodi> The backtrace is leading to the last `gcMark` call in this snippet from gc_common.nim: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5dc436633f4ea333f2c5323b]
15:22:45Araqthat's a false positive by valgrind
15:22:57Araqbut also compile with -d:noSignalhandler
15:23:11FromGitter<kaushalmodi> trying *now*
15:25:13FromGitter<kaushalmodi> still the same crash and backtrace
15:25:34FromGitter<kaushalmodi> the signal handling is done by the host C app here, right?
15:25:51Araqyes
15:25:57FromGitter<Willyboar> @citycide are you here
15:25:58FromGitter<Willyboar> ?
15:26:09FromGitter<kaushalmodi> Araq: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5dc43791a4541815c8a352f9]
15:26:26FromGitter<kaushalmodi> something happens in libpthread and triggers the serror handler in the host app
15:26:45Araqi'm out of ideas, try --gc:boehm please
15:29:38FromGitter<kaushalmodi> If I do --gc:boehm, I get: ⏎ ⏎ > libdpi.nim(11, 7) Error: undeclared identifier: 'setupForeignThreadGc'
15:30:57FromGitter<kaushalmodi> ok.. so if I remove all the setupForeignThreadGc stuff and run with --gc:boehm, it works fine!
15:31:03FromGitter<kaushalmodi> what does this mean?
15:31:24Araqit means we still get the stack pointers wrong but I dunno why
15:31:47Araqthe good news is that --gc:destructors doesn't have this problem
15:32:03FromGitter<kaushalmodi> is --gc:boehm production safe?
15:32:07Araqso please use --gc:boehm until --gc:destructors is ready
15:32:10FromGitter<kaushalmodi> (I have never used it)
15:32:30Araq--gc:boehm is production ready, it's covered by our test suite, I regularly use it with 'koch boot'
15:32:40FromGitter<zacharycarter> I wonder if that's a similar issue to what I was running into with hot reloading?
15:32:48FromGitter<kaushalmodi> seems like I might not even need --threads:on. -d:noSignalHandler
15:32:53Araqzacharycarter: most likely
15:33:00*tklohna quit (Ping timeout: 268 seconds)
15:33:10Araqyeah boehm is pretty robust against switches like these
15:33:42FromGitter<kaushalmodi> Araq: thanks for sticking through and helping with this
15:34:00FromGitter<zacharycarter> I think fowlmouth's libraries / code will remain infinitely useful forever
15:34:05FromGitter<kaushalmodi> let me know if there's anything I can provide further to help debug the root cause
15:34:15FromGitter<kaushalmodi> I can reproduce that crash 100% of the times with the default gc
15:34:29FromGitter<zacharycarter> I'm using his enet bindings and the helper module he wrote for creating packets
15:34:34Araqit's interesting but I would need access to the machine
15:34:46Araqand I'd rather spend the effort on --gc:destructors tbh
15:34:59FromGitter<kaushalmodi> Araq: ok
15:35:16FromGitter<kaushalmodi> Let me check with Cadence if I can get a temp license for you to try out
15:35:31FromGitter<kaushalmodi> .. to run their SV simulator
15:36:00FromGitter<kaushalmodi> the SV side code is pretty trivial: http://ix.io/215G
15:36:01disbot^ play at https://play.nim-lang.org/#ix=215G 😏
15:36:12FromGitter<kaushalmodi> ok disbot.. that was SystemVerilog
15:36:26FromGitter<kaushalmodi> anyone not knowing SV can read what it's doing
15:36:48FromGitter<kaushalmodi> the `imported_func` that I exporc from Nim is "import"ed into SV
15:36:55disruptekhttp://ix.io/215G/SV
15:37:09disruptekif you give it a type that isn't nim, the bot will ignore it.
15:37:18FromGitter<kaushalmodi> got it
15:37:27FromGitter<kaushalmodi> that link did not work, but this works: http://ix.io/215G/sv
15:37:35disruptekfwiw 😊
15:37:35shashlick@kaushalmodi - how complex is your nim code here
15:37:36FromGitter<kaushalmodi> seems like ix.io is case sensitive
15:38:12disruptekthey both work for me.
15:38:19FromGitter<kaushalmodi> shashlick: laughably uncomplex: http://ix.io/215I/nim
15:38:19disbot^ play at https://play.nim-lang.org/#ix=215I 😏
15:41:33*nsf joined #nim
15:45:18FromGitter<kaushalmodi> Here's the dummy code to reproduce that crash: https://github.com/kaushalmodi/nim-systemverilog-dpic/tree/master/gc_crash_debug
15:46:18*tklohna joined #nim
15:55:33FromGitter<kaushalmodi> Araq: I got a crash on boehm too, using a slightly more complex code. bt: http://ix.io/215R/text
15:56:11FromGitter<kaushalmodi> the above link renders weird with /text.. just remove that
15:56:23Araqbummer
15:56:42Araqso your stack is corrupt, do you use .bycopy for all your imported objects?
15:57:45FromGitter<kaushalmodi> the objects from SV to Nim are passed via pointer
15:58:35FromGitter<kaushalmodi> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5dc43f2bbbdf5f17b420ba12]
15:59:16FromGitter<kaushalmodi> the svOpenArrayHandle is an API .. it's basically a void* ptr
16:00:18FromGitter<kaushalmodi> it's a ptr to a dynamic array on SV side.. there another API to fetch each elem of that dyn array.. I get a ptr to each elem of that: ⏎ ⏎ ```arrElemPtr = cast[ptr XY](svGetArrElemPtr1(arrPtr, i))``` [https://gitter.im/nim-lang/Nim?at=5dc43f910725f61e9c80ce27]
16:00:26FromGitter<kaushalmodi> so I am not sure where to use bycopy
16:01:25*narimiran_ joined #nim
16:01:59*narimiran quit (Ping timeout: 250 seconds)
16:05:36FromGitter<kaushalmodi> Araq: I wrap that SV API header file using nimterop to generate this: http://ix.io/215T
16:06:07FromGitter<kaushalmodi> I see that .bycopy. is not auto-inserted there.. would it be correct to blindly add .bycopy. everywhere?
16:06:15disbot^ play at https://play.nim-lang.org/#ix=215T 😏
16:09:38Araqpretty much yeah, every imported object should by .bycopy
16:09:51Araqyou're right that it probably won't change things but it also doesn't hurt
16:11:00disrupteknimph search via github query syntax: http://ix.io/215U
16:11:01disbot^ play at https://play.nim-lang.org/#ix=215U 😏
16:11:18disruptekdisbot: quiet down, young'un.
16:11:19disboton it. 👍
16:13:40Araqkaushalmodi: what *else* is valgrind reporting?
16:13:53Araqusually the real problem is also in its log
16:14:03Araqnot only false positives
16:16:02*floppydh quit (Quit: WeeChat 2.6)
16:17:41Araqsay what you want but '.since' is sexy, https://github.com/nim-lang/Nim/pull/12600/files
16:17:56Araqesp the fact that it's a 3 line implementation
16:18:02FromGitter<kaushalmodi> Araq: brb in 10 mins
16:18:37disruptekAraq: does it work with tuples of len 3?
16:18:54Araqno because semver
16:19:01disruptekit should get special doc handling.
16:19:14Araqindeed but then its simplicity is lost
16:19:28Araqbut yeah, it needs docgen support
16:19:50disrupteksplitPath was a pretty damaging change considering it was in a patch.
16:19:55disruptekalso, the base64 change.
16:20:20disrupteki actually had to just copy the previous splitPath and use that to guarantee stability.
16:20:33disrupteknot really the idea behind a stdlib...
16:20:51Araqouch, I wasn't aware
16:21:04Araqwe might need to revert this splitPath change then
16:21:36disruptekthat's part of why i forked it into my codebase. 🤣
16:21:50Araqanyway, the idea behind --useVersion:1.0 is a "best effort emulation", some minor things like base64 are acceptable for now
16:22:41disruptekwell, anyway, since sounds good but while stuff breaks in patch-level releases, it's insufficient.
16:22:44AraqI was sceptical about splitPath but every "important package" was green as well as my compiler which is usually fragile about these things
16:23:08disrupteki think golden is broken too but i haven't looked at it. seemed more important to get aws apis working again.
16:23:22*Hideki_ joined #nim
16:23:26Araqso that's why I accepted splitPath. now you tell me I shouldn't have
16:23:34Araqraise your voice earlier please
16:23:44disrupteksorry, i was 8 days behind on `devel`.
16:23:51Araq:-)
16:23:58*Hideki_ quit (Remote host closed the connection)
16:24:18Araqbut notice that devel is not a patch-level release
16:24:28Araqthat would be the version-1-0 branch
16:24:32*Hideki_ joined #nim
16:24:34disruptekwhen this stuff goes in, it kinda needs to stay in. i just wish there'd be a deprecated version that was retained.
16:24:59disruptekthere's some subtlety to splitPath, or my use of it, that was hard to grok.
16:25:48AraqI think I'll revert it, I personally dislike "yeah, let's break it, it's INCONSISTENT with something else, who cares about existing users"
16:26:04Araqeverything is always inconsistent to something ffs
16:26:17*narimiran_ is now known as narimiran
16:26:23FromGitter<alehander92> consistency is cool
16:26:25Araqit's the most overrated word in programming.
16:26:30FromGitter<alehander92> what is inconsistent about splitPath
16:26:33FromGitter<alehander92> its really not
16:26:34narimiranbtw, disruptek, i can ping you once 1.0.4 is ready for beta-testing
16:26:55FromGitter<alehander92> if you have an api where half of the case are function(path, line) and function(line, path) its just confusing
16:27:00Araqin C# land there is .Length vs .Count vs .Count() and yet it survives
16:27:03FromGitter<alehander92> yeah autocomplete and types help
16:27:07FromGitter<alehander92> but its just confusing
16:27:15disrupteknarimiran: okie, but i actually require 1.1.1 for a lot of stuff now. i will try it for my public things.
16:27:39disruptekbecause nimph requires 1.1.1 because of compiler fixes... 🙂
16:27:49FromGitter<kaushalmodi> > *<Araq>* we might need to revert this splitPath change then ⏎ ⏎ I did have my reservations on that PR and pinged @timotheecour .. but looks like he's been away for a while
16:28:05FromGitter<alehander92> btw krux02
16:28:09narimiranhe's not the authority ;)
16:28:20FromGitter<alehander92> those bugs with csize for one of the modes i got them
16:28:24FromGitter<alehander92> with os:standalone
16:28:26FromGitter<alehander92> as well
16:28:29FromGitter<alehander92> iirc
16:28:59disruptekmaybe take a look at sigv4 package and see if you want it in important packages. it's very tiny, though. but it would at least ensure that aws signing doesn't break.
16:29:07*Hideki_ quit (Ping timeout: 265 seconds)
16:29:21Araqdisruptek: did your tests catch it?
16:29:25disruptekyep.
16:29:49Araqinteresting. Do you happen to misuse os procs on URLs? :P
16:29:59disruptekbut i released a new version with safeSplitPath, so it won't notice if you roll splitPath back.
16:30:10Araqyeah I understand
16:30:46disruptekos path procs are just string manipulation procs. 😁
16:32:10FromGitter<kaushalmodi> narimiran: He was the most active person in defining and discussing all the path splitting use cases
16:34:02disruptekAraq: fwiw, the base64 change broke google api signing. nim-jwt is the relevant package there.
16:34:13Araq:-(
16:34:17Araqbummer
16:34:33Araqbut at least that one was marked as "unstable API"
16:34:54Araqdoes it work now?
16:35:23disrupteksince i PR'd it, yes. though i had to patch it twice because nim grew to be 1.1.0 while my patch was under review.
16:35:43disruptekand afaik, treeform is the only person using my google api code.
16:35:47disruptekyou just can't make this stuff up.
16:40:24FromGitter<kaushalmodi> Araq: the full valgrind log: http://dpaste.com/01XD7M4 .. but when I run the SV compiler with its -valgrind option, the crash doesn't happen :/
16:40:41AraqI know one other party *very* interested in this code, disruptek.
16:41:10disruptekhow mysterious.
16:41:17FromGitter<kaushalmodi> Without valgrind, the crash happens after the "Saving plot .." line: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5dc4492da4541815c8a35316]
16:42:10FromGitter<kaushalmodi> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5dc449623f4ea333f2c53278]
16:42:40*tklohna quit (Ping timeout: 264 seconds)
16:43:04*tklohna joined #nim
16:43:49AraqWarning: client switching stacks? SP change: 0x7feff3140 --> 0xf32fc00
16:44:15*nsf quit (Quit: WeeChat 2.6)
16:44:26Araqnever seen a warning like this before, this C code is doing dangerous crap
16:45:22AraqInvalid read of size 8
16:45:22Araq==2218== at 0x62EED50: ???
16:45:26*Vladar quit (Quit: Leaving)
16:45:33Araq^ looks like you're in serious trouble
16:47:04FromGitter<kaushalmodi> looks like the host C app is doing the switching stacks thing
16:47:22FromGitter<kaushalmodi> and then the switching reverts after the Nim code finishes? running
16:47:27FromGitter<kaushalmodi> and that's where the crash happens
16:47:50FromGitter<kaushalmodi> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5dc44ab66570b076740f773a]
16:49:45Araqswitching stacks is not C btw as C has no idea about the involved runtime stacks
16:49:45disruptekmore irony: nimble breaks on my --define:key:val fix.
16:50:28Araqso we are not dealing with "C code" here but with something else
16:51:11Araqif you are on devel, please give --gc:destructors a try
16:51:32Araqit's in development but it's the only GC that doesn't trace the stack
16:51:40Araqso maybe you're lucky and it works for you already
16:52:11disruptekshashlick: this means i can't install nimgit2 with nimble. also, it doesn't work in nimble anyway because it's still looking for a doc directory that doesn't exist when nimble is performing the installation.
16:52:12FromGitter<kaushalmodi> > Error: unhandled exception: liftdestructors.nim(332, 14) `t.assignment != nil` [AssertionError]
16:52:14*clyybber joined #nim
16:52:26FromGitter<kaushalmodi> I am unlucku :/
16:52:33FromGitter<kaushalmodi> s/unlucku/unlucky
16:52:47Araqhow to reproduce?
16:54:13FromGitter<kaushalmodi> it's not giving a full backtrace. that's the only error.. let me figure out how it can be reproduced.. right now it used svdpi.nim which requires svdpi.h
16:55:14FromGitter<kaushalmodi> I ran another arbitrary code and I got: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ but that also uses svdpi.nim [https://gitter.im/nim-lang/Nim?at=5dc44c71a9f0dc24852bcebf]
17:03:15Araqoh I wasn't aware you use xml and stuff
17:03:38*NimBot joined #nim
17:04:13FromGitter<kaushalmodi> that xml stuff is probably pulled in by other nimble packages
17:04:51*theelous3 joined #nim
17:12:19shashlick@disruptek - what's the issue? the CI seems to work
17:12:33shashlickis it looking for nimterop/doc
17:12:52disruptekyeah.
17:18:11FromGitter<kaushalmodi> Araq: Recipe for the above move[T] error: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ Probably compiling just parsexml.nim will also do that, but I was just tracing why my "little" example failed.. because it was importing nimetry [https://gitter.im/nim-lang/Nim?at=5dc451d3a4541815c8a35321]
17:18:28Araqthat one is already fixed
17:18:37AraqI'm interested in the AssertionError
17:18:37FromGitter<kaushalmodi> oh is it?
17:18:49FromGitter<kaushalmodi> ok, finding recipe for that now
17:24:24FromGitter<kaushalmodi> Araq: Here's the recipe: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ > fatal.nim(39) sysFatal ... [https://gitter.im/nim-lang/Nim?at=5dc45348a85791488f89617f]
17:29:23*Vladar joined #nim
17:29:28shashlick@disruptek - do you have nimterop installed?
17:30:14shashlickor is it failing during nimble install which should install deps
17:30:24*berndl joined #nim
17:31:50shashlickhttps://github.com/genotrance/nimgit2/blob/master/nimgit2.nimble#L18 should be helping - if not i need to look at it again
17:31:54*luis_ joined #nim
17:32:14shashlicki guess i'm not testing a clean install in travis
17:32:58disrupteki'm not sure how the .nimble should be written, or if it needs to be rewritten, to work with localdeps.
17:33:18disrupteki have to fix the compiler to accept a define of `0.28.3` first. 🙁
17:34:52shashlickcan you explain some details on the issue?
17:36:02disruptekError: cannot open file: nimterop/docs
17:37:31FromGitter<kaushalmodi> import nimterop/docs is in nimterop.nimble
17:37:38disruptekyep.
17:38:05shashlickam testing on linux, a sec
17:38:42disrupteki wouldn't spend any time on it yet.
17:39:29FromGitter<kaushalmodi> fwiw, `nimble uninstall nimterop -i && nimble install nimterop` worked fine for me (RHEL 6.8)
17:39:59FromGitter<genotrance> gt@gt:~/programming/a$ nimble install nimgit2 --nimbleDir:abc ⏎ ⏎ ``` Info: Dependency on unicodedb@>= 0.7 already satisfied``` ⏎ ⏎ Verifying dependencies for [email protected] ... [https://gitter.im/nim-lang/Nim?at=5dc456ee9c39821509fe1e7d]
17:40:26disruptekyes; it's a localdeps thing -- that's why i suggest not working on it until i can offer something useful.
17:40:49FromGitter<mratsim> Seems like the most popular package manager written in Nim bit the dust: https://github.com/kitsunyan/pakku/pull/49
17:40:51shashlickokay i'll hold off
17:41:38*nsf joined #nim
17:41:47disruptekwritten in a stillborn programming language?
17:46:42disruptekoh, --define:getSetVer2:"0.28.3" works.
17:46:54disrupteki'm just an idiot.
17:47:19FromGitter<kaushalmodi> or use config.nims :)
17:47:32disruptekno way.
17:50:36clyybberAraq: Huh, why does parsexml need this changes?
17:50:59Araqclyybber: 'move' is destructive, shallowCopy isn't
17:52:35clyybberMaybe it was too long since I last worked on nrt but didn't we keep the implementation so that move isn't destructive and we just insert wasMoved?
17:53:18clyybberAh, sorry. Was mixing things up, I'm thinking about =sink
17:54:24clyybberHmm
17:54:53clyybberAraq: Wouldn't it be better to change the parameter to sink T instead of var T?
17:54:56shashlickwhy do you need SetVer2? <= 2
17:55:03clyybberWe should still be able to move sink T parameters.
17:55:19shashlickyou mean -d:git2SetVer?
17:55:32disruptekyeah.
17:56:18Araqclyybber: I considered it but I think 'var T' is better
17:56:47Araqit's a move, it's destructive, otherwise 'move(notLastRead)' would compile and produce a copy!
17:56:58clyybberAraq: It shouldn't matter unless you try to access the XmlParser after using rawData.
17:57:03Araqand then it would move the copy, never what I intended
17:57:12clyybberAh ok.
17:57:47Araqit's pretty well designed now, if only the compiler was stable
17:57:50clyybberI didn't look too much into it. If mutating XmlParser is better than copying it in this then I wasn't aware
17:57:59clyybberAraq: Yeah its pretty cool.
18:01:12lqdev[m]is it safe to cast a `ptr T` for a `var T` when a proc expects that as a param? https://play.nim-lang.org/#ix=216y
18:01:51disruptekshashlick: does nimterop work for you in localdeps? it installs but i can't successfully run the tests, even with toast in my path.
18:01:56Araqlqdev[m]: yes
18:03:18lqdev[m]ah, good.
18:03:20*lritter joined #nim
18:06:21clyybberAraq: How can I quickly print an TLineInfo for compiler debugging purposes?
18:07:56*nc-x joined #nim
18:08:04*berndl quit (Quit: WeeChat 2.5)
18:08:21nc-xclyybber: just print its fields instead of the whole object iirc
18:08:22*rockcavera quit (Remote host closed the connection)
18:10:27*Trustable joined #nim
18:11:04disruptekshashlick: okay, seems to work perfectly if i set NIMBLE_DIR to the localdeps directory.
18:11:07*nc-x quit (Remote host closed the connection)
18:12:33*GordonBGood joined #nim
18:17:11*GordonBGood quit (Ping timeout: 276 seconds)
18:17:46Araqclyybber: c.config $ n.info
18:18:05Araqyou need a ConfigRef but there is always one hanging around
18:18:30clyybberThanks
18:18:42clyybbernc-x: Thanks, but I need the filename too :)
18:22:32*rockcavera joined #nim
18:23:44FromGitter<kaushalmodi> Araq: I rebuilt nim and now the parsexml error when using --gc:destructors is gone, but
18:23:54FromGitter<kaushalmodi> now I get this at run time: ⏎ ⏎ ```Saving plot to plot.png .. ⏎ [FATAL] unpaired dealloc``` [https://gitter.im/nim-lang/Nim?at=5dc461390725f61e9c80ce5c]
18:24:06FromGitter<kaushalmodi> there's no except.. just that print statement
18:24:11FromGitter<kaushalmodi> *exception
18:24:28FromGitter<kaushalmodi> and it's happening just where it crashes when using boehm
18:24:38Araqer
18:24:46Araqdo you use 'ref' in your wrapper?
18:24:53Araqinstead of 'ptr'?
18:25:29FromGitter<kaushalmodi> no: http://ix.io/216C/nim
18:25:30disbot^ play at https://play.nim-lang.org/#ix=216C 😏
18:25:52FromDiscord<mratsim> btw in the destructors spec, you don't talk about {.threadvar.} are destructors of thread-local variables inserted before a thread is joined?
18:26:06FromGitter<kaushalmodi> above error is without the -d:useGgplot
18:26:15FromDiscord<mratsim> it seems like for C++ it causes a lot of stack overflow issues
18:26:18FromGitter<kaushalmodi> with -dLuseGgplot, I get that assertion error
18:27:33FromGitter<kaushalmodi> Araq: to make it simpler, this is what I am running effectively: http://ix.io/216D
18:27:34disbot^ play at https://play.nim-lang.org/#ix=216D 😏
18:28:43FromGitter<kaushalmodi> The FATAL happens in line 63
18:28:55*jjido joined #nim
18:29:00FromGitter<kaushalmodi> somewhere in the nimetry/flippy pkg when the file save is happening
18:30:10FromGitter<kaushalmodi> ok, you can recreate the FATAL using this same recipe above: https://gitter.im/nim-lang/Nim?at=5dc451d3a4541815c8a35321
18:31:27*luis_ quit (Quit: luis_)
18:31:53*luis_ joined #nim
18:39:47*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:42:11*snwmzr quit (Remote host closed the connection)
18:46:09Araqkaushalmodi: compile with -d:useSysAssert -d:useGcAssert and the default GC please
18:46:39shashlick@disruptek so --cleanNimbleDir isn't working?
18:46:44Araqmratsim: uhm, they are not, good point
18:47:18shashlickOr you running nimble actually
18:47:57disruptekshashlick: everything works if you set NIMBLE_DIR. i'm just testing nimble; you can use nimble to install nimph.
18:49:55*fredrik92 joined #nim
18:50:20*couven92 quit (Disconnected by services)
18:50:24*fredrik92 is now known as couven92
18:50:41FromGitter<kaushalmodi> Araq: With those defines and the default GC, I get the same crash: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5dc46781a4541815c8a3534a]
18:50:45*fredrik92 joined #nim
18:56:26FromGitter<kaushalmodi> woo! I can see more info in valgrind though: http://ix.io/216J/text
19:05:51*uu91 quit (Read error: Connection reset by peer)
19:06:05FromGitter<kaushalmodi> Araq: Here's what I see when using those defines and default GC with that earlier minimal Nim code: http://ix.io/216M/text
19:06:10*uu91 joined #nim
19:06:42shashlickOk how about using nimbleDir
19:06:46shashlickIt doesn't work?
19:07:18*eys quit (Quit: eys)
19:07:19disruptekno, probably because you have a gorgEx call to `nimble` which picks up the global env.
19:08:31shashlickI see ya, there's another issue from as @kaushalmodi where I don't propagate paths to child Nim processes
19:08:59disruptekoh yeah, the one his cow-orker ran into?
19:09:02shashlickUnless I can find out flags Nim was called with, no way to know that one
19:09:11FromGitter<kaushalmodi> disruptek: hah! yes :)
19:09:15FromGitter<kaushalmodi> my coworker is famous
19:09:25disruptekbetter than infamous.
19:10:18*uu91 quit (Ping timeout: 252 seconds)
19:10:45*uu91 joined #nim
19:26:58*clyybber quit (Quit: WeeChat 2.6)
19:27:42*rayman22201 quit (Quit: Connection closed for inactivity)
19:31:32*luis_ quit (Quit: luis_)
19:37:05Araqshashlick: oh look I have to look into ...nimble/pkgs/nimetry-0.4.0/nimetry.nim
19:37:40Araqkaushalmodi: can show me this file please?
19:38:48shashlickI'm benched, getting itchy though
19:39:24shashlickThinking of redoing px in Nim with libcurl
19:40:01shashlickhttps://github.com/genotrance/px
19:40:36shashlickToo much work though
19:40:51Araqsorry, didn't want to annoy you
19:41:14Araqtried to prove my point, all the time I have to look at what is "hidden" away
19:41:21*rockcavera quit (Remote host closed the connection)
19:45:12*uu91 quit (Read error: Connection reset by peer)
19:45:38*uu91 joined #nim
19:45:42shashlickNot at all, just restless
19:45:54FromGitter<kaushalmodi> Araq: https://github.com/benjif/nimetry/blob/master/nimetry.nim
19:48:47*nif_ quit (Quit: ...)
19:48:57*nif joined #nim
19:52:57*jjido joined #nim
19:59:52*rockcavera joined #nim
20:07:17zedeusI recall "openArray" simply being a way to accept both seqs and arrays as parameters, but since openArray is all about borrowing/memory safety now, it causes issues with async
20:07:19zedeushttps://play.nim-lang.org/#ix=2177
20:07:26zedeusis there a way to solve this problem?
20:12:18AraqopenArray always was a borrowed pointer and for async it must be put onto the heap
20:12:24Araqworkaround: use a 'seq'
20:15:14zedeusso the workaround to use the nice `{key: val}` syntax is adding `toSeq`
20:16:15zedeusI guess it's worth noting the "Open arrays" part of the manual doesn't mention anything about being a borrowed pointer
20:18:52Araqwell it is a (pointer, len) pair, it never was anything else
20:19:09Araqand the pointer doesn't own the memory, nowadays known as "borrowing"
20:19:20Araqwhen I wrote the manual Rust wasn't a thing.
20:23:19Araqit's not like "boo! no Rust in my Nim lang please!", we have comparable designs since forever in Nim and we too must refine them further.
20:24:14FromGitter<mratsim> we must borrow them further
20:27:53Araqeven C# has the same problems, cannot have an 'out' parameter in an async function.
20:28:32Araqultimately C#, Rust, C++, Nim are all the same language :P
20:32:48*GordonBGood joined #nim
20:32:50*thomasross quit (Remote host closed the connection)
20:33:16*thomasross joined #nim
20:35:34*nsf quit (Quit: WeeChat 2.6)
20:45:50*thomasross quit (Remote host closed the connection)
20:46:15*thomasross joined #nim
20:52:03*GordonBGood quit (Ping timeout: 265 seconds)
20:52:11*GordonBGood joined #nim
20:53:40FromDiscord<krab4t> with difference ` isNil is user-defined error `
20:55:24*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:57:52Araqwell if details matter then Nim is better :P
20:58:50GordonBGoodAraq: Yup, Nim is getting much better :)
20:59:09AraqGordonBGood: I'm back at fixing destructor bugs
20:59:15Araqall RFCs have been written
20:59:46GordonBGoodAraq: on the RTTI thing, if there is no RTTI except for RootObj derived things, they ref T finalizers go away?
21:00:12Araqfinalizers are replaced by destructors, what else
21:01:28GordonBGoodAraq: that's what I though - there will be a few rough edges to file off do do with the "new" overloads, but --gc:destructors is a major change anyway
21:03:14GordonBGoodAraq: better read the latest RFC's; is there a list of changed ones
21:03:26GordonBGoodGood you are back to destructors
21:05:29GordonBGoodAraq; also missing repr, which I used to use quite a bit - can we re-write repr.nim to not depend on RTTI?
21:19:50GordonBGoodAraq: I see the lent/var/openArray RFC but nothing else new?
21:20:01*Vladar quit (Quit: Leaving)
21:20:34*rayman22201 joined #nim
21:28:59*shashlic- joined #nim
21:30:43*narimiran quit (Ping timeout: 265 seconds)
21:31:21Araqwell yes, I write one RFC per day, sorry
21:33:02FromDiscord<mratsim> For my need at the moment I wrap ptr objects in an object to have destructor (for object pooling), but it doesn't compose well with concepts, and I don't see how to write a clean "PtrLike" concept. Any ideas as simmple as "myConcept is ptr"?
21:36:39GordonBGoodAraq: I just mean "where should we watch for the latest RFC's - https://github.com/nim-lang/RFCs/issues?
21:39:07*revere quit (Ping timeout: 250 seconds)
21:44:56Araqyes
21:45:12*revere joined #nim
21:47:18*clyybber joined #nim
21:47:19*crem quit (Ping timeout: 268 seconds)
21:48:44*crem joined #nim
21:51:34GordonBGoodOkay, I'll watch that for updates
21:51:50*thomasross quit (Remote host closed the connection)
21:52:17*thomasross joined #nim
21:58:28*jjido joined #nim
21:59:05*Trustable quit (Remote host closed the connection)
22:19:50*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:22:28*solitudesf quit (Ping timeout: 268 seconds)
22:28:15*hemite joined #nim
22:29:14hemiteThe Nim Arch Linux packages seem fairly out of date. I was wondering if there were other Arch users here, and their solution to get a working Nim setup on their personal machines
22:30:02*FromGitter quit (Remote host closed the connection)
22:30:21*FromGitter joined #nim
22:34:20zedeuschoosenim
22:34:23*shashlic- quit (Quit: ZNC 1.7.5 - https://znc.in)
22:36:47*shashlick_ joined #nim
22:47:29FromGitter<zetashift> I'm on Manjaro and use choosenim for all the nim setup stuff
22:54:09rayman22201Araq are you online?
22:54:48rayman22201Is anyone that has knowledge of the codegen online?
22:54:57*clyybber waves
22:55:11rayman22201lol. hi clyybber
22:55:19clyybberHi
22:55:27rayman22201GDB and looking at the C code was helpful :-)
22:55:30rayman22201https://github.com/nim-lang/Nim/blob/df4c339cfce15ccc5406bc7763eac4daf9b8c76f/compiler/ccgtrav.nim#L137
22:56:04rayman22201this is the proc that generates the "marker" proc for the GC mark pass
22:56:17rayman22201if that makes sense? too much meta lol
22:56:44rayman22201It looks like the marker function generated is basically a noop
22:57:42rayman22201https://www.irccloud.com/pastebin/Zrahkco3/
22:58:33clyybberhmm, what *should* it generate ideally?
22:58:33rayman22201I'm pretty sure that proc should either free the memory, or at least "mark" it for freeing....
22:58:35*ng0 quit (Quit: Alexa, when is the end of world?)
22:58:39clyybberAh okay
22:59:00rayman22201the code that generates that proc is the first link I sent
22:59:19rayman22201I appear to have hit some edge case where it's not generating the correct thing
23:00:41rayman22201but I'm not sure exactly what it should look like
23:02:57clyybberHmm, me neither
23:05:53clyybberrayman22201: Is this the result of your debugging?
23:06:09clyybberBecause it is specific to mark and sweep afaict
23:06:45rayman22201yes, correct.
23:06:56rayman22201I'm using boehm, so that makes sense
23:07:34rayman22201dispose can be ported to other GC schemes, but it's easier to test it in isolation with a known good GC.
23:08:47clyybberHmm. So you test with mark and sweep? But you isolated the problem to somewhere that is not enabled with gcBoehm
23:09:01clyybberbecause afaict gcBoehm doesn't imply gcMarkAndSweep
23:10:12rayman22201dispose triggers mark and sweep directly
23:10:54rayman22201but maybe that isn't the problem, because I just checked the version of the code that doesn't leak, and the code it generates for "Marker" is the exact same
23:11:02rayman22201so I'm back to square one
23:11:29rayman22201seperately, Boehm == MarkandSweep
23:11:33rayman22201afaik
23:11:49clyybberhmm, ok.
23:12:00clyybberrayman22201: How can I reproduce your issue?
23:12:08clyybberClone one of your PR branches?
23:12:42rayman22201https://github.com/rayman22201/Nim/tree/async-with-dispose
23:13:30FromDiscord<krab4t> i have more templates in my shitty code than procs, nice.
23:13:39rayman22201`nim --gc:markandsweep -d:nimTypeNames -d:useGcAssert -d:trackAllocationSource -d:nimGcRefLeak -d:useMalloc --debugger:native c -r basicAsync.nim`
23:13:53rayman22201and that is the flags needed to compile the test
23:14:04rayman22201you don't need all of them, but you get the idea
23:15:33clyybberrayman22201: Do you have https://github.com/nim-lang/Nim/pull/12512 merged into your branch?
23:15:57rayman22201yes. My branch is based on that branch as a base actually
23:15:58*disbot quit (Read error: Connection reset by peer)
23:16:47rayman22201you will need to re-build the compiler for this of course, since there are some vm-gen changes
23:17:00rayman22201koch temp or something
23:17:05clyybbersure
23:17:47*snwmzr joined #nim
23:19:11*ponyrider joined #nim
23:20:21*snwmzr quit (Remote host closed the connection)
23:20:48*snwmzr joined #nim
23:22:03clyybberbtw, what is the issue again? The string not being reached by dispose right?
23:29:48clyybberrayman22201: valgrind doesn't report any leaks to me?
23:30:42clyybberSo maybe the allocs/deallocs count is just wrong?
23:30:52rayman22201hrmmmm. That is possible
23:31:08rayman22201In this case it's the "Buffer" object. I forgot to change the comment
23:31:14rayman22201String is the same though
23:31:29rayman22201It's not just the count though
23:31:55rayman22201If you look at the output of `dumpNumberOfInstances()` it still shows the Buffer object as an active object
23:32:20*mipri joined #nim
23:32:55rayman22201maybe it is just a count bug...
23:33:27clyybberOr the gc is smart enough to clean it up before terminating..
23:33:36clyybberNot sure which is the case.
23:34:42FromDiscord<yewpad> is it possible to create a nimble project with a lot of submodules? like you would do in java with maven `xxx-core`, `xxx-common`, `xxx-ABC` etc.? i don't really want to create three separate nimble projects with their own git dir
23:35:18clyybberrayman22201: Its supposed to leak without the dispose calls right? Because valgrind doesn't report any leaks even with them commented out. Which leads me to believe that the gc does cleanup before terminating.
23:35:33rayman22201I disable the GC at the start of the test
23:35:40rayman22201but then turn it back on again at the end
23:35:48rayman22201maybe comment out the GC_enable call
23:36:13clyybberthere is no GC_enable call here..
23:36:16rayman22201oh, yeah
23:36:22clyybberdidn't push?
23:36:30rayman22201no, I just mis-remembered
23:37:08rayman22201you removed the dispose call on line 27?
23:37:51rayman22201that's not actually sufficient because I also add dispose calls in the asyncmacro itself
23:38:00*mipri left #nim (#nim)
23:38:57clyybberah
23:38:59clyybberok
23:39:47rayman22201I can show you where to remove those if you like
23:40:01clyybberare these those system.dispose ones in asyncdispatch?
23:40:17rayman22201https://github.com/rayman22201/Nim/commit/f6ce22adca7023a57a48fb8de21b8adda35d9bf3#diff-5933d70ab845f7daf7c238319f0b55b6R78
23:40:45clyybberthanks
23:40:58rayman22201just change it back to `valueReceiver = newDotExpr(futureVarNode, newIdentNode("read"))`
23:41:08rayman22201👍
23:42:12rayman22201It's interesting that seems to be sufficient to not leak. That was my original theory, but this rabbit hole made me doubt myself
23:42:46clyybberdoesn't leak even with them removed
23:42:59clyybberthough the deallocs count changed
23:43:04clyybberto 0 duh :D
23:43:37rayman22201:/
23:43:39rayman22201wat
23:43:50rayman22201are you compiling with --use:malloc?
23:43:52clyybberthe deallocs count of dumpInstances
23:43:59clyybberrayman22201: Yeah
23:44:10clyybberThe free count of valgrind stays the same
23:44:25clyybberso either mark and sweep is very smart and cleans up before we terminate
23:44:32clyybbereven though you disable it
23:45:40clyybberor the dealloc counts arent incremented by the gc itself and only by dispose?
23:47:59clyybberrayman22201: Btw you can debug the generated C code a bit better with -t:-g3 instead of --debugger:native
23:48:12clyybberIf you want to step through the C code in gdb
23:48:23clyybberwhich is kinda useful at times
23:48:27clyybberlike this one
23:48:37clyybberand its also much better on the eyes :)
23:50:05hemitezedeus: thanks, I'll try choosenim
23:52:59clyybberrayman22201: Btw dispose is just a call to deepDispose in the generated C code
23:55:57*couven92 quit (Quit: Client Disconnecting)
23:59:30*couven92 joined #nim
23:59:47*krux02 quit (Remote host closed the connection)