timotimo i think so, too 00:00
maybe adding --ll-exception somewhere woudl help?
jnthn Yes, that reveals the real causes. 00:01
[Coke] jnthn: ah. 00:57
I can change my "check the abort reason" to always include that.
... 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.
[Coke] either is fine. :)
timotimo is working "hard" on junction auto-threading :) 01:00
working hard, in this case, means asking jnthn every step of the way how to continue :P
[Coke] :( 01:14
er, :)
timotimo and now: a heisenbug 01:15
nwc10 would enjoy this i bet :P
it happens so early in rakudo's compile cycle
the bootstrap, not the setting
01:17 jnap joined
timotimo Missing or wrong version of dependency 'src/gen/m-BOOTSTRAP.nqp' <- wat 01:17
jnthn: ^ more symptoms of the same heisenbug perhaps?
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
jnthn o.O 01:20
Did something that depends on m-bootstrap not get re-built? 01:21
timotimo dunno. i did a make clean now
and also a moarvm build with --optimize=1 instead of =3
got a build now 01:25
This representation (VMHash) does not support positional access
seems like my flattening of the hash didn't work 01:26
i removed the %(...) around it
that must be the cause
01:28 cognominal joined
jnthn Oh, yeah, it doesn't want the %(...) thing 01:29
timotimo another clean install ...
i compiled it without a %(...) thing and it failed to flatten it properly 01:30
jnthn Did you include a | ? 01:31
timotimo yes 01:33
it was |nqp::getnamedshash($capture)
er
capturenamedshash
shush, shash
jnthn Try bidning what nqp::getnamedshash returns to a hash first
timotimo still vmhash doesn't support positional access
OK
jnthn And then flattening that in.
timotimo will do 01:34
Type check failed in bind; expected Str but got Str 01:38
a somewhat better error, i guess
timotimo force-pushed over the branch, so you can has a look 01:39
jnthn OK...gonna sleep now...will look tomorrow 01:41
timotimo sure :)
gnite!
i should get some rest, too i think
02:31 ssutch joined 02:45 raiph joined 04:01 ssutch joined 06:52 raiph joined 07:48 hoelzro joined, japhb_ joined, rurban joined 08:20 FROGGS joined
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:21
[Coke] / nwc10 / jnthn: so, seems fixed on windows and linux now, but still broken on osx, right nwc10? 08:23
nwc10 IIRC I never actually ran tests on OS X, so I can't answer that conclusively. 08:29
FROGGS nwc10: ohh, and I thought you are developing on an apple 08:32
08:32 odc joined
FROGGS nwc10: but that means the assertions are not fixed for you? 08:32
nwc10 I'm physically typing on Apple laptop, which I also tried to build on 08:44
but I'm shifting the code over to a beefy Linux box for most things 08:45
(just wanted to test build locally)
my mail is on a FreeBSD machine
and I have access to a reasonable amount of other OSes
(but sadly currently nothing running on Sparc)
(of architectures still in production and widespread deployment) 08:46
FROGGS so, does it still fail on that linux box?
nwc10 does not seem to (for that reason)
in that I've got a lot of debugging stuff as well, and some of that is failing an assertion now 08:47
for which I'd like a jnthn for advice
FROGGS yeah
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:48
nwc10 but currently I'm trying to figure out why a laserjet is printing blank pages 08:49
FROGGS "laser"
nwc10 as in, laser doesn't?
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
but, sadly, I think that it's more cost effective to buy something new
FROGGS no... "laser" as in Austin Powers 08:51
nwc10 certainly isn't skilled to the level of "solder the motherboard"
oh, right
FROGGS I've got a cheap dell color laser printer (80 Euro), and this thingy is awesome
only up to A4 pages though... 08:52
nwc10 this is an ancient HP 2200 something
only has USB and parallel, and no duplex
FROGGS my dell has only usb, and no duplex either
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
FROGGS but the printed pages look morre than awesome
more*
nwc10 a bilt like big iron shipping with all the CPUs, but only the ones you pay for are turned on. 08:54
do Dell still make this? Does it run with linux?
FROGGS that is quite possible
nwc10 it sounds better value than anything Andrea's mother might buy retail
FROGGS nwc10: it is some xerox 7000 or so under the hood
and yes, it works okay using ubuntu 08:55
nwc10 had to hack at Ubuntu to make it work with this HP.
FROGGS but I had once porblems with my ubuntu machine and did not get it to print anything... this fixed itself somehow after months
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
printer choked
FROGGS *g*
nwc10 OS X seems to default to PCL and 300dpi monochrome
hacked at Ubuntu to do something similar 08:56
masak two-line diff coming up: 09:27
- int len = snprintf(buffer, 64, "%lld", i);
+ int len = snprintf(buffer, 64, "%lld", (long long int)i);
this fixes a cast warning in the build.
can I commit and push that?
FROGGS +1 09:28
dalek arVM: 6a5ca57 | masak++ | src/core/coerce.c:
fix cast warning
 09:34
masak another two-line diff, this time from 3rdparty/libtommath/bn_error.c 09:41
- return msgs[x].msg;
+ return (char *)msgs[x].msg;
FROGGS masak: you are going PR it?
masak it does fix the (last) warning, but I don't know what the policy is for patching third-party code.
I can do that.
jnthn What type are you casting that from? 09:42
masak jnthn: a const char *
jnthn ah, ok
nwc10 jnthn: this inconsistency between frame->params and frame->caller should not happen, should it? paste.scsys.co.uk/289748 09:43
frame->caller.args and frame->params.args are identical (ie point to same memory) but the arg_count differs
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.
FROGGS masak: I don't think he'll except that PR when looking at github.com/libtom/libtommath/blob/...rror.c#L35
nwc10 (gdb) p frame->params.arg_flags
$76 = (MVMCallsiteEntry *) 0x0
masak FROGGS: s/except/object to/ ? 09:45
FROGGS accept*
jnthn nwc10: That looks certainly broken...
nwc10 OK
masak FROGGS: ...it looks the same as moar does now.
nwc10 I realise that I can add some code to figure out when that happens
FROGGS because msg is const cahr * and the function returns const char *
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
masak FROGGS: ah, you are right.
FROGGS: I should change the return type instead.
jnthn nwc10: Yeah, question is how'd we get to 2...
masak FROGGS++
nwc10 and I think that the reason is that it's frame->params.args[1]
whereas I'm guessing that frame->caller.args was rooted, and hence only (gdb) p frame->params.arg_flags 09:47
$76 = (MVMCallsiteEntry *) 0x0
(bah
)
whereas I'm guessing that frame->caller.args was rooted, and hence only [0]
anyway, I can add different code to work out where they diverged
jnthn Yeah...I just don't know how we get into such a situation...
JimmyZ jnthn: ping 09:55
FROGGS jnthn: btw, fixing shell() and run(), it segfaults not in p6decontrv... was my patch wrong? gist.github.com/FROGGS/91a9c7cc63efd3d2f587
jnthn: both the bt and my patch is in that gist
hi JimmyZ
JimmyZ Hi FROGGS
jnthn STABLE(iterval)->container_spec->fetch(tc, iterval, &r); \ 09:57
Argh, don't do that...
What if it's a code_pair like Proxy uses?
Then you've got the interpreter pointing at the wrong place. 09:58
We should fix it to make sure we don't put containerized things into the hash we pass to shell
JimmyZ jnthn: I got a patch: 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)
JimmyZ: It's always safe. 10:00
JimmyZ OK, I don't know why :)
jnthn JimmyZ: args is always allocated to at least 3 items.
Your patch is wrong as args here is stack allocated, but it must live longer than code_pair_[fetch|store] 10:01
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.
FROGGS jnthn: okay, I was thinking about that this night... and yes, that $ENV hash might be better hllized?
JimmyZ yeah, But I think what about sub() { } , the frame args is zero. 10:02
jnthn JimmyZ: What?
FROGGS jnthn: like this does it? rakudo-moar/src/Perl6/World.nqp:31:sub p6ize_recursive($x) {
jnthn Params != args, for one.
JimmyZ oh 10:03
jnthn FROGGS: Don't we have the opposite problem here?
FROGGS jnthn: right now we are putting things in the hash using p6box or so
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
ahh, hmmm
jnthn Yeah, that bit is OK, it's the containers that ain't.
JimmyZ decommutes
FROGGS ahh
jnthn my Mu $hash := nqp::getattr(%*ENV, EnumMap, '$!storage'); 10:05
That certainly will lead to a hash of containerized things. 10:06
FROGGS umm, why? Ć³.Ć² 10:07
jnthn See how it's built in terms.pm - with assignment.
FROGGS this? %ENV{$key} = nqp::p6box_s(nqp::iterval($envelem));
jnthn Yeah
FROGGS okay, this creates containers... 10:08
jnthn Anyway, solution is to make a copy of the hash without the containers.
I think most efficient way is to clone it and then iterate, decont'ing each value.
FROGGS so I'd need to walk the values and bind them to a new nqp::hash?
jnthn yeah
FROGGS k
JimmyZ jnthn: I'm asking because I see github.com/MoarVM/MoarVM/blob/mast...ame.c#L176 11:01
dalek arVM: 74c3c4a | jnthn++ | src/core/bytecodedump.c:
Get --dump able to handle extops.
 11:02
JimmyZ Which may be NULL...
jnthn JimmyZ: Ah...
JimmyZ: I...can't imagine a frame with no registers, though... 11:03
JimmyZ: That is, if it has none, it can certainly never do a decont op :)
JimmyZ isn't decont is in next_frame? 11:04
the next frame inovke
*invoke
where the store is set cur_frame 11:05
*while 11:06
jnthn doesn't understand the question... 11:14
All the calls back into the interpreter from C code use the current frame's ->args to store the args for the call. 11:15
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:50
jnthn ok 11:53
I'm working on unbusting backtraces
FROGGS ohh, that would be cool
jnthn So we don't need to --ll-exception everywhere.
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...
FROGGS yeah, there is something weird in $!ex, but I've not found anything 11:55
12:01 grondilu joined
grondilu got a segfault trying to compile moar-support after recent pull 12:01
grondilu tried again immediately, and this time it passed. Go figure. 12:02
nwc10 MoarMV master seems to break t/qregex/01-qregex.t 12:33
not ok 355 - unicode whitespace (\s)
FROGGS that might be the upgrade to unicode 6.3 12:37
12:45 cognominal joined
nwc10 Am I out of line to suggest things for other people to do? :-) 12:51
dalek arVM: 7a456ff | jnthn++ | src/core/exceptions.c:
Avoid rooting junk.
 12:52
arVM: 8e3584d | jnthn++ | src/core/exceptions.c:
Avoid looking in exception after it may move.
arVM: 84fa810 | jnthn++ | src/core/exceptions.c:
Use source filename in backtrace if possible.
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
(and heck, malloc() needs to make space to store)
(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...
nwc10: We probably save more by avoided calls to push/pop the roots... :)
nwc10 but right now, we need completeness and corectness before we really consider speed 12:57
FROGGS jnthn: calling .encode with an encoding currently segfaults in p6decontrv... github.com/rakudo/rakudo/blob/nom/...IO.pm#L321 13:02
jnthn: I changed the ternary into if/else and added a True return value after the call to setencoding, which is void 13:03
jnthn: do you have an idea why it segfaults?
.encoding*
jnthn FROGGS: Probably 'cus we try to return NULL... 13:07
QAST::MASTOperations.add_core_moarop_mapping('setencoding', 'setencoding'); 13:08
Just add a , 1
FROGGS k
jnthn: that will return the encoding, right? 13:10
jnthn yeah 13:12
FROGGS that wants fixing too: perl6-m -e 'say { a => 1 }'
("\x[61]" => 1).hash
jnthn It's...technically right :P 13:14
FROGGS bah
:P
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 :)
FROGGS \o\ let's memset all the bits /o/
jnthn Seems [Coke]++ didn't get around to pushing yesterday's roast data. 13:16
[Coke] jnthn: it's cause the jvm is sooo slow. 13:24
that doesn't inclue your fix on error reporting.
(the just-pushed data)
13:25 camelia joined
nwc10 jnthn: assert(frame->params.arg_count == frame->caller->cur_args_callsite->arg_count); 13:45
amusingly, op is 139
no, not SEGV with coredump
invoke_o
not dug further 13:46
13:47 ggoebel118 joined
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:48
but tc->cur_frame->params.args and tc->cur_frame->caller.args are equal 13:49
I think that I should take my fan club for a walk while the sun is out
dalek arVM: 720fad4 | masak++ | 3rdparty/libtommath/ (2 files):
change function signature

To avoid a warning during build.
This is consistent with how libtommath itself does it.
  github.com/libtom/libtommath/commi...f0ad64aff1		 13:51
arVM: b941ec5 | (Tobias Leich)++ | src/io/procops.c:
don't deconainerize here, we'll do it in rakudo
 14:18
FROGGS --vmlibs=dynext/libperl6_ops_moar.so=Rakudo_ops_init src/gen/m-BOOTSTRAP.nqp 14:32
Heap corruption detected: pointer 0x2b35bce30828 to past fromspace
:o(
dalek arVM: 0a798d3 | jnthn++ | src/core/frame.c:
Fix possible cause of args bug found by nwc10++.
 14:53
FROGGS ooh, that sounds promising... 14:55
JimmyZ FROGGS: I think you need revert 428cd370935ddf5ebc0ecb6cd7af4f13586cee84 too, since you reverted something in b941ec5985, as per 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)
JimmyZ: I did that in b941ec598583f1b83e8487979dfcfffdfecf75a8 14:57
jnthn FROGGS: Various tests give that message...how'd you get it, ooc? 14:59
JimmyZ FROGGS: you did'nt
diakopter ahoy moarians
FROGGS jnthn: running S02-magicals/progname.t
jnthn ah 15:00
Yeah, that's on my hit list of things to look into
JimmyZ FROGGS: you revert only part of it
FROGGS JimmyZ: yes, because that seems right to me
JimmyZ don't think so 15:01
FROGGS JimmyZ: what exactly is wrong with it? 15:02
JimmyZ FROGGS: env_str and iterval is not used after 'maybe allocation' 15:03
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
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
FROGGS (looking at HEAD github.com/MoarVM/MoarVM/blob/mast.../procops.c )
diakopter timotimo: gist diff?
JimmyZ FROGGS: yes, diakopter++ is saying 116 & 117 in github.com/MoarVM/MoarVM/commit/7cea05bebb 15:06
FROGGS: but you reverted it
FROGGS: so it's not needed now. 15:07
timotimo gist.github.com/timo/3fdd5654ffbfe6a54084
timotimo cleanly rebuilds nqp-m
FROGGS JimmyZ: but MVM_repr_get_str can still allocate
jnthn MVM_repr_get_str won't allocate 15:08
FROGGS ohh, okay
15:08 raiph joined
FROGGS JimmyZ++ 15:08
JimmyZ it's ok, even if it allcate
because we will update env_str manully after MVM_repr_get_str 15:09
dalek arVM: d0b00ac | (Tobias Leich)++ | src/io/procops.c:
rooting not needed anymore, JimmyZ++
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 :\
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
oh, I ...
I replied `(looking at HEAD ... part` 15:15
FROGGS JimmyZ: in theory the maybe alloc (which is not there) could run before we pass env_str to concat 15:16
JimmyZ oh yes, I know MVM_string_concatenate allocates.. I mixed up myself.. 15:17
:(
jnthn Yes, concatenate will allocated 15:20
*allocate 15:22
nwc10 jnthn: All tests successful.
diakopter timotimo: I don't know why that wouldn't work 15:23
what's your test
jnthn nwc10: In...?
nwc10 master, including 0a798d35abb3d86e06ebdc07cd2997c7531e862d
plus my assertions 15:24
which no longer fail
as in, that commit has fixed the inconsistency
jnthn ah, great
[Coke] jnthn: was that Test.pm commit impacting all backends? 15:54
s/commit/rebuild issue/
moar is running now. will try to report on that asap
jnthn [Coke]: No, I think Parrot has it fine, and I already fied the issue in moar-support a while ago.
[Coke] k 15:55
Error while compiling op p6bindcaptosig: No registered operation handler for 'p6bindcaptosig'
(one of the new errors)
jnthn Yeah, was always there, just hidden by broken error reporting 15:56
[Coke] *nod*
hopefully you can fix these faster than it's worth fixing my "report on the failures" script. :)
jnthn Oh, I think such a report would still be intersting at least for the next while... 15:57
[Coke] speaking of which:
Error while compiling op while (source text: [email@hidden.address] -> $x {\n $str ~= $x;\n }"): while block expects an argument, but there's no immediate block to take it
jnthn I think that shows up in a few places... 15:59
[Coke] once we get close to 100%, need to start investigating the todo passed and see if they are legit or not. 16:02
Error while compiling op call: Unknown anchor subtype zerowidth
diakopter ah :) 16:09
dalek arVM: 565df08 | jnthn++ | src/6model/ (3 files):
Fix serialization of typed arrays.

Helps fix some of the issues around Buf/Blob types.
16:10 jnap joined 16:26 d4l3k_ joined
timotimo diakopter: ./nqp-m -e 'say(nqp::iscclass( 64, "d", 0 ))' 16:49
[Coke] daily moar run almost done. 16:51
16:52 colomon joined
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?
jnthn [Coke]: Maybe -O1, not sure -O3 though... 16:53
[Coke] "total", 24356, 3472, 535, 1303, 29196, 28494
jnthn checks what yesterday's nummer was
[Coke] 22311 16:54
r: say 24356 - 223131
timotimo cool! :)
[Coke] r: say 24356 - 22311
camelia rakudo-parrot 5669b2, rakudo-jvm 5669b2: OUTPUTĀ«-198775ā¤Ā»
rakudo-parrot 5669b2, rakudo-jvm 5669b2: OUTPUTĀ«2045ā¤Ā»
jnthn Whoa
That may push us over 80%!
[Coke] if jvm holds steady:
r: say 24356 / 28452 16:55
camelia rakudo-parrot 5669b2, rakudo-jvm 5669b2: OUTPUTĀ«0.856038ā¤Ā»
[Coke] ayup.
moar++
I'll start the list of categorized test aborts now.
jnthn 85%!! 16:56
[Coke] and that's without exception handlers? ;)
I wonder if your stacktrace fix got us some passing tests. 16:57
(in addition to better error reporting)
jnthn Well, a try block works, it's CATCH that is busted.
The try that shoves stuff in $! is OK
Which is what eval_dies_ok and friends use
[Coke] I saw some messages about no handler for for "next". 16:58
(or last? something) 16:59
jnthn Hm, this is a little fiddly to fix... :) 17:07
17:08 FROGGS joined
timotimo whips out his GDB to see what the hell is wrong with iscclass 17:09
jnthn timotimo: diff? :) 17:10
timotimo gist.github.com/timo/3fdd5654ffbfe6a54084 17:11
jnthn timotimo: hm, that looks ok... 17:15
timotimo i agree
i'm having some trouble now getting debug symbols into my moarvm :o
oh, duh!
wrong --prefix 17:16
17:19 raiph joined
timotimo yeah, that's also why my patch didn't work 17:24
i didn't use the resulting binary to test.
jnthn d'oh! 17:25
timotimo yay, the fix even works! 17:33
dalek arVM: 731d2cf | (Timo Paulssen)++ | src/strings/ops. (2 files):
implement CCLASS_PRINTING
 17:34
17:35 ssutch joined
jnthn yay 17:36
17:40 jnap joined
FROGGS timotimo++ 17:51
timotimo not sure what to do next
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?
jnthn ...to rule them all
timotimo hehe.
on my laptop i have a much saner setup as well
FROGGS :o)
timotimo it has ~/perl6 with install/, nqp/, parrot/, MoarVM/, rakudo/
FROGGS timotimo: that is because it must fit into your rucksack? :P
timotimo hehe
FROGGS timotimo: dunno if you want to hunt this down: perl6-m -e 'say { a => 1 }' 17:54
("\x[61]" => 1).hash
timotimo gimme a sec.
timo@kischde ~/build/rakudo (git)-[moar-support] % ./perl6-m -e 'say { a => 1 }'
("a" => 1).hash
done
in literally a sec :P
FROGGS ?
timotimo that's what i fixed by implementing CCLASS_PRINTING 17:55
FROGGS was that your patch?
yay!
timotimo yes, it was :)
jnthn Yay, catch.t passed
FROGGS is happy
jnthn FROGGS: Did you work on shell earlier?
FROGGS jnthn: yes
jnthn FROGGS: I think it doesn't normalize the program name's slashes
not ok 4 - warn() without arguments
# got out: ""
# got err: "'.' is not recognized as an internal or external command,\r\noperable program or batch file.\r\n"
Test::Util spits out ./ 17:56
FROGGS jnthn: which test file is that?
dalek arVM: fbb31cf | jnthn++ | src/ (7 files):
Provide return-after-unwind mechanism.

Needed by Rakudo for making succeed exit the surrounding block.		 17:58
jnthn FROGGS: warn.t in that case, but it's Test::Util that does $perl6 ~~ s{^perl6} = './perl6'; 17:59
dalek arVM: a0a7288 | jnthn++ | lib/MAST/Ops.nqp:
Forgot updated MAST::Ops in previous commit.
 18:00
diakopter lol /* Bounds checking? Never heard of that. */ 18:03
tadzik who parked their car... on my sandwich! 18:04
benabik ... Who left a sandwich in my parking spot? 18:07
jnthn FROGGS: I got a fix, I think 18:09
FROGGS: Got warn.t to pass
FROGGS ohh :)
jnthn Gonna do a spectest run with it now :)
FROGGS my windows is still searching for the domain it won't find :( 18:10
jnthn ok...well, patch seems good, so... :)
FROGGS cool 18:12
less work for me :o)
jnthn S02 looks a good bit better with that working.
FROGGS >.<
does that mean something about 85% ? 18:13
diakopter tadzik: trains 18:14
jnthn Oh, the run [Coke]'s already done today hit 85%
tadzik ZZZZUUM
diakopter looks for the updated version of gist.github.com/sorear/5747025 18:15
FROGGS ohh
jnthn diakopter: docs/continuations.pod
18:15 FROGGS[mobile] joined
diakopter found it, .. oh 18:15
jnthn: new repr for these $tags? 18:17
jnthn diakopter: Don't think so, that's just any old object
diakopter: afaik, the only REPR that sorear introduced was one to represent the continuation itself.
diakopter: And afaict it's same for Moar.
18:17 FROGGS[mobile] joined
diakopter but $tag is still sort of a unique identifier 18:18
jnthn diakopter: It is, just that's just object identity 18:19
== in C
Just looked in GatherIter.pm; it seems to expect any old object to be good enough for it. 18:20
So, think we don't want to constrain it to a certain REPR...
diakopter heh "Details here are subject greatly to change." 18:22
which details are subject to change would be helpful :) 18:25
moritz the list of details that are subject to change is also subject to change :-) 18:27
18:33 jnap joined
diakopter ETOOMUCHSAUCE 18:58
jnthn cooking, dinner, etc & 19:00
19:06 raiph joined 19:11 ggoebel119 joined 19:12 ggoebel1110 joined 19:18 harrow joined
FROGGS yay, even progname.t does work now! 19:22
[Coke] any leads on the frame type issue? 19:32
FROGGS one vanished... it was something like Match.Bool 19:33
diakopter lazyirc: replace all "shift" in strings in 01-continuations.t with "control" 19:39
well, not just in strings 19:40
also var names
jnthn [Coke]: Frame type? 19:41
[Coke]: If it's the wrong outer thingy, I fixed at least the case that was busting whatever-star things 19:42
[Coke] here's the one from today's (not yet pushed) run: 19:56
gist.github.com/coke/8250608/
er. there it is.
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:57
$*TZ looks like an easy win. (130 test); "Provided outer frame" is 876 tests. 19:59
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
FROGGS weird that progname.t is not passing on your box
jnthn [Coke]: I think my fix did land after you started running tests.
I know several others on that list pass now too :)
[Coke] ok. I can do another run after work.
FROGGS .oO( must be the timezone offset ) 20:01
jnthn [Coke]++ # useful list is useful
S06-multi/lexical-multis.rakudo.moar passes too 20:04
20:04 harrow joined
masak diakopter: like this? gist.github.com/masak/8288989 20:07
dalek arVM: d1a93b7 | jnthn++ | src/io/procops.c:
Fix shell on Win32 when path has /s.
 20:13
arVM: 94432fa | jnthn++ | src/core/exceptions.c:
Make lack of control exception handler catchable.
jnthn That latter one fixes S04-statements/do.rakudo.moar
[Coke] only one segfault left, that's progress. :) 20:14
jnthn Wow. Down from 180ish? :)
masak diakopter: pushed to github.com/perl6/nqp/tree/replace-...in-strings in case that was what you meant. 20:17
[Coke] here's a golf on that segfault: 20:18
gist.github.com/coke/8289184 20:19
golf'd more. 20:22
jnthn [Coke]: urgh... 20:28
[Coke]: Thanks for golfing
[Coke] ooh, is it fun? painful? 20:29
jnthn [Coke]: Painful at first glance
[53] p6finddispatcher NYI
hmm...that one, by contrast, doesn't look too bad :)
nwc10 jnthn: right now, I don't have any known bugs 20:32
although, to be totally fair, I have I think two local fixes that I've not sent upstream
and NQP is still chugging away very slowly, with a GC run before every allocation.
and 255 fromspaces (all mapped unreadable) 20:33
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 :)
nwc10 yes. I am *trying* to break it
jnthn Well, the more things we find this way, the better :)
FROGGS really hard, yes
nwc10 oooh, that process just finished about 5 seconds after I grabbed this: 20:35
22347 nicholas 20 0 135m 113m 8616 R 98.3 0.1 226:51.79 moar
yes, 227 minutes for gen/moar/stage2/NQPP6QRegex.nqp
I'm trying to find them all. All.
every single little bugger.
FROGGS ohh, dear, I think I'll do p6decodelocaltime 20:43
jnthn ++FROGGS
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
not a problem.
just means that the answer will be a bit out of date
jnthn So long as there's a stable baseline to test a fix with, that's not really a problem. 20:47
nwc10 yes. 20:51
[Coke] nwc10== 21:01
er: nwc10++
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
I'm not building on my laptop, as it's not that fast, and the fans really don't need the exercise
er, fan. I think that there's only one 21:04
[Coke] nwc10: like you, I'm not regularly building on my laptop.
nwc10 :-)
this is what I have shell accounts for
[Coke] I'm more concerned about the linux box I run the daily test on.
jnthn I think we still have build problems on OS X.
In fact, getting those fixed is probably the main thing I'd really like to see happen before we merge moar-support 21:05
21:05 FROGGS[mobile] joined 21:11 grondilu joined
dalek arVM: f6daf4e | (Tobias Leich)++ | src/strings/ops.c:
treat binary as ascii
 21:41
jnthn Um... 21:42
What on earth is a "binary" encoding? 21:43
We should fix the real issue, not bring that brain damage into Moar. Please revert. 21:44
FROGGS k
dalek arVM: 773664f | (Tobias Leich)++ | src/strings/ops.c:
Revert "treat binary as ascii"

This reverts commit f6daf4e219bb6298c03556c5ef514b18898e58a0.
jnthn I'm fairly sure we ended up without binary as an encoding name on JVM, fwiw. 21:45
FROGGS rakudo-moar/src/core/IO.pm:110: nqp::setencoding($!PIO, $bin ?? 'binary' !! NORMALIZE_ENCODING($encoding)); 21:46
nqp/src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java:433: else if (encoding.equals("binary"))
so, we should pass "ascii" when we get :bin ? 21:47
(get :bin to open()) 21:48
lue FROGGS: I should think :bin gets you a Buf, not a string. Or am I wrong?
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:49
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:50
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?
jnthn FROGGS: I think that we simply don't state an encoding if we're just doing binary IO
timotimo what do i do now? :|
FROGGS jnthn: yeah, that is another possibility... atm we always set an encoding in open() 21:52
bbl
21:53 FROGGS[mobile] joined
jnthn timotimo: Well, I can give you some ideas... :) 21:54
timotimo go ahead :)
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.
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.
timotimo: There may be a common thread, e.g. something odd in handling of NaN/Inf stringification or something 21:55
[80] Error while compiling op call: Unknown anchor subtype zerowidth 21:56
timotimo yeah, that confused me already
jnthn ^^ may also be easy, just look how the code-gen for Moar differs from JVM/Parrot.
timotimo perhaps
timotimo is currently building all the things
jnthn S02-types\nan.rakudo.moar and S02-types\infinity.rakudo.moar suggest something is up with our handling of inf/nan. 21:57
timotimo where is the file you're quoting from? 21:58
jnthn gist.github.com/coke/8250608/ 21:59
timotimo thanks
jnthn Note it's already partially out of date in some regards.
timotimo nothing i can do to make a big feature like junctions work? :P
[Coke] I will update it again later tonight on an intraday run, but folks are fixing tests fast. 22:00
timotimo cool :) 22:01
p6bindcaptosig ... doable? :) 22:02
capturehasnameds needs a MVMCallCapture - might be what i did?
openpipe would be a cool thing to have, but not something easily havable, i guess 22:03
dalek arVM: 6028e8f | jnthn++ | src/core/ (3 files):
Factor out and expose usecapture logic.
 22:26
arVM: b8d1dc5 | jnthn++ | src/core/frame. (2 files):
Add API for looking up a lexical in a given frame.
timotimo jnthn: i can't get any trigonometry tests to fail 22:29
jnthn timotimo: Oh...maybe it's Windows specific? :( 22:31
You could maybe look into why t\spec\S03-metaops\reduce.rakudo.moar is so faily... 22:32
bbi10
timotimo may be.
jnthn back 22:53
23:36 ssutch joined
dalek arVM: 828145d | jnthn++ | src/ (5 files):
Code object name needs to be per-code object.

The user-defined operator support in Rakudo depends on this.		 23:54
23:58 ggoebel1111 joined
[Coke] ah, it is optimize=3 23:59

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!