01:27 evalable6 left, linkable6 left 01:29 linkable6 joined, evalable6 joined 04:33 Kaiepi left 04:34 Kaiepi joined 07:10 frost-lab joined 08:37 tbrowder left, zostay left, kawaii left, SmokeMachine left 08:38 chansen_ left 08:49 frost-lab left 08:52 tbrowder joined, zostay joined 08:53 chansen_ joined 08:56 SmokeMachine joined, kawaii joined 09:10 sena_kun joined 09:13 chansen_ left, chansen_ joined 10:11 MasterDuke joined
Geth_ rakudo: usev6++ created pull request #4012:
Add missing decont		 10:35
nine Working on getting zef up and running I seem to becoming to more and more obscure issues. Like the package variable my @herestub_queue; from Perl6::Grammar getting reposessed. 10:39
Geth_ rakudo: patrickbkr self-assigned gmake fails on windows github.com/rakudo/rakudo/issues/4009
417ad76c07 | (Christian Bartolomäus)++ | src/core.c/ShapedNArray.pm6

The decont got lost in 18af3f4411. On the JVM backend this lead to RuntimeExceptions because the attribute $!reified was not found.		 10:41
nine Apart from being a good sign, fixing this to become an attribute instead will also fix an issue with multi threaded compilation. That variable is not protected by any locks. So multiple concurrent compilations could tread on each other's toes if they involve heredocs
MasterDuke sound like you're closing in on the end 10:42
nine I sure hope so 10:43
MasterDuke nice 10:44
10:54 patrickb joined
nine Of course, simply turning it into an attribute doesn't work. That would be too easy 10:55
Though I have no idea why. AFAICT there herestub_queue is for tracking multiple heredocs opened by a statement. Why would that need to be shared between Perl6::Grammar objects? 10:56
timotimo is there one perl6::grammar instance for every cursor or something? 10:59
also, mixins and such happen all the time, not exactly sure how that will interoperate
so it could really be a dynamic variable that would fit best? 11:00
nine Luckily one doesn't have to always understand a problem to fix it :) I just moved it into the World's compilation context. That is shared between nested compilations (e.g. BEGIN time EVALs) but not within nested precompilations - which is exactly what I want 11:04
And this seems to give me a working zef :) 11:08
Unfortunately, I don't seem to be the only one to make that X::Whatever error. It's also in JSON::Fast: modules.raku.org/dist/JSON::Fast:c...st.pm6#L67
This is wrong, isn't it? class Foo { class Bar { } } should create Foo and Foo::Bar, not Foo and Bar, should it? 11:09
I seem to remember vrurg++ working on something like this 11:10
Yeah, that can't be right: 11:14
m: class Foo { class Int::Foo { } }; Int::Foo.new
camelia ( no output )
nine m: class Foo { class Ints::Foo { } }; Ints::Foo.new
camelia Could not find symbol '&Foo' in 'Ints'
in block <unit> at <tmp> line 1
rakudo: 46477cd271 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/ShapedNArray.pm6
Merge pull request #4012 from usev6/shapedarray_fix

Add missing decont
timotimo ah 11:16
nine WTH am I gonna do with this? 11:18
11:18 Kaiepi left, Kaiepi joined 11:39 patrickb left
lizmat nine: re class Foo { class Ints::Foo { } }; Ints::Foo.new, could it be that when Ints::Foo is being created, it looks up Foo, finds it outside and decides it doesn't need to do anything wrt to registering it ? 11:48
nine Well for multi-part names it's apparently looking for the prefix in all available scopes and uses whatever it finds. Otherwise it's adding the symbol to the current package 12:06
12:09 Altai-man joined
lizmat prefix? You mean "Foo" in this case ? 12:10
12:11 sena_kun left
nine No, Int or Ints 12:19
It does find an Int package in global scope, so adds to that. It doesn't find Ints, so it adds it as Foo::Ints 12:20
The behaviour seems to be there since 2011. The comment in install_package says "If we have a multi-part name, see if we know the opening chunk already. If so, use it for that part of the name.". The commit message isn't terribly helpful: "Start to improve and clean up package and type installation to fix some bugs and make various things work that didn't before." 12:21
Also funny: 12:28
m: class Foo { class Int::Bar::Baz { } }; Int::Bar.^name.say; Int::Bar::Baz.^name.say;
camelia Int::Bar
Foo::Int::Bar::Baz
nine m: class Foo { class Ints::Bar::Baz { } }; Ints::Bar.^name.say; Ints::Bar::Baz.^name.say; 12:30
camelia Could not find symbol '&Bar' in 'Ints'
in block <unit> at <tmp> line 1
nine m: class Foo { class Ints::Bar::Baz { } }; Foo::Ints::Bar.^name.say; Foo::Ints::Bar::Baz.^name.say;
camelia Ints::Bar
Foo::Ints::Bar::Baz
12:33 patrickb joined
lizmat nine: it looks like my Array::Agnostic module is failing with "Object does not exist in serialization context" on bleed 12:34
perhaps that rings a bell / could be helpful ?
12:36 entonian joined
nine rr record the run, breakpoint on src/6model/sc.c:121, look what *obj->st is (might give the first clue), otherwise, look at the bt to see if it's a root object or a repossession, set a watch point on the appropriate array, reverse-cont then call MVM_dump_backtrace(tc) to see where it gets added... 12:38
nine seems to have done that... a lto
s/lto/lot/
12:43 entonian left 12:44 patrickb left
Altai-man nine, hmm, is rr working on ryzen? 13:38
oh, I see some patching was done recently to support it 13:40
lizmat nine: I have been able to golf the problem re Object does not exist down 13:44
it looks like it is specific to trying to pre-compile *anything* with Array:: 13:45
note: this seems to be only true for Array::
Hash::Bar is ok, Int::Bar is ok etc 13:46
and it is connected to the Array type, not to the name: constant Foo = Array; class Foo::Bar { } will fail the same way 13:47
so I guess it's something inside the Array class that is triggering this
13:51 Kaiepi left, Kaiepi joined 13:59 Kaiepi left, Kaiepi joined 14:10 Kaiepi left 14:13 Kaiepi joined
lizmat nine: good news (I guess): it's *not* caused by the latest MoarVM bump 14:18
that included the internment fixes
nine lizmat: sounds like one of those really strange issues... 14:21
Altai-man: github.com/mozilla/rr/wiki/Zen
lizmat well, the Array class is spread out over many files, and I have been doing work there recently 14:22
wish I had set up local "test all of my modules" functionality sooner
ah, what I *do* know, is that it got introduced *after* 2020.10
nine Now that does narrow it down tremendously 14:23
lizmat yeah, because the Github Actions CI use 2020.10 and do *not* report any issues on these modules
MasterDuke huh, github.com/rakudo/rakudo/blame/mas...1623-L1639 doesn't seem to get called when it's literals on the RHS 14:42
e.g., `my @a = 1,2` doesn't do it, but `my $a = 1; my $b = 2; my @c = $a, $b` does
lizmat MasterDuke: unless it's an easy fix, I wouldn't spend too much time on it as the rakuast work will probably throw all of that out 14:45
MasterDuke yeah, this was just a distraction 14:46
nine zef is actually a pretty interesting case for working on precomp, because a zef install zef has to precompile stuff that's also currently loaded 15:04
lizmat nine: looks like ee089234fc0256df54b is the cause
linkable6 (2020-11-01) github.com/rakudo/rakudo/commit/ee089234fc Expose the Array::ShapedArray role
lizmat argh, not it isn't :-( 15:06
huh?
lizmat goes back to further bisecting
aah... it's actually ee089234fc0256df54b **and** 532b5423f0950395af686 15:10
linkable6 (2020-11-01) github.com/rakudo/rakudo/commit/ee089234fc Expose the Array::ShapedArray role
(2020-11-01) github.com/rakudo/rakudo/commit/532b5423f0 Expose Array::Shaped1|2|3Array roles
nine Neither of which give a real hint about why it's broken now 15:11
lizmat well, before, they were "my"
now their "our" *inside* of another class
that feels like a hint to me :-)
nine But roles are our scoped by default, which means that's a very common case 15:12
lizmat well, maybe because it's in the setting, it's special :-) 15:13
and usually I'd say roles are top levelly exposed, no ?
nine not necessarily
lizmat is going to try stubbing these roles 15:14
yup, that seems to fix things 15:17
nine But why did the change break something in the first place? 15:18
lizmat I have no idea, but I haven't been able to reproduce the problem outside of the setting 15:20
it all came back on the Array class
adding roles to other core classes, such as a "Int::Foo" role all worked fine 15:21
so I guess maybe it has to do with Array having been set up in the bootstrap ? 15:22
nine same's true for Int? 15:23
lizmat yeah, but Int doesn't have any roles inside of it 15:24
nine Hash does 15:25
lizmat ok, lemme see what happens if I un-"my" that :-) 15:26
in any case, there's no reason to expose those, as they wouldn't have any dispatching benefits 15:27
well, in the current naming scheme 15:28
nine And of course its parametrics that makes life just a bit too interesting again 15:43
Even the returns trait on routines mixes something into the routine which creates a parameterized type. 15:45
MasterDuke hm. the `.value` of this QAST::WVal is a Regex, not its QAST::Regex 15:46
isn't that one of the reasons `-->` is preferred over `returns`? 15:47
or do both do that?
could i get the QAST::Regex with/from the cuid of the Regex? 15:50
nine actually --> seems to do the same 15:57
But...this issue only appears when the module is precompiled in the same process as it's installed. I.e. a "bin/zef install ." with an empty .precomp works, but a "bin/zef ; bin/zef install ." does not 16:02
So I guess it's one of those "add tons of debug output until you see a critical difference" things 16:03
MasterDuke imgflip.com/i/4lkizs 16:05
nine yeah :) 16:06
16:10 MasterDuke left, sena_kun joined 16:12 Altai-man left
Geth_ rakudo: cb95c6532e | (Elizabeth Mattijsen)++ | src/core.c/Array.pm6
Stub the Array::ShapedXArray roles

These roles need stubbing for some reason, otherwise they will cause
  "Object does not exist in serialization context" error when trying to
create something inside the Array class, like the Array::Agnostic role does, which happened after ee089234fc and 532b5423f0.		 16:14
16:19 MasterDuke joined
lizmat nine: confirmed: exposing the TypeHash role creates similar issues with Hash::xxx 16:20
MasterDuke nqp: grammar F { token TOP { \d <foo> \d }; token foo { "123" } }; my $a := -1; my $b := 0; my $s := nqp::time_n; while $a++ < 500_000 { $b++ if F.parse($a) }; say(nqp::sub_n(nqp::time_n, $s)); say($b)
camelia 2.530207872390747
490
MasterDuke nqp: grammar F { token TOP { \d <foo> \d }; token foo { "123" } }; my $a := -1; my $b := 0; my $s := nqp::time_n; while $a++ < 500_000 { $b++ if nqp::index($a, "123") >= 0 && F.parse($a) }; say(nqp::sub_n(nqp::time_n, $s)); say($b) 16:21
camelia 0.1543412208557129
490
MasterDuke timotimo: you had some thoughts yesterday about how to get from the WVal to the QRegex? 16:23
16:30 leont joined
MasterDuke or any suggestions for, as the above example shows, a way to do this optimization for grammars? 16:30
nine Ahh! It works when the module is precompiled in the same process, because after precompilation follows the sc_disclaim, i.e. the types in the parametrics cache are free for grabbing by the precompilation. When the module's already precompiled it gets loaded and remembers the SC it came from 16:40
So...what if we disclaim all objects we get from the parametrics cache? 16:43
lizmat
.oO( I disclaim any responsibility :-)
 16:46
nine Or maybe less drastic, to disclaim then when we serialize 16:47
lizmat alas, my cunning plan making dispatching on objecthashes possible, has failed 16:57
17:17 go|dfish left
Geth_ rakudo: 1321a8533d | (Elizabeth Mattijsen)++ | src/core.c/Hash.pm6
Simplify Hash parameterization

  - don't need a Capture, we only call this with 1 or 2 parameters
  - add checks for "useless" parameterization, such as my Mu %hash
  - give internal roles different names describing their function better		 17:55
18:01 MasterDuke left 18:34 domidumont joined 18:38 domidumont left 18:58 samebchase- left 18:59 samebchase- joined 19:00 bartolin joined 19:08 gfldex left 19:09 gfldex joined
Geth_ roast: c4741e0954 | (Christian Bartolomäus)++ | S06-signature/shape.t
Fix typos in test descriptions
 19:31
19:37 MasterDuke joined
Geth_ rakudo/expose-objecthash-role: 1efb9e9b59 | (Elizabeth Mattijsen)++ | 19 files
Expose ObjectHash/TypedHash roles

These roles used to be internal to the Hash class. By exposing them it is possible to use them for easy typechecking and dispatch.
This makes the rather esoteric check:
... (19 more lines)		 19:50
rakudo: lizmat++ created pull request #4013:
Expose ObjectHash/TypedHash roles
20:09 Altai-man joined 20:12 sena_kun left 22:28 MasterDuke left 23:17 Altai-man left

Powered by Cro and the Raku® Programming Language.

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

Thank you!