🦋 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:02 reportable6 joined 01:37 MasterDuke left 01:49 frost joined 02:30 nine left 02:32 nine joined 02:41 melezhik joined 02:52 melezhik left 03:02 melezhik joined 03:06 melezhik left 04:07 frost left 04:45 melezhik joined 04:49 melezhik left 06:00 reportable6 left, reportable6 joined 07:27 frost joined 08:18 frost left 08:31 sena_kun joined 09:27 ab5tract joined
ab5tract m: class Day::Foo {}; enum Day<Mon>; dd +Day::Mon 10:15
camelia Could not find symbol '&Mon' in 'Day'
in block <unit> at <tmp> line 1
ab5tract ^^ works on my branch :D
I've found some buggy corners like this in base's enum implementation 10:16
m: enum E (("A" => "AA"), "B", "C"); 10:17
camelia ( no output )
ab5tract nevermind this last one. 10:18
10:30 sena_kun left
ab5tract I take it we are not in the business of reproducing like-for-like bugs with base, right 11:06
?
lizmat no, I'd say, not in corner cases 11:07
it becomes different if we find out there's a lot of code out there that's depending on a faulty behaviour, i guess 11:08
11:08 sena_kun joined 12:00 reportable6 left 12:03 reportable6 joined
lizmat nine: creating a RakuAST version of BUILDALL has a unique challenge 12:12
the BUILDPLAN basically contains QAST for the BUILD and TWEAK methods, right? 12:13
which means one would have to codegen something that takes QAST
I'm starting to lean towards ripping out the current QAST building logic of BUILDALL and use that 12:14
opinions?
or maybe we should not put QAST in the BUILDPLAN, but RakuAST ? but then we would be incompatible with base 12:15
or maybe set up an alternate RakuAST BUILDPLAN? which would allow some refactoring, probably 12:16
ab5tract nine: when trying to compile latest NQP: 12:19
===SORRY!=== Error while compiling gen/moar/stage1/NQPCORE.setting
Use of undeclared variable '&note' at NQP::src/core/IO.nqp:11, near ");\n\nmy cla"
lizmat ab5tract ? I don't see that? 12:20
ab5tract this was after a make realclean and a rebase to latest 12:21
lizmat builds clean out of the box for me 12:26
are you on some branch ?
ab5tract I shouldn't be 12:27
12:27 samebchase left
ab5tract deleting nqp and retrying 12:27
12:28 samebchase joined
ab5tract Yeah, it looks like PEBKAC :) 12:28
12:31 samebchase5 joined 12:33 samebchase left, samebchase5 is now known as samebchase 12:53 codesections1 joined 12:54 codesections left, codesections1 is now known as codesections 13:01 MasterDuke joined 13:03 frost joined
lizmat nine: I just realized that classes in RakuAST work only atm because the fall back to Mu.BUILDALL 13:14
still haven't figured what is setting up the buildplan, though :-( 13:15
13:18 melezhik joined
[Coke] awaits the day when we 13:23
13:23 melezhik left
[Coke] need a blin run with and without AST to compare! :) 13:23
MasterDuke [Coke]: you use rakudo on windows, right? 13:27
13:27 Geth joined 13:29 Altai-man joined, sena_kun left 13:32 frost left 13:35 frost joined
nine ab5tract: you had my debugging aid in there 13:43
lizmat: I thought a BUILDPLAN was a bunch of numbers that got interpreted by that builder in Mu? How does QAST factor into it? 13:44
lizmat ah, in the old days, yes 13:46
but nowadays, classes get a custom BUILDALL method built in QAST
which improved performance of HLL object creation significantly 13:47
[Coke] MasterDuke: for work, yes. 13:52
just had to tell a coworker to install something with --/rea because the install failed with it enabled. :|
lizmat but.... that would imply the module didn't exist in fez ? 13:53
it should only use the REA if it doesn't find it in fez by default, no?
[Coke] guessing the paths in rea are too long for windows default disk setup 13:54
I can only report on the symptom and the workaround. I am guessing it picked rea's version and then had issues with a long path, but it's only a guess.
lizmat hmmm feels to me that zef (at least temporarily) should soft fail on the REA then in that case, instead of a hard fail?
afk for a few hours& 13:55
nine lizmat: the custom BUILDALL sounds like something you just create in pure RakuAST and ignore all prior art 13:56
lizmat that was my plan.... until I realized that the BUILDPLAN contains QAST for TWEAK and BUILD methods 13:57
and I don't really see how to deal with that in RakuAST
for one, it will be impossible to deparse 13:58
and roundtrip
MasterDuke [Coke]: server 2022 perhaps? 14:01
lizmat just realizes that it is probably the compose of a class that sets up the BUILDPLAN, which isn't anywhere in the src/Raku tree
really afk& 14:02
[Coke] OS Name: Microsoft Windows 10 Enterprise
OS Version: 10.0.19044 N/A Build 19044
(systeminfo | findstr /B /C:"OS Name" /C:"OS Version") 14:03
MasterDuke arg. wondering about the fails in dev.azure.com/MoarVM/6b7ef196-3f6c...8a0b8a3eb3
14:05 codesections left 14:06 codesections joined
nine Now I'm confused. There is a BUILDPLAN - a list of numbers - but that was only used in the old days and there's a BUILDALL method that gets generated but generating that via RakuAST doesn't work because the BUILDPLAN contains QAST? I'm clearly missing a step or two here 14:08
14:18 codesections left 14:19 melezhik joined
vrurg nine: where did you get QAST from? BUILDALL is not generated – it is on Mu and is using buildplan list. 14:21
nine vrurg: 14:46 < lizmat> but nowadays, classes get a custom BUILDALL method built in QAST
14:22 melezhik left, melezhik joined
vrurg something is wrong here. I'm trying to figure out. 14:22
Ah, actually – true, World does a method for that. I totally forgot. 14:24
ClassHOW, lines 221+ 14:26
14:28 melezhik left
vrurg I don't see actual QAST in the BUILDPLAN itself, but what is there is Metamodel::BUILDPLAN is actually using World and that's certainly a problem. 14:29
nine That will need replacing with RakuAST 14:31
vrurg Not totally related, but ModuleLoader is the only location where QAST is used. That would need some care too. 14:34
Unfortunately, I still can't pick any of these tasks. :( 14:35
nine That QAST stuff in ModuleLoader is not used by RakuAST anyway 14:42
It has its own implementation of merging symbols
14:50 Altai-man left
ab5tract m: enum day (:Sun(1)); my $x = "Today" but day(Sun); dd +$x.Sun; 15:01
camelia 1
ab5tract currently that dies on my branch with: "No such method 'Sun' for invocant of type 'Str+{<anon|1>}'" 15:02
could that be an issue with the way roles are applied? Or is it something broken in my specific code? (nine's axiom suggests the latter, but I wanted to be sure) 15:03
From inspecting base, it also seems like the proper error message should be "No such method 'Sun' for invocant of type 'Str+{day}' 15:09
nine Is "but" even implemented yet? 15:16
ab5tract nine: maybe not, lol :D 15:19
there's a lot of weirdness in enum though....
m: my Str enum day (:Sun("hi")); my $x = "Today" but day(Sun); dd $x.Tue; 15:20
camelia No such method 'Tue' for invocant of type 'Str+{day}'
in block <unit> at <tmp> line 1
ab5tract m: my enum day (:Sun(1)); my $x = "Today" but day(Sun); dd $x.Tue; 15:29
camelia No such method 'Tue' for invocant of type 'Str+{day}'
in block <unit> at <tmp> line 1
ab5tract seems to be related to the scope of the enum
685 passing spectests in my branch 15:33
other test file failures seem to be related to non-subset things 15:51
erm, non-enum things
nine: I see from line 269 of literals.rakumod that I shouldn't expect '«:Letter[0,0,612,792]»' to work as in base atm? 15:53
is that a straightforward problem to solve? 16:07
16:07 frost left
sjn hm. I just ran "make spectest" on rakudo 2022.12, and got a bunch of failed tests... what's the best way to report these? 16:17
Maybe the spec test is too new... Hm. 16:18
spec tests are*
[Coke] which tests, what OS? 16:25
Probably worth reporting, even if it gets closed as intended, to point others at. 16:26
sjn [Coke]: Ubuntu 22.10, and a whole bunch of tests. Note that I checked out the 2022.12 tag from git, and ran the spec tests on that; I noticed one of the tests that failed was t/spec/S02-types/bag.t number 252, which I think is a test that came after the 2022.12 release? 16:28
so there may be something out of sync here
[Coke] because of the nature of the spec tests, it is possible that that spec test is tied to a bug that was fixed, yes. (We probably need to do a better job of documenting that sort of thing in comments/code) 16:29
I would expect only a few, not many, though. approximate count? Are they AST related? 16:30
sjn oof, there are quite a few
t/spec/S15-normalization/nfc-concat.t had 2040 failed tests, for instance
ah, no. 450 failed 16:31
a bunch of single tests fail in t/spec/S03-operators/precedence.rakudo.moar (1 fail) t/spec/S09-hashes/objecthash.rakudo.moar (2 failed) t/spec/S15-nfg/emoji-test.t (20 failed)... 16:32
a whole lot of TODO tests that passed
[Coke] This may be related to the recent Unicode 15 update. 16:33
sjn ok, is this something that came in before 2022.12?
[Coke] I see thundergnat updated the concat test in January this year for that.
looks like concat is a generated file, and was regen'd for 15. 16:34
sjn I'm re-running the spectest on the main branch now, and it's looking much better 16:35
16:37 ab5tract left
[Coke] looks like U15 support was added in January, so yes, after. Guessing we need to reconsider which version of Unicode the spec tests are based on, and maybe have multiple versions to support the various versions available during that language version. 16:37
github.com/Raku/problem-solving/is...1434893483 - sjn, added this to the ongoing thread about spec tests. 16:39
sjn I would be happy with a visible warning that shows if the checked-out code is older than the spectests, and that failed tests should be expected
16:41 thundergnat joined
thundergnat I had some reservations about pushing the U15 generated test to Roast just for this reason. This is one of the primary drivers I had for asking for a Unicode.version parameter we could check. In the future it may be beneficial to move Unicode specific test to a Version sub-folder and only test the supported version. 16:43
Without the version parameter it would be extremely difficult. 16:44
[Coke] Right, I think we can say "everything before Rakudo version X will have issues on Unicode spec tests" 16:45
and only support multiple versions of Unicode starting with 15. (when we upgrade to 16, everything should work.)
[Coke] finds it weird that we have docs/release_guide.pod and docs/release-guide-binary.md 16:50
16:52 thundergnat left 16:53 ab5tract joined
Geth rakudo/main: 268da12b39 | Coke++ | docs/roast.md
Warn about Unicode versioning issue
 16:56
[Coke] ^^ That seemed like a reasonable bit of text to hang in that spot. 16:57
ab5tract [Coke]++ 17:26
17:37 codesections joined, MasterDuke left 18:00 reportable6 left
nine ab5tract: I don't even know what :Letter[0,0,612,792] should do :D 18:00
18:01 reportable6 joined
ab5tract nine: I was surprised to see it as well 18:08
apparently its a shortcut to :Letter([...])
I'd just as soon remove it 18:09
but the pair part works fine
nine I don't know what that does either :D
Oh, wait a minut....you mean just a quote pair? like :foo<bar> 18:10
Then that shouldn't be too hard
ab5tract yeah, I was wondering how difficult the general solution for <<>> quotes (quotewords?) would be to implement 18:12
to be clear, right now ':Letter[0,0,612,792]' parses perfectly fine in RakuAST. It's '<<:Letter[0,0,612,792]>>' that doesn't 18:15
nine Aah, yes the full double quote words thing. Honestly I don't know. Might be ok, might escalate. 18:20
ab5tract Well, afaict the current enum code is on parity with base, minus some external issues such as the above and importing modules 18:21
18:38 sena_kun joined
jdv uh, how is the git log like 1200 lines this time around? wowzers! 18:47
nine jdv: that's from the rakuast branch :) I prefixed most of my commit messages with RakuAST: so you can easily filter out those 18:49
18:50 MasterDuke joined
jdv even filtering that out its still 700 or so as i see it:( 18:51
release'll have to wait i guess. i'll shoot for wednesday then. 18:54
lizmat jdv: any commit before the 2022.12 release can be assumed to be RakuAST and should be listed as a single item, I think 18:56
I mean, all of them together as a single item: "Development of RakuAST" 18:57
nine jdv: git log 3rdparty/ docs/ lib src/core.[de] src/core.c/*.pm6 src/core.c/Array src/core.c/Encoding/ src/core.c/Hash src/core.c/IO src/core.c/Lock src/core.c/Metamodel/ src/core.c/Proc src/core.c/Rakudo src/*.nqp src/Perl6/ src/vm/ t tools 19:04
jdv lizmat: yup, sounds good 19:17
nine: thanks
19:44 notna joined 19:50 notna1 joined 19:55 notna left, notna1 is now known as notna 20:12 NemokoschKiwi joined, NemokoschKiwi left
ab5tract another unrelated blocker for S12-enum/bsaic.t 20:42
*basic.t
BEGIN 'a'..'c' Z=> 1..2 ---> const_iX NYI
21:19 notna left 21:22 melezhik joined 21:25 melezhik left 21:44 codesections left 22:14 melezhik joined
ab5tract nine: somehow slips don't DWIM in IMPL-BEGIN-TIME-EVALUATe 22:17
(|<A B>) evaluates to an empty list 22:18
or, at least, an apparently empty list
22:19 melezhik left 22:42 ab5tract left 22:57 sena_kun 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!