00:22 librasteve_ left 01:33 guifa joined
patrickb The binary release is done. Thanks everyone! 08:25
I guess now is the time to merge the return prioritization changes then. 08:26
And it's in. 08:28
What's the policy with respect to when the respective roast tests should be merged? Can they be merged right away? 08:29
timo i think usually liz or someone else bumps the revisions in the nqp and rakudo repositories 08:40
08:57 apogee_ntv left
lizmat yeah,. bumping them now 09:18
Geth nqp/main: 4604c6664e | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get return prioritization fixes, patrickb++
 09:21
rakudo/main: c85a7c5cca | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get return priorization fixes, patrickb++
 09:27
lizmat patrickb: you're good to go! 09:28
patrickb Yay! Thank you! So it's safe to merge the roast tests now? 09:29
lizmat think so 09:30
Geth roast: 07e9098849 | (Patrick Bƶker)++ | 2 files
Test return prioritization

Discussed in github.com/Raku/problem-solving/issues/417
Depends on these three PRs:
  - github.com/MoarVM/MoarVM/pull/1782
  - github.com/MoarVM/MoarVM/pull/1785
  - github.com/MoarVM/MoarVM/pull/1788
patrickb Done.
roast: feb493462a | (Patrick Bƶker)++ (committed using GitHub Web editor) | 2 files
Merge pull request #851 from patrickbkr/return-prioritization

Test return prioritization
patrickb [Coke]: Can you do a blin run in the next few days? The return prioritization changes are in. 09:31
09:57 apogee_ntv joined
lizmat m: enum foo (BEGIN <a b c>); say c; say +c # TIL 10:08
camelia c
2		 10:09
lizmat but this doesn't work:
m: enum foo BEGIN <a b c>; say c; say +c # TIL
camelia ===SORRY!=== Error while compiling <tmp>
An enum must supply an expression using <>, Ā«Ā», or ()
at <tmp>:1
------> enum foo<HERE> BEGIN <a b c>; say c; say +c # TIL
[Coke] patrickb: sure, will kick off a run right now 15:37
jdv lizmat: any ideas about that symbol merge thing? 15:40
[Coke] nifty to have - a rakudo bisect that also bisected mainly over rakudo but then also into nqp and moarvm commits as necessary when bumping. 15:42
(could probably layer over rakubrew) 15:43
jdv iirc timo maybe looked into that but idk what happened. i know someone did at least.
[Coke] (blin) oops, upgrading to a new rakudo because I lost my "clean" version after doing that bisect to track down rir's problem. 15:44
jdv i'm blocked on that old issue rebuilding blin with SSL symbol merge conflict or whatever
[Coke] IIRC we fixed it by cleaning up some dependencies in the ecosystem - guessing someone updated one of those deps but not another and now we're hitting it again but with different versions than the last time
... and crap, now my blin is borked by the same thing because I had to reinstall deps. 15:45
jdv still confused why that happens as the 2 ssl modules' "long names" are different. i thought that seperated modules with the same "short name" enough that that shouldn't really happen
[Coke] I think it's the top level SSL:: part 15:46
... which makes my recollection of how we fixed it sketchy.
ok, let me see if I can switch back to a working version of rakudo I have installed on this box. :(
jdv then how can you have 2 modules of different long names?
[Coke] yah, don't trust my memory on this one, I guess. 15:48
OK, thankfully I found a version of raku I already have installed with rakubrew so I can still do blin runs. 15:49
but if I ever want to upgrade rakudo on that box, I'm screwed. Wonder if
jdv - when I get home, I'll find the ticket on this that got closed. 15:50
patrickb: kicked off that blin run 15:51
jdv i know the tickets. they involve Whateverable, IO::Socket::SSL, and IRC::Client and its a mess
[Coke] whoops, with 2022 as a start point. :| 15:52
jdv but, to my dumb understanding, lexical imports "shouldn't" let that happen or at least I thought that was part of the point of them.
always good to test backcompat:) 15:53
[Coke] ok, rekicked off. (running it off master instead of the coke/cleanup branch, just in case) 15:58
jdv: once it's done, I'll also poke around this working install of raku and see what I did. 15:59
ā³ 29 out of 2350 modules processed (1.23%)
jdv i how i can hack around it. i want to understand it and get it actually fixed. 16:34
*kno 16:35
gah. *know
lizmat jdv: I'm not sure which merging issue we're exactly talking about here... do you have a golf ? 16:59
jdv it happens when doing "zef install Whateverable" 17:08
but there is a golf in a ticket by coke. justa moment.
is think its github.com/raku-community-modules/.../issues/77 17:09
lizmat the golf is clean for me 17:10
use IRC::Client; use IO::Socket::Async::SSL
the most recent version of IRC::Client has IO::Socket::Async::SSL:ver<0.8.0+> as the dependency 17:12
so shouldn't be an issue ?
jdv its the last comment in that ticket
using 2 different long names of the same module
lizmat yeah, that's a generic problem with multi-level names and different versions 17:13
to be able to fix that, would require dynamic stashes, and a lot of work and breakage
I don't see that fixed before 6.e
jdv so i guess the "bandaid" is to unpin IRC::Client, no? 17:15
because IRC::Client is forcing ver<0.8.0+> but something else is pulling in another ver
lizmat well, that would have to be a lower version then 17:16
jdv so, just to be clear. lexical imports do not work as advertised at the moment?
lizmat well, it's complicated 17:17
it becomes more complicated with multi level namespaces 17:18
jdv ok. what's the fix then?
i just want Blin to work without hacking it. which requires "zef install Whateverable" to work. 17:19
lizmat if we use a Foo::Bar:auth<foo> and a Foo::Bar:auth<bar>, the Foo namespace now needs to store Bar, but which one?
so either the Bar entries should differentiate on auth / version / api as well 17:20
but at the moment, the key in the stash can only be the name
and then you have a merge conflict
well, looking at Whateverable;s META, no versions have been pinned 17:22
jdv i'm running a blin zef install now so maybe i'll catch at least the other ver. the merge error didn't give much info. 17:23
lizmat zef install . --deps-only works for me in the Whateverable repo 17:25
jdv ok
lizmat so it's within Whateverable itself 17:26
Geth whateverable: a671ffca20 | (Elizabeth Mattijsen)++ | lib/Whateverable.pm6
Make Whateverable install again

The conflict was in the Message shortcut: changed that to IRC-Message to avoid the conflict. Still not sure how that conflict comes about but at least Whateverable works out of the box again.		 17:29
jdv something pulled in IO::Socket::Async::SSL:ver<0.7.14> 17:34
which was IRC::Client:ver<4.0.9> 17:36
what a delight!
lizmat are you installing with zef, or from a local fork?
jdv zef 17:37
from inside a blin repo
be neat if zef could give the dep graph instead of a blurry view of it:)
[Coke] wow. /me wonders how liz found that one.
App::Zef-Deps maybe? 17:38
there's some graphivz output option there.
lizmat no, I first installed all the deps to make sure it wasn't in the deps
and it wasn't
then did a zef install . 17:39
and that gave me a line number:
Redeclaration of symbol 'Message'.
at /Users/liz/Github/whateverable/site#sources/FFCE30B7629EBB9BF4F889999F97C35CAC8EA91C (Whateverable):36
jdv that's the last error we had before the ssl one 17:40
lizmat and also, Whateverable should be migrated to zef 17:41
jdv fez?
lizmat but not today, at least not by me :-_
I mean, off off p6c
jdv iirc its only on rea
lizmat I don't see the last change on the REA 17:42
[Coke] opens github.com/Raku/whateverable/issues/397 17:43
jdv and there we have it
the Whateverable on rea depends on IRC::Client:ver<4.0.9> which depends on IO::Socket::Async::SSL:ver<0.7.14> 17:44
wow. so something else is pulling the newer SSL dist. didn't see that coming but makes sense why this is so confusing:)
lizmat ok, moving it to zef should fix that 17:45
as a workaround: clone the repo, and zef install . from there
jdv you mean releasing a new version to fez, right?
[Coke] ... that may be how I fixed my original copy, was a manual install of W*
lizmat yes, so it will see the more lax dependencies
jdv cool. the point is to make blin installable again by anyone. how do we get it moved to fez and all? 17:46
coke and i have hacked it long enough!
progress...
lizmat consider it be near the top of my list, so if no-one beats me to it, I will get around to it in the next week or so 17:47
[Coke] If it's already in Raku/ should be pretty straightforward, I think.
lizmat++ Appreciate it. 17:48
lizmat I assume as a community module then, right?
[Coke] it's already under Raku/ 17:49
but for the auth? sure 17:50
I think anything under raku/ could also have community auth
lizmat ack
[Coke] no? 17:52
lizmat probably
jdv lizmat: cool, thanks. let me know if i can be of assistance. 17:54
lizmat by nudging me in a week or so if I haven't done it yet :-)
[Coke] ... one thing that may break: our ability to just commit to master to restart all the bots. 17:55
jdv is p6c even used/available anymore?
[Coke] .ask alexdaniel - can you commit on the plan to move whateverable to fez instead of the old "listing of github repos" ? 17:56
tellable6 [Coke], I'll pass your message to AlexDaniel
jdv why would that break?
lizmat raku.land/stats shows still 372 modules in p6c
[Coke] jdv: maybe it's using the old ecosystem to track instead of master itself.
lizmat although effectlively those are being served by zef from the REA
[Coke] .ask alexdaniel - I mean comment
tellable6 [Coke], I'll pass your message to AlexDaniel
jdv but commits aren't necessary tracked at p6c, right? 17:57
lizmat only raku.land is still looking at updates there, which is annoying :-)
jdv yeah i thought zef stopped by default a while ago 17:58
p6c just looks at META6.json files so the restart hook should be fine i'd think 17:59
or, i see what you mean. nevermind. 18:00
if it does it would be interesting to know how its implemented
[Coke] wonders how he can setup a pipeline to fill whateverable with macos builds. 18:05
patrickb x64 or arm? 18:09
For arm I have access to a cloud box. So if you put together a smallish script to build loads of releases and pushes them somewhere, you're good to go. 18:10
[Coke] arm64 18:11
cool.
patrickb++
patrickb Coke: Ping me once you need access. a 18:16
18:49 guifa left 18:52 guifa joined
Geth rakudo/main: 5a1f70139a | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/DateTime.rakumod
Make DateTime.(modified-)julian-date take timezone into account (#5886)

In response to github.com/rakudo/rakudo/issues/5884		 18:58
18:58 guifa left 19:19 Xliff left 19:57 Xliff joined
[Coke] got home to find the blin run I kicked off ... finished? 19:58
that's about 10 hours too soon.
21:35 guifa 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!