🦋 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:03 reportable6 joined 00:13 sena_kun left 05:22 eponym joined 05:23 epony left, eponym left 06:00 reportable6 left 06:02 reportable6 joined
nine ab5tract: ok, will review on the plane :) May be until tomorrow that I have Wifi again and can approve though 06:54
tellable6 nine, I'll pass your message to ab5tract
09:40 linkable6 left, coverable6 left, tellable6 left, releasable6 left, committable6 left, reportable6 left, notable6 left, evalable6 left, nativecallable6 left, bloatable6 left, bisectable6 left, statisfiable6 left, greppable6 left, benchable6 left, unicodable6 left, quotable6 left, squashable6 left, shareable6 left, sourceable6 left, committable6 joined 09:41 bisectable6 joined, benchable6 joined, bloatable6 joined, nativecallable6 joined, greppable6 joined, unicodable6 joined, tellable6 joined, evalable6 joined, sourceable6 joined, quotable6 joined, notable6 joined 09:42 releasable6 joined, shareable6 joined, coverable6 joined, linkable6 joined, reportable6 joined 09:43 squashable6 joined, statisfiable6 joined 10:04 ab5tract joined 10:08 sena_kun joined 11:01 sena_kun left 11:02 sena_kun joined
ab5tract hmmm.. wondering where in roast my subset tests should land.. 11:42
tellable6 2023-02-12T06:54:29Z #raku-dev <nine> ab5tract: ok, will review on the plane :) May be until tomorrow that I have Wifi again and can approve though
lizmat there's a t/spec/S12-subset/ directory 11:44
ab5tract lizmat: bizarre that my branch doesn't budge the total spectest numbers 11:47
we are at 672, right?
lizmat yes
probably something else blocking.... are the ones in t/spec/S12-subset passing ?
ab5tract yes, for sure 11:49
but they shouldn't have been passing before
as subset wasn't even in the grammar yet 11:50
lizmat maybe they're not tested at all? aka not in t/spec/spectest.data ?
ab5tract didn't know about this, let me check
hmm, they are there. along with several other tests with subset in the name 11:52
let me investigate a bit
one major bummer is that Comma tries to index spec and then barfs to death
and there is no exclusion mechanism that I've been able to find. anyway, thats a tertiary dilemma 11:53
okay, nevermind, those tests are not passing with my branch. I'll have to take a look as to why, when my own test cases are all working and seem to do similar stuff 11:55
thanks for pointing this out lizmat++
lizmat ok, so I should hold off still on merging your branch ? 11:57
12:00 reportable6 left, reportable6 joined
ab5tract I don't know.. it certainly doesn't cause any regressions 12:02
but I guess it would be good to get this right
lizmat ok, I'll hold off for a bit then :-) 12:03
ab5tract sounds like a plan 12:05
frustrating... I didn't even consider the case where there is no where clause
lizmat heh :-) 12:06
ab5tract of course we support it, even though it doesn't really make any sense at all
because: torture the implementors, right? :)
lizmat I guess it's basically the same as aliasing, right?
ab5tract yeah, I guess it is 12:07
lizmat am currently looking at this very helpful message: 12:14
===SORRY!===
Something went wrong in (NotFound)
12:16 frost61 joined 12:20 frost61 left
lizmat hhmmm.. looks like the resolver method of my new VarDeclaration::Constant class is being called 7 times with the same resolver 12:32
wonder what is going on there...
for something as simple as: my constant $x = 42
ab5tract lizmat: I've seen that one before! 12:37
how I fixed it escapes me at the moment
(the SORRY)
what does "#OK not used" mean in terms of roast? does it ignore these tests? 12:38
lizmat I have *no* idea 12:39
ab5tract :) 12:50
12:52 Geth left, Geth joined
Geth rakudo/main: eff0244080 | (Elizabeth Mattijsen)++ | src/core.c/Exception.pm6
Make X::Method::NotFound more resilient

Instead of conking out without any useful information if the
  !create-message method dies.		 12:53
lizmat hmmm.. looks like Geth was on channel, but wasn't accepted any webhook pushes :-(
Geth rakudo/main: 9e4fa28635 | (Vadim Belman)++ | src/core.c/Version.pm6
Fix serialization issues with Version

Attempt to declare a class starting with `Version::` was causing 'Object does not exist in serialization context' error. Turning class declaration into a lexical (`my` was missing) and making pre-declared constants lexicals fix the problem.		 12:54
rakudo/main: bc9bd9bf32 | (Vadim Belman)++ (committed using GitHub Web editor) | src/core.c/Version.pm6
Merge pull request #5204 from vrurg/fix-version-class-serialization

Fix serialization issues with Version
lizmat re-delivering some events now 12:55
Geth rakudo/main: e09f20ca27 | (Vadim Belman)++ | src/Perl6/Actions.nqp
Fix error reporting for feeds

When LHS is a typeobject it is codegenned into a `QAST::WVal` which cannot be used as a positional.		 12:56
rakudo/main: dfcd57778f | (Vadim Belman)++ (committed using GitHub Web editor) | src/Perl6/Actions.nqp
Merge pull request #5203 from vrurg/fix-feed-error-gen

Fix error reporting for feeds
lizmat ok, it looks like that where all the commits that were missed 12:59
ab5tract: so no I get a much more informative:
===SORRY!===
Method RakuAST::VarDeclaration::Constant.IMPL-TO-QAST not found
ab5tract that's weird, it should inherit that from elsewhere 13:01
lizmat yeah... anyways.. :-)
ab5tract I think that should be the same as IMPL-QAST-DECL in this case, right? 13:04
lizmat at this moment, I'm not sure 13:12
meh, looks like the declaration is not codegenned in the case of "our" 13:14
Geth rakudo/watermarky-supply-zip: fb657a4a17 | (Jonathan Worthington)++ | src/core.c/Supply-coercers.pm6
Correct termination predicate

Input supplies may have got many values ahead of the watermark before it is set.		 13:33
ab5tract two more spectests now passing with my branch! 13:50
lizmat whee!
Geth rakudo/main: 4 commits pushed by (Stefan Seifert)++ 14:04
nine 679 passing, so now we really have more than the first half : 14:05
lizmat nine: any ideas as to why an IMPL-QAST-DECL is not being called for an "our" scoped thing?
ab5tract nine++
lizmat nine++ indeed!
nine What kind of thing? 14:06
lizmat RakuAST::VarDeclaration::Constant 14:08
gist.github.com/lizmat/ec4dc6ebda0...ca2ad2383b # work so far 14:10
ab5tract nine: I'm pretty confident in my branch at this time. needed to add support for subsets without where clauses, but those are working now. 14:11
nine Is that a RakuAST::Declaration?
lizmat yes
14:13 epony joined
lizmat hmmm.. I wonder if it is the "is-lexical' check in there that needs an additional "our" ? 14:14
nine lizmat: if it's our scoped than it's not is-simple-lexical-declaration and needs to take care of declaring that lexical explicitly 14:15
lizmat why? the only thing an "our" variable is different from a my, is that it is bound to a key in the $?PACKAGE.HOW ? 14:16
nine by default that is
lizmat and that can be taken care of in the declaration ? 14:17
nine Sure, just have is-simple-lexical-declaration return True
ab5tract: looks like that method is still called IMPL-INSTALL-INTO-PACKAGE in the version of the commit on Github 14:24
ab5tract I didn't see a message from you about wanting to change that, sorry. 14:28
What would you prefer?
IMPL-INSTALL-PACKAGES?
nine the old name 14:29
github.com/rakudo/rakudo/pull/5178...b8ff9493e8
ab5tract ok
lizmat m: our constant $x = 42; { our constant $x = 666; say $x }; say $x; say OUR::<$x> # looks like base installs "our constants" as "my constants" 14:30
camelia 666
42
666
ab5tract ah, I see the issue now, we are using two different feedback channel
lizmat I wonder whether this should be caught or not, or that installing the constants as a lexical is enough
nine looks buggy to me 14:34
lizmat yeah, you'd expect the inner "our constant $x" to be a compile time error, right ? 14:35
nine yes
lizmat: you're still working on BUILDPLAN?
lizmat well, I want to, but last time I checked, the BUILDPLAN wasn't set up correctly 14:36
so that doesn't give me a steady foundation to work with :-)
m: class A { has $.a = 42 }; use BUILDPLAN A 14:37
camelia class A BUILDPLAN:
0: nqp::getattr(obj,A,'$!a') = :$a if possible
1: nqp::getattr(obj,A,'$!a') = 42 if not set
lizmat in RauAST I get " 1: vivify nqp::getattr(obj,A,'$!a') if part of a mixin" for the 2nd element
which is a fallback for "nothing else happened to this attribute, make sure it exists" 14:38
if I remember correctly
nine For me the BUILDPLAN module doesn't even compile 14:39
lizmat ? 14:41
it's installed with the core ?
ab5tract nine: naming issue is resolved
nine lizmat: with RAKUAST
lizmat why would it need RAKUAST ? 14:42
did we change the buildplan in RakuAST ?
nine ab5tract: can't merge that PR because it's still marked as a draft 14:44
nine@sunshine:~/rakudo (main *=)> RAKUDO_RAKUAST=1 ./rakudo-m -Ilib -e 'class Foo { has $!foo = "foo" }; use BUILDPLAN Foo'
===SORRY!=== Error while compiling
Your !! was gobbled by the expression in the middle; please parenthesize
at line 181
------> note BUILDPLAN(nqp::isconcrete($_) ⏏?? ::($_) !! $_) 14:45
lizmat you don't need the -Ilib
it's installed with the core
nine nine@sunshine:~/rakudo (main *=)> RAKUDO_RAKUAST=1 ./rakudo-m -e 'class Foo { has $!foo = "foo" }; use BUILDPLAN Foo'
===SORRY!===
Could not find BUILDPLAN in:
nine@sunshine:~/rakudo (main *=)> RAKUDO_RAKUAST=1 ./rakudo-m -e 'class Foo { has $!foo = "foo" }; use BUILDPLAN Foo'
===SORRY!===
Could not find BUILDPLAN in:
lizmat did you run "make install" ?
nine No, why would I? 14:46
lizmat well, to get things like "use Test" and "use BUILDPLAN" to work ?
nine Test has worked fine with RAKUAST for half a year
lizmat ok, I'll look into getting BUILDPLAN to work with RakuAST 14:47
nine Yaks on top of yaks...
ab5tract nine: I don't think I have control over the draft mark
lizmat not a draft anymore, shall I merge ? 14:48
not as a squash, right? 14:49
ab5tract nope, this time the commit history is sensible
Geth rakudo/main: 8 commits pushed by ab5tract++, (Elizabeth Mattijsen)++
ab5tract \o/ 14:50
lizmat ab5tract++ nine++ will work on tests and deparsing :-)
ab5tract lizmat++ thank you so much
TIL that we also support subsets on individual variables, or something. not even sure what to call it 14:51
m: my ($ where 2) = 3
camelia Type check failed in assignment to anon; expected <anon> but got Int (3)
in block <unit> at <tmp> line 1
nine ab5tract: congratulations!
ab5tract sometimes I wonder if YAGNI was a principle that was ignored a bit too much in Raku development ;) 14:53
nine: Thanks! and thank you for all the pertinent advice along the way
lizmat nine: so the BUILDPLAN diff is:
- note BUILDPLAN(nqp::isconcrete($_) ?? ::($_) !! $_)
+ note BUILDPLAN(nqp::isconcrete($_) ?? (::($_)) !! $_)
are we sure this isn't a RakuAST regression ?
nine it definitely is 14:54
lizmat so, shouldn't we fix that instead of fixing BUILDPLAN ?
nine Of course? 14:55
lizmat counts 681 / 1355
Geth rakudo/main: 28771d746a | (Elizabeth Mattijsen)++ | lib/BUILDPLAN.rakumod
Make sure a RakuAST regression doesn't bother us

The code in BUILDPLAN *was* correct, but we need BUILDPLAN to work in RakuAST before we can look it this again.		 14:56
nine Err...what's the point of this ^^^? 14:57
lizmat it allows us to move on with getting a correct BUILDPLAN for classes ?
I assumed that'd be more important atm ? 14:58
nine I don't think there is a "more important" as we'll have to support _everything_. That's why I implemented some of the most obscure issues already while we on't even support enums yet
Adding workarounds hides issues that may not be covered by any spectest. Like in this case it is a bit of an obscure construct 14:59
lizmat well, you seem: 1. not to want to do a "make install", and 2. want progress on BUILDPLAN 15:00
nine I was just asking :) Don't want to duplicate effort 15:01
And my next flight gets closer, so I'll be out of comms for a while
ab5tract safe travels nine
lizmat last week I left a message here about what I thought was wrong with making the BUILDPLAN 15:02
lemme see
nine ab5tract: do you want to tackle enum next? Might be touching similar points as subset did
ab5tract nine: yeah, sounds interesting. there is still work to be done with getting 't/spec/S12-subset/subtypes.t' to work but a) it's not a subset related compilation error at the moment and b) I'm a bit burnt out on the word subset atm 15:04
nine haha, I know how that is 15:07
lizmat: want me to dive into that has $!foo = "foo" thing?
Sounds like that could keep me busy for a few hours :D 15:08
lizmat yes, please
I looked into it, and said it on channel I think
ab5tract enum is anothe RakuAST::Type, correct?
lizmat basically it was some order thing where code that would add the BUILDPLAN entry was in the wrong branch of an if / else 15:09
nine ack -i buildplan src/Raku/ast doesn't find anything 15:10
lizmat it's not called BUILDPLAN there
BUILDPLAN is basically run of the info in the Attribute objects 15:11
*off 15:12
nine Ah yes, there's your comment on BUILDALL in IMPL-COMPOSE
lizmat and the Attributes were not set up correctly ?
anyways, safe flying! 15:13
nine Ok, so I'll dig into this
lizmat great! 15:14
nine Oh, I may have implemented indirect lookups in the wrong place. That nqp::isconcrete($_) ?? ::($_) !! $_ shows that ::($_) shouldn't actually parse as a call, but just as a name 15:20
lizmat ab5tract: are there anonymous subsets? if not, I guess :$name! in .new ? 15:21
ab5tract lizmat: good call. From what I can tell, you cannot not supply a name when using 'subset' 15:28
lizmat yeah, that's what I figured :-) 15:29
ab5tract but again, I present you with:
m: my ($a where /a/) = b
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared routine:
b used at line 1
ab5tract m: my ($a where /a/) = <b>
camelia Type check failed in assignment to $a; expected <anon> but got Str ("b")
in block <unit> at <tmp> line 1
lizmat hmmm.. that currently doesn't fail on RakuAST ? 15:30
ab5tract nope 15:31
and this dies with a special error of its own
m: my ($ where .so) = False
camelia Type check failed in assignment to anon; expected <anon> but got Bool (Bool::False)
in block <unit> at <tmp> line 1
lizmat m: my ($ where !.so) = False 15:32
camelia ( no output )
lizmat feels about right ?
ab5tract Luckily those aren't RakuAST::Type::Subsets, so I don't need to worry about them
lizmat No such method 'IMPL-LOOKUP-QAST' for invocant of type
'RakuAST::ParameterTarget'
ab5tract exactly 15:33
lizmat intriguing :-)
ab5tract *don't need to worry about them atm
lizmat probably should just check whether there is a name, and only run the lookup if there is one ?\
ab5tract lizmat: ah, but that doesn't interact with my code at all because the grammar isn't parsing 'subset' 15:34
lizmat but it should, is what you're saying
ab5tract this is about a where clause not getting added as a post constraint somewhere
nope, and sorry if I'm being confusing. 15:35
lizmat ack :-)
Geth rakudo/main: 30b398b1cb | (Elizabeth Mattijsen)++ | src/Raku/ast/type.rakumod
Tweaks on RakuAST::Type::Subset

1. make :$name parameter mandatory 2. lose setting the default scope, would interfere with deparsing		 15:38
15:41 Geth left, Geth joined
ab5tract hmmm... 15:43
enum does a bunch of documentation-related stuff
15:45 Geth left, Geth joined
lizmat hmmm... .of doesn't get set until after begin time :-( 15:56
nine That's done by a trait, isn't it? And traits are usually applied by PERFORM-BEGIN 16:01
lizmat well, that could well be, but that would imply that an RakuAST object would need to have been parsed already before being able to being deparsed 16:02
and I don't think we want that to be a requirement 16:03
I mean, you want to be able to inspect a RakUAST tree *before* you run it through EVAL, no ?
nine Well it would have to be past it's CHECK time. Otherwise the deparse couldn't rely on the AST to actually make sense, could it?
lizmat it has been able to do so so far 16:04
nine If we want to keep that, deparse has to cope with traits not being applied yet 16:05
lizmat but then the deparse would be incorrect
nine Deparse can look at the list of traits in the AST 16:07
lizmat yes, it could 16:08
m: say Q|my %h is Map = a => 42; dd %h|.AST.DEPARSE # seems there's more cases of traits being missed atm 16:12
camelia my %h = a => 42;
dd(%h)
nine I've got a fix for the BUILDPLAN mis-parse 16:17
lizmat great! 16:18
nine Don't think the spectest will finish before I have to board though :D Will push on the other side 16:19
lizmat ok, safe travels! 16:24
ab5tract: I see that $!where in Type::Subset does *not* keep the same value over the lifetime of the object 16:42
where is the resolved "$!where" used ?
ab5tract it's used in the PRODUCE-META-OBJECT 16:44
I originally had one for expr and one for where but it eventually seemed redundant
What I do is roughly similar to what happens in signature.rakumod 16:45
lizmat but... a Block object doesn't have any IMPL-CURRIED method ? only a RakuAST::Block object has ? 16:49
or RakuAST::Expression ?
ah, it *isn't* a Block, it *is* a RakuAST::Block 16:50
ok
ab5tract exactly :)
lizmat ok, going to introduce a $!block attribute for that :-) 16:52
hmmm... wonder if a TopicCall would be moe appropriate 16:53
for the .ACCEPTS
ab5tract you mean for the wrapper expression? 16:54
lizmat ah no, it's $!WHERE.ACCEPTS($_) not the other way around :-)
ab5tract I think it works cleaner with just the single '$!where 16:55
attribute
no abstraction seems to be violated
lizmat yeah, but then the deparse of a Type::Subset object before and after an EVAL would be different 16:56
$!where is public
ab5tract oh, then just make it private! 16:58
:D
though I guess from a politeness standpoint, people who make these on their own may want to introspect...
lizmat: How come it works on the type signature deparsing? 16:59
lizmat not sure... :-) 17:00
working on Type::Subset now... trying to not be distracted :-)
I mean, the RakuAST classes *also* need to have an interface with which macro builders will be able to work 17:03
so ideally, each object should be instantiable with just a .new call and arguments
ab5tract ok then please proceed 17:06
we should probably standardize between named and unnamed argument lists in the classes, though 17:07
so far I've seen a mixture of both
lizmat I think the rule is: if there's only one possible argument, then it doesn't have to be named 17:11
otherwise: just named 17:12
so: RakuAST::IntLiteral.new(42)
ab5tract ah, right 17:14
that matches what I've seen
18:00 reportable6 left
ab5tract hmmm, I don't seem to be able to get past the initial parsing phase. Somehow it's like the regex doesn't even register. 18:02
18:03 reportable6 joined
ab5tract That is to say, I am getting the same answer for any missing keyword: 18:03
Unhandled exception: Cannot look up attributes in a Any type object. Did you forget a '.new'? 18:04
both 'enum F<B>' and 'dsfadfef F<B>' say that same thing 18:06
The grammar shouldn't need any serious tweaking, but even if the token match fails, it shouldn't barf like this, right? 18:09
omg... 18:13
spelling errors in NQP land can be fun! ;D
... but that didn't fix the issue 18:17
18:50 epony left 20:04 NemokoschKiwi joined
Geth rakudo/main: 1f0fe647cd | (Elizabeth Mattijsen)++ | src/Raku/ast/type.rakumod
Fix typo in type specification in signature

Wonder why this didn't blow up		 20:21
rakudo/main: b915dd3a80 | (Elizabeth Mattijsen)++ | 3 files
RakuAST: add deparsing for Type::Subset and some refactoring

  - allow an "of" named argument for programmatical uses
  - pass on RakuAST:: classes in traits rather than Match objects
  - handle traits in .new, checking for any "of" traits
  - remove the $!current-package attribute, it is not needed
  - remove the $!current-package attribute, it is not needed
  - no longer is Attaching, as there is nothing to attach anymore
  - create the meta object at BEGIN time
  - add Type::Subset candidate in RakuAST/Deparse
lizmat ab5tract ^^ now on to creating tests :-)
20:24 Geth left, Geth joined
vrurg youtu.be/sJs6jNroRXU 21:01
notable6: youtu.be/sJs6jNroRXU 21:02
notable6 vrurg, I cannot recognize this command. See wiki for some examples: github.com/Raku/whateverable/wiki/Notable
vrurg Forgot how to use it... 21:03
notable6: weekly youtu.be/sJs6jNroRXU
notable6 vrurg, Noted! (weekly)
vrurg Oh, ok. :)
lizmat nice! 21:15
Geth rakudo/main: 2b6b4019da | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.pm6
Some deparsing tweaks

  - don't show "our" (it's the default) (for now)
  - reformat Lexical::Var that are WhateverCode arguments to *		 21:21
lizmat and that concludes my hacking for today
&
23:11 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!