<< 24-02-2020 >>
00:14:12*azed joined #nim
00:20:04*krux02 quit (Remote host closed the connection)
00:24:50*azed quit (Quit: WeeChat 2.7)
00:25:54*my_dude quit (Quit: ZZZzzz…)
00:38:02FromDiscord_<Simula> is there a reason that nobody overloads `new` as a constructor for their ref objects?
00:39:08FromDiscord_<Simula> like, `proc new(t: typedesc[MyRefObject]) = something`
00:41:00FromGitter<kristianmandrup> Finally got Nim to generate Javascript with ES modules import working :)
00:42:37FromDiscord_<slymilano> noice!
00:44:56FromDiscord_<exelotl> @Simula huh that's quite a nice idiom
00:45:28FromDiscord_<Simula> yeah i used to use it, but i stopped because nobody else used it and i was worried there was a really good reason not to
00:45:40FromDiscord_<Simula> but the more i look into it, the less reason i see not to use it :P
00:46:23*dwdv quit (Quit: quit)
00:47:23FromDiscord_<exelotl> like this? https://play.nim-lang.org/#ix=2cx2
00:48:12FromDiscord_<Simula> yeah, exactly!
00:57:15FromDiscord_<exelotl> I had a look and the generated C code is identical to if you'd done newFoo()
00:57:50*hax-scramper quit (Remote host closed the connection)
00:58:23*hax-scramper joined #nim
00:59:27FromGitter<deech> Does nimble support a "dry-run"? I would like to see the sequence of `nim` commands that nimble will run for a given task.
00:59:28FromDiscord_<exelotl> maybe it's not done because passing a typedesc argument solely for the purpose of overloading disambiguation feels like a bit of a hack and isn't very beginner friendly
01:04:33*filcuc quit (Ping timeout: 272 seconds)
01:19:24*freddy92 quit (Quit: Client Disconnecting)
01:19:54FromDiscord_<exelotl> @Simula https://play.nim-lang.org/#ix=2cxe
01:20:06FromDiscord_<exelotl> made a cheeky macro
01:20:56FromDiscord_<Simula> it never ceases to amaze me what you can do with macros
01:22:12FromDiscord_<exelotl> yeah they're pretty special x)
01:22:53FromDiscord_<exelotl> not sure if this is the best way to implement such a feature but I'm pretty happy with it as a 20 minute proof of concept
01:23:52FromDiscord_<exelotl> like maybe something that takes an `init` and generates a corresponding `new` would be more appropriate instead
01:38:11FromDiscord_<Simula> i wish there were a book out there that taught how to think in terms of macros
01:57:34FromDiscord_<exelotl> Nim in Action did it for me :)
02:05:48*Hideki_ joined #nim
02:10:11*Hideki_ quit (Ping timeout: 260 seconds)
02:11:41*chemist69 quit (Ping timeout: 272 seconds)
02:13:19*chemist69 joined #nim
02:16:43*dadada quit (Ping timeout: 260 seconds)
02:17:52*oprypin quit (Remote host closed the connection)
02:18:59*oprypin joined #nim
02:21:09*dadada joined #nim
02:21:34*dadada is now known as Guest7113
02:25:59*Guest7113 quit (Ping timeout: 265 seconds)
02:36:07*dadada_ joined #nim
02:45:26*moduledge joined #nim
02:48:49disrupteknimble won't install nimph because... Missing directory /home/travis/build/disruptek/nimph/src/docs. Continue? [y/N]
02:49:14disrupteki dunno what this means... should my docs directory be inside the src?
02:49:30disruptekmy tests are failing as a result.
02:49:38*dadada_ quit (Ping timeout: 240 seconds)
02:51:14*dadada_ joined #nim
03:05:15*dadada_ quit (Ping timeout: 260 seconds)
03:06:10*dadada joined #nim
03:06:35*dadada is now known as Guest56533
03:06:45disruptekwhat should we change about the stream, leorize?
03:09:08leorizehave you fixed the mic issue?
03:09:23leorizeI got my twitch account working now :)
03:09:32disruptekah, nice.
03:09:36disruptekwhat's the mic issue?
03:10:14*my_dude joined #nim
03:11:30leorizeonly got sound on left ear?
03:11:51disruptekthat was fixed /before/ the last stream, afaik.
03:12:21leorizethen I guess it's fine
03:12:57disruptekhow is the font size?
03:13:09leorizeshould be ok now
03:13:33disruptekit would suck if i couldn't do 2-up 80-col.
03:14:58leorizeI thought you have a 4k screen?
03:15:25disrupteki do. i can make the font a lot smaller, but that doesn't buy you anything, right?
03:15:45*my_dude quit (Quit: ZZZzzz…)
03:15:54leorizewell I guess there are compromises to be made when you stream
03:16:05disruptekno; this is how i code.
03:16:48disrupteki still don't understand why i can't consume more cpu to get a higher framerate, though.
03:18:47leorizedo you have a decent gpu?
03:18:55leorizethen you can just use that thing encoder
03:19:06disrupteki'm probably not using nvenc because i'm on nouveau.
03:19:20leorizeget amd :)
03:19:40disrupteknext time, probably.
03:19:48*Guest56533 quit (Ping timeout: 258 seconds)
03:19:49leorizeyou can't get intel quicksync on linux so... you're out of options, really
03:20:20*my_dude joined #nim
03:21:07*dadada_ joined #nim
03:21:30disrupteki swore i would never buy amd again after their driver experiences from the old days.
03:21:43disrupteknow, nvidia drivers in linux are forcing me the other way.
03:22:09leorizeif you don't do windows then amd is quite decent
03:22:26leorizeotherwise I heard that their windows driver is also terrible
03:23:15*muffindrake quit (Ping timeout: 272 seconds)
03:23:22disruptekyeah, that's the problem.
03:23:42leorizewell I don't have any problem, though I'm using last-gen hardware
03:23:46disrupteki've only been on linux for a year. i was on mac for about 10 years before then.
03:23:59disruptekwhat's last-gen?
03:24:11leorizerx580
03:25:21*muffindrake joined #nim
03:25:22disrupteki just can't believe my cpu can't muscle a few more frames.
03:25:42disrupteki mean, shit.. 8fps at 2% utilization and you're telling me i can't add a few more?
03:26:48leorizesearch for a guide online I guess
03:27:14disruptekyeah, i need an 11-year-old kid.
03:35:04*dadada_ quit (Ping timeout: 255 seconds)
03:41:01*dadada_ joined #nim
03:48:06*ptdel quit (Ping timeout: 240 seconds)
03:49:42*dadada_ quit (Ping timeout: 258 seconds)
03:51:09*dadada_ joined #nim
04:05:04*dadada_ quit (Ping timeout: 265 seconds)
04:06:08*dadada joined #nim
04:06:33*dadada is now known as Guest74340
04:10:45*my_dude quit (Ping timeout: 272 seconds)
04:19:55*Guest74340 quit (Ping timeout: 260 seconds)
04:21:06*dadada_ joined #nim
04:26:26*nsf joined #nim
04:34:56*dadada_ quit (Ping timeout: 258 seconds)
04:36:14*dadada_ joined #nim
04:41:42*Tanger quit (Remote host closed the connection)
04:48:11*Tanger joined #nim
04:50:15*dadada_ quit (Ping timeout: 260 seconds)
04:51:07*dadada_ joined #nim
05:05:04*dadada_ quit (Ping timeout: 255 seconds)
05:06:10*dadada joined #nim
05:06:35*dadada is now known as Guest85106
05:19:47*Guest85106 quit (Ping timeout: 258 seconds)
05:21:12*dadada_ joined #nim
05:35:00*dadada_ quit (Ping timeout: 272 seconds)
05:36:11*dadada_ joined #nim
05:48:40moduledgeHey folks, I need some advice on a project I'm trying, in order to relearn Nim again. I'm wondering what's the best way for Nim to access the acpi features of a Linux system? I'm trying to write a very simple cli app that suspends my monitors as a good warm up exercise and as a tinker toy to mess around with. :)
05:49:01*NimBot joined #nim
05:50:04*dadada_ quit (Ping timeout: 258 seconds)
05:51:09*dadada_ joined #nim
05:51:43FromDiscord_<Elegant Beef> easiest way would probably to use the os/osproc and exec it
05:57:32moduledgeWell, for me it's gotta be a bit more challenging than that. I want to be able to get under the hood and use Linux syscalls or whatever to implement an xset like tool, as an example :)
06:05:00*dadada_ quit (Ping timeout: 252 seconds)
06:06:05*dadada joined #nim
06:06:30*dadada is now known as Guest54229
06:07:32*Hideki_ joined #nim
06:09:38*dddddd quit (Ping timeout: 240 seconds)
06:11:38*Hideki_ quit (Ping timeout: 240 seconds)
06:16:46leorizemoduledge: it's all in /sys
06:17:30leorizethe linux kernel userspace interface is mostly rooted in special file systems rather than syscalls like most other OS
06:18:04leorizethere's also /proc/acpi
06:19:16leorizefor suspending your monitor, it'd be more of communicating with your X server or wayland compositor than tackling the device directly
06:20:02*Guest54229 quit (Ping timeout: 240 seconds)
06:21:09moduledgeGotcha. I also see why Elegant Beef suggested using processes earlier. Thank you both.
06:21:11*dadada_ joined #nim
06:25:22*Hideki_ joined #nim
06:27:11moduledgeleorize: quick question, for communicating with the Xserver, could I use the net module?
06:28:57leorizeit does support unix sockets, so yes
06:29:01leorizeg'luck though
06:29:23leorizeeveryone do it via X libraries nowadays
06:29:39moduledgeoh yeah, xlib and xcb exist... I'm dumb
06:30:13moduledgeThanks again. I got a project now :)
06:30:26leorizeyou're welcome :)
06:31:28*hax-scramper quit (Ping timeout: 255 seconds)
06:34:32*narimiran joined #nim
06:35:18*dadada_ quit (Ping timeout: 258 seconds)
06:36:14*dadada_ joined #nim
06:45:26narimiranthe results of nim survey were posted on HN: https://news.ycombinator.com/item?id=22399416 - feel free to share your experiences there and/or answer some of the comments
06:47:42*hax-scramper joined #nim
06:50:11*dadada_ quit (Ping timeout: 260 seconds)
06:51:14*dadada_ joined #nim
06:58:07leorizedisruptek: so I cave in and decided to switch to the bundled nim installation approach (same as the windows version), and nimph is finally building without any patches whatsoever
07:01:52*LER0ever quit (Remote host closed the connection)
07:05:07*dadada_ quit (Ping timeout: 260 seconds)
07:06:07*dadada joined #nim
07:06:10*LER0ever joined #nim
07:06:32*dadada is now known as Guest88100
07:08:24leorizedisruptek: I can't even have jester as a dep with nimph
07:09:09leorizeso yea, that's gonna be my deal breaker in adopting nimph
07:12:40FromDiscord_<Rika> The blackrock dude has an interesting point
07:13:40livcdWhich one?
07:13:43leorizewe have a bunch of libraries for this
07:13:46leorize!repo cligen
07:13:47disbothttps://github.com/c-blake/cligen -- 9cligen: 11Nim library to infer/generate command-line-interfaces 15 157⭐ 11🍴 7& 1 more...
07:13:54leorize!repo argparse
07:13:54*Hideki_ quit (Remote host closed the connection)
07:13:55disbothttps://github.com/iffy/nim-argparse -- 9nim-argparse: 11Argument parsing for Nim 15 31⭐ 3🍴 7& 1 more...
07:14:15leorizeI found them to have fairly decent user experience
07:14:38*Hideki_ joined #nim
07:16:20FromDiscord_<Rika> I mean the compile to c one I think
07:17:19leorizeI still don't see why compiling to C is a problem...
07:17:23FromDiscord_<Rika> Though I like the idea of "why not both" rather than "let's just use asm and extend to c"
07:17:34FromDiscord_<Rika> Hmm
07:17:39leorizeasm is hell to produce
07:17:42FromDiscord_<Rika> Now that you mentioned it
07:17:55FromDiscord_<Rika> No clue what asm production would change vs c production
07:18:18leorizethe only problem we have with C is that we can't encode custom debugging data
07:18:32leorizethat's the gap where llvm can fill in
07:18:50FromDiscord_<Rika> Custom debug data for stuff like gdb or so?
07:18:55leorizeyea
07:19:07*Hideki_ quit (Ping timeout: 260 seconds)
07:19:49*neceve joined #nim
07:19:52leorizelanguage wise, producing C or asm or llvm or whatever doesn't make any difference
07:20:07*Guest88100 quit (Ping timeout: 272 seconds)
07:20:49leorizeI can never understand the "it generates C so it has all the evil in C"
07:21:08*dadada_ joined #nim
07:22:00FromDiscord_<Rika> How would I debug a program that shows a "stopped responding" on control c but not on exception
07:22:28FromDiscord_<Elegant Beef> transpiling scares people, atleast from the people i've talked to, they'd prefer it to go straight to asm
07:22:36leorize@Rika: your debugger would be able to attach to and stop the program, no?
07:23:09FromDiscord_<Rika> ~~I'm not using one, got used to not using one from python~~
07:23:13FromDiscord_<Rika> I'll use one then
07:23:50leorizenim-gdb is a nice plugin for gdb, included with your nim distribution :)
07:24:05Tangeripdb from python sure does spoil you, haha
07:24:08FromDiscord_<Rika> It's windows though
07:24:22leorizewho said you can't have gdb on windows :)
07:24:24FromDiscord_<Rika> I don't know if there's gdb
07:24:45FromDiscord_<Rika> Mm, mingw has one
07:25:01leorizethere's even a video tutorial for using gdb with vscode on windows for debugging Nim
07:25:34leorize@Elegant Beef: tell them that it compiles to LLVM IR if you pass the right flags :)
07:25:58leorizeand that it does so by default on osx :p
07:26:38FromDiscord_<Elegant Beef> yea but who develops on mac
07:26:46*Hideki_ joined #nim
07:26:55leorize4raq, dom
07:27:24FromDiscord_<Elegant Beef> jokes
07:28:03*Hideki_ quit (Remote host closed the connection)
07:28:39FromDiscord_<Elegant Beef> Yea i was joking, but yea my big thing is i dont do development outside of a game engine pretty much ever, so i lack a compelling usage
07:28:47*Hideki_ joined #nim
07:29:00leorizeuse it for everything :D
07:29:28FromDiscord_<Elegant Beef> Well I plan on using it for everything outside of unity
07:29:38FromDiscord_<Elegant Beef> but i dont do development outside of unity much
07:31:31FromDiscord_<Elegant Beef> so unless someone gets a nim to C# converter, I wont use nim much 😄
07:31:44*Hideki_ quit (Remote host closed the connection)
07:31:45leorizeI'm pretty sure unity can do js
07:31:51FromDiscord_<Elegant Beef> nope
07:32:01*Hideki_ joined #nim
07:32:13FromDiscord_<Elegant Beef> Not anymore, it's been unsupported for a while now
07:32:19FromDiscord_<Elegant Beef> Think it finally got removed
07:32:28leorizesad then :p
07:32:28FromDiscord_<Elegant Beef> It also wasnt pure js it was a custom version
07:32:57FromDiscord_<Elegant Beef> like it had strong type in it so it'd be `var type : name` iirc
07:33:16*Hideki_ quit (Remote host closed the connection)
07:34:17*Hideki_ joined #nim
07:34:55*dadada_ quit (Ping timeout: 255 seconds)
07:36:12*dadada_ joined #nim
07:36:15FromDiscord_<Rika> LMAO
07:37:00*Hideki_ quit (Remote host closed the connection)
07:37:15*Hideki_ joined #nim
07:40:43FromDiscord_<Rika> Is it easy to debug async with nimgdb and gdb
07:40:54leorizeit's never easy to debug async, sadly
07:46:27FromDiscord_<Rika> *screams*
07:46:58FromDiscord_<Elegant Beef> just dont async
07:46:59FromDiscord_<Elegant Beef> Duh
07:47:51*marmotini_ joined #nim
07:50:18*dadada_ quit (Ping timeout: 265 seconds)
07:51:11*dadada_ joined #nim
07:53:39*dadada_ quit (Read error: Connection reset by peer)
07:54:49FromGitter<alehander92> hmm
07:54:59FromGitter<alehander92> do you want async next/step ? rika
07:56:10*dadada joined #nim
07:56:35*dadada is now known as Guest30196
08:00:00*gmpreussner quit (Quit: kthxbye)
08:00:46*azed joined #nim
08:04:57*gmpreussner joined #nim
08:05:00*Guest30196 quit (Ping timeout: 258 seconds)
08:06:15*dadada_ joined #nim
08:10:23*LER0ever quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:10:56*LER0ever joined #nim
08:13:23*azed quit (Quit: WeeChat 2.7)
08:16:15*Hideki_ quit (Remote host closed the connection)
08:17:05*Hideki_ joined #nim
08:19:22Zevvoi, Nim on HN frontpage again \o/
08:19:38*dadada_ quit (Ping timeout: 240 seconds)
08:21:13*dadada_ joined #nim
08:21:22*letto joined #nim
08:21:24*Hideki_ quit (Ping timeout: 252 seconds)
08:22:40vegaikinda seminegative :/
08:22:49*letto_ quit (Ping timeout: 272 seconds)
08:29:30FromDiscord_<Rika> Alehander92 i just wanna know what the hell is causing my program to hang on Ctrl c
08:31:09FromGitter<alehander92> well, you can still run it under a debugger : if it blocks/hangs it shouldn't be hard to see where maybe
08:33:09FromDiscord_<Rika> Hang as in the "program has stopped responding" kinda hang
08:33:16FromGitter<alehander92> if you use linux, you can record your run under https://github.com/mozilla/rr/ and rerun it with gdb interface which might make it easier to catch ctrl+c kind of stuff
08:33:47FromGitter<alehander92> well, exactly: sometimes that means it's looping somewhere/waiting for something else idle-y
08:34:46*dadada_ quit (Ping timeout: 240 seconds)
08:36:07*dadada_ joined #nim
08:36:22FromDiscord_<Rika> It's on windows
08:41:31*solitudesf joined #nim
08:46:24*hax-scramper quit (Ping timeout: 258 seconds)
08:47:00*hax-scramper joined #nim
08:50:04*dadada_ quit (Ping timeout: 255 seconds)
08:50:15*clemens3 joined #nim
08:51:08*dadada_ joined #nim
08:55:43clemens3nim seems to not rely on a nim compiler, unlike go and crystal.. so i am giving it a try!! wish me luck:)
08:56:13FromDiscord_<Rika> clemens3, what do you mean?
08:56:18clemens3.. or rust..
08:56:57clemens3maybe i am wrong.. but the first thing the crystal home page tells you, if you want to compile that language yourself, you need a binary crystal compiler
08:57:06clemens3rustc btw the same..
08:57:08FromDiscord_<Rika> huh? nim uses a compiler
08:57:20clemens3FromDiscord_: gcc or nim?
08:57:21*Hideki_ joined #nim
08:57:35FromDiscord_<Rika> nim compiles to c then uses gcc to compile that to a binary
08:57:51clemens3i mean to compile the nim compiler itself?
08:58:01FromDiscord_<Rika> ah
08:58:04clemens3I want to try out nim and first compile nim from source..
08:58:04FromDiscord_<Rika> koch
08:58:09FromDiscord_<Rika> dunno what that uses though
08:58:20clemens3so far my assumption is gcc..
08:58:21FromDiscord_<Rika> but afaik it doesnt depend on itself?
08:58:33*LER0ever quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:58:38clemens3yes, which is a big plus!!!
08:58:53clemens3even java now needs a preinstalled java..
08:58:57FromDiscord_<Elegant Beef> doesnt choosenim compile from source?
08:59:08FromDiscord_<Rika> it does for linux
08:59:09clemens3earlier java versions not
08:59:12FromDiscord_<Rika> not windows i dont think so
08:59:14FromDiscord_<Elegant Beef> ah
08:59:23clemens3ah, windows doesnt count
08:59:29FromDiscord_<Elegant Beef> I recall seeing C stuff so i assumed it did
08:59:31FromDiscord_<Rika> haha, of course not
09:05:03*dadada_ quit (Ping timeout: 260 seconds)
09:06:12*dadada joined #nim
09:06:36*dadada is now known as Guest41247
09:15:09*Hideki_ quit (Ping timeout: 258 seconds)
09:17:46FromGitter<Varriount> Nim was first bootstrapped using Pascal
09:18:46FromGitter<Varriount> Now, technically, you could have the compiler run on Node (if enough low-level stuff was fixed)
09:19:46*Guest41247 quit (Ping timeout: 255 seconds)
09:21:12*dadada_ joined #nim
09:21:16FromGitter<alehander92> clemens3 yes i think you should be able to use only gcc
09:21:24FromGitter<alehander92> if you build a version from csources
09:21:53FromGitter<alehander92> but for non-prebuild c sources generally you need a nim compiler
09:22:17FromGitter<alehander92> but i still think its easier than llvm
09:22:37FromGitter<alehander92> on the other hand llvm has other +es , so its a trade-off as usual probably
09:27:16*floppydh joined #nim
09:36:03*zahary joined #nim
09:38:02FromGitter<alehander92> i want to defend a bit the nilable types from the survey, i think "nilability compile time checking" is a better name, as its an important class of bugs to be catched: having non-nilable types might be just a small part of such a feature
09:38:56FromGitter<alehander92> but i also like incremental compilation a lot, cant wait to see it
09:39:16FromGitter<alehander92> is it currently functional for small examples?
09:39:44FromDiscord_<Elegant Beef> yes i understand what you're saying completely
09:40:09FromDiscord_<Rika> are you being sarcastic
09:40:12FromDiscord_<Rika> cant tell
09:40:26FromDiscord_<Elegant Beef> Me? Im being serious right now
09:40:50FromDiscord_<Rika> sorry its really hard to tell online
09:41:03FromDiscord_<Elegant Beef> yea i know poes law and all
09:42:06FromDiscord_<Elegant Beef> Now to be serious i was joking
09:42:50FromDiscord_<Elegant Beef> `nilability compile time checking` is all i dont get
09:43:01FromDiscord_<Elegant Beef> Unless we're talking about nullable data types
09:43:16FromDiscord_<Rika> that i dont get either
09:44:29FromDiscord_<Elegant Beef> glad im not alone
09:45:50FromDiscord_<Rika> oh i see what's making my program crash on ctrl+c
09:45:58FromDiscord_<Rika> can controlc hooks be closures?
09:46:19FromDiscord_<Elegant Beef> I mean ctrl+c is stop the current process in linux, so idk 😄
09:48:05FromGitter<Varriount> Rika: I think so
09:48:51FromDiscord_<Rika> when i use a variable from the outer scope it crashes tho, hmm
09:50:23FromGitter<Varriount> Can you post a link to the code?
09:50:58*Hideki_ joined #nim
09:51:12FromGitter<Varriount> Alas, I have not yet mastered the art of astral projection
09:51:17FromDiscord_<Rika> uh not exactly, it's a discordnim bot
09:51:39FromDiscord_<Rika> i think the "basic bot" example in the discordnim library exhibits the same issue
09:52:53FromDiscord_<Rika> https://github.com/Krognol/discordnim/blob/master/examples/basic_bot.nim here if you still need a link ofc
09:54:16lqdev[m]@Rika no, ^c hooks are not closures
09:57:46FromDiscord_<Rika> knew it, wonder how i should implement how krognol did with this then
09:59:49*rokups joined #nim
10:00:09FromGitter<alehander92> elegant beef sorry, i am talking about the segfaults from "a.b => ops a is nil" thing
10:00:32FromGitter<alehander92> with stuff like ref objects
10:01:15FromDiscord_<Elegant Beef> coming from C# it's pretty standard to do `a?.b()` or `if(a != nil)`
10:01:26FromDiscord_<Elegant Beef> so idk
10:01:39FromGitter<alehander92> exactly, and c# already has this
10:01:51FromGitter<alehander92> it can enforce that you need to if a != nil
10:02:48FromDiscord_<Elegant Beef> I dont know what "this" is
10:03:16FromDiscord_<Elegant Beef> Sorry
10:03:33FromGitter<alehander92> yeah, so c# can tell you
10:04:50FromGitter<alehander92> something like "hey friend, you can't dereference a with a.b here, because its possibly null"
10:05:00FromDiscord_<Elegant Beef> ah null reference exception
10:05:05FromGitter<alehander92> no!
10:05:10FromGitter<alehander92> the exception is on runtime
10:05:24FromGitter<alehander92> but the point is that the compiler can detect that this might happen earlier
10:05:30FromDiscord_<Elegant Beef> ah ok
10:05:37FromGitter<alehander92> so it can show this error on compile time
10:05:41FromDiscord_<Elegant Beef> so more intelligent hinting for possible null refs
10:05:46FromGitter<alehander92> yes
10:06:10FromGitter<alehander92> its a small thing, but useful
10:06:37FromDiscord_<Elegant Beef> Yea, but after using C# for so long it's second nature to ensure it's not null 😄
10:06:53*Hideki_ quit (Remote host closed the connection)
10:06:57AraqC# got not-null checking as well
10:07:08AraqI haven't used it, but on paper it looked good
10:07:30Araqand they have to tackle exactly the same problems as we do (arrays are hard etc)
10:07:36*Hideki_ joined #nim
10:09:46AraqOrmin is taking off, great stuff
10:10:02FromGitter<Varriount> Araq: What are your thoughts on using libbacktrace for faster stack traces?
10:10:24Araqin other words, it found an enthusiastic new contributor / core developer.
10:10:54AraqVarriount: we'll probably do it
10:11:17Araqin the past we had patches for this already, but it never worked as well as our own stack traces
10:11:27Araqstill it's nice to have a no-cost variant for -d:release
10:12:16*Hideki_ quit (Ping timeout: 258 seconds)
10:12:18FromGitter<Varriount> Any idea on what underlying mechanism it uses? I took a brief look at the source code, but didn't get too far
10:14:23*Hideki_ joined #nim
10:15:07Araqit uses the debug information and the current stack/frame pointer
10:15:23Araqbasically asm level stuff
10:15:30*Hideki_ quit (Remote host closed the connection)
10:16:30*Hideki_ joined #nim
10:20:51*Hideki_ quit (Ping timeout: 240 seconds)
10:22:27FromGitter<Varriount> Ah. Debug information to store instruction pointer->line info mapping data?
10:24:03*lritter joined #nim
10:24:37Araqwell it's not the instruction pointer, it's the stack pointer, but yah
10:31:47*zahary quit (Quit: Leaving.)
10:32:06*zahary joined #nim
10:32:36*zahary quit (Client Quit)
10:41:48*Romanson joined #nim
10:47:38*marmotini_ quit (Remote host closed the connection)
10:48:10*marmotini_ joined #nim
10:52:31*marmotini_ quit (Ping timeout: 258 seconds)
10:55:53*Hideki_ joined #nim
11:01:45lqdev[m]is a StringTableRef faster than a Table[string, string]?
11:13:49*Hideki_ quit (Ping timeout: 272 seconds)
11:15:37AraqI don't know, probably not
11:15:56Araqit mostly exists for case insensitive keys
11:28:14dadada_Araq: hey, at the risk of being annoying, because I mentioned it multiple times here already, https://totallywearingpants.com/posts/nim-language-highlights/ , this is written in just the right way for beginners or midly interested people, it definitely belongs into the learn page of the website. Under tutorials probably.
11:28:30dadada_s/midly/mildly
11:28:38*dadada_ is now known as dadada
11:28:39Araqdon't tell me, tell narimiran
11:29:01narimirandon't tell narimiran, make a PR
11:31:16Araqlol
11:33:30*zahary joined #nim
11:39:21*abm joined #nim
11:48:26FromDiscord_<exelotl> Would be nice to have some docs for ormin, right now I'm leaning towards Norm because it's a lot clearer how it works and where to start
11:48:53FromGitter<timotheecour> @Varriount ⏎ ⏎ > Araq: What are your thoughts on using libbacktrace for faster stack traces? ⏎ ⏎ we already have option for that since #12922; one benefit is allows zero cost stacktrace (with caveat of, with -d:release, not having frames for inlined procs, of course) [https://gitter.im/nim-lang/Nim?at=5e53b8251be0ff01d5a63061]
11:48:55disbothttps://github.com/nim-lang/Nim/pull/12922 -- 6generic stack trace overriding mechanism
12:17:26*zyklon quit (Ping timeout: 240 seconds)
12:21:42*uvegbot joined #nim
12:37:35*kungtotte quit (Read error: Connection reset by peer)
12:38:45*kungtotte joined #nim
12:50:16*Hideki_ joined #nim
13:15:06*fanta1 joined #nim
13:18:40FromDiscord_<mratsim> Note that it brought a 4x to 5x improvement on compilation and runtime: https://github.com/status-im/nim-beacon-chain/pull/745#issuecomment-588360225
13:18:41disbot➥ lightweight stack traces
13:26:32FromDiscord_<clyybber> disruptek: Oh your testutils part of status now?
13:31:42*marmotini_ joined #nim
13:35:14*nsf quit (Quit: WeeChat 2.7)
13:37:53stefantalpalaruThe nim-beacon-chain compilation is about 25% faster and the test suite runtime is more than 2 times faster, with nim-libbacktrace.
13:38:33stefantalpalaruDo note that we were already using --opt:speed, so we already had -O3 enabled in our debug builds.
13:39:11FromGitter<alehander92> huh, why the compilation speedup
13:40:10FromGitter<alehander92> was it all the nimfr_ ?
13:40:22stefantalpalaruI don't know exactly, but I do see two possible sources: extra code gets enabled by -d:debug and extra code gets inserted by the default stack trace mechanism, to keep track of frames.
13:40:48FromDiscord_<clyybber> Interesting
13:41:21*Romanson quit (Quit: Connection closed for inactivity)
13:42:00FromDiscord_<clyybber> Araq: Can we make define `[]` for openarrays as an alias for the toOpenArray slicing?
13:42:51Araqsomehow we should be able to do that
13:42:57Araqbut more importantly
13:43:13Araqcan we change evaluation order to 'right to left' for everything constistently?
13:43:26Araqdo we know cases where left-to-right works better?
13:44:01Araqbecause I don't, it's slightly more intuitive but that's all
13:44:51Araqright-to-left also tends to produce better asm code iirc
13:46:41*Hideki_ quit (Remote host closed the connection)
13:47:27*Hideki_ joined #nim
13:52:19*Hideki_ quit (Ping timeout: 265 seconds)
13:53:41dadadaAraq: does this imply syntax changes?
13:53:54Araqnope
13:54:19Araqit would be a change in the spec though
13:54:47dadadacould there be different evalutation results due to it?
13:54:52dadadaevaluation
13:54:55Araqyes
13:55:09Araqbut only edge cases are effected
13:55:18dadadaokay, well, I'd need some examples first to form an opinion
13:56:18dadadaor to really see how it would affect my reading of code
13:56:36*dddddd joined #nim
13:57:39SyrupThinkeriter is an interator returning 1.., subtract(iter(), iter()) would return -1 for ltr and 1 for rtl
13:57:55dadadaI asked yesterday, is there any possibility that a macro could be aware of the context its used in? a proc, a for loop, a for loop inside a proc, in the last line/statement/expression of a proc
13:57:57SyrupThinkerThats a minimal example if I understand correctly
14:00:07*Hideki_ joined #nim
14:01:30Araqyes, SyrupThinker is correct
14:01:39*tane joined #nim
14:02:05Araqdadada: no, by design a macro can only look at what was passed to it
14:02:17FromDiscord_<mratsim> that might break the new chain/with macro?
14:02:22Araqand it cannot go up in the parse tree
14:02:29FromDiscord_<mratsim> the order of evaluation
14:02:48Araqmratsim: well the order of evaluation is only in effect after macro translations etc
14:03:11Araqit's mostly '=' and runtime calls
14:03:22Araqthe macro system isn't affected
14:05:12dadadaAraq: what exactly are you trying to achieve here besides simplifying code and possibly optimizations
14:05:33Araqmake Zevv's convoluted code "Just work"
14:07:24dadadawhich code specifically?
14:07:50dadadasry, I'm not following this closely enough perhaps
14:11:12FromDiscord_<mratsim> was there an article about Arraymancer? I got like +30 stars in 6 hours
14:11:13dadadaAraq: it wouldn't change anything about these chained function calls being called ltr, though? https://play.nim-lang.org/#ix=2czh
14:13:14*Hideki_ quit (Remote host closed the connection)
14:13:55*Hideki_ joined #nim
14:15:19Araqdadada, no, that's the "inside out" rule
14:15:30Araqor "innermost call gets evaluated first"
14:15:38Araqit's not affected
14:16:34Araqanyhow Zevv's code is tab[key].id = grows(tab)
14:16:47FromGitter<Vindaar> @dadada: LPT: if Araq talks about some new feature / optimization etc. and you wonder how it affects you from a user perspective, the answer is almost certainly "don't worry" ;)
14:17:08Araqwhich causes a memory safety bug with Nim's left-to-right evaluation rules
14:17:11zedeus@mratsim it's mentioned in the top comment here https://news.ycombinator.com/item?id=22399416
14:18:45*Hideki_ quit (Ping timeout: 272 seconds)
14:22:00FromDiscord_<clyybber> Araq: I think LTR is the way to go generally
14:22:13FromDiscord_<clyybber> But sink should be evaluated first
14:23:17*Hideki_ joined #nim
14:23:44Araqnot "last"?
14:23:55Araqyou want it to be the last read if possible, no?
14:24:26FromDiscord_<clyybber> Hmm, but sink parameters are going to be stored /somewhere/
14:24:28FromDiscord_<clyybber> most of the time
14:24:51FromDiscord_<clyybber> so we evaluate them before all others so that the thing that they are gonna be stored in is evaluated later
14:25:05FromDiscord_<clyybber> so that we can modify s in s.add b() in b
14:25:17FromDiscord_<clyybber> without breaking stuff
14:26:57FromDiscord_<clyybber> it may be a bit untransparent for the user though, since sink can also be injected automatically
14:27:18FromDiscord_<clyybber> but this is the best idea I have come up with so far
14:28:05*Hideki_ quit (Ping timeout: 265 seconds)
14:30:08Araqtoo much magic, right-to-left works for 'add' anyway
14:30:19dadadaAraq: you made it sound like you want to make everything rtl, but there's just so much based around the paradigm of reading, for example statement 1; statement 2; would you want statement 2 to be evaluated first? I'm sure this is again something like the inside-out rule, but you made it sound like RTL would be better for everything... LTR is much less intuitive, although I definitely see why it's attractive
14:30:25dadadain the case of Zevv's code. Maybe there could just be a rule around assignments that their lhs is evaluated last? ...
14:31:12Araqyeah but then assignments would be special
14:31:31dadadathey are already!? :-)
14:31:37Araqyet the evaluation rules would work better for sequence.add too
14:31:37FromDiscord_<clyybber> I'm not sure we even need rtl for add too
14:31:45FromDiscord_<clyybber> dadada: No
14:32:10FromDiscord_<clyybber> Araq: Maybe special casing `=` suffices, as `=` is used in add itself
14:32:31dadadaclyybber: what were you noing?
14:32:42FromDiscord_<clyybber> that assignments are already special
14:33:09FromDiscord_<mratsim> even if you mention that Nim is evaluated right to left, a paragraph that says "this also applies to assignments" would be needed
14:33:48dadadaclyybber: only because we discussed them this week already, the whole they're not real equations debate
14:34:04FromDiscord_<clyybber> k
14:35:06Araqmratsim: but 'a = b' is turned into `=`(a, b) for custom assignment operators
14:35:21Araqso any inconsistency around assignments would be quite bad
14:35:33FromDiscord_<mratsim> so once again the solution is {.rightToLeft.} pragma 😉
14:35:35Zevvhm it's not about assignments, is it? It is about anything that will change any state
14:35:37Araqthe fact that I still have one more sentence in the spec is not relevant
14:36:20Araqwell I keep looking for advantages for left-to-right, so far I found none
14:37:17Araqevery codegen-like pass needs to special case nnkCallKinds with a 'countdown' traversal
14:37:29Araqthat's quite a downside
14:38:35FromDiscord_<clyybber> advantage for left to right is that its more in line with what you expect
14:38:36FromDiscord_<clyybber> normally
14:38:59FromDiscord_<mratsim> I read left to right
14:39:03dadadame too
14:39:25dadadabut I see Zevv's need, as well
14:39:26FromDiscord_<mratsim> I prefer foo().bar().baz() instead of baz(bar(foo()))
14:39:31Araqit's a pretty weak argument, normally the order is irrelevant and depending on it is bad, subtle code
14:39:31FromDiscord_<clyybber> hmm
14:39:57FromDiscord_<clyybber> maybe we should add a rule that expressions with a side effect are evaluated in a first pass
14:39:58Araqbefore v1 in Nim it was unspecified, few noticed
14:40:06FromDiscord_<clyybber> and then those with no side effects
14:40:22FromDiscord_<clyybber> it shouldn't change behaviour much
14:40:23FromDiscord_<mratsim> but you can lie about side-effects
14:40:25Araqmratsim: again, the wrong example
14:40:27FromDiscord_<clyybber> but it should solve the problem
14:40:46Zevvcan this case be detected and yield a compile time error?
14:40:51Araqthe example is f(a, b) # b before a or a before b
14:41:19FromDiscord_<mratsim> yes I know, but my example is related to reading/writing left to right
14:41:27FromDiscord_<clyybber> @mratsim once you start lying about sideeffects you are on your own
14:41:28FromDiscord_<mratsim> not about an example where the order is actually significant
14:41:44AraqZevv, yeah and we'll do that but then your code needs an explicit temporary to make the compiler happy
14:41:57Zevvfair enough
14:42:07Araqbut I suppose it's the best solution, the compiler then enforces a more readable version
14:42:09FromDiscord_<mratsim> if you wrap a C library and forgot to add {.sideeffect.} you are most likely lying about sideeffect
14:42:20dadadaf( makeDir(), makeFileInDir() ) # works with ltr (because the dir exists), doesn't work with rtl becaue the file-in-dir is created at a time where the dir wasn't created yet, hopefully I understood the whole topic correctly, admittedly I constructed this example, but I think this goes against a lot of expectations
14:42:37Araqdadada, that nails it
14:42:51FromDiscord_<clyybber> @mratsim Yes but the idea here was that it doesn't matter. Everything be evaluated LTR just the expressions with a sideeffect first
14:42:55FromDiscord_<clyybber> Araq: WDYT?
14:43:17Araqclyybber: too complex, will only bite you a bit later
14:43:25FromDiscord_<mratsim> yes agree, too complex
14:44:00FromDiscord_<clyybber> But it *cant* bite you
14:44:11FromDiscord_<clyybber> since those noSideEffect procs don't rely on the order
14:44:13FromDiscord_<mratsim> it's similar to choosing copy sematics vs reference semantics vs copy-on-write. It's easier for people to know what to expect with either of the first 2, rather than the last one
14:44:14Araqha :-)
14:44:37FromDiscord_<clyybber> And the sideffect once will still be evaluated LTR
14:44:41Araqmratsim: I still like COW fwiw
14:44:46FromDiscord_<clyybber> same as the noSideEffect ones
14:45:16Araq"the evaluation order depends on the side effect system"
14:45:30Araqis not something I want to ever see in the spec
14:45:31FromDiscord_<clyybber> It doesn't even need to be documented
14:45:44FromDiscord_<clyybber> since it doesn't change the behaviour for the user
14:46:01FromDiscord_<clyybber> except for allowing this usage
14:46:35Araqsorry but you won't convince me on that
14:47:28FromDiscord_<clyybber> Araq: But only expressions with a sideeffect rely on the order? Are you with me on that?
14:47:36Araqand in Zevv's example the RHS doesn't have sideEffects either
14:47:59Araqno, I'm not with you on that
14:48:07Araqit's not about side effects
14:48:09FromDiscord_<clyybber> huh
14:48:18FromDiscord_<clyybber> but return123 does have a sideeffect?
14:48:35FromDiscord_<clyybber> it modifies table[l] ?
14:48:41dadadait's the other way around actually... proc/funcs rely on what happened BEFORE they were called
14:49:11dadadaf( makeDir(), makeFileInDir() ) <- here I would never expect makeFileInDir() to be the first one that is called
14:49:47FromDiscord_<clyybber> dadada: Yes, but you won't notice unless makeDir and makeFileInDir are procs with a sideeffect
14:49:50FromDiscord_<clyybber> that was my point
14:50:56*drewr quit (Quit: ERC (IRC client for Emacs 26.3))
14:51:11FromDiscord_<clyybber> Araq: Am I wrong about return123 having a sideeffect?
14:51:45FromDiscord_<clyybber> I thought modifiying an "upvalue" counts as sideeffect
14:51:53Araqwell it doesn't touch a global
14:52:06Araqso according to Nim it doesn't have a "side effect"
14:52:21FromDiscord_<clyybber> Oh
14:52:33Araqit's a tough nut :P
14:52:41FromDiscord_<clyybber> We almost cracked it
14:52:48*couven92 joined #nim
14:52:57FromDiscord_<clyybber> we just gotta introduce a stricter side effect
14:53:03FromDiscord_<clyybber> that is used to crack this nut
14:53:33FromDiscord_<clyybber> which is like sideeffect but also tracks *every* access to upvalues
14:53:43FromDiscord_<clyybber> and then we have enough information to solve this
14:54:56Araqyes but now you're thinking about how to detect and prevent it at compile-time. changing the eval order is about "making it work"
14:55:21FromDiscord_<clyybber> yeah, but we can change the eval order behind the back
14:55:39FromDiscord_<clyybber> since table[0].id doesnt have a sideeffect
14:55:46FromDiscord_<clyybber> but return123() does
14:55:53FromDiscord_<clyybber> (with the extended notion of sideeffect)
14:55:59FromDiscord_<clyybber> we would evaluate return123()
14:56:01FromDiscord_<clyybber> firts
14:56:08FromDiscord_<clyybber> first and then table[0].id
14:56:13FromDiscord_<clyybber> so the problem would be solved
14:56:57Araqnode.add node[^1]
14:57:00FromDiscord_<clyybber> problem is this falls apart when table[0].id does have a sideeffect. But we should make it error in that case via borrow checker rules
14:57:11*Hideki_ joined #nim
14:57:13FromDiscord_<clyybber> Araq: No sideeffects here?
14:57:18FromDiscord_<clyybber> so normal LTR
14:57:31Araqit's broken under LTR
14:57:50FromDiscord_<clyybber> huh? It just duplicates the last element
14:57:53FromDiscord_<clyybber> doesn't it?
14:58:15Araqhmm I got the example wrong, one sec
15:00:12Araqbut it was close to 'node.add node'
15:00:21Araqso 'node' is the last read, we nil it out
15:00:26Araqand then 'add' crashes
15:00:37FromDiscord_<clyybber> huh?
15:00:44FromDiscord_<clyybber> but node is not the last read
15:00:50FromDiscord_<clyybber> node[^1] is
15:00:59Araqbut it was close to 'node.add node'
15:01:09Araqforget the indexing
15:01:35FromDiscord_<clyybber> but even node.add node is not broken
15:02:00FromDiscord_<clyybber> it simply duplicates node's elements
15:02:03Araqwell I had a failing test case about it
15:02:11FromDiscord_<clyybber> we fixed it I think
15:02:15FromDiscord_<clyybber> it was an dfa issue
15:02:32FromDiscord_<clyybber> i think *you* fixed it
15:02:51AraqI think I haven't
15:03:16Araqbut the point is that it's about "disjoint" graphs, not about "side effects"
15:03:44dadadaAraq: newGuiLayout(newSpacer(), newBox("#id23"), newText("#id23", "Some Text inside the formerly created with #id23"), newSpacer()) ... in this example the GUI elements are connected over a object system (for example QObject or gobject introspection, or could be something like a dom) ... the text would expect the box with the right id to be there due to LTR ... yes, I'm definitely reaching a little, but I
15:03:50dadadathink I've seen or created code like this before, it's not totally outlandish
15:04:29Araqif g() and h() operate on disjoint data *or* only read from the data then the evaluation order doesn't matter in f(g(), h())
15:04:47FromDiscord_<clyybber> Araq: Yeah, thats what I was on to. sideeffects are maybe a bit too "course"
15:04:52FromDiscord_<clyybber> coarse
15:05:15Araqbasically ParaSail's rules
15:05:34Araqwhich then runs g() and h() in parallel
15:06:47FromDiscord_<clyybber> So we need to implement write tracking right?
15:08:01Araqnah, you only need some borrow checker that complains about .closure calls
15:08:14Araqassuming that .closures are from hell and mess with your state
15:08:41FromDiscord_<clyybber> Araq: Ok, but I thought we wanted Zevvs example to just work (TM)?
15:09:51Araqonly if we want to pay the price for RTL evaluations everywhere. Else detecting it is good enough.
15:09:59*Hideki_ quit (Ping timeout: 260 seconds)
15:16:41FromDiscord_<clyybber> Hmm, ok.
15:17:13FromDiscord_<clyybber> I agree now, have found a few examples where my idea woudn't really work out
15:18:57FromDiscord_<clyybber> Araq: For detecting it we still have to do track what reads/writes what though. Unless you want to forbid all closure calls in args :p
15:20:16Zevvis this problem in any way unique to Nim?
15:26:33dadadaok, I've this totally different idea, that probably nobody will like, but here it is, create a special keyword/macro/function for when you want somthing to be absolutely evaluated before everything else, ie. I suppose Zevv wants the grow funtion to be evaluated first so prepone(grows(tab)), there could also be the opposite postpone(grows(tab)) that would ensure the grows procedure is the last one evaluated...
15:26:39dadadathis would allow programmers to manually define execution order (hopefully needed sparsely) and it would matter lesser weather everything else is LTR or RTL ... although this of course complicates the compiler as well
15:27:11dadadas/matter lesser/matter less
15:27:13dadadawether
15:27:37dadadawhether ^^
15:28:51FromDiscord_<mratsim> as long as people don't say "I have 2 calls with prio/precedence/prepone but one should be evaluated even before the other" 😉
15:30:55dadadamratsim: the assumption is that this would be an absolute edge case worth splitting code into more lines
15:37:44*Kaivo quit (Quit: kernel update)
15:39:30FromDiscord_<mratsim> yes for sure
15:39:38*Kaivo joined #nim
15:39:40FromGitter<rishavs> How should I forward declare a proc in one module and define it in another? Currently doing so is throwing this error; ⏎ `implementation of 'data.mainScene_init() [declared in c:\Users\risharan\Documents\GitHub\rayni\src\data.nim(13, 6)]' expected`
15:44:18FromGitter<alehander92> with include maybe
15:44:24FromGitter<alehander92> but otherwise i dont think its supported
15:46:14*ptdel joined #nim
15:46:51*ptdel quit (Remote host closed the connection)
15:46:53FromGitter<rishavs> thats a good idea. Structuring my code in Nim is harder than I expected
15:48:00Araqwell if you have a dependency tree, it works out
15:48:43Araqif you don't, Nim doesn't really help you out. in this case curse me personally for it and pretend your deps are "really not cyclic" (even though they are)
15:49:14*ptdel joined #nim
15:49:34FromGitter<rishavs> my trees always end up being circular :( ⏎ Though this is because I am not very knowledgeable about coding.
15:49:55Araqdon't worry, here is one workaround:
15:49:56FromGitter<alehander92> i think its a simple/good decision , i imagine it helps with stuff like IC
15:50:20Araqvar theProc: proc () {.nimcall.} # to be set by the implementor
15:51:01Araqit's a fake dynamic call, the Nim compiler internally does the same in a couple of places
15:51:23Araqit's a hacky workaround, but it does work
15:51:32FromGitter<rishavs> Thanks. gonna give it a try :D
15:56:03*jxy quit (Quit: leaving)
15:56:12FromGitter<Varriount> Araq: Aside from changing the spec and consistency, is there any particular problem with changing only `=` operators to evaluate left-to-right?
15:56:49*nsf joined #nim
15:57:11FromGitter<Varriount> Do other languages special-case this?
15:59:22Araqsome do, some don't
16:06:01disruptekwhat's shakin', nimions?
16:07:42*marmotini_ quit (Remote host closed the connection)
16:08:14*marmotini_ joined #nim
16:08:29ZevvTrying to assign something to something else
16:11:39*natrys joined #nim
16:11:55disruptekuh oh.
16:13:13ZevvmyTable[key] = somethingThatMakesMyTableGrow()
16:14:42lqdev[m]how can I get the directory where my app can store data, eg. `C:\Users\user\AppData` on Windows and `~/.local/share` on Linux? is there a builtin for that, or do I have to implement it myself?
16:14:51*marmotini_ quit (Ping timeout: 240 seconds)
16:15:54Araqos.getConfigDir
16:16:21lqdev[m]that's for `~/.config` on Linux, I need `~/.local/share
16:17:05disruptekZevv: why did you have to write that?
16:17:13disruptekhow very inconsiderate of your.
16:17:15Araqwell we don't have it then but ~ is so full of junk in reality that you might as well use it
16:17:15disruptekyou, too.
16:17:28lqdev[m]basically I need a place where I can store plugins and various user data.
16:17:36lqdev[m]so I suppose `~/.myapp` would do?
16:17:50disruptekplease no.
16:17:57dadadalqdev[m]: better to use .config/myapp than .myapp
16:18:20lqdev[m]dadada: but I need a folder for user projects, not configuration
16:18:37Araq ~/.local/share/app makes sense
16:18:50disruptek^
16:18:54lqdev[m]I'll roll with my own proc, then
16:19:02Araqit seems to suit the rest of the setup, everything is stored in a most annoying location
16:19:07dadadalqdev[m]: chrome and other applications store loads of data their anyway, ... nothing is worse than using $HOME/.foobar directly ... either use XDG_DATA_DIR from the environment, or simply when linux .local/share/myapp
16:19:11disruptekwould be nice to pr it, as we need this for nimterop shared-libs, too.
16:19:27dadadas/their/there
16:19:46disrupteki guess today we parallelize testutils.
16:19:52lqdev[m]dadada: right, I'll go with that
16:20:06dadadadisruptek: nimble needs to move away from $HOME/.nimble as well
16:20:16disrupteki'm not the guy to talk to about that.
16:22:12FromDiscord_<clyybber> lqdev[m]: For user projects let the user decide
16:22:17Zevvdisruptek: I never wrote that. I just created the issue for someone else who came on #nim asking why this funny thing was happening
16:22:21FromDiscord_<clyybber> I mean you are gonna have a dialog anyways
16:22:40disruptekZevv: don't try to deny it. no one codes of behalf of "a friend."
16:22:42FromDiscord_<clyybber> disruptek: Hey, did you move your repo to status?
16:22:57disruptekyeah, it was status code that i pulled out of chonicles.
16:23:04Araqwhat's wrong with $HOME/.app? it's the standard, $HOME is not for you, $HOME is for apps, for yourself you can use $HOME/projects and never look inside $HOME. It's what I do on every OS.
16:23:59taneAraq, free desktop, XDG_HOME.. etc, use .local/share, .cache and .config
16:23:59disruptek$HOME is not for me?
16:24:01solitudesf$HOME is for me
16:24:10FromDiscord_<clyybber> letting the user decide is just best
16:24:23FromDiscord_<clyybber> its also what most other daws do
16:24:24Araqtane, theory vs practice
16:24:39Araqin practice $HOME is full of .dotjunk
16:24:53taneand this legitimates doing the same?
16:25:04Araqyeah as it's beyond repair.
16:25:12FromGitter<alehander92> lqdev[m]: $XDG_DATA_HOME i think
16:25:19solitudesfanalogy for windows would be apps creating folder on desktop or root of C:
16:25:29taneocaml 4.10's breaking change is moving .ocamlinit to .config, so people are actually tryin to salvage :)
16:25:32disruptekaraq was making sense and then he took a puff.
16:25:43Araqexactly, C: is not for you, it's never clean, don't look inside
16:25:44FromDiscord_<clyybber> Na na na na na, don't use any XDG stuff, just let me decide where I want to save or load a project from
16:25:47FromGitter<alehander92> but the point was to not put stuff in $HOME if you dont want it
16:26:17FromGitter<alehander92> and XDG lets you decide that indeed
16:26:31FromDiscord_<clyybber> alehander92: This is about projects though
16:26:33FromDiscord_<clyybber> like one song
16:26:39FromDiscord_<clyybber> not about global configs
16:26:51FromDiscord_<clyybber> for which XDG_CONFIG_HOME should be used, I agree
16:26:59FromDiscord_<clyybber> and also not about global data
16:27:30FromGitter<alehander92> hm, i see
16:27:38dadadalqdev[m]: there are configs in .local/share and data in .config/ there's really no consistency... you could as well use os.getConfigDir ... although the spec is pretty clear https://www.freedesktop.org/software/systemd/man/file-hierarchy.html
16:27:53FromDiscord_<clyybber> use .config
16:28:05FromDiscord_<clyybber> for configuration
16:28:28FromGitter<alehander92> which reminds me i should also use XDG for some stuff
16:28:40AraqXDG doesn't care for the poor souls like me who would never use dots though
16:28:51FromDiscord_<clyybber> never use dots?
16:29:01Araqor maybe it does hmmm
16:29:18ZevvAraq is the hardcore explicity kind of guy. His .vimrc is just called vimrc.
16:29:19FromDiscord_<clyybber> Araq: You can just set your XDG_CONFIG_HOME to $HOME/config if you like
16:29:30FromDiscord_<clyybber> noones stopping you
16:29:40disruptekduh.
16:29:41FromDiscord_<clyybber> other than for stupid programs that hardcode .config
16:29:54FromGitter<alehander92> thank you
16:30:18disruptekhttps://www.twitch.tv/disruptek
16:30:20Araqclyybber: yeah, I misread, it works
16:31:08Araqok I'm sold, XDG works
16:31:26FromGitter<alehander92> yeah i was hardcoding it, time to fix it at least somewhere
16:31:55Araqstill puzzling we need a flat key-value store to handle the mess the "hierarchy" got us into
16:32:04Araqbut whatever, back to work
16:47:05*marmotini_ joined #nim
16:47:39*jxy joined #nim
16:50:28*solitudesf quit (Remote host closed the connection)
16:53:03*Trustable joined #nim
16:56:21WilhelmVonWeiner"we need"
16:56:44WilhelmVonWeinerneed is a strong word
16:58:28lqdev[m]could anyone help me with the `dynlib` module? I have a C library (https://github.com/liquid600pgm/nadio/blob/master/plugins/test/main.c), passing it through `nm` yields all symbols including `nadPluginGetName` etc. however, when I `loadLib` the .so, and use `symAddr` to retrieve `nadGetPluginName` from the .so (https://github.com/liquid600pgm/nadio/blob/master/src/nadio/plugins.nim#L23), I get `nil`, with `dlerror` returning
16:58:28lqdev[m]the message `/home/daknus/Coding/Nim/nadio/src/nadio/nadio: undefined symbol: nadPluginGetName`.
16:58:30dadadais there an implementation of OOP class hierarchies for Nim that's considered best/farthest ahead compared to others?
16:58:52lqdev[m]`nadGetPluginName` is defined by the `NadioPluginMetadata` macro
17:06:41*Hideki_ joined #nim
17:10:51*Hideki_ quit (Ping timeout: 240 seconds)
17:22:18leorizedisruptek: I broke nimph...
17:22:58disruptekyou have twitch.
17:23:00disruptekyou can chat on stream.
17:23:02disrupteknow.
17:30:43*clemens3 quit (Ping timeout: 255 seconds)
17:35:00FromDiscord_<clyybber> with free latency
17:42:34*floppydh quit (Quit: WeeChat 2.7)
17:45:13*dadada quit (Ping timeout: 272 seconds)
17:51:18*dadada joined #nim
17:51:42*dadada is now known as Guest5151
17:52:55*shadowbane quit (Quit: Konversation terminated!)
17:54:19*shadowbane joined #nim
18:01:57*Guest5151 is now known as dadada
18:16:12*zahary1 joined #nim
18:19:29*rokups quit (Quit: Connection closed for inactivity)
18:21:17*moduledge quit (Quit: Konversation terminated!)
18:22:06FromGitter<deech> Is there any way to see a "dry run" of a nimble command? eg. I'd like to see a list of `nim` compilation commands when running `nimble install`.
18:22:25*NimBot joined #nim
18:22:45disruptekthere's an option to output the cmd-line in the compiler.
18:27:45FromGitter<rishavs> quick question, in my code I am using empty returns a lot. like this; ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ is this an ok design choice or should I try to return something anyway (like discardable bools?) [https://gitter.im/nim-lang/Nim?at=5e5415a19aeef6523216ea05]
18:28:13disruptekit's fine, but try to use `result` instead of `return`.
18:30:46shashlickWriting code with multiple returns is easier but then harder to follow later
18:31:11shashlickIdeally a single return at the bottom of the proc though it does make code harder to write
18:31:54FromGitter<rishavs> I am using return more as a break to get out of the recursive procs
18:33:22FromDiscord_<Recruit_main70007> What is that function returning?
18:34:02disruptekyou write it once, you read it many.
18:34:09disruptekit doesn't matter if it's hard to write.
18:34:13disruptekmake it easy to read.
18:34:52FromDiscord_<Recruit_main70007> Oh, I think I understand, so it’s like when you do
18:34:52FromDiscord_<Recruit_main70007> int main(){
18:34:52FromDiscord_<Recruit_main70007> }
18:34:53FromDiscord_<Recruit_main70007> void say_hi(){
18:34:53FromDiscord_<Recruit_main70007> }
18:35:23FromDiscord_<Recruit_main70007> I hope that’s not enough code to get it into a pastebin :p
18:36:55FromGitter<Varriount> Araq: For what it's worth, a surprising number of programs do support XDG environment variables
18:37:08leorizenot nimble
18:37:20FromGitter<Varriount> Gasp!
18:37:25FromGitter<rishavs> Thanks disruptek. Something to keep in mind
18:37:43FromGitter<Varriount> Leorize: This situation should be remedied
18:38:36leorizeyea, I need that to get nimble into haiku :P
18:38:47FromGitter<NOP0> Could anyone give me a link or short explanation what is gc:arc? I'm googling in vain 😀 thanks
18:38:56leorize~arc
18:38:56disbotarc: 11a new memory manager for Nim; see https://forum.nim-lang.org/t/5734
18:39:09ZevvNOP0: arc does reference counting instaed of garbage collection
18:39:20*couven92 quit (Read error: Connection reset by peer)
18:39:46*couven92 joined #nim
18:40:03FromGitter<Varriount> (though one might argue that reference counting is a form of garbage collection)
18:41:25FromDiscord_<clyybber> but deterministic
18:42:37FromGitter<NOP0> Thanks! How is this related to newruntime, and what is newruntime?
18:42:53leorizenewruntime is an old idea now
18:42:58leorizeit's no longer relevant :)
18:43:10FromDiscord_<clyybber> leorize: Eh
18:43:16leorizearc is the evolution from newruntime afaict
18:44:15*filcuc joined #nim
18:44:30FromDiscord_<clyybber> leorize: In a way yeah, but newruntime is more like a superset of arc. Its arc + owned
18:44:58FromDiscord_<clyybber> The ideas of newruntime are useful though
18:45:12FromDiscord_<clyybber> and will probably get incorporated into arc in some way
18:45:24FromDiscord_<clyybber> Especially useful for sending stuff across threads
18:46:24leorizeyea but the entire owned pointer idea kinda die off when benchmarks said it doesn't make any noticable difference from just arc
18:47:28FromGitter<NOP0> Ok, guess this is cutting edge, not anything to worry about for casual nim user I guess. Does gc arc mean anything for hard real time guarantees wrt gc?
18:47:54FromDiscord_<clyybber> Yeah
18:48:06leorizeI think it's in the plan, though hard real time is well... kinda hardcore :P
18:48:09FromDiscord_<clyybber> It is a hard realtime guarantee basically
18:48:14FromDiscord_<clyybber> I mean
18:48:22leorizesoft real time is a much better guarantee
18:48:23FromDiscord_<clyybber> its always either decRef
18:48:27FromDiscord_<clyybber> or destroy
18:50:07leorizenot entirely sure if that means you get hard real time
18:50:30Araqit does
18:50:51leorizeah ok
18:51:14Araqthere are plenty of myths around refcounting ;-)
18:51:39Araqbut I've yet to see a definition of "hard realtime" that rules out reference counting
18:51:45leorizeAraq: can you look at #13201?
18:51:46disbothttps://github.com/nim-lang/Nim/pull/13201 -- 3Make file descriptors from stdlib non-inheritable by default
18:51:51leorizeis there anything left to be done?
18:52:09FromGitter<NOP0> Thanks!
18:52:32Araqleorize, the setInheritable is a bit supoptimal as it means "omg another syscall"
18:52:41Araqcan we add flags to file/socket creation?
18:54:33leorizesocket creation already got a flag
18:54:42leorizefile creation then I'm not so sure
18:55:43leorizesince the inherited file will share the same exact file description: if you advance the file position in one process the other will have their file position changed too
18:56:27leorizeso in my experience most people would clone the descriptor manually with dup() to make sure that's not the case
18:57:25leorizenot for sockets though, which is why I gave them a flag
18:58:50Araqwell you wrote setInheritable for FileHandle, so it's a thing
19:00:02FromDiscord_<Rika> what are the disadvantages of marking a proc {.inline.}
19:00:50Araqleorize, but ok
19:00:54FromGitter<alehander92> i'd guess code bloat/a bit harder to debugg sometimes
19:01:13*jjido joined #nim
19:01:38AraqRika: as a rule of thumb, if you need to ask, don't use .inline and instead enable linktime optimizations
19:02:33FromDiscord_<Rika> no, its because i'm considering removing the {.inline.}s inside a library its inconsistent with other procs
19:02:39FromDiscord_<Rika> how would i enable LTO
19:05:53Araq--passC="-flto" not sure
19:07:21FromGitter<sheerluck> @Rika --passC="-O3 -flto=9"
19:12:27Araqleorize, another aspect: do you think this is the last file creation flag we will need? because if not we better model as a set[NewEnum]
19:16:57*zahary2 joined #nim
19:18:49FromGitter<alehander92> guys
19:19:18FromDiscord_<clyybber> yo?
19:19:37*zahary1 quit (Ping timeout: 255 seconds)
19:19:51FromGitter<alehander92> what do you think of literate programming? as more in knuth style
19:20:10FromDiscord_<Rika> oh literate programming
19:20:15FromDiscord_<clyybber> Eh, I don't particularily love it when a single loc takes up a whole window
19:20:16FromDiscord_<Rika> sounded interesting
19:20:23FromGitter<alehander92> not only text code, but more like interleaved text + code
19:20:30FromDiscord_<clyybber> I'd rather have a seperate internal documentation
19:20:37FromDiscord_<clyybber> so that I can have them side by side
19:20:54FromGitter<alehander92> i like one web site which does that, i think it was for javascript doc/libs
19:20:58FromGitter<alehander92> but i forgot its name
19:21:20FromGitter<alehander92> i dont really like separate docs except a bigger readme+maybe tutorials
19:27:39FromGitter<alehander92> probably just writing good docstrings + comment blocks in strategic places is good enough for now tho
19:27:49*dadada quit (Ping timeout: 272 seconds)
19:33:31FromDiscord_<Rika> huh, i'm getting SIGSEGV from this line (i think?) when using discordnim https://github.com/nim-lang/Nim/blob/version-1-0/lib/pure/asyncnet.nim#L229
19:36:19leorizeAraq: we definitely should model a set[FileFlags]
19:36:26*dadada joined #nim
19:36:51*dadada is now known as Guest7161
19:36:58leorizehaving fmRead, fmReadWrite, fmWrite is not really nimish
19:37:31*nsf quit (Quit: WeeChat 2.7)
19:38:20FromDiscord_<Rika> wouldnt the issue then be that some flags arent compatible with each other?
19:40:35leorizeit's not like we can't detect that
19:41:07FromDiscord_<Rika> would it confuse beginners?
19:41:47leorizeas if fmReadWrite is not confusing :p
19:41:54leorizebut it wouldn't confuse anyone, really
19:42:17leorizeit makes perfect sense when you can't have a set like {ffRead, ffTruncate} for example
19:42:56FromGitter<Varriount> Unless ffTruncate implies ffWrite
19:43:41leorizeNim's set model don't support that kind of implications
19:49:04FromDiscord_<Rika> who said its the set model that would cause the implication
19:49:38*Guest7161 quit (Ping timeout: 240 seconds)
19:51:20*dadada_ joined #nim
20:00:23*couven92 quit (Read error: Connection reset by peer)
20:00:49*couven92 joined #nim
20:02:22*couven92 quit (Read error: Connection reset by peer)
20:02:48*couven92 joined #nim
20:05:11*dadada_ quit (Ping timeout: 272 seconds)
20:06:18*dadada_ joined #nim
20:19:41*dadada_ quit (Ping timeout: 252 seconds)
20:20:46FromDiscord_<slymilano> Could one create an Elixir Phoenix like framework for Nim? Any attempts so far?
20:20:58FromDiscord_<slymilano> I’m interested in making one
20:21:22*dadada joined #nim
20:21:46*dadada is now known as Guest59848
20:22:33FromDiscord_<clyybber> sure
20:22:36FromDiscord_<clyybber> go ahead
20:22:42FromDiscord_<Elegant Beef> leorize i will attest that fmReadWrite clearing didnt make anysense to me for a good few minutes, im used to that openning and appending, it doesnt indicated clearing in the name
20:23:12FromDiscord_<Elegant Beef> fmReadWrite should be fmReadWriteClear, and fmReadWriteExisting should be fmReadWrite
20:23:26FromDiscord_<Elegant Beef> or flags
20:23:27FromDiscord_<Elegant Beef> 😄
20:23:45leorizetoo late to change that now, I'll put in a flag system once I start working on a new io.nim
20:24:26FromDiscord_<Elegant Beef> Oh i know it's too late, just backing up your "it's confusing"
20:26:44FromDiscord_<Elegant Beef> also can i pettion for flags[enum], i'd never think a set[enums] is flags until i read the tutorial part that says it
20:27:24leorizenah, set[T] is the much better name
20:27:28leorizeit can do more than just flags
20:29:09FromDiscord_<Elegant Beef> huh?
20:30:49FromDiscord_<Rika> how would you implement a flags[enum]?
20:31:12FromDiscord_<Rika> basically he said that set[T] has more uses than flags[enum]
20:31:23FromDiscord_<Rika> or flags[T] tho idk how that would look
20:31:28FromDiscord_<Elegant Beef> the same way as the set but remove the {a,b}, so it's more akin to just bit flags
20:32:00FromDiscord_<Elegant Beef> I'd say more do it to be visibly explict
20:33:02FromDiscord_<Rika> sounds like an unnecessary change for helping beginners
20:33:17FromDiscord_<Rika> how would bitflags look?
20:34:46*Guest59848 quit (Ping timeout: 255 seconds)
20:34:56FromDiscord_<Elegant Beef> would look mostly the same, just be more explict
20:35:17FromDiscord_<Elegant Beef> instead of {a,b} i'd say a & b
20:35:41FromDiscord_<Rika> looks more confusing if youd ask me
20:35:56FromDiscord_<Elegant Beef> so `fmFlag = read & write & clear`
20:36:12*dadada_ joined #nim
20:36:13FromDiscord_<Rika> it would need to look like "ffRead" still
20:36:18FromDiscord_<Rika> you're adding a symbol
20:36:18FromDiscord_<Elegant Beef> i know
20:37:00FromDiscord_<Elegant Beef> To be fair i was joking and dont care that much
20:37:01leorizeElegant Beef: that kind of `&` is C :P
20:37:19FromDiscord_<Elegant Beef> Well blame my C# roots 😛
20:39:21*zahary2 quit (Quit: Leaving.)
20:39:39*zahary1 joined #nim
20:40:07*zahary1 quit (Client Quit)
20:43:00*zahary1 joined #nim
20:43:26*fanta1 quit (Quit: fanta1)
20:45:14*narimiran quit (Ping timeout: 240 seconds)
20:45:49*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:45:51*zahary1 quit (Client Quit)
20:46:07*zahary1 joined #nim
20:46:38*zahary1 quit (Client Quit)
20:50:11*dadada_ quit (Ping timeout: 260 seconds)
20:51:16*dadada_ joined #nim
20:54:02lqdev[m]why does the stdlib use RTLD_NOW for loading DLLs instead of RTLD_LAZY?
20:54:06lqdev[m]namely the dynlib module
20:54:58leorizesecurity reasons :P
20:55:06leorizebut to be fair, it's just faster in the long run
21:01:52lqdev[m]leorize: what security reasons?
21:02:24lqdev[m]it causes issues when loading libs with undefined symbols (which are only defined during the program's runtime)
21:05:05*dadada_ quit (Ping timeout: 258 seconds)
21:06:14*dadada_ joined #nim
21:06:36leorizewdym by "only defined during the program's runtime"?
21:08:21*Hideki_ joined #nim
21:09:34lqdev[m]I have a dynlib which uses an extern declaration from a header file, but does not link to my main program which actually implements the function. the symbol for the extern function remains undefined when loading using RTLD_NOW and ultimately results in my desired function's symbol not being found by `dlsym`
21:09:56leorizelqdev[m]: it was there since the beginning, but here's the benefit of RTLD_NOW: it allows RELRO hardening to mark sections as read-only as soon as possible
21:10:32leorizelqdev[m]: do you export the symbol?
21:11:00leorizeif you don't then the library you load won't be able to open it
21:11:41lqdev[m]leorize: yes
21:11:49lqdev[m]of course I do
21:11:52leorizedid you put {.dynlib.} on it?
21:11:56*letto quit (Quit: Konversation terminated!)
21:12:08lqdev[m]which one, the one exported from the app or the lib?
21:12:11leorizeboth
21:12:35leorizeyou need one for the app so the dynamic linker exposes that symbol to the loaded library
21:12:38lqdev[m]ah, I didn't put one on the sym exported from the app
21:12:45*Hideki_ quit (Ping timeout: 258 seconds)
21:12:52lqdev[m]the lib is written in C so idk how I'd do that
21:12:54leorizeand you need one for the lib so the dynamic linker can load it from the lib
21:13:29leorizethen it's probably already supported
21:13:43*letto joined #nim
21:14:35lqdev[m]yeah `readelf` reports that the symbol is global and its visibility is normal, and it loads fine with RTLD_LAZY
21:15:00leorizewell it's lazy :P
21:15:12leorizeit won't attempt to resolve until you use it
21:15:33lqdev[m]but putting exportc, dynlib onto my app's procs doesn't work, the symbol still stays unresolved when attempting to find it
21:15:52leorizethat's strange
21:16:19leorizeaccording to dlopen whatever symbol that's already global will be available for the loaded lib to relocate against
21:18:39lqdev[m]this is my C API https://github.com/liquid600pgm/nadio/blob/master/src/nadio/plugins/c_api.nim
21:19:03lqdev[m]and this is how I load my procs https://github.com/liquid600pgm/nadio/blob/master/src/nadio/plugins.nim#L17
21:19:19*neceve quit (Ping timeout: 255 seconds)
21:19:38*dadada_ quit (Ping timeout: 240 seconds)
21:21:15leorizecan you verify that the symbol is exported from your binary?
21:21:21*dadada joined #nim
21:21:45*dadada is now known as Guest94794
21:22:55lqdev[m]yeah, it's exported
21:23:19*hax-scramper quit (Read error: Connection reset by peer)
21:23:44*hax-scramper joined #nim
21:25:25*clyybber joined #nim
21:30:20lqdev[m]I may just use my own implementation of loadLib at this point, I'm too lazy and have too little knowledge to debug this
21:32:57*solitudesf joined #nim
21:34:23*letto_ joined #nim
21:35:07*Guest94794 quit (Ping timeout: 272 seconds)
21:35:21*letto quit (Ping timeout: 265 seconds)
21:36:12*dadada_ joined #nim
21:36:54*couven92 quit (Read error: Connection reset by peer)
21:37:15*couven92 joined #nim
21:49:55*dadada_ quit (Ping timeout: 260 seconds)
21:51:16*dadada_ joined #nim
22:01:50*marmotini_ quit (Remote host closed the connection)
22:02:23*marmotini_ joined #nim
22:05:16*dadada_ quit (Ping timeout: 258 seconds)
22:05:33*drewr joined #nim
22:06:09*tane quit (Quit: Leaving)
22:06:17*dadada_ joined #nim
22:06:26*marmotini_ quit (Ping timeout: 240 seconds)
22:10:42*Trustable quit (Remote host closed the connection)
22:20:43*dadada_ quit (Ping timeout: 272 seconds)
22:21:18*dadada joined #nim
22:21:41*dadada is now known as Guest62548
22:27:43*solitudesf quit (Ping timeout: 255 seconds)
22:31:36*Hideki_ joined #nim
22:32:50*natrys quit (Ping timeout: 240 seconds)
22:35:17*Guest62548 quit (Ping timeout: 265 seconds)
22:36:42*dadada_ joined #nim
22:50:29*dadada_ quit (Ping timeout: 272 seconds)
22:51:22*dadada_ joined #nim
22:51:45*lritter quit (Ping timeout: 272 seconds)
22:52:55*clyybber quit (Ping timeout: 255 seconds)
22:54:36*clyybber joined #nim
23:04:50*dadada_ quit (Ping timeout: 240 seconds)
23:06:18*dadada_ joined #nim
23:08:09*filcuc quit (Ping timeout: 265 seconds)
23:12:32*filcuc joined #nim
23:20:14*dadada_ quit (Ping timeout: 265 seconds)
23:21:15*dadada joined #nim
23:21:40*dadada is now known as Guest49723
23:34:11*Hideki_ quit (Ping timeout: 272 seconds)
23:37:50*couven92 quit (Read error: Connection reset by peer)
23:38:18*couven92 joined #nim
23:47:55*clyybber quit (Quit: WeeChat 2.7.1)