🦋 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.
00:45 epony left 01:03 kvw_5_ joined 01:06 kvw_5 left 01:11 epony joined
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
02:55 epony left 03:06 epony joined
japhb BAK 04:33
05:48 softmoth left
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: ^^^
07:57 linkable6 left 07:58 linkable6 joined 08:08 Geth joined
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
10:44 Geth left, Geth joined
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
10:56 Kaiepi left 10:57 Kaiepi joined
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
11:52 Kaiepi left 11:53 Kaiepi joined 12:04 Kaiepi left, epony left 12:21 Kaiepi joined 12:30 epony joined
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
12:55 epony left
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"
13:10 Kaiepi left, Kaiepi joined
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
13:19 domidumont joined
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
13:37 Kaiepi left, Kaiepi joined
nine With the added twist that we only want to use those factors for the multiplications where we know they are precise 13:37
14:10 Kaiepi left
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
14:12 Kaiepi joined 14:13 Kaiepi left, Kaiepi joined
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
14:41 epony joined
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
14:43 b2gills left 14:44 b2gills joined
lizmat made one minor change re SetHash.grab 14:48
afk for a few hours&
15:07 titsuki joined 15:13 epony left 15:35 titsuki left 15:37 titsuki joined
[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.
15:57 epony joined 16:13 domidumont left 16:18 domidumont joined 16:54 bloatable6 joined 17:23 notable6 joined 17:31 Xliff joined
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
17:44 domidumont left 18:00 Kaiepi left 18:01 Kaiepi joined 18:02 Geth left 18:10 epony left 18:17 MasterDuke left 18:19 Kaiepi left 18:25 MasterDuke joined 18:30 Kaiepi joined 18:34 Kaeipi joined 18:35 Kaiepi left 18:56 Kaeipi left 18:57 Kaeipi joined 19:09 ChanServ sets mode: +o lizmat
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
19:11 ChanServ sets mode: -o lizmat 19:49 Xliff left 20:17 Kaeipi left 20:38 ChanServ sets mode: +o lizmat 20:40 lizmat sets mode: +k LizBot, lizmat sets mode: -k * 20:47 Kaiepi joined 21:10 epony joined 21:16 maggotbrain left, nine left, tyil left, moon-child left, commavir left, |Tux| left, jjatria left, notable6 left, bloatable6 left, linkable6 left, nativecallable6 left, leont left, committable6 left, quotable6 left, statisfiable6 left, benchable6 left, releasable6 left, bisectable6 left, chansen_ left, ugexe left, tbrowder left, SmokeMachine left, b2gills left, dogbert11 left, LizBot left, sena_kun left, raydiak left, gugod left, literal left, MasterDuke left, greppable6 left, tellable6 left, unicodable6 left, jdv79 left, bartolin_ left, rba left, zostay left, kawaii left, djinni` left, camelia left, epony left, finsternis left, HarmtH left, kvw_5_ left, brown121407 left, rypervenche left, moritz left, Kaiepi left, cog left, japhb left, eater left, tonyo left, krunen left, sjn left, samcv left, klapperl left, samebchase- left, nebuchadnezzar left, kvw_5_ joined, brown121407 joined 21:17 notable6 joined, bloatable6 joined, b2gills joined, linkable6 joined, dogbert11 joined, LizBot joined, sena_kun joined, nativecallable6 joined, leont joined, committable6 joined, quotable6 joined, statisfiable6 joined, benchable6 joined, releasable6 joined, bisectable6 joined, chansen_ joined, |Tux| joined, maggotbrain joined, MitarashiDango[m joined, summerisle joined, [Tux] joined, gugod joined, tyil joined, nine joined, commavir joined, moon-child joined, jjatria joined, SmokeMachine joined, tbrowder joined, ugexe joined, raydiak joined, literal joined, MasterDuke joined 21:18 patrickbkr[m] joined, rypervenche joined, moritz joined, samebchase- joined, nebuchadnezzar joined, AlexDaniel` joined, uzl[m] joined, samcv joined, klapperl joined 21:19 Kaiepi joined, cog joined, japhb joined, eater joined, tonyo joined, krunen joined, sjn joined, greppable6 joined, tellable6 joined, uzl[m] left, MitarashiDango[m left 21:20 unicodable6 joined, jdv79 joined, bartolin_ joined, AlexDaniel` left, rba joined, zostay joined, kawaii joined, djinni` joined, camelia joined, kawaii left 21:22 finsternis joined, HarmtH joined, gfldex joined, finstern1s joined, finsternis left, patrickbkr[m] left 21:23 kawaii joined 21:48 patrickbkr[m] joined, dogbert11 left 21:49 dogbert11 joined 21:58 AlexDaniel` joined, MitarashiDango[m joined, uzl[m] joined 22:28 dogbert17 joined 22:32 finstern1s is now known as finsternis 22:33 dogbert11 left 22:39 epony joined 22:52 dogbert11 joined, dogbert12 joined 22:55 dogbert17 left 22:56 dogbert11 left 23:01 dogbert17 joined 23:02 dogbert12 left 23:15 dogbert11 joined 23:19 dogbert17 left

Powered by Cro and the Raku® Programming Language.

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

Thank you!