FROGGS TimToady: you maybe need to make realclean in MoarVM and then a git submodule update 00:00
I can't imagine that it is something else because Ubuntu-ish x86_64 should just work 00:01
00:18 cognominal__ joined
[Coke] jnthn++ 00:48
diakopter TimToady: ping 01:24
TimToady: I've seen a problen like that when there is a conflicting nqp or parrot or something in the path. I'd try it with no p6 stuff in thr path if it is 01:27
01:41 jnap joined
TimToady jnthn: backtrace is at gist.github.com/TimToady/7700634 02:07
diakopter oh ok. 02:13
(yay that it's tracked down that far ;)
TimToady something funny going on with git though 02:15
if I switch to MoarVM and do git checkout master, it says I have something changed and unresolved, lib/MAST/Ops.nqp 02:16
which I dint change
trying to blow away MoarVM and reclone
diakopter sounds like someone did a force push or something 02:20
TimToady if I blow away and --gen-nqp (in nqp's Configure), it fails 02:24
if I --gen-nqp=master, it succeeds
TimToady guesses that nom's --gen-nqp isn't passing down it's option correctly to nqp's Configure 02:25
*its
trying nom's Configure again now that nqp has bootstrapped on moar 02:27
it seems to do a deeply suboptimal amount of work re-genning jvm and parrot backends before attempting moar 02:31
something is badly wrong with our configuration model 02:32
yes, doing --gen-moar from nom level breaks again; only cd nqp; perl Configure.pl --gen-moar=master fixes it 02:35
despite the fact that after the first, it thinks it's on master, and shows no diffs
TimToady scratches brane
TimToady will try the top level with --with instead this time 02:36
actually, just trying with only --backends now, and maybe it'll use everything nqp put together 02:38
02:39 BenGoldberg joined
TimToady the makefile seems to know how to build perl6-j, so that's a hopeful sign... 02:39
nope, doesn't find nqp-m, it's in nqp's install direction, not nom's 02:48
going back to rebuilding nqp with: perl Configure.pl --gen-moar=master --prefix=../install 02:51
after blowing away MoarVM again, because it segvs again 02:52
and of course, if you pass a --prefix to nqp's Configure, it doesn't add a .. to moar's prefix 02:54
lesson: don't use relative paths in prefix?
crumb, failed compiling BOOTSTRAP, moar: 3rdparty/libuv/src/unix/loop.c:150: uv__loop_delete: Assertion `!((((*(&(loop)->active_reqs))[0]) == (&(loop)->active_reqs)) == 0)' failed. 03:08
lue TimToady: ISTR getting that error a while back. If memory serves, that's not the source of the error. 03:11
TimToady vaguely recalls reading that too
lue tries the rakudo-moar process 03:12
03:13 colomon joined
TimToady first tries a make clean 03:14
duh, never did a git pull to get jnthn++'s fix, I think 03:27
nope, still fails to compile m-BOOTSTRAP 03:31
FROGGS++ was talking about m-BOOTSTRAP at irclog.perlgeek.de/moarvm/2013-11-26#i_7916795 but I don't know if that's germaine 03:37
okay, can't think of anything else, so here's the gist: gist.github.com/TimToady/7701310 03:46
04:16 colomon joined 04:28 woosley joined 05:40 BenGoldberg joined 06:11 ssutch joined
FROGGS TimToady: can you paste rakudo's Makefile? because that message is weird: failed to load library 'dynext/' 07:24
I guess your lines are different to these: 07:26
M_PERL6_OPS_DIR = dynext
M_PERL6_OPS_DLL = $(M_PERL6_OPS_DIR)/libperl6_ops_moar.so
nqp-m: say(nqp::backendconfig<dll>) 07:27
camelia nqp-moarvm: OUTPUT«lib%s.so␤»
FROGGS do you get that?
TimToady sec 07:29
gist.github.com/TimToady/7702585 07:30
lib%s.so 07:31
FROGGS okay, so I think it is either rakudo's Configure.pl's fault, or we have a problem spitting out nqp-m --dump-config again 07:36
what is your nqp-m --show-config | wc 07:37
jnthn morning o/ 07:47
FROGGS morning jnthn 07:48
jnthn So....what am I teaching today...
FROGGS jnthn: just ask your students how much they know about the topic and in what they are interested most :o) 07:50
jnthn :) 07:51
Seems that today we'll be adding shiny Ajax-powered stuff to our demo app (which is actually a beer review website) and conducting CSRF exploits...then hopefully fixing them. :) 07:53
FROGGS who had that website idea? :P 07:54
jnthn The course material author, apparently :P 07:55
FROGGS hmmm, why can I now close filehandles now again? it crashed last time badly...
hehe
:o)
ahh no, when I close stdhandles, the it is all fine in a test script after nqp was built, but I can't build nqp nor rakudo 07:57
TimToady I get 117 336 8685 08:06
jnthn bbiab &
nwc10 I get 08:50
Stage mbc : 1.980
and then the assertion abort from libuv
this is expected? And why is libuv still upset? 08:51
FROGGS TimToady: that is alright 08:52
would be interesting to know what happens here: 08:53
rakudo/Configure.pl:236: $config{'perl6_ops_dll'} = sprintf($nqp_config{'moar::dll'}, 'perl6_ops_moar'); 08:54
jnthn nwc10: Not sure on the libuv thing. I've been hoping somebody else will take care of it, but maybe I'll have to take a look at it sometime soon...
FROGGS nwc10: libuv is upset because there are unclosed and not cleaned up filehandles flying around... (from printing stagestats to stderr) 08:55
jnthn FROGGS: But don't they get cleaned up in global destruction? 08:56
FROGGS jnthn: no
see github.com/MoarVM/MoarVM/blob/mast...ndle.c#L48
jnthn: if I walk the filehandles in tc_destroy, and do the same magic as in the linked section, it still blows up 08:57
I mean, I still can't build nqp or rakudo
jnthn Hmm 08:58
FROGGS it is like we need to distinguish between stdhandles in user code and nqp/rakudo build code
jnthn We shouldn't need to do that...just need to be a bit more careful over lifetime management of them, I'd guess. 09:05
FROGGS hmmmm 09:08
:/
nwc10 I'm not *sure*. You both might be right. Or I might be teapot, or something 09:11
but there is this fun with "embedding" where "you" (the embedded program) don't own stdin, stdout, stderr
and you need to avoid closing them, unless the user program code explicitly told you to
the real quote is "If that's justice, then I'm a banana" -- news.bbc.co.uk/onthisday/hi/dates/s...503595.stm 09:12
but it doesn't an HTTP status code
(and gosh, Ian Hislop looks young in that photo) 09:13
IIRC that page is incomplete - it later turned out that the allegation deemed to be libelous was true
FROGGS nwc10: the current code (HEAD) does not close stdhandles, and this is why libuv explodes when deleting its event loop 09:16
btw:
nqp-m -e 'my $fh := nqp::getstderr; nqp::printfh($fh, "ohh noes!\n")' # explodes
nqp-m -e 'my $fh := nqp::getstderr;' # does not 09:17
when we close the handles (yes, even stderr), both commands do not explode
but this borks building nqp/rakudo
and that is something I dont understand
09:22 retupmoc1 joined 09:35 cxreg joined 10:03 woolfy left 10:07 woosley left 10:09 FROGGS joined
timotimo how far are we getting today? :) 11:04
jnthn Same as when I went to bed last night, I think :) 11:06
timotimo so ... no advance?
or the same amount of advancement as yesterday? :P
jnthn Well, we get to loading the setting and fail around line 500 afaict 11:08
timotimo oh, i worded my question poorly 11:11
i meant: at the end of today, where do you imagine the progress to be? 11:12
jnthn I really dunno 11:15
for me, I got a 4+ hour train journey home. Which sounds productive, but I can't work comfortably on a laptop on a train really...
So it'll be whatever time exists between getting home and needing to sleep :)
nwc10 does the train have beer? If so, is it decent? If so, is it anything other than insanely expensive? 11:16
FROGGS how does it fail actually? I just got a meaningless segfault IIRC
jnthn nwc10: Um...you can't take your own beer on the train. And what they have is probably both expensive and, like, stor stark or some crap... 11:21
nwc10 not that it matters for this question, but is that "you can't take beer onto the train" or "you can't drink your own beer on the train"? 11:23
jnthn uh...the latter :) 11:24
Hadnt' used to be this way
But then I guess stupid people ruined it. 11:25
nwc10 The former would be somewhat crazy.
jnthn aye
nwc10 In that in the UK there is provision for "dry trains" but they really are "no booze anywhere"
(not even carried unopened in the guard's van)
jnthn Who's gonna know if there's a bottle of something in your rucksack,though, if you keep it there? :) 11:26
ok, time to take @class to lunch...
12:09 tgt joined
FROGGS ahh 12:15
I have to twiddle perl6-m's libpath 12:16
TimToady: you have not a single moarvm config item in your generated makefile: gist.github.com/TimToady/7702585#f...1-txt-L985 12:39
I'll test if that is due to your prefix... (mine is nqp/install, and moarvm, nqp and rakudo are on the same directory level) 12:41
nwc10 vagrlind is reporting errors for current HEAD: paste.scsys.co.uk/282100 13:09
er, ex-current HEAD 13:10
I think that that was 66bf730ff695b5fb4c88ea60eb0b77bbf9fa2d0f - Implement SIG_ELEM_DEFAULT_FROM_OUTER.
FROGGS umm, I think I've got a patch for libuv's sadness 13:20
diakopter: ping 13:39
why does that what perl6-m do after stage mbc takes no cpu? 13:47
14:03 tgt joined
FROGGS looks my closing file handle patch is ending in a deadlock :/ 14:18
diakopter pong 14:37
FROGGS diakopter: hi
you remember that I once closed the stdhandles?
what were the problems with that on windows? 14:38
because I am testing a patch that would close all unclosed handles when shutting down
diakopter don't know the specifics
cool 14:39
FROGGS and it seems to work nicely on windows
(and linux)
k
diakopter but the global destruct phase is supposed to do that by calling gc_free on everything
FROGGS then I will commit after a bit more testing
diakopter: that does not seem to work here 14:40
I am closing opened handles in tc_destroy now
diakopter are their gc_free not being run?
FROGGS (right before deleting the libuv loop)
diakopter well it's supposed to clean them via the gc 14:41
FROGGS I think gc_frees got run, but maybe to early in some cases?
diakopter so that should be fixed instead
14:41 tgt joined
FROGGS but this particular thing works in tc_destroy but not in gc_free 14:41
the same code that is 14:42
diakopter what I'm saying is when the destruct phase or gc problem gets fixed, they will be closed then
it doesn't make sense for them to run "too early" 14:43
FROGGS what if you create a stderr fh in your test script that goes out of scope? when will gc_free on it be called? 14:44
damnit, not it hangs again after stage mbc -.- 14:46
s/not/now/
jnthn Once we reach global destruction we run no more code. 14:48
diakopter FROGGS: that's why I said a while ago the standard filehandles need globally created and rooted globally. 14:49
and then jnthn saif the same thing a few weeks later 14:50
jnthn Did we not already do that?
I remember it beign discussed
Not sure if it happened.
diakopter I don't think anyone did it 14:51
FROGGS I tested stashing them, without change in behaviour, so I not committed that patch
diakopter stashing?
FROGGS stashing 14:52
diakopter what is stashing
FROGGS gist.github.com/FROGGS/d245bd7f983e0b5c138f
diakopter can't click links on this phine terminal
jnthn phine is a curious spelling of effing... :P 14:53
diakopter I just wanted to know whether yiur patch rooted them
also, what "behavior" was your patch trying to solve 14:54
jnthn: lololol
FROGGS diakopter: that there is only one filehandle for stderr for example
diakopter oh, that's necessary to enforce too 14:55
jnthn It appears to fail to root them
diakopter wel
well
well then
jnthn Which certainly won't work out well :) 14:56
FROGGS k
retrying
diakopter FROGGS: but thr thing about them not being closed in global destruct is troublong
umless the closing thing in gc_free was removed 14:57
FROGGS diakopter: it was commented out because it caused trouble 14:59
might be related to not perm rooting the handles though
diakopter I'm sure that could be described very differently (without implyong it was that code to blsme) :p 15:00
FROGGS :o)
okay, nqp seems to build atm 15:01
15:03 benabik joined
FROGGS yay, rakudo built until the "cannot invoke null object" and then got stuck after printing the backtrace -.- 15:22
k, "nqp-m -e '1 1'" hangs too after the backtrace 15:24
jnthn aww
jnthn enourages FROGGS to hang on in there... 15:25
FROGGS does not dare to hope 16:17
16:37 FROGGS joined
dalek arVM/hope: 05eaefe | (Tobias Leich)++ | src/ (5 files):
stash and free std filehandles

STDIN, STDOUT and STDERR are created once per instance, and handed out on request. We now clean up all handles but the previously mentioned when gc_free-ing a filehandle.		 17:06
arVM/hope: 5b3efce | (Tobias Leich)++ | src/ (4 files):
msvc does not like names like stdin
 17:13
timotimo "hope" :) 17:16
FROGGS yeah :/ 17:21
would be cool if you could check that out
and rebuild nqp and rakudo or so
timotimo oh, sure thing 17:26
FROGGS that seems to work on windows too 17:31
timotimo i'm up to actions now.
FROGGS timotimo: btw, that libuv error will show up if we panic in moarvm land which does not gc_free the MVMOSFilehandes 17:32
timotimo ah, ok
i remember seeing that panic function show up in a stacktrace
FROGGS but this will only ever occur if we panic anyway, so there will be a proper error message above libuv's 17:33
timotimo yeah
that's acceptable
FROGGS I think so too
atm we die after printing stagestats even when the CORE.setting.moarvm got created successfully
now we get to the "Cannot invoke null object" straight ahead 17:34
do we actually know why it explodes like that? 17:36
timotimo it's about to finish. 17:39
i think i forgot to pass --optimize 17:40
retupmoca . 17:48
timotimo yeah, it does segfault. 17:50
i don't get that message you mentioned, FROGGS
4195926 9,9M -rw-r--r-- 1 timo timo 9,9M Nov 29 18:45 CORE.setting.moarvm
huh, we're still putting base64-encoded stuff into the .moarvm file? 17:51
my xxd just froze... wat? 17:52
17:53 FROGGS[mobile] joined
timotimo however, this is a thing: Unhandled exception: While looking for 'ModuleLoader.moarvm': no such file or directory at <unknown>:1 (perl6.moarvm:frame_name_9:6) 17:56
FROGGS[mobile] did you pull in rakudo too? 18:09
I'd guess you are missing the runner patch
timotimo oh, i didn't pull rakudo 18:13
FROGGS[mobile] Ohh, what a relief 18:27
timotimo Cannot invoke null object 18:28
:)
are the line numbers kind of off? 18:29
FROGGS[mobile] No idea 18:30
timotimo also, can i dump moarvm bytecode to a pretty-printed format easily?
FROGGS[mobile] There was no patch about that afaik
timotimo OK
what's with "frame_name_1901", is that very hard to improve?
diakopter yes
FROGGS[mobile] there is a --dump 18:31
diakopter --dump
timotimo moarvm --dump foo.moarvm?
FROGGS[mobile] Yes
timotimo [1] 14615 segmentation fault (core dumped) moar --dump CORE.setting.moarvm
yeah, it *did* dump
diakopter it may take a dump instead though
yes
FROGGS[mobile] And moar --dump nqp.moarvm -e '...' 18:32
diakopter no
that doesn't dwim
18:53 lizmat joined 19:02 woolfy joined
dalek arVM: 05eaefe | (Tobias Leich)++ | src/ (5 files):
stash and free std filehandles

STDIN, STDOUT and STDERR are created once per instance, and handed out on request. We now clean up all handles but the previously mentioned when gc_free-ing a filehandle.		 19:27
arVM: 5b3efce | (Tobias Leich)++ | src/ (4 files):
msvc does not like names like stdin
FROGGS TimToady: I am trying now to reproduce you bug 19:33
timotimo tee hee 19:40
TimToady: yeah, that's right! you bug!
FROGGS ohh, hehe 19:41
silly me :o)
19:43 ssutch joined
FROGGS hmmm, I dont get that error 19:43
TimToady: you are on MoarVM=master, nqp=master and rakudo=moar-support, right?
and you do something like: perl Configure.pl --backend=parrot,jvm,moar --prefix=/home/larry/nom/install && make m-install 19:44
TimToady I gave a relative prefix, which may be the problem 19:45
FROGGS no, I do that usually 19:46
TimToady I can try it again with an absolute path
19:46 camelia joined
TimToady but you're not doing --gen-moar 19:46
FROGGS I'd like to get the output of rakudo's configure and build then :o)
hmm
true
where is your moarvm repo? 19:47
in the nom folder?
TimToady gen-moar delegates to nqp, which makes nqp/MoarVM
19:47 benabik joined
FROGGS I know... 19:47
okay, I'll try 19:48
ummm, --gen-moar checks out an old version on moar 19:52
of*
TimToady you need --gen-moar=master, but the branch doesn't get through to nqp
FROGGS ahh, yes
20:41 grondilu joined, tgt joined 21:15 cognominal joined
timotimo so, we're basically waiting for nthn to fix repossession? 22:14
FROGGS sort of, yeah 22:15
rp: say 'CREDITS'.IO.m 22:19
camelia rakudo-parrot e5fd34: OUTPUT«No such method 'm' for invocant of type 'IO::Handle'␤ in block at /tmp/XMhNXf3MYb:1␤ in any at /tmp/XMhNXf3MYb:1␤ in any at gen/parrot/stage2/NQPHLL.nqp:1146␤ in any eval at gen/parrot/stage2/NQPHLL.nqp:1133␤ in any evalfiles at gen/par…»
FROGGS rp: say 'CREDITS'.IO.^methods
camelia rakudo-parrot e5fd34: OUTPUT«open close eof get getc lines read seek tell write opened t print slurp spurt copy chmod IO path flush encoding d e f s l r w x z modified accessed changed say Str gist perl <anon> <anon>␤»
FROGGS rp: say 'CREDITS'.IO.modified
camelia rakudo-parrot e5fd34: OUTPUT«stat failed: No such file or directory␤ in method modified at gen/parrot/CORE.setting:12967␤ in block at /tmp/_kqCbGfAXK:1␤ in any at /tmp/_kqCbGfAXK:1␤ in any at gen/parrot/stage2/NQPHLL.nqp:1146␤ in any eval at gen/parrot/stage2/NQPHL…»
timotimo in theory i could just grab a random op that's NYI and implement that 22:25
any suggestions?
FROGGS dunno, p6listiter? 22:26
timotimo didn't i already implement that? 22:35
FROGGS doesnt seem like 22:36
jnthn static void p6listiter(MVMThreadContext *tc) { MVMObject *arr = GET_REG(tc, 2).o; MVMObject *list = GET_REG(tc, 4).o; MVM_exception_throw_adhoc(tc, "p6listiter NYI");
gah, paste fial
Notice the make_listiter that I already wrote, though ;)
You basically just need to call that. :) 22:37
And then shove what it returns into the result register.
Done. :)
timotimo ah, it may be uncommitted or unpushed
indeed. 22:38
that's my implementation. potentially lacks something, but what do i know :)
jnthn Things work just as well on my machine here at home as on my laptop, btw 23:06
FROGGS good to know 23:09
23:10 ssutch joined, tadzik joined
jnthn Will have some tuits tomorrow. 23:13
timotimo \o/
23:23 sricloud joined 23:25 BenGoldberg joined
FROGGS gnight 23:40
jnthn 'night, FROGGS 23:46

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!