Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
00:22 pamplemousse left 00:59 ufobat_ joined 01:02 ufobat left 01:22 epony joined 04:55 pamplemousse joined
Geth rakudo: voldenet++ created pull request #3074:
Try fixing closed handle operations error		 05:22
05:43 Voldenet joined, pamplemousse left 05:53 pamplemousse_ joined 06:08 pamplemousse_ left 08:38 rfold joined
rfold Is it normal for AppVeyor builds to fail? 08:54
AlexDaniel rfold: no, but there's a ticket 08:58
rfold: github.com/rakudo/rakudo/issues/3071
rfold Thanks.
AlexDaniel t\04-nativecall\06-struct.t was fixed recently and should no longer fail
09:19 rfold is now known as chloekek, chloekek left 09:20 chloekek joined 09:47 chloekek left 09:55 Voldenet left 10:00 Voldenet joined, Voldenet left, Voldenet joined
[Tux] Rakudo version 2019.07-83-gcde40557d - MoarVM version 2019.07-17-ga7563e71b
csv-ip5xs0.685 - 0.696
csv-ip5xs-205.418 - 5.459
csv-parser23.315 - 23.324
csv-test-xs-200.428 - 0.452
test7.216 - 7.584
test-t1.835 - 1.860
test-t --race0.909 - 0.924
test-t-2029.575 - 30.080
test-t-20 --race9.647 - 9.690
 11:23
11:24 chloekek joined 11:27 robertle joined 11:47 MasterDuke joined
Geth rakudo: 7cab810bce | Chloé++ | src/Perl6/Grammar.nqp
Clear signature before parsing block

If we do not do this then the block takes on the signature of the enclosing routine, leaking %*SIG_INFO<returns> into the block and causing the block to return any declared return value of the enclosing sub.
  See also: github.com/rakudo/rakudo/issues/3070.		 12:05
rakudo: 9b183ccd51 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/Perl6/Grammar.nqp
Merge pull request #3072 from chloekek/3070-interpolate-block

Clear signature before parsing block
¦ rakudo: patzim self-assigned Windows CI test failures github.com/rakudo/rakudo/issues/3071 12:08
13:00 pamplemousse joined 13:18 MasterDuke left
Geth roast: 71bd86d058 | Chloé++ | S02-literals/string-interpolation.t
Test block interpolation in routine with signature-declared return value

  github.com/rakudo/rakudo/issues/3070		 13:35
roast: 0d4f972753 | (Jonathan Worthington)++ (committed using GitHub Web editor) | S02-literals/string-interpolation.t
Merge pull request #562 from chloekek/3070-interpolate-block

Test block interpolation in routine with signature-declared return value
13:51 lucasb joined
lizmat Files=1268, Tests=108559, 193 wallclock secs (26.68 usr 7.96 sys + 2706.23 cusr 253.61 csys = 2994.48 CPU) 14:10
nine When looking through my code I found that the special candidates for calls on P5 methods with 0 and 1 args in fact still had the memory leak issue. That's why I lost only ~ 15 % performance. After fixing them it was closer to 50 %. 14:48
I could recover some of that and am now at ~ 30 % loss. But it's at least much correcter than before.
Much of the lost time is now spent putting objects into the ObjectKeeper (which stores them in an array, so they won't be GC'd when they are only referenced by P5 code) 14:49
I wonder if it'd be worth to investigate some mechanism where the VM takes over this job. Some other NativeCall code will have the same issue. 14:51
jnthn Or work out how to make "put it in an array" faster :) 14:59
nine I was able to speed it up a bit, but there's limits considering how little code it it: github.com/niner/Inline-Perl5/blob...Keeper.pm6 15:05
15:35 pamplemousse left 16:06 pamplemousse joined
jnthn nine: You may bind BIND-POS faster than ASSIGN-POS 16:49
uh, find :)
nine jnthn: yes a bit. But I need an nqp::decont to not bind $!last_free's container and that's not a guaranteed API 17:01
timotimo you can put a postfix <> to decont 17:02
nine Huh....for some reason the <> makes it super slow 17:07
timotimo huh
nine Yeah, that just cannot be fast: multi sub postcircumfix:<{ }>(Mu \SELF, *%other ) is raw { %other ?? SELF.ZEN-KEY(|%other) !! nqp::decont(SELF) } 17:15
timotimo oh wow 17:18
nine Though all ZEN-KEY does is throw an exception 17:51
Geth ¦ problem-solving: AlexDaniel assigned to jnthn Issue No way of having new versions of CORE classes for new language revisions github.com/perl6/problem-solving/issues/71 18:42
¦ problem-solving: AlexDaniel self-assigned Ecosystem: versioning issues github.com/perl6/problem-solving/issues/72 18:43
¦ problem-solving: AlexDaniel self-assigned Official release of Perl 6 implementation github.com/perl6/problem-solving/issues/70 18:44
¦ problem-solving: AlexDaniel assigned to jnthn Issue Status of the POD6 implementation github.com/perl6/problem-solving/issues/69
TreyHarris Writing up the new issue GitHub templates for perl6/doc: where do we want to send people who have language issues? People often create doc issues asking for things to work differently, and I think a bit of text may help reduce that. I don't expect people to know whether it's a rakudo thing or a problem-solving thing or a p6-l thing... suggest they come here or to #perl6? 19:06
OTOH, docs could continue to serve as a sort of triage...
Geth ¦ problem-solving: AlexDaniel assigned to jnthn Issue One more approach for EXPORT problems. github.com/perl6/problem-solving/issues/74 19:28
19:50 pamplemousse_ joined 19:53 pamplemousse left 19:59 MasterDuke joined
[Coke] perl6-dev is for people working on perl6, so I'd pick #perl6 20:34
21:04 robertle left 21:28 chloekek left
Kaiepi i finished a basic implementation of creating IO::Handle instances with fds, but i can't decide whether to pullreq it as-is or pullreq it after i implement IO::FileDesc as an abstraction for fds for IO::Socket::INET and IO::Socket::Async to use as well later on once my networking grant work gets fully underway 21:52
IO::FileDesc would make the code look a bit cleaner the way it is now, but it's not entirely necessary 21:53
yet
22:04 MasterDuke left
Kaiepi actually i probably should write IO::FileDesc now so IO::Handle can have just one $!fh attribute instead of having both $!path and $!fd and having to check whether or not $!path is defined everywhere it's used 22:05
jnthn Would IO::FileDesc be a role done by things that can provide (or be constructed with?) a file descriptor? 22:09
Kaiepi i was thinking it'd work more like IO::Path 22:14
ugexe seems like the ideal solution would unite existing solutions or act as a base towards that 22:17
it would be sad to have IO::Path and IO::Whatever overlapping infunctionality since IO::Path and IO::Handle already largely do 22:18
jnthn Kaiepi: Ah, I think I see
ugexe so maybe something IO::Handle inherits from?
TreyHarris I thought IO::Path and IO::Handle overlap functionality purposefully because what you can do with a file with or without opening it differs so widely from system to system that those things should be in both 22:20
ugexe IO::Handle is pretty tightly coupled to IO::Path. Its hard to make it do anything useful with a handle not backed by a file path 22:21
I would have liked an IO::Handle that both IO::Path and IO::Socket could inherit from 22:22
Kaiepi there could be an IO::FileHandle role done by IO::Special, IO::Path, and potentially IO::FileDesc, etc. that'd implement the methods they share
or something like that, the name sucks with IO::Handle around 22:23
ugexe yeah
TreyHarris It's messy, but it seems to avoid the knots Python 3 ties itself into in order to present paths and files and I/O channels in a consistent way 22:24
It's one of the few areas I prefer Python 2 to 3
ugexe we should remember that new-io never made it into 6.c because of bus factor. the current IO system wasn't some super duper design 22:25
never forget the theoretical IO::File.uri("file://...") would would include a way to plug in additional handlers based on scheme 22:40
everything else is pluggable... 22:41
23:21 pamplemousse_ 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!