|
🦋 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
01:58
linkable6 left,
evalable6 left
01:59
linkable6 joined
02:01
evalable6 joined
02:48
dogbert17 left
03:08
dogbert17 joined
05:59
nativecallable6 left,
releasable6 left,
quotable6 left,
greppable6 left,
linkable6 left,
notable6 left,
unicodable6 left,
squashable6 left,
bloatable6 left,
reportable6 left,
coverable6 left,
shareable6 left,
committable6 left,
tellable6 left,
benchable6 left,
bisectable6 left,
evalable6 left,
sourceable6 left,
statisfiable6 left
06:00
jaguart left,
benchable6 joined,
committable6 joined,
sourceable6 joined,
bisectable6 joined,
coverable6 joined,
linkable6 joined,
evalable6 joined,
releasable6 joined,
jaguart joined
06:01
greppable6 joined,
squashable6 joined,
reportable6 joined,
statisfiable6 joined,
quotable6 joined,
shareable6 joined
06:02
unicodable6 joined,
bloatable6 joined,
notable6 joined,
nativecallable6 joined,
tellable6 joined
|
|||
| Geth | rakudo: usev6++ created pull request #5166: [JVM] Avoid failures caused by missing RakuAST |
06:38 | |
|
07:41
bisectable6 left,
squashable6 left,
greppable6 left,
reportable6 left,
bloatable6 left,
sourceable6 left,
tellable6 left,
committable6 left,
releasable6 left,
evalable6 left,
shareable6 left,
nativecallable6 left,
quotable6 left,
notable6 left,
unicodable6 left,
coverable6 left,
linkable6 left,
statisfiable6 left,
greppable6 joined
07:42
evalable6 joined,
tellable6 joined,
shareable6 joined,
linkable6 joined,
squashable6 joined
07:43
statisfiable6 joined,
releasable6 joined,
quotable6 joined,
reportable6 joined,
nativecallable6 joined
07:44
notable6 joined,
committable6 joined,
bisectable6 joined,
bloatable6 joined,
sourceable6 joined,
unicodable6 joined,
coverable6 joined
07:47
jjatria left
08:00
jjatria joined
|
|||
| Geth | rakudo/main: 0049c30153 | (Christian Bartolomäus)++ (committed using GitHub Web editor) | 4 files [JVM] Avoid failures caused by missing RakuAST (#5166) Three problems sneaked in that prevented the build for the JVM backend: * The operators for atomicints aren't supported yet. * The call to nqp::dispatch in src/Raku/ast/code.rakumod didn't compile either. I have no idea what it should be replaced with, but that could be figured out later on. * Run tests from t/12-rakuast on MoarVM only |
09:11 | |
|
09:13
Geth left,
Geth joined
11:00
linkable6 left,
evalable6 left
11:01
linkable6 joined
11:03
evalable6 joined
12:00
reportable6 left
12:03
reportable6 joined
|
|||
| Geth | rakudo/main: 14f56a2ca7 | (Elizabeth Mattijsen)++ | 6 files Implement support for CLOSE and QUIT phasers - Grammar / Actions added - RakuAST::StatementPrefix::Phaser::... classes added - Deparsing added - Test added Note that testing has been done without actually running any supplies, but just by interrogating a block with these phasers and running them manually. As this is what the supplies do as well (no actual code is QASTed for this in the supply handling). |
12:08 | |
| lizmat | no files won or lost | 12:13 | |
| Geth | rakudo/main: 4ab4907ab9 | (Elizabeth Mattijsen)++ | src/Raku/ast/statementprefixes.rakumod Remove dead code self.allowed-on-for-statement is always True as it inherits it from RakuAST::StatementPrefix |
12:56 | |
|
13:12
dogbert11 joined
13:14
kawaii__ joined
13:20
benchable6 left,
dogbert17 left,
discord-raku-bot left,
kawaii_ left,
kawaii__ is now known as kawaii_
13:51
epony left
|
|||
| Geth | rakudo/main: 4f207505aa | (Elizabeth Mattijsen)++ | 6 files Add (almost) complete support for ENTER phaser - Grammar / Actions added - RakuAST::StatementPrefix::Phaser::Enter class added - Deparsing added - Tests added The phaser is installed in the block, and returns its last expression. But the ENTER phaser is not actually called automatically yet, probably because I got the QAST generation wrong somehow. Hopefully nine will be able to do some magic in that respect. |
13:53 | |
| lizmat | oddly enough, this takes me to 104/139 for make test | 13:55 | |
| lizmat will hold off implementing PRE / POST / KEEP / UNDO phasers for now, until this is fixed | 13:56 | ||
|
13:59
benchable6 joined
|
|||
| Geth | rakudo/main: 6 commits pushed by (Vadim Belman)++ | 14:12 | |
| lizmat | brings it up to 108 / 139 and 632 / 1355 for me | 14:22 | |
| nine | lizmat: if you run make test without RAKUDO_RAKUAST=1 first, this will hide any regressions that only affect compilation of modules used in the tests (but not tests directly). I'd therefore consider that bad practice. | 14:25 | |
| lizmat | noted: I used "make test" as a sanity check because of the very strange errors I get every now and then | 14:26 | |
| Geth | rakudo/main: 25d583bfaa | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod RakuAST: fix bogus worry about is rw on MAIN's parameters The check forgot to check if the parameter was actually declared is rw. |
14:28 | |
| rakudo/main: bbdaf83259 | (Stefan Seifert)++ | src/Raku/ast/scoping.rakumod RakuAST: fix scopes adding themselves to themselves as declarations Nodes that are both scopes and declarations (like subs) added themselves as declarations to their own scope. This was due to self.ast-lexical-declarations including the root node (if itself is a declaration). |
|||
| rakudo/main: 68f4a96dc4 | (Stefan Seifert)++ | src/Raku/ast/compunit.rakumod RakuAST: support MAIN subs |
|||
| nine | FWIW if we want to fix those, we'd need the rakudo compiled before and after. At least the CORE.setting.moarvm (as this is where the differences most likely are) | ||
| lizmat | understood | 14:29 | |
| nine | My count is now 102 and 631 | ||
| lizmat | meanwhile, fixing github.com/rakudo/rakudo/commit/4f207505aa seems to be another way of gaining a few passes | 14:30 | |
| nine | Btw. that's actually a good process to trigger the error: compile rakudo, run something that precompiles a module, then save the generated files, make clean, build again, run the same test again and if it breaks, see where the differences in generated bytecode between now and the backup are | 14:31 | |
|
14:35
epony joined
|
|||
| lizmat | nine: using your methodology, I come to 103 / 139 and 630 / 1355 | 14:36 | |
| Geth | rakudo/main: c0cee2e5b7 | (Stefan Seifert)++ | 2 files RakuAST: support phasers on the comp unit itself During compilation the mainline block does not exist, so instead we need to install mainline phasers on the comp unit and add them to the generated QAST block later. |
15:33 | |
| rakudo/main: bbe447dbb2 | (Stefan Seifert)++ | 2 files RakuAST: actually install ENTER phasers |
|||
| rakudo/lizmat-1.log: 0d31a24349 | (Elizabeth Mattijsen)++ | src/core.c/Num.pm6 Make (-1).log mathematically correct Before, this would return NaN, rather than Complex.new(1.log,pi) (which would be more mathematically correct). This breaks 2 spectests, checking for (-Inf).log basically, and makes one todo test pass. Inspired by wandering.shop/@colomon/109744612694765045 |
15:36 | ||
| rakudo: lizmat++ created pull request #5167: Make (-1).log mathematically correct |
|||
| lizmat | nine++ (fixing ENTER phaser) | 15:37 | |
| my attempt so close, and yet so far away :-) | |||
| guess I'm ready to do PRE POST KEEP UNDO now :-) | 15:38 | ||
| Geth | rakudo/main: 49cb197a90 | (Elizabeth Mattijsen)++ | t/12-rakuast/statement-phaser.rakutest Untodo now passing ENTER phaser tests |
16:00 | |
|
16:02
Geth left,
Geth joined
16:13
discord-raku-bot joined
16:28
discord-raku-bot left,
discord-raku-bot joined
|
|||
| Geth | rakudo/main: d8184117b3 | (Elizabeth Mattijsen)++ | 2 files Add deparsing and tests for RakuAST::StatementPrefix::Phaser::Init |
16:36 | |
|
17:22
[Coke] joined
|
|||
| [Coke] | . | 17:22 | |
| Geth | rakudo/main: 9fc9b06180 | (Stefan Seifert)++ | 2 files RakuAST: fix default type of signature declarations to Any The default value for variables is Any, not Mu. However, we must not set a non-Mu type on array or hash variables as we'd e.g. create an object hash instead of a normal one. So instead of trying to figure out a default type, just don't set any type if we don't have one, but instead create containers for all variables unconditionally. I don't think this is entirely correct, but with my existing confusion about type, of and default, it's the best I can do and it unlocks a few more tests. |
17:31 | |
| nine | 107 and 633! | ||
| lizmat | whee! | 17:40 | |
| almost finished with KEEP and UNDO phasers :-) | |||
| nine | t/08-performance/05-processkeys.t is complaining about a $W, but it doesn't indicate what one should do about it | 17:41 | |
|
18:00
reportable6 left
18:02
reportable6 joined
|
|||
| lizmat | could that be something that vrurg introduced ? | 18:11 | |
| Geth | rakudo/main: 91ebaa013f | (Elizabeth Mattijsen)++ | 6 files Add complete support for KEEP / UNDO phasers - Grammar / Actions added - RakuAST::StatementPrefix::Phaser::(Keep|Undo) classes added - Deparsing added - Tests added This one turns out to be simple: it just needed the exit-handler flag to be set. |
18:12 | |
| rakudo/main: 03b2cf356e | (Elizabeth Mattijsen)++ | 2 files Fix issue with multiple FIRST phasers Any additional FIRST phasers would not be called because the "first" flag was already reset. Combine all FIRST phasers into a single statement list if there are more of them |
18:47 | ||
|
18:56
NemokoschKiwi joined
|
|||
| nine | m: my $foo = $*FOO; say PROCESS::.keys | 18:58 | |
| camelia | ($SPEC $ERR $FOO $SCHEDULER $IN $OUT $AWAITER $PID &chdir $RAT-OVERFLOW %ENV $CWD) | ||
| nine | Huh? Will any dynamic variable show up in PROCESS::? | ||
| [Coke] | *. | 18:59 | |
| oops | |||
|
19:00
NemokoschKiwi left
|
|||
| lizmat | bisectable6 | 19:25 | |
| bisectable6: old=2020.02 my $foo = $*FOO; say PROCESS::<$FOO>:exists | 19:26 | ||
| bisectable6 | lizmat, Bisecting by output (old=2020.02 new=d52342e) because on both starting points the exit code is 0 | ||
| lizmat, bisect log: gist.github.com/f19bdf1b74aab09604...81e0d35d3e | 19:27 | ||
| lizmat, (2022-03-30) github.com/rakudo/rakudo/commit/e7...f51a6b8746 | |||
|
19:56
ab5tract joined
|
|||
| nine | lizmat: apparently you wrote that test for PROCESS keys :) | 20:30 | |
|
20:31
ab5tract left
20:33
[Coke] left
|
|||
| nine | Ha! Now I know why they are called "post constraints". Because they have to be processed _after_ binding an argument | 21:03 | |
| vrurg | Wow, Nobel prize for the genius! :D :D :D | ||
| vrurg feels like he is gonna be beaten hard today... ;) | 21:05 | ||
| nine | Would you have known that the post is about binding? ;) | 21:07 | |
|
21:11
[Coke] joined
21:14
[Coke]_ joined
21:16
[Coke] left
|
|||
| vrurg | nine: I've spent enough time around that location in the legacy Actions to knew about it back then. Not sure if I'd recall if asked recently... :) | 21:19 | |
| Geth | rakudo/main: 69fa6bbaf8 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod RakuAST: fix parameter where constraints acessing the parameter target Where constraints on parameters are "post constraints" because they must be evaluated after binding the argument to the paramter target. Fixes sub foo($x where { say $x }) {} |
21:23 | |
| nine | 108 and 634 respectively :) | ||
| Nemokosch | this reminds me of a recent issue | 21:25 | |
| if you have a coercion of the format Target(SourceSubset), the conditions of the subset will be evaluated after the coercion happens... | 21:26 | ||
| do you know anything about that behavior? | 21:27 | ||
|
21:30
[Coke]_ is now known as [Coke]
|
|||
| vrurg | The source is checked before, the target – after. Are there any other way? | 21:48 | |
| Nemokosch | That's what I expected, too, but not what I witnessed | 21:51 | |
| what I witnessed was that the condition of the subset jumped outside and was performed after the coercion | |||
| vrurg | Actually, it's not impossible. The "post" might play the role. Unfortunately, I don't remember all the details right away. | 22:01 | |
| Nemokosch | Now, I tried to reproduce and failed. Unfortunately I don't have the exact code that led me to this conclusion, it was while working on this github.com/raku-community-modules/...l/67/files | 22:03 | |
| It could also be that I misunderstood something... I tried to do open-xml more literally, taking the constrained Str and just wrapping it into IO::Path, I don't remember the details | 22:04 | ||
| vrurg | As long as I checked the actions, constraint type is checked prior to coercion. So, should be some kind of mistake. | 22:10 | |
| Nemokosch | okay... not quite what I said but this still seems strange: glot.io/snippets/ghlfzwgoss | 22:18 | |
|
22:18
guifa_ left
|
|||
| this doesn't happen if I say of Str:D actually. The Str type object goes in for some reason, and then explodes | 22:21 | ||
| it also doesn't happen for a variable constraint and assignment. Probably there's some interference with multiple dispatch | 22:25 | ||
| the multiple dispatch, the lack of 😄 and the coercion are all needed apparently... | 22:26 | ||
| vrurg | Do you know that .IO is a coercion method creating an IO::Path for you? | 22:27 | |
| Nemokosch | yes | ||
| it's not a very practical example, although it is inspired by a state that showed up while refactoring the sub | 22:28 | ||
| something tells me, though, that it should have worked. The fact that the absence of the type smiley, the parameter and the coercion together are responsible for this behavior, makes this suspicious | 22:30 | ||
| vrurg | Ha, it's the optimizer! Oh, my... It tries to optimize a constant parameter call. | 22:32 | |
| Nemokosch | glot.io/snippets/ghlgf84bly this is more or less a golf I think. One multi candidate, coercion in the parameter, no Str:D. | 22:33 | |
| vrurg | And does it all wrong by typechecking on the subset from argument's type, not value. Actually, it must not optimize over subsets with dynamic constraints at all. | ||
| The current situation is such that it is unlikely that the optimizer would get a fix soon. | 22:36 | ||
| Nemokosch | There was that benchmark with the "speed regressions", and I started thinking that many of those speed regressions might actually be fixes of broken optimizations | 22:37 | |
| anyways, it would be good to note this somewhere. Should I open an issue? | 22:41 | ||