<< 07-07-2019 >>
00:00:01*junland quit (Quit: %ZNC Disconnected%)
00:01:41*junland joined #nim
00:02:21*lritter quit (Quit: Leaving)
00:05:35*chun quit (Remote host closed the connection)
02:13:29*lritter_ joined #nim
02:26:17*lritter_ quit (Quit: Leaving)
02:28:39FromGitter<awr1> https://github.com/nim-lang/Nim/pull/11667
02:29:13FromGitter<awr1> does anyone have an idea of why appveyor screwed up here?
02:29:47FromGitter<awr1> https://ci.appveyor.com/project/dom96/nim/builds/25790889/job/u36wih34lt82kdor
02:29:51FromGitter<awr1> all i did was change a string
02:29:57FromGitter<awr1> it was green before
02:37:32FromGitter<Varriount> @awr1 Looks like the package nim-chronicles failed to build successfully
02:44:44*laaron- quit (Quit: ZNC 1.7.1 - https://znc.in)
02:46:24*laaron joined #nim
02:46:29*drewr joined #nim
02:48:04FromGitter<awr1> yeah appveyor seems to be stuck on chronicles for new PRs
02:48:25FromGitter<awr1> https://ci.appveyor.com/project/Araq/nim/builds/25795637/job/iay3rivnh0eham0n/tests
02:49:10FromGitter<awr1> https://ci.appveyor.com/project/dom96/nim/builds/25790531/job/329oh7nv70qgca2o
02:49:43FromGitter<awr1> ¯\_(ツ)_/¯
02:54:52FromGitter<awr1> i cloned chronicles and am running the tests, am getting this
02:54:55FromGitter<awr1> /home/awr/.nimble/pkgs/faststreams-0.1.0/faststreams/output_stream.nim(2, 38) Error: cannot open file: std_shims/strings
03:08:38FromGitter<awr1> https://github.com/status-im/nim-faststreams/pull/4
03:08:49FromGitter<awr1> can anyone @ status merge this when they get the chance? thanks in advance
04:12:17*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
05:00:39*shashlick joined #nim
05:16:17*narimiran joined #nim
05:18:04*absolutejam1 joined #nim
05:22:40*nsf joined #nim
05:25:21*absolutejam1 quit (Ping timeout: 248 seconds)
06:08:01*meff[m] quit (*.net *.split)
06:08:01*planetis[m] quit (*.net *.split)
06:08:02*k0mpjut0r quit (*.net *.split)
06:08:02*mattisme quit (*.net *.split)
06:08:02*sentreen quit (*.net *.split)
06:08:03*surma quit (*.net *.split)
06:08:03*zestyr quit (*.net *.split)
06:08:03*vegai quit (*.net *.split)
06:12:24*gangstacat quit (*.net *.split)
06:12:24*uvegbot quit (*.net *.split)
06:12:25*zeroDotTwenty[m] quit (*.net *.split)
06:12:25*xomachine[m] quit (*.net *.split)
06:12:25*zielmicha[m]1 quit (*.net *.split)
06:12:25*macsek1911[m] quit (*.net *.split)
06:12:25*gh0st[m] quit (*.net *.split)
06:12:25*Manny8888 quit (*.net *.split)
06:12:26*FromGitter quit (*.net *.split)
06:12:26*nimblepoultry quit (*.net *.split)
06:12:26*snowolf_ quit (*.net *.split)
06:14:57*m712 quit (Ping timeout: 248 seconds)
06:18:06*gangstacat joined #nim
06:18:06*uvegbot joined #nim
06:18:06*zeroDotTwenty[m] joined #nim
06:18:06*xomachine[m] joined #nim
06:18:06*zielmicha[m]1 joined #nim
06:18:06*macsek1911[m] joined #nim
06:18:06*gh0st[m] joined #nim
06:18:06*Manny8888 joined #nim
06:18:06*FromGitter joined #nim
06:18:06*nimblepoultry joined #nim
06:18:06*snowolf_ joined #nim
06:18:27*meff[m] joined #nim
06:18:27*planetis[m] joined #nim
06:18:27*mattisme joined #nim
06:18:27*k0mpjut0r joined #nim
06:18:27*sentreen joined #nim
06:18:27*surma joined #nim
06:18:27*zestyr joined #nim
06:18:27*vegai joined #nim
06:19:34*m712 joined #nim
06:35:30*eterps joined #nim
06:36:40*couven92 joined #nim
06:37:54*solitudesf joined #nim
06:38:43*Vladar joined #nim
06:41:07FromGitter<zacharycarter> kuon: nuklear bindings need updating I think - but there are no circular imports in the bindings I produced
06:41:35FromGitter<zacharycarter> as they're only one module
06:41:41FromGitter<zacharycarter> so you're probably not using my bindings
06:43:55FromGitter<zacharycarter> I plan on using them in my new project - so maybe I'll work on getting them up to date, today
06:48:14kuonzacharycarter it's because I moved the macro and it broke the module in two, I got that figured out.
06:49:54FromGitter<zacharycarter> ah okay cool
06:50:32FromGitter<zacharycarter> yeah - I made those bindings a couple of years ago and didn't keep them up to date, but I will make an effort to do so, if not today then soon
06:50:53kuonno problem:)
07:00:00*gmpreussner quit (Quit: kthxbye)
07:04:42*gmpreussner joined #nim
07:24:57*narimiran quit (Ping timeout: 258 seconds)
07:36:59*stefanos82 joined #nim
07:37:11*Trustable joined #nim
07:47:00*brakmic joined #nim
07:50:58*brakmic quit (Read error: Connection reset by peer)
07:51:28*brakmic joined #nim
07:52:23*Trustable quit (Remote host closed the connection)
08:12:06*nergal[m]1 quit (Write error: Connection reset by peer)
08:12:10*isaac[m] quit (Remote host closed the connection)
08:12:12*leorize[m] quit (Remote host closed the connection)
08:12:16*skrylar[m] quit (Read error: Connection reset by peer)
08:12:16*lqdev[m] quit (Read error: Connection reset by peer)
08:12:16*BitPuffin quit (Read error: Connection reset by peer)
08:12:21*mattisme quit (Read error: Connection reset by peer)
08:12:21*meff[m] quit (Write error: Connection reset by peer)
08:12:21*k0mpjut0r quit (Write error: Connection reset by peer)
08:12:21*planetis[m] quit (Remote host closed the connection)
08:12:22*Swedneck2 quit (Write error: Connection reset by peer)
08:12:23*yglukhov[m] quit (Remote host closed the connection)
08:12:23*spymasterd[m] quit (Remote host closed the connection)
08:12:23*Miguelngel[m] quit (Remote host closed the connection)
08:12:23*narimiran[m] quit (Remote host closed the connection)
08:12:23*Demos[m] quit (Remote host closed the connection)
08:12:24*TheManiac[m] quit (Remote host closed the connection)
08:12:26*Connor[m] quit (Remote host closed the connection)
08:12:27*xomachine[m] quit (Remote host closed the connection)
08:12:27*zeroDotTwenty[m] quit (Remote host closed the connection)
08:12:28*Manny8888 quit (Remote host closed the connection)
08:12:28*macsek1911[m] quit (Read error: Connection reset by peer)
08:12:28*gh0st[m] quit (Read error: Connection reset by peer)
08:12:28*zielmicha[m]1 quit (Remote host closed the connection)
08:12:29*cfv[m] quit (Remote host closed the connection)
08:12:29*GitterIntegratio quit (Write error: Connection reset by peer)
08:18:50*Connor[m] joined #nim
08:19:38*eterps quit (Ping timeout: 252 seconds)
08:23:03*eterps joined #nim
08:23:52*jjido joined #nim
08:29:28*eterps quit (Ping timeout: 264 seconds)
08:31:44*surma quit (Ping timeout: 252 seconds)
08:32:37*dwdv joined #nim
08:32:49*surma joined #nim
08:36:03*chun joined #nim
08:38:28*eterps joined #nim
08:40:13*BitPuffin joined #nim
08:40:13*Manny8888 joined #nim
08:40:13*TheManiac[m] joined #nim
08:40:13*Demos[m] joined #nim
08:40:14*GitterIntegratio joined #nim
08:40:14*k0mpjut0r joined #nim
08:40:14*isaac[m] joined #nim
08:40:14*leorize[m] joined #nim
08:40:14*Swedneck2 joined #nim
08:40:14*nergal[m]1 joined #nim
08:40:14*gh0st[m] joined #nim
08:40:14*lqdev[m] joined #nim
08:40:14*mattisme joined #nim
08:40:20*zeroDotTwenty[m] joined #nim
08:40:20*Miguelngel[m] joined #nim
08:40:20*cfv[m] joined #nim
08:40:21*narimiran[m] joined #nim
08:40:21*yglukhov[m] joined #nim
08:40:21*spymasterd[m] joined #nim
08:40:21*xomachine[m] joined #nim
08:40:21*meff[m] joined #nim
08:40:21*planetis[m] joined #nim
08:40:23*macsek1911[m] joined #nim
08:40:24*zielmicha[m]1 joined #nim
08:40:25*skrylar[m] joined #nim
08:56:40*eterps quit (Ping timeout: 252 seconds)
09:00:29*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:08:24*uvegbot quit (Ping timeout: 252 seconds)
09:09:05*uvegbot joined #nim
09:22:53*chun quit (Quit: Leaving)
09:30:04*uvegbot quit (Ping timeout: 264 seconds)
09:36:52cfv[m]I managed to install the latest nightly build on my RPi! ARMv7 version seems to be working well since the ARMv8 processor on the Raspberry supports software built for ARMv7.
09:40:12*cfv[m] is now known as BaldEagleX02[m]
10:03:43*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
10:04:50*laaron joined #nim
10:25:16*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
10:26:44*laaron joined #nim
10:36:50*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
10:37:00*laaron- joined #nim
10:51:22FromGitter<zacharycarter> shashlick: is nimnuklear in a working state? could save me the time of bringing my bindings up to date
11:19:32*uvegbot joined #nim
11:20:14FromGitter<zacharycarter> I wasn't able to install the project - but I think it might be a problem with nimgen itself
11:20:28*eterps joined #nim
12:09:36*jjido joined #nim
12:16:09*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:22:43*eterps quit (Ping timeout: 246 seconds)
12:30:22*stefanos82 quit (Quit: Quitting for now...)
12:37:13FromGitter<arnetheduck> @awr1 we're considering moving faststreams into `stew` given its small size and general utility (to simplify our dependency mgmt) - any thoughts / opinions on this? (see https://github.com/status-im/nim-stew for a bit of background)
12:39:12FromGitter<arnetheduck> fwiw, chronicles already depends on `stew` indirectly, so roughly it's one less repo to sync / depend on
12:46:52*jjido joined #nim
12:51:32*ganderzz joined #nim
12:53:41*ganderzz quit (Remote host closed the connection)
12:56:51*clyybber joined #nim
13:04:03clyybberAraq: What I meant yesterday is that with eqmove we pass a temporary to a var parameter, which is not a problem in the C backend, but with the CPP backend we generate var parameters as references, and CPP doesn't allow one to pass temporaries to them even if theoretically possible.
13:04:21*NimBot joined #nim
13:07:25*narimiran joined #nim
13:07:30*clyybber quit (Quit: WeeChat 2.5)
13:09:02*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:13:40*solitudesf quit (Ping timeout: 272 seconds)
13:13:58*Snircle joined #nim
13:20:48FromGitter<awr1> @arnetheduck makes sense considering stew's scope
13:24:16FromGitter<awr1> i would put the modules it provides in the readme though or people aren't gonna understand what stew is for
13:31:13*vlad1777d__ quit (Ping timeout: 248 seconds)
13:41:02*solitudesf joined #nim
13:53:57FromGitter<arnetheduck> you mean like https://github.com/status-im/nim-stew#notable-libraries ? :)
13:56:49FromGitter<arnetheduck> think I might move that higher up though, the rest is sort of admin
14:00:07*lf-araujo joined #nim
14:01:27FromGitter<awr1> yeah i didn't see that, you should move it higher
14:04:36*lf-araujo quit (Ping timeout: 244 seconds)
14:05:09*lqdev[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/KDsQnRKawFiFGdlBoIgoXrBN >
14:05:12lqdev[m]what the hell?
14:09:45*lf-araujo joined #nim
14:19:43*livcd quit (Ping timeout: 258 seconds)
14:30:17*dddddd joined #nim
14:31:47*lf-araujo quit (Remote host closed the connection)
14:52:40*stefanos82 joined #nim
14:52:47*clyybber joined #nim
14:53:55Araqclyybber, but the temporary is produced by Nim too
14:54:07Araqfor C++ it's just another variable that can be passed to 'T&'
14:59:01clyybberIf we patch the compiler to generate that temporary that is.
14:59:08clyybberBut currently it doesn't
14:59:26clyybbersince normally you arent allowed to pass a temporary to a var parameter
15:00:51clyybberSo what I want to argue we should do, is make the C backend generate T* instead of T&
15:01:03clyybbers/C backend/CPP backend
15:03:15FromGitter<phrmoy> (https://files.gitter.im/nim-lang/Nim/1z2U/image.png)
15:03:20FromGitter<phrmoy> This is truly outstanding.
15:03:41FromGitter<phrmoy> And they chose Swift for their tensorflow frontend
15:03:48FromGitter<phrmoy> what a joke
15:04:33disrupteki know, it's obscene that python doesn't have better syntax highlighting by now.
15:04:41*disruptek runs and hides.
15:04:47FromGitter<awr1> what types of optimizations can a C++ compiler do with T& vs. T*
15:05:48clyybberawr1: I don't know, but the fact that C++ doesn't allow modifying a temporary (or passing a temporary to T&) is an ergonomics feature
15:06:10FromGitter<awr1> https://stackoverflow.com/a/9039469/10444138
15:06:11FromGitter<awr1> hm
15:07:12Araqclyybber, read the spec, a temporary has to be generated
15:07:15clyybberawr1: I assume it only does that when you are not actually modifiyng the underlying variable
15:07:25clyybberAraq: But =move doesn't have a sink parameter
15:07:34clyybberI'm talking about this: "eqmove__jRxUrAfjudolXPsxKTlFXg(result, rawNewString(((NI) 32)));"
15:08:46AraqI know, =move isn't called by the Nim programmer
15:08:54Araqit's called by the injectdestructors transformation
15:09:06Araqand you need to pass a temporary to it
15:09:30Araqmaybe the spec could be clearer
15:11:49clyybberAraq: Wait, so 'foo = bar()' gets transformed to 'foo; var tmp; `=`(tmp, bar()); `=move`(foo, tmp)' ?
15:12:18Araqno.
15:12:27Araqor
15:13:12Araqmore like 'bitwiseCopy(tmp, bar()); =move(foo, tmp)
15:13:41clyybberyeah, sry I meant that basically
15:14:31clyybberAraq: But won't that make it impossible to return an owned ref?
15:14:56clyybberSince at some point both the result of bar() and tmp are pointing to the same location?
15:14:59Araqhow so?
15:18:43Araqsorry, gotta go, bll
15:18:45Araqbbl
15:19:46clyybberbb
15:20:37clyybberand nevermind the concern with the owned ref
15:22:08clyybberAraq: Still, technically C (and CPP) allows us to pass a temporary directly to move, and generate `=move`(foo, bar())
15:22:23clyybberSo I figured why not do that?
15:23:06clyybberBut maybe its not worth it, depending on how the C compiler optimizes the bitwiseCopy away
15:38:12FromGitter<zacharycarter> how can I fix - `cannot evaluate 'sizeof/alignof' because its type is not defined completely` ?
15:40:44clyybberzach: What type is it?
15:41:35FromGitter<zacharycarter> a type imported from C
15:41:49FromGitter<zacharycarter> but just doing something like - `type nk_window* {.importc: "nk_window", bycopy.} = object`
15:41:59FromGitter<zacharycarter> will cause this error to be thrown when called with `sizeof`
15:42:22FromGitter<awr1> you need to fill out the fields to get a proper sizeof from nim probably
15:43:03FromGitter<zacharycarter> I figured removing fields might make the error go away - but that's not the case
15:43:08FromGitter<zacharycarter> I've tried with the object having fields and with it not having fields
15:45:50FromGitter<awr1> add `{.final.}` maybe?
15:48:00FromGitter<awr1> either that or the types of the fields are not defined in the same respect
15:48:36FromGitter<awr1> for sizeof to work i believe nim needs to have "the full picture"
15:49:14clyybberAraq: Nevermind most of what I said above.
15:49:16FromGitter<zacharycarter> well technically I don't think I need to `importc` these types since I'm using the `{.compile.}` pragma on a `.c` file that includes the header file these types are defined in
15:49:26FromGitter<zacharycarter> so I'll just grid of the importc pragma - that seems to solve the problem
15:52:20FromGitter<awr1> for the record you don't need to pass a string to `importc`if you want it to be the same name as the nim identifier
15:54:32FromGitter<zacharycarter> I know - c2nim generated that stuff
15:55:14FromGitter<awr1> o ok
16:14:48*couven92 quit (Ping timeout: 272 seconds)
16:15:23*shashlick quit (Remote host closed the connection)
16:16:14*shashlick joined #nim
16:17:43*brakmic quit (Remote host closed the connection)
16:17:59*brakmic joined #nim
16:25:44lmariscalIs @kraptor in here by any chance?
17:09:54*narimiran quit (Ping timeout: 258 seconds)
17:25:31*laaron- quit (Remote host closed the connection)
17:26:02*stefanos82 quit (Quit: Quitting for now...)
17:40:12*m|b joined #nim
17:57:51*brakmic quit (Read error: Connection reset by peer)
17:58:26*brakmic joined #nim
18:05:36*brakmic quit (Read error: Connection reset by peer)
18:05:44*brakmic_ joined #nim
18:10:48*brakmic_ quit ()
18:11:08*brakmic joined #nim
18:11:13FromGitter<zacharycarter> hmm - if I compile with verbosity 3, the compiler crashes
18:11:19FromGitter<zacharycarter> if I use 2 or default the compiler just hangs
18:11:33FromGitter<zacharycarter> I forget how to debug the compilation - will try to googl eit
18:13:53FromGitter<zacharycarter> I think I figured it out - `./koch temp c /tmp/test.nim`
18:17:30FromGitter<zacharycarter> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d22373a9a8a5d3cf4b2c0dd]
18:18:31ZevvI've seen that before
18:18:59Zevvhttps://github.com/nim-lang/Nim/issues/9605?
18:19:50Zevvhm that doesn't hang on verb lower then 3, but the stack trace tail is similar to yours
18:21:20FromGitter<zacharycarter> ooph - open since Nov?
18:22:01FromGitter<zacharycarter> I crash without even using nim temp
18:23:09FromGitter<zacharycarter> I guess I'm stuck then atm - compilation just hangs and if I try to increase verbosity in an effort to maybe figure out why, it crashes with that error
18:24:24Zevvcan you share some code to reproduce?
18:27:27FromGitter<zacharycarter> it's a lot of code
18:27:32FromGitter<zacharycarter> it's the demo for the nuklear Nim bindings
18:27:51FromGitter<zacharycarter> let me update the repo and I'll give instructions on how to reproduce the erroor
18:28:45ZevvI probably can't figure it out, but a reproducing example might inspire araq to take a look
18:29:21lmariscaldom96 any progress on https://github.com/nim-lang/nimble/issues/482 ? I do not like to be pushy, I just want to know if this feature is still in the plans.
18:30:09dom96Sure, it's in the plans
18:30:42FromGitter<zacharycarter> ```code paste, see link``` ⏎ ⏎ NOTE: need to have glfw3.dll installed [https://gitter.im/nim-lang/Nim?at=5d223a5151d87058befba1c8]
18:31:12*livcd joined #nim
18:33:00Zevvmissing glfw3.nim?
18:34:04Zevvimport glfw3 as glfw, opengl
18:34:36FromGitter<zacharycarter> I do have the glfw3 nimble package installed
18:35:00Zevvi can't seem to find that - only glfw, not glfw3
18:35:25FromGitter<zacharycarter> try - `nimble install nimrod-glfw`
18:37:35FromGitter<kayabaNerve> Do you guys remember Nake?
18:37:38FromGitter<kayabaNerve> I liked it :(
18:37:40Zevvhm dependency hell - on linux opengl nimble tries import X
18:37:46Zevvwhich is not there
18:38:26FromGitter<zacharycarter> bleh
18:40:29Zevvok I got that hacked by local fixes in opengl nimble: import x11/X x11/Xlib instead
18:40:30Zevvnow I get
18:40:43Zevvhttp://ix.io/1NXh
18:40:58Zevvbah
18:41:48FromGitter<zacharycarter> weird
18:42:17FromGitter<zacharycarter> you're probably getting further than I am
18:42:40FromGitter<zacharycarter> mine hangs at the line - CC: glfw3_opengl3.nim
18:42:53Zevvfixed this by adding #include <stdarg.h> to nuklear.h
18:42:54Zevvand now I hang
18:43:02FromGitter<zacharycarter> bleh okay
18:43:04Zevvreproduced!
18:43:10FromGitter<zacharycarter> yay! thank you!
18:44:35*nsf quit (Quit: WeeChat 2.4)
18:46:54Zevvit looks as if the c compilers stderr is not eaten, so it hangs on a write()
18:48:02FromGitter<zacharycarter> hmmm
18:49:05*eterps joined #nim
18:49:44Zevvnim is waiting for gcc to finish. Gcc is waiting for cc1, and cc1 is blocked because its pipe to stderr is full
18:49:54FromGitter<zacharycarter> wonderful
18:50:01Zevvos plumbing galore
18:50:21FromGitter<zacharycarter> I got some helpful output by killing `cc1.exe` in task explorer
18:51:00FromGitter<zacharycarter> apparently all of these `@`'s in nuklear.nim are causing issues
18:51:34Zevvyeah I see something similar in strace
18:51:38Zevvsanitizng the output for you
18:51:53Zevvbut the root cause of the hanging nim is nasty
18:52:06FromGitter<zacharycarter> agreed
18:52:48Zevvhttp://ix.io/1NXl
18:52:53Zevvthat is what cc1 is saying
18:52:56Zevvbut noone is listening
18:53:32*laaron joined #nim
18:54:35FromGitter<zacharycarter> haha ooph - okay thanks! I'll get rid off all these `@`'s and see what happens
18:54:45Zevvusually the compiler will barf out after so many errors occur
18:54:47Zevvbut this keeps going
18:55:37Zevvbetter version: http://ix.io/1NXp
18:56:57*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
18:57:33ZevvI can reproduce with a nim oneliner
18:57:52ZevvI'll file an issue
18:59:26Zevvah known issue
18:59:29Zevvhttps://github.com/nim-lang/Nim/issues/8648
19:03:02FromGitter<zacharycarter> ah okay well that's good - at least it's been reported
19:03:24FromGitter<zacharycarter> okay I got to the program actually running - it still crashes but hopefully I can take it from here - thank you for the help Zevv!
19:03:30Zevvyw
19:18:31*xace quit (Ping timeout: 246 seconds)
19:19:51Araqoh nice. I didn't think of that solution, Zevv
19:20:09Zevvnot that nice, actually. Fix is nasty
19:20:13Araqin my mind fixing osproc was the only way ... but so far we failed
19:23:09Zevvosproc should probably learn to work with async, although that added complexity is not something you would want to use from the compiler itself I guess
19:26:14*absolutejam1 joined #nim
19:34:47*xace joined #nim
19:48:49*m|b quit (Quit: Connection closed for inactivity)
20:03:48shashlickThere's already https://github.com/cheatfate/asynctools
20:06:21*abm joined #nim
20:08:37Zevvwhoah
20:09:45Zevvhow is it that there is so much great stuff i never heard about. We really need a curated list of recommended nimbles
20:12:17*tdog quit (Quit: Leaving)
20:12:25shashlickAgreed, we need a third party equivalent of https://nim-lang.org/docs/lib.html
20:12:43shashlickStuff that is tested in important packages is a good start
20:12:57shashlickShould include generated docs too
20:12:59rayman22201Cheatfate's async package in particular could arguably go in the std lib. It's that useful!
20:13:49rayman22201his code is a masterclass in async
20:14:36shashlickI really wonder what the criteria is for stuff to get pulled into the stdlib
20:15:06shashlickI haven't seen it happen in all the time I've tracked Nim
20:16:51ZevvIve heard rumours that ideally everything not needed by the compiler itself should be moved out
20:17:00rayman22201I'm being facetious. I think your idea of an "official important packages" is more inline with the Nim philosophy .
20:19:51*eterps quit (Ping timeout: 264 seconds)
20:20:16*lf-araujo joined #nim
20:21:55rayman22201Araq had also brought up the idea of creating a special "batteries included" distribution of Nim, with important libraries included, kind of like a "stdlib ++". For those that want it. I kind of like that idea.
20:24:05Zevvthat makes sense. The core devs should not have to bother with that, the effort can be made by others who just use the compiler and a bunch as libs as upstream
20:24:17FromGitter<awr1> @kayabaNerve nake kinda got repurposed into the nimscript build stuff
20:25:30kungtotteWouldn't that distribution basically just be the core Nim distribution and a list of packages for Nimble to install?
20:25:56kungtotteOr was the idea that it would be a giant installer that packaged everything ready to go?
20:26:17Zevvthe istaller could of course use nimble, but I guess the package should be presented as a whole
20:26:23Zevvdocs, overview, tutorials
20:26:30Zevvnim starter pack
20:26:40FromGitter<zetashift> Random question but are concepts still slated for 1.0?
20:27:12rayman22201I don't think too much thought was put into it, but "nim starter pack" is the right idea.
20:27:53FromGitter<awr1> the list of packages could be done itself as just a nimble package with them as dependencies
20:27:59rayman22201@zetashift, I don't think so. Too many problems and Araq wanted to completely rework them. IIRC
20:28:43FromGitter<awr1> i like the way concepts work in theory
20:29:25Calinouthat reminds me, I'm moving a package from docopt to cligen
20:29:30Calinouor at least trying to :)
20:30:28rayman22201Too many people try to use concepts as interfaces, and they don't work well for that use case.
20:31:28Calinouas for "batteries included", to me, the Nim stdlib already feels quite large to me
20:31:33Calinouit supports many things other languages' stdlibs don't
20:31:38clyybberI concur
20:31:39FromGitter<awr1> thing is i've never personally had to use concepts for much of anything. most of what nim's type system does already seems to suffice for me. to me concepts would be useful in the sense of of programmers, for instance, requiring alternative implementations of things from the stdlib
20:31:52FromGitter<awr1> or well
20:32:13rayman22201awr1: an interface is what you need for that, not a concept
20:32:15FromGitter<awr1> i'm rambling, but things like openArray
20:32:21rayman22201openArray is an interface
20:32:34rayman22201a special built in one, but still
20:32:43FromGitter<awr1> then what would a concept be useful for?
20:33:04*lf-araujo quit (Ping timeout: 258 seconds)
20:33:15clyybberrayman22201: How is a concept not an interface? I'm sorry I never really understood that :p
20:33:45rayman22201exactly :-P that is why Araq pulled them from 1.0
20:34:10Calinoustyle guide question: do you use 1 or 2 line breaks between procs?
20:34:19Calinouhttps://nim-lang.org/docs/nep1.html doesn't seem to mention anything about it
20:34:28*abm quit (Ping timeout: 272 seconds)
20:35:07rayman22201concepts are half way between an affine or structural type and an interface, and they don't do either one very well.
20:35:26FromGitter<awr1> 1 line break
20:35:28FromGitter<awr1> https://github.com/nim-lang/Nim/blob/devel/koch.nim#L104
20:35:45FromGitter<awr1> unless you're counting the one after the last character of the proc
20:35:53FromGitter<awr1> then it would be two
20:35:58clyybberIsn't the only difference between a concept and an interface, that the concept matches without explicitly telling the compiler?
20:36:53clyybberOr is an interface always checked at runtime, while a concept is checked at compiletime?
20:37:00*brakmic quit (Ping timeout: 272 seconds)
20:37:11rayman22201Concept is compile time, interface is runtime
20:37:29FromGitter<zetashift> @rayman22201 thanks! Yeah I remember reading about that they needed a rework
20:37:39FromGitter<zetashift> I thought they were like traits
20:37:57clyybberrayman22201: And what does an interface effectively allow me to do, that a concept can't?
20:38:25Calinou@awr1 thanks :)
20:39:19rayman22201interface implements a vtable, so you can have a function take two different types even if they are different sizes.
20:39:26*brakmic joined #nim
20:39:45FromGitter<awr1> if `concept` is compiletime then it seems to me that openArray should be a concept
20:40:28FromGitter<awr1> because the programmer at hand should ideally be able to extend openArray past array and seq
20:41:25clyybberrayman22201: Thanks
20:41:58rayman22201The problem is `concepts` are not well defined.
20:42:16Araqeasiest explanation: seq[Iface] is a heterogenous container
20:42:20Araqseq[Concept] isn't.
20:42:42FromGitter<mratsim> Iface?
20:42:52rayman22201exactly. I was digging through the forum. There was a good example recently: https://forum.nim-lang.org/t/4965
20:43:06rayman22201Iface == Interface
20:43:59FromGitter<mratsim> yeah but I thought the point of concepts was to be more general than interfaces, and the point of VTable to be able to have heterogeneous containers of types that respect a concept
20:44:11*narimiran joined #nim
20:44:49FromGitter<awr1> this person sounds like they want a "thinner" variant
20:44:50FromGitter<mratsim> also @awr1 there is a feature request to start using Indexable and Iterable concepts in the standard library. If that is done, openarray could arguable also accept those.
20:45:02Araqargh... the way I implemented 'owned' doesn't allow for type conversions of 'owned' types
20:45:10Araqepic failure...
20:45:20Araqhmmm
20:45:26FromGitter<mratsim> oh and this one too: https://github.com/nim-lang/RFCs/issues/22
20:45:50AraqopenArray is really nice the way it is
20:46:14Araqwe can extend it later to give us Rust-like borrowing for important cases
20:46:14FromGitter<ratiotile> Does Nim have static fields, or somewhere to store values in common with all instances of an object?
20:46:19FromGitter<mratsim> https://github.com/nim-lang/RFCs/issues/50
20:46:34FromGitter<awr1> @ratiotile generic params
20:46:51FromGitter<awr1> wellll
20:46:55FromGitter<awr1> hm
20:46:57FromGitter<mratsim> fields on the super type are shared
20:47:16Araqthere are no 'static fields', use a global instead
20:47:26FromGitter<mratsim> ah for instances, use an initializer proc or global
20:47:39FromGitter<ratiotile> I was hoping to avoid using prefixes and have the type as a namespace itself
20:48:19Araqglobals now require prefixes? that's news to me
20:48:51FromGitter<ratiotile> I mean something like Foo.max_size=123 vs foo_max_size=123
20:48:56FromGitter<awr1> yeah they all have to start with g_ now :P
20:49:05FromGitter<mratsim> :D
20:49:16Araqtemplate maxSize(t: typedesc[Foo]) = 123
20:50:08FromGitter<ratiotile> That works for constants
20:51:05Araqtemplate maxSize(t: typedesc[Foo]) = foo_maxSize
20:51:05FromGitter<mratsim> proc `maxSize=`(t: typedesc[Foo], size: int) = myHiddenGlobal {.global.} = size
20:51:13FromGitter<mratsim> mine is better :p
20:51:28Araqis .global even in the spec? :P
20:51:44FromGitter<awr1> do templates have a default return type now?
20:51:50FromGitter<awr1> as `untyped`, assumedly
20:51:54FromGitter<mratsim> void?
20:52:12FromGitter<ratiotile> thanks
20:52:37Araqoh yeah, the default to 'void' and my examples should use 'untyped', mea culpa
20:53:16FromGitter<awr1> i have long kinda felt templates should default to `untyped`
20:53:29FromGitter<awr1> that way it would be easier to be able to alias things
20:53:35FromGitter<ratiotile> why not `auto`?
20:54:06Araqconsistency with 'proc'
20:54:19FromGitter<awr1> `template xyz: untyped = abc` in the sense of `xyz` being an alias for `abc` could be shortened to `template xyz = abc`
20:54:39Araqawr1: I agree but now it's kinda too late for that
20:54:41FromGitter<awr1> yeah but don't macros have default return of `untyped`?
20:54:52Araqmacros don't have a default
20:55:27FromGitter<mratsim> I'd like an `alias` keyword or something
20:55:46FromGitter<mratsim> well I can create an alias macro, and put it in sugar
20:56:50Araqanyway, consistency trumps everything, after all, why should 'template' NOT be exactly the same as 'proc'? I mean, sure, one has expansion semantics and the other one hasn't, 'return' in templates is really different from 'return' in 'proc', but hey! consistency!
20:58:00FromGitter<awr1> wait can you do `return` in templates with the keyword?
20:58:04*eterps joined #nim
20:58:13FromGitter<awr1> everytime i've tried it before with the keyword it doesn't work
20:58:31Araqtemplate checkBounds() =
20:58:38Araq if a < 0 or a > 100: return
20:58:46Araq^ why wouldn't it work?
20:58:50FromGitter<awr1> ohhhhhhhhh
20:58:54FromGitter<awr1> so that would be in the context of a proc
20:59:00Araqexactly
20:59:04FromGitter<awr1> gotcha
20:59:59*lf-araujo joined #nim
21:00:13FromGitter<ratiotile> Well, I should report that I tried my benchmark with the closure iterators, and in my initial implementation it's 3x slower than using `asyncdispatch`. So async is actually pretty efficient already.
21:01:08Araqgiven that async uses closure iterators that's actually quite impossible
21:03:51shashlickSlowly crawling out of vacation mode
21:04:05FromGitter<ratiotile> Yeah I expect an optimal version to be about the same. Currently there's some additional indirection going on to allow Tasks to call and wait for other Tasks. I'm working on smoothing it out
21:04:09shashlickAraq: do you have some time to review https://gist.github.com/genotrance/b835bd9318dadb7541c0db5d9fe45ec7
21:06:40Araqplease use UpperCased for types
21:06:58Araqyou types need '=' and '=sink' and '=destroy'
21:07:02Araq*your
21:08:02Araqif x.len == 0: x.add "foobar" # racy
21:08:33Araqin other words, shared data structures need much more API design
21:08:45Araqand most APIs are broken by default
21:10:57Araqbut it depends on your use case, of course
21:11:36Araqif all you want is a 'shared memory' string, you don't need the locks
21:13:20Calinouhow can I read multiple positional arguments efficiently using cligen? Having to use args: seq[string] looks suboptimal/less safe to me
21:13:23*lf-araujo quit (Ping timeout: 245 seconds)
21:13:27Calinou(with different types, that is)
21:13:35Calinouthe first one is a Color, the second one is a float, and I don't expect more than 2
21:13:53CalinouI could do validation myself still but it's less fun :P
21:14:01Araqif you need a 'shared' string where multiple threads can append to, 'proc len' should assert that no other thread is accessing the string anymore
21:14:48shashlickThanks Araq - how's the seq looking so far?
21:15:15shashlickNeeds lots of optimization but should allow me complex objects
21:15:24shashlickMore
21:15:38*narimiran quit (Ping timeout: 272 seconds)
21:15:55shashlickThat's why I was using the locks
21:16:06Calinou(also, I can't seem to convert a string extracted from a sequence into a float)
21:16:22*Vladar quit (Remote host closed the connection)
21:17:13*eterps quit (Ping timeout: 250 seconds)
21:18:37FromGitter<kayabaNerve> @awr1 I know. Difference is Nimscript is Nimscript and Nim is Nim.
21:19:20shashlickWhat do you mean when you say "need more api design"
21:19:42shashlickI'm attempting to have similar capabilites as standard strings or seqs
21:19:58shashlickThough the price will be heavy due to copying
21:20:13Araqshashlick, seq looks too complex, see tcustomseqs.nim for an implementation
21:20:43FromGitter<awr1> the only reason i've ever needed nake in lieu of nimscript was for a CPU extension detection thing
21:21:25Araqand the single global lock man ... remove it, it's not necessary
21:21:54Araqit's much better and easier to push the locking to the clients of your data structure
21:31:54shashlickThe single global lock is ugly, could make one per instance but wondering if there are lock limits
21:32:22shashlickI agree it would be more sensible to defer that to the client
21:32:51shashlickBut for the lazy who want shared without too much effort
21:33:55*sagax joined #nim
21:38:50FromGitter<ratiotile> in other words, a lock-free api
21:46:43Calinounevermind for my cligen problem, I redesigned my CLI options and it's now more user-friendly and easier to code
21:47:04Calinoumost importantly, it allows performing multiple operations at once: https://i.imgur.com/ZruNBv2.png
21:54:25*Sencatsu quit (Quit: WeeChat 2.5)
21:55:49clyybberDoes anyone else experience test case failures on devel with asyncfutures?
21:59:11AraqCIs are green, so no
21:59:34clyybberHmm, so I fucked up somewhere; great \o/
21:59:36Araqbut these tests are kinda fragile so don't worry
21:59:56clyybberCannot instantiate Future does sound really bad tho :p
22:02:50clyybberAraq: https://github.com/nim-lang/Nim/blob/devel/compiler/injectdestructors.nim#L504 can it really?
22:03:47clyybberI'm currently dealing with a sigsegv resulting from passing a 'static const NimStringV2' to a sink parameter
22:03:58*lf-araujo joined #nim
22:04:53clyybberOr rather: Where does the string implementation handle that?
22:05:33clyybberBecause I think I might need to patch it to handle being passed to a sink parameter too, unless you want me to generate a temporary copy instead, as we do for the seq case.
22:10:25lf-araujoHi all! Look, Nim support added to cheat.sh:
22:10:29lf-araujohttps://github.com/chubin/cheat.sh/issues/112
22:11:53lf-araujoCould you guys check and chime in in the above thread? Many thanks... I will test it too later this week...
22:12:42FromGitter<ratiotile> I rewrote my benchmark to only use if statement state machine, and it's only 2x slower than C++. That's pretty good. It's also 140x faster than my prior await implementation. I'll have to revisit that. One issue might be using array of arrays instead of a single array.
22:13:58FromGitter<ratiotile> 1) with all ref objects, not optimized
22:17:32*lf-araujo quit (Ping timeout: 245 seconds)
22:18:49Araqtemplate frees(s) =
22:18:49Araq if not isLiteral(s):
22:18:49Araq s.p.allocator.dealloc(s.p.allocator, s.p, contentSize(s.p.cap))
22:18:57Araqtemplate isLiteral(s): bool = s.p == nil or s.p.allocator == nil
22:19:15Araq^ string literals have no allocator and are never freed not mutated
22:19:19Araq*nor
22:19:32Araqproc prepareAdd(s: var NimStringV2; addlen: int) {.compilerRtl.} =
22:19:32Araq if isLiteral(s) and addlen > 0:
22:19:32Araq let oldP = s.p
22:19:32Araq # can't mutate a literal, so we need a fresh copy here:
22:19:32Araq let allocator = getLocalAllocator()
22:19:37Araqetc
22:20:07Araqbut maybe a nimMoveStrV2 is required indeed ;-)
22:20:08*brakmic quit ()
22:21:34*stefanos82 joined #nim
22:21:47Calinouhow do I set up my Nim file so that "nim doc" generates documentation correctly?
22:22:28Calinousome of my procs already have ## comments
22:22:46Calinouor I suppose it only generates docs for exported procs?
22:25:43*sagax quit (Read error: Connection reset by peer)
22:25:46*solitudesf quit (Ping timeout: 244 seconds)
22:40:11Araqonly for exported procs, yes
22:44:43*Senketsu joined #nim
22:54:45clyybberAraq: It looks like a nimMoveStrV2 is required indeed :)
22:54:57clyybberaccording to gdb
23:09:44*dwdv quit (Quit: quit)
23:21:25*absolutejam1 quit (Ping timeout: 246 seconds)
23:22:51*sealmove joined #nim
23:25:45clyybbergn8
23:25:46*clyybber quit (Quit: WeeChat 2.5)
23:28:13*rockcavera joined #nim
23:43:47*cybj quit (Quit: WeeChat 2.4)