🦋 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
|