🦋 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:01 reportable6 joined 00:23 epony left 00:49 epony joined 01:22 rypervenche joined 01:53 MasterDuke joined
tonyo patrickb: registered 02:38
06:00 reportable6 left 06:03 reportable6 joined
Geth nqp/main: 510e0508c5 | (Christian Bartolomäus)++ | t/nqp/063-slurp.t
Mark t/nqp/063-slurp.t as self-referential

Also, there is no need to accept two numbers as the number of chars anymore. With 0412c22303 the JVM backend learned to count a CRLF as one char as well. So even if the test file would be written with CRLF as line endings, nqp::chars should give back the same number as for LF as line endings.
This should fix github.com/Raku/nqp/issues/512.		 06:55
nqp/main: 4250c96550 | niner++ (committed using GitHub Web editor) | t/nqp/063-slurp.t
Merge pull request #799 from usev6/gh_512

Mark t/nqp/063-slurp.t as self-referential
09:08 ab5tract joined 09:30 sena_kun joined
ab5tract I think I've found an (the?) issue with the WhateverCodes not evaluating for subsets 10:14
Could it be related to 'TODO implement other thunk types' in IMPL-THUNK-ARGUMENT?
Specifically what I'm investigating is why a bind to lexical '$whatevercode_arg1' is missing from the QAST in the rakuast branch 10:16
AFAICT it should both have a 'QAST::Var(lexical $whatevercode_arg1)' as well as a bind to the local decont var .. both are missing 10:17
lizmat that feels to me you're on to something 10:39
nine Running code at BEGIN time is just an endless source of joy. So any code run at BEGIN time wants access to the lexical environment it was defined in, e.g. `my $foo; BEGIN $foo = "foo";` But at the time that BEGIN statement runs, the frame that the $foo lexical is defined in does not yet exist. 11:11
The old frontend solved this by creating a wrapper frame containing all lexicals that should be visible from the code. This includes all symbols of the setting, so these frames were huge!
In the RakuAST frontend we replaced that wrapper frame with a new mechanism that allowed for a call back from the runtime to the compiler, so it could resolve such symbols on demand. This is already working. 11:12
ab5tract hmmm
nine Now one problem still persists, and I think it's something that wasn't even solved conciously in the old frontend but was just a side effect of having that wrapper frame:
When we compile a code block dynamically, this block may contains nested blocks. E.g. a role body (which is also a code block, run at compile time when the role gets composed into a class) will contain methods. 11:13
We replace the $!do attributes of such nested code objects which at that time still point to stubs with the actual compilation result, e.g. the bytecode frames. But these frames have a lexical environment which in the old frontend was the wrapper frame. But in the new frontend that wrapper doesn't exist. 11:14
Instead their outer frame will still be the comp unit we generated and this comp unit contains the callback to run on missing lexicals. 11:15
ab5tract Just to clarify, do you think this relates to my current issue? 11:23
nine no 11:28
ab5tract ok, I didn't see the connection there but just wanted to double check 11:30
That's an interesting quandary
lizmat added a problem solving issue: github.com/Raku/problem-solving/issues/365 11:40
Nemokosch and a pretty well-aimed one, too 11:46
Geth rakudo/main: 34cf82aa16 | (Will Coleda)++ (committed using GitHub Web editor) | 2 files
Add Complex.sign to v6.e
 11:47
Nemokosch > When we currently run a spectest, it is done with the CURRENT state of v6.d, which is not what the next version will be. We should have an easy way to run the spectests for a specific version of Raku perhaps I failed to express myself well but that's almost the same thing I tried to ask like a week ago 11:48
how the spectests relate to language versions
lizmat well, I guess that somehow stuck in my subconscious :-)
and just having worked a lot on RakuAST and stuff... 11:49
Nemokosch wait, is it actually an N:M situation? Version of specification X version used by the compiler
where preferably the Z pairs should work 🙂 11:50
lizmat the problem is that there shouldn't be *any* version specification in the test files in general, I think 11:51
except for the ones that are testing features that have been deprecated / removed in later versions 11:52
Nemokosch okay, I think this is an important exception still - because this implies a certain design of the specification 11:53
lizmat so a file that specifies 6.c implies that it should only work on 6.c
Nemokosch is there a convenient way to say in a test - "pass the whole file if version doesn't match"? 11:54
"match" could be understood broader, even
lizmat nope, which is another issue, I guess
Nemokosch "only run this in c AND d", for example
or "from e onwards"
lizmat well, the spectest.data file is frozen on language version release 11:55
Nemokosch oh, so that's the file JJ mentioned, I suppose
the file that decides what tests are "active" 11:56
lizmat yup 11:59
and some meta-info for the test runner
12:00 reportable6 left 12:02 reportable6 joined
Geth rakudo/lizmat-more-complex: 67de08d7b5 | (Elizabeth Mattijsen)++ | 6 files
Make log and sqrt handle negative values mathematically correct

  - in 6.e only
  - make sqrt a multi
  - add a new sqrt candidate handling negative values
  - add a new log candidate handling negative values
Note that the use of "is default" in these new candidates is needed to resolve dispatch ambiguities. This is really a stopgap measure for now, hopefully we can dispatch on language version soon!		 12:52
rakudo: lizmat++ created pull request #5192:
Make log and sqrt handle negative values mathematically correct
lizmat Funny thing on the way to the forum: 13:07
the TEMP phaser is *not* documented, but has TODOd tests
it's basically just a stub in the grammar with no action associated with it 13:08
the COMPOSE phaser *is* documented as NYI, but doesn't have tests
yet the code that supposedly needs to tell you that it is NYI, doesn't fire
m: COMPOSE say "foo" 13:09
camelia ( no output )
lizmat m: role A { COMPOSE say "foo" }; A.new
camelia ( no output )
Geth rakudo/lizmat-lose-compose: daaa304dc5 | (Elizabeth Mattijsen)++ | 3 files
Eradicate knowledge of COMPOSE phaser

There were some speculations, and an attempt at creating a stub that was supposedly create a NYI error, but didn't. Meanwhile, the mainline of a role is run every time it gets composed into a (new) class, so effectively we already *have* an implicit COMPOSE phaser. So there's no need for a COMPOSE phaser, it appears.		 13:29
rakudo: lizmat++ created pull request #5193:
Eradicate knowledge of COMPOSE phaser		 13:31
lizmat meh, it picked up something it shouldn't have :-(
Geth rakudo/lizmat-lose-compose: fe90d50b2e | (Elizabeth Mattijsen)++ | 6 files
Revert "Make log and sqrt handle negative values mathematically correct"

This reverts commit 67de08d7b533424dc2b0850895db30a7e28209d8.		 13:32
lizmat afk for a few hours& 13:40
ab5tract lizmat++ # removing a phaser ... my mind was boggling yesterday looking at all the extant phaser options 13:58
so many phasers, and even one that is different based on whether it is in a supply or a loop 13:59
Nemokosch Is it right for the RakuAST variable node to report type "Int" for my Int &foo? 14:58
I'd think it is, just making sure. Perhaps the actual type needs to be handled at container level
ab5tract what are you working on, out of curiousity?
Nemokosch I'd like to see the named call to generate the right defaults, and probably metadata in general 15:01
it's inspired by a persisting tiny issue with the current system that itches me a lot
namely that my Int &foo has the type Callable[Int] but the default value of Callable, hence failing its own type check if you want to reset the value 15:02
now, this is NYI with the new frontend
my Int &foo is simply a Scalar, with an Int type
ab5tract ah, ok. all above my pay grade I'm afraid 15:03
in fact, I feel like I'm losing my mind since I started working in RakuAST ;) 15:04
Nemokosch it might be a lot easier than what you're working with, it's "world-scoped" development mostly
the generated AST itself looks fine, so does the QAST
that's why I want to make sure this assumption is correct, so that I don't go in the wrong direction 15:05
but I'd hope that I'm really close with metamodel stuff
ab5tract Why on earth is it the case that '* ~~ 5' successfully installs a lexical in QAST and binds that lexical to the lowered decont var, whereas 'subset F where * ~~ 5' has no lexical "$whatevercode_arg1" in QAST and is not bound 15:06
what kind of variable node is it? a declaration or a lookup? 15:07
^ Nemokosch
Nemokosch declaration 15:08
I'd think that's where the container is decided
ab5tract hmm, I don't see any special consideration for '&' as a sigil in the var declaration code 15:20
Nemokosch and that's probably the reason it acts exactly like '$' 😄 15:21
ab5tract :) 15:45
nine: sorry to bother you so much, but it really is driving me a bit crazy. Any thoughts on why a bare WhateverCode is getting attached lexically and bound to lowered arg but when neither happens in the case of being wrapped by the logic shared by subset and signature? 15:51
nine Would need to have a closer look for which I don't have the time right now 15:52
ab5tract okay, no worries
16:34 camelia left, nine left 16:35 nine joined 16:38 nine left 16:40 camelia joined, nine joined
ab5tract What's driving me particularly batty is that the lexical definition for '$whatevercode_arg_1' is "QAST::Var(lexical $whatevercode_arg_1 :decl(contvar)) " .. but I can find nowhere in the source where a QAST::Var is created that is both lexical and contvar! 17:08
Outside of VarDeclaration::Implicit::Special, that is
Ah... 17:23
Another place where it is possible is ParameterTarget::Var 17:24
which does not get its IMPL-QAST-DECL called when our whatevercode is in a subset or a signature where clause 17:25
. o O ( I really wish 'caller' would be available in NQP land ) 17:28
17:30 Xliff joined
Xliff Is the QAST generation for RakuAST::Parameter complete? 17:46
patrickb The GSoC application is up. Now we have to wait for feedback from Google whether we are accepted. 17:54
Nemokosch very much appreciated ^^ 17:59
tonyo i don't work in perl or raku (or with people too interested in either), do we have any mentees seeking mentors?
Xliff gist.github.com/Xliff/b228b05633ac...d6502c7a06
18:00 reportable6 left 18:01 reportable6 joined
patrickb tonyo: It's too early. We'll have to wait for the call for students. Here's a timeline: developers.google.com/open-source/gsoc/timeline 18:06
18:09 nine left 18:10 nine joined
ab5tract Xliff: I don't think it can be considered complete if its IMPL-QAST-DECL is not called. But its only this last stage of defining the lexical and binding it to the lowered var that is different between base QAST and RakuAST 18:52
Xliff ab5tract: So do you think this patch will work: gist.github.com/Xliff/b228b05633ac...d6502c7a06 19:10
Which isn't IMPL-QAST-DECL but DEPARSE
Which I need for something else.
19:10 epony left 19:11 epony joined
lizmat Xliff: not sure what you need? 19:13
Xliff I need RakuAST::Parameter to properly .DEPARSE parameter literals. 19:20
Ala « multi sub a("Bee") { say "Cee" } » 19:21
lizmat the code lives in src/core.c/RakuAST/Deparse.pm6 :-) 19:22
Xliff: I could try to fix by example, do you have some examples that don't deparse correctly ? 19:23
nine ab5tract: when I want to know how we got at a certain place in the code I just add an nqp::die('here') with maybe a condition. 19:30
tonyo nine++
nine This weekend, in addition to nqp::bindhllsym('nqp', 'note', &note); I also added this to nqp/src/core/IO.nqp: nqp::bindhllsym('nqp', 'cluck', -> $message { nqp::die('here'); CATCH { nqp::gethllsym('nqp', 'note')($message ~ nqp::join("\n", nqp::backtracestrings($_))) } }); 19:31
With this nqp::gethllsym('nqp', 'cluck')('This is how we got here') prints that message with a backtrace 19:32
Xliff: I wouldn't consider anything complete. I only ever write code for fixing a specific test I'm after. Otherwise I rarely know what the desired behaviour actually is. 19:33
lizmat Xliff: re "sub a("Bee") { }" looks like the deparse is not the issue, it doesn't even parse yet! 19:35
m: Q|sub a("Bee") { }|.AST 19:36
camelia ===SORRY!===
No such method 'compile-time-value' for invocant of type
'RakuAST::QuotedString'
nine sub a(1) { } does
lizmat m: Q|sub a(42i) { }|.AST
camelia ===SORRY!=== Error while compiling
Missing block
------> sub a⏏(42i) { }
lizmat m: Q|sub a(<42i>) { }|.AST 19:37
camelia ===SORRY!=== Error while compiling
Missing block
------> sub a⏏(<42i>) { }
lizmat m: Q|sub a(42e0) { }|.AST
camelia ( no output )
lizmat hmmm
so maybe this is low-hanging fruit :-)
nine I think it is 19:41
ab5tract: that QAST::Var must be from the ParameterTarget::Var
ab5tract nine: Yup, I agree. Just can't seem to figure out why its IMPL-QAST-DECL only gets called for the non-wrapped WhateverCode 19:43
Xliff m: Q|sub a ("bee") { 1 }|.AST 19:52
camelia ===SORRY!===
No such method 'compile-time-value' for invocant of type
'RakuAST::QuotedString'
Xliff That's odd. This was working 2 or so weeks ago when I originally asked this question. 19:53
lizmat Xliff: I'm on it, fixing deparsing now :-) 19:54
Xliff lizmat++ -- Thank you SO MUCH! 19:55
Once this gets in, I can now make Cro handlers from method definitions. 19:57
No more hand coded route blocks!
lizmat whee!
20:01 NemokoschKiwi joined
lizmat fixed deparsing now, working on making a test 20:23
nine ab5tract: I fear I don't understand your problem. Would need more info on what you see exactly in what situation and what you would expect instead 20:25
ab5tract nine: I've boiled it down a bit further. For some reason the ApplyInfix object doesn't have any thunks associated when it has been wrapped 20:27
when it is bare, it has a thunk and we call IMPL-THUNK-CODE-QAST on that thunk
nine What do you mean by wrapped? 20:28
ab5tract this eventually leads to IMPL-QAST-DECL being called on the ParameterTarget::Var
both subset and signatures wrap the expression in a block
effectivaly making it '{(* ~~ 5).ACCEPTS($_).Bool}' 20:31
lizmat Xliff: still working on making a test :-) 20:38
ab5tract nine: here's a gist of the QAST -- gist.github.com/ab5tract/3abeadf95...28c249db02 20:44
nine ab5tract: I wouldn't be surprised if ApplyPostfix' PERFORM_BEGIN's handling of currying were utterly broken. 20:45
It looks like the implementation in PerformInfix before I actually got that right...or at least less broken
ab5tract PerformInfix? 20:48
nine er... ApplyInfix 20:49
m: Q|(*.abs.say)(-5)|.AST 20:50
camelia ( no output )
nine m: use MONKEY-SEE-NO-EVAL; EVAL Q|(*.abs.say)(-5)|.AST
camelia 5
nine m: use MONKEY-SEE-NO-EVAL; EVAL Q|((* + 1).abs.say)(-5)|.AST
camelia No such method 'abs' for invocant of type 'WhateverCode'
in block <unit> at <tmp> line 1
nine Yeah, it only handles the most basic case of applying a postfix (e.g. a method call) to a curried expression. 20:51
Geth rakudo/main: 156fc2cfa1 | (Elizabeth Mattijsen)++ | 4 files
Add support for literal string as a parameter

  - QuotedString needed special handling
  - adapted deparsing for literal values
  - made the RakuAST::Parameter.$!value attribute public
  - added test
Feels to me that the RakuAST::Parameter object is overkill for literal Parameters: I think a Parameter::Literal object that would just have a $!value would also work. Will investigate...		 20:53
lizmat which brings us to: 666 / 1355 !
nine That's how your variable disappears. You wrap the expression in an ApplyPostfix which will then UNCURRY the expression and try to re-curry, but does a really bad job at it
lizmat: we should freeze everything there :D
lizmat m: my $a = 42; sub a("$a: foo") { } # heh, wondered how that would work now :-) 20:57
camelia ===SORRY!===
Cannot find method 'compile_time_value' on object of type QAST::Op
lizmat m: Q|my $a = 42; sub a("$a: foo") { }|.AST 20:58
camelia ===SORRY!===
No such method 'compile-time-value' for invocant of type
'RakuAST::QuotedString'
lizmat m: Q|my $a = 42; sub a("$a: foo") { }|.AST 21:01
camelia ===SORRY!===
No such method 'compile-time-value' for invocant of type
'RakuAST::QuotedString'
lizmat I guess camelia needs some time to catch up
will say: Could not get a literal value of a quoted string as a parameter 21:02
when camelia is up-to-date
21:05 NemokoschKiwi left
ab5tract nine: why does it want to uncurry the expression? 21:05
lizmat afk& 21:07
ab5tract also -- worse news.. I special-cased RakuAST::ApplyInfix in subset's PERFORM-BEGIN wrapping code, delivering it without the ApplyPostfix stuff. 21:08
now the QAST matches the "bare" WhateverCode and yet... it still doesn't work (ie, assigning a subset that doesn't meet the criteria will erroneously succeed) 21:11
21:25 melezhik joined
nine ab5tract: it wants to uncurry because e.g. you want (* + 1).abs.say to compile to {($_ + 1).abs.say}, but we process from inner-most to outer-most, i.e. (* + 1).abs.say becomes ({$_ + 1}).abs.say becomes {($_ + 1).abs}.say becomes {($_ + 1).abs.say} 21:32
Uncurrying the operand and then currying again was my attempt to get this done, but as I discovered later, at least my ApplyInfix implementation was far too simplistic. And now we know that ApplyPostifx' is also. 21:33
21:34 melezhik left
nine So, either you attach ApplyPostifx first, or you only test subsets with code blocks instead of curried expressions 21:34
ab5tract yeah, understood. the special casing for ApplyInfix was to see what would happen. and, depressingly, it fixed QAST to look exactly like that generated by the old frontend AFAICT. And yet, it still doesn't work 21:39
22:07 sena_kun left
Xliff lizmat++ # Looks to be working. Many, many, many thx 22:18
22:18 Xliff left
ab5tract I think I found a corner case where my code does better than the old frontend in handling subsets 23:20
m: subset F where * && 5; say my F $f = True 23:21
camelia Type check failed in assignment to $f; expected F but got Bool (Bool::True)
in block <unit> at <tmp> line 1
ab5tract m: subset F where { $_ && 5 }; say my F $f = True
camelia True
ab5tract Ah, nevermind. It's not fixed on my branch, but it's interesting that this example is broken in the old compiler. 23:22
erm, frontend 23:23
23:35 ab5tract 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!