Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2017-05-08

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 lizmat joined #perl6-toolchain
01:49 ilbot3 joined #perl6-toolchain
01:49 Topic for #perl6-toolchain is now Fire is step THREE! | https://github.com/perl6/toolchain-bikeshed | Channel logs: http://irclog.perlgeek.de/perl6-toolchain/today | useful prior art: https://metacpan.org/pod/CPAN::Meta::Spec
04:24 lizmat joined #perl6-toolchain
06:08 lizmat joined #perl6-toolchain
06:19 Zoffix joined #perl6-toolchain
06:49 domidumont joined #perl6-toolchain
06:54 domidumont joined #perl6-toolchain
07:52 lizmat joined #perl6-toolchain
10:00 stmuk joined #perl6-toolchain
12:09 stmuk_ joined #perl6-toolchain
13:59 ugexe nine: thoughts on using Proc::Async for that precompile problem area? The big drawback I know of is it doesn't exist on the jvm yet
14:01 ugexe another (shit) way would be to remove :err on that proc, and capture stderr via `$*ERR = class :: { method print { ... } }; run ...; $*ERR = $orig-err;`
14:03 llfourn ugexe: I was thinking the same thing earlier. Read from Proc::Async so the hangining thing doesn't happen :).
14:03 llfourn would also allow us to print ERR as it happens
14:03 llfourn rahter than waiting till it's done
14:04 llfourn fyi Proc::Async is kinda goofy on OSX and F'BSD
14:04 llfourn at least last time I checked.
14:05 llfourn have to sleep 0.1 to work around it: https://github.com/spitsh/spitsh/blob/master/lib/Spit/cli.pm6#L360
14:06 llfourn but that's only when .write()'ing to it which I don't think you're planning to do come to think of it.
14:06 ugexe when zef was concurrent I had problems on OSX too, but I thought that was due to Proc::Async just being Proc + start and the related OSX await bugs (that have been fixed I think)
14:07 llfourn yeah I think some things have improved but the .write being ignored unless you manually yield by sleeping is still there I think.
14:09 ugexe that seems like an easy bug to fix at first glance though... e.g. your gist means that the write is still happening when .close-stdin is called (and finished) right?
14:10 nine ugexe: I wonder why we need to capture stderr at all
14:10 ugexe nine: its used for RAKUDO_MODULE_DEBUG at least, but other than that yeah Im not aware of any reason
14:11 llfourn ugexe: could be.
14:11 llfourn and compile time errors?
14:12 nine Commit 4f338014ae which introduced the capturing talks about not showing module compile errors twice. I can faintly remember something like that but don't see a reason why the previous could would have displayed them twice.
14:13 ugexe ah yeah. i was thinking VERBATIM-EXCEPTION or whatever turned that to stdout, but it just strips part of the exception
14:13 ugexe nine: my pr actually reintroduced that
14:13 ugexe https://github.com/rakudo/rakudo/pull/1076/files#diff-c97d8fc8b5978ba87f7f726ed9cc28a4R279 # removing this line got rid of the dupe
14:15 ugexe but i could not figure out why it happened before or after either
14:16 llfourn isn't it because if precomp fails you fallback to non-precomp which will print the same error?
14:16 ugexe its like... the precompiling process dies with an exception that gets printed to STDERR. The process that was trying to precompile gets the STDERR from the failed precompile process and prints it out for the user to see
14:17 * llfourn &
15:46 tadzik joined #perl6-toolchain
16:14 domidumont joined #perl6-toolchain
17:13 tbrowder joined #perl6-toolchain
18:01 lizmat joined #perl6-toolchain
22:33 lizmat_ joined #perl6-toolchain
23:39 SmokeMachine joined #perl6-toolchain

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary