00:38 librasteve_ left
Geth nqp: coke++ created pull request #847:
[Snyk] Upgrade jsbi from 2.0.5 to 4.3.2		 09:21
nqp/snyk-upgrade-c6f2fe28c7cecc4c2bdb770458f44761: be09e8b18b | snyk-bot++ | src/vm/js/nqp-runtime/package.json
feat: upgrade xregexp from 3.2.0 to 5.1.2

Snyk has created this PR to upgrade xregexp from 3.2.0 to 5.1.2.
See this package in npm: xregexp
See this project in Snyk:
  app.snyk.io/org/raku.org-default/p...upgrade-pr
nqp/snyk-upgrade-8d035f37c3fa470720e550c132dbfaad: 92341f5fbe | snyk-bot++ | src/vm/js/nqp-runtime/package.json
feat: upgrade jsbi from 2.0.5 to 4.3.2

Snyk has created this PR to upgrade jsbi from 2.0.5 to 4.3.2.
See this package in npm: jsbi
See this project in Snyk:
  app.snyk.io/org/raku.org-default/p...upgrade-pr
nqp: coke++ created pull request #848:
[Snyk] Upgrade xregexp from 3.2.0 to 5.1.2
nqp/snyk-upgrade-1975e304fce6f3c620fb69bf8b6edd60: 565f513a95 | snyk-bot++ | src/vm/js/nqp-runtime/package.json
feat: upgrade ref-napi from 1.5.2 to 3.0.3

Snyk has created this PR to upgrade ref-napi from 1.5.2 to 3.0.3.
See this package in npm: ref-napi
See this project in Snyk:
  app.snyk.io/org/raku.org-default/p...upgrade-pr
nqp: coke++ created pull request #849:
[Snyk] Upgrade mkdirp from 0.5.6 to 3.0.1
nqp: coke++ created pull request #850:
[Snyk] Upgrade ref-napi from 1.5.2 to 3.0.3
nqp/snyk-upgrade-4a30655238b01663f20b40ddc4cb802b: cfd7016937 | snyk-bot++ | src/vm/js/nqp-runtime/package.json
feat: upgrade mkdirp from 0.5.6 to 3.0.1

Snyk has created this PR to upgrade mkdirp from 0.5.6 to 3.0.1.
See this package in npm: mkdirp
See this project in Snyk:
  app.snyk.io/org/raku.org-default/p...upgrade-pr
lizmat which makes me wonder we should ditch the JS backend altogether :-( 09:30
Geth raku.org: librasteve++ created pull request #318:
Pico2.10		 09:40
10:21 hurufu joined
hurufu Hello all, I don't know where is a good place to write, but this channel seems to be right place. I'm current maintainer of moarvm, nqp and rakudo AUR packages. Recently I wanted to add signature validation (using .asc file) in addition to checksums. But I can't find public key that was used to sign latest release. Can someone help me with that? 10:27
Public key fingerprint that I'm looking is 0F09888FE017A4C2.
lizmat I'm not sure we have an official one atm, patrickb [Coke] ? 10:28
hurufu I tried github.com/coke.gpg and github.com/jdv.gpg, but they seem to have different fingerprint from what I see is needed... idk 10:30
11:59 hurufu left
timo salsa.debian.org/perl6-team/moarvm...25a6e7f905 I think this is the right key? 12:00
but we should definitely have the key posted somewhere public and verifibale in some way
[Tux] Rakudo v2026.04-111-g8c5157ae0 (v6.d) on MoarVM 2026.04-26-gf2e25d78d
csv-ip5xs0.264 - 0.273
csv-ip5xs-201.082 - 1.402
csv-parser1.055 - 1.082
csv-test-xs-200.113 - 0.115
test1.798 - 1.832
test-t0.456 - 0.460
test-t --race0.289 - 0.296
test-t-205.911 - 6.259
test-t-20 --race1.399 - 1.435
 12:07
csv-test-xs 0.015 - 0.017
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
timo did someone already do some kind of research or planning for how we should compare the rakuast-built core setting vs the legacy-built core setting to spot what exact differences because of optimization we have between the two? 12:09
lizmat nine might have, but other than that, I don't think so: the focus has been on making it work 12:10
timo we could compare the output of moar --dump of the precompiled files, or the QAST from --target=optimize and the equivalent on the rakuast backend
yeah, that makes sense 12:11
the output of moar --dump isn't perfect for diffing, since many things are numbered and when something causes numbers to shift, that gives you differences in the rest of the file 12:13
so a "canonicalization" step could be good there
patrickb hurufu: Look here: rakudo.org/downloads/verifying 12:14
timo is that the right key actually? 12:15
patrickb If none of the keys there match, then something's wrong and we should look into it.
Depends on who did the release. Last one was Coke, right? 12:16
timo yeah, coke has done releases for a good little while now 12:17
12:19 hurufu joined
[Coke] I have had to change mine at least once since I started being release manager. 12:21
and I probably forgot to add the new one there. 12:22
I assume we should keep the historic ones there as well?
(change) because it expired 12:23
timo yes, historic ones should stay there as well, since you can still download releases signed with them 12:26
[Coke] I'll get this sorted today, apologies.
(that key exists on the blin/release box I azure in azure, have to spin it up, pull it down, put it on the website+github..) 12:27
timo [Coke]: the commit I linked has the public key that you gave me at some point, is that the correct one? then you can just take that :) 12:28
it's the public key, after all
[Coke] hurufu: added to github.com/coke, at least 12:41
Thank you for the ping.
hurufu Thanks a lot for giving references to public keys, but I'm afraid the latest package wasn't signed by any of them. There are 5 public keys at rakudo.org/downloads/verifying#gpg2-key-list they are:
rakudo.org/keys/justin_devuyst-59E...887C01.asc
 keyid: 602D51EACA887C01
 keyid: B5B563CD0CD39322
rakudo.org/keys/patrick_boeker-DB2...6410D0.asc
 keyid: C09FF113BB6410D0
 keyid: 2CC6E973818F386B
 keyid: E951F5A05ACDDC68
 keyid: A4C3820BF775D7EB
rakudo.org/keys/rakudo_github_auto...61E2EE.asc
 keyid: A2919382E961E2EE
rakudo.org/keys/alexander_kiryuhin...A8FCDE.asc
 keyid: DE8F8F5E97A8FCDE
 keyid: D22EDA20C9311B0A
rakudo.org/keys/will_coleda-F5CB0A...AACD53.asc
 keyid: 7DC7827609AACD53
 keyid: 7B3BE46BB719BA78
But latest release wants different keyid:
Or am I doing something very wrong? 12:42
[Coke] I updated *github*. I didn't update *the web site* yet. 12:45
I'm editing the "verifying" page right now. 12:46
hurufu 🙏 12:49
timo oh, that's strange, the other pubkey i have in the debian keyring is older but not expired (yet) 12:50
that was CC289A0AD69C70542B52C492ABA557C591417E5F 12:51
[Coke] fatal: unable to write loose object file: No space left on device
timo: that could be one from my laptop. I probably did the release from there once before realizing it didn't work on a mac.
coleman: trinity.raku.org has a disk full error
this from trying to restart the web app to pickup changes. 12:52
hurufu: as soon as devops can fix that, the web page should have at least two of my keys (one used for several releases this year so far) 12:53
Looks like it's not impacting the site being up, that's good 12:54
hurufu Thanks a lot [Coke]
[Coke] fatal: unable to write loose object file: No space left on device
fatal: unpack-objects failed
timo whoopsie
[Coke] hurufu: thanks for actually USING the signatures!
ok, I can actually ssh in there. there is a giant "perl.core" file in ~/rakudo.org 12:58
timo maybe it's extremely compressible 13:06
I don't know much about perl5 internals, so I can't claim that I could make sense of a core dump from a crash. but just deleting it ... 13:09
[Coke] can't compress it if the FS is full
can't move it to /tmp... 13:10
timo indeed. though if it compresses really well the compressed could go to /tmp
then rm the original and move the compressed file in its place after
i have no idea what kind of "giant" we are talking though
[Coke] -rw------- 1 rakudo.org rakudo.org 2561948727 May 12 06:49 /home/rakudo.org/rakudo.org/perl.core 13:11
timo 55 gigabytes? 13:12
wait no, 2 gigabytes?
I've seen bigger :D 13:13
[Coke] .... and I screwed up. I think trying to copy it to /tmp also horked temp. :(
timo- there's not a lot of disk available.
and now I'm locked out. :(
Sorry, coleman. 13:14
timo ah shit
[Coke] and I think I horked the website. :| 13:15
s/think/know/
timo I wonder if I should apply to the infra team so I could be of use in some situations, but I'm not sure if getting access without also regularly spending time and becoming familiar with everything might instead be a net negative?
[Coke] like me! :)
timo haha 13:16
[Coke] though we should have a disk full alert on there.
timo presumably I'd potentially have the kind of access needed to do a more extreme intervention than just "ssh into the box", though I'm not sure if this is a hardware box or a VM or what
(moving this to the infra channel) 13:17
a few debian packages of raku modules don't build reproducibly because the file vendor/dist/* has a time field for stuff in the "provides" section (and reproducible packages will become a hard requirement for debian in the next release or something like that) 14:03
ugexe yeah we don't even use that field 14:09
i opened a PR to get rid of all the extra fields that require raku itself to mutate provides but it wasn't accepted because it didn't figure out a migration pattern for handling existing installed modules on raku upgrade (which personally i was fine with saying oh well) 14:11
that being said for time specifically i think we can just delete its generation from the code and nothing would break 14:12
[Coke] hurufu: rakudo.org/downloads/verifying updated 15:08
coleman++ for cleaning things up
hurufu Thank you all. I confirm that latest package can be verified. Sorry for causing such comotion with my request :) 15:15
[Coke] thanks again for the reminder. 15:19
easy to miss that when I'm in the middle of the release and my old key's expired.
timo .o( gpgtimerobot ) 15:28
16:30 hurufu left 16:35 hurufu joined 16:42 hurufu left 16:44 hurufu joined
Geth rakudo/main: 47b5e3067c | (Elizabeth Mattijsen)++ | src/core.e/Formatter.rakumod
Make 6.e sprintf %f format compatible with C

Which fixes various issues with the legacy implementation.		 18:21
roast: a5294f7679 | (Elizabeth Mattijsen)++ | 2 files
Update 6.e tests of sprintf %f formatting
rakudo/main: 31076bbc24 | (Elizabeth Mattijsen)++ | src/core.e/Formatter.rakumod
Make 6.e sprintf %o format compatible with C

By adding a special flag in the generic integer handling for "o" that will just add a 0 if the # flag is specified and the initial stringification did not start with a 0 (also handling negative values).		 19:11
roast: 2f57eab1b0 | (Elizabeth Mattijsen)++ | 2 files
Update 6.e tests of sprintf %o formatting
lizmat and that concludes my hacking for today& 19:13
japhb lizmat++ 19:16
19:54 hurufu left 19:55 hurufu joined 21:50 hurufu left
Geth roast: d3b58dd2b4 | (Elizabeth Mattijsen)++ | S32-str/sprintf-f.t
Adjust tests for # in %f format

It means: alwats show decimal point		 21:52
rakudo/main: 505e0061e3 | (Elizabeth Mattijsen)++ | src/core.e/Formatter.rakumod
Add support for # in 6.e sprintf %f format

Somehow it was missed until now that the # flag in the %f format indicates that a decimal point should *always* be rendered, even when the precision is 0. Until now, # was just ignored in %f.
lizmat hmmm I pushed rakudo before roast...
anyways sleep& 21:53
Geth rakudo/main: 60ff486a02 | (Nick Logan)++ | src/Raku/ast/call.rakumod
RakuAST: retry .& resolution at check time to handle forward references

RakuAST::Call::Name.PERFORM-CHECK retries resolution if not resolved at BEGIN time, which is how forward references to `my sub` work: the sub isn't in scope yet at parse/begin time but is by check time.
RakuAST::Call::VarMethod (.&foo syntax) only had PERFORM-BEGIN with no check-time retry, so forward-referenced subs were always reported as undeclared. Adding RakuAST::CheckTime and a PERFORM-CHECK that retries PERFORM-BEGIN when unresolved mirrors the pattern already used by RakuAST::Call::Name.		 22:20
rakudo/main: 3b68b4c881 | (Nick Logan)++ (committed using GitHub Web editor) | src/Raku/ast/call.rakumod
Merge pull request #6178 from ugexe/ugexe/rakuast-call-varmethod-retry

RakuAST: retry .& resolution at check time to handle forward references
rakudo/main: e803a394dc | (Nick Logan)++ | src/Raku/ast/scoping.rakumod
RakuAST: add meta-object to RakuAST::Declaration::Import

compunit.rakumod calls .meta-object on the result of find-lexical('&MAIN') to get the Code object for QAST::WVal. When &MAIN comes from a use'd module, find-lexical returns a RakuAST::Declaration::Import, which has compile-time-value but no meta-object method.
... (5 more lines)
rakudo/main: ec00e3b69c | (Nick Logan)++ (committed using GitHub Web editor) | src/Raku/ast/scoping.rakumod
Merge pull request #6179 from ugexe/ugexe/rakuast-import-meta-object

RakuAST: add meta-object to RakuAST::Declaration::Import
rakudo/main: 3761996b59 | (Nick Logan)++ | 4 files
RakuAST: evaluate non-trivial package colonpair values once, cached

Under RAKUDO_RAKUAST=1, `module Zef:ver($?DISTRIBUTION.meta<version>
  // '*')` produced "Use of Nil in string context" warnings and
  `Zef.^ver` came back `(Mu)` instead of `v1.1.1`. Legacy resolves
this through `Perl6::World.compile_time_evaluate`, called once per colonpair from `colonpairs_hash`, with thunk-and-call fallback for ... (37 more lines)
rakudo/main: 0e03c00c34 | (Nick Logan)++ (committed using GitHub Web editor) | 4 files
Merge pull request #6180 from ugexe/ugexe/rakuast-colonpair-eval-cache

RakuAST: evaluate non-trivial package colonpair values once, cached
rakudo/main: fc09ce63be | (Nick Logan)++ | src/Raku/ast/type.rakumod
RakuAST: strip colonpairs from subset/enum meta-object names

Under RAKUDO_RAKUAST=1, `subset S:ver("1.0") of Int; say S.^name` reported
  `S:ver("1.0")` rather than `S`, and the same for `enum E:ver(...) <a b c>`.
Legacy's subset/enum machinery passes just the bare identifier (no colonpairs) when calling `new_type(:name(...))` on the HOW, so the runtime-visible `.^name` is the unqualified declared name; the version ... (13 more lines)
rakudo/main: c4ed6b4832 | (Nick Logan)++ (committed using GitHub Web editor) | src/Raku/ast/type.rakumod
Merge pull request #6181 from ugexe/ugexe/rakuast-subset-enum-bare-name

RakuAST: strip colonpairs from subset/enum meta-object names
[Coke] bunch of bots are missing, one sec. 22:32
do we not announce raku/whateverable commits? 22:33
22:34 unicodable6 left, bloatable6 left, committable6 left, bisectable6 left, sourceable6 left, greppable6 left, shareable6 left, linkable6 left, benchable6 left, notable6 left, evalable6 left, nativecallable6 left 22:37 releasable6 joined, evalable6 joined, notable6 joined, tellable6 joined, huggable6 joined, committable6 joined, shareable6 joined 22:38 unicodable6 joined, bloatable6 joined, greppable6 joined, nativecallable6 joined, bisectable6 joined, benchable6 joined 22:39 coverable6 joined, sourceable6 joined, linkable6 joined 22:41 quotable6 joined
[Coke] releasable6: next 22:41
releasable6 [Coke], Next release in ≈8 days and ≈20 hours. 1 blocker. 87 out of 122 commits logged
[Coke], Details: gist.github.com/c251fcfeba2045ebb1...d3c5709c37
ugexe i have one more PR i'll want to get in before the Blin run 23:53

Powered by Cro and the Raku® Programming Language.

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

Thank you!