🦋 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
MasterDuke vrurg: not sure what you mean? we're not supposed to be using both nqp and rakudo on the branch named 'main' yet? 02:56
vrurg MasterDuke: did you always use NQP from the tip of master branch? About the same situation here. 02:57
I'm currently working on better errors for Rakudo and it includes fixed Backtrace.
MasterDuke yeah, i have all three repos checked out separately configured with a common --prefix and i usually keep them all at HEAD 03:17
vrurg Unfortunately, it doesn't guarantee their compatibility, apparently. 03:52
MasterDuke in unrelated news, i have my convert-list-assignment-into-list-of-assignments branch passing a spectest (not counting the current fails related to backtraces) 04:02
it's not pretty. but `my $a; my $b; my $c; ($a, $b) = ($_, $_) for ^1_000_000; say "$a $b";` now takes ~0.25s instead of ~1.6s 04:04
Geth rakudo: MasterDuke17++ created pull request #5128:
Try to convert `($a, $b) = ($c, $d)` into `$a = $c; $b = $d`		 04:10
rakudo: vrurg++ created pull request #5129:
Make use of line directive information for compile time errors		 04:33
vrurg MasterDuke: +++ !!! 04:35
05:33 epony left 06:00 reportable6 left 06:01 reportable6 joined 07:17 epony joined 07:44 sena_kun joined
patrickb ugexe: re rakubrew and mail, 10:40
*main, I suspect it will be a problem. I'll probably manage to look at this in the evening. 10:42
10:46 evalable6 left 10:49 evalable6 joined
lizmat I assume we want RakuAST to be a 6.e thing only, right? and then only with "use experimental :rakuast", right ? 11:39
nine vrurg 11:54
12:00 reportable6 left, reportable6 joined 13:11 |Tux| left
ugexe patrickb++ 13:13
13:19 |Tux| joined, Tux__ joined 13:23 Tux__ left
vrurg lizmat: neither I think this is really possible, nor it makes sense when we switch to it completely. How could be block RakuAST in 6.c if the version going to be implemented in it? 14:12
*could we 14:13
[Coke] (ast 6.e) that seems very reasonable to me. 15:21
(the ask, not the implementation :)
15:25 squashable6 left 15:26 squashable6 joined
vrurg [Coke]: ?? 15:50
What does (ast 6.e) means?
leont <lizmat> I assume we want RakuAST to be a 6.e thing only, right? 15:55
Nemokosch it all boils down to "when we switch to it completely" doesn't it 15:58
16:01 discord-raku-bot left, discord-raku-bot joined 16:42 Kaiepi left
[Coke] vrurg: was referring to lizmat's ask about ast in 6.e 16:44
17:01 Kaiepi joined 17:45 lizmat left 17:47 lizmat joined 18:00 reportable6 left 18:01 reportable6 joined 18:22 sena_kun left 18:23 sena_kun joined 19:20 discord-raku-bot left, discord-raku-bot joined
lizmat notable6: weekly 19:38
notable6 lizmat, 2 notes: 2022-12-05T21:05:10Z <El_Che>: rakudo-pkg releases for 2022.12 + added packages for newly released alpine 3.17 ; 2022-12-07T13:59:44Z <lizmat>: twitter.com/jnthnwrthngtn/status/1...8722257920
lizmat notable6: weekly reset 19:46
notable6 lizmat, Moved existing notes to “weekly_2022-12-12T19:46:18Z”
19:53 Nemokosch joined
Nemokosch bisectable6: enum BooleanEnum (:!Lies, :Truth); say False ~~ BooleanEnum; 19:54
bisectable6 Nemokosch, Will bisect the whole range automagically because no endpoints were provided, hang tight
19:54 Nemokosch left
bisectable6 Nemokosch, Output on all releases: gist.github.com/f0e879eb4cfc6ce67c...144a1b1c41 19:54
Nemokosch, Bisecting by output (old=2021.12 new=2022.02) because on both starting points the exit code is 0
Nemokosch, bisect log: gist.github.com/4c74467d315f8fd21f...7a0f9f1cf6 19:55
Nemokosch, (2021-12-27) github.com/rakudo/rakudo/commit/9f...decd5dcc79
Nemokosch, Output on all releases and bisected commits: gist.github.com/7759c03d6978abeff0...dc3d152927
20:21 discord-raku-bot left, discord-raku-bot joined 20:26 sena_kun left 20:27 sena_kun joined 20:30 discord-raku-bot left, discord-raku-bot joined
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/12/12/2022-50-mainified/ 20:32
20:39 discord-raku-bot left, discord-raku-bot joined
bartolin lizmat++ 20:57
patrickb ugexe: I have just uploaded rakubrew v31 accounting for the master -> main rename. Previous rakubrew versions continue to work for the most part, as rakubrew rarely accesses the master / main branch. `rakubrew self-upgrade` is what one can do to upgrade an installation. 21:06
lizmat patrickb
++
Nemokosch 🎉 21:08
bartolin does anyone know about the impact of rakuast on the jvm backend? if I'm not mistaken the jvm backend doesn't compile anymore since we switched to main (fka rakuast). Currently it complains about the unknown nqp::const::DISP_ONLYSTAR -- e.g. dev.azure.com/Rakudo/rakudo/_build...810221fdff 21:12
but if I add that constant a new failure mode comes up: "Operation 'dispatch' requires 4 operands". Is this expected at this point? I've seen, that there are various conditionals '#if moar' around the RakuAST things in src/Perl6/bootstrap.c/BOOTSTRAP.nqp. That somehow looks like the jvm backup *should* still work. 21:16
lizmat vrurg nine might know, but nine is on holiday 21:17
bartolin in the longer run, the jvm backend probably needs to learn some of the new things as well (if it want's to live on). I'd be curious if there is a kind of "high level" assessment what needs to be implemented. 21:18
lizmat the thing is: afaik, RakuAST is just bullt on NQP and doesn't need any specific backend things
maybe that assumption is wrong :-( 21:19
bartolin maybe it's only this one call to nqp::dispatch that doesn't work on the jvm backend: github.com/rakudo/rakudo/blob/b0f9...kumod#L223 21:22
Geth rakudo/lizmat-experimental-rakuast: f184794078 | (Elizabeth Mattijsen)++ | 3 files
Implement "use experimental :rakuast"

This pretty hacky approach fetches the RakuAST type object at the end of the core.c compilation, and stashes that with bindcurhllsym. It then replaces the CORE::<RakuAST> entry with Nil, causing all lookups for RakuAST classes to fail from thereon.
... (5 more lines)		 21:28
rakudo: lizmat++ created pull request #5131:
Implement `use experimental :rakuast`
vrurg lizmat: You're right. There is one reference to a dispatcher which currently breaks JVM, but that's just a matter of implementing alternate QAST for JVM. 21:30
bartolin vrurg++ 21:31
vrurg And, again, I'm not sure what's the reason of blocking access to RakuAST types in 6.c. New macros are a different story, yes.
lizmat the pull request also allows it in 6.c
it was the simplest way 21:32
vrurg lizmat: am I missing something? `raku -e 'use v6.c; say RakuAST::CompUnit.WHICH'` on main - RakuAST::CompUnit|U3077766583360 21:35
RakuAST types are part of 6.c bootstrap.
lizmat it's a PR, did you build it ? 21:36
% r 'use v6.c; say RakuAST::CompUnit.WHICH'
Could not find symbol '&CompUnit' in 'Nil'
Geth rakudo/lizmat-experimental-rakuast: d68c80e57f | (Elizabeth Mattijsen)++ | 3 files
Add some comments on when to remove the code
 21:37
vrurg lizmat: Ah, trying to do a couple of things at once makes me slow... You just block it _without_ experimental. Well, it could be done differently, within the BOOTSTRAP. It could optionally install an entry into EXPORT. 21:40
lizmat if this gives you inspiration for a better solution, I'm all for it :-) 21:41
vrurg Not sure I could do it the coming two days.
lizmat jnthn's requirement was that users shouldn't be able to use RakuAST functionality unless it was specifically enabled
ok, would you mind if I merged it now, so that we at least have the API working ? 21:42
vrurg Better not or otherwise I would be reluctant to get it done properly. ;)
lizmat well, it's temporary anyway 21:43
I want to be able to write a blog post about RakuAST's features now, and tell about "use experimental :rakuast"
vrurg lizmat: Actually, there is even better way, than I initially thought. That EXPORT::DEFAULT.WHO<RakuAST> := RakuAST; must be replaced with bindhllsym. The `experimental` module can then export the symbol by fetching it with gethllsym. 21:45
Much less hackery.
lizmat that's what the experimental module already does
I think it's the same idea, just that the bindcurhllsym is different 21:46
vrurg Why the Nil binding then?
lizmat to disable it
to disable lookups of any of the "sub"classes of RakuAST
hmmm 21:47
which line in the bootstrap are you talking abour?
vrurg That's what I meant by removing the EXPORT::DEFAULT from bootstrap. 21:48
lizmat looks
vrurg I think it is generated by RakuAST compiler.
Yes, tools/build/raku-ast-compiler.nqp
Line 322. 21:49
Just deleting it would be sufficient to disable by default.
lizmat oki
vrurg is on the phone at the same time, so better not edit anything. :)
lizmat meh, that breaks core.c compilation of RakuAST::Deparse 21:56
vrurg lizmat: I'm sure it is fixable. 21:57
lizmat well, I guess I need to sleep on that :-) 22:01
vrurg lizmat: last note: RakuAST::Deparse must not be available either then. Perhaps it should live in lib/ for a while and be part of `use experimental` export? 22:08
lizmat vrurg: with my approach: 23:16
% r 'dd RakuAST::Deparse'
Could not find symbol '&Deparse' in 'Nil'
% r 'use experimental :rakuast; dd RakuAST::Deparse'
RakuAST::Deparse
vrurg lizmat: BTW, rather confusing error message. 23:17
23:33 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!