🦋 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.
00:00 reportable6 left 00:01 reportable6 joined
Geth rakudo/ugexe/curfs-extensions: 924386f508 | (Nick Logan)++ | src/core.c/CompUnit/Repository/FileSystem.pm6
Make extensions for CURFS configurable

When using CURFS that isn't pointed at a directory containing a META6.json file (i.e. -Ilib) it will consider .rakumod .pm6 and
  .pm files as raku modules. However, some users might want to
opt out of e.g. .pm files getting treated in this way.
This adds the ability for users to define which extensions a CURFS will scan for using the CompUnit::Repository::Spec format. For example: file#extensions<.rakumod .pm6>#lib would only scan for files with the .rakumod and .pm6 extension of the lib directory.		 02:02
rakudo: ugexe++ created pull request #5279:
Make extensions for CURFS configurable
03:59 kurahaupo left 04:59 nativecallable6 left, bloatable6 left, linkable6 left, greppable6 left, tellable6 left, committable6 left, reportable6 left, squashable6 left, statisfiable6 left, releasable6 left, quotable6 left, unicodable6 left, benchable6 left, sourceable6 left, notable6 left, shareable6 left, coverable6 left, evalable6 left, bisectable6 left, tellable6 joined, linkable6 joined, committable6 joined, bloatable6 joined 05:00 greppable6 joined, benchable6 joined, quotable6 joined, releasable6 joined, reportable6 joined, evalable6 joined 05:01 nativecallable6 joined, notable6 joined, shareable6 joined, squashable6 joined, statisfiable6 joined, sourceable6 joined, unicodable6 joined, coverable6 joined 05:02 bisectable6 joined 06:00 reportable6 left 06:01 reportable6 joined
|Tux| Rakudo v2023.05-98-ge8b477b58 (v6.d) on MoarVM 2023.05-6-gb039b913b
csv-ip5xs0.852 - 0.874
csv-ip5xs-205.267 - 5.364
csv-parser3.725 - 3.802
csv-test-xs-200.391 - 0.406
test6.676 - 6.957
test-t1.450 - 1.453
test-t --race0.851 - 0.915
test-t-2021.757 - 23.31
test-t-20 --race6.264 - 6.668
 07:33
07:35 sena_kun joined 08:06 sena_kun left 08:07 sena_kun joined 08:13 squashable6 left 08:14 squashable6 joined
Geth rakudo/main: 75bdcd649a | (Elizabeth Mattijsen)++ | 2 files
RakuAST: make sure unit scoped packages deparse ok
 08:33
08:51 Xliff joined
Geth rakudo/main: 4 commits pushed by (Stefan Seifert)++ 09:00
09:06 kurahaupo joined
Xliff \o, nine 09:11
nine: Are you still using the first -I item as the global precomp store?
nine: Is there a reason we can't add a moar::precompdir and set that to <bindir>/../.precomp, which has the benefit of now allowing all of the precomp files to live with the running verion of Rakudo? 09:14
If this is easier for you to discuss in problem-solving, I can move it there. Thanks.
09:19 sena_kun left 09:35 jjatria left, jjatria joined
nine Xliff: I'm not aware of any changes. Right now I'm focussing 100 % on RakuAST 10:13
11:22 nebuchadnezzar left, nebuchadnezzar joined 12:00 reportable6 left, reportable6 joined
vrurg Xliff: This is not how things work. Precomp directory is not any business of MoarVM, it's up to CompUnit classes to decide. 13:14
13:23 samebchase left 13:24 samebchase joined, timo left, timo joined
Xliff vrurg: OK, but if my first -I listing has a .precomp that is over 74G! That's awfully arbitrary. I'm saying the existing way no longer makes sense. Wherever this decision is being made, might my suggestion be a better way for future progress? 13:25
vrurg Xliff: of course, this is discussible. I'm only afraid we barely have anybody to deal with it in the code. :( 13:26
But at least there is hope to get somebody for it in the future. 13:27
nine <bindir>/../.precomp would violate the FHS even more than we do already and would often be not writable
vrurg Oh, I'm still sleepy, haven't noticed the <bindir>. That is a bad idea, no doubt. 13:28
Xliff nine: Sorry, that was a terrible description for what I was trying to say. My <bindir> is moar::bindir=/home/cbwood/.rakubrew/versions/moar-blead/install/bin 13:30
So .precomp in this case would be /home/cbwood/.rakubrew/versions/moar-blead/install/.precomp
Which has the advantage of isolating .precomp blobs in the moar-blead version of Raku if using rakubrew. 13:31
That is writeable, but I did not think about the situation if it were using the system rakudo
nine Solves one case, breaks others. Par for the course for suggestions about where to store precomp files
You are not the first one to be annoyed by this :) 13:32
Xliff OK. Let me give it some more thought. Would problem-solving be a better place for it?
vrurg Xliff: absolutely.
nine That is a far more interesting question than it looks like :D
Xliff Fair enough. 13:33
nine lizmat: I kinda forgot. What was the results of problem solving the problem solving at the summit?
lizmat we need to spend more time on it?
nine Xliff: one requirement for a solution, I've already told you: that it has to work for a non-root user with a system rakudo. Another one is that dependencies of a precomp file must be available for loading once we've determined that the precomp file is up-to-date. 13:42
Then there's quite a big headache: it must support distro packaging modules including their precomp files.
I think a step forward would be to differentiate precomp files generated by module installation and precomp files generated on-demand. 13:57
Xliff nine: Thanks for the extra information. 14:14
lizmat and yet another Rakudo Weekly hits the Net: rakudoweekly.blog/2023/06/12/2023-23-4-at-48/ 14:20
notable6: weekly
notable6 lizmat, 3 notes: gist.github.com/7c8ea3e25bfc419698...d6bbe7767d
lizmat notable6: weekly reset 14:21
notable6 lizmat, Moved existing notes to “weekly_2023-06-12T14:21:02Z”
15:05 sjn left 16:00 kurahaupo left
japhb nine: Of note, Python has long had the "system package versus pip package" problem, and apparently they can mark certain packages as being system-managed, and pip will refuse to install into the system directories if the system package manager is in charge. 16:29
nine We've never had that particular problem since we inherited Perl's core vs. vendor vs site structure 16:44
But yes, people keep ignoring the things Perl got right and run into problems... surprise :) 16:45
17:01 kurahaupo joined
leont Yeah 17:25
japhb TRUE 17:37
17:41 sena_kun joined 18:00 reportable6 left 18:01 reportable6 joined 19:50 Xliff left 20:33 sena_kun left 21:22 [Tux] left, [Tux] joined 21:36 kurahaupo left 21:41 kurahaupo joined
ugexe I wonder if we could get away with apply some more limits to CURFS when it has to discover files. for instance: only recurse X folders deep 21:54
(with an option for increasing that limit) 21:55
another more extreme example would be to not recurse into a directory called perl5/ 22:04
but that is only correct 99.9% of the time
maybe we should just throw a warning once the directory recursion has passed a certain threshold, to let the user know they may want to organize their code differently or use a more precise library path 22:14
22:25 kurahaupo left 22:38 [Coke] left, [Coke] joined 23:14 m6502 joined
Geth rakudo/ugexe/sha1-resource-files: 6ddbf68a37 | (Nick Logan)++ | src/core.c/CompUnit/Repository/FileSystem.pm6
Include resource files when calculating CURFS repository id

We sha1 the source code of module files for CURFS so we can tell when source code has changed. Since source code can rely on files in resources/ we should also sha1 those files as well.		 23:28
rakudo: ugexe++ created pull request #5280:
Include resource files when calculating CURFS repository id		 23:29

Powered by Cro and the Raku® Programming Language.

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

Thank you!