<< 05-07-2019 >>
00:22:41*Jjp137 quit (Read error: Connection reset by peer)
00:23:13*Jjp137 joined #nim
00:48:29*krux02_ quit (Remote host closed the connection)
01:02:57*lritter quit (Ping timeout: 248 seconds)
01:03:31*absolutejam2 joined #nim
01:07:58*absolutejam2 quit (Ping timeout: 245 seconds)
01:21:31*SenasOzys joined #nim
02:11:05*chun joined #nim
02:48:44*leorize quit (Ping timeout: 260 seconds)
02:50:06*leorize joined #nim
03:01:04TangerAraq: Sorry, had to disappear last night. In relation to my query about wrapConnectedSocket, how else would one make a socket use SSL? asyncnet::acceptAddr() doesn't seem to wrap the client socket when called, compared to net::acceptAddr()
03:01:16TangerIs it just a current limitation on async/ssl?
03:01:26*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
03:06:34leorizeisn't there wrapSocket also?
03:06:50leorizenot sure if openssl supports non-blocking sockets
03:09:36TangerHmmm, I'll have a look see at the docs leorize. I figured wrapConnectedSocket was the choice as it operates on connected sockets
03:22:18FromGitter<zacharycarter> Trying to pass a callback to C and it's been a while... ```type mismatch: got <proc (this: ptr bgfx_callback_interface_t, filePath: cstring, line: uint16, format: cstring, argList: va_list){.cdecl, gcsafe, locks: 0.}> but expected 'proc (this: ptr bgfx_callback_interface_t, filePath: cstring, line: uint16, format: cstring, argList: va_list){.closure.}' ⏎ ⏎ `````` [https:
03:22:18FromGitter... //gitter.im/nim-lang/Nim?at=5d1ec26ac5f3c329aee835cf]
03:22:30FromGitter<zacharycarter> any ideas?
03:24:41*uptime is now known as ^
03:25:05*^ is now known as uptime
03:29:56Tangerzacharycarter: Incorrect pragmas on the proc? ie {.closure.}?
03:30:05FromGitter<zacharycarter> I don't think that's it
03:30:44FromGitter<zacharycarter> I think it's because I have something mucked up in the definition for the C callback I'm trying to call
03:30:58FromGitter<zacharycarter> I tried adding {.cdecl.} to the end of it but that did not do anything
03:34:13FromGitter<zacharycarter> maybe also because I'm using ptr and not pointer
03:34:47TangerIs there a semantic difference?
03:35:40FromGitter<zacharycarter> ptr is a Nim thing - pointer is not
03:35:47FromGitter<zacharycarter> well
03:35:53FromGitter<zacharycarter> pointer is generally what you use when interoping with C
03:35:58FromGitter<zacharycarter> C has no concept of `ptr`
03:36:32TangerAh. So pointer is just C compatible like cuint, cshort etc?
03:37:42FromGitter<zacharycarter> https://forum.nim-lang.org/t/823 - explains it better than I would :P
03:38:26TangerAwesome, thanks
03:39:33*SenasOzys quit (Ping timeout: 258 seconds)
03:39:45*dddddd quit (Remote host closed the connection)
03:40:41leorizeptr is pointer to C anw...
03:41:10FromGitter<zacharycarter> bleh I can't figure out why this isn't working
03:41:12leorizezacharycarter looks like the function signature was incorrect
03:41:30leorizeyou're passing the right thing, but the wrapper function is not
03:41:39FromGitter<zacharycarter> hmm
03:42:12leorizeit's expecting a `{.closure.}` somehow
03:42:23leorizeguess someone forgot to annotate the param with `{.cdecl.}`
03:43:01FromGitter<zacharycarter> well I added `{.cdecl.}` to the wrapper function but that didn't seem to fix it
03:44:00FromGitter<zacharycarter> here's the C definition - ` void (*trace_vargs)(bgfx_callback_interface_t* _this, const char* *filePath, uint16*t _line, const char* *format, va*list _argList);`
03:44:25leorizewhat's the wrapper function signature?
03:44:33FromGitter<zacharycarter> and mine is - `proc (this: ptr bgfx_callback_interface_t; filePath: cstring; ⏎ ⏎ ``` line: uint16; format: cstring; argList: va_list) {.cdecl.}```` [https://gitter.im/nim-lang/Nim?at=5d1ec7a13a1e451bfda04c7e]
03:45:07leorizeseems to be correct
03:45:24FromGitter<zacharycarter> maybe something is up with `va_list`
03:45:38leorizeget rid of it
03:45:38FromGitter<zacharycarter> I have that defined as - `type va_list* {.importc,header:"<stdarg.h>".} = object`
03:45:43FromGitter<zacharycarter> okay
03:45:45leorizeuse `{.varargs.}` pragma instead
03:45:57FromGitter<zacharycarter> I didn't realize that would work with C interop - cool
03:46:14leorizeah wait, not that easy :p
03:46:22FromGitter<zacharycarter> haha
03:46:31leorizethis is a callback :p
03:46:35FromGitter<zacharycarter> yar
03:47:10leorizeyour definition is correct, so what's wrong atm?
03:47:36FromGitter<zacharycarter> still getting this error - ```type mismatch: got <proc (this: ptr bgfx_callback_interface_t, filePath: cstring, line: uint16, format: cstring, argList: va_list){.cdecl, noSideEffect, gcsafe, locks: 0.}> but expected 'proc (this: ptr bgfx_callback_interface_t, filePath: cstring, line: uint16, format: cstring, argList: va_list){.cdecl.}' ⏎ ⏎ `````` [https://gitter.im/nim-lang/Nim?at=5d1ec858ce3d0458f2afb48b]
03:48:09FromGitter<zacharycarter> my callback looks like - ```proc cbTraceVargs(this: ptr bgfx_callback_interface_t; filePath: cstring; line: uint16; format: cstring; argList: va_list) {.cdecl.} = ⏎ discard```
03:49:05leorizelooks like a bug to me
03:49:12leorizethese two should be compatible
03:50:19FromGitter<zacharycarter> yeah - I'll try to throw together a small reproducable gist
03:56:16FromGitter<zacharycarter> something strange is going on - I can make an small example with similar code that compiles fine
04:02:10*chun_ joined #nim
04:03:08*chun_ quit (Remote host closed the connection)
04:03:28*chun_ joined #nim
04:04:31*chun quit (Ping timeout: 246 seconds)
04:12:11FromGitter<zacharycarter> heh - I can even use the same types in another file and no compile errors
04:15:36leorizenow that's weird
04:15:38FromGitter<zacharycarter> ugh so strange - I just reverted all my changes and added the same code again and no compile errors
04:15:57FromGitter<zacharycarter> something must have been going on with nimble building packages and cached libs not getting replaced I guess
04:16:09FromGitter<zacharycarter> whatever - it's working now
04:22:27FromGitter<zacharycarter> thanks for helping me leorize
04:22:53leorizenp :)
04:23:46*chun_ quit (Ping timeout: 246 seconds)
04:33:16*nsf joined #nim
04:36:57*laaron joined #nim
04:36:58*SenasOzys joined #nim
04:54:30*chun joined #nim
04:56:44*SenasOzys quit (Ping timeout: 272 seconds)
05:05:09*absolutejam2 joined #nim
05:09:53*absolutejam2 quit (Ping timeout: 248 seconds)
05:24:06*hoijui joined #nim
05:26:54*absolutejam2 joined #nim
05:31:29*absolutejam2 quit (Ping timeout: 258 seconds)
05:31:34*narimiran joined #nim
05:41:08*brakmic joined #nim
05:44:44*brakmic quit (Remote host closed the connection)
05:45:25*brakmic joined #nim
05:47:02*absolutejam2 joined #nim
06:03:13*solitudesf joined #nim
06:10:54*jjido joined #nim
06:21:45*arecaceae quit (Remote host closed the connection)
06:22:04*arecaceae joined #nim
06:39:37*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
06:39:51*absolutejam2 quit (Ping timeout: 244 seconds)
06:45:01*solitudesf quit (Ping timeout: 244 seconds)
06:45:20*jjido joined #nim
06:52:22*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
06:55:01*krux02 joined #nim
07:00:00*gmpreussner quit (Quit: kthxbye)
07:00:49*chun quit (Remote host closed the connection)
07:01:09*chun joined #nim
07:04:32*gmpreussner joined #nim
07:20:02*dwdv joined #nim
07:21:26*alexander92 joined #nim
07:21:46*purebadger joined #nim
07:29:13*crem quit (Read error: Connection reset by peer)
07:33:41*crem joined #nim
07:38:25*Vladar joined #nim
07:52:33*absolutejam2 joined #nim
07:59:07*crem quit (Read error: Connection reset by peer)
08:00:53*crem joined #nim
08:19:28*chun quit (Remote host closed the connection)
08:19:38*chun joined #nim
08:20:49*chun quit (Remote host closed the connection)
08:21:09*chun joined #nim
08:22:02*chun quit (Client Quit)
08:22:21*chun joined #nim
08:24:08*chun quit (Client Quit)
08:24:28*chun joined #nim
08:25:48*chun quit (Remote host closed the connection)
08:26:08*chun joined #nim
08:30:00Araqany OBS users around? how can make the chat blend into my recorded dektop?
08:31:18*chun quit (Remote host closed the connection)
08:31:38*chun joined #nim
08:32:00alexander92hm where do you see chat in obs
08:34:20Araqit's a separate window
08:34:48alexander92btw are there segfault test cases in the suite
08:34:59alexander92like something testing stack traces for them or something
08:35:55alexander92i am looking for small programs with strange to explain segfaults e.g. race conditions or something not sure
08:52:16Araqthere is tproper_stacktrace.nim
09:00:51federico3https://elixirschool.com/blog/phoenix-live-view/ something like this would be really nice for Nim
09:02:17FromDiscord_<SychoRyn> is nim viable for game development?
09:02:31federico3SychoRyn: very much so
09:02:33FromDiscord_<SychoRyn> getting really tired of C++ :/
09:03:16Vladartotes, I used it to participate in Linux Game Jam for 3 years already
09:04:51ZevvI tried to do some c++ the last few days. Try deciphering the stream of vomit coming out of the compiler when there's a signature mismatch when doing a std::bind(), or when leaving out the
09:04:57Zevv'= 0' on a virtual method
09:05:13Zevvprecious hours of my life, *poof*, gone, just like that
09:06:08ZevvI tried googling the error messages, and I get here: https://codegolf.stackexchange.com/questions/1956/generate-the-longest-error-message-in-c
09:06:18Zevvpeople having a little competition generating the longest error message from C++
09:07:04FromDiscord_<SychoRyn> amazing
09:07:35FromDiscord_<SychoRyn> is nim viable for gui apps
09:09:16Zevvhttps://matthiashager.com/gui-options-for-nim
09:09:24alexander92hm zevv, isnt clang better
09:09:33alexander92with error messages, i think that was one of its main pro-s
09:09:45FromDiscord_<SychoRyn> I really want to use nim but people keep telling me I should use "RUST" and RUST and ugh I fucking... Rust (I'm too dumb to use it lole)
09:11:04Zevvslightly. Part my problem was that I was making a shared lib which happely links, but barfs on my at run time with unresolved symbols like _j6Kgbcodec4Ksetup4. Which I need to demangle manually, and translates to "typeinfo of codec::setup()". WTH does that mean if the linker can't find typeinfo?
09:11:46ZevvSo it seems that vtables went missing because I forgot initialze my vritual method to 0. But EVERY FRIGGING virtual method I ever saw was initialized to 0. So why is that not the default?
09:11:57Zevv</rant>
09:17:25*absolutejam joined #nim
09:18:42federico3https://github.com/nim-lang/needed-libraries/issues/107
09:21:31FromGitter<rokups> federico3 there are https://github.com/pragmagic/karax and https://github.com/dom96/jester
09:21:49federico3rokups: they don't fit those requirements
09:23:31FromGitter<rokups> alright. i know little of modern webdev, just thought you might have missed these projects :]
09:23:45federico3I'm aware of those, thank you :)
09:24:41FromGitter<rokups> someone is working on https://github.com/nepeckman/nerve-rpc which seems it will be very handy for exposing APIs
09:24:49FromGitter<rokups> and karax can render html on server side i think
09:27:33federico3https://www.hug.rest/ is another good examuple
09:29:04*brakmic quit (Read error: Connection reset by peer)
09:29:45alexander92praise the Lord, i was thinking about phoenix just today
09:29:53alexander92even asked them a few questions in their irc
09:30:13*brakmic joined #nim
09:30:15alexander92i also wanted to create a little framework eventually
09:30:47alexander92but i feel these days usually there are minimal api-related backend libs
09:31:16alexander92which let you easily create simpler api microservices and stuff like this (probably like hug)
09:31:32alexander92and then you have the more classical big frameworks(e.g. phoenix, rails style)
09:32:01alexander92and i am not sure if actually the second kind is still popular
09:33:29alexander92(but yeah it shouldn't be too hard: there are orm-s like ormin/norm, template engine is easy to pull out: karax or htmlgen or a custom one, routing can be quite nice with macros
09:34:28alexander92the most missing thing imho would be a good validation layer, and a good cli tool for scaffolding/managing a web app, and a migration lib
09:34:44alexander92(i have written a migration lib in my job, but not sure if its good enough for general use)
09:35:44alexander92and good websocket abstraction
09:36:11alexander92and good background job mechanism: i feel like awaiting from threads might help a lot with that
09:37:28alexander92but yeah, my point is that if one has ok components for most of those and manages to combine them with a good DSL, this might be useful as a web fr
09:38:52*tjmac joined #nim
09:41:34alexander92but i dont really have time today to think about that
09:52:49*clyybber joined #nim
09:59:14livcdfederico3: i am too stupid but i dont really understand what is this liveview
09:59:53livcdi mean i have an idea but..
10:00:27federico3livcd: https://www.youtube.com/watch?v=8xJzHq8ru0M
10:01:24livcdBut there has to be JS right ?
10:03:00*solitudesf joined #nim
10:10:30federico3livcd: almost none it seems
10:16:27FromGitter<rishavs> Can I update nim from nimble itself?
10:22:58*couven92 joined #nim
10:25:18lqdev[m]rishavs: no, you use choosenim to do that
10:25:53*purebadger quit (Ping timeout: 245 seconds)
10:26:08FromDiscord_<SychoRyn> http://boards.4channel.org/g/thread/71730586
10:26:16FromDiscord_<SychoRyn> nim general
10:31:47*purebadger joined #nim
10:35:06*chun quit (Remote host closed the connection)
10:36:39FromGitter<rishavs> Thanks
10:38:10*purebadger quit (Ping timeout: 268 seconds)
10:41:44*purebadger joined #nim
10:53:23lqdev[m]but iirc there's a nimble package `compiler` which *is* the Nim compiler, I never tried installing it this way though. maybe it works
11:04:05alexander92i think it works indeed
11:13:36*alexander92 quit (Quit: WeeChat 2.4)
11:22:14FromGitter<rishavs> what is this pattern supposed to do? ⏎ `discard buttonSkin.assignTexture buttonMosaic.render(patternStretchBorder(8, 2))` ⏎ essentially `discard func_a func_b()`
11:23:02FromGitter<rishavs> is it essentially, ⏎ `discard func_a() ⏎ discard func_b()`
11:24:42clyybberAraq: tySink should not be an abstractInst anymore right?
11:25:49*Vladar quit (Remote host closed the connection)
11:27:03*hoijui quit (Ping timeout: 264 seconds)
11:44:39*Vladar joined #nim
11:54:02*ibutra joined #nim
11:55:29Araqclyybber: it should be but the backend has to be careful
11:57:30*nsf quit (Quit: WeeChat 2.4)
12:02:10FromGitter<rokups> @rishavs its `discard buttonSkin.assignTexture(buttonMosaic.render(patternStretchBorder(8, 2)))`. `discard` there means you do not use return type of `assignTexture()`
12:05:39*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
12:06:38*laaron joined #nim
12:07:10clyybberAraq: Why is tyLent not an abstractInst then?
12:09:49clyybbernevermind
12:10:20*Snircle joined #nim
12:15:18FromGitter<rishavs> Thanks @rokups so, it is the same way functional langs like F# call functions
12:17:28FromGitter<rokups> not sure how they work. in nim you can make make calls in multiple ways: `foo(a, b)`, `a.foo(b)`, `foo a, b`. they all do same thing
12:18:40FromGitter<rishavs> in f#, fn(a,b) is `fn a b`
12:19:21FromGitter<rishavs> this syntax confuses my a lot, specially when the same file uses all 3 function syntaxes :)
12:21:27clyybberAraq: Where do implicit addresses get introduced when passing something as a var (or what I want to achieve: sink) to a proc?
12:22:50*ibutra quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:34:57*dddddd joined #nim
12:37:38*ibutra joined #nim
12:57:24*stefanos82 joined #nim
13:01:33*clyybber quit (Quit: WeeChat 2.5)
13:08:00*ibutra quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:08:49*xace quit (Ping timeout: 248 seconds)
13:09:05*ibutra joined #nim
13:13:51*ibutra quit (Ping timeout: 264 seconds)
13:19:26*ibutra joined #nim
13:19:49FromGitter<mratsim> because var need a memory location so you can mutate it (i.e. lvalue)
13:20:05FromGitter<mratsim> memory locations have addresses
13:30:26narimiran@rishavs well it that example, somebody tried really hard to make the code cryptic and not easy to understand when you skim through it
13:31:58narimiranadding parentheses, as @rokups did, makes more sense
13:34:57*couven92 quit (Quit: Client disconnecting)
13:43:46*purebadger quit (Ping timeout: 246 seconds)
13:47:41*drewr quit (Read error: Connection reset by peer)
13:49:30*drewr joined #nim
14:01:05*narimiran quit (Ping timeout: 248 seconds)
14:40:36disruptekphoenix uses a js dom differ.
14:56:35*SenasOzys joined #nim
15:00:29*tjmac left #nim ("-bye")
15:04:00*ibutra quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:08:53*absolutejam2 quit (Ping timeout: 268 seconds)
15:20:52*SenasOzys quit (Ping timeout: 245 seconds)
15:32:23lqdev[m]nice, seems that the Nim VS Code extension is back from the dead. time to get back to work
15:44:01*lritter joined #nim
16:07:18FromGitter<awr1> lack of circular imports in nim is still bugging me. the "types.nim" solution feels too C headerfile-ish for me; in general i wouldn't have as much of a problem with that but when it comes to doc generation things get messy
16:08:46FromGitter<awr1> could also use `include` + `codeReordering` but that seems inelegant, plus the same problem occurs
16:18:48*chun joined #nim
16:19:20*crem quit (Read error: Connection reset by peer)
16:20:18*Virxes joined #nim
16:21:37*crem joined #nim
16:24:17disruptekawr1: can you give an example of how this problem manifests?
16:27:05Araqyou can dislike it all you want, but F# shares the same problem so I wouldn't say "C headerfile-ish"
16:27:38*ibutra joined #nim
16:33:31*kuon__ joined #nim
16:36:01kuon__Hello, I am still in early stage of learning nim, and I was wondering if nim has plan/had a discussion, about a pipe operator, like a(b(val)) written val |> b |> a like in elixir or elm.
16:40:36disruptekyou can make your own. zero functional might be inspirational if you don't like what comes in the tin: https://github.com/zero-functional/zero-functional
16:43:16kuon__That library is interesting, thanks.
16:49:55*chun quit (Quit: Leaving)
16:51:36*chun joined #nim
16:53:01*chun left #nim (#nim)
16:54:29*chun joined #nim
17:04:57FromGitter<awr1> @disruptek for ex: i have a toy renderer/engine i'm working on, i have a platform.nim that handles (multiple) window generation, event loops etc. and then i have a renderer_vk.nim that initializes+handles a vulkan instance, logical devices, queues, swapchain, cmd buffers, shader SPIRV etc. but i have this issue where i want to "integrate" a window to the vulkan system (swapchain, imageviews, etc.). ideally what i would do
17:04:57FromGitter... is that the platform window would have some sort of "vulkan integration" object in it containing, which would ideally be imported from renderer_vk.nim, but then platform.nim needs to call the integration proc, and this integration proc needs to be able to grab some of the generic window internals to do its work. s ... [https://gitter.im/nim-lang/Nim?at=5d1f833911bfea0b67ac7991]
17:06:28*leorize quit (Ping timeout: 260 seconds)
17:06:54*leorize joined #nim
17:07:55FromDiscord_<demotomohiro> kuon__: you can just write ``val.b.a`` using method call syntax.
17:08:27FromGitter<awr1> circular imports are of course never *ideal* but sometimes they would be useful
17:09:19kuon__demotomohiro hoo, didn't think it would work
17:13:01disruptekit sounds like you have a piece of code in mind that knows about vulkan and knows about platform. shouldn't that piece import those two files and do the nasty?
17:15:35FromGitter<awr1> i could possibly have a renderer_integrator.nim, yeah. although in general i would prefer to seem vulkan code in its appropriate domain
17:16:32FromGitter<awr1> circular imports are always ultimately resolvable by the programmer but they become useful when you want to keep things more tightly bound
17:18:03lqdev[m]yeah, circular imports made me split my player.nim file into playerbase.nim and playerdef.nim which is less than ideal
17:18:04FromGitter<awr1> however on thinking about it some more some of the same problems emerge. the integrator needs details from vulkan and platform, but platform needs to be able to call the integrator
17:20:03disruptekso?
17:24:44FromGitter<awr1> is that not a circular import
17:25:00kuon__I get this error when trying to install sdl2 package, any idea ? http://dpaste.com/2X8D2AS
17:25:32kuon__Without colors http://dpaste.com/0BGN1PC
17:26:59FromGitter<awr1> what ver of nim are you on?
17:27:00disruptekif you want to pass types that are shared between platform and vulkan, then yes, you will have to choose a scope in which those types are shared. no way around that. if you just want to trigger events or move data, then you don't need any of that. use channels, or futures, or callbacks, or, or, or, or...
17:27:08FromGitter<awr1> try doing a `choosenim update #head`
17:27:16FromGitter<awr1> @kuon__
17:27:16kuon__0.20.99
17:27:52disruptekit sounds like you're trying to make this harder than it needs to be. make it work first, then make it correct.
17:28:44disruptekie. just import vulkan into platform and stop being so pedantic. :-P
17:29:00FromGitter<awr1> in general i would be fine with a shared types.nim it's just that to me this would predictably more annoying when doing doc generation
17:29:06FromGitter<awr1> *would be
17:29:15FromGitter<awr1> for a larger project
17:29:43disrupteki don't use shared types, but most of my code is greenfield, so i rarely run into problems that aren't of my own creation.
17:38:22kuon__Ho I found the problem, I installed nimble from package manager and it was an older version.
17:42:16*jjido joined #nim
18:05:18*absolutejam2 joined #nim
18:07:37*absolutejam3 joined #nim
18:09:46*absolutejam2 quit (Ping timeout: 246 seconds)
18:14:00*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:24:16*chun quit (Remote host closed the connection)
18:27:42FromGitter<zacharycarter> everyone is jumping on the vulkan ship
18:28:08FromGitter<zacharycarter> still not 100% sure why - I guess it's just cool
18:31:37*nsf joined #nim
18:34:48FromGitter<zacharycarter> time to test out HCR :D
18:35:50*ibutra left #nim ("Textual IRC Client: www.textualapp.com")
18:44:26kuon__I am starting with nim, and I have a working C app using SDL I port to nim for learning. In my C code, I have a lot of calls like if (SDL_Init(...)) { SDL_Log("error..."); exit(1); } how do you write that "the nim way" ?
18:45:37disruptekquit(1); the rest should work (minus the {}).
18:48:04kuon__ok, so the structure remain the same? No need for other error handling mechanism (exception, whatever) ?
18:48:33disruptekwhat would you do if the init threw an error?
18:49:15FromGitter<zacharycarter> well... that doesn't appear to work at all
18:49:22FromGitter<zacharycarter> hotcodereloading I mean
18:49:29kuon__well, right now if I have a low level error (SDL, opengl), I just abort the app
18:49:38disrupteksounds good to me.
18:49:47kuon__If this is acceptable in nim, I just do it the same way.
18:50:32disruptekabortions are only against the law in alabama.
18:50:46lqdev[m]zacharycarter: remember that you need to request a reload manually
18:50:56FromGitter<zacharycarter> I am
18:50:59FromGitter<zacharycarter> here's what I did
18:51:14FromGitter<zacharycarter> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d1f9c2211bfea0b67ad3471]
18:51:28FromGitter<zacharycarter> but `getStr` returns the same value
18:51:39FromGitter<zacharycarter> every time I press enter - regardless of what the other script contains
18:51:55kuon__And what about namespace pollution and collision? I notice that doing import sdl2 just import everything in the file namespace. What about name conflict?
18:51:58FromGitter<zacharycarter> do I need to tell the hcr module about the script or something?
18:52:12disruptekwhat about it?
18:52:45lqdev[m]dunno, I never used it before. I just remembered that reloading must be done manually so I thought this might be your problem
18:52:57kuon__If I import two package with an init() proc, how do I tell which is which?
18:53:05FromGitter<zacharycarter> ah gotcha
18:53:22lqdev[m]also, you can achieve a similar effect using the dynlib module, but it's nowhere as convenient
18:53:34disruptekkuon__: you can package1.init if they have the same signature.
18:53:51Araqthe compiler will tell you when it's ambiguous
18:54:01kuon__aah, it is distinguished by signature, then I can prefix the package name, ok thanks.
18:54:22disruptekit's one of those scary-on-paper-harmless-in-practice things.
18:54:48Araqit's harmless-on-paper too when you know anything about type systems
18:55:09disruptekwell, if they have the same type...
18:56:08Araqthen it's ambiguous
18:56:44disrupteki think that's what kuon meant by `collision`.
18:57:53FromGitter<awr1> @zacharycarter i plan on making a more nim-friendly vulkan library
18:57:55kuon__Yeah that is what I meant, but the fact that I can prefix the package name resolve it
18:58:07FromGitter<zacharycarter> vulkan is not friendly :P
18:59:23FromGitter<zacharycarter> well I can't get the HCR stuff to work at all
19:00:00FromGitter<zacharycarter> `hasAnyModuleChanged` always returns `false` even though an imported module HAS changed and `performCodeReload` doesn't seem to do what it's supposed to
19:01:43Araqzacharycarter: read the new docs about it?
19:02:14FromGitter<zacharycarter> hrm I think so - I built the two shared libs and put them in the same dir as my executable, I added the switch to my config
19:02:25FromGitter<zacharycarter> but I'm probably still missing something
19:03:13FromGitter<awr1> which backend are you using? C or C++?
19:03:39FromGitter<awr1> i've run into problems with the C++ backend on HCR
19:03:48FromGitter<zacharycarter> C - I'm looking at these docs: https://nim-lang.org/docs/nimc.html
19:04:19*nsf quit (Quit: WeeChat 2.4)
19:05:12*kungtotte joined #nim
19:06:11FromGitter<zacharycarter> running with - `nim c -d:useNimRtl --hotcodereloading:on -r src\zeal.nim .`
19:06:58FromGitter<awr1> try `--hotcodereloading` without the `:on`
19:07:28FromGitter<zacharycarter> okay
19:07:35FromGitter<ratiotile> Does anyone know if `coro` is supposed to work in cpp mode? I'm getting link errors
19:07:47FromGitter<awr1> also you shouldn't try to reload every tcik
19:07:49FromGitter<zacharycarter> no dice
19:07:59FromGitter<zacharycarter> I'm not - I'm only reloading when stdin can be read
19:08:09FromGitter<zacharycarter> the program pauses and waits for stdin each iteration of the while loop
19:08:11FromGitter<awr1> oh i see
19:08:30AraqI used SDL2 and a keypress to reload, it worked really well
19:08:42Araqbut before I got it to work I had the same problems as you
19:08:43FromGitter<zacharycarter> I wonder why it's not working for me
19:08:51FromGitter<zacharycarter> hrm - let me try in another main file
19:09:13Araqthe logic MUST NOT be in the main file, main file is never reloaded
19:09:19FromGitter<awr1> iirc performCodeReloading() shouldn't be in main module
19:09:21FromGitter<awr1> yeah
19:09:55FromGitter<awr1> does nim output an error for that?
19:10:03Araqno...
19:10:20FromGitter<awr1> hm maybe i should do a PR
19:10:41FromGitter<zacharycarter> wait - so `performCodeReload` doesn't get called from the main file?
19:10:58FromGitter<awr1> it just "doesn't work"
19:11:22FromGitter<zacharycarter> I guess I'm confused as to how this works then
19:11:49FromGitter<awr1> just put your loop in another file
19:11:53FromGitter<awr1> and call it from the main module
19:12:23FromGitter<zacharycarter> call what from the main file? my loop?
19:12:42FromGitter<zacharycarter> oh I think I get what you're saying
19:13:12Araqhttps://github.com/nim-lang/Nim/blob/devel/doc/hcr.rst
19:13:50Araqplease read this carefully
19:14:28FromGitter<zacharycarter> I hadn't seen this doc before - thanks
19:16:20FromGitter<zacharycarter> okay I get it now and got it working - thanks!
19:16:59FromGitter<ratiotile> Is there some dll I need to include in cpp mode that has GC_addStack? Because that is the linker error I get
19:17:10disruptekit's weird that there aren't some little examples that demonstrate some of these common little projects like hcr and sdl.
19:17:36Araqratiotile: coro.nim is hardly supported, most use async instead
19:17:41disruptekmaybe i just don't know about them.
19:17:50Araqdisruptek: we have the worst marketing in the world... :-(
19:17:54Zevvah, hcr, I wanted to check that out. I get "could not import: nimrtl_nimGCvisit
19:18:06FromGitter<ratiotile> I was testing async and surprised at how slow it is
19:18:23disruptekratiotile: what, specifically?
19:18:27Zevvat run time. Where does that come from?
19:19:04FromGitter<ratiotile> something like 1000x slower than C++ coroutines
19:19:39FromGitter<ratiotile> I was going to benchmark `coro` as well to compare
19:20:25FromGitter<awr1> ideally for HCR reloads the build script could have some IPC mechanism to tell the app to reload
19:20:27Zevvratiotile: maybe a obvious remark, but did you compile with -d:release?
19:20:53kuon__nimpretty cannot be used with stdin to stdout?
19:21:15kuon__I tried to pass /dev/stdin but nimpretty is getting smart and try to open /dev/stdin.nim
19:21:16disruptekasync is just a code transformation, but the last time i finally whined about it being slow, it got fixed. so, please whine about it.
19:23:27Araqthere is also nim-chronos that could be faster
19:24:10disruptekit's faster for some stuff on some platforms (linux).
19:25:18FromGitter<awr1> going to do a PR, i forget, if you point choosenim at a custom Nim directory, will it auto-build?
19:26:01disruptekwhy is it that old people don't understand weather? if you haven't figured this shit out by the time you are 70, you just aren't gonna.
19:27:35disruptekif you do build a benchmark, i'd be curious to see some golib results. there's a nim wrapper for it somewhere.
19:28:02FromGitter<ratiotile> my notes are not precise enough :( I'm going to rerun the benchmark.
19:28:24disruptekto the noisemobile, batman!
19:28:28*laaron quit (Remote host closed the connection)
19:29:52FromGitter<alehander42> they do get weather very well actually
19:30:04*laaron joined #nim
19:30:29disrupteki guess i need to upgrade my oldsters.
19:37:43FromGitter<awr1> does enabling HCR emit a define?
19:37:48FromGitter<awr1> i dont think it does
19:37:58FromGitter<awr1> should add one in the future maybe
19:41:12FromGitter<awr1> donezo https://github.com/nim-lang/Nim/pull/11667
19:47:51kuon__what is the * when declaring types? I am reading the SDL2 source, and it's type \n DisplayMode* = object
19:49:21FromGitter<awr1> can you elaborate?
19:49:31FromGitter<awr1> oh
19:49:42FromGitter<awr1> markdown confused me
19:49:57FromGitter<awr1> star just means publicly exported out of the module
19:50:01kuon__it's not only for type, it's everywhere
19:50:07kuon__Aaaaaah. Ok
19:50:16kuon__I couldn't find it in the doc.
19:51:10kuon__Well, it's because I should have searched "asterisk" I searched wildcard and star in the doc:)
19:51:32FromGitter<awr1> i feel like it should be one of the first things in the nim tutorial
19:52:17FromGitter<awr1> oh it's all the way at the bottom
19:52:18FromGitter<awr1> hm
19:52:25FromGitter<awr1> https://nim-lang.org/docs/tut1.html#modules
19:52:28FromGitter<awr1> oh well
19:53:37kuon__it's writted under objects also https://nim-lang.org/docs/tut1.html#advanced-types-objects
19:53:48kuon__but I didn't see it :)
19:58:21*narimiran joined #nim
19:59:03kuon__There is something that puzzle me, I am reading https://github.com/nim-lang/sdl2/blob/master/src/sdl2.nim#L1200 and getDesktopDisplayMode takes a var DisplayMode while getClosestDisplayMode takes ptr DisplayMode
19:59:34kuon__But in C, both take pointers https://wiki.libsdl.org/SDL_GetDesktopDisplayMode https://wiki.libsdl.org/SDL_GetClosestDisplayMode
20:03:05FromGitter<awr1> passing var is implicitly done w/ pointers iirc, similar to passing references in C++
20:04:19kuon__but why the different signatures in the SDL lib?
20:05:18FromGitter<awr1> i would guess ease-of-use (since ideally Nim programs should avoid using raw pointers) but there are some types in there that are ptr so...idk
20:05:21*uli00 joined #nim
20:06:09FromGitter<awr1> it's possible this could be some c2nim weirdness
20:07:00*Trustable joined #nim
20:07:06kuon__ok
20:07:10FromGitter<awr1> https://github.com/Vladar4/sdl2_nim is the one that more closely matches the original SDL2 iirc. don't quote me on that
20:07:13FromGitter<awr1> but both should work fine
20:08:08kuon__ok
20:08:12kuon__Thanks
20:24:39lqdev[m]https://nim-lang.github.io/Nim/dynlib.html#loadLibPattern%2Cstring I think should be referring to the `dynlib` pragma, not `dlimport` (iirc this does not exist in the latest Nim)
20:26:03lqdev[m]also, the `global_symbols` parameter does not comform to NEP1's naming scheme
20:26:22lqdev[m]same with `loadLib`
20:50:10Araqawr1: the idea was to use 'var T' if it cannot be NULL
20:50:47FromGitter<ratiotile> ok I have benchmark numbers: nim is 6000ns per await, C++ is 20ns (both in release)
20:52:28FromGitter<ratiotile> so it's more like 300x slower
20:52:45FromGitter<awr1> @lqdev[m] PR them?
20:53:27FromGitter<alehander42> 30
20:53:34FromGitter<alehander42> not 300
20:53:38FromGitter<alehander42> but yeah, strange
20:53:48FromGitter<ratiotile> I suspect Nim's await is doing far more than my C++ coro implementation (duff's device)
20:53:53FromGitter<alehander42> oh no 300
20:54:07FromGitter<alehander42> wow math is hard
20:55:43Zevvrayman22201: do you have a small test program?
20:55:55Zevvoh wrong msg sorry rayman22201, I ment ratiotile
20:56:00Araqratiotile: share the benchmark with us please
20:56:23Araqbut I mean, C++ has more compiler devs working on it than Nim
20:57:15Zevvyeah, but 6µS is a lot of time to spent on an await
20:57:20FromGitter<ratiotile> well, the C++ implementation is basically a switch and a loop
20:57:29FromGitter<ratiotile> Nim is pulling in sockets and stuff
20:57:51Araqoh better compare it to a raw .closure iterator then
20:58:06Araqwe too compile the state machine to duff's device btw
20:58:36FromGitter<ratiotile> hmm I'll see if I can implement it using the closure
20:58:56*brakmic quit (Read error: Connection reset by peer)
20:59:03FromGitter<zacharycarter> Is something like this in Nim possible? ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d1fba17b682244d498be447]
20:59:11Araqread the manual about to use them for a 'task' system
20:59:35*brakmic joined #nim
20:59:38Araqzacharycharter, yes, use 'cast'
20:59:39stefanos82I was wondering; how does Nim makes sure that the generated code, whether that is C or C++, is always secure without memory leaks and such? Genuine curiosity here, not trying to disrespect or offend the language, let alone its dev team
20:59:46FromGitter<zacharycarter> thanks Araq - makes sense
21:00:11Araqthe C codegen knows the 'cast' cannot be mapped to a C cast, but needs an interim union
21:00:15FromGitter<ratiotile> thanks, that was closer to what I was looking for - await is a bit heavyweight
21:00:36FromGitter<zacharycarter> gotcha - cast worked perfectly
21:02:01Araqstefanos82: we don't have a good answer, we use valgrind and the sanitizers occasionally but simply have many tests. With the --newruntime everything works so much better...
21:02:20stefanos82ah good good :)
21:02:35AraqI dunno why people act like I'll take away something from them. the tool support will be so much better that it's ridiculous
21:03:03kuon__Well, I have been coding in nim for my first day, and I ported 20% of a small embedded project written in C. I like it. I really love the easy interoperability with C. We can just replace C bit by bit.
21:03:13FromGitter<awr1> is there anything i should read to get started w/ newruntime
21:03:27kuon__It took me a while to get it to cross compile for my embedded environment, but after a little makefile it works :)
21:03:30FromGitter<awr1> i've been seeing a lot of github issues and haven't had a chance to dive into it
21:03:44ZevvAraq: I guess the majority of concern is the misconception that goes around: people feel you're making them do Rust-like things
21:04:53Araqawr1: I'm slowly fixing the bugs, clybber is working on implementing the new spec
21:05:03kuon__I have tried a lot of "C alternatives", and this is the first time I actually think this might be true. Of course there is rust, but I found rust so hard to write for prototyping.
21:05:20kuon__Anyway, thanks for your assistance here.
21:05:37Araqkuon__: you're welcome
21:05:58Araqanyway... can we rename the 'manual' to the 'spec' or would that still be ridiculous?
21:06:40*jjido joined #nim
21:07:00*kuon__ quit (Remote host closed the connection)
21:07:57*narimiran_ joined #nim
21:08:11FromGitter<awr1> the thing is what is considered "the definition of nim"
21:08:46FromGitter<awr1> in terms of "if XYZ person were to make their own nim compiler from scratch" or w/e
21:09:18FromGitter<awr1> because that would have to logically include some of the stuff from `system.nim` that is tied directly to compilation
21:10:08stefanos82Araq: well, to me a spec is a document that describes the technicalities of a language and its semantics, whereas a manual demonstrates how to use the language as a whole more or less
21:10:47Araqthe manual is constantly evolving into a spec, that was the goal for a long time now
21:10:58stefanos82then a spec that is!
21:11:02Araq"how to use it" is covered by the tutorial
21:11:02*narimiran quit (Ping timeout: 258 seconds)
21:11:09stefanos82that's more like it
21:11:53Araqbut I strive for more pseudo-code in the spec instead of "legalese"
21:11:59disruptekimo, the spec is the code, however correct or incorrect the output is. understanding what that is and why it is the job of the manual.
21:12:04FromGitter<awr1> how long is the manual
21:12:06FromGitter<awr1> 200 pages?
21:12:10stefanos82maybe there could be a section called "manual" that contains the links to spec and tutorial and any other links that could be considered useful, such as cookbook tricks?
21:12:11disruptekit's useless to describe a system that is purely theoretical.
21:12:16*lf-araujo joined #nim
21:12:25FromGitter<awr1> oh 132 pages
21:13:05disruptek6000ns is not correct as far as await goes; i see smaller figures in debug mode running actual work. can we see the code?
21:14:10Araqdisruptek: well my ideal is Knuth's literate programming for the Nim spec/reference implementation
21:14:34Araqbut we are a long way from that...
21:14:35FromGitter<awr1> i'm trying to remember why the C++ spec is so long . i guess the standard library definitions take up a big part of it
21:14:57FromGitter<ratiotile> disruptek: https://pastebin.com/JDJUjYQp
21:15:49stefanos82Araq: you are touching some sensitive chords of mine brother...one day I will get the books on my shelf, ONE day!
21:18:30Zevvratiotile: what is your exact nim version?
21:19:00FromGitter<ratiotile> Nim Compiler Version 0.20.0 [Windows: i386]
21:19:18FromGitter<ratiotile> tried x64, and it was similar times
21:21:43FromGitter<awr1> @Araq rust seems to be a similar situation? they have a "reference" that is technically not a spec
21:21:45FromGitter<awr1> https://doc.rust-lang.org/stable/reference/
21:21:46*absolutejam4 joined #nim
21:23:07disruptekrunnable examples is great. i hope we see more of that.
21:24:06*absolutejam3 quit (Ping timeout: 272 seconds)
21:24:37Araqdisruptek: the examples in the manual are also checked automatically
21:24:53*Vladar quit (Remote host closed the connection)
21:25:59stefanos82by the way, with every git pull I run on Nim repo and recompilation, the megatest executes faster and faster
21:26:03stefanos82that's simply amazing
21:26:20FromGitter<ratiotile> It would be a good idea to mark clearly that `coro` doesn't work in cpp
21:27:13narimiran_stefanos82: then do the git pull 50x a day, to optimize it even further :P
21:27:33stefanos82narimiran_: I didn't say anything about optimization Mr Sarcasm
21:27:46narimiran_:)
21:27:58stefanos82I meant it performs better and better due to constant improvement
21:28:07Araqstefanos82: you're alone :-( for me Nim constantly keeps getting slower at compilation
21:28:14narimiran_i know what you meant ;)
21:28:26stefanos82Araq: weird...
21:28:39stefanos82let me check it right now then
21:28:56Zevvfwiw: the top 10 perf output of ratiotile's code
21:30:35disruptekit's been a very long time since i cared how long compilation took, in any language. probably 25 years. computers are fast. code does what i cannot, and for free -- i never care how long it takes.
21:31:50FromGitter<ratiotile> I get the impression that people want the compiler to work like spellcheck
21:33:03stefanos82Araq: 34.366s is slow to fully compile the language after syncing my repo?
21:33:05disruptekand if you find a mispelling, throw away the entire OS image and start over.
21:34:10Araqstefanos82: for me it cannot be fast enough, I use 'koch temp' + echo to debug the compiler. I should use -d:leanCompiler more often...
21:34:27stefanos82ah I use build_all.sh
21:34:28stefanos82that's all
21:34:31stefanos82*why
21:34:32disrupteki was surprised at your dev process, tbh.
21:35:18*narimiran_ is now known as narimiran
21:35:23Araqdisruptek: got some tips for me? :-)
21:35:27disruptekyou'll never get that 34.366s back. and for what? all you got in return is a current nim with fewer bugs than last week, and better performance. sucks, don't it?
21:36:50FromGitter<awr1> i wonder how much faster it would become w/ incremental comp
21:37:28disrupteki mean, i don't know anything about the compiler. it's greek to me. i just know that if it were me, i'd have long since hacked at my dev mainloop. also, i am in a linux environment quite different from your vs code world.
21:37:54Araqit was instantaneous, awr1, back when it worked
21:38:12Araqand we had it working 6 years ago
21:38:25FromGitter<awr1> what broke it?
21:38:33disruptekwho was it that was working on a repl?
21:39:52Araqawr1: compile-times were fast enough, the internal formats changed, it rotted
21:40:33Araqplus of course automatic testing of this feature was a pita. now I have some ideas of how to do it better
21:40:51Zevvratiotile: http://ix.io/1NO7 lot of time is spent in genericAssignAux/genericSeqAssign. No clue what that tells me, though
21:40:59Zevv:)
21:41:11Araqah that thing, gah
21:41:43Araqwanna take a guess if genericAssignAux is still a thing in --newruntime?
21:41:57disrupteklol
21:42:35Zevv/home/ico/external/Nim/lib/pure/asyncfutures.nim(171, 22) Error: assignment produces a dangling ref: the unowned ref lives longer than the owned ref
21:42:39Zevvaww
21:43:56*lf-araujo quit (Ping timeout: 252 seconds)
21:44:35Araqthat's the elefant in the room
21:45:20AraqI *still* don't know if the newruntime can work with async. In theory there is no problem. But the theory overlooks so many details that I don't know.
21:46:51federico3Araq: how was incremental compilation working?
21:47:15*solitudesf quit (Ping timeout: 268 seconds)
21:47:37Araqfederico3: we mmap()ed an IR for every module
21:48:03federico3...and then?
21:48:03Araqthe IR was optimized for size
21:48:47Araqand then we loaded the IR of the modules that didn't change and recompiled the modules that did change
21:52:25federico3if the compiler had hooks for loading and storing IRs this could be used to reimplement incremental compilation but also distributed building
21:57:33disruptekis there documentation for this mysterious "lean compiler"?
21:59:27*lf-araujo joined #nim
22:13:56Araqdisruptek: grep for leanCompiler
22:14:11Araqit's the compiler without the docgen and the crazy 'parallel' statement
22:15:02Araqfederico3: maybe but first it has to work before we can make it "hookable"
22:16:50*Snircle quit (Read error: Connection reset by peer)
22:17:34*Snircle joined #nim
22:23:22*narimiran quit (Ping timeout: 245 seconds)
22:29:17FromGitter<ratiotile> what is the type of an instantiated iterator closure?
22:33:01*nsf joined #nim
22:36:04*brakmic quit ()
22:46:38*lf-araujo quit (Ping timeout: 252 seconds)
22:52:22*uli00 quit (Remote host closed the connection)
22:57:45*nsf quit (Quit: WeeChat 2.4)
22:59:44*Trustable quit (Remote host closed the connection)
23:03:25*dwdv quit (Ping timeout: 246 seconds)
23:04:43*krux02_ joined #nim
23:07:10*krux02 quit (Ping timeout: 252 seconds)
23:11:06*smitop joined #nim
23:14:49*absolutejam4 quit (Ping timeout: 268 seconds)
23:34:32*krux02_ quit (Remote host closed the connection)
23:35:09*NimBot joined #nim
23:42:13*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:53:55*chun joined #nim
23:54:19*chun_ joined #nim
23:54:26*chun_ quit (Client Quit)