🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org). This channel is logged for the purpose of keeping a history about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs can be inspected at colabti.org/irclogger/irclogger_log/raku-dev | For MoarVM see #moarvm
Set by lizmat on 21 April 2021.
raydiak .tell japhb I checked out 0.0.3, those enums did help the clarity for sure. I noticed there's places you do numeric addition instead of bitwise OR. Seems like +| is probably semantically closer to the intentded meaning, though I don't know for sure which performs better on current rakudos 01:19
tellable6 raydiak, I'll pass your message to japhb
raydiak .tell japhb also, I'm not really concerned about it either way, but you said you were open to a persuasive argument about mu/any/nil/undefined/null: gist.github.com/raydiak/b8d2eb22b5...dfb1a794ba 01:20
tellable6 raydiak, I'll pass your message to japhb
japhb raydiak: I'm here. 01:21
tellable6 2021-04-23T11:04:11Z #raku-dev <raydiak> japhb cool deal! I'll check it out tomorrow, about to hit the hay. spent a sickening amount of time today riding the distro merry-go-round and now it's 4 AM
raydiak oh, cool. I was about to step outside but I'll be back in a couple minutes
japhb Yeah, I dunno which is faster. I tend to use + just because I figure if any ops are going to get optimization, base arithmetic is going to be on that list. 01:22
SGTM
raydiak: Read the gist. I think it's a decent argument, but it doesn't feel overwhelmingly so; appealing to our docs or error messages is sometimes a self-reinforcing thing (meaning its hard to tell the difference between "mostly correct" and "absolutely solid", and if it's the former and we treat it as the latter, we can't do better than that). 01:26
Still, I think you've got a good point, especially about Nil, and I'd like to hear some more thoughts. Anyone else care to comment on raydiak's gist? 01:27
Certainly I will say that supporting Mu is a bit of a pain, since e.g. === doesn't work with Mu arguments.
raydiak literally if you don't define something, it's Any. Not Mu. That's both spec and implementation. But I'm about out of steam on the front of that point, I personally don't think I'd use those things in places where I'd use CBOR anyway 01:29
and if I did, I can still write ~~ Any or :U, regardless of whether I'm testing againt Mu or Any 01:30
japhb If we don't support a particular undefined value, we can always substitute. For example, I could make CBOR undefined === Raku Any, and then have Raku Mu === CBOR "absent" (github.com/svaarala/cbor-specs/blo...t-tag.rst) 01:31
raydiak erm, not ~~ Any 01:32
japhb Hmmm, that's a little appealing actually.
raydiak absent is exactly what null/Nil is for. didn't know CBOR had an "absent"
japhb OK, so what are you suggesting for the three concepts (null, undefined, absent)? 01:34
raydiak it felt intuitive to my understanding of these concepts that null would be Nil and undefined would be Any. I didn't know there was an absent, so I hadn't considered it. all the abstractness after researching and writing that is making my brain feel squishy, whatever seems best to you is cool with me :) 01:35
japhb IIUC absent is intended for "this key doesn't exist", as opposed to "this key has an undef value" or "this column hasn't been filled yet"
To be clear, I very much appreciate you writing that up. Gives me stuff to think about. 01:36
At the very least, I'm going to keep trying to make the core Mu-safe on encode (meaning a Mu somewhere in a struct won't cause a problem), but it's totally reasonable to never produce Mu on decode. There is definitely usefulness to only producing non-Any if that's specifically intended, since as you point out it's the default type in most places. 01:38
Also, remember that we can add an extension relatively easily; Raku Mu could be specified as a new tagged undefined -- or even, a bit weirdly perhaps, a tag of a tag. 01:39
raydiak who knew...glad my drinking too much coffee and sprinting headlong down rabbitholes might be somewhat useful! yeah that's a wrinkle for sure, we use :exists for that in Raku 01:40
that's what I was thinking, Mu and many other things that don't map well to CBOR would be some tag thing 01:41
japhb Yeah, I haven't read all the tag specs yet, so I keep finding interesting bits.
raydiak the empty thing might be useful to serialize elements in Raku structures that don't :exist 01:43
or not empty, absent I mean 01:44
japhb The other thing I've done is extend my perf test script with different structures, from a JSON dump of the zef ecosystem to 100x100 matrices of various types, to large raw blobs. On basically every one, CBOR output is smaller than JSON (even with !pretty on the latter). Sometimes JSON::Fast is 3-5x faster, sometimes they're within 1.5x of each other, and for some cases (such as blobs) CBOR is so much
faster it's hard to accurately measure. (Orders of magnitude faster for packed arrays.)
raydiak: hmmm, yes. To be explicit about the not existing, yeah. 01:45
And of course, a fair number of the test structures don't roundtrip in JSON, but do RT in CBOR. 01:46
Still, I'd be happy if I could get CBOR handling to be strictly faster than JSON for All The Things.
(It's good to have goals. ;-) )
raydiak I really don't get how CBOR is anything like "binary JSON" like I've read in multiple places. they seem completely different to me 01:47
japhb Yeah, it's really not. JSON's *data model* is a strict subset of CBOR, but a fair number of formats can claim that. 01:48
*of CBOR's data model
raydiak well...it's more compact in many cases, so already faster over the wire! 01:49
japhb Given that JSON was pretty much intended to be "Look, we can all agree that every modern language wants these data types, right? So what if we had a serialization format that was just those?"
If you have a slow wire, yes. ;-)
Gotta run, BBL
raydiak o/ 01:50
japhb BAK 04:33
nine Funny: one of our release blockers (GH#4009 gmake fails on windows) ultimately depends on a MoarVM PR that's marked "After a release" (github.com/MoarVM/MoarVM/pull/1472) 07:57
sena_kun: ^^^
nwc10 nine: by what route of dependenies? 09:03
in that I can't see it, and that ticket has been marked as a blocker for some months, yet MoarVM's 1472 only appeared last week. So I'm confused. 09:05
and the MinGW issue is (I think) actually fixed by a combination of a fix in the relevant PR, and ony] has joined #raku-dev 09:06
04:33 < japhb> BAK
er.
*that* github.com/Raku/nqp/pull/716
Dear Firefox, X, dammit 09:07
none of which needs Ryū
nine nwc10: oh, I misread the discussion in github.com/MoarVM/MoarVM/pull/1385 09:43
sena_kun nine, re "After a release" - I think a misconception that one can control people's time with the blocker label is among the worst misconceptions I had while doing all this. :S 10:25
releasable6, status 10:26
releasable6 sena_kun, Next release will happen when it's ready. 2 blockers. 31 out of 191 commits logged (⚠ 1 warnings)
sena_kun, Details: gist.github.com/8875cd273b84b5a918...6b406c2e35
nine sena_kun: well you for sure can't control anyone's time with labels, but at least I try to give blockers higher priority. 10:45
sena_kun nine, you have my utmost respect for this. :) 10:46
releasable6, status 10:55
releasable6 sena_kun, Next release will happen when it's ready. 2 blockers. 58 out of 191 commits logged (⚠ 1 warnings)
sena_kun, Details: gist.github.com/cdaf2efd7323901c62...22117ea010
sena_kun releasable6, status 11:35
releasable6 sena_kun, Next release will happen when it's ready. 2 blockers. 86 out of 191 commits logged (⚠ 1 warnings)
sena_kun, Details: gist.github.com/e85f28a3172f295c85...14356dc6f4
sena_kun releasable6, status 12:42
releasable6 sena_kun, Next release will happen when it's ready. 2 blockers. 92 out of 191 commits logged (⚠ 1 warnings)
sena_kun, Details: gist.github.com/bd4e227b13676e9ab7...10082320df
nwc10 Also, I thought that github.com/Raku/nqp/pull/716 was good, but I'd like someone else to say whether it's daft or not. 13:03
lizmat doesn't think it's daft, but also feels out of her league to judge it 13:08
nwc10: do you feel this should be in the 2021.4 release ?
nwc10 I honestly don't know. It fixes the MinGW problem, and I don't think that it introduces new problems, but the MinGW problem was still a problem a month ago, so the cautious part of me thinks "probably better not to" 13:09
and also, there are many things where I think "reviewing this is out of my league"
lizmat then I propose we merge it after the 2021.4 release, unless sena_kun thinks it is a good idea to merge it now 13:10
nwc10 I'm fine with that. 13:11
Also, I might well be AFK for a few hours. Stuff "needs" doing outside
(and it's still daylight)
sena_kun no merge 13:15
lizmat m: dd "zip/zop/foo.bar".IO.basename # looks like we don't have an easy way to get to "foo" ? 13:20
camelia "foo.bar"
lizmat guess I'll settle for: 13:28
m: dd "zip/zop/foo.bar".IO.basename.split(".").head
camelia "foo"
nine lizmat: PR 716 seems very un-magical to me. It's closely related to the problem of calculating large exponents. The naive method of just multiplying in a loop from 1..exponent is quite slow and with floating points can be quite unprecise, since you do exponent number of multiplications.
lizmat well, if I had been RM, I would have merged it, but I'm not RM :-) 13:31
and I'm glad sena_kun *is*!
tonyo rm ?
lizmat Release Manager
tonyo ah 13:32
nine For example you could calculate 10^13 by just doing 13 multiplications. Or you re-use intermediary results. E.g. a = 10 * 10, then 10^13 is a * a * a * a * a * a * 10, i.e. 7 multiplications. But then you can set b = a * a and 10^13 becomes b * b * b * 10, i.e. only 5 multiplications
nine With the added twist that we only want to use those factors for the multiplications where we know they are precise 13:37
sena_kun releasable6, status 14:11
releasable6 sena_kun, Next release will happen when it's ready. 2 blockers. 160 out of 191 commits logged
sena_kun, Details: gist.github.com/f76840868d78e5d4a1...e17f0b5599
sena_kun releasable6, status 14:41
releasable6 sena_kun, Next release will happen when it's ready. 2 blockers. 191 out of 191 commits logged
sena_kun, Details: gist.github.com/b1c8d199f0d3934546...973b15f4b2
sena_kun please check github.com/rakudo/rakudo/wiki/ChangeLog-Draft for grammar, my writing is as awful as usual, feel free to reword 14:42
sena_kun goes after MoarVM log
lizmat made one minor change re SetHash.grab 14:48
afk for a few hours&
[Tux] Rakudo v2021.03-191-gea102883d (v6.d) on MoarVM 2021.03-61-gb553aba6f
csv-ip5xs0.829 - 0.833
csv-ip5xs-208.239 - 8.549
csv-parser26.542 - 27.442
csv-test-xs-200.371 - 0.373
test7.620 - 7.873
test-t1.966 - 1.989
test-t --race0.861 - 0.983
test-t-2034.018 - 34.059
test-t-20 --race9.972 - 10.320
 15:42
vrurg sena_kun: Forgot to post it yesterday. github.com/rakudo/rakudo/issues/4339 15:50
sena_kun vrurg, thanks. Phew, the results do not prevent the release.
Geth roast/6.c-errata: 7c20c1cfb6 | (Elizabeth Mattijsen)++ (committed by Altai-man) | S06-signature/errors.t
unival(42.2) shouldn't fail if (42.2).unival doesn't

Built-in sub versions should just pass on to their method counterparts.
  (42.2).unival returns NaN, unival(42.2) should as well, therefore this
test is incorrect.		 17:34
roast/6.c-errata: d51ae9444f | (Elizabeth Mattijsen)++ (committed by Altai-man) | S15-unicode-information/unimatch-general.t
Make unimatch test fail for the right reason

unimatch should always be called with at least 2 parameters as a sub, or one parameter as a method.
roast/6.c-errata: 1dd1a2ab6a | (Elizabeth Mattijsen)++ (committed by Altai-man) | S32-temporal/DateTime-Instant-Duration.t
Adjust troublesome Instant / Duration test

The test depended on the Instant / Durations actually having a Rat at their core. Since this may not be the case, an Instant or a Duration of 2/7 seconds, will not test correctly in real life, as 2/7 seconds can not actually be represented on any actual hardware now or in the future (other than by having Rats implemented in hardware I guess).		 17:35
lizmat 🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs can be inspected at colabti.org/irclogger/irclogger_log/raku-dev | For MoarVM see #moarvm 19:10

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!