🦋 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.
vrurg tbrowder: not before RakuAST/new dispatch lands in the master. 00:11
00:25 Xliff_ joined 00:27 Xliff left
japhb Why doesn't rakudo ever use unbox_u instead of unbox_i? I discovered this when I got an error that I traced down to trying to unbox (2**64 - 1), and traced down and back up the stack to find that MoarVM and NQP are both happy to support unbox_u, but it doesn't get used anywhere in Rakudo. 01:05
01:06 kvw_5_ joined 01:09 kvw_5 left
tbrowder vrurg: thnx 02:08
Xliff_ tbrowder: What was the question you asked vrurg? 02:23
02:23 Xliff_ left 03:25 lucasb left 05:35 nativecallable6 left, shareable6 left, tellable6 left, sourceable6 left, greppable6 left, quotable6 left, benchable6 left, bisectable6 left, unicodable6 left, committable6 left, notable6 left, evalable6 left, squashable6 left, linkable6 left, bloatable6 left, coverable6 left, statisfiable6 left, releasable6 left 05:36 bisectable6 joined 05:37 shareable6 joined, releasable6 joined, benchable6 joined, statisfiable6 joined 06:34 domidumont joined
lizmat japhb: re use of unbox_u : probably because it is moar specific? 07:12
japhb lizmat: Ah, that makes sense. 07:21
I mean, unfortunate, but I understand. 07:22
CBOR::Simple v0.0.2 uploaded to fez. Much more complete; almost all core codec functionality in place, aside from num16 support (because Rakudo doesn't yet, and I'm not (yet) faking it). 07:24
lizmat how would you fake that? as a Rat ? FatRat ?
japhb There are still a fair number of extensions that could usefully be added, and probably some more special Raku type round-trip handling, plus the "diagnostic view" which is for humans trying to figure out what got corrupted in a CBOR stream. 07:25
lizmat: I'd take a num32 and hand-reduce it to num16 with bit twiddling and write that out, and then reverse it on parse. 07:26
lizmat ah, so it is a 16 *bit* format
japhb Right
lizmat ok
japhb "half float" in other languages 07:27
Commonly used for computer graphics and machine learning.
07:27 patrickb joined
lizmat interesting 07:27
japhb The nice thing is that CBOR can round-trip exactly stuff that JSON had no hope of handling. Exact BigInt and Rational support, for instance, plus real DateTimes. 07:29
lizmat looks like the META6.json of your distribution doesn't link back properly to the repo :-(
japhb ??
japhb looks
lizmat the auth also looks weird? modules.raku.org/dist/CBOR::Simple...:zef:japhb
japhb Oh, because the source-url is https instead of git? That would be an mi6 thing, I think. 07:30
lizmat I don't see a source-url in the META
but I'm looking at 0.0.1
japhb Oh, 0.0.2 should have that fixed 07:31
lizmat ok, patience is in order then
ooc, if you upload to fez, shouldn't the auth be fez:xxx ?
japhb I think the double-zef in the URL is a fez thing. To use fez, your auth *has* to be 'zef:<username>'.
lizmat ah, not fez: then ? 07:32
strange
japhb Yeah, I think it's a FAQ though.
I always use 'fez checkbuild' before uploading, which checks that the META6 looks as it expects.
lizmat still doesn't explain the repetition in the URL
japhb Well, when I look at a search for it (modules.raku.org/search/?q=CBOR) I see a notation about zef/zef:japhb -- I'm guessing the first slash was converted to another colon? 07:34
tonyo: ^^ # Is that expected?
Are you still unable to see 0.0.2?
lizmat japhb: if you plan to support all forms of data in that format, why the ::Simple ?
yeah, only 0.0.1 07:35
japhb lizmat: Because the code is simple, it's not optimized like you have for JSON::Fast. So this is more the reference version, before one or more of us goes wild speeding it up. 07:36
lizmat is willing to have a look at that in time :-)
japhb (That said, if it turns out to be really easy to speed it up a lot without going full nqp::ops on it, I will.)
lizmat afk for breakfast& 07:37
japhb I suspect the biggest problem is going to be continuous extension of small buffers; I was able to speed up Cro::WebSocket at one point by just pre-allocating buffer space, and I haven't done that in the CBOR::Simple code.
Enjoy!
japhb is weirded out that lizmat can't see 0.0.2 -- I can see it with 'zef info CBOR::Simple', I can see it in modules.raku.org search, I can see it (and the tag) on github ... Hrrmph. 07:39
lizmat can see it now 08:15
guess I needed to reload the searchresults page
lizmat also sees some magical numbers: ($_ ~~ Any ?? 22 !! 23)); 08:18
raydiak those are the correct short count bits of the item headers. according to wikipedia "The values 20–23 are used to encode the special values false, true, null, and undefined" for major type 7 09:00
lizmat my point was: shouldn't those not also be Enums 09:01
raydiak ah, my mistake 09:02
09:35 lizmat is now known as lizmmat_, lizmmat_ is now known as lizmat
lizmat is playing with IRC::Client 09:37
raydiak I was going to suggest the counterpoint that the CBOR types and special values themselves aren't part of the public API, it'd only be a bit of help to internal readability. but then I wondered why the only enum in there is exported at all, which then got me wondering why null doesn't map to Nil and undefined to Any. which I figure perhaps was chosen for ability to round-trip both Mu and Any, but then how do
you represent Nil?
nwc10 japhb: C doesn't support 16 bit floats (in any standard way) does it? So bit fiddling *somewhere* is going to be needed. 09:39
Eric the half-a-float.
lizmat
.oO( half-sunk )
 09:48
09:52 lizmat is now known as lizmat_, lizmat_ is now known as lizmat, lizmat is now known as lizmat_ 09:53 lizmat_ is now known as lizmat 09:54 lizmat is now known as lizmat_, lizmat_ is now known as lizmat
Geth rakudo: 01a0c9349e | (Daniel Green)++ | src/core.c/DateTime.pm6
Give DateTime its own infix:<eqv>

Otherwise it falls back to Mu's, which just relies on the .raku output.		 09:58
rakudo: f872413141 | MasterDuke17++ (committed using GitHub Web editor) | src/core.c/DateTime.pm6
Merge pull request #4334 from MasterDuke17/give_DateTime_its_own_eqv

Give DateTime its own infix:<eqv>
patrickb github.com/rakudo/rakudo/pull/4331 is another candidate for merging (before the release?) 10:28
sena_kun patrickb, yes. 10:30
Geth nqp: 9858768b77 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump NQP to hopefully unblock Rakudo
 10:34
lizmat ok, I will merge that first as well 10:36
well, soon anyway :-)
sena_kun releasable6, status 10:46
releasable6 sena_kun, Next release will happen when it's ready. 3 blockers. 8 out of 188 commits logged (⚠ 1 warnings) 10:47
sena_kun, Details: gist.github.com/88ab71ae6bd8d0e157...ffa5e83407
Geth rakudo: 4e4c485660 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to hopefully unblock Rakudo
rakudo: c05b23f182 | niner++ (committed using GitHub Web editor) | src/core.c/CompUnit/Loader.pm6
Fix compilation failure with EVAL in precompiled module's mainline (#4331)

The error was reported as "Cannot look up attributes in a NQPMu type object" with a require in a module's mainline. The error message gets reported because QASTCompilerMAST cannot find the frame for a given CUID. The error only appeared when the require loaded an already installed and precompiled module and only if the repository chain got changed since (by way of 'use lib' or -I). ... (20 more lines)
sena_kun vrurg, can you start a Blin please? 10:48
nine niner committed 2 minutes ago Verified 10:50
Funny....I'm pretty sure 2 minutes ago I was getting some coffee :D
11:27 brrt joined
tbrowder .tell Xliff_ i asked vrurg about forecast for implementing version 'e' 11:31
.tell Xliff ^^^ 11:32
11:33 LizBot left 11:39 LizBot joined
lizmat PSA: LizBot is an experimental logger by yours truly 11:46
atm, it just logs
12:12 sena_kun left 12:14 sena_kun joined
lizmat ilogger2: VERSION 12:17
ilogger2 lizmat: I am a logger bot. Lines starting with [off] won't be logged. Extra help available at colabti.org/irclogger/irclogger_logs.
lizmat ilogger2: help
ilogger2 lizmat: I am a logger bot. Lines starting with [off] won't be logged. Extra help available at colabti.org/irclogger/irclogger_logs.
nwc10 ilogger2: botsnack
ilogger2 nwc10: I am a logger bot. Lines starting with [off] won't be logged. Extra help available at colabti.org/irclogger/irclogger_logs.
lizmat aha... that's something I forgot to implement :-) 12:18
12:18 Kaeipi left
lizmat [off] just checking 12:22
12:22 Kaiepi joined 12:26 LizBot left, LizBot joined
lizmat starting a line with [off] will now not log the message 12:28
nwc10 naff [off]
but that is logged? 12:29
lizmat yes, it should *start* with [off]
to not have it logged
12:31 Kaiepi left 12:32 Kaeipi joined 12:36 Kaeipi left 12:40 Kaiepi joined 12:41 LizBot left 12:42 LizBot joined 12:45 brrt left
lizmat IRC::Client::Plugin::Logger now on its way to the ecosystem 12:49
afk for a few hours& 12:50
13:04 shareable6 left, lizmat left, nwc10 left 13:05 shareable6 joined, lizmat joined, nwc10 joined
vrurg . 13:18
sena_kun: started
sena_kun vrurg++
13:23 Xliff joined
Xliff \o 13:25
I had a run-in with R#2378
github.com/rakudo/rakudo/issues/2378 13:26
nwc10 o/
Xliff Any idea if this is really fixable?
nwc10 reads, but has no idea about this sort of thing. 13:28
Geth nqp/new-disp: 34 commits pushed by (Jonathan Worthington)++
review: github.com/Raku/nqp/compare/f14c14...74f51fa5c5		 13:38
rakudo/new-disp: 35 commits pushed by (Jonathan Worthington)++
review: github.com/rakudo/rakudo/compare/4...97c4dfbd67
14:23 b2gills left
tonyo japhb: lizmat: yea that url repetition is expected. the format is <provider>/<auth> on m.r.o and provider is zef/zef:japhb 14:25
14:32 lucasb joined 14:34 lucasb left 14:35 lucasb joined 14:36 lucasb left 14:41 b2gills joined
Geth rakudo/new-disp: 9e1eed4975 | (Jonathan Worthington)++ | 2 files
Port coervice assignment changes from spesh plugin

These were added after it was ported to the new dispatcher mechanism. There's potential to optimize these rather better in the future, but for now just make it work.		 14:43
lizmat tonyo: but the auth is fez, is ot not?
so shouldn't that be zef/fez:japhb ? 14:44
14:50 brrt joined, ChanServ sets mode: +o lizmat 14:51 ChanServ sets mode: -o lizmat 14:54 LizBot left, LizBot joined, ChanServ sets mode: +o lizmat 14:55 ChanServ sets mode: -o lizmat
tonyo the auth string when you upload using fez is zef 14:55
eg, i'm zef:tony-o
14:55 LizBot left, LizBot joined
lizmat I find that counter-intuitive 14:56
when you're uploading to fez, "zef" is just another installation tool, like "panda" was
tonyo it's a zef ecosystem, fez is just the tool used to upload to it
right and to not lump the authoring tool and installation tool into one monolith, the reverse of zef (fez) is how you get stuff into the zef eco 14:57
lizmat so you are saying that no other installation tools will ever be able to use modules from the "zef" ecosystem ?
tonyo not at all
they can query the index and download source tars just as zef can 14:58
lizmat then I don't understand why it is called the "zef" ecosystem
patrickb the name clash is a bit unfortunate, but has no deeper meaning IIUC
lizmat tonyo: to be clear: I welcome the initiative 14:59
tonyo it's only named that because i worked on zef and i like that name, it's one of the more adopted things i've worked on
lizmat and, since I'm lazy, I'm waiting for App::Mi6 to transparently support fez upload
but then for sure my modules will move from PAUSE to zef 15:00
tonyo iirc that's coming soon. either patrickb or tbrowder mentioned something to me about that in gh issues
lizmat tonyo: suggest you start calling it the "Raku Community Ecosystem" 15:01
patrickb I think it was tbrowder who mentioned it. Skaji did the actual work: github.com/skaji/mi6/pull/122
tonyo you want i can change it in mro? RCE/zef:author
or are you suggesting auth be rce:author ? 15:02
lizmat because there's little doubt in my mind, it will replace the old ecosystem, and the make the use of PAUSE unnecessary
patrickb can someone explain the difference between auth and provider?
lizmat rce:author feels like a good way to describe it ?
tonyo there's around 30 authors in there right now that would need to update all of their stuff 15:03
lizmat better 30 now than 2000 later :-)
but you could for now allow zef:author as an alias of rce:author 15:04
until the next upload ?
of a module by an author I mean
tonyo about 230 modules in there right now 15:05
lizmat well, moving to fez would be 100+ modules for me 15:06
tonyo hmm .. kind of wary about messing with them. give me a couple of hours to think about how to migrate all of it
lizmat alone
patrickb auth is the guy responsible for a module and the format for auth is currently "zef:some_identifier" for everything uploaded on the zef eco. Whereas the provider is the website that hosts the stuff. Correct? 15:07
tonyo because it involves changing tooling on the backend as well
yea
auth is the spec .. the provider is just the backend _thing_ in the mro code
patrickb This is not the first time the naming talk was had. I'd really like we don't do another quick shot this time. 15:08
lizmat I missed the previous one, apparently
perhaps a problem solving issue then?
patrickb It went zef -> fez -> zef -(> rce?) 15:09
IIRC that is 15:10
tonyo rce:author ? 15:13
patrickb Unrelated question: The validation that fez currently does, is that replicated on the server? I.e. could I upload broken stuff by directly interacting with the server?
tonyo the auth with fez has always been just zef:auth - i had to do a reindex a little while ago because vrurg needed to remove something and there was no capability at that point 15:14
yea it's validated on the server
patrickb tonyo++
tonyo the architecture is kind of cool, give me a minute and i'll draw a picture
actually, it's just all in lambdas (tar verification|api endpoints) -> mq -> indexed 15:15
patrickb mq = message queue? 15:16
tonyo yea
15:17 LizBot left, LizBot joined 15:19 brrt left 15:23 LizBot left, LizBot joined 15:29 LizBot left 15:30 LizBot joined 15:34 brrt joined 15:36 Kaiepi left, Kaiepi joined 15:40 LizBot left, LizBot joined 15:42 ChanServ sets mode: +o lizmat, ChanServ sets mode: -o lizmat, patrickb left 15:43 brrt left 15:46 tellable6 joined, LizBot left, LizBot joined 15:49 ChanServ sets mode: +o lizmat, ChanServ sets mode: -o lizmat 15:53 LizBot left 15:54 LizBot joined 15:56 ChanServ sets mode: +o lizmat, ChanServ sets mode: -o lizmat 16:06 LizBot left, LizBot joined 16:07 ChanServ sets mode: +o lizmat, ChanServ sets mode: -o lizmat 16:12 ChanServ sets mode: +o lizmat 16:13 ChanServ sets mode: -oo lizmat tyil 16:14 ChanServ sets mode: +oo lizmat tyil 16:15 ChanServ sets mode: -oo lizmat tyil 16:22 LizBot left, LizBot joined, ChanServ sets mode: +o lizmat 16:23 LizBot left, LizBot joined, ChanServ sets mode: -oo lizmat tyil 16:25 greppable6 joined 16:26 brrt joined 16:54 domidumont left 17:06 lucasb joined 17:28 HarmtH left 17:35 quotable6 joined, MasterDuke left 17:41 HarmtH joined, finsternis joined 17:43 sxmx1 joined 17:44 brrt left 17:59 committable6 joined 18:05 LizBot left, LizBot joined 18:25 LizBot left, LizBot joined
lizmat ... 18:26
vrurg .tell sena_kun gist.github.com/vrurg/a608e01a44e5...205359cf9c 18:51
tellable6 vrurg, I'll pass your message to sena_kun
japhb Lots of backlog today, wheee ... 19:13
lizmat, raydiak: You're probably right that there should be more enums, and they should not be exported. This is why the version is 0.0.x with api version 0, because I'm just working as fast as I can and welcome the feedback. :-) 19:15
nwc10: Half floats in the current format were invented back in 1997, added to GPUs back in 2002, the 2008 IEE754 standard supported them as "binary16", Intel and AMD processors have supported them (with native "F16C" conversion instructions even) since 2011 or so, ARM supports a slight variant (GCC supports both variants), and ISO/IEC standardized the C extensions in 2015. I'd be shocked if we couldn't 19:28
find a freely-licensed library that has all the conversions for us.
nwc10 cool. But I more meant "they don't have any sort of type - float is (usually) 32 bit floats, and there isn't a `short float`" 19:29
japhb Yeah, it's supported as _Float16 apparently 19:30
Apparently GCC first supported them as __fp16, but now recommends using the standardized C names. 19:31
19:43 MasterDuke joined, linkable6 joined 19:52 leont left 19:58 leont joined
japhb Pushed enum reformed version to GitHub. 20:10
20:13 lizmat is now known as lismat, lismat is now known as lizmat 20:15 LizBot left, LizBot joined, lizmat is now known as lismat, lismat is now known as lizmat
japhb raydiak: You wondered why I chose CBOR null => Any:U, and CBOR undefined => Mu:U? I think the latter one makes sense, as it is in fact the "most undefined" thing in Raku, but I can easily be swayed on the first. Anyone want to argue whether CBOR null should map to Any, Nil, or some other value? 20:16
I think that's the last of the feedback I saw ... anything I missed? 20:17
Oh, I should mention that there is an assigned tag for "absent value", github.com/svaarala/cbor-specs/blo...t-tag.rst, which is interestingly used to tag a CBOR undefined rather than a CBOR null. 20:19
lizmat japhb: how would your module handle Junctions? 20:28
if it would not, then undefined => Any would be better maybe ? 20:29
japhb lizmat: Right now it does not. However, we can easily define an extension tag for it, if we want Junctions to round trip. 20:45
CBOR is general enough to allow just about any data type to be defined, we just need to decide how much of Raku we want to be able to serialize this way. 20:46
lizmat well, then I guess undefined would need to be Mu:U
japhb OK, looks like I have my work cut out for me. On equivalent (large) structures, JSON::Fast is about 5.1x faster on decode and 9.1x faster on encode (which ends up being about 7.3x faster round trip because for both libraries the encode side is heavier). Thankfully those are just the baseline "I have not yet begun to fight" numbers. :-) 20:49
tonyo what're you writing? 20:50
japhb tonyo: github.com/japhb/CBOR-Simple
jdv79 lizmat: how did you manage to lose that much weight? 20:55
lizmat eating less, moving more
jdv79 i should get on my bike more i guess
i've been moving less thanks to covid and such:(
lizmat basically monitor your calorie intake
make sure it's a few 100 less than what you need every day
roughly every 9000 / less per day = number of days to lose one kg 20:56
I try to do 500 less / a day
with cycling accounting for (avg speed - 11) / minute for calories lost in cycling 20:57
jdv79 how much cycling do you do on avg? 20:59
21:04 Kaiepi left, Kaiepi joined
lizmat well... I've done 2600 km this year so far 21:07
jdv79 wow
lizmat so that would be about 23.5 a day, every day 21:08
japhb Impressive!
lizmat but there've been some bad weather days: snow, sleet, rain, storm
so I think I've only cycled 75 days so far this year, with an average of 34 or so 21:09
jdv79 it was hailing y'day for a bit here
very random and rare
lizmat yeah, that's not nice when on a bicycle
note: *no* electric support whatsoever
jdv79 between pea and marble size i think
lizmat although woolfy helps me occasionally on the very difficult spots 21:10
yesterday 60km, today 28km, still felt the 60 from yesterday :-) 21:15
jdv79 ha 21:18
lizmat although my bicycle does have something modern: it has a NuVinci CVT 21:20
en.wikipedia.org/wiki/NuVinci_Cont...ansmission
NuVinci N380 to be precise 21:21
21:37 dogbert11 joined 21:39 dogbert12 joined 21:41 dogbert17 left, dogbert11 left 21:44 LizBot left, LizBot joined
lizmat sleep& 21:45
21:48 dogbert17 joined 21:52 dogbert12 left 22:29 sena_kun left 22:54 dogbert11 joined 22:58 dogbert17 left 23:17 Xliff left 23:40 nativecallable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!