🦋 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:08 reportable6 left 01:36 ggoebel left 03:10 reportable6 joined 03:56 kjp_ left, kjp joined 06:08 reportable6 left 06:11 reportable6 joined 08:35 frost joined 08:36 dogbert17 left, dogbert17 joined
lizmat Files=1351, Tests=117115, 290 wallclock secs (35.14 usr 10.02 sys + 4059.50 cusr 332.70 csys = 4437.36 CPU) 09:37
09:50 squashable6 left
Geth rakudo: 07d580bcc9 | (Stefan Seifert)++ | lib/CompUnit/Repository/Staging.rakumod
Fix resources of the parent repo not found when using Staging

Resources are loaded lazily, so we pick up changes in the repository's location. Indeed, this is exactly what happens when a dist gets installed via the Staging repsitory: the files will end up in a different location than they were installed to. The lookup uses the name of the repository, the dist id and the resource's name. Since the Staging repo shadows its parent, it will end up ... (7 more lines)		 10:05
nine jdv: I know it's very late in the release process. This fix ^^^ affects only users of the Staging repo (of which there are very few), so I judge it very low risk, and it fixes a use case that could never have worked before. 10:06
Geth rakudo: 46ec1ce7a6 | (Elizabeth Mattijsen)++ | lib/CompUnit/Repository/Staging.rakumod
Remove obvious debugging leftover
 10:08
lizmat nine ^^
nine Argh....thanks lizmat++
So much for "fix is so trival, nothing could go wrong" 10:09
lizmat so, I'm thinking of adding a CompUnit::Repository::Installation candidate to CURI.install 10:10
which would just copy files over to the correct location
would that make sense ?
which would be used for the CURS of course, in most cases 10:11
but the core doesn't know about CURS, so it would have to be more general anyway
nine So far I've considered the copying of result files to be out of scope, because packaging tools and installers handle that anyway. 10:12
lizmat well, the line of thought would be that e.g. zef would install the module to a CURS, run the tests, and then just copy the files to the correct location
nine That said. If zef starts using Staging for real, then things do become more gray. I just wonder if this belongs to CURI or to CURS 10:13
So, CURI.install(CURS) or CURS.deploy?
lizmat CURS.deploy(CURI) you mean?
nine Or maybe CURS.commit or whatever one bikesheds it to.
Well the CURS instance already knows its parent, so I figure there's no need to tell it again. 10:14
lizmat it would have to know where to deploy to, no ?
ah, ok
hmmmm then there's something I'm not grokking yet
nine what's that? 10:17
lizmat starting to grok now :-)
a child class keeping a copy of its parent... :-) 10:18
parent instance even :-)
nine It's not the parent class, it's the parent repository
Maybe we just have too few words for such relationships :) 10:19
lizmat well, their both repositories
afk for a bit&
10:51 squashable6 joined
lizmat *they're 10:59
nine Well Staging still seems to do its job just fine :) build.opensuse.org/project/show/ho...rakudo-git 11:16
lizmat ok, a .deploy method would just look at the right directories and copy any files within there verbatim, right ? 11:19
nine Yes, copy everything from $.prefix to $!parent.prefix 11:20
lizmat ok, I think I can do that :-)
nine: I guess the CompUnit::RepositoryRegistry.register-name($!name, self); in CURS.BUILD is there just in case ? 11:32
ah, no, it's to make sure that the CURx with that name refers to the Staging one, right? 11:37
but that would be... potentially messing up in longer running processes ? 11:38
12:08 reportable6 left, reportable6 joined 12:31 sena_kun left, sena_kun joined
lizmat nine: why isn't CURS not just part of core? 12:35
13:04 frost left 13:07 sena_kun left 13:08 sena_kun joined
Geth rakudo/precomp-longest-first: d49cf841ca | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/Repository/Installation.pm6
CURI: pre-compile longest names first

The idea being that the longest names have fewer dependenencies
  (in general). Also make sure that we only sort the entries once.
It would probably be better if we could specify an order in which modules should be pre-compiled. But alas, the current META6.json format is a hash, so without order. And we need some sort of order to get reproducible builds.		 13:34
rakudo: lizmat++ created pull request #4821:
CURI: pre-compile longest names first
13:41 frost joined 13:44 [Coke] left
Geth rakudo/staging-into-core: 6315033e06 | (Elizabeth Mattijsen)++ | 6 files
Move CUR::Staging into core

Yes, it is only needed for very specific applications. But it is a very small module, and it simplifies the various install scripts significantly (most notable "install-core-dist.raku"). And it won't break code that actually do a 'use CompUnit::Repository::Staging".
And it reduces the core setting compilation with about a second. Which, on a normal core development day, I'm doing a *lot*.		 13:46
rakudo: lizmat++ created pull request #4822:
Move CUR::Staging into core
14:02 [Coke] joined
Geth rakudo/staging-into-core: 6aeaadcfae | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/Repository/Staging.pm6
Fix another branch sneaking in
 14:03
15:43 frost left
nine lizmat: it's not core because it's really really rarely used (comparitively). It's also my testbed for custom CUR implementations and precompilation (wasn't easy to get those working together) 16:13
lizmat nine: that's all in the eye of the beholder: I would be using CURS more than I would be using Complex numbers, yet Complex numbers *are* in core 16:57
jdv nine: ok. started a blin maybe 1.5h ago. 17:04
nine lizmat: sure, there are tons of features that I also don't use but are in core. The argument for those (and complex numbers are a great example for that) is that they provide common types that libraries can be built around. This avoids the situation where library A deals with Number::Complex thingies while B's author was more convinced of Complex::Numbers::Number 17:07
lizmat doesn't that apply to CURS as well ? 17:08
17:25 discord-raku-bot left, discord-raku-bot joined
nine I can't see how. CURS has pretty much only one job. There's not much room for alternative implementations and even if, its API is identical with CURI's. 17:32
jdv the blin run looks mostly clean - the shortest i've gotten 17:42
gist.github.com/jdv/31f86b77382191...63461b248d 17:43
nine So no regressions? 17:44
jdv that is, surprisingly the uneddited report from blin 17:45
the Cro::SSL "ZefFailure" may be real 17:47
but its deprecated it seems so i guess ignoreable 17:52
so, yeah, no regressions. all good to go for tomorrow's release then. 17:54
MasterDuke cool beans 17:56
Geth rakudo: 3f10f7daac | (Elizabeth Mattijsen)++ | lib/CompUnit/Repository/Staging.rakumod
CURS simplification

  - use TWEAK instead of BUILD (no need to fetch any params)
  - remove .name (auto-generated for public attributes)		 17:59
18:00 sena_kun left 18:01 sena_kun joined 18:08 reportable6 left 19:11 reportable6 joined 19:29 sena_kun left 19:30 sena_kun joined 19:39 discord-raku-bot left, discord-raku-bot joined 19:44 gfldex left, gfldex joined 20:12 sena_kun left 20:13 sena_kun joined 20:53 curiosa joined 20:55 curiosa left 21:19 ggoebel joined 23:04 gfldex left, discord-raku-bot left 23:06 gfldex joined 23:09 discord-raku-bot 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!