|
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 3 May 2017. |
|||
|
01:50
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 | ||
|
03:19
Zoffix joined
07:32
domidumont joined
07:38
domidumont joined
07:45
domidumont joined
|
|||
| ugexe | nine: any suggestions on how to hunt down a precomp getting stuck trying to precompile Foo.pm6 into whatever.bc ? | 14:18 | |
| I was able to remove all logic in the pm files and have just `use XXX`, and seemed like `use Zef; use Foo; use Bar;` (where use Foo and Bar both use Zef) would only work if i removed one of Foo or Bar | 14:21 | ||
| although RAKUDO_MODULE_DEBUG never mentions these modules, just the initial module that is loaded | |||
| so i'm not sure what to do to get more useful information at this point | 14:22 | ||
| note that i'm talking about a modified zef causing this, not some recent rakudo change causing a normal zef to break | 14:23 | ||
| nine | ugexe: is it stuck with no CPU load? | 14:25 | |
| ugexe | ah it *is* pegging the cpu | 14:27 | |
| ...all night in fact | |||
| nine | Odd. Usually when precompilation gets stuck it's because too much output on STDERR. But then everything just stops and waits. | 14:29 | |
| Anyway you could still comment all handling of err in CompUnit::PrecompilationRepository::precompile to get a live view of STDERR | |||
| ugexe | gist.github.com/ugexe/80326e62033d...7b2d156912 fwiw | ||
| also worth noting that while it freezes on Zef::Client, Zef::CLI or any other Zef::* seems to work (probably due to the `use ...` statements) | 14:30 | ||
| s/work/freeze as well/ | |||
| nine | Oh wait. It may still be the STDERR thing. I'm not sure anymore about it using CPU or not in that case. I think actually moarvm runs some busy loop in that case. | 14:31 | |
| So yes, please remove the :err from run and the couple of lines dealing with .err below | 14:32 | ||
| ugexe | and doing this is for debug output yes? | ||
| nine | Like this: gist.github.com/niner/18b84e2f298a...d1fc8d5b9b | ||
| Well if it is the STDERR issue, you'll at least see the error that's causing the hang. | 14:33 | ||
| ugexe | hmm it actually is not encountering this problem on a linux workstation (previously I was on OSX) | 14:46 | |
| i'll have to try that edit later (just did it to rakudo on linux but I didn't need to :/) | 14:48 | ||
|
15:10
hoelzro joined
|
|||
| ugexe | nine: So it definitely seems OSX specific. On linux my problem doesn't happen at all. On OSX it doesn't happen *if* I apply the patch you gave me (I see no sign of an error) | 15:20 | |
| i wonder if its this weird proc bug where you have to do like `my @out = $proc.out.lines; my @err = $proc.err.lines; $proc.out.close unless +@err; $proc.err.close;` | 15:28 | ||
| Zoffix | Is it filed? | 15:29 | |
| ugexe | i believe so, but no idea where. it would be over a year old at this point | 15:30 | |
| everything I know about it anymore is summed up in these 8 lines github.com/ugexe/zef/blob/master/l...6#L97-L104 | 15:32 | ||
| Zoffix | So you never close the .out pipe if you got anything on STDERR? :S | 15:33 | |
| ugexe | it would error if you did | ||
| on osx or windows | |||
| Zoffix | but not on linux? | ||
| ugexe | right | ||
| that or above meaning i dont remember if it was osx *or* windows | 15:34 | ||
| Zoffix | Can't repro any issues on Win7 with 2017.04 Star with this: perl6 -e "with run $*EXECUTABLE, q|-e|, q|note 42; say 42;q|, :err, :out { @ = .out.lines: :close; @ = .err.lines: :close; }; say q|All good|" | 15:36 | |
| And tried explicit .close calls along with changing what gets printed first STDERR or STDOUT | |||
| oh there's an error in code it's running | 15:37 | ||
| Nope. No luck reproing | |||
|
15:38
ZofBot joined
|
|||
| ugexe | it depended the contents of :out and :err as well | 16:12 | |
| but if this really is related to my current issue it would be osx | 16:16 | ||
| cant think of any reason why osx would behave differently in this respect though | 16:18 | ||
|
16:31
ribasushi joined
16:55
awwaiid joined
19:27
perlpilot joined
21:35
sivoais joined
22:41
stmuk joined
|
|||