<< 19-03-2020 >>
00:06:01*krux02_ joined #nim
00:08:34*krux02 quit (Ping timeout: 246 seconds)
00:20:15*blackbeard420 quit (Quit: ZNC 1.7.5 - https://znc.in)
00:20:33*blackbeard420 joined #nim
00:31:38*voltist joined #nim
00:35:18voltistIs there a good source of documentation for Nim's locks module beyond https://nim-lang.org/docs/locks.html?
00:39:05rayman22201the Nim in Action book: https://livebook.manning.com/book/nim-in-action/chapter-6/239
00:39:10rayman22201but what question do you have?
00:39:19leorizerelated: https://nim-lang.org/docs/manual_experimental.html#guards-and-locks
00:39:46voltistThanks, ill have a look at those
00:40:07voltistI'm basically just trying to understand how to use it
00:54:55*blueberrypie quit (Quit: Ping timeout (120 seconds))
00:55:28*blueberrypie joined #nim
01:01:58*krux02_ quit (Remote host closed the connection)
01:04:41*sealmove quit (Quit: WeeChat 2.7.1)
01:07:46*dadada quit (Ping timeout: 256 seconds)
01:08:00rayman22201@axion and @Rika, I got a mostly working version of the genComponentWise macro: https://play.nim-lang.org/#ix=2eDI
01:09:21rayman22201bad news: it requires the experimental pragma. I don't see a way around that. Other bad news, I think Nim has a bug where it "loses" the default value to extra params. I'm trying to create a minimal repo so I can report that.
01:09:33*dadada joined #nim
01:09:57*dadada is now known as Guest39909
01:23:47*zielmicha__ quit (Read error: Connection reset by peer)
01:23:55*zielmicha__ joined #nim
01:24:12*dwdv quit (Ping timeout: 256 seconds)
01:38:36voltistIs there a way to make the compiler give more information as to why a proc is not GC safe?
01:38:57voltistAs in what variables it is trying to access
01:40:24leorizethere aren't any, I think
01:40:39leorizeone day --gc:arc will be the default and you won't have to deal with all this gcsafe thing
01:40:58voltistWhat does --gc:arc do?
01:41:10leorize~arc
01:41:11disbotarc: 11a new memory manager for Nim; see https://forum.nim-lang.org/t/5734
01:43:32rayman22201bug reported: https://github.com/nim-lang/Nim/issues/13688
01:43:35disbot➥ Cannot retrieve the default paramater value of a proc from inside a macro ; snippet at 12https://play.nim-lang.org/#ix=2eDK
01:46:06voltistSo how could --gc:arc remove the need to deal with gcsafe stuff?
01:46:33leorizebecause it uses a shared heap
01:46:34rayman22201all threads share a heap with --gc:arc,
01:46:49voltistAh I see
01:47:49voltistWould that mean that var parameters would work with threads as well?
01:48:12leorizeno, that's a different issue
01:49:17voltistFair enough. Is FlowVar still needed with --gc:arc?
01:49:37leorizeyes :P
01:50:14leorizethough the data passing can/will be made lighter as the "copy everything" restriction won't hold anymore
01:50:22voltistCool
01:51:15rayman22201FlowVar is a way for threads to talk to each other and let each other know they are done. It's a signaling mechanism.
01:52:25voltistYeah got it, I just thought this new system might come with some convenience procs/templates/macros to make it all a bit more tidy
01:52:46voltistI'm going to live life on the edge and switch to devel so I can try --gc:arc
01:55:28rayman22201🎉🎉🎉
01:56:35*NimBot joined #nim
02:04:06voltistHmmm https://hastebin.com/mokimadore.makefile
02:04:43voltistIdk why that came up as .makefile
02:04:55voltistBut it has Nim compiler output in it
02:05:28*sz0 quit (Quit: Connection closed for inactivity)
02:05:36voltistAny thoughts on the error? I was using --gc:arc
02:08:07FromDiscord<slymilano> I install Nim using choosenim on windows, choosenim-0.6.0_windows_amd64.zip - when I run `nim -v` I get Nim Compiler Version 1.0.6 [Windows: i386] - so I can't compile because of the `error: size of array 'Nim_and_C_compiler_disagree_on_target_architecture' is negative` error. How can I install Nim 64 bits compiler so it works?
02:10:29leorize!repo threadpools
02:10:31disbothttps://github.com/yglukhov/threadpools -- 9threadpools: 11 15 15⭐ 7🍴
02:10:43leorizevoltist: I'd advise you to use this instead ^
02:10:51leorizeit's the threadpool that actually works
02:11:32voltistHuh ok, why is it off in a nondescript repo rather than the standard library?
02:12:03leorizethe author didn't want to merge this because they feel that they could do it better
02:12:09leorizebut as of now it's the best :P
02:12:30leorizewell the best that works with the gc
02:12:36leorize!repo weave
02:12:37disbothttps://github.com/mratsim/weave -- 9weave: 11A state-of-the-art multithreading runtime: message-passing based, fast, scalable, ultra-low overhead 15 131⭐ 9🍴
02:13:59leorize^ that one is the best
02:14:25voltistOooo ill try that out
02:15:42leorize@mratsim wrote that it's not GC-tested (yet), though --gc:arc might change this
02:16:54voltistI shouldn't have to worry too much for my application
02:20:48voltistDoes weave work with var parameters?
02:21:06leorizevar parameters can never be passed to thread
02:21:12leorizethis is by design, unfortunately
02:21:45leorizesince the parameter might went out of scope while your thread is executing
02:22:15voltistSure ok, but at least weave is easier on the eyes
02:29:42FromGitter<timotheecour> @leorize are you here?
02:29:54leorizeyep
02:33:18FromGitter<timotheecour> so i think your changes to .gitattributes in https://github.com/nim-lang/Nim/pull/13670 are causing complications for existing PR's
02:33:19disbot➥ Disable Github Actions CI
02:33:42leorizewell 4raq got rid of it
02:33:46leorizebut what was the problem?
02:34:12FromGitter<timotheecour> in latest devel: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e72da2453614f269bc8f8cd]
02:36:20leorizethat's weird
02:36:58leorizeI guess they should be put per directory
02:37:42FromGitter<timotheecour> here: https://github.com/nim-lang/Nim/issues/13690
02:37:45disbot➥ changes to gitattributes cause weird errors ; snippet at 12https://play.nim-lang.org/#ix=2eDV
02:38:11FromGitter<timotheecour> this actually affects a lot of my PR’s after I rebase, and I don’t see simple way to fix them
02:39:21leorizeare you on windows?
02:39:40FromGitter<timotheecour> OSX
02:39:59leorizehmm, git shouldn't mess with EOL on osx
02:40:21FromGitter<timotheecour> i think the problem is that these files had prexisting CRLF, and after your changes it surfaces those errors
02:41:48leorizewell just stash them and pop it after switching branch
02:42:03leorizeyou'd have thought that in 2020 tools wouldn't pay too much attention to CRLF
02:42:13*chemist69_ quit (Ping timeout: 246 seconds)
02:42:55FromGitter<timotheecour> i’m not saying your change was bad, i’m saying we need to fix https://github.com/nim-lang/Nim/issues/13690 so it doesnt’ affect ppl w weird errors when they rebase or checkout a different branch
02:42:56disbot➥ changes to gitattributes cause weird errors ; snippet at 12https://play.nim-lang.org/#ix=2eDV
02:43:10FromGitter<timotheecour> maybe the fix is to commit changes to thos 2 files wo CRLF; let me try that
02:43:54leorizeso 4raq dropped the file because git on his PC was acting weird
02:44:17*chemist69 joined #nim
02:44:35leorizemust be due to that
02:45:30voltist"Error: cannot create a flowVar of type: Worm". What about an object would make it not work here?
02:45:48disruptekworms are notoriously lazy.
02:46:42FromGitter<timotheecour> right might be due to a96842a
03:02:50FromGitter<timotheecour> @leorize git stash doesn’t help: ⏎ cat -ve tests/tools/second.nim ⏎ import tables^M$ ⏎ ^M$ ⏎ let dataEx* = {1: 2, 3: 4}.toTable^M$ [https://gitter.im/nim-lang/Nim?at=5e72e0da9b8c8a1ef3857134]
03:03:18FromGitter<timotheecour> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e72e0f6f7268f29190df0d7]
03:06:15leorizeso git stash is crlf aware, but not every other git command
03:06:32leorizemaybe you gotta ask the git experts :P
03:28:45shashlick@slymilano: what's your version of gcc?
03:31:24leorizeshashlick: do you wanna look into moving nightlies onto github actions?
03:31:41leorizecomparable speed to azure, and a ton of concurrent jobs
03:32:23FromGitter<timotheecour> actually is there a reason nightlies can’t be run alongside nim CI, to avoid weird issues where nim CI passes but nightlies (later…) fail?
03:41:09FromGitter<timotheecour> Hi @genotrance I’m not sure I understand your comment here https://github.com/nim-lang/nimble/issues/783#issuecomment-600968134 ; https://github.com/nim-lang/nimble/issues/783 is currently an issue and I’m not sure what is your alternate fix instead of https://github.com/nim-lang/nimble/pull/781
03:41:12disbot➥ show cmd used with --verbose (even on success); fix #783 ; snippet at 12https://play.nim-lang.org/#ix=2eE8
03:45:32leorizegenotrance is shashlick
03:46:10FromGitter<timotheecour> right; @shashlick see above note
03:50:02shashlicknightlies take a long time
03:50:28shashlickbut ya, it should be fine to move it
03:51:36shashlick@timotheecour - let me play with the CI and get back to you, please remove that change though
03:52:07shashlickI meant the travis.sh gist history
03:56:55*rockcavera quit (Remote host closed the connection)
03:58:34shashlickokay, please revert that change and let me know, i'll test that job and get back to you
04:00:21*muffindrake quit (Ping timeout: 272 seconds)
04:01:22FromGitter<Knaque> Hey, quick question from someone who knows basically nothing about JS. Nim's JS compilation seems... really bulky. 133 lines for the equivalent of 4 console.log()s. Is this something I need to be worried about? (In terms of speed, mainly.)
04:02:17*muffindrake joined #nim
04:03:14leorizewell there was a real world comparison somewhere on the forum
04:05:09leorizehttps://forum.nim-lang.org/t/2991#18807
04:05:16leorizethis was when the js backend was new
04:05:26leorizeso expect that things have improved since
04:05:53leorizetl;dr: fast
04:06:44FromGitter<Knaque> Sounds good to me.
04:14:29FromGitter<timotheecour> @shashlick could you convert your gist to a repo, it’s just way more standard (eg could accept PR’s, issues etc), especially since it’s used by nimble; https://gist.github.com/genotrance/fb53504a4fba88bc5201d3783df5c522/revisions has a bunch of changes so I’m not sure which one you’re referring to
04:19:01FromGitter<timotheecour> > please remove that change though ⏎ ⏎ if I remove my change, https://github.com/nim-lang/nimble/pull/781 ’s CI will fail, but I’m guessing you just need to update your gist to my version https://gist.github.com/timotheecour/fff49b1102659eedcbc2762bc201b375 ; (in any case, this should be a real git repo instead of a gist)
04:19:02disbot➥ show cmd used with --verbose (even on success); fix #783 ; snippet at 12https://play.nim-lang.org/#ix=2eE8
04:20:01*endragor joined #nim
04:20:06shashlicki want to verify that deleting the cache and running it again fixes the issue with the gist as it is
04:20:16shashlickcannot do that without you removing that change
04:20:20shashlickwill take 30 minutes to confirm
04:20:28FromGitter<timotheecour> which change?
04:20:28shashlickthe same gist is used in many repos
04:21:03FromGitter<timotheecour> I didn’t change anything, all I have are PR's
04:21:18shashlickthe choosenim $BRANCH line in your PR
04:22:09FromGitter<timotheecour> you don’t need that to test the fix, see https://github.com/nim-lang/nimble/issues/783 ⏎ ⏎ > not sure about "always" but that's my best guess: ⏎ > see #782 which really should be a noop. [https://gitter.im/nim-lang/Nim?at=5e72f371f7268f29190e1509]
04:22:12disbot➥ [CI] travis always fails for nim=#hash after the 1st run ; snippet at 12https://play.nim-lang.org/#ix=2eEg
04:23:24FromGitter<timotheecour> deleting the cache seems like the wrong fix AFAIK. IMO the better approach is to fix the gist (especially if used in other repos) as I did here https://gist.github.com/timotheecour/fff49b1102659eedcbc2762bc201b375 ⏎ => all i did was add 1 line `choosenim $BRANCH`
04:24:20shashlickI have no problem adding that to the gist but it didn't work in isolation
04:24:30shashlickif that's all it takes, let's add it to the gist
04:26:22*voltist quit (Ping timeout: 250 seconds)
04:26:25FromGitter<timotheecour> > it didn't work in isolation ⏎ ⏎ the 1st time will succeed for a new PR (because the cache won’t be used for a new PR), as I explained in https://github.com/nim-lang/nimble/issues/783 ⏎ ⏎ > if that's all it takes, let's add it to the gist ... [https://gitter.im/nim-lang/Nim?at=5e72f4718efb7417d7c971e1]
04:26:26disbot➥ [CI] travis always fails for nim=#hash after the 1st run ; snippet at 12https://play.nim-lang.org/#ix=2eEg
04:27:18*nsf joined #nim
04:29:24*zedeus quit (Ping timeout: 250 seconds)
04:31:15*zedeus joined #nim
04:32:13FromGitter<timotheecour> trying it in https://github.com/nim-lang/nimble/pull/781/commits/8bec86039d8335af152acf238ab14d0268e003e5 to check if works
04:32:15disbot➥ show cmd used with --verbose (even on success); fix #783 ; snippet at 12https://play.nim-lang.org/#ix=2eE8
04:38:00shashlickcool let me know how it goes - prefer everything being in the sh script so that the yml files are minimal
04:43:44*chemist69 quit (Ping timeout: 246 seconds)
04:44:30shashlickI've updated the gist
04:44:45*chemist69 joined #nim
05:07:19*silvernode-mobil joined #nim
05:31:47*leorize quit (Remote host closed the connection)
05:32:19*leorize joined #nim
05:33:07FromGitter<timotheecour> keeping yml files minimal is a good thing, that’s not my concern, my concern is using gists for that instead of standard practice which is a git repo, which enable the usual workflow (PRs, issues, etc)
05:42:02*silvernode-mobil quit (Ping timeout: 256 seconds)
05:42:04*solitudesf joined #nim
05:43:54*narimiran joined #nim
05:58:57*silvernode joined #nim
06:14:19rayman22201@axion, @Rika, learned a workaround and fixed the default param issue. Best version of this macro yet (still a beast though): https://play.nim-lang.org/#ix=2eEr
06:16:08rayman22201bah: https://play.nim-lang.org/#ix=2eEt
06:22:38silvernodeIs there a "foreach" keyword in nim?
06:22:52narimiransilvernode: `for x in xs:`
06:23:09silvernodeok thanks, just checking
06:23:59FromGitter<gogolxdong> `undefined reference to '__builtin_saddll_overflow'`
06:24:24FromGitter<gogolxdong> `undefined reference to '__builtin_saddll_overflow'` isn't the falut of gcc, compile with 7.3.0 has the same problem.
06:25:52Araqgogolxdong: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
06:27:11FromGitter<gogolxdong> Does 7.3.0 have these builtins?
06:29:32Araqit should, GCC 5 introduced them
06:30:41FromGitter<gogolxdong> Have no idea how to fix this except to migrate OS to ubuntu18.04 or centos8. It's fine in ubuntu18.04
06:31:16FromGitter<sheerluck> wait a month and migrate to ubuntu 20.04
06:31:37FromGitter<gogolxdong> build gcc7.3.0 from source ,probably miss something.
06:31:58FromGitter<sheerluck> gcc-9.2 in ubuntu 20.04
06:32:20Araqgogolxdong: we can add a workaround
06:32:43FromGitter<sheerluck> http://cdimage.ubuntu.com/daily-live/current/
06:36:01FromGitter<sheerluck> ((https://i.imgur.com/6B0ieyW.png))
06:36:29*tdog joined #nim
06:37:58FromGitter<gogolxdong> found a page says it's a known issue of centos default gcc.
06:38:31FromGitter<timotheecour> Link?
06:38:54FromGitter<gogolxdong> https://wiki.swoole.com/wiki/page/1013.html it's in Chinese.
06:40:30Araqunfortunately we cannot use __has_builtin to detect the feature as __has_builtin is too new...
06:40:41FromGitter<gogolxdong> this solution doesn't work either.
06:41:01*dddddd quit (Ping timeout: 264 seconds)
06:41:14Araqbut if your GCC 7 lacks it we cannot use a version check either
06:43:35FromGitter<gogolxdong> then question becomes how to build gcc with these builtins?
06:44:55silvernodeIs there something like sleep() in nim? I am just trying to slowly step through a while loop, maybe I should just use a for loop
06:45:25FromGitter<sheerluck> silvernode https://nim-lang.org/docs/times.html
06:46:13silvernodeAh there it is, thank you much
06:49:31FromGitter<sheerluck> @gogolxdong I reckon it's faster to migrate to ubuntu 20.04 then to build gcc in centos. And even more reliable.
06:53:41FromGitter<gogolxdong> building gcc takes three-four hours, sure migration is faster, just try fixing this.
06:57:05*silvernode quit (Ping timeout: 246 seconds)
06:59:27FromGitter<gogolxdong> yeah, my production enviroments are all in centos7.
07:05:00*gmpreussner joined #nim
07:13:15*Zectbumo quit (Remote host closed the connection)
07:15:00Araqgogolxdong: I'm addinga workaround
07:15:04*Zectbumo joined #nim
07:18:24*Zectbumo quit (Remote host closed the connection)
07:46:06Araqhttps://github.com/nim-lang/Nim/pull/13692 once this is merged use
07:46:06disbot➥ added a switch -d:nimEmulateOverflowChecks for broken or old GCC vers…
07:46:25Araq-d:nimEmulateOverflowChecks to compile
07:54:17*natrys joined #nim
07:55:33*PMunch joined #nim
08:02:08leorizedom96: can I get your blessing for #13682?
08:02:09disbothttps://github.com/nim-lang/Nim/pull/13682 -- 3httpcore: deprecate `==`(string, HttpCode)
08:08:02Araqleorize, merged it
08:08:30*hsh quit (Ping timeout: 256 seconds)
08:09:04*LyndsySimon quit (Ping timeout: 256 seconds)
08:09:27*nikita` quit (Ping timeout: 240 seconds)
08:09:27*d10n-work quit (Ping timeout: 240 seconds)
08:09:27*l1x quit (Ping timeout: 240 seconds)
08:11:00*hsh joined #nim
08:11:23*LyndsySimon joined #nim
08:11:28*d10n-work joined #nim
08:11:47*nikita` joined #nim
08:12:07*l1x joined #nim
08:16:16FromGitter<alehander92> Araq
08:16:30FromGitter<alehander92> i am trying to imagine how raises tags would look like for my app
08:16:37FromGitter<alehander92> can we combine 3 effects into one
08:16:54FromGitter<alehander92> e.g. each async function can raise A, B, C => just combine into AsyncError
08:17:01FromGitter<alehander92> so i dont have to annotate too much
08:18:22leorize@timotheecour: the "better" way would be to set -text on every file
08:18:50leorizethat's the short hand for "don't touch their line endings"
08:20:05leorizenim itself don't care about crlf, and files that needs to be lf-only would already be commited as lf into the repo
08:20:24leorizeso it's better to just take them verbatim and tell git not to mess with it
08:28:46PMunchalehander92, you might be able to make a pragma pragma to combine them: https://nim-lang.org/docs/manual.html#pragmas-pragma-pragma
08:29:02PMunchOr you could of course create an exception hierarchy with AsyncError on the bottom
08:31:59FromGitter<alehander92> love you
08:32:08FromGitter<alehander92> pragma pragma makes sense, ohhh
08:40:16FromGitter<timotheecour> @leorize are you referring to https://github.com/nim-lang/Nim/pull/13693 or to https://github.com/nim-lang/Nim/issues/13690
08:40:18disbot➥ changes to gitattributes cause weird CRLF errors ; snippet at 12https://play.nim-lang.org/#ix=2eEG
08:47:00FromGitter<alehander92> hey
08:47:02FromGitter<alehander92> so async raises
08:47:15FromGitter<alehander92> Exception i guess because field error can be almost anything
08:47:23FromGitter<alehander92> await* sorry
08:47:36FromGitter<alehander92> hm, at least in the template impl, but i'd guess with rewriting as well
08:47:58FromGitter<alehander92> if we can just annotate generic Future[T] {.R.}
08:48:50FromGitter<alehander92> and somehow raise only R from each await for each futurre
08:49:48FromGitter<alehander92> but then we need to still add some effects for the async processing : e.g. i dont know what can happen, NonComplete , OsError ? etc
08:50:10FromGitter<alehander92> the problem is with return types
08:50:29FromGitter<alehander92> this seems a bit easier but still you cant catch the async errors as they happen when its yield-ed
08:50:54FromGitter<alehander92> so does anyone have an actual plan how async can be checked? or am i missing something?
08:51:35FromGitter<alehander92> in the javascript backend we can just add await to raise the call defects + a general JavascriptAsyncError or AsyncError i guess
08:51:47FromGitter<alehander92> so this might be easier there
08:59:46FromDiscord<flywind> what does this mean? https://play.nim-lang.org/#ix=2eEP
08:59:54FromDiscord<flywind> Error: system module needs: nimErrorFlag
09:02:20FromDiscord<flywind> when i use 2020-03-17 nim devel and --gc:arc, I can't compile some programs which can run in old devel with --gc:arc
09:06:56*tane_ joined #nim
09:11:34FromDiscord<flywind> find reasons.Because --gc:arc can't work with --threads:on.
09:12:58Araqflywind: I fixed that yesterday
09:13:14Araqbut there is also as a workaround: --tlsEmulation:off
09:13:33Araqwhich is a good idea anyway, tlsEmulation is slow
09:14:02FromDiscord<flywind> Thanks.I'll try.
09:17:43Araqalehander92: afaik Rust and Swift make the error part of the Future type just like Nim because Either[Future[T], Error] is much too annoying to work with
09:18:02Araqso if it returns Future[T], well, the future can be in the "failed" state, deal with it
09:18:17Araqand 'await' does deal with it for you
09:21:51*dwdv joined #nim
09:29:17*zahary joined #nim
09:29:35*abm joined #nim
09:30:05*Zectbumo joined #nim
09:36:54*zahary quit (Quit: Leaving.)
09:38:10FromGitter<alehander92> thanks
09:38:22FromGitter<alehander92> i'll have a look at rust/swift
09:38:36FromGitter<alehander92> but if I use {.raises: [..].} for async
09:38:54*krux02 joined #nim
09:40:17AraqI dunno what happens with .raises: [] for async
09:40:35*jjido joined #nim
09:41:42FromGitter<alehander92> but
09:42:04FromGitter<alehander92> ok, so afaik this is the preferred way to typecheck errors, and i dont understand how to use it with async
09:42:09FromGitter<alehander92> sorry if being unclear
09:43:10Araqtry:
09:43:19Araq f()
09:43:23Araqexcept:
09:43:53Araq if getCurrentException() of Defect: quit(1) # fix the broken 'try except'
09:44:27Araq else: handleError()
09:44:56Araqthere you go, robust error handling
09:45:54Araqyour way: proc foo() {.raises: [].} # gah, foo uses callbacks and stuff and not even the compiler can sort out the mess
09:46:19*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:47:22Araqbut that's just me, I don't like Nim's effect tracking
09:48:45Araqand no, I don't like encoding the same information in the type system via Option/Either either
09:49:52Araqin my world errors are so pervasive that it makes no sense to model them statically
09:52:21FromGitter<alehander92> in some cases that's true
09:52:32FromGitter<alehander92> but especially for libs / certain components
09:52:39FromGitter<alehander92> it might be useful to annotate them
09:53:22FromGitter<alehander92> "your way", i thought you recommend this way compared to Either/similar
09:53:36FromGitter<alehander92> i am not really using actively any of those ways in my project i think
09:54:28Araqwell maybe I keep changing my mind :P
09:54:44FromGitter<alehander92> what i wonder is if it is possible to do at all for async
09:55:39FromGitter<alehander92> maybe the other option is to just tag with myerror-like tags some component functions that i manually say "they lead to those errors" and track only those
09:56:21Araqwhy though? what's really the point? think your 'proc print' that doesn't return anything CANNOT possibly fail? well, guess what, it can fail.
09:57:11Araqso ok, print can only raise IOError and not ValueError
09:57:25Araqstill not clear how that really helps me
09:57:43Araqit's not like 'except IOError' is easier to write than 'except:'
09:58:04FromGitter<alehander92> well, its useful to know just like types
09:59:03Araqrarely, it'd rather have a single Error type with an enum inside instead of the current hierarchy
09:59:22FromGitter<alehander92> ok
09:59:41FromGitter<alehander92> what i mean is that its useful to know "ok here i can get only those classes of errors"
10:00:11FromGitter<alehander92> i am talking about more domain-specific things like "myDbError / WriteError / GDBError " etc
10:00:35FromGitter<alehander92> i agree some errors are ignore-able e.g. one might not care about some echo-s etc
10:00:46Araqnot my point :-)
10:01:52FromGitter<alehander92> well, what is your point? :D
10:02:31Araq1. once the type hierarchy is gone, there is only .raises vs .noraises
10:02:45FromGitter<alehander92> ah, this kind of check
10:03:17Araq2. raises is so pervasive that .noraises seems to be liability, what if the implementation changes and it needs to call a function that can raise
10:04:19Araq3. functions can raise. accept it. even in holy C functions can call _exit()
10:05:46Araq4. 'try except' continues to work well in Java, C#, Python and no, the systems written in these languages are not toys and no, C# programmers do not long for verbose Either monads everywhere.
10:06:35PMunchI'm going to create a language that never crashes. If everything goes to shit it will just start calling random functions and try to edit all variables on the stack until it managed to get further
10:06:49FromGitter<alehander92> ok but
10:06:51PMunchIt might not do what you wanted it to, but god damn if it isn't trying!
10:06:52FromGitter<alehander92> look at my view
10:07:03FromGitter<alehander92> pervasive is nonlocal: ⏎ i imagine 4 kinds of handling: bug(quit or fail or something), recover(again, probably do it locally), raise, ignore: most of them are local (bug, recover, ignore) and only raise is nonlocal
10:08:47FromGitter<alehander92> ok, the last one is also "restart" : using a global/component-handler
10:09:03FromGitter<alehander92> so i imagine that if one handles more errors relatively "locally", more functions would have only "component-level" errors which are not a burden to follow
10:09:39FromGitter<alehander92> only the "restart" case where one just pushes error up and up until it gets to the main component handler seem to be a bit hard as they are mostly noise
10:10:11Araqit depends on the problem domain how well you can handle errors "locally"
10:10:53AraqI analysed it roughly and you would be surprised how often 'on error return' is the best option by far
10:11:23FromGitter<alehander92> hm, so raise is always some kind of "component-level" and restart mostly recover indeed so they remain 4 but recover might be non-local sometimes
10:11:41FromGitter<alehander92> ok, but this is similar to `ignore`
10:12:08FromGitter<alehander92> which is good: a gets an error and just swallows it and you dont need to annotate anything about `a`
10:12:14Araqbeware of the "local handler" that "logs it away"
10:12:28Araqsee Java and why everything depends on some logging framework
10:12:45FromGitter<alehander92> yeah and those views are just what i remembered for your guys quit vs handle discussions + some thinking
10:13:17Araqhere is a realistic example:
10:13:34FromGitter<alehander92> well, one should be able to cast/ignore those errors in the type system as well
10:13:38Araqthe Nim compiler reports an error and then dies. no exceptions required, ok.
10:14:05FromGitter<alehander92> yeah but if you use it as a lib?
10:14:16Araqexactly.
10:14:25*Vladar joined #nim
10:14:59Araqwhat if you want to use the Nim compiler on the playground? ok, you can run it as a process
10:15:35Araqbut now what you really have is quit() + process isolation + a way to recover from it
10:15:51Araqin other words: An exception implementation.
10:16:16Araqa rather good one too with process isolation. But still, sometimes you cannot afford processes
10:16:43FromGitter<alehander92> yeah, and it's a bit expensive
10:16:47FromGitter<alehander92> sometimes*
10:17:26FromGitter<alehander92> e.g. i use it as a plugin and i mostly parse stuff with it : i dont want to always invoke it as a process
10:17:39Araqand there is more: every process has an exitcode, 0 for "success"
10:18:04Araqthere are no non-failing processes, it's simply assumed every process can fail.
10:18:20Araqthere always is an exitcode.
10:19:24*lritter joined #nim
10:19:45FromGitter<alehander92> well .. ok, talking about components this might make sense
10:21:18FromGitter<alehander92> but again: its useful to know that you deal with this subcomponent errors locally: e.g. you invoke the nim compiler: it fails somehow, you do what you do or you just handle this in the parent level where you invoke all kinds of compilers? or even on an upper level
10:22:06Araqwell yeah, consider a REPL loop, it failed, you output the error message and read in the next line of input
10:22:29Araqnow lets say the compiler fails due to a bug
10:22:42Araqcan you continue in your repl? who knows :-)
10:22:58Araqdo you want the Nim playground to keep running? yep
10:24:08FromGitter<alehander92> yes thats a good question
10:24:16FromGitter<alehander92> i ask myself about a gdb lib
10:25:04FromGitter<alehander92> usually its good to let the user deal with it
10:26:22FromGitter<alehander92> and let him choose if he wants to recover somehow, just log/ignore it or try to restart/reset a whole component
10:27:05FromGitter<alehander92> i think with some "bugs" a useful thing is to offer a `reset` method: when you know your state got somehow broken, but you can "go back" in a relatively sensible way
10:28:42Araqsure, could be useful
10:32:02FromGitter<alehander92> but yeah i guess often its useful to know also : component A has handled low level errors and generated a end user action(e.g. message) , so like turning many low level errors into just 2-3 kinds of high level errors (or simply restart/quit)
10:32:23FromGitter<alehander92> so there is this kind of "processing" of errors
10:32:35FromGitter<alehander92> which is still useful to be enforced
10:33:16FromGitter<alehander92> i mean the whole point is to think "this error should be handled this way, that kind of error not" , but to be able to do that
10:33:35*Ven`` joined #nim
10:33:44FromGitter<alehander92> its useful to have something that calculates what kinds of errors are at a certain point
10:34:43FromGitter<alehander92> this works well with the enum idea: checking that one has handled all the kinds at a certain critical boundary/
10:35:59AraqI think at this point we can say 'errno' is really an enum and it really suffices for POSIX and thus for everybody
10:36:23Araqand inheritance hierarchies are overkill
10:36:49FromGitter<alehander92> but errno is not a great enum imo
10:37:05FromGitter<alehander92> i mean ok yeah there are conventions about it
10:37:31FromGitter<alehander92> but nothing enforces a process to really quit in the correct way
10:37:47Araqmaybe not "great" but Python's hierarchy is not "great" either IMO
10:37:51FromGitter<alehander92> yea
10:38:00FromGitter<alehander92> i like the enum errors idea
10:38:02FromGitter<alehander92> but in a different way
10:38:09FromGitter<alehander92> hierarchy can be just set of enums
10:38:32FromGitter<alehander92> and this way one can easily tweak how errors are handled in his project
10:39:23FromGitter<alehander92> i might be just repeating some kind of `zig` example with this sentences which i saw tho, i think i've seen this kind of handler before
10:41:18Yardanicowell yeah, zig just has enums and exception catching is like in go
10:41:25Yardanico(exceptions are values and can't be ignored)
10:43:14FromGitter<alehander92> but it has exactly sets of enums which look much more flexible imo
10:45:19FromGitter<alehander92> https://ziglang.org/documentation/master/#Errors
10:46:23FromGitter<alehander92> i am not saying i like the verbosity tho
10:49:49Araqlooks ok to me, not sure how 'try' and 'catch' and sugar for passing errors around is not an exception handling mechanism
10:50:22Araqit was the first thing they added to Rust after 1.0 iirc, sugar for making the monads bearable
10:51:52FromGitter<alehander92> yeah i agree
10:52:05Araqso yeah, sure, checked exceptions, they are awesome, see Java
10:52:09FromGitter<alehander92> but still you get annotations/inferrence for the errors even if you use try
10:52:23FromGitter<alehander92> which is good: as the inferrence kinda stops the checked exception problem
10:52:49FromGitter<alehander92> as sometimes you dont really need to annotate all the errors: just need to annotate they raise as you said with raises
10:53:33Araqthe real problem is composition in an evolving codebase. you start with 'returns T'
10:53:41Araqand then it becomes T?
10:53:51Araqand then it bubbles up everywhere
10:53:59Araqhave fun
10:54:27Araqand yeah, the same problem happens in other cases when you use a static type system
10:54:56Araqand it's already bad, but it doesn't happen as often
10:55:25Araqsame story with 'const' in C++
10:55:51FromGitter<alehander92> yea i know
10:55:56FromGitter<alehander92> but this is not bad imho
10:56:07FromGitter<alehander92> something changes: its good to notice that
10:56:24FromGitter<alehander92> and function becoming for non-erroring to erroring is a big change
10:57:01Araqis it though? so what do you do now that 'f' can fail? how about you let the error bubble up...
10:57:10FromGitter<alehander92> well thats the point
10:57:31Araqyeah, you let it bubble up without having to patch thousands of lines of code...
10:57:33FromGitter<alehander92> now you can decide : i ignore it, i do something about it locally, i quit or i bubble it up
10:57:44FromGitter<alehander92> well why would you patch so many
10:57:53FromGitter<alehander92> often you would just patch several other signatures
10:58:06FromGitter<alehander92> or if it doesnt really matter, you'll ignore it
10:58:20FromGitter<alehander92> and think about it
10:58:35FromGitter<alehander92> usually 1-2 levels up you have a function which already deals with other error-ing calls
10:58:51FromGitter<alehander92> so you'll usually just bubble it up to there in the bad case
10:58:58FromGitter<alehander92> not changing your whole codebase
10:59:38Araqdoesn't match my experience but maybe it works
10:59:47FromGitter<alehander92> yeah maybe the problem here is ignoreable vs "important" errors
11:00:20FromGitter<alehander92> e.g. maybe sometimes people just want to bubble up the globally-ignoreable (not just return one-s) errors
11:00:34FromGitter<alehander92> and try to track the other ones more closely
11:01:34FromGitter<alehander92> then if one can use sets it seems easy to just an error set of Ignoreable which lets you do that
11:01:58FromGitter<alehander92> basically dont track those in the whole codebase and just put manually a `catch`/whatever on top
11:02:22AraqI have yet to see many "Ignorable" errors
11:03:14Araqno idea why you bring them up, it's like admitting that otherwise disruptive source code changes are necessary
11:15:58FromGitter<alehander92> not really
11:16:04FromGitter<alehander92> more that they are like noise sometimes
11:16:18FromGitter<alehander92> otherwise i still think people have many error-able calls
11:16:28FromGitter<alehander92> so it doesnt matter so much if a T changes to T?
11:16:44FromGitter<alehander92> because either you'll quickly deal with it locally or in a close parent call
11:17:10FromGitter<alehander92> or because most calls around are also without `?` so it is indeed important to notice it now errors and to do something more
11:19:00FromGitter<alehander92> but again most cool to me is the combo of error set + tracking somehow: one can actually immitate that with a Result, but no way to specify type A is just a "type B or type C" without being generic
11:25:42Araqas I said elsewhere, I consider Java's checked exceptions a failure
11:26:06Araqand they are a failure because they picked the wrong default
11:26:27Araqso everytime you write an interface people who implement it are forced to handle the error locally
11:26:51Araqas the methods inside the interface lack the 'throws Exception' annotation
11:27:13*Trustable joined #nim
11:27:22FromGitter<alehander92> but i see two problems with checked exceptions which seem to be solveable
11:27:48FromGitter<alehander92> first one is being annoying to write all the checked exception lists : one can indeed infer that
11:27:56Araqwhenever I write a stdlib proc just to make it future-proof it should be "yeah, can raise"
11:28:29Araqso in the end so much can raise that 'try' annotations before function calls become pure noise
11:28:41FromGitter<alehander92> and yeah about interfaces i am not sure why
11:28:54FromGitter<alehander92> i mean you can have error-level-generic interfaces
11:29:04FromGitter<alehander92> which offer both non-errorable and errorable variants
11:29:10FromGitter<alehander92> depending on the caller
11:29:54FromGitter<alehander92> well that's where the "ignoreable" sets idea comes: you decide which errors do you want to actually track
11:31:32Araqand in Java you can turn a checked exception into an unchecked one
11:31:45FromGitter<alehander92> i dont know why a stdlib proc have to be "future-proof" : if it errors, it errors if it doesnt, it doesnt: if this changes: let the caller either ignore* that ⏎ ⏎ which can be even just calling it in a "ignore any error with this call" way: no need for any big changes in the codebase , just the call lines ⏎ or even with this ignoreable set: just one change ⏎ ... [h
11:31:45FromGitter... ttps://gitter.im/nim-lang/Nim?at=5e735821a73c1910996c0b78]
11:32:02FromGitter<Kvothe87> hello again, I'm sorry to keep on asking for help, but as a beginner i thought this was the best place
11:32:11Yardanicoyeah, it's perfectly fine to ask beginner questions here
11:32:22FromGitter<Kvothe87> i want to create a zip of a folder
11:32:32Yardanicohttps://github.com/nim-lang/zip
11:32:58Araqalehander92: it needs to be future proof because otherwise nobody can rely on it and it keeps changing and clients keep adapting
11:33:00Yardanicoalthough you'll need a zlib dll if you're on windows (it's usually bundled with nim)
11:33:01FromGitter<Kvothe87> i installed the miniz library
11:33:11FromGitter<Kvothe87> that i thought was exactrly for that
11:33:58FromGitter<Kvothe87> but if i understood correctly it returns a string
11:34:04FromGitter<Kvothe87> instead of a file
11:34:10Yardanicowell string in nim is just bytes
11:34:19Yardanicoit can be a file
11:34:25Yardanico(contents of a file)
11:34:32FromGitter<alehander92> Araq but how often does this change?
11:34:39Yardanicoand if you're a beginner I'd recommend you to use "zip" lib since it has more usage
11:34:50FromGitter<Kvothe87> so should i just write the string to file and set extension to zip?
11:35:13FromGitter<alehander92> i mean this seems useful: you now need to know you need to handle an error
11:35:16Araqalehander92: often. recently I learned that even getCurrentDir() can fail
11:35:21Yardanicowell, honestly IDK how miniz works, maybe yes
11:35:27FromGitter<alehander92> how is this less reliable than "ok this just starts to fail"
11:35:42*Araq sighs
11:35:43Yardanicoin nim zip library it's quite easy to create zip archives
11:35:49Yardanicohttps://github.com/nim-lang/zip/blob/master/tests/ziptests.nim
11:35:54FromGitter<alehander92> well .. it makes sense that getCurrentDir can fail
11:36:18FromGitter<alehander92> and if it was annotated properly one wouldnt need to learn that by finding an obscure bug
11:36:48FromGitter<alehander92> one can still ignore it freely, but its just good to know what *can* happen
11:37:33FromGitter<alehander92> and yeah i think i had a similar error these days
11:37:46FromGitter<Kvothe87> @Yardanico i started from miniz since it seemed to be smaller and simpler, just two functions compress and uncompress, so ithough i had few options for error
11:37:53FromGitter<Kvothe87> but i will check zip library
11:38:08FromGitter<alehander92> my script rm-ed a dir (which appears to have been its current dir) and then started a git process there iirc
11:38:16FromGitter<alehander92> and it failed indeed
11:38:30Araqin reality errors are pervasive and the sane default is .canraise, just imagine you change the implementation to use a helper string that allocates
11:38:41FromGitter<alehander92> so i guess this is an easy way to say "see: even git doesnt handle it, why track such a case"
11:38:49FromGitter<alehander92> (if i am not mistaken about git)
11:39:01FromGitter<alehander92> but thats my point
11:39:16Araqso previously your precious "cannot raise muahaha" proc became "can raise OOM"
11:39:18FromGitter<alehander92> you can say in your app: ok, i just ignore MemoryError or AllocError
11:39:27FromGitter<alehander92> so now you dont need to change anything
11:39:35Araqwtf man, you don't "ignore" them
11:39:51FromGitter<alehander92> why? ignoring means "just let them bubble and crash"
11:39:53Araqyou turn them into process terminations
11:40:06Araqah well
11:40:12FromGitter<alehander92> is this sarcasm :D
11:40:16Araqthat's not "ignoring"
11:40:36FromGitter<alehander92> well i meant "ignore them in type signatures through your codebase"
11:40:41FromGitter<alehander92> yeah, a bit confusing
11:40:53FromGitter<alehander92> NOTRACK = {MemoryError}
11:40:56FromGitter<alehander92> something like this
11:41:07Araqyeah exactly, that's what I want to do. ignore them in the type signatures
11:41:21Araqit's what I've been arguing for all day long
11:41:22Araq:P
11:41:29FromGitter<alehander92> well ok and i am saying you canleave
11:41:33FromGitter<alehander92> the choice to the user of the lib
11:41:47FromGitter<alehander92> some users might find it useful to track X others Y
11:41:58FromGitter<alehander92> others to just ignore
11:42:19Araqthat causes trouble ;-)
11:43:17Araqbecause then you cannot a library which does 'try .. except OverflowError' when you just turned overflow errors into quit()s
11:44:33FromGitter<alehander92> sorry i havent researched enough your guys discussions
11:44:36FromGitter<alehander92> yeah you're right
11:44:41FromGitter<alehander92> what i imagine is that
11:45:01FromGitter<alehander92> using a lib you just inherit its NOTRACK so you have to follow/combine that somehow
11:45:37Araqcan you see how this is all much more complex than simply using *unchecked* exceptions instead?
11:46:31Araqyou do 'try: optionalComponent() except:' to turn into a sandbox, problem solved
11:46:38FromGitter<alehander92> but yeah indeed if my library does this with OverflowError I just cant do that of course
11:46:56FromGitter<alehander92> but i know i cant, because the library cant raise OverflowError
11:47:08FromGitter<alehander92> so the compiler can tell me ok it doesnt make sense to do this
11:47:14Araqbe my guest and use the new --panics:on switch
11:47:30Araqand now let me work please, I'm tired of this
11:47:32FromGitter<alehander92> yeah it is more complex yeah
11:48:13FromGitter<alehander92> but i still think user defineable checked sets vs unchecked sets changes the game a bit
11:48:24FromGitter<alehander92> no problem i have to continue as well sorry
12:00:02*dddddd joined #nim
12:03:18*Trustable quit (Remote host closed the connection)
12:23:19*rockcavera joined #nim
12:36:52axionI need help with linking to other procs with nim doc. The anchors it is generating do not make sense to me and seem ambiguous
12:45:47axionhttps://play.nim-lang.org/#ix=2eFG
12:47:16Araq [see also](...#sign%2CT%2CT)
12:47:36Araqwhat's the problem? yeah the links can be ugly but they usually work
12:48:15axionAh I was following the syntax of the sequtils documentation that actually wrote the whole signature. I was expecting it to just do the right thing like it does there
12:48:34axionAlso it used `foo<#bar>`_ syntax or smth
12:51:20axionSo it looks like that is just [T] base64 encoded, and the other one is [T. What's to stop both from working if I add another similar proc?
12:52:03axionThat's why I was expecting it to generate a link for the signature...not the first few characters of it
12:54:46Araqsomebody put some though into this but it wasn't me and it's probably broken in all sort of subtle ways
12:54:53Araqas name mangling usually is
12:55:16Araqbut we cannot change it easily, we would need to update all the URLs everywhere
12:55:45axionYeah name mangling causes issues, but this is name managling and truncation. Seems very fragile and tedious to check each link every time you add new generic procs
12:56:46axionI am now questioning if it is worth the time to write nice docs :)
12:57:11Araqnice docs doesn't mean "lost of silly anchors to jump around"
12:57:48axionIt does if it's crucial to understanding which ones to use in a given context.
12:58:24Araqif you say so. we use long top level comments that explain how the different procs work together
12:59:15*zahary joined #nim
13:00:11Araqdon't document type signatures and the arguments, they are formalized via Nim's type system
13:01:45axionI just noticed sequtils links aren't name mangled...huh
13:02:01axionthey aren't even encoded. how?
13:02:45axionoh some are
13:02:47axionweird
13:07:06*nsf quit (Quit: WeeChat 2.7)
13:16:11*endragor quit (Remote host closed the connection)
13:17:56FromDiscord<Rika> is there a naming scheme for procs that "clone an object for use in another thread"
13:20:13*jjido joined #nim
13:34:28*shadowbane joined #nim
13:38:11*natrys quit (Ping timeout: 246 seconds)
13:39:51*Zectbumo quit (Read error: Connection reset by peer)
13:40:14*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:41:29axionIs there a way to run runnableExamples to unit test, without generating docs?
13:47:55FromGitter<kaushalmodi> axion: probably not
13:48:18FromGitter<kaushalmodi> for tests for which you don't need docs, put them in separate tests
13:48:32FromGitter<kaushalmodi> you can have a mix of runnableExamples and tests
13:49:35PMunchRunnable tests are just meant to ensure that the examples in the documentation are actually valid
13:49:46*blackbeard420 quit (Remote host closed the connection)
13:49:47PMunchIn case you change your code but forget to update the docs
13:50:03*blackbeard420 joined #nim
13:50:34PMunchI've seen documentation in the past where a function had been completely renamed. So the documentation told you to run functions that didn't exist at all any longer.
13:50:58PMunchIt would be cool if runnableTests could take a scope argument though..
13:51:35PMunchSo you could do `testScope: import somepacke; var x = initSomething[int](100)` and then do `runnableExamples(testScope): <code>`
13:52:09axionThat just confused me :)
13:52:36PMunchWhat confused you?
13:52:40axionSo if I change the code but forget to update the docs, the runnableExamples are never ran so the docs are wrong, right?
13:52:45*clyybber joined #nim
13:52:54PMunchNo
13:53:14PMunchThe runnableExamples will then not compile, or fail on a runtime assert, so you won't be able to generate the documentation
13:53:26PMunchUntil you fix the runnableExamples
13:53:49axionRight, by forgetting to update the docs I was including the forgetting to run `nim doc` as well.
13:54:11PMunchAh, well yes then they won't run
13:54:25PMunchBut if you forget to run `nim doc` your docs are likely not correct anyways..
13:54:33axionSo I'd want a git hook to call that probably or something.
13:54:53PMunchYeah that'd be a good way of doing it
13:55:12PMunchOr like nimble.directory does it
13:55:32PMunchWhen you try to access a package that hasn't been generated yet it tries to generate it
13:56:22PMunchA git hook has the benefit of being able to deny you the push though if the docs don't generate properly :D
13:56:33axionYeah seems like a perfect fit.
13:57:42PMunchHmm, I guess I should set something like that up for my packages
13:58:00FromDiscord<Recruit_main707> how can you print something without a garbage collector?
13:58:05PMunchWould be cool to have a website with all my packages, with generated docs and such
13:58:26PMunchRecruit_main707, what do you mean?
13:58:33axionSet up a hook to deny push if an exported proc doesn't have docs too :)
13:58:52FromDiscord<Recruit_main707> how can i print things with --gc:none
13:59:18PMunchstdout.write I guess
14:00:09clyybberRecruit_main707: Why are you using gc:none?
14:00:29*Guest39909 is now known as dadada
14:00:34*sz0 joined #nim
14:01:04FromDiscord<Recruit_main707> gced memory might be messing things around and i want to check if there is luck without garbage collector
14:01:17clyybberYeah, but don't use gc:none
14:01:21clyybberInstead use gc:arc
14:01:32clyybberAnd os:any if you need to
14:01:35PMunchI'd say that is quite unlikely..
14:01:55FromDiscord<Recruit_main707> PMunch, i am injecting a dll so not so much
14:02:06clyybberUse gc:arc still
14:02:12FromDiscord<Recruit_main707> ok
14:02:24PMunchAh okay, slightly more likely then :P
14:03:03axionWhen I saw the ARC announcement I was super excited but haven't written any code that would notice a difference yet...can't wait to try it.
14:05:39FromDiscord<Recruit_main707> chips and kernels is where arc is gonna be game changing imo
14:07:22lqdev[m]don't forget multithreading
14:07:53FromDiscord<Recruit_main707> will arc become default gc?
14:09:18lqdev[m]that's the plan; to deprecate all GCs until we remain with arc and boehm
14:10:37FromGitter<kaushalmodi> axion: ⏎ ⏎ > So I'd want a git hook to call that probably or something. ⏎ ⏎ You would normally have your CI run `nim doc ..` [https://gitter.im/nim-lang/Nim?at=5e737d5c12ef9a435db2c090]
14:11:01FromGitter<kaushalmodi> e.g. CI services: Travis, Azure, sourcehut
14:11:06FromDiscord<clyybber> lqdev[m]: Eh, not so much deprecate. But arc is certainly the future
14:12:23lqdev[m]@clyybber: that's what I heard from ar4q sometime, but I can't find the quote.
14:22:45*natrys joined #nim
14:26:30*Vladar quit (Quit: Leaving)
14:28:29FromDiscord<Rika> any of you getting 502s on nimble.directory?
14:28:38FromDiscord<Rika> who owns that anyway
14:36:43PMunchRika, federico3 maintains it
14:37:30PMunchI manage to browse the site
14:37:45*shadowbane quit (Ping timeout: 250 seconds)
14:38:26FromDiscord<Rika> odd
14:38:51federico3Rika any broken package?
14:38:57PMunchHmm, is there a module that turns a series of string with tabs in them into a nicely formatted table?
14:39:10axionIt works here, although incredibly slow.
14:39:33PMunchYeah it's slow for me as well :(
14:39:35PMunchfederico3, https://nimble.directory/ci/badges/macroutils/nimdevel/output.html
14:39:49PMunchWhy was NimScript killed?
14:40:09FromDiscord<Rika> no, refreshing fixed it
14:40:23FromGitter<kaushalmodi> PMunch: there's one CLI table generator package
14:40:34FromDiscord<Rika> its just super slow
14:40:54FromDiscord<Rika> also wtf, this is prolly my side but no avatars from github load
14:41:18PMunchkaushalmodi, link?
14:41:25FromGitter<kaushalmodi> PMunch: https://github.com/xmonader/nim-terminaltables
14:41:57PMunchHmm, that takes rows though..
14:42:07PMunchAnd it's a whole system..
14:43:17FromGitter<kaushalmodi> it has a `render` proc that returns a string: https://xmonader.github.io/nim-terminaltables/api/terminaltables.html
14:43:24FromGitter<kaushalmodi> may be that's what you want from there?
14:49:42*endragor joined #nim
14:54:13*endragor quit (Ping timeout: 250 seconds)
14:58:40*zahary quit (Quit: Leaving.)
15:02:49*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:11:21*zahary joined #nim
15:14:14PMunchkaushalmodi this is what I wanted: https://play.nim-lang.org/#ix=2eGv
15:16:47*ptdel joined #nim
15:36:33*shadowbane joined #nim
15:39:54*Ven`` joined #nim
15:42:32FromGitter<kaushalmodi> PMunch: nice!
15:42:44FromGitter<kaushalmodi> btw I just happened to read your message
15:43:00ZevvHey ppl, I'm dropping of #nim for some time, I have too many apps and windows bipping for my attention these days. See you guys later!
15:43:02FromGitter<kaushalmodi> Gitter does not alert me unless you write @kaushalmodi with that @
15:43:32*Zevv left #nim (#nim)
15:58:52*Hideki_ joined #nim
16:07:00*Vladar joined #nim
16:11:50FromGitter<alehander92> oh zevv
16:11:52FromGitter<alehander92> see ya
16:38:23*Hideki_ quit (Remote host closed the connection)
16:39:17*Hideki_ joined #nim
16:43:51*Hideki_ quit (Ping timeout: 250 seconds)
16:50:38*skelett quit (Quit: WeeChat 2.5)
16:51:14*Kaivo quit (Ping timeout: 240 seconds)
16:51:39*skelett joined #nim
16:53:50*Kaivo joined #nim
16:58:09disruptek~stream
16:58:10disbotstream: 11https://twitch.tv/disruptek (live video/audio) and mumble://uberalles.mumbl.io/ (live voice chat) -- disruptek
16:58:18disruptekmore compiler backend cache stuff.
16:58:28Yardanico*secretly works on pulseaudio again*
16:58:38disrupteknah, i finished last night.
16:58:51disruptek!repo disruptek/pulseauto
16:58:53disbothttps://github.com/disruptek/pulseauto -- 9pulseauto: 11setup pulseaudio stream levels via app names or pids 15 0⭐ 0🍴
16:59:16dadadadon't know if I'm late to post this
16:59:31dadadabut Nim is used with a code example on Arstechnica today
16:59:36dadadahttps://arstechnica.com/information-technology/2020/03/the-windows-subsystem-for-linux-conference-was-a-virtual-success/
16:59:45dadadathis is a big event IMO, for Nim
17:00:01dadadatopic is Windows Subsystem for Linux :-)
17:00:59Yardanicowell maybe there'll be a noticeable spike in traffic for nim-lang.org :P
17:01:10dadadaArstechnica is one of the most frequented tech websites
17:01:26dadadaYardanico: most certainly
17:02:55PMunchWow, that is actually really cool
17:03:25PMunchEspecially cool to see Nim just being used as a tool without spending half the article explaining what it is
17:03:44PMunchAnd I like the line "We just used it here as a clean, quick, simple way to make a Hello World-style app without a lot of cruft to get in the way of seeing what's going on."
17:03:55PMunchNice selling point for Nim there :)
17:04:37dadadayes, so we might have an ally in this Jim Salter guy, who authored that article, maybe he'll write about Nim again
17:04:41Yardanicowow jesus though
17:04:47Yardanicothey installed nim 0.17.2
17:04:52Yardanicocoz default ubuntu version in WSL has that nim
17:05:06Yardanicoits ubuntu 16.04 iirvc
17:05:07Yardanicoiirc*
17:08:23dadadacan we see the nim-lang.org statistics somewhere?
17:08:42Yardanicoask narimiran, although idk if he has access to that :P
17:08:47Yardanicobut you can check stats for the repo
17:08:55Yardanico(well, if you have push access to nim repo)
17:09:16narimirani don't have such info/access
17:09:40*Hideki_ joined #nim
17:14:08*Hideki_ quit (Ping timeout: 265 seconds)
17:16:23*Trustable joined #nim
17:18:31*bra-ket quit (Ping timeout: 250 seconds)
17:20:13FromDiscord<Varriount> What do you mean? Why would the github repo have visitor stats?
17:21:44*uvegbot joined #nim
17:22:48FromDiscord<Varriount>
17:22:48FromDiscord<Varriount> https://cdn.discordapp.com/attachments/371759389889003532/690248923679424519/unknown.png
17:24:33FromDiscord<Varriount> Green is views, blue is unique visitors
17:25:17FromDiscord<Recruit_main707> Holy shit, wikipedia as blown up this february
17:25:25FromDiscord<Varriount> What do you mean?
17:25:56FromDiscord<Recruit_main707>
17:25:56FromDiscord<Recruit_main707> https://cdn.discordapp.com/attachments/371759389889003532/690249710958673930/unknown.png
17:26:56dadadaRecurit_main707: what does the number represent exactly?
17:27:26FromDiscord<Recruit_main707> wikipedia views afaik
17:28:10FromDiscord<Recruit_main707> we might pass D this month!
17:28:10FromDiscord<Recruit_main707> https://cdn.discordapp.com/attachments/371759389889003532/690250274644033603/unknown.png
17:29:22dadadaRecruit_main707: so you compare the visitor stats of nim lang's wikipedia page against rust lang's wikipedia page... okay
17:30:11FromDiscord<Recruit_main707> want the pic?
17:31:34*zahary quit (Quit: Leaving.)
17:33:09FromDiscord<Recruit_main707> at least rust is stalling
17:33:10FromDiscord<Recruit_main707> https://cdn.discordapp.com/attachments/371759389889003532/690251531484004371/unknown.png
17:33:42FromDiscord<Recruit_main707> anyways, congrats for the all-time high!
17:34:21dadadayeah, nice development overall! thanks Recruit_main707 for the stats
17:39:39*zahary joined #nim
17:40:20FromDiscord<Recruit_main707> here you have the page if somebody wants to check other stats:
17:40:20FromDiscord<Recruit_main707> https://tools.wmflabs.org/pageviews/?project=en.wikipedia.org
17:49:56*silvernode joined #nim
17:50:31*Amun_Ra joined #nim
17:50:42*Hideki_ joined #nim
17:51:24*SebastianM joined #nim
17:57:50*s4mu3lbk joined #nim
17:58:07*SebastianM quit (Quit: leaving)
18:00:47*nullwarp quit (Ping timeout: 272 seconds)
18:03:44*clyybber quit (Quit: WeeChat 2.7.1)
18:07:50*koltrast quit (Quit: ZNC - http://znc.in)
18:08:39*Jesin quit (Quit: Leaving)
18:08:43*koltrast joined #nim
18:11:37*Hideki_ quit (Ping timeout: 264 seconds)
18:14:34*rockcavera quit (Remote host closed the connection)
18:25:49*Jesin joined #nim
18:31:26*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:38:42*Ven`` joined #nim
18:38:59FromGitter<Kvothe87> hi all again
18:39:36FromGitter<Kvothe87> based on this morning suggestion i'm trying to use the zip library to zip a folder
18:40:14*dadada quit (Ping timeout: 246 seconds)
18:40:17FromGitter<Kvothe87> i imported it like zip/zipfiles as seen on the forum
18:40:51FromGitter<Kvothe87> but when i compile the program i get an error
18:41:50*dadada joined #nim
18:42:01FromGitter<Kvothe87> execution of an external program failed ....mingw32\bin\gcc.exe -o
18:42:01FromGitter<Kvothe87> i'm on windows
18:42:14*dadada is now known as Guest83817
18:42:25FromGitter<Kvothe87> how should i fix it?
18:43:08FromGitter<Kvothe87> i saw on the forum that i'm not the first with this issue, but it seems the solution was for linux
18:43:37*SebastianM joined #nim
18:44:06FromGitter<awr1> https://github.com/nim-lang/zip/blob/master/zip/libzip.nim#L50
18:44:17FromGitter<awr1> are you linking with libzip
18:45:05FromGitter<awr1> oh it already imports libzip_all.c
18:45:07FromGitter<awr1> from the repo
18:45:08FromGitter<awr1> hm
18:50:56*SebastianM quit (Quit: leaving)
18:55:57*filcuc joined #nim
18:57:55FromGitter<Kvothe87> this was the thread i mentioned https://forum.nim-lang.org/t/1857
18:58:46FromGitter<Kvothe87> but honestly i don't understand how to fix it based on my situation
18:58:49*zahary quit (Quit: Leaving.)
18:59:00shashlickcan you share some snippets of your error
19:07:01FromGitter<Kvothe87> https://play.nim-lang.org/#ix=2eHC
19:08:58*silvernode quit (Ping timeout: 256 seconds)
19:09:52*filcuc quit (Quit: Konversation terminated!)
19:10:42*filcuc joined #nim
19:10:45*shadowbane quit (Ping timeout: 250 seconds)
19:12:36*filcuc quit (Remote host closed the connection)
19:13:51*filcuc joined #nim
19:14:12*filcuc quit (Client Quit)
19:15:06*filcuc joined #nim
19:16:53*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:25:29*Vladar quit (Quit: Leaving)
19:28:31*filcuc quit (Ping timeout: 250 seconds)
19:28:52rayman22201!last axion
19:28:52disbotaxion spoke in 12#nim 4 hours ago
19:29:02rayman22201@axion are you online atm?
19:29:46axionI will be in about an hour...mobile right now
19:30:47rayman22201idk if you saw my post last night. I got that "componentWiseLifting" macro working.
19:31:36*zahary joined #nim
19:33:09rayman22201https://gist.github.com/rayman22201/bfc4ce11fa15e57176130c4855407199
19:33:16rayman22201whenever you get a chance to take a look at it
19:37:41Yardanicobtw does async work with arc now or not yet? :)
19:37:46Yardanicoi mean no leaks, I know it compiles and runs fine
19:38:56Araqdisruptek, the C++ exception bugfix now merged
19:39:04disrupteksweet.
19:39:08Araqand will be in 1.2, nice
19:39:16disruptekyeah, that's a nice feather.
19:39:34disruptekYardanico: nope.
19:44:01*tdog quit (Quit: Leaving)
19:44:37*Ven`` joined #nim
19:46:58rayman22201ughhhh. More hints that I should stop procrastinating and actually do something about async... probably not today...
19:50:42leorizedo it \o/
19:51:34leorizeyou're our async expert rn :P
19:52:21*s4mu3lbk quit (Ping timeout: 250 seconds)
19:53:53*jjido joined #nim
19:58:53*shadowbane joined #nim
20:21:24*zahary quit (Quit: Leaving.)
20:21:40*zahary joined #nim
20:22:10*zahary quit (Client Quit)
20:33:28*Hideki_ joined #nim
20:35:03*filcuc joined #nim
20:37:54*Hideki_ quit (Ping timeout: 250 seconds)
20:46:56axion@kaushalmodi: does your nim muscl still work these days?
20:47:47axionrayman22201: wow. hehe i'll have to play with this. clyybber also wrote a macro for me that i've been using successfully
20:52:21rayman22201I hope you get some use or educational value out of it lol. It was a fun little distraction for me either way. I love little macro puzzles like this :-)
20:53:01*NimBot joined #nim
20:56:29*shadowbane quit (Ping timeout: 250 seconds)
20:56:50*ksandvik quit (Quit: WeeChat 2.2)
21:03:58*al1ranger joined #nim
21:07:25*zahary joined #nim
21:11:09FromGitter<Kvothe87> @Yardanico Do you have any experience of zip library on windows?
21:11:38Yardanicowell, not really, but if you're having problems with .dll - you should get zlib dll from nim binary folder and copy it to your app's folder
21:12:34*zacharycarter joined #nim
21:16:23FromGitter<kaushalmodi> axion: Travis CI hasn't failed for that repo. So it should still be good
21:17:57FromGitter<kaushalmodi> yep, it still prints Hello World as of yesterday's Travis CI cron: https://travis-ci.org/github/kaushalmodi/hello_musl/jobs/664137510#L1362 :)
21:21:49axionNice. I found your blog a nice resource
21:22:16FromGitter<deech> Does `gc:destructors` mean that there should not be any reachable nodes after the program is done?
21:23:24leorizeno
21:23:32leorizedon't use gc:destructors
21:23:44leorizeit's not a working thing rn, use gc:arc
21:29:37*lritter quit (Ping timeout: 264 seconds)
21:36:54FromGitter<deech> Ok, should I expect that with `gc:arc`?
21:37:17FromGitter<deech> `valgrind` is showing still reachable blocks.
21:37:23leorizenope
21:38:40*narimiran quit (Ping timeout: 246 seconds)
21:39:23leorizefrom what I can tell, the system assumes that the OS will do the cleaning of any open resource on exit
21:39:30leorizealso destroying global variables are a pain
21:40:13FromGitter<deech> That makes sense so to clarify, this is "still reachable blocks" is expected behavior.
21:41:07leorizeyep
21:41:23*sagax quit (Quit: Konversation terminated!)
21:44:21*al1ranger quit (Quit: Leaving)
21:45:00*PMunch quit (Quit: leaving)
22:00:29FromDiscord<Recruit_main707> how can i have a type, lets say:
22:00:29FromDiscord<Recruit_main707> type Vector3* = object
22:00:29FromDiscord<Recruit_main707> x, y, z: float #and be able to initialise it as Vector3(10, 10, 10)
22:02:14Araqleorize, we do destroy global variabbles
22:02:19Yardanicoyou can't do that @Recruit_main707
22:02:25Yardanicoeither create a proc initVector or specify fields
22:02:37Yardanicolike Vector3(x: 10, y: 10, z: 10)
22:02:44FromDiscord<Recruit_main707> thats a pitty
22:02:54Yardanicoor proc initVector3(x, y, z: float): Vector3 = Vector3(x: x, y: y, z: z)
22:03:25FromDiscord<Recruit_main707> no plans on changing that right?
22:03:55FromDiscord<Recruit_main707> at least making fields be filled in order of declaration
22:03:57FromDiscord<Recruit_main707> ?
22:04:17Yardanicoi didn't hear of any
22:04:29Yardanicoit's not that bad actually, it seems fine for me
22:04:52FromDiscord<Recruit_main707> how it is? or changing it?
22:06:06*sagax joined #nim
22:07:05*abm quit (Quit: Leaving)
22:07:18Yardanicothe current way seems fine for me
22:13:10*zahary quit (Quit: Leaving.)
22:18:46*natrys quit (Quit: natrys)
22:21:05Araqyou can write a macro to automate it
22:22:17axionI'm not sure why I am getting an ambiguous call conflicting with system.min ONLY in runnableExamples...the same test outside of it works. Any ideas?
22:22:20*filcuc quit (Ping timeout: 250 seconds)
22:22:43axionI know I can just qualify the module prefix, but I'm not sure why it works outside of the runnable example
22:28:21*sagax quit (Ping timeout: 250 seconds)
22:28:57*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:31:07*sagax joined #nim
22:33:17FromDiscord<Recruit_main707> Araq: i just have no clue where to start with macros, i look at the examples, dont understand, and keep working with functions
22:34:54*solitudesf quit (Ping timeout: 250 seconds)
22:35:58FromDiscord<Rika> @Recruit_main707 well its just reading the `macros` module, using `treeRepr` or `lispRepr` a lot, and using `newTree` for generation or so
22:36:11leorizeAraq: so the cycle breaker got merged? does it magically save me from cycle with ARC now? :P
22:36:54Araqno, I merged it because I have too many rotting PRs
22:37:06Araqin the end 'when false' works better than git branches
22:56:43*disrupteq quit (Ping timeout: 246 seconds)
22:58:07*ptdel quit (Ping timeout: 246 seconds)
22:58:45*rockcavera joined #nim
22:59:11*ptdel joined #nim
23:04:38*couven92 joined #nim
23:16:23*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:16:55*Ven`` joined #nim
23:17:13*Ven`` quit (Client Quit)
23:17:26*gmpreussner quit (Ping timeout: 246 seconds)
23:18:11*gmpreussner joined #nim
23:28:15*tane_ quit (Quit: Leaving)
23:31:08*couven92 quit (Read error: Connection reset by peer)
23:44:44*cyraxjoe quit (Ping timeout: 246 seconds)
23:44:46*MightyJoe joined #nim
23:53:54*my_dude joined #nim
23:57:06*ptdel quit (Ping timeout: 256 seconds)