|
Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec Set by moderator on 6 May 2017. |
|||
|
00:00
lizmat joined
01:49
ilbot3 joined
|
|||
| moderator | Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec | ||
|
04:24
lizmat joined
06:08
lizmat joined
06:19
Zoffix joined
06:49
domidumont joined
06:54
domidumont joined
07:52
lizmat joined
10:00
stmuk joined
12:09
stmuk_ joined
|
|||
| 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 | 13:59 | |
| another (shit) way would be to remove :err on that proc, and capture stderr via `$*ERR = class :: { method print { ... } }; run ...; $*ERR = $orig-err;` | 14:01 | ||
| llfourn | ugexe: I was thinking the same thing earlier. Read from Proc::Async so the hangining thing doesn't happen :). | 14:03 | |
| would also allow us to print ERR as it happens | |||
| rahter than waiting till it's done | |||
| fyi Proc::Async is kinda goofy on OSX and F'BSD | 14:04 | ||
| at least last time I checked. | |||
| have to sleep 0.1 to work around it: github.com/spitsh/spitsh/blob/mast...i.pm6#L360 | 14:05 | ||
| 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) | ||
| 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:07 | |
| 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:09 | |
| 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 | ||
| llfourn | ugexe: could be. | 14:11 | |
| and compile time errors? | |||
| 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:12 | |
| ugexe | ah yeah. i was thinking VERBATIM-EXCEPTION or whatever turned that to stdout, but it just strips part of the exception | 14:13 | |
| nine: my pr actually reintroduced that | |||
| github.com/rakudo/rakudo/pull/1076...cc28a4R279 # removing this line got rid of the dupe | |||
| but i could not figure out why it happened before or after either | 14:15 | ||
| 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 | ||
| llfourn & | 14:17 | ||
|
15:46
tadzik joined
16:14
domidumont joined
17:13
tbrowder joined
18:01
lizmat joined
22:33
lizmat_ joined
23:39
SmokeMachine joined
|
|||