<< 04-02-2021 >>

00:01:43*spiderstew joined #nim
00:03:25*spiderstew_ quit (Ping timeout: 240 seconds)
00:05:35*muffindrake joined #nim
00:08:28*Vladar quit (Quit: Leaving)
00:18:17*spiderstew_ joined #nim
00:19:07*spiderstew quit (Ping timeout: 272 seconds)
00:43:09*spiderstew_ quit (Ping timeout: 264 seconds)
00:44:09*spiderstew joined #nim
01:01:10*njoseph quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
01:01:33*njoseph joined #nim
01:03:41*krux02 quit (Remote host closed the connection)
01:29:08*Tlangir quit (Remote host closed the connection)
01:36:55*Tanger joined #nim
01:45:45*evbo quit (Ping timeout: 246 seconds)
02:07:57*kitech1 quit (Max SendQ exceeded)
02:08:33*kitech1 joined #nim
02:29:09*Amun_Ra quit (Ping timeout: 246 seconds)
02:31:50*Amun_Ra joined #nim
02:38:03*a_chou joined #nim
02:41:44*jjido quit (Quit: Connection closed for inactivity)
02:41:45*wasted_youth quit (Quit: Leaving)
03:06:08*irchaxwell_zzz joined #nim
03:10:07*irchaxwell_ quit (Ping timeout: 272 seconds)
03:31:37*rockcavera quit (Remote host closed the connection)
03:49:51ForumUpdaterBotNew thread by Boia01: Help needed: Deadlock during allocShared0, see https://forum.nim-lang.org/t/7470
03:55:55*muffindrake quit (Ping timeout: 258 seconds)
03:57:49*muffindrake joined #nim
04:12:21*a_chou quit (Remote host closed the connection)
04:39:09*zedeus joined #nim
04:48:02*spiderstew_ joined #nim
04:50:34*spiderstew quit (Ping timeout: 276 seconds)
04:54:12*Tlangir joined #nim
04:56:57*Tanger quit (Ping timeout: 264 seconds)
05:09:15*muffindrake quit (Quit: muffindrake)
05:23:24*muffindrake joined #nim
05:30:37saemwooooow, that "fix" I just made really punched the compiler performance in the face.
05:34:21saemDon't worry, I'm not going to commit it.
05:35:05FromDiscord<ElegantBeef> Did you build the compiler in danger mode?
05:35:08FromDiscord<ElegantBeef> (edit) "danger" => "release"
05:37:32saemI added an extra conditional check in a hotspot. 😬
05:39:54*mmohammadi9812 quit (Read error: Connection reset by peer)
05:40:03*mmohammadi9812 joined #nim
05:40:05*zedeus quit (Ping timeout: 240 seconds)
05:42:33*zedeus joined #nim
05:44:07*muffindrake quit (Quit: muffindrake)
05:50:25*mmohammadi9812 quit (Ping timeout: 240 seconds)
05:51:21*mmohammadi9812 joined #nim
05:57:31*zedeus quit (Ping timeout: 276 seconds)
06:00:02FromDiscord<Stuffe> Anyone know how I can distinguish between varargs and openArray in the function signature when calling a function?
06:01:04FromDiscord<Stuffe> I am using a library where both are implemented and I just want to call either one of them, but im blocked by the "ambiguous call" error message
06:03:21FromDiscord<ElegantBeef> are the names identical?
06:03:53FromDiscord<ElegantBeef> Can you show the two proc signatures, or link the reference code?
06:08:02FromDiscord<Stuffe> arrays.newArray(s: varargs[Variant])↵arrays.newArray(s: openArray[Variant])
06:08:46FromDiscord<Stuffe> right after I asked I figured out I was able to do: newArray(1, 2)
06:08:59FromDiscord<Stuffe> of course I only thought of that after asking
06:09:30*Tanger joined #nim
06:09:39FromDiscord<Stuffe> but I can't see how you could ever call the openArray one
06:10:36FromDiscord<ElegantBeef> I dont think you can
06:11:09FromDiscord<ElegantBeef> aside from doing `let a: proc(s: openArray[Variant) = newArray`
06:13:04FromDiscord<Stuffe> ah yes
06:13:16*Tlangir quit (Ping timeout: 272 seconds)
06:13:18FromDiscord<Stuffe> glad I ddidnt have to do that though, a bit hacky 🙂
06:13:24FromDiscord<ElegantBeef> "a bit"
06:13:37FromDiscord<ElegantBeef> It's very hacky 😄
06:13:56FromDiscord<ElegantBeef> Although Nim tends to use the least generic so i'd have imagined the OA version was used
06:31:46*zedeus joined #nim
06:40:24*muffindrake joined #nim
06:57:41*letto quit (Quit: Konversation terminated!)
07:00:01*letto joined #nim
07:02:15*krux02 joined #nim
07:03:13*waleee-cl quit (Quit: Connection closed for inactivity)
07:05:45*mmohammadi9812 quit (Ping timeout: 240 seconds)
07:06:24*mmohammadi9812 joined #nim
07:06:37*narimiran joined #nim
07:11:51*tsujp1 quit (Ping timeout: 260 seconds)
07:27:49*dv^_^96 joined #nim
07:28:50*dv^_^9 quit (Read error: Connection reset by peer)
07:47:19*liblq-dev joined #nim
07:50:57*hyiltiz quit (Ping timeout: 264 seconds)
07:51:50*hyiltiz joined #nim
07:54:46*opal quit (Ping timeout: 268 seconds)
07:55:34*mmohammadi9812 quit (Quit: Quit)
07:55:44*opal joined #nim
07:57:56*PMunch joined #nim
08:14:16*haxscramper joined #nim
08:17:08*superbia joined #nim
08:24:33*zedeus quit (Ping timeout: 264 seconds)
08:24:59*zedeus joined #nim
08:35:22*krux02 quit (Ping timeout: 258 seconds)
08:39:52*vicfred quit (Quit: Leaving)
08:48:27*krux02 joined #nim
08:59:27*superbia quit (Quit: WeeChat 3.0)
09:00:18*fredrikhr joined #nim
09:00:28FromDiscord<impbox> with strformat can I do something like `echo &"""foo: {if bar: "ON" else: "OFF"}"""` this errors with `Error: could not parse 'if bar.'`, is there something similar I can do to get a ternary like behaviour in a format str?
09:08:12FromDiscord<pietroppeter> the issue with strformat is that `:` is interpreted as format specificier: see here https://stackoverflow.com/a/63612872/4178189
09:08:57*liblq-dev quit (Ping timeout: 264 seconds)
09:09:30FromDiscord<pietroppeter> I guess the standard answer would be to avoid doing complex stuff inside a strformat. for a workaround you would need to find a way to have a ternary expression without `:`. I guess you could use ?! of elvis: https://github.com/mattaylor/elvis
09:10:08FromDiscord<impbox> i've worked around it by making a `proc toOnOff(x: bool): string`, but yeah it'd be nice to be able to do ternary type operations in format strings
09:10:32*liblq-dev joined #nim
09:11:01FromDiscord<impbox> `&"""foo: {(if bar: "ON" else: "OFF")}"""` would be fine too if the ()s meant it interpreted it as an expression
09:11:08FromDiscord<impbox> but ahh well, not a big drama
09:11:19FromDiscord<impbox> thanks for explaining why it doesn't work
09:12:54FromDiscord<Rika> i wish nim used something else for the format specifier
09:13:12FromDiscord<Rika> this is prolly why python doesnt use colons in their ternary
09:13:39FromDiscord<pietroppeter> you are welcome! and I guess also your suggestion of using parenthesis to avoid parsing a formatSpecifier is also a good one, better the one I gave in the SO answer.it probably could be not so hard to implement in strformat
09:14:11FromDiscord<Rika> its not gonna be trivial i believe
09:14:26FromDiscord<Rika> needs a parens matcher doesnt it?
09:14:56FromDiscord<haxscramper> sent a code paste, see https://play.nim-lang.org/#ix=2OiS
09:17:14FromDiscord<pietroppeter> yes not trivial. it would need some kind of parens matching but probably not a full fledged one (if there is an open par I do not parse the formatSpecifier; I do not care if parens are correctly open and closed...)
09:17:56FromDiscord<Rika> i guess its just a counter?
09:18:29FromDiscord<Rika> counter while iterating through the string so sadly still O(n)
09:18:36FromDiscord<Rika> maybe?
09:19:43FromDiscord<pietroppeter> yeah probably just a counter. but the more I think about it, I guess also this solution would have its problems (e.g. `"""{(if c == ')': 0 else: 1")}`)
09:20:10FromDiscord<pietroppeter> (I was also missing a `"""` at the end)
09:20:52FromDiscord<haxscramper> This can be done by keeping flags for opening/closing string elements in addition to counting balanced `{`
09:20:52FromDiscord<Rika> so also a '' counter lol
09:21:18FromDiscord<haxscramper> Or keeping a stack for all opening/closing delimiters instead of just a counter
09:21:33Oddmongeri'm using nvim with the alaviss/nim plugin. It works well, except sometimes i've some words which are inverted (backgroud color becomes foreground, and vice-versa)
09:21:47FromDiscord<haxscramper> Since there is no AST to speak of it could be just `seq[string]` of delimiters
09:22:01FromDiscord<Rika> that can get large
09:22:13FromDiscord<Rika> can be a seq[char] since delimiters are rarely more than one character?
09:22:20FromDiscord<Rika> or are they even ever over one char
09:22:24Oddmongeri don't know why it does that. It's not highlighting («:noh» removes nothing) , and not an error indication too
09:22:51Oddmongeri'm curious to know if alaviss/nim users here have the same behaviour
09:24:06FromDiscord<lqdev> @Rika a seq[char] is the same as a string…
09:24:18FromDiscord<Rika> read again
09:24:30FromDiscord<Rika> seq[string] vs seq[char]
09:24:41FromDiscord<lqdev> blind me
09:24:50FromDiscord<Rika> haha
09:25:15FromDiscord<Rika> in this case a seq[char] is more appropriate than a string even if they have the same representation in computer
09:28:27*irchaxwell_ joined #nim
09:32:05*joast quit (Ping timeout: 240 seconds)
09:32:39*irchaxwell_zzz quit (Ping timeout: 272 seconds)
09:33:12FromDiscord<pietroppeter> and even without colons, strformat does have problem with string/char delimited closing braces: `echo fmt"{c == '}'}"` does not compile, see https://play.nim-lang.org/#ix=2OiY
09:39:17krux02eval: echo fmt"{c == '}'}"
09:39:25krux02,eval echo fmt"{c == '}'}"
09:39:34krux02isn't there this nimbot?
09:39:40krux02NimBot, help
09:40:32krux02not sure if I have the syntax right, but NimBot should answer
09:40:47FromDiscord<Rika> !eval echo fmt"{c == '}'}"
09:40:48NimBotCompile failed: /usercode/in.nim(1, 6) Error: undeclared identifier: 'fmt'
09:40:50FromDiscord<Rika> ah
09:41:07FromDiscord<Rika> !eval import strformat; echo fmt"{c == '}'}"
09:41:09NimBotCompile failed: /playground/nim/lib/core/macros.nim(550, 7) Error: invalid character literal
09:46:53*liblq-dev quit (Ping timeout: 256 seconds)
09:48:44*liblq-dev joined #nim
09:55:09*liblq-dev quit (Ping timeout: 264 seconds)
09:56:40*fredrikhr quit (Read error: Connection reset by peer)
09:56:56*liblq-dev joined #nim
10:35:52*abm joined #nim
10:51:06ForumUpdaterBotNew thread by Steven: Length of a string in bytes, see https://forum.nim-lang.org/t/7471
10:56:03FromDiscord<jmgomez> Hey guys, not sure if I am missing something but there is no support for autocomplete in any of the editors that I tried. What am I missing? https://media.discordapp.net/attachments/371759389889003532/806840486375456768/unknown.png
10:56:39Clonkk[m]There is support for Vim, Neovim, VSCode at least
10:58:07FromDiscord<jmgomez> https://github.com/pragmagic/vscode-nim/issues/177
10:58:17PMunchNimLSP has auto-complete
10:58:31PMunchIt's a bit, uhm, dodgy
10:58:33PMunchBut it's there
10:59:30FromDiscord<jmgomez> Okay! Will try it out
10:59:57*zedeus quit (Ping timeout: 264 seconds)
11:00:25*zedeus joined #nim
11:01:57Clonkk[m]On VSCode you can try Saem's extension. He is pretty active and it works fine (disclaimer: I don't use VSCode much so I may not have encountered the complex case)
11:02:16Clonkk[m]On Neovim NimLSP does the job
11:09:36*rockcavera joined #nim
11:31:27*irchaxwell_zzz joined #nim
11:35:26*irchaxwell_ quit (Ping timeout: 264 seconds)
11:54:33*zedeus quit (Ping timeout: 264 seconds)
11:55:00*zedeus joined #nim
12:01:26*opal quit (Ping timeout: 268 seconds)
12:04:35FromGitter<offbeat-stuff> Hint: [Link] ⏎ /usr/bin/ld: /home/kai/.cache/nim/main_d/@mmain.nim.cpp.o: in function `NimMainModule()': ⏎ @mmain.nim.cpp:(.text+0x1d0): undefined reference to `nimLoadProcs0'
12:05:17FromGitter<offbeat-stuff> on this line
12:05:18FromGitter<offbeat-stuff> extern "C" N_NIMCALL(void, nimLoadProcs0)(void);
12:06:23FromGitter<offbeat-stuff> CC: read ⏎ CC: stdlib_assertions.nim ⏎ CC: stdlib_system.nim ⏎ CC: stdlib_times.nim ⏎ CC: stdlib_os.nim ... [https://gitter.im/nim-lang/Nim?at=601be33f9fa6765ef8f94e50]
12:07:46*opal joined #nim
12:11:37*fredrikhr joined #nim
12:12:21PMunchUhm, how are you trying to build?
12:12:48FromGitter<offbeat-stuff> nim cpp -r --opt:speed src/main.nim -o bin/app
12:13:00FromGitter<offbeat-stuff> -d:debug too
12:13:08FromGitter<offbeat-stuff> with a nakefile
12:13:57FromGitter<offbeat-stuff> Although it solved after I removed opengl import
12:15:07*liblq-dev quit (Quit: WeeChat 3.0)
12:20:57*zedeus quit (Ping timeout: 264 seconds)
12:22:25*zedeus joined #nim
12:23:03*xet7 quit (Quit: Leaving)
12:28:20*opal quit (Remote host closed the connection)
12:28:46*opal joined #nim
12:31:05FromDiscord<Goel> What are the drawback of using -d:release --opt:speed? I mean between simply using -d:release without options
12:31:39FromDiscord<lqdev> none. `-d:release` implies `--opt:speed`.
12:31:53*liblq-dev joined #nim
12:32:05FromDiscord<Goel> Ah, smart choice :nimGlow2:
12:32:28FromDiscord<lqdev> well, why wouldn't a release build imply the best possible performance anyways?
12:33:26FromDiscord<mratsim> if you want the best possible performance, you hop on a rocket and you turn on -d:danger
12:33:34FromDiscord<mratsim> brrrrrrrrrrrrrrrrrrr
12:34:07FromDiscord<Goel> I though the optional "speed" was mean as "+speed compared to the release default"
12:34:28FromDiscord<mratsim> no it's for compiling in debug + optimization
12:35:16*Tanger quit (Remote host closed the connection)
12:37:21PMunchAnd you can do -d:release --opt:size if you want to optimise for size instead
12:37:34PMunchWell, in addition to
12:37:36FromDiscord<zetashift> Hiya is that IntelliJ? Are you using: https://plugins.jetbrains.com/plugin/15128-nim ?
12:40:28FromDiscord<Goel> I have a noob question not related to Nim, but just i dont undersand how it works: z = 3 + 2
12:40:59*xet7 joined #nim
12:41:17FromDiscord<jmgomez> yup
12:41:31FromDiscord<Goel> How is saved in memory the value of the variabile z? as 5 or as 3+2?
12:41:49*liblq-dev quit (Ping timeout: 276 seconds)
12:41:58PMunchAs 5
12:42:22FromDiscord<mratsim> any compiler will see that 3+2 is a constants and will directly put 3+2 in z
12:42:25FromDiscord<Goel> I don't undestand why in the example they declare a variabile like that, doesn't make much sense
12:42:47FromDiscord<mratsim> some examples are contrived
12:42:48PMunchIn general values will be evaluated before they are assigned to a variable
12:42:50FromDiscord<Goel> Yeah i get it
12:43:10PMunchIn fact the compiler will do this one for you, if you look at the binary it will be z = 5
12:43:16*liblq-dev joined #nim
12:43:46FromDiscord<mratsim> even Nim will do that here
12:44:01PMunchI guess it might be to show that Nim is able to figure out that int + int = int and that z is int without having to declare z: int = 2 + 3
12:44:05PMunchOr something like that
12:44:18PMunch@mratsim, before it hits the C compiler?
12:44:36FromDiscord<Goel> Yep that make sense
12:44:39FromDiscord<haxscramper> yes, we have quite good constant folding
12:45:20PMunchYeah I knew we did, but in this case it doesn't really have to be done by Nim
12:45:32FromDiscord<Goel> I found this tutorial online that is not mentioned in the Nim "Learn" page or resource, seems good to me, even though my browser tells me is "not safe" for some reason http://ssalewski.de/nimprogramming.html#_part_ii_the_basics
12:45:38PMunchWouldn't make a difference if you're not using a really dumb C compiler
12:46:12PMunch@Goel, that's just because it's HTTP and not HTTPS
12:46:31FromDiscord<mratsim> before the C compiler yes, it's the semfold pass
12:47:01FromDiscord<mratsim> @ssalewski, your website is apparently unsafe
12:47:23FromDiscord<mratsim> probably need some https
12:47:46PMunchI mean it's not really unsafe
12:47:56FromDiscord<Goel> How are called the "Zero Value" in Nim?
12:47:58PMunchIt would just be unsafe to put private information into it
12:48:14FromDiscord<mratsim> can you show an example of those zero values?
12:48:15PMunchOr trust that the content is from the origin and not MITM'ed
12:49:17FromDiscord<Goel> in golang a Zero Value is for example if i define x as an Int but i dont set a value
12:49:21FromDiscord<konsumlamm> hmm, does nim also fold constant when it would result in an overflow?
12:50:00FromDiscord<mratsim> @Goel you use an option from `import std/options`
12:50:02FromDiscord<konsumlamm> you mean the default value when you don't explicitly initialize something?
12:50:10FromDiscord<Goel> Yes
12:50:11FromDiscord<mratsim> @konsumlamm you would have a compile-time overflow
12:50:18FromDiscord<haxscramper> No, there are checks for overflow as far as I can see
12:50:38FromDiscord<haxscramper> At least after quick look at `compiler/semfold.nim`
12:50:52PMunch@Goel, unassigned variables are all binary 0
12:50:53FromDiscord<lqdev> @Goel `default(T)`, where T is the type
12:50:55FromDiscord<mratsim> @Goel if you don't define a value, everything is set to binary zero
12:51:03FromDiscord<haxscramper> ddos response
12:51:06FromDiscord<mratsim> lol
12:51:28FromDiscord<Goel> 0 or Nil?
12:51:33PMunchFor integers this means a 0, strings are empty string, sequences empty sequences, pointers and refs are nil
12:51:37FromDiscord<mratsim> nil is binary zero
12:51:42PMunchSo is 0
12:51:48FromDiscord<mratsim> yes
12:51:53PMunchIntegers can't be nil in Nim
12:52:01FromDiscord<konsumlamm> and binary zero actually makes sense, since for number (int/float) types it's just 0, for seqs/strings it's the empty seq/string and for ref types it's nil
12:52:04PMunchBecause they aren't objects
12:52:12FromDiscord<haxscramper> @Goel also there is an article specifically about memory model in nim - http://zevv.nl/nim-memory/
12:52:16FromDiscord<mratsim> they arent ptr you mean
12:52:23FromDiscord<konsumlamm> because they aren't ref objects
12:52:31FromDiscord<konsumlamm> normal objects can't be nil either
12:52:37FromDiscord<Goel> sent a long message, see http://ix.io/2OjV
12:52:42PMunch@konsumlamm, it didn't use to be empty strings and sequences. Back in the olden days string and seqs could be nil
12:52:53PMunchWhich just caused a bunch of headache
12:53:12FromDiscord<lqdev> nowadays, a binary zero string is the empty string.
12:53:15FromDiscord<konsumlamm> it's pretty much the same in nim
12:53:18FromDiscord<haxscramper> `enum` values are also initialized with zeros
12:53:31PMunch@mratsim, yes, but if Goel was used to object oriented languages I didn't want to confuse them with ref object vs object
12:53:34FromDiscord<konsumlamm> except for the last line since most of these aren't builtin in nim
12:54:22PMunchMaps, ie. tables in Nim, are also just an empty table
12:58:28FromDiscord<Goel> What do you mean with "empty"? How do i check if a Table is "emtpy" if its not set as Nil at compile time?
12:58:47FromDiscord<mratsim> myTable.len == 0
12:58:55FromDiscord<Goel> Ok
12:59:25FromDiscord<mratsim> Oh, FOSDEM is this weekend?
12:59:42FromDiscord<mratsim> I miss the beer though i don't miss being stuffed in that bar
13:02:06PMunchYup, FOSDEM this weekend
13:02:19PMunchAnd I fully plan on buying Belgian beer to enjoy at home for the occasion
13:02:24FromDiscord<konsumlamm> a normal Table is not a reference type, thus it literally can't be nil
13:03:46PMunchShould we organise a Nim digital meetup? Just drink some beer and talk about Nim like we usually do when we're at FOSDEM?
13:05:53*wasted_youth joined #nim
13:07:40*abm quit (Quit: Leaving)
13:11:56FromDiscord<konsumlamm> lol, TIL that you can leave out the `:` after `case <expression>`
13:13:06PMunchWait, really?
13:13:39FromDiscord<Ardek> yes
13:14:20FromDiscord<Ardek> thats how i write cases
13:16:51FromDiscord<Clyybber> it's more common without the `:` I think even
13:16:58FromDiscord<lqdev> yeah
13:17:03FromDiscord<lqdev> the `:` is optional
13:17:37FromDiscord<lqdev> one cool aesthetic quality it has is that in `case x` all the cases align with `x`
13:17:39FromDiscord<lqdev> like so
13:18:04FromDiscord<Clyybber> oh
13:18:06FromDiscord<lqdev> sent a code paste, see https://play.nim-lang.org/#ix=2Ok7
13:18:11FromDiscord<Clyybber> thats a neat way to format a case
13:18:18FromDiscord<lqdev> yeah, and it's totally legal
13:18:36FromDiscord<lqdev> as i said, you can add a `:` after `case x` if you prefer to but it's optional
13:18:44FromDiscord<lqdev> the indent is optional too, ofc
13:19:03Clonkk[m]<PMunch "Should we organise a Nim digital"> Could be fun.
13:19:19FromDiscord<lqdev> PMunch: i second this
13:19:25FromDiscord<Ardek> i mostly use it without `:` because the emacs plugin idents automatically the cases and i dont like that
13:19:25FromDiscord<konsumlamm> i've never seen it without the `:` until looking at the documentation for `parseopt`
13:19:56PMunch@lqdev, that paste was something completely different :P Or was it the Discord bot tripping up?
13:20:27FromDiscord<lqdev> hold on, i gotta check the irclogs for this
13:20:42PMunchClonkk[m], @lqdev, I say organise, but it would really just be to set up a Jitsi room or something
13:20:44FromDiscord<lqdev> PMunch: that must be something on your side, i'm getting the right paste
13:20:57PMunchOh weird, now it worked
13:21:05PMunchI have noticed ix.io sometimes giving me the wrong paste
13:21:15FromDiscord<lqdev> playground paste downloads are a bit flaky in my experience
13:21:21PMunchOh, but I don't usually indent my case statements
13:21:21FromDiscord<lqdev> sometimes they just don't work
13:21:34FromDiscord<lqdev> though it's just sometimes, and a refresh usually fixes the issue
13:21:48PMunchYeah, that's the playground <-> ix interaction
13:22:01PMunchBut as you say a refresh typically fixes it
13:24:51FromDiscord<Goel> Is it best to opt for a wrapper or a binding of a library that is not native to Nim? I've been reading for the past 15 mins the difference but i still didn't get which one is the best performance wise, someone tells the bindings are usually better, someone else say the opposite
13:26:15Clonkk[m]<FromDiscord "<Goel> Is it best to opt for a w"> What do you mean wrapper vs binding ?
13:29:35FromDiscord<Goel> I want to import a GUI library not written on Nim, like ImGui or raylib
13:30:27FromDiscord<Goel> (edit) "raylib" => "raylib. Some of them are called Bindings for: and some other are Wrapper for"
13:30:32FromDiscord<lqdev> wrappers and bindings are synonymous
13:30:43FromDiscord<Goel> I don't think so
13:30:46FromDiscord<lqdev> what really matters is whether they're idiomatic (high-level) or not
13:31:12FromDiscord<Goel> https://stackoverflow.com/questions/8628326/what-is-the-difference-between-a-wrapper-a-binding-and-a-port
13:31:30Clonkk[m]Bindings means linking a nimble function to a library function. Wrapper means creating a layer on top of it usually to offer a better API.
13:32:01FromDiscord<lqdev> > It should also be noted that sometimes people will say wrapper when what they technically mean is a binding (myself included).
13:32:03Clonkk[m]If you want to use an external lib you NEED bindings, and you can do a wrapper on top of it to improve your API
13:32:25Clonkk[m]<FromDiscord "<lqdev> > It should also be note"> Yeah, the difference is thin
13:32:46FromGitter<Araq> 'NEED' is a strong word. you would be surprised how far you can get with `.emit` :P
13:33:11Clonkk[m]Fair point
13:33:19PMunch@Goel, for a UI library you probably won't notice any difference
13:33:32PMunchChose the one with the interface that feels best for you
13:33:49Clonkk[m] * If you want to use an external lib you <del>NEED</del> most likely want bindings, and you can do a wrapper on top of it to improve your API
13:33:49PMunchIt's probably not going to be a massive overhead anyways
13:35:28FromDiscord<Goel> Now i don't remember the names, but some months ago i tried a few guys, one of which (desktop app gui) i tried to work with a few examples, like a basic window app with a few buttons and stuff, and i tried the same thing with a few different Gui's one and was cosuming like 250mb of ram while opened, while another was like 24mb of ram
13:36:20FromDiscord<Goel> (edit) "ram" => "ram.↵And they did exactly the same thing, it was targeting win32 API"
13:38:59*vicfred joined #nim
13:41:53PMunchProbably one of those libraries have a lot of overhead..
13:42:47Clonkk[m]Honestly 250mb for GUI is not much nowadays I wouldn't worry about it
13:45:50PMunchI would, but that's just because I'm opposed to using more resources than you need
13:45:54PMunchCall me old fashioned
13:46:02FromGitter<Araq> 250MB is terrible bloat, but ymmv
13:47:47FromDiscord<mratsim> Says Araq using Gitter
13:48:08FromGitter<Araq> running in the browser he has open already anyway
13:48:22FromGitter<Araq> I don't use an app, just another tab
13:48:28FromDiscord<mratsim> oh, my bad
13:48:57FromDiscord<Clyybber> does gitter even have a standalone app?
13:49:25*liblq-dev quit (Ping timeout: 276 seconds)
13:50:29*liblq-dev joined #nim
13:50:31Clonkk[m]Gitter is being migrated to Element.io anyway
13:53:46FromDiscord<Clyybber> Shouldn't paths in a config be relative to the config file?
13:53:55FromDiscord<Clyybber> instead of relative to the CWD
13:54:12FromDiscord<Clyybber> seems like a much saner default
13:55:04leorize[m]Clonkk: they're gonna keep the gitter client and potentially make it an alternative to element
13:55:18FromDiscord<Clyybber> leorize: Whats your opinion on the above ^
13:55:39leorize[m]I have no idea what you're referring to :p
13:56:00FromDiscord<Clyybber> if you do switch("outDir", "bin") for example
13:56:11FromDiscord<Clyybber> then that bin path is relative to your CWD
13:56:24FromDiscord<Clyybber> instead of relative to the config file
13:57:17leorize[m]config composition complicates that though
13:57:27leorize[m]but yea, sounds reasonable
13:58:24FromDiscord<Clyybber> although that makes it "inconsistent" with command line switches I guess
13:59:54leorize[m]you can see how other tools do it if in doubt
14:00:28*rockcavera quit (Remote host closed the connection)
14:01:23leorize[m]nim is not the only program with relative paths in config + command line switch
14:01:24Clonkk[m]Btw leorize do you know how to get your Vim plugin working with coc & nimlsp ?
14:01:55Clonkk[m]I switched from ``prabirshrestha/vim-lsp``
14:01:55PMunchGitter tab in my browser 48Mb RAM, HexChat running on my machine 84Kb RAM, doesn't have to be an app to be bloat Araq ;)
14:02:31leorize[m]Clonkk: Prestige would know more than I do. I personally don't use nimlsp.
14:03:14Clonkk[m]Damn
14:03:19Clonkk[m]Thanks anyway ^^
14:03:51Prestigehttps://github.com/avahe-kellenberger/dotfiles/blob/master/nvim/coc-settings.json Clonkk[m]
14:04:35PrestigeI think there are instructions on the coc repo wiki
14:05:31FromDiscord<Goel> Which Browser/s did you use, guys?
14:06:19leorize[m]Firefox, though I do have Chromium for sites that don't work with FF
14:06:26Clonkk[m]<Prestige "">https://github.com/avahe-kellenb"> So coc itself is running fine, I have the settings JSON setup. But with the old lsp I had the error displayed by the pluign inside Vim and since switching it's not anymore
14:06:48FromDiscord<lqdev> @Goel same as leorize
14:07:21PMunchSame as leorize[m] and lqdev
14:07:36FromDiscord<Ardek> i use ungoogled-chromium
14:07:53FromDiscord<Goel> I tried all of them during the years, mostly i sticked to Firefox and Opera, but then last year i tried Brave, and i never switched back
14:07:55PrestigeClonkk[m]: do you mean it's working now? Or, if not, what is happening?
14:07:55PMunchHad a brief go at trying to get Chromium embedded framework to run in Nim so I could make my own browser
14:08:06PMunchGot to the point of it running, and then Christmas came :P
14:08:15*clyybber joined #nim
14:08:21PMunchI used Opera back in the days
14:08:34PMunchIt was pretty good until it turned into a Chromium reskin..
14:08:54Clonkk[m]<Prestige "Clonkk: do you mean it's working"> I had coc working in general (checked on python & C++ file). But for Nim specifically, since switching, errors are not displayed anymore in Vim (when it used to). So I assumed it was a nim.vim plugin issue
14:09:45PrestigeOh like language diagnostics? Interesting - should be an issue of the setup with coc and nimlsp though
14:10:18leorize[m]nim.nvim doesn't do diagnostics, yet
14:11:24PrestigeThere should be a log for coc you can look into, if you aren't seeing it work with nimlsp
14:11:36PMunch@Goel, can you put your tabs on the right hand side in Brave?
14:11:45PrestigeMy guess is that it isn't pointed at the nimlsp executable
14:12:55Clonkk[m]<Prestige "My guess is that it isn't pointe"> I have the same settings as you for Nim server though
14:13:37PrestigeIf you can show us the coc log, I could help a bit more (probably)
14:14:24Clonkk[m]I'll try to take screenshot to explain my points better.
14:16:39FromDiscord<Goel> @PMunch I'm looking at the Brave settings for Tabs but no, i dont think you can do that, at least not without an extension
14:16:58PMunchWell I'd be fine with an extension
14:32:02*joast joined #nim
14:38:45ForumUpdaterBotNew post on r/nim by CLDev-447: Iterator/proc wrapping examples?, see https://www.reddit.com/r/nim/comments/lcgyia/iteratorproc_wrapping_examples/
14:43:09*liblq-dev quit (Ping timeout: 264 seconds)
14:44:46*liblq-dev joined #nim
14:48:18*abm joined #nim
15:02:40*opal quit (Remote host closed the connection)
15:03:07*opal joined #nim
15:04:21*liblq-dev quit (Quit: WeeChat 3.0)
15:09:48*PMunch quit (Quit: leaving)
15:10:03*Vladar joined #nim
15:11:47*liblq-dev joined #nim
15:14:56stefantalpalaruNimble vulnerabilities: https://consensys.net/diligence/vulnerabilities/nim-insecure-ssl-tls-defaults-remote-code-execution/
15:17:16leorizeso... no disclosure time for us to fix it?
15:17:37leorizeah, affecting old versions only
15:18:45*liblq-dev quit (Quit: WeeChat 3.0)
15:18:54saemOlder versions that are still very much in use?
15:19:13saemSeems pretty lame.
15:19:16*liblq-dev joined #nim
15:19:41leorizeit's a nimble bug, do you seriously expect those to be fixed?
15:20:39leorizefrom what I can tell, they contacted dom and received zero answers
15:20:46leorizeat least from their timeline
15:21:42FromDiscord<zetashift> yea I saw that too
15:22:08leorize@dom96 ^
15:23:04FromDiscord<dom96> They did receive answers, we have a telegram group for this
15:23:29FromDiscord<dom96> federico was working on fixing that that specific nimble issue AFAIK
15:23:32leorizeso, uh, why are the bugs unfixed?
15:24:19FromDiscord<dom96> Maybe because nobody pays us to fix these issues?
15:24:29FromDiscord<mratsim> ....
15:24:32leorize.......
15:24:35leorizeare you for real?
15:24:42FromDiscord<mratsim> it's features here
15:24:47FromDiscord<mratsim> it's not
15:24:50FromDiscord<mratsim> it's security
15:25:28FromDiscord<mratsim> If you don't have the time to address those issues in 6 months, I'm sure you can talk to some select people in the community to see if they have the time to handle this
15:25:34FromDiscord<dom96> I did
15:25:40FromDiscord<dom96> I don't want to blame people
15:25:44FromDiscord<dom96> because that's not fair
15:26:06FromDiscord<dom96> But it's also not fair to name me as if I have some responsibility for Nimble when I have a full-time job that does not involve Nim at all
15:26:29leorizeif I read about nim and I see "unfixed security issue", I would run away
15:26:51FromDiscord<mratsim> You have a moral responsibility to notify people if you are too busy to maintain your library
15:26:55leorizeyou're the security contact, dom96
15:26:56FromDiscord<Rika> Well then who is responsible for nimble
15:26:59FromDiscord<dom96> Like I said, I did notify people
15:27:31FromDiscord<mratsim> I totally understand being too busy to do things, but in that case remove yourself from being a choke point
15:28:18leorizesecurity issues should be a top priority
15:28:37leorizewe have plenty of funds in opencollective
15:29:19FromDiscord<dom96> In what way am I the choke point?
15:30:02FromDiscord<Rika> you're the contact, if youre too busy to tend to security issues maybe someone else should be the contact
15:30:14FromDiscord<mratsim> You're still the maintainer of nimble, if you don't have time to delegate, announce that someone should take over and also be the main security contact for it
15:30:38FromDiscord<Rika> keywords are "to tend to security issues"
15:31:00FromDiscord<Rika> its fine if you cant tend to minor or even prolly major issues in a while, but security issues are critical
15:31:24FromDiscord<dom96> sure, and I was under the impression that miran/araq were on it
15:31:28FromDiscord<mratsim> This has been open for 3 years: https://github.com/nim-lang/nimble/pull/459
15:35:01FromDiscord<dom96> In fact, I just checked and I explicitly said to them "I have passed this to Andreas Rumpf"
15:35:07FromDiscord<dom96> and they agreed
15:35:10FromDiscord<dom96> so not cool to name me
15:36:33FromDiscord<Rika> you keep on passing the blame
15:36:35saemHandoff needs a confirmation from the other side, that's typical incident or security incident command.
15:36:42FromDiscord<Rika> you're still the main contributor
15:36:48FromDiscord<Rika> you should be aware of things stalling
15:37:38FromDiscord<dom96> I have done my dilligence
15:37:41FromDiscord<dom96> and the pass over was confirmed
15:39:31leorizethe only thing written in that security advisory is that they contacted dom96 on telegram and "Vendor response: unknown"
15:39:40FromDiscord<dom96> Yes, well that's not accurate
15:39:43FromDiscord<dom96> and I pm'd them to fix that
15:44:37*waleee-cl joined #nim
15:45:00FromDiscord<dom96> Like, is it that you just don't believe me? or are your expectations for volunteer open source contributors wild?
15:46:14*aeverr joined #nim
15:46:22FromDiscord<mratsim> Expecting that something happens in 6 months for a critical security issue is not wild.
15:46:35saemThe exception people are taking here is that in other matters you're seen as acting as authority -- PRs approvals or various other access you invoke. It's demonstrably blocking progress in this and other areas as had been pointed out on numerous occasions, yet when something urgent came along all of that seemed to have gone unexercised.
15:47:03FromDiscord<mratsim> It also reflects badly on how Nim core contributors think about security and kind of defeat the promotion that we did on Nim.
15:47:45*zedeus quit (Ping timeout: 240 seconds)
15:48:18*zedeus joined #nim
15:48:51FromDiscord<dom96> saem: In the past I have been far more strict with PR approvals, I agree with that. I do still share my thoughts but I very rarely outright block changes.
15:49:04FromDiscord<dom96> In this particular instance I haven't blocked anything.
15:49:59FromDiscord<mratsim> The thing is, everyone needs to realize that since Nim 1.0, Nim isn't a playground anymore
15:50:10FromDiscord<mratsim> you are very vocal about backwards incompatible change
15:50:10FromDiscord<dom96> And if there are areas where you think I am still blocking progress I am more than willing to discuss it and address that.
15:50:40FromDiscord<mratsim> I don't understand why you don't take security flaws with minimal reproducible examples seriously.
15:51:11FromDiscord<mratsim> "don't break things" also means "don't let things stay broken"
15:51:22FromDiscord<dom96> yes, but I'm never against backwards incompatible changes that fix security issues
15:51:47FromDiscord<mratsim> I'm not criticizing your stance about backward compatible changes here
15:52:17FromDiscord<dom96> FWIW they have changed the disclosure timeline
15:52:22FromDiscord<mratsim> But the fact that you should handle security issues with as much care if not more as backwards incompaatible changes
15:53:14FromDiscord<konsumlamm> the issue is not you blocking anything, but security issues not being fixed
15:53:58FromDiscord<dom96> Can you see how getting piled on by a bunch of people is from my perspective?
15:54:18FromDiscord<dom96> When I believe I have done a lot to make sure the people who have the time are aware of this and work towards fixing it?
15:54:25FromDiscord<mratsim> Can you see how everyone in the Nim community being infected by some Trojan horse is?
15:54:35saemYou have authority in this community, no one is punching down here.
15:57:01FromDiscord<mratsim> I can't believe I'm trying to build advanced cryptographic libraries for Nim when basic security: "follow through with CVE" is not dealt with
15:58:13planetis[m]i totally agree with mratsim, PRs stall waiting doms approval all the time
15:58:24leorizeping Araq for some perspective on this issue
15:59:10FromDiscord<Rika> but in the case of the CVE its not dom stalling it is it?
15:59:17leorize@Araq <- since the gitter bot don't auto tag after awhile
16:00:11FromDiscord<dom96> saem: maybe I have more authority than I feel then, but I'm not saying this shouldn't have been fixed, it definitely should have
16:00:22FromDiscord<mratsim> There are multiple issues here: the certificate checking with a PR open for 3 years, but also the remote code execution, which has no fix.
16:01:04FromDiscord<dom96> In a professional setting you wouldn't pile on a single person in public, even if it is clear they fucked up
16:01:12FromDiscord<Goel> Hierarchy problem here probably
16:01:26*a_chou joined #nim
16:02:14FromDiscord<mratsim> Nim is not a playground anymore as I said. In a professional settings, you take security issues seriously
16:02:28FromDiscord<mratsim> and you delegate or step down when you don't have time to handle things
16:03:37FromDiscord<mratsim> you don't shift the blame to Araq and Federico either, and say it's not my fault. You apologize, talk with them, put out a post-mortem with next steps
16:03:47FromDiscord<zetashift> The delegating wasn't handled well, but why is that certificate PR failing the CI so much damn
16:04:16FromDiscord<mratsim> because those are things that destroy reputations about everything the community has been trying to build
16:04:48FromDiscord<dom96> Well, from my perspective I gave an update of this from my perspective
16:04:57FromDiscord<dom96> and all I got was the insinuation of "why didn't you fix it?"
16:05:17FromDiscord<mratsim> Why nothing happened in 6 months
16:05:22FromDiscord<mratsim> not an insinuation, a real question
16:05:25FromDiscord<dom96> I never blamed Araq or Federico
16:05:27FromDiscord<zetashift> From what I've read I don't think that Dom was trying to shift blame on araq but people wanted answers.
16:06:08FromDiscord<zetashift> Bbl I hope the team comes together to fix the issues!
16:06:29FromDiscord<mratsim> Anyway, I've said what i wanted to say.
16:07:25FromDiscord<Goel> Even if they team comes together to fix it, a same scenario will occur in the future, because the root of the problem won't even be touched
16:07:56FromDiscord<mratsim> if we need to replace Nim's http libraries, note that Consensys Diligence also audit Status' and all security issues were fixed.
16:09:11FromDiscord<Goel> (edit) "they" => "their"
16:09:33FromDiscord<zetashift> This is a good reason for a postmortem
16:10:15FromDiscord<dom96> Yes, a postmortem is a great idea.
16:11:29FromGitter<Araq> we did take the security issues seriously, did bugfixes and backported the bugfixes
16:12:15FromGitter<Araq> apparently not everything was fixed. we're investigating and will fix the others too
16:12:46FromGitter<Araq> apart from that I don't know what to say. And yes, I do apologize.
16:13:49FromDiscord<zetashift> The article said `httpClient()` was fixed in 1.4 no? the rest is nimble not being compiled with an updated nim and that `doCmd` and the ssl PR
16:14:04FromDiscord<zetashift> (still major issues ofcourse)
16:14:12FromDiscord<Goel> That is the problem "apparently" There must be someone, some figure of the main Team of Nim that should just have that as a priority, for example in this case the Security field
16:14:56leorizethe fact that it's easier to use the unsafe shell-based osproc interface is one of the reason why I wrote nim-sys/exec :P
16:16:17FromDiscord<Goel> (edit) That is the problem "apparently" There must be someone, some figure of the main Team of Nim that should just have that as a priority, for example in this case the Security field. In my opinion if that was the case, the real and final solution on those security issues could have been adressed and fixed months ago
16:16:40*smitop joined #nim
16:16:59FromGitter<Araq> the problem is that we did fix them months ago
16:17:57stefantalpalaruAll this criticism is focused on getting to the bottom of it, so we can fix systemic issues and be better prepared next time, so don't take it personally, dom96.
16:18:05FromGitter<Araq> you can blame me for this of course. but it's not that we didn't do anything. we did. I thought every issue has been completely addressed
16:18:41FromGitter<Araq> these bugs were prioritized
16:19:09leorizeI guess we need more personnel in the core team
16:19:58leorizedom96 is busy with his full time job
16:20:25FromGitter<Araq> that, and some issue tracker for hidden bug reports
16:20:27FromDiscord<dom96> stefantalpalaru: I don't have a problem with criticism, it's how it's delivered that I have a problem with.
16:20:33leorizeand Araq has to handle the entirety of Nim rn from what I can tell
16:20:59leorizesome extra personnel would be helpful in tracking these
16:21:33leorizeAraq: we should be able to create a private repo in nim-lang, right?
16:21:42FromGitter<Araq> that too, yes, but bugs that are not reported in the issue tracker are harder to track
16:22:03stefantalpalaruPeople being pissed that security issues are not handled properly is a good thing. I'd be worried if the opposite were true.
16:23:19FromGitter<Araq> our "Nim security Audit" channel has 5 members fwiw and Federico filled CVEs in the past
16:28:31FromGitter<Araq> @leorize Miran is involved, fulltime
16:37:51FromDiscord<dom96> I would recommend creating a working group for security issues with an official list of who’s in it. We already sort of have one. But the fact that nobody knows how to contact it is pretty bad.
16:39:46FromGitter<Araq> I'm setting up https://github.com/nim-lang/security
16:41:06*rockcavera joined #nim
16:47:44FromDiscord<lqdev> maybe a https://securitytxt.org/ ?
16:47:51federico3Araq why a repository?
16:48:13FromDiscord<mratsim> for opening private issues
16:48:13leorizeas a "hidden" bug tracker for this stuff
16:48:20FromDiscord<mratsim> to allow discussions still
16:48:38FromDiscord<Avatarfighter> Having a catalog of issues we’ve had and fixed is nice imo hopefully we’ll learn to not do them again
16:49:59FromDiscord<mratsim> Well, even if we don't do them anymore, there will inevitably be new issues. What we need is a professional way to address them.
16:50:25FromDiscord<mratsim> Even cryptographers introduce bugs in their libraries
16:51:10FromGitter<HJarausch_gitlab> I have something like ⏎ ⏎ ```var Raw: RawHeader; ⏎ readChars(MyFile, cast[array[500,char]](Raw), 0, 500)``` ⏎ ⏎ is reject: ... [https://gitter.im/nim-lang/Nim?at=601c25fe063b6c68d53b9424]
16:58:40FromGitter<haxscramper> You might need to take address of your `var raw` and pass it ro `readChars`
16:59:03FromDiscord<Avatarfighter> mratsim: of course there will be new issues I didnt mean to imply that a security tracker would magically help fix issues 😛
16:59:20FromDiscord<Avatarfighter> ^ hope that didnt sound aggressive
16:59:22FromGitter<Araq> federico3: because tracking these issues via private emails and Telegram messages is a failed experiment
17:00:18federico3yes, usually people use dedicated security trackers (that are very private)
17:00:54leorizewill we have a public statement about these issues later?
17:01:11FromGitter<Araq> now that you ask, do I have a choice? :P
17:01:45*Gustavo6046 quit (Ping timeout: 258 seconds)
17:06:14*abm quit (Quit: Leaving)
17:06:44*zedeus quit (Ping timeout: 258 seconds)
17:07:54federico3for the record, gh security advisories improved its (toy) workflow and now supports CVEs https://docs.github.com/en/github/managing-security-vulnerabilities/about-github-security-advisories
17:08:15FromGitter<HJarausch_gitlab> @haxscramper how to take the address
17:08:25FromGitter<HJarausch_gitlab> I've tried
17:10:20FromGitter<HJarausch_gitlab> I've tried ⏎ ⏎ ```cast[array[512,char]](Raw.unsafeAddr) ⏎ cast[array[512,char]](Raw).unsafeAddr``` ⏎ ⏎ but I need something to be passable to a ... [https://gitter.im/nim-lang/Nim?at=601c2a7c55359c58bf203bda]
17:13:49FromGitter<haxscramper> You can take address, cast it to different pointer and then dereference or something like that: `(cast[array[512, char]](addr raw))[]`
17:23:35*tane joined #nim
17:26:08FromDiscord<haxscramper> If I understand correctly from this issue - https://github.com/nim-lang/nimble/issues/743 , if I have some additional submodule for nimble package I have to set `srcDir` to `"."` in order for `nimble install` to clone and copy to installation directory.
17:26:28FromDiscord<haxscramper> But this breaks imports because now I have to use `src/<packagename>` when I installed
17:27:37FromDiscord<haxscramper> Is there any built-in workaround, or I need to tamper with temporary download locations and move files around manually
17:28:11FromDiscord<haxscramper> Maybe someone has an example for a nimble project that uses external git submodule as a dependency?
17:29:25FromDiscord<mratsim> I have thick skin
17:29:56FromDiscord<Avatarfighter> Like a true Frenchmen 🙂
17:30:59FromDiscord<haxscramper> Although I can do `after install` `mvDir("src/<project>", "<project>")` and `mvFile("src/<project.nim>")`
17:31:16FromDiscord<haxscramper> (edit) "`mvFile("src/<project.nim>")`" => "`mvFile("src/<project.nim>", "<project.nim>")`"
17:31:38FromDiscord<haxscramper> But this is very hacky still
17:32:11ForumUpdaterBotNew thread by Psirus: Macro beginner code review, see https://forum.nim-lang.org/t/7472
17:50:01FromDiscord<dom96> @haxscramper sounds like that bug needs to be marked high priority, unfortunately I'm not sure what I can advise. You can maybe have a look at what Nimble does with the `--debug` flag to figure out why the installation doesn't do what you expect it to do.
17:50:54FromDiscord<haxscramper> Well it's not like it is doing something unexpected with `srcDir = "."`, but it is not really convenient for submodules
17:51:19FromDiscord<haxscramper> I'm not sure how it should've worked actually
17:51:25FromDiscord<dom96> But if you're using `srcDir = "src"` then shouldn't your submodule be inside the "src" dir?
17:51:36FromDiscord<mratsim> srcDir is utterly broken
17:51:58FromDiscord<queersorceress> sent a long message, see http://ix.io/2OlG
17:52:32FromDiscord<mratsim> I don't even try to use src anymore: https://github.com/SciNim/flambeau/pull/12#pullrequestreview-583486776
17:52:48FromDiscord<mratsim> lost time on it once again today
17:53:00FromDiscord<haxscramper> Actually yes, though I need to move submodule to `src/` so I would go with `mvFile` for now
17:53:31FromDiscord<dom96> Why do you need to move it?
17:54:22FromDiscord<dom96> @mratsim since Nimble isn't at 1.0 yet there is the opportunity to overhaul it
17:54:54FromDiscord<haxscramper> I either put it in `src/` and don't touch `srcDir`, or put submodule on toplevel and use `srcDir = "."`
17:54:54FromDiscord<dom96> then again, I can see breaking multiple packages because of changes to this being upsetting anyway
17:54:58FromDiscord<haxscramper> And I've done latter
17:55:56FromDiscord<mratsim> sure, but we had tons of RFC for package structure so far. People have created nimble alternatives left and right, I think we have consensys but we need someone to write the code.
17:56:03FromDiscord<mratsim> consensus
17:56:37FromDiscord<mratsim> similarly task level dependencies would be useful so that you can for example import GMP only when you want to test against GMP.
17:57:01FromDiscord<mratsim> that's also why I created a RFC for a focus on developer tools
17:57:04FromDiscord<SneakyBaguette> Shouldn't passing the package manager in 1.0 part of the tooling roadmap ? A package manager is a pretty important tool
17:57:28FromDiscord<mratsim> 1.0 is just symbolic
17:57:33FromDiscord<mratsim> but yes
17:58:06FromDiscord<mratsim> we worked a lot on the compiler, we need an ecosystem now
17:58:17FromDiscord<mratsim> and tooling is like the fertilizer while the compiler is the ground
17:59:19*NimBot joined #nim
17:59:50FromDiscord<haxscramper> I thought about creating something like "what stops you from contributing to compiler" at some point
18:00:14FromDiscord<haxscramper> Because I'm not a compiler developer, I just happened to read some books
18:00:26FromDiscord<ElegantBeef> I cannot read
18:00:26FromDiscord<haxscramper> And nim compiler is not really that convoluted
18:00:58FromDiscord<mratsim> cc @Clonkk discussion about nimble src/
18:01:10FromDiscord<haxscramper> So maybe increasing community engagement with development process could relieve some burden from core developers, ... theoretically
18:01:40FromDiscord<mratsim> in practice, until the first new joiners can take care of the new newbies, the burden actually increases
18:02:43FromDiscord<haxscramper> that is true
18:02:44FromDiscord<mratsim> also you likely need area of focus
18:03:03FromDiscord<mratsim> For example cooldome handles everything destructors and so that removes all that load from Araq
18:04:40FromDiscord<konsumlamm> btw @dom96 are there any concrete plans to make a default build bin directory?
18:05:00*Gustavo6046 joined #nim
18:05:39FromDiscord<dom96> Nothing concrete, last I've seen there were discussions about putting the build artifacts of `nimble test` somewhere by default.
18:10:02FromDiscord<dom96> Hm, I should get in touch with shashlick again to see what his plans are for Nimble
18:10:08*hyiltiz quit (Ping timeout: 256 seconds)
18:10:30*hyiltiz joined #nim
18:13:20FromDiscord<mratsim> I feel like most project use either `build` or some !. gitignore trick
18:13:29FromDiscord<mratsim> (edit) "!." => "!\.\"
18:15:08FromDiscord<queersorceress> is there a proper example of how to use `--clib` so that it doesn't prefix the nimble project src directory? is there a way to fix the ordering, or do i have to use the more fragile method of linking by passing flags directly to the linker itself?
18:16:43FromDiscord<mratsim> @queersorceress I use clibdir + passL here: https://github.com/mratsim/Arraymancer/blob/master/nim.cfg#L53-L57
18:17:17FromDiscord<mratsim> cincludes here: https://github.com/mratsim/Arraymancer/blob/master/nim.cfg#L28-L30
18:17:47FromDiscord<mratsim> Why do you say that passing flags to the linked is fragile?
18:17:48FromDiscord<queersorceress> yeah, like i mentioned, using `clibdir`, `cincludes` both work with `passL`, but doesn't work with `clib` which seems to be the correct way of doing things now.
18:18:02FromDiscord<mratsim> you can use "localPassC" to scope them to the local C file
18:18:16FromDiscord<mratsim> ah
18:18:27FromDiscord<queersorceress> because it depends on the linker recognizing the specific flags i'm passing
18:18:38FromDiscord<mratsim> never used "clib"
18:19:42FromDiscord<queersorceress> yes, the vast majority of linkers will recognize `-l` and `-L` as the correct things, but i'd rather not be specifying those things if i don't have to -- which seems like i shouldn't given the existence of the `clib` flag in the first place.
18:20:22FromDiscord<queersorceress> but the behavior and ordering of these flags aren't respected and i'm trying to work out if i need to file a bug report on this
18:20:46FromDiscord<mratsim> you can
18:21:09FromDiscord<mratsim> we add issue with --std=gnu++14 being at the wrong place in the past
18:21:20FromDiscord<mratsim> I should request to change it to c++14 btw
18:21:46FromDiscord<queersorceress> in this case, it's the problem of specifying the library name prior to specifying search paths.
18:21:53FromDiscord<garett> Hello folks. I'm looking at sdl.nim, just to get a feel for it, and I would like to better understand why some scopes, like `else:` use a colon, and some scopes like `type` do not.
18:22:33FromDiscord<ElegantBeef> One is flow control one is declarative
18:22:45FromDiscord<ElegantBeef> `var`, `let`, `const` do not use a colon
18:22:55FromDiscord<garett> Ok, so control flow blocks will all have a colon, and declaration blocks will not
18:23:23FromDiscord<garett> I wonder whether it is necessary syntactically...
18:23:30FromDiscord<ElegantBeef> Which one?
18:23:42FromDiscord<garett> The colon. Maybe just there for Pythonic appeal?
18:23:43FromDiscord<ElegantBeef> Declaration blocks dont create scope
18:23:58FromDiscord<ElegantBeef> Yes the colon is needed for one liners
18:24:08FromDiscord<queersorceress> @garett have you read the language manual?
18:24:26FromDiscord<ElegantBeef> `if thingy dothing()` `if thingy: doThing()` one of those two cannot be certain where the condition ends
18:24:49FromDiscord<garett> I have skimmed the manual, but I wasn't specifically looking for the need for a colon at the time.
18:25:02FromDiscord<garett> @ElegantBeef Thanks 🙂
18:25:35FromDiscord<queersorceress> i would highly recommend it, as it explains these types of scopes
18:25:36FromDiscord<garett> So in the case of `else:` the colon is just for symmetry with other constructs that require a conditional clause
18:25:47*smitop quit (Quit: Connection closed for inactivity)
18:25:55FromDiscord<garett> @queersorceress thanks, I will spend more time with it
18:35:31FromDiscord<queersorceress> you should probably be given the option to choose between which stdlib to use rather than it being hard-coded tbh.
18:37:30FromDiscord<mratsim> it's technically not hardcoded
18:37:37FromDiscord<mratsim> it's in the global nim.cfg
18:37:53FromDiscord<mratsim> but changing it would requires users to edit it which is not really user friendly
18:38:09FromDiscord<mratsim> anyway I raised my issue
18:51:48*aeverr_ joined #nim
18:51:55*aeverr quit (Remote host closed the connection)
18:51:55*dv^_^969 joined #nim
18:52:03*letto quit (Remote host closed the connection)
18:52:28*letto joined #nim
18:52:59*dv^_^96 quit (Ping timeout: 276 seconds)
19:03:22*opal quit (Remote host closed the connection)
19:03:48*opal joined #nim
19:09:37*natrys joined #nim
19:42:14*PMunch joined #nim
19:42:36FromDiscord<queersorceress> i filed a new issue for the bug looks like the issue was more the prefixed path rather than the ordering. glad i have a work-around for now, but this is annoying. looks like it is a compiler issue rather than something that nimble was doing for me.
19:51:23*PMunch quit (Quit: leaving)
19:51:46*PMunch joined #nim
19:56:54FromDiscord<haxscramper> How to debug dependency resolution for nimble installation? I have a package with version `v0.9.16` (latest), and all other packages require version with `>=`, so there is no unsolvable conflict
19:57:02*Gustavo6046 quit (Ping timeout: 260 seconds)
19:57:09*Gustavo6046_ joined #nim
19:57:09FromDiscord<haxscramper> But `nimble install` fails on first try
19:57:14FromDiscord<haxscramper> And succedes on second
19:57:44FromDiscord<mratsim> modern package managers use a theorem prover
19:58:05FromDiscord<haxscramper> and nimble uses ... ?
19:59:06*Gustavo6046_ is now known as Gustavo6046
19:59:11FromDiscord<mratsim> https://news.ycombinator.com/item?id=21696363
19:59:17FromDiscord<mratsim> nimble uses homegrown solution
19:59:52*Jesin joined #nim
20:00:02FromDiscord<haxscramper> IIRC we have z3 wrappers (for drnim, but still). Is this applicable for dependency resolution?
20:00:18FromDiscord<mratsim> gentoo also fails: https://forums.gentoo.org/viewtopic-t-1074202-start-0.html
20:00:28federico3a full theorem prover sounds really overkill
20:00:35FromDiscord<mratsim> yes if we have Z3 we might as well use it
20:01:03FromDiscord<mratsim> if we already use it for DrNim it's a sunk cost
20:01:08FromDiscord<mratsim> if we only use it for Nimble yes
20:01:27federico3is it shipped with the compiler?
20:01:49FromDiscord<mratsim> this is a good writeup: https://www.anaconda.com/blog/understanding-and-improving-condas-performance
20:02:45FromDiscord<haxscramper> https://github.com/nim-lang/Nim/blob/6f1289b80ccf599008368b121d874b4ce4717fc6/koch.nim#L495
20:02:52FromDiscord<mratsim> And the team behind mamba reused the solver from Opensuse: https://wolfv.medium.com/making-conda-fast-again-4da4debfb3b7
20:02:58FromDiscord<haxscramper> It is already a dependency for a compiler from what I can tell
20:03:09federico3so no
20:03:16FromDiscord<haxscramper> why?
20:03:26FromDiscord<haxscramper> it is a dependency for drnim already
20:03:39FromDiscord<haxscramper> so it is not like we will introduce new dependencies
20:04:13federico3not on most distributions
20:04:33FromDiscord<mratsim> anyway I can write like 20 lines about dealing with the problem in a sane way pointing to COnda/mamba and potnetial long-term solution using either Z3 or OpenSuse libsolv
20:04:35FromDiscord<haxscramper> we can do it on most distributions then
20:05:10federico3I can look at shipping it
20:06:07FromDiscord<mratsim> libsolve APIs have been tuned to dependency resolutions
20:06:20FromDiscord<mratsim> so no AST to learn or SAT notations
20:06:29federico3but it should be an optional dependency
20:10:57FromDiscord<haxscramper> I would imagine introducing new dependency will have some additional resistance, while `z3` is already partially shipped, so it won't have such issues.
20:11:12leorizehaxscramper: drnim is not built, ever
20:11:32FromDiscord<haxscramper> yes, I know it is not being actively worked on
20:12:02FromDiscord<haxscramper> I'm talking about precedent of using z3 as direct dependency in core tooling
20:13:23*Gustavo6046_ joined #nim
20:13:33*Gustavo6046 quit (Read error: Connection reset by peer)
20:14:14federico3if it's a runtime dependency only for "nimble install" and drnim it's probably ok
20:15:16*Gustavo6046_ is now known as Gustavo6046
20:16:59FromDiscord<haxscramper> For now, I will just do `nimble build -y || nimble build -y`, but I will look into z3 later, though I need to spend some time getting familiar with general concept etc.
20:20:44FromDiscord<haxscramper> What is the recommended way of creating build binaries from `nimble build`?
20:23:14FromDiscord<mratsim> recap so it isn't lost: https://github.com/nim-lang/nimble/issues/890
20:23:28FromDiscord<haxscramper> I mean creating build artifacts for CI environment
20:26:37leorizedepends on what you want
20:30:15leorizedo you want the binaries to be run on all os or what?
20:30:33FromDiscord<haxscramper> Actually no, I'm just an idiot - I used `actions/upload-artifact@v2` and then tried running artifact directly, but forgot it is zipped
20:30:48FromDiscord<haxscramper> But I just wanted to do `nimble build` and then ship generated binary
20:31:11FromDiscord<haxscramper> Which is exactly what I got actually, so nevermind the question
20:33:37leorizejust be careful of your build env if you want the binary to run everywhere
20:34:51FromDiscord<haxscramper> Yes, I already found out about it
20:35:22FromDiscord<haxscramper> `getCurrentCompilerExe()` is a compile-time `==` binary does not work anywhere but `CI`
20:39:08leorizethis is why we should never got that api...
20:39:13leorizepeople abuse it so much
20:42:19FromDiscord<haxscramper> It is certainly quite confusing
20:45:16leorizethere should be a warning when used in a runtime context
20:45:25*liblq-dev quit (Ping timeout: 276 seconds)
20:46:32*liblq-dev joined #nim
20:47:44FromDiscord<mratsim> like {.compileTime.} var
20:52:25*a_chou quit (Ping timeout: 240 seconds)
21:04:19FromDiscord<haxscramper> @Yardanico I decided to make a push and getting some pre-pre-pre-alpha version for `haxdoc` in CI, so you can try it out now by either building directly, or downloading from CI https://github.com/haxscramper/haxdoc/actions
21:05:09FromDiscord<haxscramper> Right now it just allows to create sourcetrail database for compilation for a single file `./haxdoc trail file.nim` - it indexes all imported modules, symbols in them etc. and creates database file that you can view using sourcetrail
21:05:27FromDiscord<haxscramper> Callgraph, field dependencies, enum uses etc.
21:06:24FromDiscord<ElegantBeef> Is this an alternative implementation to `nimdoc`?
21:06:51FromDiscord<ElegantBeef> If so ensure there is a subtitle of the import path to save braincells 😄
21:07:25FromDiscord<haxscramper> Yes, it will eventually support all nimdoc features
21:08:00FromDiscord<haxscramper> sent a code paste, see https://play.nim-lang.org/#ix=2OmI
21:08:15FromDiscord<haxscramper> Example file + callgraph/field use etc.
21:09:05FromDiscord<haxscramper> For the start I decided to go with this one, because I needed to dig around compiler a lot
21:09:55FromDiscord<haxscramper> It is insanely buggy of course, but still
21:10:11FromDiscord<haxscramper> It allows drilling down on compilcated callgraphs so much faster
21:10:17FromDiscord<ElegantBeef> I'm too accepting of the current docs, since the biggest problem imo is the lack of a `std/modulename` at the top of the file 😄
21:10:55FromDiscord<haxscramper> For current docs I have an opinion
21:11:10FromDiscord<haxscramper> That they can be improved, at least from basic design perspective
21:11:35FromDiscord<haxscramper> And `nim doc` itself is really bad
21:15:43*Jesin quit (Quit: Leaving)
21:22:35FromDiscord<exelotl> I'm excited for nim doc alternatives
21:22:48*natrys quit (Ping timeout: 246 seconds)
21:23:16FromDiscord<exelotl> The current docgen is not human friendly enough, though I find it hard to pinpoint exact areas for improvement
21:24:51FromDiscord<haxscramper> I think that adapting some features from doxygen (grouping based on types instead of just `procs`/`iterators` + alphabetic numbering)
21:25:18FromDiscord<haxscramper> Better support for things like `@arg{}`
21:25:38FromDiscord<haxscramper> More emphathis in documentation of procedure effects - this is very nice feature of nim
21:25:56FromDiscord<haxscramper> That is usually hidden with `{...}`
21:26:08FromDiscord<mratsim> exceptions thrown are really importnt for API
21:26:09FromDiscord<exelotl> I'd love custom headings and being able to choose to put symbols underneath them (and interleave them with prose)
21:26:35FromDiscord<haxscramper> Yes, exceptions. Basically anything that we can know about a function must be shown nicely
21:27:46FromDiscord<haxscramper> I'm planning to integrate org-mode into documentation generator, though it is more focused on writing external articles linking them in together in docs
21:28:02*Jesin joined #nim
21:28:08FromDiscord<haxscramper> Like https://doc.cgal.org/latest/Manual/tutorial_hello_world.html#intro_Three
21:28:09FromDiscord<mratsim> that's fine, even if I have a mini mdbook out put that would be great
21:28:52FromDiscord<mratsim> This made HN top 10 a day ago again btw: https://documentation.divio.com/
21:29:08FromDiscord<haxscramper> again? I think I've seen it at least four times in total
21:29:12FromDiscord<haxscramper> But the article is great
21:29:16FromDiscord<mratsim> we are using it throughough our code: https://nimbus.guide/
21:29:36FromDiscord<haxscramper> I'm not sure I fully get all ideas, but it really inspired some design decisions
21:29:41FromDiscord<mratsim> For API in particular you Nim good Nim itnegration: https://nimbus.guide/api.html
21:30:34FromDiscord<mratsim> right now our descriptions are poor
21:31:01FromDiscord<mratsim> (even if we had library APi instead of RPC)
21:32:17FromDiscord<haxscramper> org-mode in itself is all about literate programming and "how-to" & "examples" part. "reference documentation" is more about nicely laying out documentation comments, providing links, serach and making things discoverable and easy to search for
21:33:27FromDiscord<haxscramper> Good unit tests are also about "how-to" and "examples" - I hope it can be relatively clear of what I mean by this from my pattern matching implementation
21:33:58FromDiscord<haxscramper> But I want to make such tests even more useful as learning material
21:35:43*natrys joined #nim
21:35:49*a_chou joined #nim
21:36:59*liblq-dev quit (Quit: WeeChat 3.0)
21:38:01*natrys quit (Client Quit)
21:38:56*narimiran quit (Ping timeout: 240 seconds)
21:50:13*PMunch quit (Quit: leaving)
21:57:00FromDiscord<Goel> Is it possible to define a variabile like var x = " "
21:57:14FromDiscord<haxscramper> !eval var x = " "
21:57:16NimBot<no output>
21:57:19FromDiscord<Goel> I mean its considered a string with a whitespace as value?
21:57:26FromDiscord<haxscramper> yes
21:57:47FromDiscord<haxscramper> !eval import sequtils; var x = " "; echo toSeq(x)
21:57:50NimBot@[' ']
21:59:47leorize!eval var x = " "; echo @x
21:59:50NimBot@[' ']
22:03:18FromDiscord<Goel> sent a long message, see https://paste.rs/mVL
22:04:04*superbia joined #nim
22:04:14FromDiscord<Goel> (edit) "http://ix.io/2OmX" => "https://paste.rs/QeG"
22:04:41FromDiscord<ElegantBeef> "without external libraries" does that mean no stdlib or no nimble packages?
22:04:50*superbia quit (Client Quit)
22:04:53FromDiscord<Goel> just with the stdlib
22:05:10FromDiscord<ElegantBeef> `import strutils; write("file",input.split())`
22:05:12FromDiscord<ElegantBeef> QED
22:05:19*jjido joined #nim
22:05:23FromDiscord<Clyybber> @timotheecour ping
22:05:44FromDiscord<ElegantBeef> Clyybber you lost your green name?
22:05:45FromDiscord<Goel> -disappointed- Thanks Nim
22:05:51FromDiscord<Clyybber> colors were changed
22:06:01FromDiscord<ElegantBeef> Why are you disappointed?
22:06:02FromDiscord<Clyybber> shadow government
22:06:45FromDiscord<ElegantBeef> You can of course do it without using any modules as i do here(aside from the character sets from strutils) https://github.com/beef331/strviewutils/blob/master/src/strviewutils.nim
22:08:16FromDiscord<Goel> @ElegantBeef I'll have a look tomorrow im leaving for now but thanks (and i was kidding, that was a good way to disappoint me)
22:08:34FromDiscord<ElegantBeef> ah
22:08:54FromDiscord<ElegantBeef> Thought the implication was that i cause i imported strutils you were sad with the solution i offered
22:22:23*tane quit (Quit: Leaving)
22:22:30*haxscramper quit (Remote host closed the connection)
22:22:55*haxscramper joined #nim
22:25:27*haxscramper quit (Remote host closed the connection)
22:26:16*fredrikhr quit (Ping timeout: 256 seconds)
22:39:44*clyybber quit (Quit: WeeChat 3.0)
22:46:40FromDiscord<dom96> I’ve made all the role colours the same, I think it’s the right move to make us more egalitarian.
22:50:01FromDiscord<ache of head> 🤔
22:55:26FromDiscord<ElegantBeef> But now how am i supposed to know where it's safe to break the rules?!
22:58:38*a_chou quit (Quit: a_chou)
23:00:18FromDiscord<SivadNai> who wants to be safe
23:02:37FromDiscord<ElegantBeef> Safes
23:03:20FromGitter<timotheecour> @Clyybber you pinged me?
23:03:33FromDiscord<ElegantBeef> Lol you just pinged someone named ed
23:04:08FromDiscord<Clyybber> @timotheecour Oh yeah; I wanted to ask why wrapnils are not options in the first place
23:08:15FromGitter<timotheecour> because options are more cumbersome to use in most cases: usually the default value `default(T)` is enough for user code to handle, eg: ⏎ ⏎ `echo (?.foo.bar[].baz, ?n.typ.sym.name.s)` is much simpler than dealing with options type for which `get` raises
23:08:51FromGitter<timotheecour> (but in the cases where you do need to distinguish between default(T) and isSome, you have `??.` from https://github.com/nim-lang/Nim/pull/16931)
23:09:15ForumUpdaterBotNew thread by Filcuc: Traits or macros for inspecting proc/lambda/functor type, see https://forum.nim-lang.org/t/7473
23:09:52FromGitter<timotheecour> now that you’re mentioning this though, I should probably make `get` raise in https://github.com/nim-lang/Nim/pull/16931 (with also a get overload that doesn’t raise and takes a default value)
23:10:27FromDiscord<Clyybber> @timotheecour I meant internally, they could be options no?
23:11:48FromGitter<timotheecour> I had thought about that; it’s plausible but i wanted something lighter (options imports typetraits and isn’t small) ; but it’s debatable, yes
23:12:32FromDiscord<Clyybber> Hmm, I think we should really try to base it on options
23:12:49FromDiscord<Clyybber> else we could end up duplicating the whole options api for WrapNil
23:14:06FromDiscord<Clyybber> and the typetraits import isn't really that bad; all in all I think options.nim is still really small
23:14:26FromDiscord<Clyybber> but I'm not arguing for putting wrapnils.nim into options.nim
23:14:29FromGitter<timotheecour> i’m not against the idea
23:14:32FromDiscord<Clyybber> just making wrapnils import options.nim
23:15:22FromDiscord<Clyybber> @timotheecour Ah cool, I think it'd be a good approach to https://github.com/nim-lang/Nim/pull/16931
23:16:00FromGitter<timotheecour> 1 other option is: ⏎ lib/std/private/options_impl.nim that defines the common thing including Option type, which then gets imported/re-exported by std/options and also used by std/wrapnils
23:16:12FromDiscord<Clyybber> yeah; I thought about that too
23:16:23FromDiscord<Clyybber> but I think it's fine if we import options.nim
23:16:35FromDiscord<Clyybber> because options is fairly small already and won't grow further
23:17:15FromDiscord<Clyybber> but if it does grow too much in the future we can of course do that options_impl thing
23:17:33FromGitter<timotheecour> Ok, i marked PR as draft to explore this
23:17:50FromDiscord<Clyybber> Cool, thanks
23:18:08FromDiscord<Clyybber> for replying :)
23:18:13FromGitter<timotheecour> no :)
23:18:21FromGitter<timotheecour> np
23:18:25FromDiscord<Clyybber> :D
23:18:42FromDiscord<ElegantBeef> Then there is me going "I'd prefer if we had `noNils` aliased to `?.` and `nilOption` to `??.`" 😄
23:18:46FromDiscord<Clyybber> I find gitter/irc to be much better for quickly exploring ideas/directions as opposed to github issues
23:19:05FromDiscord<Clyybber> or maybe I should put a stone on my F5 key
23:19:21FromDiscord<ElegantBeef> Just solder it together
23:19:26FromDiscord<Clyybber> lol
23:19:41FromDiscord<Clyybber> oh, I think github actually autoupdates nowadays
23:19:45FromDiscord<Clyybber> but it's brittle
23:20:11FromDiscord<ElegantBeef> Github's auto update is as infrequent as someone that eats a block of cheese daily
23:20:48FromDiscord<Clyybber> suspiciously specific
23:21:13FromGitter<timotheecour> lol how did you know
23:21:42FromDiscord<ElegantBeef> the two Es it's your screaming for it to be over
23:23:05FromGitter<timotheecour> touché, ElegantBéef
23:24:26FromDiscord<ElegantBeef> In that sentence you needed to write Boeuf, but my comedic stylings are lacking
23:25:11FromDiscord<dom96> timotheecour: nice to see you around here more often these days 🙂
23:25:28FromDiscord<ElegantBeef> He's only here cause he likes to read my shitty jokes
23:25:40FromDiscord<Clyybber> lol
23:25:46FromGitter<timotheecour> bof, bof.
23:26:07FromDiscord<ElegantBeef> Just so happens my jokes and my PR's share the same quality
23:28:37*Vladar quit (Quit: Leaving)
23:31:41FromGitter<timotheecour> @dom96 likewise; this chat seems to have become more civil recently
23:32:30FromDiscord<ElegantBeef> Subtle
23:41:22FromDiscord<dom96> Glad to hear that 🙂
23:47:10federico3how comes?
23:50:11*stefantalpalaru quit (Ping timeout: 272 seconds)
23:50:39*rockcavera quit (Remote host closed the connection)
23:56:15FromDiscord<konsumlamm> @dom96 regarding compile options for `nimble run`: there is a doc comment explicitly saying that the options before the command name ("run") are the compile flags and the ones after are the program args. should i still do a PR to change that to "everything before the executable name or -- is a compile flag"?