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