Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-01-06

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 timotimo i think so, too
00:00 timotimo maybe adding --ll-exception somewhere woudl help?
00:01 jnthn Yes, that reveals the real causes.
00:57 [Coke] jnthn: ah.
00:57 [Coke] I can change my "check the abort reason" to always include that.
00:59 [Coke] ... with that I get "Junction auto-threading NYI" instead.
00:59 jnthn [Coke]: Yeah, or we could fix it...I'll take a look at that tomorrow.
00:59 [Coke] either is fine. :)
01:00 * timotimo is working "hard" on junction auto-threading :)
01:00 timotimo working hard, in this case, means asking jnthn every step of the way how to continue :P
01:14 [Coke] :(
01:14 [Coke] er, :)
01:15 timotimo and now: a heisenbug
01:15 timotimo nwc10 would enjoy this i bet :P
01:15 timotimo it happens so early in rakudo's compile cycle
01:15 timotimo the bootstrap, not the setting
01:17 jnap joined #moarvm
01:17 timotimo Missing or wrong version of dependency 'src/gen/m-BOOTSTRAP.nqp'  <- wat
01:17 timotimo jnthn: ^ more symptoms of the same heisenbug perhaps?
01:19 jnthn No, that just sounds like a build mess-up...
01:19 timotimo m-bootstrap built without failure. this error came from trying to build Test
01:20 jnthn o.O
01:21 jnthn Did something that depends on m-bootstrap not get re-built?
01:21 timotimo dunno. i did a make clean now
01:21 timotimo and also a moarvm build with --optimize=1 instead of =3
01:25 timotimo got a build now
01:25 timotimo This representation (VMHash) does not support positional access
01:26 timotimo seems like my flattening of the hash didn't work
01:26 timotimo i removed the %(...) around it
01:26 timotimo that must be the cause
01:28 cognominal joined #moarvm
01:29 jnthn Oh, yeah, it doesn't want the %(...) thing
01:29 timotimo another clean install ...
01:30 timotimo i compiled it without a %(...) thing and it failed to flatten it properly
01:31 jnthn Did you include a | ?
01:33 timotimo yes
01:33 timotimo it was |nqp::getnamedshash($capture)
01:33 timotimo er
01:33 timotimo capturenamedshash
01:33 timotimo shush, shash
01:33 jnthn Try bidning what nqp::getnamedshash returns to a hash first
01:33 timotimo still vmhash doesn't support positional access
01:33 timotimo OK
01:33 jnthn And then flattening that in.
01:34 timotimo will do
01:38 timotimo Type check failed in bind; expected Str but got Str
01:38 timotimo a somewhat better error, i guess
01:39 * timotimo force-pushed over the branch, so you can has a look
01:41 jnthn OK...gonna sleep now...will look tomorrow
01:41 timotimo sure :)
01:41 timotimo gnite!
01:41 timotimo i should get some rest, too i think
02:31 ssutch joined #moarvm
02:45 raiph joined #moarvm
04:01 ssutch joined #moarvm
06:52 raiph joined #moarvm
07:48 hoelzro joined #moarvm
07:48 japhb_ joined #moarvm
07:48 rurban joined #moarvm
08:20 FROGGS joined #moarvm
08:21 FROGGS [Coke] / nwc10 / jnthn: when comparing rakudo-moar.summary from 7 days ago and yesterday, I see that the uv__loop_delete assertions are gone on [Coke]++'s machine too
08:23 FROGGS [Coke] / nwc10 / jnthn: so, seems fixed on windows and linux now, but still broken on osx, right nwc10?
08:29 nwc10 IIRC I never actually ran tests on OS X, so I can't answer that conclusively.
08:32 FROGGS nwc10: ohh, and I thought you are developing on an apple
08:32 odc joined #moarvm
08:32 FROGGS nwc10: but that means the assertions are not fixed for you?
08:44 nwc10 I'm physically typing on Apple laptop, which I also tried to build on
08:45 nwc10 but I'm shifting the code over to a beefy Linux box for most things
08:45 nwc10 (just wanted to test build locally)
08:45 nwc10 my mail is on a  FreeBSD machine
08:45 nwc10 and I have access to a reasonable amount of other OSes
08:45 nwc10 (but sadly currently nothing running on Sparc)
08:46 nwc10 (of architectures still in production and widespread deployment)
08:46 FROGGS so, does it still fail on that linux box?
08:46 nwc10 does not seem to (for that reason)
08:47 nwc10 in that I've got a lot of debugging stuff as well, and some of that is failing an assertion now
08:47 nwc10 for which I'd like a jnthn for advice
08:47 FROGGS yeah
08:48 FROGGS if I find my external hdd at home I can probably test on some OSes... I have a snow leopard and some Linuxes/BSDs on it
08:49 nwc10 but currently I'm trying to figure out why a laserjet is printing blank pages
08:49 FROGGS "laser"
08:49 nwc10 as in, laser doesn't?
08:50 nwc10 for anyone (else) trying this at home, it seems that the magic phrase on google is "service manual" to get a PDF of what to take apart
08:50 nwc10 but, sadly, I think that it's more cost effective to buy something new
08:51 FROGGS no... "laser" as in Austin Powers
08:51 * nwc10 certainly isn't skilled to the level of "solder the motherboard"
08:51 nwc10 oh, right
08:51 FROGGS I've got a cheap dell color laser printer (80 Euro), and this thingy is awesome
08:52 FROGGS only up to A4 pages though...
08:52 nwc10 this is an ancient HP 2200 something
08:52 nwc10 only has USB and parallel, and no duplex
08:52 FROGGS my dell has only usb, and no duplex either
08:53 FROGGS I only bought it because that printer was that cheap and the (refilled) colors are too
08:53 nwc10 strange thing is that it looks like it has at least half the mechanism for duplex. The main PCB says "SIMPLEX" which makes me wonder if all ship with the duplex hardware, and the non-duplex ones omit only the control circuitry
08:53 FROGGS but the printed pages look morre than awesome
08:53 FROGGS more*
08:54 nwc10 a bilt like big iron shipping with all the CPUs, but only the ones you pay for are turned on.
08:54 nwc10 do Dell still make this? Does it run with linux?
08:54 FROGGS that is quite possible
08:54 nwc10 it sounds better value than anything Andrea's mother might buy retail
08:54 FROGGS nwc10: it is some xerox 7000 or so under the hood
08:55 FROGGS and yes, it works okay using ubuntu
08:55 nwc10 had to hack at Ubuntu to make it work with this HP.
08:55 FROGGS but I had once porblems with my ubuntu machine and did not get it to print anything... this fixed itself somehow after months
08:55 nwc10 Ubuntu seemed to decide that because the printer could do 1200dpi, and might be colour, it was a great idea to generate colour PS at 1200dpi
08:55 nwc10 printer choked
08:55 FROGGS *g*
08:55 nwc10 OS X seems to default to PCL and 300dpi monochrome
08:56 nwc10 hacked at Ubuntu to do something similar
09:27 masak two-line diff coming up:
09:27 masak -    int len = snprintf(buffer, 64, "%lld", i);
09:27 masak +    int len = snprintf(buffer, 64, "%lld", (long long int)i);
09:27 masak this fixes a cast warning in the build.
09:27 masak can I commit and push that?
09:28 FROGGS +1
09:34 dalek MoarVM: 6a5ca57 | masak++ | src/core/coerce.c:
09:34 dalek MoarVM: fix cast warning
09:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6a5ca57c4a
09:41 masak another two-line diff, this time from 3rdparty/libtommath/bn_error.c
09:41 masak -          return msgs[x].msg;
09:41 masak +          return (char *)msgs[x].msg;
09:41 FROGGS masak: you are going PR it?
09:41 masak it does fix the (last) warning, but I don't know what the policy is for patching third-party code.
09:41 masak I can do that.
09:42 jnthn What type are you casting that from?
09:42 masak jnthn: a const char *
09:42 jnthn ah, ok
09:43 nwc10 jnthn: this inconsistency between frame->params and frame->caller should not happen, should it? http://paste.scsys.co.uk/289748
09:43 nwc10 frame->caller.args and frame->params.args are identical (ie point to same memory) but the arg_count differs
09:44 jnthn nwc10: Um, is frame->params.arg_flags set?
09:44 nwc10 meanwhile, on a different CPU, an NQP build grinds slowly onwards. With a nursery gc run before every allocation.
09:44 FROGGS masak: I don't think he'll except that PR when looking at https://github.com/libtom/libtommath/blob/master/bn_error.c#L35
09:44 nwc10 (gdb) p frame->params.arg_flags
09:44 nwc10 $76 = (MVMCallsiteEntry *) 0x0
09:45 masak FROGGS: s/except/object to/ ?
09:45 FROGGS accept*
09:45 jnthn nwc10: That looks certainly broken...
09:45 nwc10 OK
09:45 masak FROGGS: ...it looks the same as moar does now.
09:45 nwc10 I realise that I can add some code to figure out when that happens
09:45 FROGGS because msg is const cahr * and the function returns const char *
09:46 jnthn nwc10: arg_flags is set when we flattened, but then args can point to some different memory.
09:46 nwc10 I spot it because my existing code to sanity check parameters spots that args[1] is pointing to fromspace
09:46 masak FROGGS: ah, you are right.
09:46 masak FROGGS: I should change the return type instead.
09:46 jnthn nwc10: Yeah, question is how'd we get to 2...
09:46 masak FROGGS++
09:46 nwc10 and I think that the reason is that it's frame->params.args[1]
09:47 nwc10 whereas I'm guessing that frame->caller.args was rooted, and hence only (gdb) p frame->params.arg_flags
09:47 nwc10 $76 = (MVMCallsiteEntry *) 0x0
09:47 nwc10 (bah
09:47 nwc10 )
09:47 nwc10 whereas I'm guessing that frame->caller.args was rooted, and hence only [0]
09:47 nwc10 anyway, I can add different code to work out where they diverged
09:47 jnthn Yeah...I just don't know how we get into such a situation...
09:55 JimmyZ jnthn: ping
09:55 FROGGS jnthn: btw, fixing shell() and run(), it segfaults not in p6decontrv... was my patch wrong? https://gist.github.com/FROGGS/91a9c7cc63efd3d2f587
09:55 FROGGS jnthn: both the bt and my patch is in that gist
09:55 FROGGS hi JimmyZ
09:55 JimmyZ Hi FROGGS
09:57 jnthn STABLE(iterval)->container_spec->fetch(tc, iterval, &r); \
09:57 jnthn Argh, don't do that...
09:57 jnthn What if it's a code_pair like Proxy uses?
09:58 jnthn Then you've got the interpreter pointing at the wrong place.
09:58 jnthn We should fix it to make sure we don't put containerized things into the hash we pass to shell
09:59 JimmyZ jnthn: I got a patch: https://gist.github.com/zhuomingliang/8277298  , beacuse I think set tc->cur_frame->args is unsafe, since cur_frame may have no args. But I think this patch is not thread-safe if there are multi-threads access args[0] and args[1]. I'm not sure which one is  right.
09:59 jnthn Not try to decont in the middle of C code (which you can't do)
10:00 jnthn JimmyZ: It's always safe.
10:00 JimmyZ OK, I don't know why :)
10:00 jnthn JimmyZ: args is always allocated to at least 3 items.
10:01 jnthn Your patch is wrong as args here is stack allocated, but it must live longer than code_pair_[fetch|store]
10:01 jnthn Remember invoke doesn't actually invoke anything. It just sets up the interpreter so when we return to it, it will run the invoked thing.
10:01 FROGGS jnthn: okay, I was thinking about that this night... and yes, that $ENV hash might be better hllized?
10:02 JimmyZ yeah, But I think what about sub() { } , the frame args is zero.
10:02 jnthn JimmyZ: What?
10:02 FROGGS jnthn: like this does it? rakudo-moar/src/Perl6/World.nqp:31:sub p6ize_recursive($x) {
10:02 jnthn Params != args, for one.
10:03 JimmyZ oh
10:03 jnthn FROGGS: Don't we have the opposite problem here?
10:03 FROGGS jnthn: right now we are putting things in the hash using p6box or so
10:04 jnthn Oh, that doesn't matter in so far as a Str unboxes just fine.
10:04 FROGGS jnthn: and I guessed that we do that so these are proper in perl 6 land
10:04 FROGGS ahh, hmmm
10:04 jnthn Yeah, that bit is OK, it's the containers that ain't.
10:04 * JimmyZ decommutes
10:04 FROGGS ahh
10:05 jnthn my Mu $hash := nqp::getattr(%*ENV, EnumMap, '$!storage');
10:06 jnthn That certainly will lead to a hash of containerized things.
10:07 FROGGS umm, why? ó.ò
10:07 jnthn See how it's built in terms.pm - with assignment.
10:07 FROGGS this? %ENV{$key} = nqp::p6box_s(nqp::iterval($envelem));
10:07 jnthn Yeah
10:08 FROGGS okay, this creates containers...
10:08 jnthn Anyway, solution is to make a copy of the hash without the containers.
10:08 jnthn I think most efficient way is to clone it and then iterate, decont'ing each value.
10:08 FROGGS so I'd need to walk the values and bind them to a new nqp::hash?
10:08 jnthn yeah
10:08 FROGGS k
11:01 JimmyZ jnthn: I'm asking because I see https://github.com/MoarVM/MoarVM/blob/master/src/core/frame.c#L176
11:02 dalek MoarVM: 74c3c4a | jnthn++ | src/core/bytecodedump.c:
11:02 dalek MoarVM: Get --dump able to handle extops.
11:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/74c3c4a9e8
11:02 JimmyZ Which may be NULL...
11:02 jnthn JimmyZ: Ah...
11:03 jnthn JimmyZ: I...can't imagine a frame with no registers, though...
11:03 jnthn JimmyZ: That is, if it has none, it can certainly never do a decont op :)
11:04 JimmyZ isn't decont is in next_frame?
11:04 JimmyZ the next frame inovke
11:04 JimmyZ *invoke
11:05 JimmyZ where the store is set cur_frame
11:06 JimmyZ *while
11:14 * jnthn doesn't understand the question...
11:15 jnthn All the calls back into the interpreter from C code use the current frame's ->args to store the args for the call.
11:50 FROGGS jnthn: shell() seems to work now (with the proper way of doing it), but slurp is broken... I'll commit when both is fixed
11:53 jnthn ok
11:53 jnthn I'm working on unbusting backtraces
11:53 FROGGS ohh, that would be cool
11:53 jnthn So we don't need to --ll-exception everywhere.
11:54 FROGGS the call to nqp::throw in print_exception or what it is called explodes
11:54 jnthn Nah, real reason is burried in backtrace construction, it seems...
11:55 FROGGS yeah, there is something weird in $!ex, but I've not found anything
12:01 grondilu joined #moarvm
12:01 * grondilu got a segfault trying to compile moar-support after recent pull
12:02 * grondilu tried again immediately, and this time it passed.  Go figure.
12:33 nwc10 MoarMV master seems to break t/qregex/01-qregex.t
12:33 nwc10 not ok 355 - unicode whitespace (\s)
12:37 FROGGS that might be the upgrade to unicode 6.3
12:45 cognominal joined #moarvm
12:51 nwc10 Am I out of line to suggest things for other people to do? :-)
12:52 dalek MoarVM: 7a456ff | jnthn++ | src/core/exceptions.c:
12:52 dalek MoarVM: Avoid rooting junk.
12:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7a456ff7d0
12:52 dalek MoarVM: 8e3584d | jnthn++ | src/core/exceptions.c:
12:52 dalek MoarVM: Avoid looking in exception after it may move.
12:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8e3584d331
12:52 dalek MoarVM: 84fa810 | jnthn++ | src/core/exceptions.c:
12:52 dalek MoarVM: Use source filename in backtrace if possible.
12:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/84fa810e5d
12:54 nwc10 jnthn: for optional args, that quick fix that diakopter applied of mine, to NULL them. Would it be better to change the code *not* to temp root them if they don't exist (or are NULL, or whatever). ie, to reduce pressure on the number of temp roots the GC needs to traverse
12:54 nwc10 (and heck, malloc() needs to make space to store)
12:55 nwc10 (that wasn't the "other people" thing)
12:55 jnthn nwc10: I suspect that compared to things like inter-generational roots and frame roots, temp roots are a drop in the ocean...
12:55 jnthn nwc10: We probably save more by avoided calls to push/pop the roots... :)
12:57 nwc10 but right now, we need completeness and corectness before we really consider speed
13:02 FROGGS jnthn: calling .encode with an encoding currently segfaults in p6decontrv... https://github.com/rakudo/rakudo/blob/nom/src/core/IO.pm#L321
13:03 FROGGS jnthn: I changed the ternary into if/else and added a True return value after the call to setencoding, which is void
13:03 FROGGS jnthn: do you have an idea why it segfaults?
13:03 FROGGS .encoding*
13:07 jnthn FROGGS: Probably 'cus we try to return NULL...
13:08 jnthn QAST::MASTOperations.add_core_moarop_mapping('setencoding', 'setencoding');
13:08 jnthn Just add a , 1
13:08 FROGGS k
13:10 FROGGS jnthn: that will return the encoding, right?
13:12 jnthn yeah
13:12 FROGGS that wants fixing too: perl6-m -e 'say { a => 1 }'
13:12 FROGGS ("\x[61]" => 1).hash
13:14 jnthn It's...technically right :P
13:14 FROGGS bah
13:14 FROGGS :P
13:15 FROGGS we'd need to rename the method .gist to fix it then :P
13:15 jnthn Time for some shopping/dinner; will clear up some more bits this afternoon :)
13:15 FROGGS \o\ let's memset all the bits /o/
13:16 jnthn Seems [Coke]++ didn't get around to pushing yesterday's roast data.
13:24 [Coke] jnthn: it's cause the jvm is sooo slow.
13:24 [Coke] that doesn't inclue your fix on error reporting.
13:24 [Coke] (the just-pushed data)
13:25 camelia joined #moarvm
13:45 nwc10 jnthn: assert(frame->params.arg_count == frame->caller->cur_args_callsite->arg_count);
13:45 nwc10 amusingly, op is 139
13:45 nwc10 no, not SEGV with coredump
13:45 nwc10 invoke_o
13:46 nwc10 not dug further
13:47 ggoebel118 joined #moarvm
13:48 nwc10 as in, having just run the op invoke_o, tc->cur_frame->caller->cur_args_callsite->arg_count is 1, but tc->cur_frame->caller->params.arg_count is 2
13:49 nwc10 but tc->cur_frame->params.args and tc->cur_frame->caller.args are equal
13:49 nwc10 I think that I should take my fan club for a walk while the sun is out
13:51 dalek MoarVM: 720fad4 | masak++ | 3rdparty/libtommath/ (2 files):
13:51 dalek MoarVM: change function signature
13:51 dalek MoarVM:
13:51 dalek MoarVM: To avoid a warning during build.
13:51 dalek MoarVM:
13:51 dalek MoarVM: This is consistent with how libtommath itself does it.
13:51 dalek MoarVM:
13:51 dalek MoarVM: https://github.com/libtom/libtommath/commit/abb79ebfeda41bb5a701a40f5739b9f0ad64aff1
13:51 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/720fad4e83
14:18 dalek MoarVM: b941ec5 | (Tobias Leich)++ | src/io/procops.c:
14:18 dalek MoarVM: don't deconainerize here, we'll do it in rakudo
14:18 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b941ec5985
14:32 FROGGS --vmlibs=dynext/libperl6_ops_moar.so=Rakudo_ops_init src/gen/m-BOOTSTRAP.nqp
14:32 FROGGS Heap corruption detected: pointer 0x2b35bce30828 to past fromspace
14:32 FROGGS :o(
14:53 dalek MoarVM: 0a798d3 | jnthn++ | src/core/frame.c:
14:53 dalek MoarVM: Fix possible cause of args bug found by nwc10++.
14:53 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0a798d35ab
14:55 FROGGS ooh, that sounds promising...
14:56 JimmyZ FROGGS: I think you need revert 428cd370935ddf5ebc0ecb6cd7af4f13586cee84 too, since you reverted something in b941ec5985, as per http://irclog.perlgeek.de/moarvm/2014-01-04#i_8073457
14:56 FROGGS ahh, no, that message still pops up: When invoking frame_name_146, Provided outer frame 0x7390bd0 (MVMStaticFrame frame_name_144) does not match expected static frame type 0x7390c90 (MVMStaticFrame frame_name_145)
14:57 FROGGS JimmyZ: I did that in b941ec598583f1b83e8487979dfcfffdfecf75a8
14:59 jnthn FROGGS: Various tests give that message...how'd you get it, ooc?
14:59 JimmyZ FROGGS: you did'nt
14:59 diakopter ahoy moarians
14:59 FROGGS jnthn: running S02-magicals/progname.t
15:00 jnthn ah
15:00 jnthn Yeah, that's on my hit list of things to look into
15:00 JimmyZ FROGGS: you revert only part of it
15:00 FROGGS JimmyZ: yes, because that seems right to me
15:01 * JimmyZ don't think so
15:02 FROGGS JimmyZ: what exactly is wrong with it?
15:03 JimmyZ FROGGS: env_str and iterval is not used after 'maybe allocation'
15:04 diakopter it could be if the order of the arg evaluation is indeterminate
15:04 * timotimo is doing *something* wrong about implementing CCLASS_PRINTING o_O
15:05 FROGGS I can agree on iterval not being used, but according to diakopter++ the execution order in line 117 is not guaranteed, and so env_str could get moved
15:05 timotimo the implementation is now exactly the implementation of CONTROL with a negation
15:05 FROGGS (looking at HEAD https://github.com/MoarVM/MoarVM/blob/master/src/io/procops.c )
15:05 diakopter timotimo: gist diff?
15:06 JimmyZ FROGGS: yes, diakopter++ is saying 116 & 117 in  https://github.com/MoarVM/MoarVM/commit/7cea05bebb
15:06 JimmyZ FROGGS: but you reverted it
15:07 JimmyZ FROGGS: so it's not needed now.
15:07 timotimo https://gist.github.com/timo/3fdd5654ffbfe6a54084
15:07 * timotimo cleanly rebuilds nqp-m
15:07 FROGGS JimmyZ: but MVM_repr_get_str can still allocate
15:08 jnthn MVM_repr_get_str won't allocate
15:08 FROGGS ohh, okay
15:08 raiph joined #moarvm
15:08 FROGGS JimmyZ++
15:08 JimmyZ it's ok, even if it allcate
15:09 JimmyZ because we will update env_str manully after MVM_repr_get_str
15:09 dalek MoarVM: d0b00ac | (Tobias Leich)++ | src/io/procops.c:
15:09 dalek MoarVM: rooting not needed anymore, JimmyZ++
15:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d0b00acc6f
15:12 diakopter jnthn: I suppose I was being overly imaginative when imagining MVM_repr_get_str could allocate at some future date :)
15:12 timotimo even with a clean nqp-m PRINTING isn't properly working :\
15:14 JimmyZ FROGGS: we will set env_str a new val by 'env_str =' after 'maybe allocation', so it's ok if it is moved.
15:14 JimmyZ oh, I ...
15:15 JimmyZ I replied `(looking at HEAD ... part`
15:16 FROGGS JimmyZ: in theory the maybe alloc (which is not there) could run before we pass env_str to concat
15:17 JimmyZ oh yes, I know MVM_string_concatenate allocates.. I mixed up myself..
15:17 JimmyZ :(
15:20 jnthn Yes, concatenate will allocated
15:22 jnthn *allocate
15:22 nwc10 jnthn: All tests successful.
15:23 diakopter timotimo: I don't know why that wouldn't work
15:23 diakopter what's your test
15:23 jnthn nwc10: In...?
15:23 nwc10 master, including 0a798d35abb3d86e06ebdc07cd2997c7531e862d
15:24 nwc10 plus my assertions
15:24 nwc10 which no longer fail
15:24 nwc10 as in, that commit has fixed the inconsistency
15:24 jnthn ah, great
15:54 [Coke] jnthn: was that Test.pm commit impacting all backends?
15:54 [Coke] s/commit/rebuild issue/
15:54 [Coke] moar is running now. will try to report on that asap
15:54 jnthn [Coke]: No, I think Parrot has it fine, and I already fied the issue in moar-support a while ago.
15:55 [Coke] k
15:55 [Coke] Error while compiling op p6bindcaptosig: No registered operation handler for 'p6bindcaptosig'
15:55 [Coke] (one of the new errors)
15:56 jnthn Yeah, was always there, just hidden by broken error reporting
15:56 [Coke] *nod*
15:56 [Coke] hopefully you can fix these faster than it's worth fixing my "report on the failures" script. :)
15:57 jnthn Oh, I think such a report would still be intersting at least for the next while...
15:57 [Coke] speaking of which:
15:57 [Coke] Error while compiling op while (source text: "@array.pop -> $x {\n      $str ~= $x;\n  }"): while block expects an argument, but there's no immediate block to take it
15:59 jnthn I think that shows up in a few places...
16:02 [Coke] once we get close to 100%, need to start investigating the todo passed and see if they are legit or not.
16:02 [Coke] Error while compiling op call: Unknown anchor subtype zerowidth
16:09 diakopter ah :)
16:09 dalek MoarVM: 565df08 | jnthn++ | src/6model/ (3 files):
16:09 dalek MoarVM: Fix serialization of typed arrays.
16:09 dalek MoarVM:
16:09 dalek MoarVM: Helps fix some of the issues around Buf/Blob types.
16:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/565df08216
16:10 jnap joined #moarvm
16:26 d4l3k_ joined #moarvm
16:49 timotimo diakopter: ./nqp-m -e 'say(nqp::iscclass( 64, "d", 0 ))'
16:51 [Coke] daily moar run almost done.
16:52 colomon joined #moarvm
16:52 jnthn Wow. Our exception handlers are basically busted. Amazing we pass 78% with busted exception handlers. :)
16:52 [Coke] are optimizations on by default again?
16:53 jnthn [Coke]: Maybe -O1, not sure -O3 though...
16:53 [Coke] "total",     24356,  3472,   535,  1303, 29196, 28494
16:53 * jnthn checks what yesterday's nummer was
16:54 [Coke] 22311
16:54 [Coke] r: say 24356 - 223131
16:54 timotimo cool! :)
16:54 [Coke] r: say 24356 - 22311
16:54 camelia rakudo-parrot 5669b2, rakudo-jvm 5669b2: OUTPUT«-198775␤»
16:54 camelia rakudo-parrot 5669b2, rakudo-jvm 5669b2: OUTPUT«2045␤»
16:54 jnthn Whoa
16:54 jnthn That may push us over 80%!
16:54 [Coke] if jvm holds steady:
16:55 [Coke] r: say 24356 / 28452
16:55 camelia rakudo-parrot 5669b2, rakudo-jvm 5669b2: OUTPUT«0.856038␤»
16:55 [Coke] ayup.
16:55 [Coke] moar++
16:55 [Coke] I'll start the list of categorized test aborts now.
16:56 jnthn 85%!!
16:56 [Coke] and that's without exception handlers? ;)
16:57 [Coke] I wonder if your stacktrace fix got us some passing tests.
16:57 [Coke] (in addition to better error reporting)
16:57 jnthn Well, a try block works, it's CATCH that is busted.
16:57 jnthn The try that shoves stuff in $! is OK
16:57 jnthn Which is what eval_dies_ok and friends use
16:58 [Coke] I saw some messages about no handler for for "next".
16:59 [Coke] (or last? something)
17:07 jnthn Hm, this is a little fiddly to fix... :)
17:08 FROGGS joined #moarvm
17:09 * timotimo whips out his GDB to see what the hell is wrong with iscclass
17:10 jnthn timotimo: diff? :)
17:11 timotimo https://gist.github.com/timo/3fdd5654ffbfe6a54084
17:15 jnthn timotimo: hm, that looks ok...
17:15 timotimo i agree
17:15 timotimo i'm having some trouble now getting debug symbols into my moarvm :o
17:15 timotimo oh, duh!
17:16 timotimo wrong --prefix
17:19 raiph joined #moarvm
17:24 timotimo yeah, that's also why my patch didn't work
17:24 timotimo i didn't use the resulting binary to test.
17:25 jnthn d'oh!
17:33 timotimo yay, the fix even works!
17:34 dalek MoarVM: 731d2cf | (Timo Paulssen)++ | src/strings/ops. (2 files):
17:34 dalek MoarVM: implement CCLASS_PRINTING
17:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/731d2cfaea
17:35 ssutch joined #moarvm
17:36 jnthn yay
17:40 jnap joined #moarvm
17:51 FROGGS timotimo++
17:51 * timotimo not sure what to do next
17:52 FROGGS timotimo: btw, that is the reason why I only have one moar, one nqp repo, and one prefix...
17:52 timotimo i could try making the implementation of Str.perl faster?
17:52 jnthn ...to rule them all
17:52 timotimo hehe.
17:52 timotimo on my laptop i have a much saner setup as well
17:52 FROGGS :o)
17:52 timotimo it has ~/perl6 with install/, nqp/, parrot/, MoarVM/, rakudo/
17:52 FROGGS timotimo: that is because it must fit into your rucksack? :P
17:52 timotimo hehe
17:54 FROGGS timotimo: dunno if you want to hunt this down: perl6-m -e 'say { a => 1 }'
17:54 FROGGS ("\x[61]" => 1).hash
17:54 timotimo gimme a sec.
17:54 timotimo timo@kischde ~/build/rakudo (git)-[moar-support] % ./perl6-m -e 'say { a => 1 }'
17:54 timotimo ("a" => 1).hash
17:54 timotimo done
17:54 timotimo in literally a sec :P
17:54 FROGGS ?
17:55 timotimo that's what i fixed by implementing CCLASS_PRINTING
17:55 FROGGS was that your patch?
17:55 FROGGS yay!
17:55 timotimo yes, it was :)
17:55 jnthn Yay, catch.t passed
17:55 * FROGGS is happy
17:55 jnthn FROGGS: Did you work on shell earlier?
17:55 FROGGS jnthn: yes
17:55 jnthn FROGGS: I think it doesn't normalize the program name's slashes
17:55 jnthn not ok 4 - warn() without arguments
17:55 jnthn #      got out: ""
17:55 jnthn #      got err: "'.' is not recognized as an internal or external command,\r\noperable program or batch file.\r\n"
17:56 jnthn Test::Util spits out ./
17:56 FROGGS jnthn: which test file is that?
17:58 dalek MoarVM: fbb31cf | jnthn++ | src/ (7 files):
17:58 dalek MoarVM: Provide return-after-unwind mechanism.
17:58 dalek MoarVM:
17:58 dalek MoarVM: Needed by Rakudo for making succeed exit the surrounding block.
17:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fbb31cf859
17:59 jnthn FROGGS: warn.t in that case, but it's Test::Util that does $perl6 ~~ s{^perl6} = './perl6';
18:00 dalek MoarVM: a0a7288 | jnthn++ | lib/MAST/Ops.nqp:
18:00 dalek MoarVM: Forgot updated MAST::Ops in previous commit.
18:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a0a72883f0
18:03 diakopter lol /* Bounds checking? Never heard of that. */
18:04 tadzik who parked their car... on my sandwich!
18:07 benabik ...  Who left a sandwich in my parking spot?
18:09 jnthn FROGGS: I got a fix, I think
18:09 jnthn FROGGS: Got warn.t to pass
18:09 FROGGS ohh :)
18:09 jnthn Gonna do a spectest run with it now :)
18:10 FROGGS my windows is still searching for the domain it won't find :(
18:10 jnthn ok...well, patch seems good, so... :)
18:12 FROGGS cool
18:12 FROGGS less work for me :o)
18:12 jnthn S02 looks a good bit better with that working.
18:12 FROGGS >.<
18:13 FROGGS does that mean something about 85% ?
18:14 diakopter tadzik: trains
18:14 jnthn Oh, the run [Coke]'s already done today hit 85%
18:14 tadzik ZZZZUUM
18:15 * diakopter looks for the updated version of https://gist.github.com/sorear/5747025
18:15 FROGGS ohh
18:15 jnthn diakopter: docs/continuations.pod
18:15 FROGGS[mobile] joined #moarvm
18:15 diakopter found it, .. oh
18:17 diakopter jnthn: new repr for these $tags?
18:17 jnthn diakopter: Don't think so, that's just any old object
18:17 jnthn diakopter: afaik, the only REPR that sorear introduced was one to represent the continuation itself.
18:17 jnthn diakopter: And afaict it's same for Moar.
18:17 FROGGS[mobile] joined #moarvm
18:18 diakopter but $tag is still sort of a unique identifier
18:19 jnthn diakopter: It is, just that's just object identity
18:19 jnthn == in C
18:20 jnthn Just looked in GatherIter.pm; it seems to expect any old object to be good enough for it.
18:20 jnthn So, think we don't want to constrain it to a certain REPR...
18:22 diakopter heh "Details here are subject greatly to change."
18:25 diakopter which details are subject to change would be helpful :)
18:27 moritz the list of details that are subject to change is also subject to change :-)
18:33 jnap joined #moarvm
18:58 diakopter ETOOMUCHSAUCE
19:00 jnthn cooking, dinner, etc &
19:06 raiph joined #moarvm
19:11 ggoebel119 joined #moarvm
19:12 ggoebel1110 joined #moarvm
19:18 harrow joined #moarvm
19:22 FROGGS yay, even progname.t does work now!
19:32 [Coke] any leads on the frame type issue?
19:33 FROGGS one vanished... it was something like Match.Bool
19:39 diakopter lazyirc: replace all "shift" in strings in 01-continuations.t with "control"
19:40 diakopter well, not just in strings
19:40 diakopter also var names
19:41 jnthn [Coke]: Frame type?
19:42 jnthn [Coke]: If it's the wrong outer thingy, I fixed at least the case that was busting whatever-star things
19:56 [Coke] here's the one from today's (not yet pushed) run:
19:56 [Coke] https://gist.github.com/coke/8250608/
19:56 [Coke] er. there it is.
19:57 [Coke] I tried to collapse all the frames into a single error category, looks like I missed one. still a few dozen instances as of earlier today.
19:59 [Coke] $*TZ looks like an easy win. (130 test); "Provided outer frame" is 876 tests.
20:00 [Coke] that 301 Killed is probably too aggressive, as I dialed down the allowed time to find the error. (it's 90s during the normal run, more like 20s here.)
20:00 jnthn [Coke]: S02-types/whatever.rakudo.moar is one of the ones that was broken with that frame error, and I fixed
20:00 FROGGS weird that progname.t is not passing on your box
20:00 jnthn [Coke]: I think my fix did land after you started running tests.
20:00 jnthn I know several others on that list pass now too :)
20:00 [Coke] ok. I can do another run after work.
20:01 * FROGGS .oO( must be the timezone offset )
20:01 jnthn [Coke]++ # useful list is useful
20:04 jnthn S06-multi/lexical-multis.rakudo.moar passes too
20:04 harrow joined #moarvm
20:07 masak diakopter: like this? https://gist.github.com/masak/8288989
20:13 dalek MoarVM: d1a93b7 | jnthn++ | src/io/procops.c:
20:13 dalek MoarVM: Fix shell on Win32 when path has /s.
20:13 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d1a93b7d0f
20:13 dalek MoarVM: 94432fa | jnthn++ | src/core/exceptions.c:
20:13 dalek MoarVM: Make lack of control exception handler catchable.
20:13 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/94432fa554
20:13 jnthn That latter one fixes S04-statements/do.rakudo.moar
20:14 [Coke] only one segfault left, that's progress. :)
20:14 jnthn Wow. Down from 180ish? :)
20:17 masak diakopter: pushed to https://github.com/perl6/nqp/tree/replace-shift-with-control-in-strings in case that was what you meant.
20:18 [Coke] here's a golf on that segfault:
20:19 [Coke] https://gist.github.com/coke/8289184
20:22 [Coke] golf'd more.
20:28 jnthn [Coke]: urgh...
20:28 jnthn [Coke]: Thanks for golfing
20:29 [Coke] ooh, is it fun? painful?
20:29 jnthn [Coke]: Painful at first glance
20:29 jnthn [53] p6finddispatcher NYI
20:29 jnthn hmm...that one, by contrast, doesn't look too bad :)
20:32 nwc10 jnthn: right now, I don't have any known bugs
20:32 nwc10 although, to be totally fair, I have I think two local fixes that I've not sent upstream
20:32 nwc10 and NQP is still chugging away very slowly, with a GC run before every allocation.
20:33 nwc10 and 255 fromspaces (all mapped unreadable)
20:34 nwc10 and between every op sanity checks on all registers and at least some of the current parameters (forget how far down the rabbit hole)
20:34 jnthn Wow :)
20:34 nwc10 yes. I am *trying* to break it
20:34 jnthn Well, the more things we find this way, the better :)
20:34 FROGGS really hard, yes
20:35 nwc10 oooh, that process just finished about 5 seconds after I grabbed this:
20:35 nwc10 22347 nicholas  20   0  135m 113m 8616 R 98.3  0.1 226:51.79 moar
20:35 nwc10 yes, 227 minutes for gen/moar/stage2/NQPP6QRegex.nqp
20:35 nwc10 I'm trying to find them all. All.
20:35 nwc10 every single little bugger.
20:43 FROGGS ohh, dear, I think I'll do p6decodelocaltime
20:43 jnthn ++FROGGS
20:46 nwc10 at the rate NQP is going, I'm wondering if it's going to take the better part of a week to get to the end of Rakudo
20:46 nwc10 not a problem.
20:46 nwc10 just means that the answer will be a bit out of date
20:47 jnthn So long as there's a stable baseline to test a fix with, that's not really a problem.
20:51 nwc10 yes.
21:01 [Coke] nwc10==
21:01 [Coke] er: nwc10++
21:03 nwc10 [Coke]: related to a previous question, I think from FROGGS - were you building Moar & Rakudo on OS X? If so, were you getting the assertion failures and other crap from the file handle in UV? And if you were, are they now fixed?
21:03 nwc10 I'm not building on my laptop, as it's not that fast, and the fans really don't need the exercise
21:04 nwc10 er, fan. I think that there's only one
21:04 [Coke] nwc10: like you, I'm not regularly building on my laptop.
21:04 nwc10 :-)
21:04 nwc10 this is what I have shell accounts for
21:04 [Coke] I'm more concerned about the linux box I run the daily test on.
21:04 jnthn I think we still have build problems on OS X.
21:05 jnthn In fact, getting those fixed is probably the main thing I'd really like to see happen before we merge moar-support
21:05 FROGGS[mobile] joined #moarvm
21:11 grondilu joined #moarvm
21:41 dalek MoarVM: f6daf4e | (Tobias Leich)++ | src/strings/ops.c:
21:41 dalek MoarVM: treat binary as ascii
21:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f6daf4e219
21:42 jnthn Um...
21:43 jnthn What on earth is a "binary" encoding?
21:44 jnthn We should fix the real issue, not bring that brain damage into Moar. Please revert.
21:44 FROGGS k
21:44 dalek MoarVM: 773664f | (Tobias Leich)++ | src/strings/ops.c:
21:44 dalek MoarVM: Revert "treat binary as ascii"
21:44 dalek MoarVM:
21:44 dalek MoarVM: This reverts commit f6daf4e219bb6298c03556c5ef514b18898e58a0.
21:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/773664f48a
21:45 jnthn I'm fairly sure we ended up without binary as an encoding name on JVM, fwiw.
21:46 FROGGS rakudo-moar/src/core/IO.pm:110:        nqp::setencoding($!PIO, $bin ?? 'binary' !! NORMALIZE_ENCODING($encoding));
21:46 FROGGS nqp/src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java:433:            else if (encoding.equals("binary"))
21:47 FROGGS so, we should pass "ascii" when we get :bin ?
21:48 FROGGS (get :bin to open())
21:48 lue FROGGS: I should think :bin gets you a Buf, not a string. Or am I wrong?
21:49 FROGGS lue: correct, but what you get pack when reading from a handle does not say anything about what you tell parrot what the encoding is
21:50 FROGGS I'd guess that parrot fails when reading binary data into a buf using ascii, I can't explain otherwise why we use "binary" at all
21:51 FROGGS I will investigate tomorrow if nobody beats me to it...
21:51 lue Am I missing something here, or does Buf.decode() not imply that Buf is encoding-less?
21:51 jnthn FROGGS: I think that we simply don't state an encoding if we're just doing binary IO
21:51 timotimo what do i do now? :|
21:52 FROGGS jnthn: yeah, that is another possibility... atm we always set an encoding in open()
21:52 FROGGS bbl
21:53 FROGGS[mobile] joined #moarvm
21:54 jnthn timotimo: Well, I can give you some ideas... :)
21:54 timotimo go ahead :)
21:54 lue I think it'd be better if open() didn't set an encoding on binary data. The fact that I'm using :bin should state that I'm not playing with purely text already.
21:54 jnthn timotimo: We fail a couple of tests in each of the trig test files. Maybe work those out. There's others in S32-num that may or may not be LHF.
21:55 jnthn timotimo: There may be a common thread, e.g. something odd in handling of NaN/Inf stringification or something
21:56 jnthn [80] Error while compiling op call: Unknown anchor subtype zerowidth
21:56 timotimo yeah, that confused me already
21:56 jnthn ^^ may also be easy, just look how the code-gen for Moar differs from JVM/Parrot.
21:56 timotimo perhaps
21:56 * timotimo is currently building all the things
21:57 jnthn S02-types\nan.rakudo.moar and S02-types\infinity.rakudo.moar suggest something is up with our handling of inf/nan.
21:58 timotimo where is the file you're quoting from?
21:59 jnthn https://gist.github.com/coke/8250608/
21:59 timotimo thanks
21:59 jnthn Note it's already partially out of date in some regards.
21:59 timotimo nothing i can do to make a big feature like junctions work? :P
22:00 [Coke] I will update it again later tonight on an intraday run, but folks are fixing tests fast.
22:01 timotimo cool :)
22:02 timotimo p6bindcaptosig ... doable? :)
22:02 timotimo capturehasnameds needs a MVMCallCapture - might be what i did?
22:03 timotimo openpipe would be a cool thing to have, but not something easily havable, i guess
22:26 dalek MoarVM: 6028e8f | jnthn++ | src/core/ (3 files):
22:26 dalek MoarVM: Factor out and expose usecapture logic.
22:26 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6028e8ff7a
22:26 dalek MoarVM: b8d1dc5 | jnthn++ | src/core/frame. (2 files):
22:26 dalek MoarVM: Add API for looking up a lexical in a given frame.
22:26 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b8d1dc52ae
22:29 timotimo jnthn: i can't get any trigonometry tests to fail
22:31 jnthn timotimo: Oh...maybe it's Windows specific? :(
22:32 jnthn You could maybe look into why t\spec\S03-metaops\reduce.rakudo.moar is so faily...
22:32 jnthn bbi10
22:32 timotimo may be.
22:53 * jnthn back
23:36 ssutch joined #moarvm
23:54 dalek MoarVM: 828145d | jnthn++ | src/ (5 files):
23:54 dalek MoarVM: Code object name needs to be per-code object.
23:54 dalek MoarVM:
23:54 dalek MoarVM: The user-defined operator support in Rakudo depends on this.
23:54 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/828145d7e3
23:58 ggoebel1111 joined #moarvm
23:59 [Coke] ah, it is optimize=3

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary