🦋 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.
Geth rakudo/megamorphic-handlers: 85df0ba1a1 | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Use named constants for megamorphic thresholds
 10:23
Geth rakudo/master: 13 commits pushed by (Jonathan Worthington)++
review: github.com/rakudo/rakudo/compare/5...5adc06c3ff		 11:20
[Tux] Rakudo v2021.10-42-g665adc06c (v6.d) on MoarVM 2021.10-21-g0821570aa
csv-ip5xs1.360 - 1.478
csv-ip5xs-2015.669 - 16.848
csv-parser4.202 - 4.396
csv-test-xs-200.372 - 0.387
test7.247 - 7.966
test-t1.653 - 1.708
test-t --race0.981 - 1.081
test-t-2025.124 - 25.381
test-t-20 --race7.565 - 8.440
 14:43
Xliff_ gist.github.com/Xliff/77534ec98cfb...7d2145149e 14:54
lizmat hmmm... should a "depends" field in META6.json be an array, or a hash? 16:34
ugexe there are two forms, one is an array and one is a hash
lizmat github.com/CurtTilmes/raku-db/blob...6.json#L11 16:35
aha
ugexe github.com/ugexe/zef/blob/master/t...-parsing.t
lizmat ugexe: but that's an array, in which the element can be a hash 16:36
the DB example, it's a hash on the outside
ugexe there are various formats
lizmat so there are 3 forms at least
ugexe github.com/ugexe/zef/blob/ba39127d...sing.t#L52
lizmat aaah I see... 16:37
ugexe there are two data types that can be used for depends. there are also two different ways to declare the items inside depends
i.e. string "Foo:ver<1>" and hash `{ "name":"Foo", "ver":1 }`
lizmat ok, thanks for the examples
ugexe: so there's no form of: depends: "Foo" 16:41
aka, just a scalar value
ugexe no
Geth nqp: 94a5440799 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump NQP to get the latest MoarVM fixes
 17:51
Geth rakudo: a8329f6fd0 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get the latest MoarVM fixes
 18:04
lizmat well... actually Rakudo of course :-( 18:05
if a module depends on NativeCall, should it be listed as a dependency? as it is always in a Raku distribution? 18:07
or is NativeCall considered an implementation detail?
github.com/tony-o/raku-fez/blob/ma...6.json#L11 # case in point 18:08
ugexe yes its a dependency 18:10
a strict code base would require e.g. versioning requirements on it etc
plus if you want to do something like install all dependencies into a single external repo you have to list them all 18:11
lizmat but how would you install "NativeCall" ? 18:44
without installing Rakudo? 18:45
you're basically saying that you're depending on Rakudo, but without Rakudo the whole thing would be pointless anyway
ugexe just get the distribution from a CURI (probably site) 18:50
and install it wherever
my $dist = CURI.candidates(...). CURI.new(prefix => ...).install($dist) 18:51
this is why i keep saying CURs are naive recommendation engines 18:52
also why i think the core modules should be broken into individual distributions, but that would require updating all the build tooling to add the additional -I paths 18:54
i cant really think of a single advantage of not treating them as dependencies 19:00
lizmat fair enough :-) 19:02
now, to create a fully qualified identity for NativeCall 19:03
ugexe its unfortunate we cant do that fully -- they are all versioned as e.g. 6.d
lizmat NativeCall:ver<*>:auth<core> ?
ugexe instead of 6.d.$foo
the auth is still perl i believe
lizmat where is that mentioned ? 19:04
ugexe the META6.json in lib 19:05
well i guess that gets generated at build time
lizmat doesn't seem to survive that ?
ugexe its inside install-core-dist or whatever script
MasterDuke github.com/rakudo/rakudo/blob/mast...t.raku#L47 i guess? 19:06
lizmat ah, ok
it's not an in-file meta
maybe we should just add that to lib ?
ugexe it is after install
but its some sha1 in a install repo 19:07
and it wouldnt go in lib, it would go in lib/../, and it would look out of place there
lizmat what would be a reason against just adding a META6.json to the rakudo lib dir ?
ugexe because META6.json doesnt go in lib
technically you could but i wouldnt do it
lizmat right, so it should be in the root dir
so any reason to not put it in the root dir ? 19:08
ah, I see now...
different META6.json for different backend
s
do we have support for dependencies for different backends? 19:09
ugexe not really, that doesnt belong in META6.json which doesnt is not tightly coupled to an implementation that has backends... you could use like from<bin> to find an appropriate backend 19:10
similar to how you cant say you want a rakudo > 2021.12 19:12
lizmat hmmm... 19:20
anyways, thanks for the explanation :-) 19:21
ugexe it does suggest writing modules that only work on one-backend are not what the goal of raku was
lizmat it does, doesn't it.. :-) 19:24
Geth roast: 6f76902ad6 | (Daniel Green)++ | S32-num/expmod.t
Turn a skip in expmod tests into a todo

This way when it starts passing we'll know to un-todo it.		 19:40
roast: 0db9b58f51 | MasterDuke17++ (committed using GitHub Web editor) | S32-num/expmod.t
Merge pull request #770 from MasterDuke17/turn_skip_in_expmod_test_into_todo
rakudo/change-auth-core-modules: 30e0b05268 | (Elizabeth Mattijsen)++ | tools/build/install-core-dist.raku
Make "raku" the authority of core modules

Seems to me that "perl" is a bit... outdated. And changing it to
  "raku" doesn't break any tests.		 19:42
rakudo: lizmat++ created pull request #4613:
Make "raku" the authority of core modules		 19:43
rakudo: 1fec0ef26e | (Vadim Belman)++ | 5 files
Clarify let and temp operators

Make sure they preserve and restore holes in arrays (though preserving currently depends on `clone` method implementation) and conterization of elements.
The new implementation shifts the locus of control to `Array` and `Hash` ... (15 more lines)		 19:50
rakudo: 8986875eac | (Vadim Belman)++ (committed using GitHub Web editor) | 5 files
Merge pull request #4602 from vrurg/rakudo_1433

Clarify let and temp operators
Geth rakudo: d88d1cc0e4 | (Elizabeth Mattijsen)++ | src/core.c/Process.pm6
Introducing RAKUDO_PRECOMPILATION_PROGRESS

If set to 1, will show modules being precompiled on STDERR, like:
Precompiling Ecosystem::Archive
   Precompiling Cro::HTTP::Client
   Precompiling Base64
... (6 more lines)		 21:17
lizmat ok, this ^^ feature allowed me to spot a module being re-compiled when I think it shouldn't 22:18
it appears that a "use Foo" and "use Foo:ver<0.0.42>" are treated as different identities, even if only Foo 0.0.42 is installed 22:19
so it feels to me that the version of the module *found* is *not* taken into account on the decision whether or not to re-compile 22:21
note that these uses are in different compunits 22:23
but they refer to the same actual module
MasterDuke that does seem like the re-compilation might not be necessary. but how common of an occurrence is that? 22:26
japhb MasterDuke: I actually think that might be rather common, especially as more people use versioned/authed 'use' ... because when you get deep in the dependency stack, there will be a lot of modules required by LOTS of stuff. 22:34
lizmat yes, and e.g Cro is not using versioned uses internally, e.g. 22:35
but that should be fine
japhb And some module authors have been versioned-requiring all of the modules within the dist
lizmat the problem is really that rakudo is not doing the right thing, IMO 22:36
going to sleep over that &
japhb So for those modules, you'll have the versioned 'use' internally, and then all the outside users who *don't* do that will recompile
lizmat: Right, and sleep well
ugexe because Foo:ver<*> is not the same as Foo:ver<0.0.42> 22:38
MasterDuke sure. but if you ask for * and get 0.0.42, and you've already precompiled 0.0.42, do you have to recompile? 22:41
ugexe for CURFS yeah, because you cant encode e.g. version ranges into a file path 22:42
tonyo that ambiguity in loading is something that users should be advised to avoid
`use Foo:ver<1>` should be the common case and an open `use Foo`
ugexe for CURI i wouldnt expect it to recompile though 22:45
ugexe for CURFS you either accept those will re-precompile or that they don't consider specific versions 22:51
right now they will consider specific versions, e.g. `use Foo:ver<3>` will fail if Foo isnt ver 3 22:52
this is yet another reason we have CURI
if there is a way around this i havent been able to think of it over the past many years 22:53
ugexe pretty sure it would be the same deal with CURAP and things like ./foo/bar and ./foo/bar/../bar 23:03
lizmat ugexe: it's *with* CURI that it recompiles 23:33
ugexe yeah that is unexpected
lizmat I'll try to figure out more tomorrow, unless someone beats me to it :-) 23:35
ugexe RAKUDO_MODULE_DEBUG=1 raku -e 'use Zef:ver<0.13.0>; use Zef;' 23:37
when i do that i see no precompilation occuring
lizmat that's because it checks the compunit to see if it is already there ?
and doesn't bother to load again?
ugexe i dont see the difference between your example and mine 23:40
if my example isnt the same then i dont quite understand 23:42
MasterDuke what if you put each use in its own { }? 23:48
japhb ugexe: Yeah, I *think* lizmat is saying that if different compunits have the different 'use' formats (with and without `:ver`), you'll get the problem. Your test is just one compunit. 23:50
lizmat also: look at the sample output I made: gist.github.com/lizmat/acbe0cdfc42...4a99d1b11d 23:54
it lists Cro::HTTP::Client twice
for example
ugexe: way to reproduce:
zef install Ecosystem::Archive 23:55
make a change in rakudo and make install it again
then run 'RAKUDO_PRECOMPILATION_PROGRESS=1 raku -e 'use Ecosystem::Archive' 23:56
ugexe ah i can't say what I expect to happen when you rebuild rakudo 23:58
lizmat why else would it recompile ?
ugexe bugs?
lizmat there's that :-) 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!