03:15 lucasb left 04:52 tyil left 04:53 raku-bridge left 04:54 raku-bridge joined, raku-bridge left, raku-bridge joined, raku-bridge1 joined, raku-bridge1 left, raku-bridge1 joined 04:55 Geth_ joined 04:58 raku-bridge left, raku-bridge1 is now known as raku-bridge 05:00 maggotbrain left 05:07 raku-bridge1 joined 05:10 Geth left 05:12 tyilanmenyn joined, raku-bridge1 left 05:24 Geth joined 05:28 raku-bridge2 joined, raku-bridge2 left, raku-bridge2 joined 05:33 raku-bridge2 left 05:37 raku-bridge3 joined, raku-bridge3 left, raku-bridge3 joined 05:39 raku-bridge3 left 05:40 raku-bridge4 joined, raku-bridge4 left, raku-bridge4 joined 05:41 tyildesu joined 06:17 tyilanmenyn is now known as tyil 07:09 [Tux] left 07:17 [Tux] joined 07:36 JJMerelo joined 07:48 sena_kun joined
Geth_ rakudo/JJ-patch-1: 11afa53b32 | (Juan Julián Merelo Guervós)++ (committed using GitHub Web editor) | src/Perl6/Compiler.nqp
Add read-from-input option, closes #3743
 07:51
rakudo: JJ++ created pull request #3744:
Add read-from-input option, closes #3743
linkable6 RAKUDO#3743 [open]: github.com/rakudo/rakudo/issues/3743 Behavior of (raku -) command
JJMerelo .tell patrickb what's with these pipeline errors? dev.azure.com/Rakudo/rakudo/_build...02&l=9 08:00
tellable6 JJMerelo, I'll pass your message to patrickb
08:09 Altai-man_ joined 08:12 sena_kun left
Altai-man_ .tell MasterDuke the blin problem is still here with the patch suggested yesterday. 08:30
tellable6 Altai-man_, I'll pass your message to MasterDuke
lizmat Files=1306, Tests=111376, 215 wallclock secs (28.97 usr 8.27 sys + 3012.17 cusr 281.46 csys = 3330.87 CPU) 08:34
Geth_ rakudo: 999d04aae5 | (Elizabeth Mattijsen)++ | src/core.c/IO/Handle.pm6
Don't check whether to actually close when calling .close

61046d7695615d67 unified some logic regarding closing of file handles. Unfortunately, that broke the semantics regarding .lock/.unlock, specifically wrt closing a locked file. Fixed by undoing the unification of that logoc: only DESTROY will now not close an open handle if it was told not to do so. An explicit call to .close will *always* close the file handle. Spotted by ugexe++. Fixes #3742		 08:57
linkable6 RAKUDO#3742 [closed]: github.com/rakudo/rakudo/issues/3742 New IO::Handle auto-closing logic is broken
MasterDuke Altai-man_: hm, well i think it's a needed change anyway. but maybe 999d04aae5 fixes it 08:59
linkable6 (2020-06-04) github.com/rakudo/rakudo/commit/999d04aae5 Don't check whether to actually close when calling .close
tellable6 2020-06-04T08:30:24Z #raku-dev <Altai-man_> MasterDuke the blin problem is still here with the patch suggested yesterday.
09:01 JJMerelo left
Altai-man_ Oh, very interesting. 09:01
Geth_ rakudo: 11afa53b32 | (Juan Julián Merelo Guervós)++ (committed using GitHub Web editor) | src/Perl6/Compiler.nqp
Add read-from-input option, closes #3743
 09:03
rakudo: 8509621b41 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Perl6/Compiler.nqp
Merge pull request #3744 from rakudo/JJ-patch-1

Add read-from-input option, closes #3743
linkable6 RAKUDO#3743 [closed]: github.com/rakudo/rakudo/issues/3743 Behavior of (raku -) command
09:12 leont joined
Geth_ nqp: 59c6124d08 | (Elizabeth Mattijsen)++ | src/HLL/Compiler.nqp
Start up REPL if "-" given *and* STDIN is a tty

This mimics the Python behaviour: when started with "-" as the single positional parameter, it will check if STDIN is connected to a terminal. If so, it will start up the REPL, else it will start processing whatever is given on STDIN.		 09:25
rakudo: 83b2a15cd4 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get new "-" behaviour

When you start Raku with "-" as a single positional parameter, it will now check if STDIN is connected to a terminal. If it is, then the REPL will be started, rather than appearing to freeze waiting for the user to enter something and issue an EOF. If STDIN is *not* connected to a terminal, then Raku will read from STDIN and process that as the source of a program.		 09:40
rakudo: 45df9bc423 | (Elizabeth Mattijsen)++ | src/Perl6/Compiler.nqp
Adapt usage to reflect new "-" behaviour
 09:55
09:55 tyildesu left 09:56 tyilanmenyn joined 09:57 zostay left, zostay joined 10:10 sena_kun joined 10:12 Altai-man_ left
lizmat re: stackoverflow.com/questions/621889...3#62192483 10:31
I wonder whether we couldn't use some syntactic sugar for:
BEGIN D.^add_method("speak",C.^find_method("speak"));
method speak is alias-of(C) { } 10:32
jnthn `method speak(|c) { self.C::speak(|c) }` is shorter 10:37
Also, C::speak style dispatches are already quite well optimized 10:38
The capture bit less so, but I'd rather just speed that up than pile on yet more syntax.
[Tux] Rakudo version 2020.05.1-237-g45df9bc42 - MoarVM version 2020.05-28-g2922f3d1a
csv-ip5xs0.824 - 0.891
csv-ip5xs-208.100 - 8.474
csv-parser26.512 - 28.265
csv-test-xs-200.386 - 0.400
test7.579 - 8.483
test-t1.963 - 1.975
test-t --race0.807 - 0.828
test-t-2031.652 - 32.636
test-t-20 --race9.080 - 9.597
 10:45
10:46 lizmat left
jnthn (Also, if we did, `alias-of` is a bit awkward there in that it leaves the question of "what is the method body about"...) 10:50
In principle though, with the capture stuff better optimized, the overhead could inline away 10:51
11:02 lizmat joined
Geth_ rakudo: 8cbd4e47b0 | LLFourn++ | src/Perl6/World.nqp
Fix RT #126759

create a sneaky lexical EXPORTHOW package so if you do:
   use MyDeclarator;
   EVAL 'my-declarator my-class { }'
it will work because my-declarator is available in %*HOW in EVAL		 11:13
rakudo: 3ad8fedf76 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Perl6/World.nqp
Merge pull request #613 from LLFourn/eval_exporthow

Fix RT #126759
jnthn Hm, that's a cute fix 11:21
Hmm...though I wonder if it might accidentally cause a module to leak its EXPORTHOWs 11:24
e.g. if I `use OO::Monitors` in a module M, I get `monitor` available. But if something uses M then it does not get monitor (good since we don't want language tweaks to "escape")
I'm not able to convince myself either way if the PR changes that as a side-effect of its desirable behavior of fixing EVAL 11:25
(I'd try it, but my build is in quite a few pieces...)
Geth_ rakudo: lizmat self-assigned @a[-42..∞]:delete does not work github.com/rakudo/rakudo/issues/3658
a0efef5ead | (Elizabeth Mattijsen)++ | src/Perl6/World.nqp

It broke Inline::Perl5 and probably others such as OO::Monitors. Sorry for the noise.
lizmat jnthn: merging that was a mistake, reverting 11:26
jnthn lizmat: Feel free to assign it to me 11:27
jnthn Did it actaully break OO::Monitors? 11:28
Wow
That I didn't expect
lizmat no, it broke Inline::Perl5 for sure
you want me to assign 3658 to you, or the old RT one ?
jnthn Ah, perhaps due to the leakage I mentioned.
The PR
I have to rework those things a bit in RakuAST anyway 11:29
lizmat I'll assign the #126759 to you then
jnthn Works for me 11:30
lizmat rba: rakudo.org/bugs is a 404 11:34
rt.perl.org has a link to that for "Rakudo Bugs"
perhaps redirect to github.com/rakudo/rakudo/issues ? 11:35
sena_kun lizmat, redirect to rakudo.org/issue-trackers could be better 11:37
lizmat probably, sena_kun++
11:53 leont left 12:05 leont joined 12:09 Altai-man_ joined 12:11 sena_kun left
jnthn back 12:19
12:31 raku-bridge2 joined, raku-bridge2 left, raku-bridge2 joined, MasterDuke left, raku-bridge5 joined, raku-bridge5 left, raku-bridge5 joined, lizmat_ joined 12:32 dogbert11 joined, Kaeipi joined 12:33 nebuchad` joined 12:36 lizmat left, raku-bridge4 left, raku-bridge left, Kaiepi left, nebuchadnezzar left, Geth left, tyil left, sivoais left, dogbert17 left, krunen left, tyildesu joined, sivoais joined, tyildesu left, tyildesu joined, sivoais left, sivoais joined 12:37 raku-bridge2 is now known as raku-bridge, krunen joined 12:49 tyildesu is now known as tyil, lizmat_ is now known as lizmat
Geth_ rakudo/new-disp: de50a36c7e | (Jonathan Worthington)++ | 3 files
Start using dispatcher for return value type check

This does not yet handle the coercions case yet, but otherwise seems to work quite decently. (For now, requires that spesh is disabled, since so far MoarVM doesn't handle spesh with dispatchers.)		 12:57
roast: 8943531beb | (Elizabeth Mattijsen)++ | S32-io/slurp.t
Add tests for R#3566
 13:04
linkable6 R#3566 [open]: github.com/rakudo/rakudo/issues/3566 [tests needed] Unexpected, slurp(:bin) returns type Str
13:09 nebuchad` is now known as nebuchadnezzar
Geth_ ¦ rakudo: lizmat assigned to jnthn Issue Looping sized native typed array is slow github.com/rakudo/rakudo/issues/3532 13:15
rakudo/new-disp: 30c27c71ba | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Start sketching out some more dispatchers
 13:47
13:48 MasterDuke joined 14:06 patrickb joined 14:10 sena_kun joined 14:12 Altai-man_ left 14:29 MasterDuke left
Geth_ rakudo: 4ba70b7a4b | (Elizabeth Mattijsen)++ | src/core.c/Str.pm6
Make constants real code objects with proper sigil

No functional change, but these are needed as actually callable things for some upcoming optimizations		 14:45
15:13 raku-bridge5 left, tyilanmenyn left 15:22 JJMerelo joined, MasterDuke joined 15:33 travis-ci joined
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make constants real code objects with proper sigil 15:33
travis-ci.org/rakudo/rakudo/builds/694681602 github.com/rakudo/rakudo/compare/a...a70b7a4bce
15:33 travis-ci left
Geth_ nqp/new-disp: 358c0de0f8 | (Jonathan Worthington)++ | t/moar/53-dispatch.t
Test basic use of dispatcher-track-attr
 16:00
16:09 Altai-man_ joined 16:12 sena_kun left 16:30 JJMerelo left 17:04 maggotbrain joined 17:15 ShimmerFairy left 17:18 ShimmerFairy joined 17:26 patrickb left 18:10 sena_kun joined 18:12 Altai-man_ left 18:46 lichtkind joined
Geth_ rakudo: 9fe471cf1c | (Christian Bartolomäus)++ | src/core.c/IO/Handle.pm6
Unbreak the JVM and JS build

The referenced variable $openend and method !forget-about-closing are only defined for the MoarVM backend. With 999d04aae5 they were used on other backends, too. This patch should restore the state from 61046d7695^ for the JVM and JS backend.		 19:02
lizmat bartolin++ 19:09
sena_kun lizmat++ MasterDuke++ The issue with locking is fixed! I'm posting a round ticket... 19:11
MasterDuke nice. lizmat++ 19:20
Geth_ rakudo: Altai-man assigned to lizmat Issue Blin 2020.06, round 1 github.com/rakudo/rakudo/issues/3745
496e91663c | (Elizabeth Mattijsen)++ | src/core.c/List.pm6

cross( (1,2,3), (4,5,6), :with(42) ) would die with the perplexing error message: "Unexpected named argument 'with' passed". This is caused by the candidate that *does* accept :with has a Callable constraint on it. And since 42 is not a Callable, that candidate is not selected, so the next candidate is, except for the fact that ... (11 more lines)		 19:31
19:39 squashable6 left 19:40 squashable6 joined
AlexDaniel sena_kun: looks nice 19:43
lizmat except all of the problems seem to be caused by my commits 19:44
I guess that's only fair, since I did produce the most commits since the last release :-)
19:44 squashable6 left
bartolin_ lizmat++ :) 19:45
19:45 squashable6 joined
20:09 Altai-man_ joined 20:11 sena_kun left
nine Oh, so much progress :) I finally got past my issue with lexicals. And understand the issue that I was trying to solve in the first place 20:18
lizmat bisectable6: old=2020.02 dir "/tmp", :test(&say) 20:21
bisectable6 lizmat, Bisecting by output (old=2020.02 new=496e916) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/dbe855a5a1ae48bc8f...ecd5c04195 20:22
lizmat, (2020-02-22) github.com/rakudo/rakudo/commit/63...e424460bca
lizmat bisectable6: old=2020.05 dir "/tmp", :test(&say)
bisectable6 lizmat, Bisecting by output (old=2020.05 new=496e916) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/adbda37525a7e1644c...68df7ebba7
lizmat, (2020-05-03) github.com/rakudo/rakudo/commit/2b...a48530fc19
lizmat clearly that's not working :-( 20:23
bisectable6: old=2020.05 dir "/tmp", :test( { die if $_ eq "." } )
bisectable6 lizmat, On both starting points (old=2020.05 new=496e916) the exit code is 1 and the output is identical as well
lizmat, Output on both points: «Died␤ in block <unit> at /tmp/cJwhz6xrCE line 1␤␤»
lizmat bisectable6: old=2020.02 dir "/tmp", :test( { die if $_ eq "." } ) 20:24
bisectable6 lizmat, On both starting points (old=2020.02 new=496e916) the exit code is 1 and the output is identical as well
lizmat, Output on both points: «Died␤ in block <unit> at /tmp/7_uBc97Uj9 line 1␤␤»
lizmat bisectable6: old=2020.05 dd "/proc/cpuinfo".IO.slurp 20:29
bisectable6 lizmat, Bisecting by output (old=2020.05 new=496e916) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/3568748241006fa63f...c3b1c10872
lizmat, (2020-05-03) github.com/rakudo/rakudo/commit/2b...a48530fc19
lizmat m: dd "/proc/cpuinfo".IO.slurp 20:30
camelia ""
lizmat m: dd "/proc/cpuinfo".IO.lines
camelia ("processor\t: 0", "vendor_id\t: GenuineIntel", "cpu family\t: 6", "model\t\t: 6", "model name\t: QEMU Virtual CPU version 2.1.0", "stepping\t: 3", "microcode\t: 0x1", "cpu MHz\t\t: 3411.482", "cache size\t: 4096 KB", "physical id\t: 0", "siblings\t: …
lizmat m: dd "/proc/cpuinfo".IO.e 20:32
camelia Bool::True
Geth_ rakudo/new-disp: 4e9fe020dd | (Jonathan Worthington)++ | 2 files
Move to a dispatcher for return value decont

Instead of the spesh plugin. Has almost all the functionality, missing only the v6.c rw/Proxy bug compatibility.		 20:48
nine So, to give code objects created by BEGIN time EVAL access to the setting, I need to add a load_setting call and forceouterctx. These go into a deserialization frame. I now share these between nested compilers, so they actually get used. But this also causes the outer's tasks to leak in. 20:52
And then an EVAL tries to forceouterctx with a block that's not finished compiling yet 20:53
So I must not share the list but add the inner's task to the outer's when done
Same as with the frames list (which is why I got those lexical errors)
jnthn nine: Hmm, how does the BEGIN-time EVAL get to see symbols that are declared in the scope of the BEGIN block? 20:58
Uh, that was unclear. I mean the scopes between the setting and the BEGIN?
class C { }; BEGIN EVAL 'C.new'
Well, the C is a WVal so it's a bad example maybe... 20:59
nine jnthn: EVAL does a forceouterctx 21:01
But that only works at runtime. Doesn't do much good for BEGIN EVAL 'sub foo() { say "yes" }'
jnthn Indeed
I mean more like `sub foo() { "hello " }; my &x = BEGIN EVAL 'sub bar() { say foo() ~ "world" }'; x() 21:03
`
nine So I now know how to solve making the setting available. Not so sure about an outer context as like I said, that's not even compiled at that time
jnthn Yeah, that's the thorny issue :S
nine I guess that'd require defering compilation of that deserialize frame to the very end
jnthn Well, it's either that, or we have to look a bit deeper to if we're missing a primitive. 21:04
I mean, it'd be nice if we could let the runtime (and serialization) know about scopes we're going to be compiling later, but we ain't done with yet. 21:05
Then when we do compile them later, it's "filling in" the thing we promised with an implementation.
That's kinda-ish what the whole markcodestub (iirc) thing was trying to achieve but...maybe it's not sufficient. 21:06
nine Or in between. compile_node(QAST::BVal $bv, :$want) could just not die in case it doesn't find the corresponding mast_frame, but instead take a note of the place in the bytecode where it wanted to store the reference and put it into a list for filling later 21:07
jnthn Hm, intersting.
nine Compared to the whole SubBuffer dance I had to do for compiling frames in the first place, that sounds downright trivial 21:11
Oh, and we already have exactly the same case with labels. Which often are referenced before they actually put into the bytecode 21:12
jnthn I've been starting to ponder this space a bit, 'cus the RakuAST work is going to end up touching on all these bits too
(So I'm really glad I've got somebody to ask who understands how it works today :)) 21:14
There's a few things I'd really like to try and get rid of, including the double-compilation of role bodies 21:15
And the massive fake outer frame that we build up when doing a BEGIN that has All The Things in it
I'm sure there's at least 10% of CORE.setting compilation time reduction to be had on that 21:16
Geth_ rakudo: cde948aee0 | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Fix IO::Path.slurp for special files

If a file claimed it only had 0 bytes, then no attempt would be made to actually read from that file. This semantic however broke the Linux::Cpuinfo module in the ecosystem, because that is trying to read the /proc/cpuinfo special file that does not claim to consist of any data.
Now, if a file claims to have 0 bytes, then it will be read in 1M increments until it produces less than that. This should fix Linux::Cpuinfo, but alas, cannot verify as committer is on MacOS.		 21:17
lizmat afk& 21:20
nine jnthn: yeah, I've wondered how long I'll be able to work in this space before I've got to rethink that All The Things frame. So far I got away with just a minor adjustment 21:22
MasterDuke oooo, potential 10% reduction in CORE.setting compilation time!!! nice 21:33
22:10 sena_kun joined 22:12 Altai-man_ left 22:35 zostay left 22:36 chansen_ left 22:37 tbrowder left, SmokeMachine left 22:38 chansen_ joined, SmokeMachine joined 22:39 tbrowder joined 22:40 zostay joined 23:26 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!