🦋 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: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:03 linkable6 left, evalable6 left 00:06 evalable6 joined 00:07 reportable6 left 00:36 Kaiepi left 00:39 Kaiepi joined 00:54 Kaiepi left 01:03 Kaiepi joined 01:10 reportable6 joined 01:16 Kaiepi left 01:43 Kaiepi joined 01:46 Kaiepi left 01:49 discord-raku-bot left, discord-raku-bot joined 01:51 Kaiepi joined 01:53 gfldex left 01:57 gfldex joined 01:58 Kaiepi left 02:00 Kaiepi joined 03:01 nine left, nine joined 03:05 frost joined 04:21 frost left 04:46 kjp left 04:50 kjp joined 05:23 frost joined 06:02 kjp left 06:07 reportable6 left 06:10 reportable6 joined 06:14 kjp joined 06:37 frost left 06:40 frost joined
releasable6 Next release in ≈2 days and ≈11 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 07:00
07:04 linkable6 joined 07:16 frost left 07:28 frost joined 07:34 frost left
lizmat Files=1351, Tests=117094, 280 wallclock secs (35.21 usr 9.88 sys + 3904.09 cusr 321.57 csys = 4270.75 CPU) 08:22
10:21 qorg11 left 12:07 reportable6 left 12:08 reportable6 joined 12:41 kjp left 12:44 lucs_ joined 12:45 bartolin_ joined, tonyo1 joined 12:46 lucs left, bartolin left, tonyo left, ugexe left, discord-raku-bot left, [Tux] left, discord-raku-bot joined, ugexe joined 12:47 [Tux] joined 12:54 kjp joined
lizmat Is there a reason why the Distribution::Resource object doesn't have a $.IO attribute ? 12:56
rather than an .IO method that seems to not cache fetching it ?
13:10 Kaiepi left, Kaiepi joined
nine Yes. The actual path and file handle must not become part of the precomp file. They must be resolved at runtime. 13:13
Indeed, that's the whole point of having Distribution::Resource in the first place, instead of just returning the IO object from %?RESOURCES access directly. 13:15
lizmat hmmm... but that would only happen if the Distribution::Resource object is created at compile time, no ? 13:16
nine Yes, which it is e.g. in sub foo() is native(%RESOURCES<libraries/foo>) { ... } 13:17
lizmat but at that time, %?RESOURCES is already fixed, no ? 13:21
nine What do you mean by fixed?
lizmat when the module is compiled, at that time the Locations of the resources is already known ? 13:22
or is there a reason why we cannot pre-compile an IO::Path object ?
I mean, it does *not* have a file handle 13:23
nine No, they are not. Compilation can happen into a staging repository with the files getting moved to their final locations only after compilation is done. This is the case e.g. when packaging modules. 13:24
A relocatable rakudo installation amplifies this problem even more. 13:25
lizmat ok, but a lazily set IO attribute wouldn't have that issue, no?
nine What would that look like? 13:26
lizmat method IO() {
$!IO //= (self.repo-name ....
nine I don't see why this wouldn't have the issue.
lizmat fwiw, that spectests clean
but I understand your worry 13:27
nine sub foo() is native(%RESOURCES<libraries/foo>) and immediately you get a Distribution::Resource object with a fully initialized .IO attribute with an absolute path in the precomp file.
It's not a worry. This would be definitely wrong and cause breakage. No doubt at all about that.
lizmat ok :-)
lizmat reverts a local commit 13:28
nine And yes, having a regression test for this would be nice
Geth__ rakudo: 67906e48dc | (Elizabeth Mattijsen)++ | src/core.c/Distribution.pm6
Add missing methods to Distribution::Resource

Distribution::Resource is supposed to be acting as an IO::Path object. But because the underlying IO::Path object *SHOULD NOT EVER* be serialized during pre-compilation, it is impossible to create an $.IO attribute.
Sadly, "handles" codegens to calling the attribute rather than any accessor ... (6 more lines)
14:29
14:30 Geth__ left, Geth joined
lizmat m: class A { method b() handles Str { } } 14:48
camelia ===SORRY!=== Error while compiling <tmp>
Cannot unbox a type object (Str) to a str.
at <tmp>:1
lizmat interesting 14:49
14:50 Geth left 14:51 Geth joined
ugexe ideally it wouldnt be an IO, but an IO::All (or at least what was proposed for IO::All) 16:05
since then you can have e.g. resources backed by a socket
(maybe it was IO::File.new(uri => ...) actually)
long ago there was something on a type of IO abstraction that could have additional uri handlers added to it 16:06
"For example, calling IO::File.uri('....') will throw an error (but will suggest using just uri('...') instead)." 16:11
from github.com/Raku/old-design-docs/bl...streamable 16:12
nine lizmat: that Distribution::Resource doesn't support all IO methods was on purpose. As ugexe++ pointed out, one shouldn't make any assumptions about how resources are stored. We only added methods that make sense regardless of storage backend (like slurp, lines or copy) or that have already been in use at the time we replaced IO with Distribution::Resource. 16:15
So if anything it should have fewer methods, not more. That's just hard because auf backwards compatibility 16:16
lizmat ok, but then maybe we should deprecate these methods, and force everybody to use the .IO method ?
because .modified was just about the first thing I tried :-) 16:17
and it wasn't there
jdv lizmat: can you look at the PDF::Font::Loader issue (github.com/rakudo/rakudo/issues/4724) 16:19
bisected to one of yours
lizmat jdv: will do
jdv if you know how to fix Trait::Traced that'd be nice as well. thanks. 16:20
lizmat I think that's more up vrurg's alley ? 16:25
16:31 evalable6 left, linkable6 left
lizmat jdv: I'm afraid PDF::Font::Loader is *not* caused by the bisected commit 17:00
I would be *really* surprised by that, as the commit only changed Capture.raku, which is pretty far away from where the code blows up 17:01
jdv: did Trait::Traced also fail on the 2021.12 Blin runs? 17:02
the commit bisected to predates 2021.12 ?
Geth rakudo: 25562dd80d | (Elizabeth Mattijsen)++ | src/core.c/Distribution.pm6
Revert "Add missing methods to Distribution::Resource"

This reverts commit 67906e48dca69ff9af9dbb4d01dd1ff3a1e759b9.
17:19
18:07 reportable6 left 18:10 reportable6 joined 18:31 evalable6 joined 18:38 dogbert17 joined 18:40 dogbert11 left 18:55 Kaiepi left 18:56 Kaiepi joined
jdv lizmat: I believe the offending changes were created before the 2021.12 but merged after 18:57
well, given the amount of mess in the current blin we might have to push the release a week and hope next week peeps can get it in shape:( 18:59
nine jdv: looks like the only way out is through. The "unreachable unbox" failures can be fixed by merging the rest of fix_unsigned
jdv all or nothing, huh? 19:00
nine Thing is, I'm gonna be on vacation for a bit over a week starting this Saturday
And the rest of fix_unsigned will break JVM. Past few days I've made some progress on porting over the changes, but it's hard to say when I'll have it up and running 19:01
jdv nice... hmm, maybe its worth skipping 2022.01 then?
or it is easy enough to back out what's in already?
nine That would also kinda suck because of NQP bootstrap files 19:02
jdv i guess we have no good choice except to skip the Jan release then, right? 19:05
nine Unless....I merge those branches really soon and Blin works out fine. If there are no open issues, it won't matter if I'm available or not 19:08
Is JVM mandatory for a release?
jdv i'm not sure that's specified:) 19:09
do you think there's a good chance it could all be fixed up by 2/18 or 2/25?
likely dates for the Feb release 19:10
i could probably use a vaca - thanks for reminding me 19:11
bartolin_ imho a release with a broken jvm is ok. (it should be pointed out in the release announcement of course) 19:12
19:15 Geth left, Geth joined 20:00 kjp left 20:01 kjp joined
vrurg lizmat: Trait::Traced bisected to Jonathan's attributes work. I can have a look at it, but that's not really my alley. :) 20:37
20:43 qorg11 joined 21:26 ilogger2 left
[Tux] Rakudo v2021.12-122-g25562dd80 (v6.d) on MoarVM 2021.12-73-gf884085c1
csv-ip5xs1.087 - 1.094
csv-ip5xs-205.714 - 5.747
csv-parser4.182 - 4.288
csv-test-xs-200.406 - 0.415
test6.878 - 6.977
test-t1.580 - 1.635
test-t --race0.888 - 0.968
test-t-2023.706 - 24.184
test-t-20 --race7.163 - 7.470
21:29
jdv vrurg: i haven't blin'd your change yet cause there's a lot of blin failure that's yet to be cleaned up. if and when a bunch does get cleaned i'll re-run 21:48
vrurg jdv: ok. I'm mostly worried about the release. 21:49
jdv why worried? 21:50
vrurg Not to be an obstacle for the next one. 22:05
jdv ah, well there's so much of that there's a real chance the release will not happen on schedule at this point. thanks for trying though. 22:16
22:21 ilogger2 joined 22:32 linkable6 joined