🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
jdv who uses relocatable builds? i guess i don't because i could install zef the whole time. 01:07
japhb [Coke]: Instant values are in TAI seconds, stored internally as an integer number of nanoseconds and then divided by 10^9 when looked up as something expecting seconds as a base. 01:12
jdv this is now the second time in about as many months we've had a post release issue. not a great trend. 01:15
japhb (It doesn't make a lot of sense for something of at least laptop size to have a concept of "instant" more precise than nanoseconds, because the average laptop is around a light-nanosecond across.)
jdv: It sounded like this time we had a structural problem: we can produce builds configured in a way that our CI doesn't currently test. 01:16
(I don't remember what last month's problem was off the top of my head.)
jdv it was the mimalloc on alpine thing. also could have been could by a apline ci build i guess 01:17
oddly enough both were caught during downstream release builds 01:19
japhb Well, downstreams are likely to have good CI for their own build configs. :-) 01:31
But yeah, it sounds like we need to expand our CI pool.
At the very least it would be good to CI against any downstream that we want to consider "supported" or that we at least have a good relationship with (project to project) 01:32
Doesn't mean we need to CI against everything on every commit, but it would be nice to have a "release CI pool" that is more all-inclusive 01:33
s/all-//
[Coke] patrickb: maybe let's review the release docs and see how we can test a relocatable build in there. 01:36
Also we might want to consider starting doing a pre-release build. 01:37
jdv no, the manual release process is already too long 02:14
japhb [Coke]: Is there a standard way to get such a pre-release to trigger CI from the downstreams? In other words, is this a part of standard project - distro handshake protocol?
jdv should we also try to build the release manually on alpine 02:15
?
how many other things should the release manager be burdened with?
both of the recent "downstreams" are "us" El_Che found the mimalloc one and patrickb found this one. 02:16
japhb Ah, I thought you meant distro build farms.
jdv it was just binary builds of some sort
i think we've only had maybe one distro issue in a few years so that seems fine 02:17
japhb I guess then [Coke]'s idea comes into play: splitting out pre-release and release enough that El_Che/patrickb/whomever building/testing binary builds can be fit in between. 02:19
So it's not a huge added burden on the release manager, but it does split the release into possibly a two-day process.
(Which of course may be its own burden) 02:20
jdv it would be extra work both up front and ongoing
if we could reduce the existing burden more then maybe it could come out even in the end, maybe 02:21
japhb I certainly don't want to laser the RM, but we have to compare the effort of that versus the effort of doing additional point releases.
nodnod
jdv i'd still like to know what is the impact here. with the last issue it was just alpine and i think El_Che just patched it up and we didn't need to re-engage the whole release chain 02:24
japhb realizes that he just ... yet AGAIN ... made the "increased baseline cost versus reduced risk" argument 02:25
jdv does this need to be fixed in 4 days or is in 4 weeks sufficient?
yup 02:26
japhb I guess it depends on whether we consider "one of the downstreams will have to skip a month" to be a critical fail. 02:28
It's certainly not as bad as "we found a security issue", but it does feel like a broken window.
patrickb The e 04:12
The issue affects everyone using `rakubrew download` or any of the binaries released on rakudo.org. 04:14
ugexe which includes GitHub actions I presume 04:30
patrickb I know too little about those, but possibly yes. 06:19
All in all, we're not breaking those people's workflow, but they just can't use 2025.06. 06:20
Geth rakudo/main: 74d02b5a30 | (Patrick Böker)++ (committed using GitHub Web editor) | src/core.c/Distro.rakumod
Fix `raku -V` on strange non-standard MacOS (#5922)

There exist non-standard MacOS versions out there (specifically MacOS-15 on Azure CI) that have this in their license file:
SOFTWARE LICENSE AGREEMENT FOR APPLE CONFIDENTIAL macOS PRE-RELEASE SEED SOFTWARE
... (6 more lines)		 07:14
lizmat [Coke]: must have been asleep: the problem is that you'd need to also specify RAKUDO_RAKUAST=1 to make "use L10N:JA" work 07:16
I'll adapt the docs accordingly 07:17
Geth CY/main: b344bfe2f5 | (Elizabeth Mattijsen)++ | 4 files
0.0.7
 07:30
¦ NL: lizmat self-assigned Non-localized version information github.com/Raku-L10N/NL/issues/1 08:07
08:13 Geth left, Geth joined 08:38 nine left, nine joined
[Tux] `Type check failed for return value; expected Array[CSV::Field] but got Array ([CSV::Field.new(is_q...). You` 09:56
How can I prevent that `.new` is included in the type of the object being push on an array? 09:57
lizmat by not calling .new on it ? 09:58
[Tux] is .new implicit? 09:59
lizmat no
[Tux] so, then I am confused
my $f = CSV::Field.new; @a.push: $f; 10:00
lizmat how is @a defined ?
[Tux] Array[CSV::Field]
(it should, but /me would have to check all occurances) 10:01
lizmat my Array[CSV::Field] @a ??
[Tux] my CSV::Field @a; 10:02
lizmat ah, ok
if you specify that as an argument, it expects an array that is typed that way, *not* an array that happens to have those types of values
perhaps better: sub foo(@a where @a.are(CSV:Field)) ?? 10:03
[Tux] you lost me there
lizmat ah, return value
[Tux] to be clear on what I am trying to do now: I want to make field order stable for hashes 10:04
lizmat the array that you return, how is that defined ?
[Tux] that means I have to remember the order of the first row and reorder the fields in method $f.fields 10:05
gist.github.com/Tux/dc845ac1f8fdae...611e76220d 10:06
plus many more small changes, but specifically this part causes trouble
Full current diff added to that gist 10:07
lizmat github.com/Raku/problem-solving/issues/482 10:36
patrickb I'd like to merge 11:35
github.com/MoarVM/MoarVM/pull/1812
That's the return prioritization PR from one and a half years ago. It's rebased to latest main, it passes all tests and spectest, including added tests to validate the new behavior. 11:36
Will this cause any trouble because we haven't concluded how to deal with the 2025.06 fallout yet? 11:37
lizmat I would wait until that is cleared, and I would be in favour of a point release 11:40
patrickb Ok. 12:28
lizmat jdv ^^
jdv are we sure the issue is fixed and no new issued have been introduced? i didn't notice any additional tests. 13:26
lizmat irclogs.raku.org/raku-dev/2025-06-29.html#21:55 13:28
5922 got also merged after some tweaks
jdv if we have a quorum then i can do a point release later today 13:29
lizmat I guess +1 from lizmat patrickb 13:30
I guess [Coke] is on the road today
jdv [Coke]: ?
lizmat perhaps nine would like to chime in
[Coke] as co-release manager ?
jdv oh, i didn't mean specifically rsc. just core-ish peeps:) 13:31
but, basically, yeah
lizmat pings japhb ugexe 13:34
jdv looks like i didn't have enough coffee yet 13:37
lizmat how so? 13:38
jdv it looks like a point release later today unless someone gives it a thumbs down
i missed your line on coke being on the road:) 13:39
patrickb I'll put some brains into which additional testing would be good in our CI. As about every one noticed - there is room for improvement.
jdv i have to run for a few hours. please don't commit anything crazy until after the release;) 13:40
patrickb jdv: Will not. Thank you!
jdv patrickb: thanks
lizmat: thanks
patrickb My current thinking is to not add more tests to the test suite, but exercise the installation with a few representative everyday situations and assert on those. E.g. install a module, make an actual web request via one of our web stacks, ... 13:42
lizmat fwiw, most of the dists that I maintain, also try to install the dist in question as one of the CI tests 13:43
13:46 librasteve_ joined 14:02 vrurg_ joined 14:04 vrurg left
patrickb lizmat: I'm mostly aiming to exercise our integration, not the module installation itself. I.e. does an installed rakudo work, do the installed scripts work, does a standalone script using some module work, ... 14:21
lizmat ah, ok :-) 14:22
patrickb Integrations are pretty tricky to test, it's pretty much the stuff that usual tests never exercise, but bite you the instant you want to actually use the thing.
lizmat as we've found out :-( 14:23
patrickb Which - in my defense - explains why I have a higher than average tendency to break releases. I work a lot on integrations. 14:24
[Coke] belatedly waves from the road. 14:25
I vote "present" on a point release. I think in an ideal world we do it, but I also know I will not be able to help with it at all. 14:26
16:35 librasteve_ left
jdv so it'll be 2025.06.01? 17:03
[Coke]: thanks
Please halt all commits for a bit while we do an unscheduled point release which will commence shortly. 17:04
lizmat is halting :-) 17:05
jdv i meant hold. a bit too dramatic there:) 17:06
lizmat
.oO( sorry, can't respond, I've halted :-)
patrickb 2025.06.1, (without the 0, right?) 17:10
lizmat that indeed appears to be customary 17:11
although I do recall there being some issue with that
?
could very well be misremembering
jdv i don't think i care. 01 or 1? 17:14
i see more .1 than .01 so .1, sure. 17:15
17:32 librasteve_ joined
Geth rakudo/release-2025.06.1: 609b90335d | (Justin DeVuyst)++ | 3 files
Update changelog + announcement

Deliberately not logged:
  [9847a6ac][51fb0954]		 17:50
lizmat jdv++ 18:02
librasteve_ weekly => rakudoweekly.blog/2025/06/30/2025-06-released/ 18:11
Geth nqp/main: 8804e251b5 | (Justin DeVuyst)++ | VERSION
[release] Bump VERSION to 2025.06.1
 18:58
rakudo/release-2025.06.1: f856293c1c | (Justin DeVuyst)++ | tools/templates/NQP_REVISION
[release] Bump NQP revision to 2025.06.1
rakudo/release-2025.06.1: cf048a948a | (Justin DeVuyst)++ | VERSION
[release] Bump VERSION to 2025.06.1
rakudo: jdv++ created pull request #5924:
Release 2025.06.1		 19:01
rakudo/main: 4 commits pushed by (Justin DeVuyst)++
lizmat jdv++ again! 19:04
jdv patrickb: 2025.06.1 point release done 19:10
.tell El_Che 2025.06.1 point release done
tellable6 jdv, I'll pass your message to El_Che
jdv commit away!
patrickb Thank you very much! 19:12
[Coke] the 0 vs. 01 was a thing I was confused about, don't worry about that. :) 19:31
[Coke] adds another drink ticket to jdv's tab.
21:40 apogee_ntv joined 21:56 apogee_ntv left, apogee_ntv joined 21:57 apogee_ntv left 22:09 apogee_ntv 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!