02:41 Xliff joined 05:58 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 06:17 AlexDaniel left 07:00 sena_kun joined
[Tux] Rakudo version 2020.09-8-g62a22d0fe - MoarVM version 2020.09-8-g60070970c
csv-ip5xs0.815 - 0.831
csv-ip5xs-207.968 - 7.970
csv-parser26.192 - 28.683
csv-test-xs-200.392 - 0.392
test7.759 - 7.915
test-t1.870 - 1.914
test-t --race0.842 - 0.958
test-t-2032.682 - 32.852
test-t-20 --race9.440 - 9.851
 07:26
MasterDuke anyone have an idea why github.com/rakudo/rakudo/blob/mast...#L242-L260 (`multi sub infix:<%%>(Int:D \a, Int:D \b) {`) isn't in Int.pm6? 08:17
looks like there is an Int candidate for each of gcd and lcm that also belong in Int.pm6 08:20
lizmat: just an oversight in github.com/rakudo/rakudo/commit/75...7f93def3d3 ? 08:21
09:42 Altai-man joined 09:44 sena_kun left 10:08 codesections left, codesections joined
lizmat MasterDuke: pretty sure I just followed with whatever was there, so I have no idea why it lives there 10:23
MasterDuke: I'd say, move it and see what happens
generally, some things need to be done in a specific order in the setting, so there *could* be a reason it lives where it lives, then again, that reason can have disappeared since then 10:24
the setting *is* bootstrapping itself: e.g. a trait on a Routine needs to have been defined before it can be applied to a routine :-) 10:25
this is the reason for the weird src/core.c/precedence file: at the time the operators were defined, you could not apply the precedence trait yet because it didn't exist yet 10:27
so it happens at BEGIN time close to the end of setting compilation
Geth rakudo/rakuast: 36a0bfa6c1 | (Elizabeth Mattijsen)++ | t/12-rakuast/regex.t
Source comment tweaks
 11:04
rakudo/rakuast: 6d62abd2a7 | (Elizabeth Mattijsen)++ | t/12-rakuast/statementprefixes.t
Migrate remaining statement prefix tests

These were held up because initially they seemed to indicate a bug in the rakuast implementation. Turns out it is a bug / feature of string EVAL in master as well: on successful execution, it does not set $!, *or* it sets it to Any. Todoed related tests.
rakudo/rakuast: 4dc741bab5 | (Elizabeth Mattijsen)++ | t/12-rakuast/package.t
Mark failing package name test as todo
 11:11
Xliff lizmat: Can you tell me why my RakuAST samples don't run, but the test codes appear to run fine? 11:19
lizmat the rakuast branch is really two projects in one 11:20
Xliff And yes, I am setting RAKUDO_RAKUAST, but I am getting typed_panic exceptions
lizmat one is the building the RakuAST class hierarchy 11:23
the tests in t/12-rakuast test those, and that's what I've been working on 11:24
Xliff I know.
lizmat the other is replacing the src/Perl/Grammar|Actions|World with src/Raku/Grammar|Actions
that's what you activate with RAKUDO_RAKUAST 11:25
Xliff So why is it, when I copy code from t/12-rakuast, and try them in my sample code, they don't work? I figure I'm not in the right environment.
lizmat (sprry, just mentioning it for people less informaed)
Xliff And I JUST TOLD YOU that I set that variable.
And I am getting typed_panic exceptions.
nine Xliff: no need to shout
Xliff So if there is a bug, where do I report? 11:26
If there is something else I need to do, what is it?
lizmat Xliff: currently, only 200+ spectest files pass their tests, out 0f 1336 11:27
so I think it's likely you're running into uncovered parts of the migration pretty quickly
Xliff Yes, and I am using code that passes in a different type of script.
lizmat with all sorts of ... interesting errors
Xliff Maybe code will help explain. 11:28
lizmat it probably will, it will allow me to double check the problems you're seeing
Xliff This is the script I am currently trying to run: repl.it/@Xliff/AshamedBeautifulBud...#main.raku 11:29
Geth rakudo/rakuast: 4dd89c5799 | (Elizabeth Mattijsen)++ | t/12-rakuast/strings.t
Remove DEPARSE test

for code that currently does not have a proper source representation.		 11:30
Xliff Much of this should look familiar. It's all in t/12-rakuast
When I invoke via: RAKUDO_RAKUAST=1 perl6 ~/test-ast.pl6
I get: ===SORRY!=== 11:31
Cannot find method 'typed_panic' on object of type Raku::Grammar
lizmat ah.. but if you're doing that, you should *not* use the RAKUDO_RAKUAST=1
Xliff Fair enough. If I don't, I get: "Too many positionals passed; expected 1 argument but got 2 11:32
in block <unit> at /home/cbwood/test-ast.pl6 line 5"
lizmat yeah, that's because recently the interface for Expression has changed
from taking a single positional, to a named expression => parameter
Xliff So why are the tests working?
I mean, this is code lifted right out of a working test.
lizmat but from a few days ago ? 11:33
Xliff Currently active git code!
lizmat the current tests use expression =>
Xliff I can go and run the script containing the active code in this script and it will work just fine.
lizmat since 0c81db7ae38aa06eead466b2
I added "expression => " in two locations in your code, and it then runs fine 11:34
Xliff So ::Expression is now "expression =>" ? 11:35
lizmat ::Expression.new( expression => ... ) indeed
Xliff OK. Adjusting
OK. Works. Thank you! 11:37
lizmat you're welcome
glad to see more eyes on it
Xliff: BTW, you can now also do "dd $ast" to see a source representation of the AST 11:39
Xliff lizmat++ 11:40
Good to know, thanks!
Also, if I do run into bugs, where is the best place to report them?
lizmat I guess making an issue for it is best 11:41
I'll create tags for "if you're working on building code with RakuAST classes" and "using RAKUDO_RAKUAST=1" 11:42
Altai-man Isn't RakuAST incomplete to get issues? 11:45
timotimo never too early to complain :) :) :) :)
lizmat well, the RAKUDO_RAKUAST=1 part definitely is
but the RakuAST:: class development (as far as it is developed) *should* work now, and works as far as tests are concerned now (apart from some minor todos) 11:46
Altai-man I don't follow closely, but remember, hmm, "Try it out, break it, etc. (Please don't report things that are missing at this point. Most things are, so it's not that useful. :-))". I suspect it is not caused by a missing thing, so sorry for not backlogging enough.
lizmat again, running code with RAKUDO_RAKUAST=1 is definitely *NOT* ready for issue reporting yet
code that uses the RakuAST classes, like my re-implementation of sprintf, definitely is 11:47
timotimo has .assuming been attempted on rakuast yet? 11:48
Xliff How is that going, by the way?>
lizmat: ^^ # re sprintf
lizmat it's implemented using RakuAST in the rakuast branch now
Xliff goes to check.
lizmat currently it's called zprintf for easier testing / comparison with sprintf 11:49
Xliff sourcebaby: 2.sprintf("%d")
sourceable: 2.sprintf("%d") 11:50
sourceable6 Xliff, github.com/rakudo/rakudo/blob/62a2...l.pm6#L391
lizmat src/core.e/Formatter.pm6
Xliff lizmat: Ah. Thanks. 11:51
lizmat only available with 'use 6.e.PREVIEW'
Xliff: if you really want to get into this, you could have a look at re-implementing "assuming" in RakuAST :-) 11:54
Ah, I just notice timotimo mentioned assuming
Xliff Heh. I may take a look. This is only my first day looking at it, and all
lizmat yeah... it may be rather steep 11:55
Xliff Nice thought, though.
lizmat yeah, it's one of the few places in core that uses STRING eval atm
Xliff I am trying to get some footing for the eventual Macro implementation
I am probably going to need it for my p6-GLib projects
11:56 Kaiepi left 11:58 Kaiepi joined
lizmat Xliff: without a macro implementation, I think you can already do quite some "damage" with creating your own custom AST's in a library and then EVALling them to get code to execute 11:58
Xliff: in any case, I'm first going to look at the use of EVAL in CURI, and then if nobody has beaten me to it, look at assuming 11:59
BTW, another one is src/core.c/INTERPOLATE :-) 12:00
Xliff OK, I will follow along, then. 12:02
lizmat ok, MAKE_REGEX is still no go, as it needs :context for the EVAL, and that is as yet unsupported in rakuast last 12:03
*land
12:08 Kaiepi left 12:11 leont joined, Kaiepi joined
Xliff Mmm: 0-cost sprintf! 12:14
lizmat: Is that why you called it zprintf? :)
nine lizmat: EVAL in CURI will usually want evaluation via the AST instead of full blown compilation as it's rather simple expressions that are only run once 12:15
lizmat Xliff: actually, no, just something phonetically close, but it's a nice idea 12:16
timotimo the DependencySpecification.new(...) blah?
lizmat nine: yeah, that was my thought as well
nine timotimo: yes
12:16 Kaiepi left
timotimo i wonder if most dependency specifications are simple enough to be parsed by a much simplified grammar without a need for compilation anyway, though of course RakuAST is so close that it could also be a waste of time 12:23
nine They are - it's what we do on JVM 12:24
But we only need to evaluate them when we need to re-scan dependencies, i.e. after anything changed in any repository
timotimo oh
nine So there are actually 3 stages: take forever as we need to compile, just check if any dependency changed, everything is the same as last time: just load this flat list of files and be done 12:26
12:30 Kaiepi joined
Geth rakudo: MasterDuke17++ created pull request #3943:
Move Int candidates from Numeric.pm6 to Int.pm6		 13:04
13:09 Kaiepi left, Kaiepi joined
Geth rakudo/Junction-collapse: 351070b6eb | (Elizabeth Mattijsen)++ | src/core.c/Junction.pm6
Add Junction.collapse method

Inspired by Wim Vanderbauwhede's The strange case of the greedy junction
   gist.github.com/wimvanderbauwhede/...05740adcf8
The implementation is rather different from the one proposed, but this should perform a *lot* better.		 13:11
rakudo: lizmat++ created pull request #3944:
Add Junction.collapse method		 13:12
13:42 sena_kun joined 13:44 Altai-man left
Geth rakudo: bf799bae11 | (Daniel Green)++ | 2 files
Move Int candidates from Numeric.pm6 to Int.pm6
 14:05
rakudo: 029094282c | MasterDuke17++ (committed using GitHub Web editor) | 2 files
Merge pull request #3943 from MasterDuke17/move_Int_candidates_from_Numeric_to_Int

Move Int multis from Numeric.pm6 to Int.pm6
rakudo: 51db5341a7 | (Stefan Seifert)++ | src/Perl6/World.nqp
Fix stub packages in multi part declarations only knowing part of their name

In package Foo { package Bar::Baz { } } the created stub package for Bar had only "Bar" as longname instead of the expected "Foo::Bar" like you'd get if the Bar package was created explicitly. Fix by using the target package's name as starting point when assembling the longname.		 14:20
rakudo: 9fdc003ef1 | niner++ (committed using GitHub Web editor) | src/Perl6/World.nqp
Merge pull request #3926 from rakudo/fix_name_of_stub_packages_in_multi_part_declarations

Fix stub packages in multi part declarations only knowing part of the…
lizmat afk for a few hours& 14:37
Geth rakudo/fix_possible_race_in_multi_threaded_precompilation: 12946210ea | (Daniel Green)++ | src/core.c/CompUnit/PrecompilationStore/File.pm6
Fix possible race in multi-threaded precompilation

by changing $!lock-count to an atomicint and using atomic operations to interact with it. This code used to be inside a `.protect` call (and so didn't need to be atomic), but that was removed in ac87ea2ac84883bf701808485ac2da887f7496ed for other reasons.		 14:43
15:01 domidumont joined 15:20 domidumont1 joined 15:22 domidumont left 16:24 hankache joined 16:51 hankache left 17:08 domidumont1 left 17:41 Altai-man joined 17:44 sena_kun left 17:50 domidumont joined 18:03 domidumont left
MasterDuke nine, lizmat: github.com/rakudo/rakudo/pull/3741 looks good to CI, mergeable? 18:13
18:42 Xliff left 20:38 Altai-man left
Geth roast: d89e475eb2 | (José Joaquín Atria)++ | S04-phasers/in-loop.t
Test FIRST statement in loop does not warn

Closes R#1900 rakudo/rakudo#1900		 21:28
roast: f05caa0398 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | S04-phasers/in-loop.t
Merge pull request #675 from jjatria/raku_1900

Test FIRST statement in loop does not warn
linkable6 R#1900 [open]: github.com/rakudo/rakudo/issues/1900 [phasers][tests needed] Weird warning about sink context in loop phaser
linkable6 RAKUDO#1900 [open]: github.com/rakudo/rakudo/issues/1900 [phasers][tests needed] Weird warning about sink context in loop phaser
Geth roast: 9b0c91a9c7 | (Stoned Elipot)++ | S02-types/baghash.t
Test BagHash.pick/pickpairs/grab/grabpairs(Callable)
roast: 9de1408d44 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | S02-types/baghash.t
Merge pull request #668 from Raku/baghash-picky-grabby-callable

Test BagHash.pick/pickpairs/grab/grabpairs(Callable)
roast: 062d1dbadc | (Zoffix Znet)++ | S12-subset/subtypes.t
Improve where &-sigiled tests

  * Fix erroneous test github.com/Raku/roast/pull/677#dis...r498638109
  * Add multi dispatch tests
  * Add tests with Block and Whatever values in variable		 21:33
roast: 7b21ebfdd6 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | S12-subset/subtypes.t
Merge pull request #678 from zoffixznet/hacktoberfest-where-sub2

Improve where &-sigiled tests
roast: a8a52bf485 | (Elizabeth Mattijsen)++ | S04-phasers/in-loop.t
Add missing 'use lib'
 21:41
rakudo: 12946210ea | (Daniel Green)++ | src/core.c/CompUnit/PrecompilationStore/File.pm6
Fix possible race in multi-threaded precompilation

by changing $!lock-count to an atomicint and using atomic operations to interact with it. This code used to be inside a `.protect` call (and so didn't need to be atomic), but that was removed in ac87ea2ac84883bf701808485ac2da887f7496ed for other reasons.		 21:55
rakudo: acd95d7d41 | MasterDuke17++ (committed using GitHub Web editor) | src/core.c/CompUnit/PrecompilationStore/File.pm6
Merge pull request #3741 from MasterDuke17/fix_possible_race_in_multi_threaded_precompilation

Fix possible race in multi-threaded precompilation
23:08 leont 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!