🦋 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:02 shareable6 left, statisfiable6 left, bloatable6 left, squashable6 left, greppable6 left, tellable6 left, reportable6 left, linkable6 left, coverable6 left, committable6 left, notable6 left, nativecallable6 left, benchable6 left, releasable6 left, bisectable6 left, unicodable6 left, quotable6 left, sourceable6 left, evalable6 left, quotable6 joined, greppable6 joined, reportable6 joined, statisfiable6 joined, benchable6 joined 01:03 evalable6 joined, linkable6 joined, coverable6 joined, bisectable6 joined, squashable6 joined 01:04 notable6 joined, unicodable6 joined, committable6 joined, bloatable6 joined, sourceable6 joined, releasable6 joined 01:05 nativecallable6 joined, tellable6 joined, shareable6 joined 02:05 linkable6 left, squashable6 left, notable6 left, benchable6 left, bloatable6 left, nativecallable6 left, unicodable6 left, greppable6 left, reportable6 left, evalable6 left, statisfiable6 left, tellable6 left, releasable6 left, coverable6 left, committable6 left, sourceable6 left, shareable6 left, quotable6 left, coverable6 joined, quotable6 joined 02:06 linkable6 joined, shareable6 joined, sourceable6 joined, committable6 joined, benchable6 joined, evalable6 joined, squashable6 joined, nativecallable6 joined, tellable6 joined, releasable6 joined 02:07 bloatable6 joined, unicodable6 joined, reportable6 joined, greppable6 joined, notable6 joined 02:08 statisfiable6 joined 04:03 linkable6 left, evalable6 left 04:04 evalable6 joined, linkable6 joined 06:00 reportable6 left 06:02 reportable6 joined 08:58 sena_kun joined
[Tux] Rakudo v2022.12-1-gd52342eb0 (v6.d) on MoarVM 2022.12-29-g256ecc8cd
csv-ip5xs0.800 - 0.961
csv-ip5xs-205.102 - 5.142
csv-parser3.412 - 3.491
csv-test-xs-200.410 - 0.549
test6.503 - 7.395
test-t1.402 - 1.403
test-t --race0.810 - 0.835
test-t-2020.262 - 21.586
test-t-20 --race7.398 - 7.622
 09:51
10:11 ab5tract joined
ab5tract frustratingly, I can't reproduce it via something like 'my $begin := BEGIN (|<A B>, 'C')' 10:14
lizmat ok, I figured out what creates the BUILDPLAN: it's ClassHOW.compose and EnumHOW.compose that call .create_BUILDPLAN 10:16
so I guess the question becomes: 10:17
1. do we consider the creation of the BUILDALL method as part of the Raku language parsing 10:18
2. or do we consider it part of composing a class in the metamodel ?
nine I'm leaning towards the latter since then we can have it for classes created through the MOP as well 10:19
lizmat in case of 1. we can build the code of the BUILDALL method in RakuAST
in case of 2. then it should be done in QAST
nine Why should it be done in QAST?
lizmat and we should rip that code from World into some place
because the metamodel gets QAST for the BUILD and TWEAK methods 10:20
nine Gets QAST from whom? 10:21
ab5tract nine, lizmat: you are indeed excellent rubber ducks! my issue was that I needed to match against the List from the setting
lizmat sorry, indeed, not QAST, but a Method object, something you can feed an 'nqp::callmethod" op, but which you cannot deparse 10:22
nine So, perfectly doable 10:24
lizmat perhaps, but I'm not seeing it 10:25
nine Nothing prevents you from creating an AST, compiling it and getting at the meta object of that method. That's apparently exactly what the meta model needs. 10:29
The only more interesting thing the CompilerServices have to do is, if this thing happens as part of an ongoing compilation, the resulting QAST needs to be added to that comp unit, so the generated method will be available when the comp unit gets loaded. 10:31
10:32 frost joined
lizmat I still don't see how that could work with the TWEAK and BUILD methods, without changing the semantics of the BUILDPLAN 10:40
nine What's the problem there?
lizmat the BUILDPLAN contains a Method object, not a RakuAST::Method object 10:42
nine Yes, a Method object. Which is exactly what $your-rakuast-method.meta-object returns 10:45
lizmat indeed, but how do you get back to the RakuAST::Method object from there ? 10:53
nine Why would you have to? 10:54
lizmat because you'd want to be able to deparse ?
nine Where? What for? 10:55
lizmat $file.IO.slurp.AST.DEPARSE 10:56
nine What does that have to do with BUILDALL?
lizmat hmmmmm 10:59
ok, suppose we build the BUILDALL and accessor methods using RakuAST and attach it to tree 11:01
then a deparse would not know the difference between what is generated and what is actual code
that was written by the author
nine Then add a flag marking it as auto-generated
lizmat hmmmm 11:02
lemme mull on that
ab5tract okay, so I've gotten pretty far rubber ducking but I think I need a pointer on how to convert a settings-level list into something iterable in NQP 11:10
nine .FLATTENABLE_LIST 11:11
ab5tract thanks!
Geth rakudo/main: 5 commits pushed by (Stefan Seifert)++ 11:19
nine 694 spectest files passing!
ab5tract nice one! 11:25
12:00 reportable6 left, reportable6 joined
ab5tract another kind of weird corner of enum: 12:04
m: class W::Foo {}; enum W<Foo>; dd W::Foo.new; dd +W::Foo
camelia W::Foo.new
Use of uninitialized value of type W::Foo in numeric context
in block <unit> at <tmp> line 1
0
ab5tract so it works but it also kind of doesn't work ("Use of uninitialized value") 12:05
In my branch I die with a redeclaration error message
nine Arguably your's is more correct 12:06
ab5tract I'd argue that, for sure :)
We can address it later if it comes up in the spectests 12:07
One thing I'm having trouble with right now is that in base, we look at the lexicals in the current lexpad and then bind a failure when there is a redeclaration by another enum. 12:09
m: enum F1<a b c>; enum F2<b c d>; dd b; dd +F2::b 12:10
camelia Potential difficulties:
Redeclaration of symbol 'b and c'.
at <tmp>:1
------> enum F1<a b c>; enum F2<b c d>⏏; dd b; dd +F2::b
Failure.new(exception => X::PoisonedAlias.new(alias => "b", package-type => "enum", package-nam…
ab5tract m: enum F1<a b c>; enum F2<b c d>; dd +F2::b; dd b;
camelia Potential difficulties:
Redeclaration of symbol 'b and c'.
at <tmp>:1
------> enum F1<a b c>; enum F2<b c d>⏏; dd +F2::b; dd b;
0
Failure.new(exception => X::PoisonedAlias.new(alias => "b", package-type => "enum", packag…
ab5tract I'm not really a fan of this, but it is definitely tested in roast. I'm not clear on how to go about actually coding this up. 12:12
This is the only deviation from base that I am currently aware of, btw :D 12:13
*only other
nine m: my $a = 1; my $a = 2; 12:15
camelia Potential difficulties:
Redeclaration of symbol '$a'.
at <tmp>:1
------> my $a = 1; my $a⏏ = 2;
nine Seems to be a general mechanism that I will need
ab5tract Is it good enough to leave this as a documented TODO item?
Or are you going to sink your teeth into it directly? :) 12:16
nine I'm pretty busy right now 12:17
ab5tract no worries, just trying to understand whether this deviation should be a blocker for submitting the PR for review 12:18
nine Definitely not 12:20
Everything that advances the state without regressions is eligible for merging
ab5tract excellent :D 12:21
lizmat has 695 / 1356 12:40
nine: perhaps your roast is outdated ? 12:41
12:46 discord-raku-bot left, discord-raku-bot joined
nine Indeed, it was missing the new subset tests 12:52
lizmat ok, *phew* :-) 12:53
nine: the BUILDPLAN is not the same yet for class A { has $.a = 42 } 12:54
1: nqp::getattr(obj,A,'$!a') = 42 if not set # base
1: nqp::getattr(obj,A,'$!a') = execute-code() if not set # RakuAST
nine see commit message 12:59
lizmat gotcha 13:01
"whether an expression's result is known at compile time" don't we have that in other situations already ? 13:03
nine I didn't find anything on that 13:05
lizmat hmm is it intentional that it gets codegenned as a method ? 13:08
(400, A, "\$!a", method (Mu: $_, *%_)
nine That's what the old frontend does
ab5tract needs to be a method to access $!a, right? 13:09
lizmat heh, indeed it does... hmmm 13:10
nine ab5tract: right 13:12
ab5tract okay, so for some reason I'm only seeing 694 passing tests on current main, even with the updated roast... weird 13:14
but that also implies my branch fixes a whole 4 spectests :D
13:46 evalable6 left 13:47 evalable6 joined
ab5tract what does the '::' in `enum :: <a b c>` actually indicate? 14:04
is that technically a psuedo-stash-y thing? 14:05
lizmat to create an anonymous enum? 14:07
similar to an anonymous class ?
ab5tract yeah, just curious about it in terms of what it means as a name
I'm currently having a guard that says "don't install package if $!name is anonymous" 14:09
lizmat m: enum :: <a b c>; say a, b c
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> enum :: <a b c>; say a, b⏏ c
expecting any of:
infix
infix stopper
postfix
statement end
statem…
lizmat m: enum :: <a b c>; say a, b, c
camelia abc
lizmat m: enum :: <a b c>; dd a, b, c
camelia ::a
::b
::c
ab5tract yup, also works as:
lizmat m: enum :: <a b c>; say +a, +b, +c
camelia 012
ab5tract m: enum <a b c>; say +a, +b, +c
camelia 012
ab5tract I need a guard that catches both those cases 14:10
and $!name.canonicalize eq '::' feels icky
so I was wondering if the name class should get an 'is-anonymous' that hides the icky-ness or otherwise does a different check 14:11
lizmat it would be nice if deparsing could know the difference between "enum <a b c>" and "enum :: <a b c>" but only a little bit nice though 14:13
ab5tract I think it will 14:17
Since in one case $!name is '' and the other it is '::"
but I'm nothing near a deparse expert :)
lizmat heh :-) 14:37
ab5tract actually, I think not... <longname> already returns a RakuAST::Name.from-identifier('') for '::' 14:39
14:47 linkable6 left, evalable6 left, linkable6 joined 14:48 evalable6 joined
ab5tract okay, *phew*, 695 in main for me now 14:56
lizmat good! 15:00
consistency is good :-)
ab5tract nothing worse than a flapping test!
nine So just 5 more tests to 700... 15:20
lizmat always 'nother milestone :-) 15:21
ab5tract my branch is at 698 :) 15:32
With two more passing as soon as roles and the 'const_iX NYI' at begin time are resolved 15:33
nine That one I dread a bit... 15:35
ab5tract ah, it's on your radar, eh? 15:38
nine I haven't looked at it yet, but that const_iX NYI in general is the result of broken bytecode. The const ops are the ones with the lowest indexes, so when bytecode contains small integers or we wrongly jump into a memory region containing them, you'll see that message. 15:42
ab5tract :( 15:43
yeah, that sounds tough
I wonder how many tests it might unlock though.
nine Oh, it happens in the fallback resolver 15:46
ab5tract nine, lizmat: My PR is ready for review 16:01
sorry! spoke to soon! 16:04
Let me get rid of the nonsense changes to literals.rakumod 16:05
I hate how Comma does that
nine getlexstatic_o doesn't play well with the fallback resolver
lizmat ab5tract: in Subset I removed the $!current-package entry in visit-children
ab5tract Okay, will do that too
wasn't sure if it was something to keep documented or not
lizmat because there is no need to visit something that is an implementation detail
nine what?!
lizmat well, maybe I was wrong, maybe nine should 16:06
I guess nine did :-)
nine Without visit-children there is no resolution, no BEGIN handling, no nothing
ab5tract nine: but you can't visit $!current-package when that package is GLOBALish
I could put a check to that effect there 16:07
nine Please, read RakuAST::Node::IMPL-CHECK before making any more assumptions about what it does
lizmat nine: I did not remove "visit-children" 16:08
nine ab5tract: Wait, is the current-package you talk about a RakuAST::Node or a Package? In the first case it has to be visited, in the latter it must not (and doing it anyway will explode)
lizmat right, that was my point :-)
afaik it's a Package 16:09
ab5tract nine: I thought GLOBALish was somewhat special here? Doesn't current-package return a RakuAST::Package? 16:10
nope, that's a dumbo on my part 16:11
its clearly there in the docs
nine Ok, got a fix for getlexstatic_o. Now need to translate that to assembly 16:21
ab5tract nine: :O 16:25
nine A partly fix got pused to MoarVM 16:46
ab5tract amazing 16:47
lizmat nine: shall I bump MoarVM?
nine I don't think that's necessary. The fix is only important for RakuAST 16:48
lizmat yeah, and we wants it ?
but guess, with an impending release, it's better to wait? 16:49
hmmm... but then it would be in the MoarVM release anyways
nine assumes all RakuAST developers are on MoarVM master anyway 16:52
lizmat nine assumes incorrectly 16:53
nine That's a bit of a surprise. If not us who would be? 16:54
lizmat well, I'm always in a --gen-moar environment, on purpose
ab5tract me too, but not so purposefully :)
okay, so I've triple checked my PR. 17:05
it's ready whenever the tuits are there 17:07
it was fun to implement this without nearly as many questions needing to be asked :)
lizmat shouldn't this be a loop? $visitor($!term); 17:16
OOC: why the: 17:17
my $iter := nqp::iterator(%values);
while $iter {
and not:
for %values -> $pair 17:18
??
ab5tract lizmat: There's only ever one term 17:25
lizmat: regarding %values -> $pair, I guess I thought I couldn't do that :) 17:26
%values -> $pair pushed 17:52
18:00 reportable6 left 18:01 reportable6 joined 18:25 Geth left, Geth joined
shmup link to PR please 21:58
22:00 frost left 22:05 guifa joined 22:08 guifa_ left 22:32 sena_kun left
ab5tract shmup: github.com/rakudo/rakudo/pull/5207 23:42

Powered by Cro and the Raku® Programming Language.

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

Thank you!