<< 08-06-2019 >>

00:01:44FromGitter<Gooseus> ok, yeah, you're right, it's def something to do with nimsuggest, I'll see if I can fix or else disable
00:04:38*envoyt quit (Ping timeout: 268 seconds)
00:05:41*envoyt joined #nim
00:07:59*luis__ joined #nim
00:08:15FromGitter<Gooseus> looks like I had to set the nimsuggest path in my .spacemacs user-config, even though it seemed to be in my PATH - https://github.com/syl20bnr/spacemacs/issues/4403#issuecomment-172987432
00:09:34*luis_ quit (Ping timeout: 246 seconds)
00:10:24*jsonfrost joined #nim
00:18:05FromGitter<Gooseus> nope, that only seemed to work and then froze again - I disabled nimsuggest with `(setq nimsuggest-mode nil)` in the user-config of .spacemacs
00:21:14*luis__ quit (Remote host closed the connection)
00:40:28*jsonfrost quit (Remote host closed the connection)
00:46:59*deech joined #nim
00:47:42*krux02_ quit (Remote host closed the connection)
01:21:30*drewr joined #nim
01:30:08*c3v0axz quit (Ping timeout: 248 seconds)
01:30:21*c3v0axz joined #nim
01:53:31*deech quit (Ping timeout: 248 seconds)
02:04:12*sealmove quit (Quit: WeeChat 2.4)
02:22:52FromDiscord_<exelotl> Oh wow I missed that 0.2.0 came out
02:23:43FromDiscord_<exelotl> I should switch over soon and pray my game boy advance game still compiles :')
02:24:09*deech joined #nim
02:26:58deechHow do I return some 'typedesc' from a function? I want to do something like (all on one line for convenience): 'proc f(n:int):typedesc = if (n == 0): bool else: int; let x : n(0) = true'.
02:45:00deechSorry, that should be 'let x : f(0) = true'.
03:00:52leorizeshashlick: I'm gonna setup Linux jobs on circleci, the rest on azure
03:01:53leorizewith that setup then circleci can run 2 build jobs
03:02:00leorizeazure can run 2.5 build jobs
03:02:33leorizewhich should be balanced enough
03:03:24leorizeofc since we can also use other CI systems, we delegate more testing jobs for them, like 32 bit Windows or package testing on linux
03:14:05*laaron quit (Remote host closed the connection)
03:16:13*laaron joined #nim
03:33:23*deech quit (Ping timeout: 245 seconds)
03:49:33*theelous3_ quit (Ping timeout: 258 seconds)
03:57:26*laaron quit (Remote host closed the connection)
03:57:35*AndChat|624225 joined #nim
03:58:18*AndChat|624225 quit (Read error: Connection reset by peer)
03:58:44*AndChat|624225 joined #nim
03:59:48*laaron joined #nim
04:00:40*envoyt quit (Ping timeout: 272 seconds)
04:03:07*AndChat|624225 quit (Ping timeout: 248 seconds)
04:07:51*dddddd quit (Remote host closed the connection)
04:10:02shashlick@leorize - cool, i am planning on cleaning up nightlies to be more generic (not travis specific)
04:10:17shashlickalso some packaging improvements
04:11:01shashlickbut am wondering if i should bother putting effort into setting up build stages there
04:16:11skrylar[m]i guess it's just me, but i had very little trouble with basic jenkins setups. the new pipelines seemed to have more cognitive overhead than really necessary, but the old-school jobs seemed good enough for a lot :\
04:16:36skrylar[m](although i suppose this is a more mercenary adoption of travis/azure configs purely to exploit free hardware, and little else)
04:19:44leorizeeventually we'll need our own CI :P
04:20:41*envoyt joined #nim
04:26:44skrylar[m]for a while .. i think it was .18 or something, i just used a matrix plugin with jenkins to test some nimble packages against stable and crossbar with head
04:27:42skrylar[m]laminar-ci is really tight and tiny if you're only doing linux (mac is probably close enough to work too) but the tiny ones like laminar or less tiny like drone fall apart when you want mac and windows (buildbot might be lighter than jenk, although buildbot seemed.. awkward to me)
04:28:00FromDiscord_<j$> is there a way to get the path of a file object?
04:39:55*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
04:40:37*laaron joined #nim
04:43:04skrylar[m]oh hey builtbot lives on python3 now
04:43:06skrylar[m]buildbot
04:52:26shashlickthe fact that these CI are remote makes it hard to get things right quickly, have to run many iterations for simple commands
05:24:41skrylar[m]haven't used those particular ones. the ones i tend to poke are tantamount to running a bash script
05:25:12skrylar[m]not much harder to test than making a clean build environment
05:26:05skrylar[m]although travis is very wasteful from what i've read; inscentivizes people to do checkouts/redownload things every build, instead of caching in workspaces or prebaked images? :shrug:
05:31:47skrylar[m]Drone seems interesting in the sense that if you're a docker shop you can just test the build environments out locally before shoving the images to your ci server (but that still only works for linux builds.)
05:36:23shashlickWell there are always crazy bugs in Travis that causes random issues
05:36:45shashlickIncomplete logs
05:36:55skrylar[m]rip
05:37:00shashlickTotal pain getting it to just work
05:37:21shashlickAnd after it does, you don't feel like touching it again
05:39:46shashlickAnd in my case, I conveniently forget and try again
05:40:03skrylar[m]time to update nim
05:40:09skrylar[m]tqdm has spoiled me for progress bars
05:40:36skrylar[m]only better one i've seen was a multi-bar for rust
05:45:05laaronis there someway to get last value of tuple like this: proc tail(t : tuple) : auto
05:46:42skrylar[m]isn't every tuple a type
05:47:24skrylar[m]i mean you could have a macro inspect the type type it got and make a function to read that and return what you want, but nim tuples aren't haskell lists
05:49:01skrylar[m]the changelog on https://nim-lang.org/blog/2019/06/06/version-0200-released.html doesn't mention you can't use `out foo` parameters
05:49:35skrylar[m]it gives a useless `undefined identifier` error too, instead of `using out is deprecated`
05:49:47skrylar[m]this is seriously D- shit but whatever
05:52:02laaronlet me try macro
05:52:43FromGitter<Varriount> skrylar: What was 'out'?
05:54:01skrylar[m]@Varriount its `var` with the hint that it will be written (not read) so there's no confusion about passing uninitialized inputs
05:54:13FromGitter<Varriount> Ah
05:54:25FromGitter<Varriount> I don't ever recall that being documented anywhere
05:54:57skrylar[m]i seem to be a resident expert in having to fix everything during updates
05:55:09skrylar[m]and i've only been back for less than two weeks
05:55:45skrylar[m]anyway the messages module of thunderstrike is updated now
06:15:30*nsf joined #nim
06:18:02leorize`out` has never been put to use or implemented by the compiler :p
06:18:41skrylar[m]i have code that compiled with it on 0.19...
06:19:27leorizenow that's weird
06:19:30leorizeAraq: ^
06:20:43*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
06:20:50skrylar[m]its even in the stock syntax highlighters in ex. kakoune
06:20:55leorizeAraq has been meaning to remove `out` from the keywords list for quite a while now, since it's not used anywhere nor documented and I believe was never implemented
06:21:10leorizeskrylar[m]: yea, it's a part of the keyword list, just unused
06:21:19leorizethat's used to be `func` fate
06:21:37skrylar[m]`unused` but it literally compiled like var 🥴
06:22:04skrylar[m]anyway the code that used it has been updated now
06:22:10*laaron joined #nim
06:22:19leorizeguess there was some plumbing code for it :p nothing related to out is in the commit log though
06:22:58leorize!eval proc a(b: out int) = discard
06:23:00NimBot<no output>
06:23:07leorizeweird
06:23:31skrylar[m]that particular project is stalled until i hate myself enough to bind gdk/gtk3
06:23:48skrylar[m]i think we already have winapi bindings
06:24:11leorizethere's gintro...
06:24:27leorizeit even have gtk4 bindings
07:00:00*gmpreussner quit (Quit: kthxbye)
07:02:14*couven92 joined #nim
07:04:28*gmpreussner joined #nim
07:06:41*nsf quit (Quit: WeeChat 2.4)
07:10:01*laaron quit (Remote host closed the connection)
07:11:46*laaron joined #nim
07:13:18FromGitter<mratsim> Mmmh, I get OOM in CI with GCC 32/64 bits on Linux and mingw64 32-bit on windows, https://travis-ci.org/mratsim/Arraymancer/jobs/542973325#L1059, https://travis-ci.org/mratsim/Arraymancer/jobs/542973326, https://ci.appveyor.com/project/mratsim/arraymancer/builds/25131456/job/h20ihmw4e5urigro#L332
07:15:58*narimiran joined #nim
07:19:32FromGitter<mratsim> Somehow with the introduction of 0.20 (required for complex) I need 4GB of RAM to run Arraymancer's test suite ...
07:20:22Araqdo you mean our 'complex' stdlib module?
07:22:52FromGitter<mratsim> yes
07:23:28FromGitter<mratsim> I'm trying to check on an old commit: 0.19.6 vs 0.20.0 to see if it's related to complex or to 0.20
07:24:24*arecaceae quit (Remote host closed the connection)
07:24:44*arecaceae joined #nim
07:27:48FromGitter<mratsim> quick glance it's seems to be just related to complex but AFAIK I didn't see anything that would consume lots of memory in the module so it's probably in Arraymancer
07:30:30*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
07:30:52*laaron joined #nim
07:32:08*alexander92 joined #nim
07:34:06narimiran@mratsim btw, are you aware of `-d:danger` in 0.20?
07:41:49*fjellfras joined #nim
07:49:07*leorize quit (Remote host closed the connection)
07:49:35*leorize joined #nim
07:49:40FromGitter<mratsim> yes
07:54:52*neceve joined #nim
07:54:52*neceve quit (Client Quit)
07:55:14*neceve joined #nim
08:01:03FromGitter<mratsim> Is there a way to get the per-file compilation stats like we have at the end of a build ⏎ ⏎ > Hint: operation successful (104489 lines compiled; 9.922 sec total; 955.473MiB peakmem; Debug Build) [SuccessX]
08:04:11*vlad1777d quit (Ping timeout: 248 seconds)
08:06:08Araqthere is no way except patching the compiler...
08:07:29FromGitter<mratsim> I guess I will soon require to switch to a testament like setup, Arraymancer CI is getting really slow
08:10:03*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
08:10:41*laaron joined #nim
08:12:53FromGitter<mratsim> can we use testament from nimble/nimscript?
08:17:16Araqit's not a nimble package but give it a try, I want to be become Nim's testing tool instead of unittest.nim
08:18:40*alexander92 quit (Ping timeout: 248 seconds)
08:20:28*alexander92 joined #nim
08:22:08*Vladar joined #nim
08:22:11*Vladar quit (Remote host closed the connection)
08:22:35*Vladar joined #nim
08:26:13*alexander92 quit (Quit: WeeChat 2.4)
08:26:33*alexander92 joined #nim
08:45:05*leorize quit (Ping timeout: 256 seconds)
08:48:14FromGitter<mratsim> I don't know where to start to use it :P
08:48:20FromGitter<mratsim> Here are my compilation stats: https://github.com/mratsim/Arraymancer/issues/359#issuecomment-500107895
08:50:58*al_ joined #nim
08:51:40*leorize joined #nim
08:52:41FromGitter<mratsim> I'm doing the same before the "complex" change, I think it's generics resolution that may be too costly
09:07:35lqdev[m]shashlick: have you finished adding bitfield support to nimterop?
09:44:06skrylar[m]mratsim: i've ended up just using TAP for that ^^;;
09:44:22FromGitter<mratsim> TAP?
09:44:59skrylar[m]https://testanything.org/ with a very small testing unit to do the outputs
09:45:49skrylar[m]each suite is its own binary but the whole thing can be tripped from any number of testing harnesses
09:50:29*Vladar quit (Remote host closed the connection)
09:55:32*deech joined #nim
09:55:39*fjellfras quit (Ping timeout: 248 seconds)
10:00:06*natrys joined #nim
10:02:08*alexander92 quit (Ping timeout: 248 seconds)
10:03:56*alexander92 joined #nim
10:08:38*alexander92 quit (Ping timeout: 272 seconds)
10:15:09federico3https://testanything.org/tap-specification.html that's it? :(
10:19:19FromGitter<mratsim> yeah same reaction
10:20:40*deech quit (Ping timeout: 272 seconds)
10:21:43*i7sDream quit (Ping timeout: 245 seconds)
10:23:09*deech joined #nim
10:24:44*i7sDream joined #nim
10:34:31*nsf joined #nim
10:36:11*fjellfras joined #nim
10:36:55*fjellfras quit (Max SendQ exceeded)
10:37:25*fjellfras joined #nim
11:00:25*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
11:01:15*laaron joined #nim
11:05:42lqdev[m]`/home/daknus/Coding/Nim/rapid/tests/t_window.nim(35, 8) Warning: method has lock level <unknown>, but another method has 0 [LockLevel]`
11:05:51lqdev[m]what does this mean?
11:06:54*vlad1777d joined #nim
11:09:35*clyybber joined #nim
11:21:41*PMunch joined #nim
11:23:20*narimiran quit (Remote host closed the connection)
11:33:20*fjellfras quit (Ping timeout: 248 seconds)
11:36:54clyybberAraq: For eliding the destructors, I want to use the dfa to check wether all code paths `=move` a variable, and if so, elide the destructor for that variable. Wdyt?
11:40:25*dddddd joined #nim
11:55:40*fjellfras joined #nim
12:06:18*fjellfras quit (Ping timeout: 245 seconds)
12:06:59*AndChat|624225 joined #nim
12:08:58*envoyt quit (Ping timeout: 272 seconds)
12:14:04federico3how can I convert a Port to a binary string?
12:14:58teroriefederico3: Serialized integer or base10 string?
12:15:06teroriein serialized
12:16:47teroriebuf[0] = cast[uint8](port shr 8); buf[1] = cast[uint8](port)
12:17:23*lritter joined #nim
12:17:47federico3serialized but I was assuming we have a stdlib proc for this
12:41:01*neceve quit (Ping timeout: 246 seconds)
12:41:12federico3https://github.com/FedericoCeratto/nim-tor there
12:41:20*neceve joined #nim
12:46:14*jsonfrost joined #nim
12:47:03*leorize quit (Ping timeout: 256 seconds)
12:54:18*sealmove joined #nim
13:01:17Araqclyybber: I like the idea but please focus on making the new spec work first
13:02:25Araqalso: the C/C++ compiler will hopefully detect the dead destructors too and remove them for us
13:06:08*AndChat|624225 quit (Ping timeout: 248 seconds)
13:08:42*envoyt joined #nim
13:13:57deechAraq, https://irclogs.nim-lang.org/07-06-2019.html#23:37:25
13:24:49AraqsemProcTypeNode or typeAllowed
13:25:20*leorize joined #nim
13:29:43*PMunch quit (Remote host closed the connection)
13:29:43*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
13:30:56*laaron joined #nim
13:33:39clyybberAraq: Yeah, sure, but it probably makes more sense to make the callee responsible for cleaning up sink parameters if we want to employ destructor elision.
13:35:22clyybberOtherwise the caller always cleans up the sink parameters, even if they are moved in all code paths of the callee
13:36:31Araqread the spec.
13:36:39Araq proc select(cond: bool; a, b: sink string): string =
13:36:39Araq if cond:
13:36:40Araq result = a # moves a into result
13:36:41Araq else:
13:36:43Araq result = b # moves b into result
13:36:45Araq proc main =
13:36:47Araq var x = "abc"
13:36:49Araq var y = "xyz"
13:36:51Araq # possible self-assignment:
13:36:53Araq x = select(rand() < 0.5, x, y)
13:36:55Araq # 'select' must communicate what parameter has been
13:36:57Araq # consumed. We cannot simply generate:
13:36:59Araq # (select(...); wasMoved(x); wasMoved(y))
13:37:35Araqif you have a different solution for this very real problem you could try it
13:39:10AraqI personally think it's the better design to let the caller do the cleanup, always.
13:46:50clyybberAraq: What I propose is generating
13:49:54clyybbers/generating/inserting `=destroy`(a); `=destroy`(b) calls at the end of select's body instead of `=destroy`(x); `=destroy`(y) after select(...)
13:54:44clyybberNevermind, that could never work, sorry for not thinking :D
14:20:24*alexander92 joined #nim
14:25:04*alexander92 quit (Ping timeout: 248 seconds)
14:27:12*jsonfrost quit (Ping timeout: 248 seconds)
14:32:29Araqthis is subtle stuff, my spec is the 3rd or 4th iteration :P
14:32:43Araqcan't beat it that easily
14:36:37clyybberYeah, the amount of work/thinking you put into this spec really shows
14:40:56clyybberAraq: Gets really tricky when thinking about passing `someref[]` to sink parameters
14:46:12Araqwell no, you have to do let tmp = someref[]; #[copy here]# toSinkParam(tmp)
14:46:44Araqthe control flow analysis cannot prove someref[] will be the "last read", ergo copy required.
14:47:36Araq(yes, I know it sucks, but so far nobody has a better solution)
14:48:42clyybberHmm, right, so whats the problem if we transform `x = select(rand() < 0.5, x, y)` to `x = select(rand() < 0.5, (let tmp = x; #[copy here]# toSinkParam(tmp), y)`
14:49:14*theelous3_ joined #nim
14:49:31clyybberwe could do that, when we count the assignment of `x =` as a read
14:50:05clyybberand say that `select(...)` happens "before" `x = ...`
14:51:41sealmoveAt "Motivating Example" https://github.com/nim-lang/Nim/wiki/Destructors,-2nd-edition#id2 7th row, should it be x.data[i] instead of x[i]?
14:52:08AraqI considered it but it's a special case for the DFA and then you're still left with 2 'wasMoved', one in the callee, one in the caller
14:52:13sealmovefor i in 0..<x.len: `=destroy`(x.data[i])
14:52:23Araqsealmove: probably
14:52:55Araqclyybber: so it seemed less elegant to me
14:54:11sealmovewow, anyone can edit it?
14:56:33Araqwasn't aware...
14:56:59Araqgood that I have my own copy of it anyway as it'll be an appendix to the manual
14:57:04Araqbbl
14:58:30*fjellfras joined #nim
15:04:18*natrys quit (Quit: natrys)
15:09:14clyybberAraq: Yes it's less elegant in this case, but it opens the possibility for an optimization
15:11:24clyybberNamely, with a more or less scope based destructor injection implentation, (more like branch based), we could get rid of the `!= nil` check in `=destroy`
15:14:35clyybberThe above example would then be transformed to:
15:15:14clyybberproc select(cond: bool; a, b: sink string): string =
15:15:16clyybber if cond:
15:15:18clyybber result = a # moves a into result
15:15:20clyybber `=destroy`(b)
15:15:22clyybber else:
15:15:24clyybber result = b # moves b into result
15:15:26clyybber `=destroy`(a)
15:15:28clyybberproc main =
15:15:30clyybber var x = "abc"
15:15:32clyybber var y = "xyz"
15:15:34clyybber # possible self-assignment:
15:15:36clyybber x = select(rand() < 0.5, (let tmp = x; #[copy here]# tmp), y)
15:15:38clyybberY
15:18:33clyybber `=destroy`(x)
15:18:58clyybber#disregard that outlier y, it's a typo
15:21:59clyybberSo yes we have one more temporary and it's destructor call in this edge case, but we get rid of the `!= nil` check in `=destroy`.
15:24:02sealmovewhy is it important to get rid of the nil check?
15:24:24sealmovefor ergonomics reasons when someone is making a destructor?
15:24:37*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
15:26:21*laaron joined #nim
15:26:40clyybbersealmove: That's one reason, the other one would be performance. OTOH C compilers optimize, but thats not really reliable
15:27:41clyybberAnd I think this is kinda hard for a C compiler to optimize since they need to check every `=destroy` invocation
15:27:53*al_ quit (Quit: al_)
15:44:10sealmoveSo you are proposing to transform all self-assignments to normal moves by duplicating the value
15:45:29FromDiscord_<Dexelon> Hello, I'm new to Nim and uh.. - is there any way where you can put operators at the back? Like for example `"oof wheelchair"?` and `true?`?
15:47:19sealmoveNo, Nim doesn't support postfix notation. The exception is `*` for exporting names.
15:48:43sealmovehttps://nim-lang.org/docs/macros.html#callsslashexpressions-postfix-operator-call
15:50:31FromGitter<alehander42> You can do it in some contexts
15:50:38FromGitter<alehander42> But it's limited indeed
15:52:33*fjellfras quit (Ping timeout: 245 seconds)
15:52:55sealmoveclyybber: why the `=destroy` in the last row of your snippet?
15:52:57shashlick@lqdev not yet, probably sometime today or tomorrow for sure
15:54:25clyybbersealmove: Because x was not moved, but a copy of x was moved into the sink.
15:54:59clyybberIt's the (copy-to-sink) rule
15:55:27sealmoveyes but we are assigning a value to x in this case :P
15:56:02clyybberYes?
15:56:13sealmoveso `result` will move into x, and the `=move` will take care of calling `=destroy`
15:56:39clyybberYes?
15:56:49clyybberBut afterwards x will have a value
15:57:06clyybberinsert a mental `...` between the last two lines :p
15:57:27sealmoveAhh you mean at the end of scope, I see, sorry.
15:57:53clyybberyeah, sorry, I left out the "finally:" in this example
15:58:52*deech_ joined #nim
16:08:28*fjellfras joined #nim
16:12:46sealmoveI don't understand Araq's solution in this part of the spec. "Consequence: sink parameters for objects that have a non-trivial destructor must be passed as by-pointer under the hood". Example?
16:13:52federico3recommended Postgres client?
16:22:52*Trustable joined #nim
16:35:37*natrys joined #nim
16:51:00*fjellfras quit (Quit: Leaving)
16:56:02*deech_ quit (Ping timeout: 244 seconds)
16:59:05*laaron quit (Remote host closed the connection)
17:01:13*laaron joined #nim
17:01:43*deech_ joined #nim
17:03:26*NimBot joined #nim
17:11:23*deech_ quit (Ping timeout: 268 seconds)
17:12:58*theelous3_ quit (Ping timeout: 246 seconds)
17:38:18*neceve quit (Ping timeout: 272 seconds)
17:50:41*laaron quit (Remote host closed the connection)
17:52:10*laaron joined #nim
17:59:52Araqclyybber: in general you cannot optimize away the '!= nil' check, it is required to see whether it got moved or not.
18:00:24Araqsecondly, for the snippets I tested with clang, clang was surprisingly clever in optimizing them out when it could
18:00:49Araqdon't assume, measure.
18:01:59Araqone way of thinking about it: the write barrier implementation moved from the heap to the stack where an optimizer can reason about it effectively.
18:04:00gearshiftis sha256 going to be added to the stdlib before v1.0?
18:04:10gearshiftit's funny the nim website provides sha256 hashes of your downloads but i can't check them in nim
18:05:07*jsonfrost joined #nim
18:16:09Araqgearshift: there are third party Nimble packages that provide it
18:16:35Araqclyybber: and finally, if you want to optimize further, write an optimizer.
18:17:36Araqindication that you're currently not writing an optimizer: the spec requires it. ;-)
18:19:17gearshiftbut there's already md5 and sha1 in the stdlib and sha256 is used much more often
18:19:44Araqlegacy cannot be used as an argument for consistency.
18:19:48leorize3rd party packages do this much better than the stdlib
18:19:49leorizecheckout nimcrypto
18:22:55*deech quit (Remote host closed the connection)
18:23:19*deech joined #nim
18:29:50*nsf quit (Quit: WeeChat 2.4)
18:31:47Araqsealmove: x = sinkParam is turned into =move(x, sinkParam), afterwards sinkParam is empty and you better propagate this to the caller in order to prevent the destruction
18:32:54FromDiscord_<lmariscal> Araq do you have or know any good resource to introduce Nim at work?
18:33:54gearshiftAraq: so md5 and sha1 are kept for legacy reasons? i didn't know that
18:35:16gearshiftleorize: thanks i'm aware of that i was just wondering why it wasn't already included in the stdlib
18:36:21Araqlmariscal: I had some nice slides
18:36:21*Serentty left #nim ("User left")
18:36:46Araqlet me compile them...
18:37:54Araqgearshift: pretty much yeah. however, the discussion about what the stdlib should be are never-ending.
18:38:07*Vladar joined #nim
18:41:55Araqwe should have a Tesla distribution that bundles Nim with a selected set of Nimble packages.
18:43:04FromDiscord_<lmariscal> and there would be a fight over which packages would go in there haha
18:43:22gearshiftyeah it was kind of weird i had to get a library for sha256 when i saw the others were already included
18:44:12xace!eval import io; discard
18:44:14NimBotCompile failed: in.nim(1, 8) Error: cannot open file: io
18:44:24xace^^ why?
18:48:18Araq!eval echo NimVersion
18:48:22NimBot0.19.6
18:48:37Araq^ 19.6 doesn't understand io.nim
18:48:47Araqalso: io.nim is still part of system.nim
18:49:02xaceAraq: im getting the same on nim 0.20.0
18:49:33AraqI'm not sure. but as I said, it's still part of system, no need to import it
18:50:08xaceoki, ill try
18:52:20sealmoveso what happens in case of ` x = select(rand() < 0.5, x, y) ` after all?
18:53:02gearshiftgiven the popularity of sha256 i think it would be a welcome addition to the stdlib
18:53:24gearshifteven if the others are legacy, having a complete set of the popular hashes without dependencies is helpful
19:01:06*arnetheduck quit (Quit: Leaving)
19:01:26*arnetheduck joined #nim
19:03:21Araq"set of popular hashes"? there are hundreds of them :P
19:05:22sealmoveAraq: This can be treated as the general case, but then we might have 2 unnecessary moves, is this the problem?
19:06:24Araqyou lost me
19:06:56Araqwhat's the "general case"? which moves are unnecessary?
19:13:23gearshift"set of *the* popular hashes" aka the ones everyone uses in day to day life lol
19:17:03sealmoveAraq: sorry, ignore what I said about `move`s. What about disallowing self-assignments all-together?
19:17:30sealmoveThen the user is forced to make the tmp var.
19:23:07sealmoveIs it impossible to detect?
19:25:41*pydsigner quit (Excess Flood)
19:25:54*pydsigner joined #nim
19:44:49Araqsealmove: no, it seems feasible but I feared the shitstorm
19:45:24Araq"waa, new Nim runtime cannot even do assignments properly, I'm sticking to the old Nim"
19:47:12Araqhowever, I need to clear up my example, x = select(rand() < 0.5, x, y) is not *really* a self assignment unless you inline it and even then 'result' should be a temp
19:51:16*alexander92 joined #nim
19:53:23sealmoveyes, the problem is not the self-assignment but the possibility of select() destroying x when it shouldn't.
19:59:05deechAraq, even with the new runtime you're still planning on keeping the deferred rc option, yes?
20:01:34Araqdeech: it'll be with us for years to come
20:02:51deechAwesome. Having a well tuned GC *and* a typesafe RAII option will put Nim ahead of most.
20:04:52Araqwell define "well tuned", nowadays we're losing quite often against Boehm
20:06:05Araqthe problem with Boehm though is that it's unpredictable, what do you do when it crashes...
20:06:45deechIME deferred RC is a great option for FFI both into and out of the the Nim runtime and occasional strings. It's probably bad for Futures.
20:07:51Araqthe other problem with deferred RC is that I know no way of making it threadsafe. I mean no way that is not a PITA
20:09:54Araqsomebody needs to fix the hardware to make atomicInc really fast if uncontested.
20:10:23Araqbut probably it's as fast as it can get on Haswell
20:23:10*envoyt quit (Ping timeout: 268 seconds)
20:24:19*couven92 quit (Read error: Connection reset by peer)
20:27:53*Vladar quit (Remote host closed the connection)
20:29:36*Tyresc joined #nim
20:47:17clyybberAraq: I can't think of a case where the '!= nil' is required, so whats the general case? I think it can always be statically determined.
20:47:47Araqvar a = f()
20:47:58Araqif cond: container.add(a) # moves
20:48:19Araq=destroy(a) # don't dealloc the memory, the container could own it now. or not.
20:50:18clyybberAraq: Thats why I'm proposing branch based destructor injection
20:50:23clyybberso that the above becomes
20:50:28clyybbervar a = f()
20:50:53clyybberif cond: container.add(a) #moves
20:51:03clyybberelse: `=destroy`(a)
20:51:18AraqI see
20:53:28Araqthree problems with that:
20:53:51sealmovewhat is `=sink`? :P
20:53:56Araq1. it's harder to implement that you think
20:54:01Araq*than
20:54:17Araq2. exception safety gets in the way
20:55:13Araq3. the check in =destroy is generally necessary for most containers that do not allocate for the "empty" container (strings, seqs, ...)
20:57:20sealmove`=sink` because `=move` right?
20:57:25sealmovebecame*
20:57:30Araqif you want to produce better code I would go for something like: 'instead of =move a type can also implement the more fine-grained '=selfcheck', '=rawcopy' and '=steal' primitives
20:57:54Araqoften we know =selfcheck is always false
20:58:16clyybber1. Yep, probably.
20:58:42Araqoften we know previously the var was unassigned so that we don't need the (init(x); if not init(x): destroy(x)) steps
20:58:45clyybber3. Then leave the check in for those containers, we still get the benefits for everything else
20:59:07*Trustable quit (Remote host closed the connection)
20:59:48Araqbut this extension can be done for strings/seqs as builtin, the spec doesn't need it. and then in v2 we add it to the spec so that others can use the same mechanism
21:00:49Araqhowever, this 'init(x); if not init(x): destroy(x)' is really *very* annoying, it prevents us from implementing emplace_back()
21:07:02FromGitter<Varriount> Araq: How goes the new runtime?
21:08:44lqdev[m]so I have `const GL_ONE = 1` and `const GL_ONE_MINUS_SRC_ALPHA: GLenum = GLenum(0x0303)`, and `glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA)`. for some reason using it standalone works, but when I try to have a tuple `tuple[src, dest: GLenum]` and create one using `(GL_ONE, GL_ONE_MINUS_SRC_ALPHA)` I get a type mismatch
21:11:06AraqVarriount: 0.20 was quite stressful so I'm taking a break and work on nimpretty
21:13:40*natrys quit (Quit: natrys)
21:16:21FromGitter<Varriount> Araq: Oh, neat!
21:16:35Araqprogress tracking is here: https://github.com/nim-lang/Nim/issues/11217
21:16:49FromGitter<Varriount> Araq: I'm very happy about the release!
21:17:14Araqlqdev[m]: report it properly
21:19:22sealmove`=sink` doesn't exist in new spec, right?
21:19:32Araqright
21:19:58sealmoveok, you accidentally wrote `=sink` instead of `=move` somewhere, so I edited
21:32:05*nsf joined #nim
21:39:26FromDiscord_<lmariscal> does nim have a good simd optimized linear algebra lib for graphics?
21:39:41FromDiscord_<lmariscal> cause glm is great but still looking for that simd optimization :/
21:45:32*jjido joined #nim
21:59:19*envoyt joined #nim
21:59:23*lritter quit (Ping timeout: 248 seconds)
21:59:31*clyybber quit (Quit: WeeChat 2.4)
22:13:52*jsonfrost quit (Remote host closed the connection)
22:14:27Araqask nimble
22:14:36FromDiscord_<lmariscal> nimble says no
22:14:40FromDiscord_<lmariscal> so I guess no
22:15:12FromDiscord_<lmariscal> https://github.com/davidgarland/sol could enter the category
22:29:21*pyotr joined #nim
22:35:17*pyotr quit (Quit: pyotr)
22:39:44*alexander92 quit (Quit: WeeChat 2.4)
22:49:13*PMunch joined #nim
23:06:13FromGitter<singularperturbation> Congrats on the new release! I love the improved error messages :)
23:10:02*luis_ joined #nim
23:13:39*nsf quit (Quit: WeeChat 2.4)
23:35:25*envoyt quit (Ping timeout: 244 seconds)
23:35:47*envoyt joined #nim
23:36:03*ng0 joined #nim
23:41:17*theelous3_ joined #nim
23:46:00*vegax87 quit (Ping timeout: 258 seconds)
23:52:31*luis_ quit (Ping timeout: 258 seconds)
23:53:28*ng0 quit (Quit: Alexa, when is the end of world?)
23:55:03*theelous3_ quit (Ping timeout: 245 seconds)