🦋 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:01 reportable6 left 00:04 reportable6 joined 01:16 guifa joined 04:23 linkable6 left, evalable6 left 04:24 evalable6 joined 04:25 linkable6 joined 04:26 epony left 05:30 quotable6 left, reportable6 left, bloatable6 left, coverable6 left, evalable6 left, releasable6 left, shareable6 left, squashable6 left, tellable6 left, unicodable6 left, sourceable6 left, linkable6 left, committable6 left 05:31 sourceable6 joined, committable6 joined, releasable6 joined, unicodable6 joined, quotable6 joined, squashable6 joined 05:32 bloatable6 joined, coverable6 joined, linkable6 joined, evalable6 joined, tellable6 joined 05:33 reportable6 joined, shareable6 joined 06:00 reportable6 left 06:01 reportable6 joined 07:02 linkable6 left, evalable6 left 07:03 linkable6 joined 07:06 evalable6 joined
Geth rakudo: usev6++ created pull request #5187:
[JVM] Set Xmx4G for building Rakudo		 08:25
09:05 sivoais left 09:55 sivoais joined 09:57 sena_kun joined
nine m: module A { module B { module C { module D { say B::.keys } } } } 10:04
camelia (C)
nine m: module A::B::C::D { say B::.keys }' 10:05
camelia ===SORRY!=== Error while compiling <tmp>
Strange text after block (missing semicolon or comma?)
at <tmp>:1
------> module A::B::C::D { say B::.keys }⏏'
expecting any of:
infix
infix stopper
stat…
nine m: module A::B::C::D { say B::.keys }
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared name:
B used at line 1
nine I'd claim that these should give the same result
(yes, I should have used package instead of module, but that doesn't change the result) 10:06
10:41 sena_kun left 10:44 sena_kun joined
Geth nqp: usev6++ created pull request #797:
[JVM] Add op jvmgetunicodeversion		 11:33
rakudo: usev6++ created pull request #5188:
[JVM] Add support for $?UNICODE-VERSION
11:41 ab5tract joined
ab5tract nine: yeah, I think that is a reasonable claim :) 11:42
Geth rakudo/main: e1899640a9 | (Elizabeth Mattijsen)++ | 3 files
RakuAST: merge ::Isms into RakuAST::Pragma

  - also prepare RakuAST::Pragma to handle more arguments
  - change interface to use nameds only as we now have more of them
  - adapt calls to ::Pragma accordingly
  - adapt deparsing accordingly
  - no tests needed adaptation, as none were made yet		 11:44
rakudo/main: df1fbfedf6 | (Elizabeth Mattijsen)++ | src/Raku/ast/pragma.rakumod
Disable MONKEY- pragmas without meaning for now

These were added a long time ago, but never had any meaning associated with them apart from them having a funny name. Nothing could be found in the design documents either.		 11:47
ab5tract nine: I see you've been working on adding an `$!is-stub` to the packages 11:51
is that all wired in now or is it a WIP? 11:52
I think the compiler needs to (re-)learn about stubbing 11:53
nvm, according to the comment in PERFORM-BEGIN, it's not actually ready yet 11:55
12:00 reportable6 left 12:01 reportable6 joined
[Tux] Rakudo v2022.12-1-gd52342eb0 (v6.d) on MoarVM 2022.12-15-g6b456a6c0
csv-ip5xs0.822 - 0.873
csv-ip5xs-205.343 - 5.412
csv-parser3.801 - 3.848
csv-test-xs-200.412 - 0.424
test6.494 - 6.780
test-t1.423 - 1.441
test-t --race0.851 - 1.054
test-t-2020.521 - 22.274
test-t-20 --race6.806 - 7.016
 12:07
ab5tract Can't wait to see more dramatic shifts in the right direction on these tests [Tux] 12:29
Nemokosch I don't know what good comes from posting these results all the time...
especially now when optimizations are not the primary concern clearly
Another note about benchmarks: perhaps I said this but they can easily become unfair, without running the new spectests on the older versions 12:30
because the language itself shifts when contradictions to implied behavior are noticed 12:31
ab5tract I don't know, I think it's fair to have a relatively arbitrary benchmark. 12:37
I wouldn't say it should be a *primary indicator* for the project or anything 12:38
It's been incredible to watch those numbers halve or better when various general language optimizations have been merged
But I guess I also haven't paid much attention to how frequently they might be posted 12:39
And IIRC, one of the ultimate pushing points for RakuAST's development was when we had the most recent performance regression 12:43
Nemokosch I think it's fairly uncontroversial that correctness should come before performance 12:44
ab5tract obviously
Nemokosch and unfortunately optimizations are a usual source of behavior regressions. I'm not saying that this is a hard law of nature but I'd always take these out-of-context benchmarks with a grain of salt
because it's very possible that a performance regression is simply related to a bugfix 12:45
meaning that the previous state was simply invalid, an unfair comparison
ab5tract Nemokosch: Ah yes, I see your concern 12:46
tellable6 ab5tract, I'll pass your message to Nemokosch
Nemokosch it would be interesting to run current spectests against older versions, too 12:47
we'd get a more complete picture, I would hope
ab5tract Yeah, that is an interesting thought.
lizmat I'd always welcome more metrics, but spectests are intrinsically a bad benchmark, because most code doesn't run long enough to get optimized 12:50
Geth rakudo/main: dbbd515a67 | (Elizabeth Mattijsen)++ | src/Raku/ast/pragma.rakumod
Add support for more pragmas

Namely: soft attributes invocant parameters variables
Some of these don't actually work yet, but didn't work before: the original code has been ported		 12:51
lizmat 659/1355 supporting "use soft" gave us another file
ab5tract lizmat: I merged with main and now my branch is giving a sorry: 'Error while compiling, type X::Parameter::InvalidType \n typename: RakuAST::Nqp' 12:58
lizmat m: use experimental :rakuast; dd RakuAST::Nqp 12:59
camelia You cannot deparse a RakuAST::Nqp type object
in any DEPARSE at src/Raku/ast/base.rakumod line 291
in block <unit> at <tmp> line 1
lizmat m: use experimental :rakuast; dd RakuAST::Nqp.new("say","foo")
camelia nqp::say("foo")
lizmat looks like it works for me
? 13:00
Geth rakudo/main: 0e99334e5f | (Jared Miller)++ (committed by Christian Bartolomäus) | 10 files
Fix minor non-comment typos

There are plenty of comment related typos
ab5tract let me merge again
Nemokosch Oh sure, I don't mean for benchmarking, just for retrospective validation 13:02
ab5tract hmm, looks like it went through fine the next time around after a rebase
lizmat *phew*
Nemokosch Something that was "valid Raku" in 2016 might be failing everywhere in 2023 13:03
ab5tract lizmat: actually wait, nope :(
lizmat ab5tract: could you give me a golf? 13:04
ab5tract of the branch? probably not :) ... should have mentioned the sorry happens during compilation 13:05
also seems to happen when I'm on `main` with current upstream
13:05 linkable6 left, evalable6 left
ab5tract This is after a `make clean` 13:05
it happens while compiling the core setting 13:07
13:07 linkable6 joined 13:08 evalable6 joined
lizmat I'm sorry, I'm not seeing that :-( 13:09
ab5tract Anyone else on Linux that can check? 13:25
Geth rakudo/main: 5dc5bb7147 | (Elizabeth Mattijsen)++ | src/Raku/ast/pragma.rakumod
RakuAST: make "use soft foo" a NYI

Instead of silently ignoring any arguments		 13:29
lizmat ab5tract: fwiw, it still feels like an incomplete merge somehow ?
ab5tract make realclean fixed it 13:30
*phew*
lizmat you may have needed to reconfigure
I always do that standard nowadays, with a "make clean"
a lot less issues with broken precomps that way
also, you might want to install "Repository::Precomp::Cleanup" 13:31
and run cleanup-precomp every now and then
I just did:
% cleanup-precomp 13:32
Freed 220,960,812 bytes from 7 repositories.
it basically removes *all* precomps that were not make with the current Compiler.id
*made
ab5tract ahh, nice! 13:33
\o/ 13:51
I solved the issue with 'class F::B {}; subset F where 5; my F $f = 5; die unless F::.keys.grep("B")' 13:52
now only two tests failing in my corpus.. the proper hiding of my scoped subsets and the issues with WhateverCode 13:53
Geth rakudo/main: 47408ed8a7 | (Elizabeth Mattijsen)++ | src/Raku/ast/statements.rakumod
RakuAST: properly handle "use lib" errors
lizmat which brings us to 660/1355 (t/spec/S10-packages/require-and-use.t now passes)
nine bash config.status is required after a file got added to the core 14:18
ab5tract nine++ 14:29
lizmat++
increments for everybody!
lizmat ab5tract++ 14:30
indeed
Geth rakudo/main: 91965978a8 | (Elizabeth Mattijsen)++ | 3 files
RakuAST: move "use lib" handling to RakuAST::Pragma

This means that RakuAST::Statement::No has now basically become an empty husk. And that RakuAST::Statement::Use now only handles actual loading of modules and not handle any pragmas anymore. Which allowed for a significant simplification.
ab5tract Hey nine, you know how you said I needed to resolve the current package at attach time? How come the package code doesn't do that? 14:33
Geth rakudo/main: 6405f37937 | (Stefan Seifert)++ | src/Raku/ast/resolver.rakumod
RakuAST: look up names not only lexically but also in packages
 14:35
rakudo/main: 46982a940b | (Stefan Seifert)++ | 2 files
RakuAST: fix resolver in dynamically compiled code missing symbols

The resolver used for resolving symbols in dynamically compiled code needs to be the resolver as it was at the time when we created the stub for that piece of code, because the resolver's state then reflects the lexical environment that the code is defined in.
So use a deep clone of the resolver in the "lexical not found" callback.
ab5tract hmm, I was hoping this new patch from nine would fix this issue: 'my subset P::F where 5; "my P::F \$f = 5".EVAL' <--- works 14:52
'my subset P::F where 5; my P::F $f = 5' <--- malformed my
nine Ah I think for that the new code in the resolver would need to learn about multi-part names. 14:57
ab5tract would that involve adding new variants to `resolve-name` and friends that handle parts? I guess I'm having trouble conceptualizing that change 15:03
I don't suppose you have the tuits? :) 15:04
nine IMPL-RESOLVE-NAME-IN-PACKAGES needs to be expanded. Honestly I don't know if I have the smarts today to do this. FOSDEM is somewhat exhausting 15:21
ab5tract oh, no worries! I forgot FOSDEM is today 15:27
I think I understand what you mean.. let me give it a try
nine ++ab5tract 15:29
15:44 linkable6 left, evalable6 left 15:45 evalable6 joined, linkable6 joined
Geth rakudo/main: 32a733c553 | (Elizabeth Mattijsen)++ | 5 files
RakuAST: Eradicate Statement::No class

Since all use of "no foo" will be pragmas for the foreseeable future, it doesn't make sense to keep the class around, but instead directly refer to the RakuAST::Pragma class directly in the actions.
This allows further simplifications, and changing tests for RakuAST::Statement::No to RakuAST::Pragma		 16:23
ab5tract dang, I'm getting nowhere 16:35
Geth rakudo/main: 403b680acd | (Elizabeth Mattijsen)++ | src/Raku/ast/pragma.rakumod
RakuAST: don't allow "use lib" inside a package statement

This check was omitted so far.		 16:50
lizmat brings us to 661 / 1355 (t/spec/S04-phasers/end.t now passes) 16:51
not sure how that's related, but I'll take it :-) 16:52
nine I think end.t was on me :) 17:03
lizmat aha... ok, that makes sense :-) 17:04
hmmm... still ah well, more important things to do 17:05
17:06 gfldex left, gfldex joined
Geth roast: usev6++ created pull request #829:
Use Test::Util's &make-temp-path for socket tests		 17:11
lizmat nine: I just realized that .new on classes in RakuAST work because of Mu.BUILDALL 17:12
nine: I just realized that .new on classes in RakuAST work because of Mu.BUILDALL 17:13
which is the default if a class has no method BUILDALL of its own
so the problem with defaults of attributes and so, are cause by BUILDPLAN not being set up correctly
17:13 Geth left 17:14 Geth joined
lizmat so I'll focus on that first before working on creating custom BUILDALL methods 17:14
17:19 ab5tract left 18:00 reportable6 left 18:01 reportable6 joined 18:13 [Tux] left
nine ok 18:14
18:24 [Tux] joined
Geth rakudo/main: 0d9f70a088 | (Elizabeth Mattijsen)++ | src/Raku/ast/variable-declaration.rakumod
Normalise RakuAST class specifications (9/N)
 18:51
18:53 Geth left, Geth joined 18:58 Geth left, Geth joined 19:10 epony joined
lizmat nine: re attributes defaults, it looks to me that 19:19
github.com/rakudo/rakudo/blob/main...kumod#L354
and github.com/rakudo/rakudo/blob/main...kumod#L403
are in contradiction: the else clause is never entered for "has" scoped things, yet the else clause checks on a "." twigil ?
going to mull on that a bit 19:21
20:13 ab5tract joined
ab5tract I 20:19
I've pushed the approach I started taking in resolver.rakumod
Geth rakudo/main: 33c2b283ca | (Elizabeth Mattijsen)++ | src/Raku/ast/literals.rakumod
Introduce RakuAST::Literal class

To keep all of the common stuff in the xxxLiteral classes in one place and to allow for easier checking for *any* RakuAST literal
Also: normalise RakuAST class specifications		 20:38
20:41 Geth left, Geth joined 20:55 ab5tract left 21:00 ab5tract joined
ab5tract what would be the most idiomatic (or best for core) way to check whether a type object represents a package or not? 21:30
My first impulse is to use nqp::type against its HOW
lizmat m: package A { }; dd A.HOW.^name
camelia "Perl6::Metamodel::PackageHOW"
lizmat or check against its name 21:31
ab5tract thanks! 21:33
lizmat I wonder if we would need to introduce some ^method to give the type of package
to avoid checking against names that may change 21:34
ab5tract it's a pretty specific little corner I'm plugging at...
not sure how useful it would be outside of this sort of installing and stubbing packages scenario
lizmat ack 21:35
ab5tract just something about tightly coupling it to the type rubs me the wrong way 21:36
Geth rakudo/main: 1d97dceb25 | (Elizabeth Mattijsen)++ | 23 files
Normalise RakuAST all other class specifications (10/10)
 21:44
lizmat oops, I'm afraid something snuck in here that shouldn't have snuck in there :-( 21:49
21:49 sena_kun left 21:50 sena_kun joined
ab5tract hate it when that happens 22:08
Geth rakudo/main: 5cc476e7e5 | (Elizabeth Mattijsen)++ | 5 files
Add support for Complex literals
 22:10
lizmat should be all well now, at 665 / 1355 now passing
so +4
ab5tract excellent :)
22:24 sena_kun left
ab5tract m: class A { }; dd A.HOW.^name 22:37
camelia "Perl6::Metamodel::ClassHOW"
lizmat m: class A { }; dd A.HOW.^name.split("::").tail.chop("HOW").lc 22:40
camelia Cannot convert string to number: base-10 number must begin with valid digits or '.' in '⏏HOW' (indicated by ⏏)
in block <unit> at <tmp> line 1
lizmat m: class A { }; dd A.HOW.^name.split("::").tail.chomp("HOW").lc
camelia "class"
lizmat m: module A { }; dd A.HOW.^name.split("::").tail.chomp("HOW").lc
camelia "module"
lizmat m: gramma A { }; dd A.HOW.^name.split("::").tail.chomp("HOW").lc
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared name:
A used at lines 1, 1
Undeclared routine:
gramma used at line 1
lizmat m: grammar A { }; dd A.HOW.^name.split("::").tail.chomp("HOW").lc
camelia "grammar"
ab5tract I couldn't compile a call to $thing.HOW.^name 22:41
and 'nqp::istype($resolved.HOW, Perl6::Metamodel::ModuleHOW)' is not working as expected 22:44
right before, I print '$resolved.HOW.raku' and that outputs "Perl6::Metamodel::ModuleHOW.new" 22:45
lizmat that'd be weird ?
22:45 melezhik joined
ab5tract yeah, I'm definitely flummoxed 22:46
oh man... is this a huge brain fart? 22:47
yes, yes it is
22:49 melezhik left 22:52 melezhik joined
Geth rakudo/main: 4a6ea806c6 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: Make sure we default to "use strict"

In preparation to support "no strict" in RakuAST		 22:55
22:56 melezhik left
lizmat and that concludes my hacking for today& 22:56
ab5tract check time is earlier than begin time, right? 23:24
Geth tap-harness6: a4b499debf | (Leon Timmermans)++ | lib/TAP.rakumod
Fix shebang detection in TAP::SourceHandler::Raku
 23:28
tap-harness6: ac8f3edd36 | (Leon Timmermans)++ | 2 files
Colorize "ok" on success"
tap-harness6: 75ec11374b | (Leon Timmermans)++ | 3 files
0.3.14
23:48 melezhik joined 23:52 melezhik 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!