00:01:44 | FromGitter | <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:15 | FromGitter | <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:05 | FromGitter | <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:52 | FromDiscord_ | <exelotl> Oh wow I missed that 0.2.0 came out |
02:23:43 | FromDiscord_ | <exelotl> I should switch over soon and pray my game boy advance game still compiles :') |
02:24:09 | * | deech joined #nim |
02:26:58 | deech | How 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:00 | deech | Sorry, that should be 'let x : f(0) = true'. |
03:00:52 | leorize | shashlick: I'm gonna setup Linux jobs on circleci, the rest on azure |
03:01:53 | leorize | with that setup then circleci can run 2 build jobs |
03:02:00 | leorize | azure can run 2.5 build jobs |
03:02:33 | leorize | which should be balanced enough |
03:03:24 | leorize | ofc 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:02 | shashlick | @leorize - cool, i am planning on cleaning up nightlies to be more generic (not travis specific) |
04:10:17 | shashlick | also some packaging improvements |
04:11:01 | shashlick | but am wondering if i should bother putting effort into setting up build stages there |
04:16:11 | skrylar[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:36 | skrylar[m] | (although i suppose this is a more mercenary adoption of travis/azure configs purely to exploit free hardware, and little else) |
04:19:44 | leorize | eventually we'll need our own CI :P |
04:20:41 | * | envoyt joined #nim |
04:26:44 | skrylar[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:42 | skrylar[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:00 | FromDiscord_ | <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:04 | skrylar[m] | oh hey builtbot lives on python3 now |
04:43:06 | skrylar[m] | buildbot |
04:52:26 | shashlick | the fact that these CI are remote makes it hard to get things right quickly, have to run many iterations for simple commands |
05:24:41 | skrylar[m] | haven't used those particular ones. the ones i tend to poke are tantamount to running a bash script |
05:25:12 | skrylar[m] | not much harder to test than making a clean build environment |
05:26:05 | skrylar[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:47 | skrylar[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:23 | shashlick | Well there are always crazy bugs in Travis that causes random issues |
05:36:45 | shashlick | Incomplete logs |
05:36:55 | skrylar[m] | rip |
05:37:00 | shashlick | Total pain getting it to just work |
05:37:21 | shashlick | And after it does, you don't feel like touching it again |
05:39:46 | shashlick | And in my case, I conveniently forget and try again |
05:40:03 | skrylar[m] | time to update nim |
05:40:09 | skrylar[m] | tqdm has spoiled me for progress bars |
05:40:36 | skrylar[m] | only better one i've seen was a multi-bar for rust |
05:45:05 | laaron | is there someway to get last value of tuple like this: proc tail(t : tuple) : auto |
05:46:42 | skrylar[m] | isn't every tuple a type |
05:47:24 | skrylar[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:01 | skrylar[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:35 | skrylar[m] | it gives a useless `undefined identifier` error too, instead of `using out is deprecated` |
05:49:47 | skrylar[m] | this is seriously D- shit but whatever |
05:52:02 | laaron | let me try macro |
05:52:43 | FromGitter | <Varriount> skrylar: What was 'out'? |
05:54:01 | skrylar[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:13 | FromGitter | <Varriount> Ah |
05:54:25 | FromGitter | <Varriount> I don't ever recall that being documented anywhere |
05:54:57 | skrylar[m] | i seem to be a resident expert in having to fix everything during updates |
05:55:09 | skrylar[m] | and i've only been back for less than two weeks |
05:55:45 | skrylar[m] | anyway the messages module of thunderstrike is updated now |
06:15:30 | * | nsf joined #nim |
06:18:02 | leorize | `out` has never been put to use or implemented by the compiler :p |
06:18:41 | skrylar[m] | i have code that compiled with it on 0.19... |
06:19:27 | leorize | now that's weird |
06:19:30 | leorize | Araq: ^ |
06:20:43 | * | laaron quit (Quit: ZNC 1.7.1 - https://znc.in) |
06:20:50 | skrylar[m] | its even in the stock syntax highlighters in ex. kakoune |
06:20:55 | leorize | Araq 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:10 | leorize | skrylar[m]: yea, it's a part of the keyword list, just unused |
06:21:19 | leorize | that's used to be `func` fate |
06:21:37 | skrylar[m] | `unused` but it literally compiled like var 🥴 |
06:22:04 | skrylar[m] | anyway the code that used it has been updated now |
06:22:10 | * | laaron joined #nim |
06:22:19 | leorize | guess there was some plumbing code for it :p nothing related to out is in the commit log though |
06:22:58 | leorize | !eval proc a(b: out int) = discard |
06:23:00 | NimBot | <no output> |
06:23:07 | leorize | weird |
06:23:31 | skrylar[m] | that particular project is stalled until i hate myself enough to bind gdk/gtk3 |
06:23:48 | skrylar[m] | i think we already have winapi bindings |
06:24:11 | leorize | there's gintro... |
06:24:27 | leorize | it 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:18 | FromGitter | <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:32 | FromGitter | <mratsim> Somehow with the introduction of 0.20 (required for complex) I need 4GB of RAM to run Arraymancer's test suite ... |
07:20:22 | Araq | do you mean our 'complex' stdlib module? |
07:22:52 | FromGitter | <mratsim> yes |
07:23:28 | FromGitter | <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:48 | FromGitter | <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:06 | narimiran | @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:40 | FromGitter | <mratsim> yes |
07:54:52 | * | neceve joined #nim |
07:54:52 | * | neceve quit (Client Quit) |
07:55:14 | * | neceve joined #nim |
08:01:03 | FromGitter | <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:08 | Araq | there is no way except patching the compiler... |
08:07:29 | FromGitter | <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:53 | FromGitter | <mratsim> can we use testament from nimble/nimscript? |
08:17:16 | Araq | it'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:14 | FromGitter | <mratsim> I don't know where to start to use it :P |
08:48:20 | FromGitter | <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:41 | FromGitter | <mratsim> I'm doing the same before the "complex" change, I think it's generics resolution that may be too costly |
09:07:35 | lqdev[m] | shashlick: have you finished adding bitfield support to nimterop? |
09:44:06 | skrylar[m] | mratsim: i've ended up just using TAP for that ^^;; |
09:44:22 | FromGitter | <mratsim> TAP? |
09:44:59 | skrylar[m] | https://testanything.org/ with a very small testing unit to do the outputs |
09:45:49 | skrylar[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:09 | federico3 | https://testanything.org/tap-specification.html that's it? :( |
10:19:19 | FromGitter | <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:42 | lqdev[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:51 | lqdev[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:54 | clyybber | Araq: 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:04 | federico3 | how can I convert a Port to a binary string? |
12:14:58 | terorie | federico3: Serialized integer or base10 string? |
12:15:06 | terorie | in serialized |
12:16:47 | terorie | buf[0] = cast[uint8](port shr 8); buf[1] = cast[uint8](port) |
12:17:23 | * | lritter joined #nim |
12:17:47 | federico3 | serialized but I was assuming we have a stdlib proc for this |
12:41:01 | * | neceve quit (Ping timeout: 246 seconds) |
12:41:12 | federico3 | https://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:17 | Araq | clyybber: I like the idea but please focus on making the new spec work first |
13:02:25 | Araq | also: 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:57 | deech | Araq, https://irclogs.nim-lang.org/07-06-2019.html#23:37:25 |
13:24:49 | Araq | semProcTypeNode 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:39 | clyybber | Araq: 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:22 | clyybber | Otherwise the caller always cleans up the sink parameters, even if they are moved in all code paths of the callee |
13:36:31 | Araq | read the spec. |
13:36:39 | Araq | proc select(cond: bool; a, b: sink string): string = |
13:36:39 | Araq | if cond: |
13:36:40 | Araq | result = a # moves a into result |
13:36:41 | Araq | else: |
13:36:43 | Araq | result = b # moves b into result |
13:36:45 | Araq | proc main = |
13:36:47 | Araq | var x = "abc" |
13:36:49 | Araq | var y = "xyz" |
13:36:51 | Araq | # possible self-assignment: |
13:36:53 | Araq | x = select(rand() < 0.5, x, y) |
13:36:55 | Araq | # 'select' must communicate what parameter has been |
13:36:57 | Araq | # consumed. We cannot simply generate: |
13:36:59 | Araq | # (select(...); wasMoved(x); wasMoved(y)) |
13:37:35 | Araq | if you have a different solution for this very real problem you could try it |
13:39:10 | Araq | I personally think it's the better design to let the caller do the cleanup, always. |
13:46:50 | clyybber | Araq: What I propose is generating |
13:49:54 | clyybber | s/generating/inserting `=destroy`(a); `=destroy`(b) calls at the end of select's body instead of `=destroy`(x); `=destroy`(y) after select(...) |
13:54:44 | clyybber | Nevermind, 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:29 | Araq | this is subtle stuff, my spec is the 3rd or 4th iteration :P |
14:32:43 | Araq | can't beat it that easily |
14:36:37 | clyybber | Yeah, the amount of work/thinking you put into this spec really shows |
14:40:56 | clyybber | Araq: Gets really tricky when thinking about passing `someref[]` to sink parameters |
14:46:12 | Araq | well no, you have to do let tmp = someref[]; #[copy here]# toSinkParam(tmp) |
14:46:44 | Araq | the control flow analysis cannot prove someref[] will be the "last read", ergo copy required. |
14:47:36 | Araq | (yes, I know it sucks, but so far nobody has a better solution) |
14:48:42 | clyybber | Hmm, 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:31 | clyybber | we could do that, when we count the assignment of `x =` as a read |
14:50:05 | clyybber | and say that `select(...)` happens "before" `x = ...` |
14:51:41 | sealmove | At "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:08 | Araq | I 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:13 | sealmove | for i in 0..<x.len: `=destroy`(x.data[i]) |
14:52:23 | Araq | sealmove: probably |
14:52:55 | Araq | clyybber: so it seemed less elegant to me |
14:54:11 | sealmove | wow, anyone can edit it? |
14:56:33 | Araq | wasn't aware... |
14:56:59 | Araq | good that I have my own copy of it anyway as it'll be an appendix to the manual |
14:57:04 | Araq | bbl |
14:58:30 | * | fjellfras joined #nim |
15:04:18 | * | natrys quit (Quit: natrys) |
15:09:14 | clyybber | Araq: Yes it's less elegant in this case, but it opens the possibility for an optimization |
15:11:24 | clyybber | Namely, 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:35 | clyybber | The above example would then be transformed to: |
15:15:14 | clyybber | proc select(cond: bool; a, b: sink string): string = |
15:15:16 | clyybber | if cond: |
15:15:18 | clyybber | result = a # moves a into result |
15:15:20 | clyybber | `=destroy`(b) |
15:15:22 | clyybber | else: |
15:15:24 | clyybber | result = b # moves b into result |
15:15:26 | clyybber | `=destroy`(a) |
15:15:28 | clyybber | proc main = |
15:15:30 | clyybber | var x = "abc" |
15:15:32 | clyybber | var y = "xyz" |
15:15:34 | clyybber | # possible self-assignment: |
15:15:36 | clyybber | x = select(rand() < 0.5, (let tmp = x; #[copy here]# tmp), y) |
15:15:38 | clyybber | Y |
15:18:33 | clyybber | `=destroy`(x) |
15:18:58 | clyybber | #disregard that outlier y, it's a typo |
15:21:59 | clyybber | So 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:02 | sealmove | why is it important to get rid of the nil check? |
15:24:24 | sealmove | for 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:40 | clyybber | sealmove: That's one reason, the other one would be performance. OTOH C compilers optimize, but thats not really reliable |
15:27:41 | clyybber | And 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:10 | sealmove | So you are proposing to transform all self-assignments to normal moves by duplicating the value |
15:45:29 | FromDiscord_ | <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:19 | sealmove | No, Nim doesn't support postfix notation. The exception is `*` for exporting names. |
15:48:43 | sealmove | https://nim-lang.org/docs/macros.html#callsslashexpressions-postfix-operator-call |
15:50:31 | FromGitter | <alehander42> You can do it in some contexts |
15:50:38 | FromGitter | <alehander42> But it's limited indeed |
15:52:33 | * | fjellfras quit (Ping timeout: 245 seconds) |
15:52:55 | sealmove | clyybber: why the `=destroy` in the last row of your snippet? |
15:52:57 | shashlick | @lqdev not yet, probably sometime today or tomorrow for sure |
15:54:25 | clyybber | sealmove: Because x was not moved, but a copy of x was moved into the sink. |
15:54:59 | clyybber | It's the (copy-to-sink) rule |
15:55:27 | sealmove | yes but we are assigning a value to x in this case :P |
15:56:02 | clyybber | Yes? |
15:56:13 | sealmove | so `result` will move into x, and the `=move` will take care of calling `=destroy` |
15:56:39 | clyybber | Yes? |
15:56:49 | clyybber | But afterwards x will have a value |
15:57:06 | clyybber | insert a mental `...` between the last two lines :p |
15:57:27 | sealmove | Ahh you mean at the end of scope, I see, sorry. |
15:57:53 | clyybber | yeah, sorry, I left out the "finally:" in this example |
15:58:52 | * | deech_ joined #nim |
16:08:28 | * | fjellfras joined #nim |
16:12:46 | sealmove | I 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:52 | federico3 | recommended 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:52 | Araq | clyybber: in general you cannot optimize away the '!= nil' check, it is required to see whether it got moved or not. |
18:00:24 | Araq | secondly, for the snippets I tested with clang, clang was surprisingly clever in optimizing them out when it could |
18:00:49 | Araq | don't assume, measure. |
18:01:59 | Araq | one 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:00 | gearshift | is sha256 going to be added to the stdlib before v1.0? |
18:04:10 | gearshift | it'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:09 | Araq | gearshift: there are third party Nimble packages that provide it |
18:16:35 | Araq | clyybber: and finally, if you want to optimize further, write an optimizer. |
18:17:36 | Araq | indication that you're currently not writing an optimizer: the spec requires it. ;-) |
18:19:17 | gearshift | but there's already md5 and sha1 in the stdlib and sha256 is used much more often |
18:19:44 | Araq | legacy cannot be used as an argument for consistency. |
18:19:48 | leorize | 3rd party packages do this much better than the stdlib |
18:19:49 | leorize | checkout 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:47 | Araq | sealmove: 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:54 | FromDiscord_ | <lmariscal> Araq do you have or know any good resource to introduce Nim at work? |
18:33:54 | gearshift | Araq: so md5 and sha1 are kept for legacy reasons? i didn't know that |
18:35:16 | gearshift | leorize: thanks i'm aware of that i was just wondering why it wasn't already included in the stdlib |
18:36:21 | Araq | lmariscal: I had some nice slides |
18:36:21 | * | Serentty left #nim ("User left") |
18:36:46 | Araq | let me compile them... |
18:37:54 | Araq | gearshift: pretty much yeah. however, the discussion about what the stdlib should be are never-ending. |
18:38:07 | * | Vladar joined #nim |
18:41:55 | Araq | we should have a Tesla distribution that bundles Nim with a selected set of Nimble packages. |
18:43:04 | FromDiscord_ | <lmariscal> and there would be a fight over which packages would go in there haha |
18:43:22 | gearshift | yeah it was kind of weird i had to get a library for sha256 when i saw the others were already included |
18:44:12 | xace | !eval import io; discard |
18:44:14 | NimBot | Compile failed: in.nim(1, 8) Error: cannot open file: io |
18:44:24 | xace | ^^ why? |
18:48:18 | Araq | !eval echo NimVersion |
18:48:22 | NimBot | 0.19.6 |
18:48:37 | Araq | ^ 19.6 doesn't understand io.nim |
18:48:47 | Araq | also: io.nim is still part of system.nim |
18:49:02 | xace | Araq: im getting the same on nim 0.20.0 |
18:49:33 | Araq | I'm not sure. but as I said, it's still part of system, no need to import it |
18:50:08 | xace | oki, ill try |
18:52:20 | sealmove | so what happens in case of ` x = select(rand() < 0.5, x, y) ` after all? |
18:53:02 | gearshift | given the popularity of sha256 i think it would be a welcome addition to the stdlib |
18:53:24 | gearshift | even 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:21 | Araq | "set of popular hashes"? there are hundreds of them :P |
19:05:22 | sealmove | Araq: This can be treated as the general case, but then we might have 2 unnecessary moves, is this the problem? |
19:06:24 | Araq | you lost me |
19:06:56 | Araq | what's the "general case"? which moves are unnecessary? |
19:13:23 | gearshift | "set of *the* popular hashes" aka the ones everyone uses in day to day life lol |
19:17:03 | sealmove | Araq: sorry, ignore what I said about `move`s. What about disallowing self-assignments all-together? |
19:17:30 | sealmove | Then the user is forced to make the tmp var. |
19:23:07 | sealmove | Is it impossible to detect? |
19:25:41 | * | pydsigner quit (Excess Flood) |
19:25:54 | * | pydsigner joined #nim |
19:44:49 | Araq | sealmove: no, it seems feasible but I feared the shitstorm |
19:45:24 | Araq | "waa, new Nim runtime cannot even do assignments properly, I'm sticking to the old Nim" |
19:47:12 | Araq | however, 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:23 | sealmove | yes, the problem is not the self-assignment but the possibility of select() destroying x when it shouldn't. |
19:59:05 | deech | Araq, even with the new runtime you're still planning on keeping the deferred rc option, yes? |
20:01:34 | Araq | deech: it'll be with us for years to come |
20:02:51 | deech | Awesome. Having a well tuned GC *and* a typesafe RAII option will put Nim ahead of most. |
20:04:52 | Araq | well define "well tuned", nowadays we're losing quite often against Boehm |
20:06:05 | Araq | the problem with Boehm though is that it's unpredictable, what do you do when it crashes... |
20:06:45 | deech | IME 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:51 | Araq | the 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:54 | Araq | somebody needs to fix the hardware to make atomicInc really fast if uncontested. |
20:10:23 | Araq | but 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:17 | clyybber | Araq: 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:47 | Araq | var a = f() |
20:47:58 | Araq | if cond: container.add(a) # moves |
20:48:19 | Araq | =destroy(a) # don't dealloc the memory, the container could own it now. or not. |
20:50:18 | clyybber | Araq: Thats why I'm proposing branch based destructor injection |
20:50:23 | clyybber | so that the above becomes |
20:50:28 | clyybber | var a = f() |
20:50:53 | clyybber | if cond: container.add(a) #moves |
20:51:03 | clyybber | else: `=destroy`(a) |
20:51:18 | Araq | I see |
20:53:28 | Araq | three problems with that: |
20:53:51 | sealmove | what is `=sink`? :P |
20:53:56 | Araq | 1. it's harder to implement that you think |
20:54:01 | Araq | *than |
20:54:17 | Araq | 2. exception safety gets in the way |
20:55:13 | Araq | 3. the check in =destroy is generally necessary for most containers that do not allocate for the "empty" container (strings, seqs, ...) |
20:57:20 | sealmove | `=sink` because `=move` right? |
20:57:25 | sealmove | became* |
20:57:30 | Araq | if 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:54 | Araq | often we know =selfcheck is always false |
20:58:16 | clyybber | 1. Yep, probably. |
20:58:42 | Araq | often 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:45 | clyybber | 3. 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:48 | Araq | but 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:49 | Araq | however, this 'init(x); if not init(x): destroy(x)' is really *very* annoying, it prevents us from implementing emplace_back() |
21:07:02 | FromGitter | <Varriount> Araq: How goes the new runtime? |
21:08:44 | lqdev[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:06 | Araq | Varriount: 0.20 was quite stressful so I'm taking a break and work on nimpretty |
21:13:40 | * | natrys quit (Quit: natrys) |
21:16:21 | FromGitter | <Varriount> Araq: Oh, neat! |
21:16:35 | Araq | progress tracking is here: https://github.com/nim-lang/Nim/issues/11217 |
21:16:49 | FromGitter | <Varriount> Araq: I'm very happy about the release! |
21:17:14 | Araq | lqdev[m]: report it properly |
21:19:22 | sealmove | `=sink` doesn't exist in new spec, right? |
21:19:32 | Araq | right |
21:19:58 | sealmove | ok, you accidentally wrote `=sink` instead of `=move` somewhere, so I edited |
21:32:05 | * | nsf joined #nim |
21:39:26 | FromDiscord_ | <lmariscal> does nim have a good simd optimized linear algebra lib for graphics? |
21:39:41 | FromDiscord_ | <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:27 | Araq | ask nimble |
22:14:36 | FromDiscord_ | <lmariscal> nimble says no |
22:14:40 | FromDiscord_ | <lmariscal> so I guess no |
22:15:12 | FromDiscord_ | <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:13 | FromGitter | <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) |