travis-ci Rakudo build errored. lizmat 'Merge pull request #852 from awwaiid/repl-simplify-catching 05:54
travis-ci.org/rakudo/rakudo/builds/155479040 github.com/rakudo/rakudo/compare/7...294e94d646
buggable ☠ [travis build above] One job failed but NOT due to the timeout.
lizmat "No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself." 05:56
sounds like timeout to me 05:57
afk& 06:57
nebuchadnezzar hello 09:40
timotimo greetings
nebuchadnezzar maybe this chan is the good place to speak about tests hangs during rakudo build on arm64? 09:41
timotimo sounds good 09:42
nebuchadnezzar dod made some tests on an arm64 box: lists.alioth.debian.org/pipermail/...00914.html
timotimo can you ask them to try a moar with libffi instead of dyncall? 09:50
nebuchadnezzar ho, libffi was only use on mipsel 09:52
timotimo hm?
nebuchadnezzar timotimo: I'm asking 09:53
timotimo i can't parse that question 09:54
nebuchadnezzar sorry, it was not a question, I was thinking loudly with my fingers ;-) 09:55
we just need to pass --has-libffi at Configure.pl, right?
timotimo i think so
nebuchadnezzar looks like qemu-system-arm could emulate aarch64 09:58
timotimo i didn't know aarch is arm 10:00
nebuchadnezzar it is wiki.debian.org/Arm64Port 10:01
timotimo cool
MasterDuke timotimo: looks like you saw that the Coverity scans are actually up to date 11:12
oops, that would have made more sense in #perl6 11:13
mst timotimo: so, if I was to attempt to write up what our install structure currently looks like, and go from there to what people might want to do instead 11:18
is there an existing place that would make sense to put it?
I'm tempted to go for a forkable public gist tbh
timotimo that sounds sensible to me 11:19
mst I'm a trifle sleep deprived atm so am -thinking- about it but probably not going to manage to write anything down today 11:34
except maybe some shitty notes in a local text file or something
timotimo i'm also a bit sleep deprived 11:35
mst had a 6.30am flight 11:37
so instead of sleeping I double checked everything and wrote that "how to rakudo" tweet
[Tux] This is Rakudo version 2016.08.1-46-g6a8278c built on MoarVM version 2016.08 15:35
csv-ip5xs 10.494
test 15.739
test-t 8.024
csv-parser 17.138
japhb [Tux]: Any idea what commit slowed it down? 15:53
[Tux] can be a fluke, I'll test again 16:06
S/test/time/ 16:07
dalek kudo/lexical_module_load: eac3d01 | niner++ | src/Perl6/World.nqp:
Fix importing globals nested in imported packages.

Given a diamond shaped dependency tree like A -> N::B, A -> N::C, N::B -> N::D, N::C -> N::D lexical import of N::D into N::B and N::C caused the N namespace to be declared lexically in both import sites. Therefore N::B and N::C got added to the lexically scoped package and missing from the comp units globals.
Fix by upgrading lexicaly scoped packages to full globals when our scoped symbols are added to them.
16:10
[Tux] This is Rakudo version 2016.08.1-46-g6a8278c built on MoarVM version 2016.08
csv-ip5xs 10.306
test 15.384
test-t 7.415
csv-parser 16.441
nine On the airplane I finally got enough quiet time to figure that one out
[Tux] nine++
nine Oh, intriguing question: when use statements are really lexical, should an EVAL in the same scope see the use'd packages? Like: use A; EVAL 'A' 16:24
awwaiid nine: why wouldn't EVAL see A? 16:47
especially if lexical
it can see other lexical vars
awwaiid continues to try to understand ctxsave, $*CTXSAVE, $*MAIN_CTX, ... . Making progress. 17:05
nine awwaiid: oh, you're right. It _can_ see other lexicals. Which makes me wonder why it can't see A 17:13
arnsholt nine: OOC, are we still doing precomp by forking a rakudo subprocess? 18:22