🦋 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.
lizmat aaah... the plot thickens: in the -e case, it does *not* re-precompile 00:00
ugexe precompilation on module installation (and thus on rakudo rebuilding) is just brute force from what i recall
lizmat you have to have the use in a script and then run that
MasterDuke interesting. i was just experimenting with -e and couldn't get double (re)compilation 00:02
00:02 reportable6 left
lizmat the script I was using to load the module, had a "use v6.*" in it 00:04
without it, it doesn't re-precompile
I'm calling it a day, as I'm starting to lose track of channels& 00:05
00:05 reportable6 joined
ugexe maybe a use v6.d would fi it 00:06
use v6.* is kind of pointless
s/fix/workaround/ 00:07
00:12 squashable6 left 01:29 dogbert11 left 01:48 nebuchadnezzar left 02:06 frost joined 02:09 Xliff_ left 02:38 dogbert11 joined 02:41 dogbert17 joined 02:43 dogbert11 left 02:51 dogbert17 left 02:53 dogbert17 joined 03:06 nine left, nine joined 03:14 squashable6 joined 03:55 dogbert17 left 04:43 dogbert17 joined 05:08 dogbert17 left 05:47 dogbert17 joined 06:03 reportable6 left 06:05 reportable6 joined 07:10 dogbert17 left 07:12 nebuchadnezzar joined
nine Precompilation after a rakudo rebuild does not go through the same code as installation. After a rakudo rebuild we only do the normal on-demand precompilation as we don't find any precomp files for the current compiler version. 07:34
07:39 dogbert17 joined 08:02 dogbert17 left 08:14 squashable6 left 08:40 dogbert17 joined 09:12 sena_kun joined 09:19 dogbert17 left, dogbert17 joined
Geth rakudo/remove-experimental-collation: 9e13d2374e | (Elizabeth Mattijsen)++ | 2 files
Remove support for use experimental :collation

It is now supported by default, and was marked to be deleted in 2019, so seems to have ample sunsetting time for this feature.		 10:17
rakudo: lizmat++ created pull request #4616:
Remove support for use experimental :collation		 10:18
lizmat ugexe: sleeping a night on the double precomp issue, I think it was caused by the fact that the compunit of my script had a different language version than the reference to the same module by another module 10:21
and that would make sense that it would create a different precomp sha, wouldn't it ? 10:22
Skarsnik *being annoying* Can someone comment on my last post on github.com/Raku/problem-solving/issues/186 so I can maybe took another shot at it tomorrow (I am trying to do like Zoffix a while ago with Rotfix Thuesday) x) 10:29
10:33 evalable6 left, linkable6 left 10:35 evalable6 joined, linkable6 joined
lizmat wonders how hard it would be to convert the RAKUDO_MODULE_DEBUG logic into something that Log::Timeline or similar could handle 11:07
11:26 Altai-man joined 11:46 squashable6 joined
Geth Blin/ugexe-patch-1: 04c1d2d9b4 | Altai-man++ | docker/pkg-dependencies
Add new native library
 11:47
Blin/ugexe-patch-1: b751d7a63a | Altai-man++ | docker/Dockerfile
Accomodate for new zef installation path
Blin/ugexe-patch-1: d7428f0dfc | Altai-man++ | lib/Blin/Tester/Zef.rakumod
Accomodate for new zef config layout

See github.com/ugexe/zef/commit/a12d28...83dL32-R44 for details.
Blin/master: 8 commits pushed by (Nick Logan)++, Altai-man++ 11:48
12:02 reportable6 left 12:05 reportable6 joined
[Tux] Rakudo v2021.10-46-gd88d1cc0e (v6.d) on MoarVM 2021.10-23-g4d145b465
csv-ip5xs1.376 - 1.379
csv-ip5xs-2015.600 - 15.640
csv-parser4.159 - 4.223
csv-test-xs-200.371 - 0.379
test7.066 - 7.315
test-t1.599 - 1.627
test-t --race0.991 - 1.005
test-t-2023.561 - 23.758
test-t-20 --race7.760 - 8.192
 12:32
Geth nqp/new-disp-nativecall: 791163b286 | (Stefan Seifert)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Remove last remnant of old invocation protocol
 13:23
lizmat whee! 13:26
13:38 frost left
Geth rakudo/new-disp-nativecall: 14 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/1...f1c80a3908		 14:46
nqp/new-disp-nativecall: bdd31cefe9 | (Stefan Seifert)++ | 4 files
API for asking whether the compiler supports a certain nqp op

This can be used to conditionally compile backend specific code in modules like NativeCall		 14:51
nqp/new-disp-nativecall: 8b609200d8 | (Stefan Seifert)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Remove last remnant of old invocation protocol
15:40 evalable6 left, linkable6 left 15:41 linkable6 joined 16:22 patrickb joined 16:43 evalable6 joined 17:00 patrickb left
Geth rakudo: ab02205ed4 | (Jonathan Worthington)++ | src/vm/moar/ops/perl6_ops.c
Add a missing MVMROOT in extops
 17:44
18:02 reportable6 left
lizmat ugexe: so, is what you specify in a META6.json "depends" the name of a key in a <provides> , or the "name" of a distribution 18:09
or can it be both?
case in point: there are modules that list "LibCurl" as a dependency, and others that list "LibCurl::Easy" 18:10
ugexe currently it can be both, but that is just because that was what was always done. the spec says its supposed to match what you would find in 'use' statements so technically dist names shouldnt work
tellable6 2021-11-03T11:05:06Z #raku <tbrowder> ugexe ^^^
lizmat right, so technically modules that have a depends on a dist name are technically wrong 18:11
ugexe in that respect yeah, but its also kind of dumb to require them to put multiple modules from what may be a single distribution in their depends 18:12
lizmat true that
Altai-man what's the motivation of the spec in this case? If I'm using 10 things from a distribution, I have to type 10 things into depends?
lizmat hmmm
ugexe things would be a bit better if we hadnt used :: in distribution names
lizmat well, empirically you only need to mention the distro name
in any case, if you specify a single module from a dist, you would get the whole dist anyway 18:13
Altai-man which is "technically wrong" according to the spec, but I always assumed there is a rule like "if the spec says dumb thing then fix the spec, don't blindly believe", no?
ugexe yeah but getting the whole dist might not matter is contexts outside of package management
lizmat indeed :-)
Altai-man specifying just one arbitrary module from a dist is also confusing 18:14
lizmat yeah... also true
ok, so I guess we should just allow a dist name as a dependency
ugexe the nice thing about listing all modules in depends would be we could introspect that and automatically apply the required versions and stuff to all the imports 18:15
18:48 Altai-man left 19:03 reportable6 joined
lizmat ugexe: suppose I install a module with many dependencies, shouldn't it be possible to install depencies that have no depencies themselves, in parallel ? 19:18
ugexe that is why zef has various --[phase]-degree options 19:19
but a given CURI.install is basically a giant lock so that part no
lizmat and the CURI.install lock is there because we want to make sure we don't create any parallelization issues 19:20
right? 19:21
ugexe thats generally all locks are used for yeah 19:23
lizmat ok 19:25
hmmm... does zef at least test these "leaf" modules in parallel ? 19:26
there shouldn't be any reason not to, apart from complexity :-)
ugexe if you give it a --test-degree=... then sure, but yes there are reasons
like tests just fail for no reason occasionally
lizmat ok... best be conservative, is what you're saying 19:29
in testing
ugexe maybe things have gotten better since i implemented the defaults 19:30
--test-degree and --fetch-degree were added sep 3 2019 19:31
there is also equiv env vars ZEF_FETCH_DEGREE and ZEF_TEST_DEGREE
lizmat ok, will check it out 19:32
20:28 evalable6 left, linkable6 left 20:31 linkable6 joined 21:30 evalable6 joined 21:34 sena_kun left
Geth rakudo/Rakudo-CORE-META: 4c874a8b35 | (Elizabeth Mattijsen)++ | 2 files
Abstract virtual core META6.json into a module

The install-core-dist.raku script kept the information about which files are actually part of the Rakudo core distribution to itself.
This commit extracts that information into a separate module, so that other programs can get at the meta information in a reliable ... (7 more lines)		 21:36
ugexe its not good practice to have a module in a lib and its not in the meta6.json
Geth rakudo: lizmat++ created pull request #4617:
Abstract virtual core META6.json into a module
lizmat ugexe ?? 21:38
ugexe oh it is in there, but i guess that isnt really ideal either 21:39
fwiw i'm stil against all these modules in core
not just this one, but a lot of them 21:40
lizmat but wouldn't you want to be able to check dependencies on e.g. NativeCall in zef ?
with this, you would be able to
ugexe it can check 21:42
lizmat you mean, now? how? 21:43
ugexe i guess im misunderstanding something because it would be however you check any other dependency 21:44
lizmat in Ecosystem::Archive I'd like to be able to check all dependencies and reverse dependencies 21:45
NativeCall and Test are sort of deal breakers here
with %Rakudo::CORE::META I would be able to reliably check for core modules as well 21:46
as valid targets of a "use" statement
ugexe i dont understand how you cant check for those without this
you query the CompUnit repositories 21:47
this is like adding a Build.pm type module into the lib/
this = that pr
lizmat well, querying the CompUnit repos is checking for what is available that's locally installed, right ? 21:48
ugexe if you only query CURI yeah
lizmat unless of course there's a $*REPO implementation that is smarter
but yeah, assuming there's only CURI
and we're not using -Ilib 21:49
or -I more generally
ugexe i dont understand what is wrong with e.g. $*REPO.repo-chain.map(*.?candidates(...))
or even .resolve
anyways `zef rdepends NativeCall` is what should do whatever you mentioned earlier except it looks like i broke that when i added return type constraints at some point 21:50
lizmat because that would be only what is locally installed ?
ugexe no, it is whatever implemented .candidates 21:51
implements^
if you only want locally installed, which i assume means CURI, then just do a .grep(CompUnit::Repository::Installation)
lizmat well, my goal is to be able to produce a database for all modules that ever existed (a la BackPan) 21:53
and an API / interface to it 21:55
ugexe ...so implement CUR? 21:56
i just dont see what that has to do this that module
lizmat well, I want to do many things with that information...
such as checking if all dependencies of a module are correct 21:57
ugexe how does that module help with that?
everything you've said so far you can already do, so i dont quite understand 21:58
lizmat by being able to report that distribution foo:ver<>:auth<> has a dependency on bar:ver<>:auth<>, but that there is no module or distro with that identity
ugexe why not just ignore everything in the site and home repos 21:59
er, site and core? perl? i forget the second core one
or instead of ignore, consider those instead of just ignoring them 22:00
lizmat this is not a module that would be used by many people
it would probably just be used by a server providing backpan modules and maybe some other people interested in spelunking
ugexe we are talking about lib/Rakudo/CORE/META.rakumod?
lizmat no Ecosystem::Archive 22:01
you're saying that the META hash that is provided by Rakudo::CORE::META could be build by calling stuff on $*REPO? 22:02
if that is so, then I'll just make an ecosystem module that would do that
but I got the impression you could only ask a $*REPO for specific things, not say "give me all" ? 22:03
ugexe no. one thing is that module shouldnt be in lib/... put it in one of the build tool directories or something if you really want a module for this
lizmat and adapt the info in provides? 22:04
ugexe but you can also generate most META6 hashes via Distribution::Path.new(...).meta
er, scratch that
because there is no meta6 it would have to be:
CompUnit::Repository::FileSystem.new(prefix => "path/to/lib").distribution.meta
ideally those modules would be split into logical distributions with literal META6.json files, though as i mentioned that would require updating e.g. make spectest to those new dirs 22:06
lizmat hmmm... so CompUnit::Repository::Staging should also live in the tools/build dir, right ? 22:07
ugexe m: say CompUnit::RepositoryRegistry.repository-for-name("core").installed.map(*.meta<provides>.keys.Slip).join(",") 22:09
camelia NativeCall::Compiler::MSVC,newline,SIL,safe-snapper,Telemetry,NativeCall,experimental,MoarVM::Spesh,Pod::To::Text,SL,snapper,Test,MoarVM::Profiler,NativeCall::Types,CompUnit::Repository::Staging,MoarVM::SL,MoarVM::SIL,BUILDPLAN,NativeCall::Compiler::G…
ugexe CompUnit::Repository::Staging should be in the core but it cant for some reason
lizmat looks like Compunit::Repository::Staging can live in tools/build 22:13
ugexe its intended to be used to eventually get around the double precomp of testing
it was originally going to be put in core but i believe the build process did not work (maybe nine remembers) so it was put in lib/ 22:14
lizmat ok, thanks for the enlightenments again 22:15
I think I'll make an ecosystem module out of it instead
but not today... 22:16
ugexe that one liner above would be the idiomatic way to get the modules included with a raku compiler 22:17
imo
lizmat right... 22:18
will get back to this tomorrow
for now, afk&
Geth rakudo/Rakudo-CORE-META: 5d7a5acf0e | (Elizabeth Mattijsen)++ | 5 files
Move moduled to tools/build
 22:23

Powered by Cro and the Raku® Programming Language.

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

Thank you!