parrot.org/ - clean up those smolders for the release!
Set by moderator on 20 October 2008.
00:10 AndyA joined, Limbic_Region joined 00:23 magnachef joined 00:26 magnachef__ joined 00:46 magnachef joined 00:59 magnachef__ joined 01:18 magnachef joined, bsb joined 02:04 magnachef__ joined 02:55 grim_fandango joined 03:14 magnachef joined
pmichaud ...I'm getting spectest failures in rakudo -- is that "expected" at this point? 03:44
t/spec/S03-junctions/boolean-context.t is one example -- I'll get a full list in a second. 03:45
03:47 Psyche^ joined
dalek r32370 | allison++ | pdd22io: 03:48
: [pdd22io] Separate tests for 'read' and 'print' methods on FileHandle PMC.
diff: www.parrotvm.org/svn/parrot/revision?rev=32370
r32371 | allison++ | pdd22io: 03:52
: [pdd22io] Cache filename and mode passed to 'open' method for introspection and
: reopening. Add 'read' and 'print' methods.
diff: www.parrotvm.org/svn/parrot/revision?rev=32371
03:53 Ontolog joined
dalek r32372 | allison++ | pdd22io: 04:00
: [pdd22io] Keeping the revision history of the I/O buffering code under the new name.
diff: www.parrotvm.org/svn/parrot/revision?rev=32372
04:05 japhb joined
nopaste "pmichaud" at 76.183.97.54 pasted "rakudo spectest failures in trunk (r32369)" (7 lines) at nopaste.snit.ch/14492 04:32
04:56 clunker3 joined
bacek_ pmichaud: last 8 tests in junctions/boolean-context were added yesterday 04:58
pmichaud ...but they weren't marked as todo or skip? 04:59
bacek_ not yet. 05:00
pmichaud grrr. 05:01
I spent an hour or so trying to figure out why my changes were causing failures.
how about the ones in misc.t ? 05:02
bacek_ pmichaud: no idea... 05:03
but i have patch for boolean-context :) 05:04
not ok 19 - junction ("a" | "b" | "c") matches junction ($a & $b & $c) 05:15
ok(('a' | 'b' | 'c') eq ($a & $b & $c), 'junction ("a" | "b" | "c") matches junction ($a & $b & $c)'); 05:16
pmichaud probably need a boolean context there somewhere.
bacek_ probably bug in parrot...
rakudo: say (('a' | 'b' | 'c') eq ($a & $b & $c))
polyglotbot No output (you need to produce output to STDOUT)
pmichaud otherwise it can autothread over the ok() function
so it should be
ok( ? (('a' | 'b' | 'c') eq ($a & $b & $c)), '...') 05:17
bacek_ rakudo: say ?(('a' | 'b' | 'c') eq ($a & $b & $c))
polyglotbot No output (you need to produce output to STDOUT)
bacek_ hmm...
it's... weird...
pmichaud $a, $b, $c not defined there.
so of course that fails in channel. 05:18
bacek_ rakudo: my $a='a'; my $b='b'; my $c='c'; say ?(('a' | 'b' | 'c') eq ($a & $b & $c))
polyglotbot No output (you need to produce output to STDOUT)
bacek_ rakudo: my $a='a'; my $b='b'; my $c='c'; say ?(('a' | 'b' | 'c') eq ($a & $b & $c));
polyglotbot No output (you need to produce output to STDOUT)
bacek_ rakudo: say "hello"
polyglotbot No output (you need to produce output to STDOUT)
bacek_ yak...
pmichaud looks to me as though polyglotbot is the problem :-|
> my $a='a'; my $b='b'; my $c='c'; say ?(('a' | 'b' | 'c') eq ($a & $b & $c)); 05:19
0
bacek_ it's wrong
pmichaud it is?
purl Oh no it isn't!
pmichaud okay, I'll buy that it's wrong. Possibly a problem with the order in which things are being threaded. 05:22
wow, junction_comparrison_helper is *real* wrong. 05:24
for one, it should not be returning a single boolean true or false value -- it's collapsing prematurely 05:26
it's also always autothreading over the first junction, regardless of the junction's type 05:31
nopaste "pmichaud" at 76.183.97.54 pasted "example of junction autothreading result" (23 lines) at nopaste.snit.ch/14493 05:35
05:42 GeJ joined 05:46 Debolaz_ joined
bacek_ pmichaud: can you check my second patch from #60168? I slightly refactor all junctions ;) 05:51
pmichaud as I mentioned before, it would be better if it short circuited. 05:55
and infix_junction_helper has the same bug that junction_comparison_helper does -- it's always autothreading on the leftmost junction 05:57
dalek r32373 | pmichaud++ | trunk: 06:44
: [rakudo]: Add Object.Str method and get_string vtable function [RT #60350]
diff: www.parrotvm.org/svn/parrot/revision?rev=32373
06:48 MariachiElf joined
bacek_ pmichaud: in which synopsis described correct auto-threading behavior? 07:36
07:36 uniejo joined
moritz I guess it's either S03 or S06, but I didn't look yet. 07:37
bacek_ moritz: i did... 07:38
S03
no. nothing. 07:39
dalek r32374 | cotto++ | trunk: 07:41
: [pipp] make actions.pm more vim-friendly
diff: www.parrotvm.org/svn/parrot/revision?rev=32374
bacek_ afk # going home. 07:47
07:51 Ademan joined 07:58 iblechbot joined 08:03 bacek joined 08:05 tomyan joined 08:47 japhb joined
dalek r32375 | cotto++ | trunk: 09:00
: [codingstd] trailing space fix
diff: www.parrotvm.org/svn/parrot/revision?rev=32375
09:04 cosimo joined 09:14 rblackwe joined 10:20 kj joined
jonathan morning all 10:41
purl morning, jonathan
moritz moin ;)
kj morning
jonathan: I sent you an email about 5 min. ago 10:46
jonathan kj: Where did you send it to? 10:47
purl, jonathan
purl you are mailto:jnthn@jnthn.net or trying to put together a grant application.
jonathan wow, purl is actually accurate!
kj it's jonathan@jnthn.net I think
jonathan ah, there
kj that's an old one?
jonathan I'll go dig it out - in general, bad place.
No, it's my mailing list one. 10:48
kj ok
jonathan Being on mailing lists => spam
So the stuff that gets sent from mailing lists there gets sorted into folders, and I pretty much ignore the rest.
kj oh ok
jonathan kj: Found it, replying 10:49
kj .. and replied again :-) 10:53
jonathan Same! 10:57
:-)
OK, all sorted.
pmichaud++ # object stringification stuff
I suspect now that is fixed, this can be closed too... rt.perl.org/rt3/Ticket/Display.html?id=57310 10:58
dalek r32376 | jonathan++ | trunk: 11:19
: [rakudo] Make inheriting from classes complete with a namespace work. Patch courtesy of Chris Dolan.
diff: www.parrotvm.org/svn/parrot/revision?rev=32376
jonathan Less than 25 tickets before we can get the Rakudo queue back down to 150 - if indeed we can! :-) 11:23
bacek jonathan: can you fix #56612? :) 12:02
jonathan bacek: It's part of the wider lexical issues, I suspect - pm has a branch where I think he's made quite a lot of progress on that stuff. 12:03
bacek jonathan: I'll try "lex" branch. 12:05
jonathan: (while it compiles) Where I can find information about how Junctions auto-threading should work? 12:06
../../parrot perl6.pbc --target=pir --output=Test.pir Test.pm 12:08
Lexical '$/' not found
it's on "lex" branch...
jonathan S09?
purl hmmm... S09 is perlcabal.org/syn/S09.html
bacek Yo! But why tests in 't/junction' instead of 't/spec'? 12:10
jonathan Those are from Pugs tests, and have maybe not been reviewed yet (or maybe have been and also exist in t/spec somwehere) 12:12
bacek In spectest there is only S09-autovivification and S09-subscript_slice 12:15
we probably need help of "Moritz the Test Master" ;) 12:16
msg moritz Can you review tests from 't/junction' and copy appropriate tests into 't/spec'? 12:18
purl Message for moritz stored.
moritz I already reviewed the simpler tests
bacek moritz++ # being faster that quantum computers :) 12:19
moritz well, back in the days, at least 12:20
I guess the remaining ones are non-trivial
bacek "back in days"... Looks like you moving faster than light (if Einstein right) 12:22
moritz anyway, if I get around to review some more, it's surely not before 19H localtime (that's in 6H), likely even later 12:24
bacek moritz: deal 12:26
dalek r32377 | fperrad++ | trunk: 12:28
: [Lua]
: - add "man or boy" test
: see en.wikipedia.org/wiki/Man_or_boy_test
diff: www.parrotvm.org/svn/parrot/revision?rev=32377
r32378 | bernhard++ | trunk: 12:43
: #60364 [PATCH] pod fixes: L<draft/pdd19_pid.pod>, typos, syntax
: Courtesy of Brad Bowman.
diff: www.parrotvm.org/svn/parrot/revision?rev=32378
12:44 barney joined 13:36 Hunger joined 13:53 gryphon joined
Coke is the __get_string mentioned in dolan's email the parrot 'get_string :vtable' ? 14:06
(in which case lets stop using the __)
pmichaud good morning 14:12
14:12 nopaste joined
pmichaud I'm guessing that dolan saw the __ somewhere in the docs or in existing code. 14:13
14:14 gryphon joined
pmichaud autothreading is in S09 14:17
diakopter re r32377, I daresay the Perl (5) implementation on the referenced wiki is the shortest of the implementations listed. 14:18
... at first glance
although the Ruby one is comparable. 14:20
Coke i'm just happy the tcl one works. =-) 14:23
jonathan pmichaud: morning 14:24
Just went out for food, to the posta, etc
s/posta/post office/
pmichaud jonathan: good morning 14:25
jonathan pmichaud: So, container stuff? 14:26
pmichaud first thing I'd like to see us do is rename Mutable to ObjectRef
since that's a bit more accurate. 14:27
then we'll be getting rid of (or sharply reducing) Scalar
jonathan Perl6Scalar OK. 14:28
Should we do it in a branch, or? 14:29
pmichaud probably branch
jonathan OK
pmichaud can you remind me how .true, .True, etc. ultimately played out? 14:31
jonathan Oh, ouch...
IIRC, True was going to a role.
And False too
And when composed they overrode .true to return 1 and 0 respectively 14:32
pmichaud same as any other enum, or special?
got it
jonathan No, the main point out of it was that they weren't going to be like any other enum.
pmichaud right, because they have a .true method
(that overrides an object's .true when composed)
jonathan Well, that's the problem. The enum Bool <True False> would actually have a True method.
And not a .ture one
pmichaud I don't see that as a problem. 14:33
jonathan So it couldn't just work as a straightforward enum.
pmichaud am I missing something?
right.
okay, so True and False are just special roles
jonathan Right. That's how I remember the discussion ending.
pmichaud they're basically the same as the enum but with an additional .true method
jonathan Yes.
So I suppose they'd also introduce .True and .False and .Bool
pmichaud okay, here's another question -- what's the relationship between .Bool and .true in Object ? 14:34
jonathan That one I'm not totally certian on, but my expectation is that the default .Bool method just does coercion to a Bool. For Object it would maybe not be so surprising if it was defined in terms of .ture. But I could argue that the other way around too... 14:35
pmichaud yes, I was wondering which one is the base and which one is derived.
jonathan It seems to me almost like we have too many things here.
pmichaud I'm starting to think we should get rid of .true 14:36
jonathan IMO, but IANALD, since we have people overriding Str, Num etc to say "what is my Str representation, what is my Num representation", I'd rather stick with that scheme and tell people to override Bool.
pmichaud agreed.
although I don't mind if .true in fact calls .Bool
jonathan And then .true is just a utility method from Any that calls .Bool, and .false calls it and negates it.
pmichaud I haven't seen a .false, fwiw. 14:37
jonathan If indeed there is .false...is there? :-)
OK, then I made it up.
pmichaud I think it's just .true
jonathan Now, the thing is that if we actually do it this way around, then Bool *can* just be the enum, I think.
So you mix it in, and now .true calls .Bool, which was overriden by mixing in the enum and hey, we get the right answer. 14:38
pmichaud and Object.Bool just checks definedness?
jonathan Yes.
pmichaud that does seem correct.
jonathan Yeah. Why didn't we think of it this way before... :-)
pmichaud I'm thinking there's a case that doesn't work.
or that there's a LD reason for wanting .true 14:39
jonathan Hmm.
What's the relationship of prefix:? and prefix:! with all of these too, is also worth asking.
Thing is, there's potentially three ways that you can specify how you booleanize. Override Bool, override true, overload prefix:? 14:40
You could do them all differently for epic fail. ;-)
pmichaud well, overload prefix: operators is discouraged
jonathan Sure.
pmichaud for example, to specify stringify we define Str() and not overload prefix:~
jonathan Right.
So for getting a boolean value, overriding Bool would seem to fit in the "what we encourage" pattern. 14:41
pmichaud I'm also wondering if .true is intended to be able to check a value's truth "without mixin"
jonathan That feels...odd.
pmichaud i.e.,: my $a = 0 but True; ?$a (true) $a.true (false)
jonathan I hope not.
Then again, I'm just implementing, not designing. ;-) 14:42
pmichaud I'm guessing "not", since S03/S04 don't speak of .true in that manner
jonathan Yeah 14:43
I can't recall seeing anything along those lines.
dalek r32379 | tewk++ | trunk:
: [pirc] fixed linking to be portable
diff: www.parrotvm.org/svn/parrot/revision?rev=32379
jonathan tbh, part of me wonders if the relationship between all of these is one of those "whichever implementation does it and has it right enough makes the standard" kinda things 14:44
pmichaud heh
well, I'm actually thinking of specifying it in Perl 6
and posting that to p6l
jonathan That may be a good plan.
The fact that this way makes Bool just work as an enum feels encouraging. 14:45
14:46 gryphon joined
jonathan tries to work out why on earth he's getting invalid PIR spat out 14:47
Am doing if foo() -> $x { ... } stuff
pmichaud where -> $x is bound to the result of foo() ?
jonathan Right.
Did some change in PCT. 14:48
pmichaud I think that requires PCT
jonathan To support this.
pmichaud ah.
I was going to solve it generically in PCT. But I felt it needed to wait to see how lexicals finished out.
jonathan Not committed yet. It worked in the REPL for a simple test...and a spectest one that looks very similar comes out with bad code.
Ah, OK.
pmichaud I wanted to use the same approach in PCT for while/until/for/unless/etc. 14:49
jonathan Well, this'll give us something that works until then...
I was just checking the block arity.
Like for does to know how many things to take at once.
pmichaud I'm a little concerned about getting too much "something that works until then" because our "something that works" is often ending up being a blocker to future progress
but yes, checking the block arity is the right way to go. 14:51
I think that the 'for' loop has its own arity that can override the block arity.
jonathan Yes, it has to handle the special case of no arguments and thus setting $_, I think. Conditionals don't do that. 14:52
pmichaud well, for doesn't set $_
but it does force an arity of at least 1.
kj tewk++ # pirc builds on win *and* linux 14:53
jonathan Ah, OK, and we handle the $_ at the Perl 6 compiler level.
pmichaud correct -- it's just a parameter 14:54
jonathan For this case I check we have an arity of 0 or 1 and complain if not.
pmichaud I would just check if arity is non-zero and use that to decide whether to send the value as a param
jonathan If we have a sub with arity 2, and we send in just 1, we're doomed at runtime anyway, I think. 14:55
pmichaud yes, but I think it makes more sense as a runtime error.
jonathan prefers compile time errors when possible
It felt possible.
I can do it that way instead, though.
pmichaud sure, but in this case a runtime error would be more consistent with what we would see for most other sub calls with wrong number of params 14:56
at any rate, I think I'd prefer arity checking to be performed by the HLL compiler and not by PCT
jonathan Ah, OK. 14:57
I'll just go on > 1 then.
Oh argy.
This is...weird.
pmichaud if a HLL has a sub with arity > 1 but that can somehow be called with a single argument, I don't want PCT to second-guess that.
dalek r32380 | coke++ | trunk: 14:58
: this ticket is closed.
diff: www.parrotvm.org/svn/parrot/revision?rev=32380
jonathan OK, good point.
Will modify it.
I think my problem may be some weird parse issue.
nopaste? 14:59
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
purl well, nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/
nopaste "jonathan" at 85.216.157.73 pasted "heh" (10 lines) at nopaste.snit.ch/14494
jonathan pmichaud: If you uncomment the last line of that, it suddenly gives a bunch of PIR errors.
jonathan wonders what the PAST looks like
pmichaud do we support my ($a, $b, $c); yet? 15:00
that looks odd to me.
jonathan Yes, but not assigning to them all.
(as in, not list assignment...)
pmichaud also, given that lexicals have known issues I would eliminate $a_val and $b_val from that test. 15:01
sub testa { 'true_a' }
sub testb { 0 }
particle look, perl 5 constants! 15:02
15:03 rdice joined
jonathan Ah, got simple short test case. 15:04
dalek r32381 | coke++ | trunk: 15:07
: reference additional ticket
diff: www.parrotvm.org/svn/parrot/revision?rev=32381
pmichaud so, shall we get started on value/containers? 15:14
jonathan Yes - we can, I was hoping to work on what on earth was wrong with my if ... -> ... patch first, but it doesn't look obvious. 15:15
So, create the branch. 15:16
And then we can starting working in there.
jonathan delegates the scary version control bits of the job :-)
pmichaud I always wonder what to call the branch 15:17
:-)
jonathan rakontainer
pmichaud how about rakon for short?
jonathan nice
In a week everyone will be asking us, "why rakon", and we won't remember. ;-) 15:18
pmichaud of course, eventually we'll have a rakoff, I suspect.
branch committed.
svn.perl.org/parrot/branches/rakon
(checking out, building) 15:19
dalek r32382 | tewk++ | trunk:
: [MSWin32] fix build
diff: www.parrotvm.org/svn/parrot/revision?rev=32382
r32383 | pmichaud++ | rakon:
: [rakudo]: new branch for redesigning value/container semantics
diff: www.parrotvm.org/svn/parrot/revision?rev=32383
jonathan OK, checking it out.
dalek r32384 | kjs++ | trunk: 15:23
: [pirc] add a TODO file. update manifest and .skip.
diff: www.parrotvm.org/svn/parrot/revision?rev=32384
15:24 jhorwitz joined
jonathan pmichaud: OK, got it built. 15:28
pmichaud same here. 15:29
first thing I'd like to do is have an ObjectRef type. I'm thinking "Mutable" should become "ObjectRef"
jonathan OK.
In theory that's "just" some renaming. 15:30
pmichaud well, there are some things that Mutable does now that ObjectRef should not.
i.e., there shouldn't be assign_pmc, or type checking 15:31
jonathan OK 15:32
I note: Note that the 'copy' opcode above doesn't modify or
copy PMC properties on either PMC, so properties effectively
remain with their PMC "container".
pmichaud correct. 15:33
jonathan Is that what it does today, or what we need it to do?
pmichaud that's what it does today.
jonathan OK
pmichaud (and what we need it to do.)
also, I'd like an ObjectRef to not create an Undef object on initialization. :-)
jonathan OK.
You'd like it to creathing nothing? 15:34
pmichaud I'm okay with it initializing to PMCNULL.
jonathan NULLPMC?
OK.
I guess another step is writing the !VALUE methods.
Shall I take the renaming and just start doing it?
I think rename and then start to modify it...
pmichaud yes, please. I'll start working on the details of !VALUE
jonathan OK, great.
pmichaud I'm still not certain where Perl6Scalar will end up in all of this. We need a PMC type that can be used for scalar parameters to "wrap" additional constraints onto a value, so perhaps that's Perl6Scalar 15:36
jonathan Ah yes, we discussed all the additional constraints a while back and I think we found an answer.
pmichaud for a basic "my $x";, I'm expecting that $x is simply the Object protoobject 15:37
jonathan Yes.
Me too.
And I note we clone the object prototype too.
pmichaud okay, we can do that.
jonathan I think we need to, since my $x; $x++; needs to do something sane.
pmichaud oh, that's been worked out.
jonathan Oh? 15:38
purl rumour has it Oh is there a standard rule that defines a number of estimated man-hours per ticket
pmichaud increment on an undef replaces it with an Int
jonathan Right.
Which means we shoulda cloned though, I think.
pmichaud yes, you're correct there.
jonathan Otherwise we modify the Object proto. Which would kinda suck. :-)
pmichaud but the cloning of the Object proto can/should be done in actions.pm 15:39
jonathan Oh yes, I was expecting that.
Coke if we're getting rid of the integer type, we also need an easy way to do what "$P1 = new 'foo'" is doing. should we add pmc_new_from_string and pmc_new_from_pmc to wrap that sort of functionality? 15:40
pmichaud Coke, you lost me.
Coke pmc_new takes an int. 15:41
pmichaud oh, you're talking about internally in Parrot.
Coke yes.
"new thread"
pmichaud istr that allison told me that integer types would likely remain in Parrot through 1.0
they just wouldn't be visible at the PIR level 15:42
Coke if the ticket to remove VTABLE_type is still valid, that's still a ton of updates.
pmichaud that said, I wouldn't see an issue with having pmc_new_from_string and pmc_new_from_pmc 15:43
particle that's my understanding, too (int types)
Coke since vtables are user facing, I'm assuming all those tickets are still valid.
15:44 Andy joined
pmichaud agreed. 15:44
Coke hurm. I think instead of a top level pmc_new, I can just add a helper function to go from "Frob" to an int (odd if one doesn't already exist.) 15:45
jonathan Coke: Though on removing the vtable method, a good first step is maybe to remove the op that lets you get at the value from PIR and fixing the PIR side. Then that "just" leaves the C side for afterwards. 15:46
jhorwitz Coke: Parrot_PMC_typenum? 15:47
pmichaud hasn't the op for getting int values in PIR already been removed?
Coke hurm. we have pmc_type, but the op <pmc_new_p_s> does more. 15:48
jonathan: vtable_type is pretty invasive. 15:49
jhorwitz pmichaud: IIRC, that was find_type
pmichaud jhorwitz: yes, that's what I recall also.
jhorwitz was deprecated a while ago, not sure if it's been removed
Coke I don't think much of the user facing int types have been removed at all. 15:51
pmichaud are there any opcodes left that use int types?
Coke yes. 15:52
the biggest being "new_p_i"
15:52 hercynium joined
pmichaud ah, yes. 15:52
is anything blocking their removal?
particle i can't think of anything... at least nothing serious. we changed the test suite from .Integer to 'Integer' a long time ago 15:53
Coke I haven't researched it since the last time when i didn't get any replies. =-)
pmichaud so, try removing new_p_i and see what breaks. :-) 15:54
Coke I figured I'd slowly pull things out of trunk this time, if I could find any threads that weren't too deep.
pmichaud same for find_type_*
(new topic) is it appropriate to "bump" things on the mailing list to try to bring attention to them again? I'm thinking of my exceptions thread that has been warnocked since last week. 15:55
particle yes
Coke PIC breaks. 15:57
(removing that section...) 15:58
dalek r32385 | jonathan++ | rakon: 16:04
: [rakon] Rename Mutable to ObjectRef. This just does the rename everywhere, so should be nearly no breakage (sanity tests still all pass, checking spectest for anything missed).
diff: www.parrotvm.org/svn/parrot/revision?rev=32385
pmichaud excellent.
jonathan++
jonathan This was the easy step. ;-) 16:05
dalek r32386 | pmichaud++ | rakon: 16:06
: [rakudo]: Update MANIFEST.
diff: www.parrotvm.org/svn/parrot/revision?rev=32386
jonathan Ah, missed a couple of bits 16:08
pmichaud okay. next I'm thinking that infix:= goes back to being a function instead of a method.
jonathan Had two failing tests in spectest regression.
pmichaud (we can fix the missed couple of bits first)
jonathan OK, done them, just going to have a final re-run of spectest_regression. 16:09
One of them was in a bit of code we'll delete anyway. One of them wasn't.
dalek r32387 | jonathan++ | rakon:
: [rakon] Two missed references to Mutable, which caused a couple of spectest regression failures.
diff: www.parrotvm.org/svn/parrot/revision?rev=32387
pmichaud so, infix:= is a function that we call to do assignment. It's basically the same as what's currently defined in Object.pir, except no longer a method and we don't need to be checking for Mutable/ObjectRef 16:10
and I'm guessing it should move out of Object.pir, since it's no longer specific to Object. 16:11
jonathan Yes, into builtins, somewhere.
pmichaud there's already an assign.pir, I think
jonathan Yes, I think so.
moritz if the test suite catches misses in refactors, I (and all test suite hackers) can be proud ;)
jonathan moritz: I'd hate to be doing this refactor without a decent sized test suite. 16:12
pmichaud the test suite hackers can be proud regardless :-)
and what jonathan said
the test suite is a huge help to us here.
jonathan: do you want to do the infix:= adjustment or shall I?
jonathan pmichaud: I can do it. This is where everything breaks, I guess... :-) 16:13
pmichaud it's where things start to break, yes. we can do frequent commits. (more)
unfortunately, paula just added something to my schedule for the day, so if I'm going to have any lunch I have to do it now or else wait 6+ hrs
(I also have some other errands that must be done very soon.) 16:14
so I'm thinking I may disappear for about 90 mins but then will be back for the remainder of the day.
does that work? 16:15
jonathan Yes, it can.
So do you want me to push ahead with changing infix:= to a function? 16:16
particle jonathan: i can help
pmichaud yes, please.
particle what else needs doing?
pmichaud some things will probably break, but I think you can make progress.
jonathan OK. Did you have any of the !VALUE methods written?
pmichaud no
jonathan OK. So we're not going to switch to doing those again yet.
pmichaud I'm thinking we should be able to convert infix:= to a function without having to get !VALUE working yet. 16:17
i.e., and still be fairly close on passing existing tests.
jonathan OK. infix:= does different things right now depending on the LHS, which is decided by what we call the method on.
Does it become a multi sub?
pmichaud it can be a multi, but for now there would only be one.
the only way in which the LHS affects things now is to decide if it should dispatch to Scalar or to use the PIR version 16:18
since we're losing some of our Scalar stuff, it should matter less. 16:19
jonathan Array and Hash have infix:= methods that do fairly different things.
pmichaud oh.
jonathan From Scalar, that is.
.namespace ['Perl6Array']
.sub 'infix:=' :method .param pmc source $P0 = get_hll_global 'list' $P0 = $P0(source) $I0 = elements self splice self, $P0, 0, $I0 .return (self)
.end
erm, that's readable...but gives you an idea 16:20
pmichaud oh yes, they're coercing the rhs to a list.
that will change, but yes, for now they can be made multis
jonathan OK
Then we write the !VALUE and it's the thing that does the co-ercion to the list.
pmichaud yes/no.
eventually we'll end up with two infix:='s, neither of which will be called infix:= :-) 16:21
we'll have one for list assignment and one for item assignment
and the parser will determine which is called.
jonathan Ah, yes.
Is that something we're doing in this refactor too?
pmichaud for now we'll just mmd/cheat
jonathan hehe 16:22
pmichaud I still need to fix the parser so that it can recognize the two types of assignment.
jonathan OK
jonathan pushes that task firmly onto pmichaud's plate
pmichaud I'm thinking that will likely occur with protoregexes.
although I may implement a stopgap solution if it looks like protoregexes will be a bit longer than I like.
jonathan ok 16:23
particle so, if spectests pass, can rakon be merged to trunk after infix:= -> multi sub/
?
jonathan OK, we've got a clean spectest run from the renaming.
pmichaud: Did you start on the !VALUE methods at all?
pmichaud jonathan: only in my head. 16:24
jonathan pmichaud: If not and you're gone beyond me having done the infix:= changes, shall I do some of them?
pmichaud you can start on !VALUE if you want, yes.
jonathan ok, sounds good.
I'll leave you to do lunch.
pmichaud particle: there's a _lot_ of stuff that has to change as part of infix:=, so merging to trunk might be a bit premature.
particle ok, well we can merge NOW, to get the renaming in 16:25
pmichaud I'll leave that to you and jonathan to decide -- I don't think this will be a long-lived branch anyway.
particle i'm a big fan of merging frequently to reduce pain later
ok
jonathan particle: You can do it now if you like, I'll just continue working in the branch. 16:26
pmichaud I don't like the way most people do merges at the moment.
particle we're on svn 1.5 now, and don't need to do through the gyrations previously used
pmichaud most people seem to try to merge trunk updates into the branch prior to merging back to trunk -- I don't like doing that. 16:27
and after merging back to trunk, I tend to drop the branch and create a new one from trunk.
as opposed to continuing on in the current branch.
jonathan particle: If you can merge the branch as it is now into the trunk without affecting the branch, and it will make the fianl merge easier, you can do it. Otherwise, I'd rather you didn't. 16:28
distractions--
:-)
pmichaud that way I don't have to keep track of "what's already been merged in the branch and trunk?"
I find that except for long-lived branches or branches that deeply affect a lot of parrot, intermediate merges are more complex. I had that problem with the hllmagic branch a few weeks ago. 16:29
particle make sure you have svn 1.5* client 16:30
then it's not a problem, svn tracks what merged when automatically
see svnbook.red-bean.com/nightly/en/svn...rging.html for the details if you wish 16:31
pmichaud will do, later.
oops, before I go... I'm thinking that infix:= as a function might not work.
particle urk. 16:32
pmichaud let me work it through before I go.
the problem is that if the lhs is an ObjectRef to an Array or Hash, we don't want it to MMD to the Array/Hash assignment. 16:33
that's probably one reason why infix:= was a method before -- to avoid MMD issues. 16:34
jonathan Ah.
Hmmm...yes. 16:35
pmichaud let's make it a function anyway.
inside of the array/hash versions, we can check to see if the target is an ObjectRef and redispatch there.
jonathan OK. 16:36
pmichaud i.e., we'll let MMD play, but we may have to patch up MMD when it guesses wrong.
either that or we can just do our own "mmd" within a single infix:= function (no :multi)
*that* might be better for now.
jonathan That may be more desirable.
pmichaud let's do that.
at least all the nastiness will be in one place until we get around to doing list assignment.
jonathan In fact I was kinda hoping we might get away with calling infix:= in some cases as an optimization, in The Future.
But anyway, that's for later. 16:37
pmichaud right. okay, let's do it that way -- just a single infix:= function that handles all assignment
if the lhs is an ObjectRef, force scalar assignment
else if the lhs is an Array, then we place the rhs into list context and assign that
else it's a scalar assignment
(all of this is semantically wrong in several ways, but it's a cheat for now.) 16:38
jonathan Sure.
particle let's see what the tests catch us on
dalek r32388 | coke++ | trunk:
: [CAGE] Use of type ids is deprecated.
diff: www.parrotvm.org/svn/parrot/revision?rev=32388
pmichaud Hash gets treated like Array
jonathan *nod*
pmichaud okay, lunch for me, back in 90.
particle i'm not going to merge/delete/recreate branch now 16:39
jonathan OK, thanks.
particle i'm building parrot/rakudo now, will be able to help after running spectest 16:40
16:45 jan joined
particle jonathan: for container types on the lhs (Hash/Array) can we use a 'does' test for a role rather than checking 'isa' or 'can'? 16:45
jonathan Depends if there's a role exclusively done by mutable stuff like hashes that is distinct from what arrays do, etc. 16:46
Coke has a patch that removes new_p_i and new_p_i_p
particle coke: passes make test? 16:47
Coke ayup
only needed a few tweaks in t/pmc/pmc.t
particle ship it! see what the smokers think of it.
ah, parrot finally built in rakon branch. 16:49
Coke particle: committed. 16:50
purl The chicken is involved, but the pig is *committed*.
Coke svn seems happier today 16:51
dalek r32389 | coke++ | trunk:
: RT #48024 : remove [DEPRECATED] new_p_i and new_p_i_p.
diff: www.parrotvm.org/svn/parrot/revision?rev=32389
jonathan OK, moved over to infix:= function and whipped out the assign thing that Perl6Scalar did. Sanity tests all pass still. 17:01
17:01 masak joined
jonathan particle: I think the next commit is where plenty breaks. 17:05
Finding out just how much now... 17:06
particle ok, i'm still running spectests
my cpu is rather saturated with other tasks atm
disk too, for that matter
dalek bernhard.schmalhofer@gmx.de | Pipp: 17:08
link: www.perlfoundation.org/parrot/index.cgi?pipp
jonathan OK. 17:16
Damage not actually that bad.
Failed 8/211 test scripts. 29/6377 subtests failed.
particle wow
jonathan I was expecting worse.
Of course, I may always have done something wrong... ;-) 17:17
dalek r32390 | jonathan++ | rakon: 17:20
: [rakon] Move us away from having an infix:= method to having an infix:= function. Also rip out the usage of assign; we're just using copy now.
diff: www.parrotvm.org/svn/parrot/revision?rev=32390
Coke if type ids are being removed, does anyone see a point in keeping t/op/types.t? (esp if find_type is the next thing to go) 17:23
17:25 Theory joined
barney Shouldn't the copyright lines be changed to 'The Parrot Foundation' ? 17:25
Coke not yet. 17:26
eventually, that's the plan.
barney k 17:27
particle we're working on it, barney. in fact, i have some docs from our lawyer to review
nopaste "Coke" at 193.200.132.135 pasted "remove find_type opcodes" (1292 lines) at nopaste.snit.ch/14495 17:28
Coke apparently has the least interesting board position. woot. =-) 17:29
particle coke: the MANIFEST.SKIP patch looks unrelated, sholud commit that now 17:30
also, what about removing typeof?
Coke ... one thing at a time.
particle ok, just checking
Coke MANIFEST.SKIP is only updated because it's a generated file. I can revert it. 17:31
particle no, it needs to go in
i updated pirc metadata some time ago, didn't regen the skipfile
Coke ok. any problem removing those test files?
particle not that i can see
17:32 ruoso joined
dalek r32391 | bernhard++ | trunk: 17:35
: #60184: [CAGE] Change the name of 'stacktrace' attribute to 'backtrace'
: changed 'stacktrace' to 'backtrace'
diff: www.parrotvm.org/svn/parrot/revision?rev=32391
Coke particle: was missing an update, kjs already fixed that. 17:36
dalek r32392 | coke++ | trunk: 17:38
: RT #48024 : remove [DEPRECATED] find_type_i_p and find_type_i_s opcodes
diff: www.parrotvm.org/svn/parrot/revision?rev=32392
r32393 | jonathan++ | rakon: 17:43
: [rakon] Rip out assign vtable method that is now no longer used. Doesn't affect any test results.
diff: www.parrotvm.org/svn/parrot/revision?rev=32393
r32394 | jonathan++ | rakon: 17:47
: [rakon] Re-instate readonly check that we lost when we stopped using assign vtable.
diff: www.parrotvm.org/svn/parrot/revision?rev=32394
jonathan BTW, it seems we don't have any spectests that test that parameters to subs are readonly by default.
jonathan smiles at moritz 17:48
moritz can amend that later
jonathan w00t
is copy and is rw should both work too
17:53 Psyche^ joined
moritz jonathan: there's a test for that in S06-traits/misc.t 18:02
tewk_ :q 18:03
jonathan moritz++ 18:04
moritz but rakudo probably dies anyway because of eval issues...
jonathan Ah. :-|
moritz and if I move the variable inside the eval string, it fails for current (trunk) rakudo. 18:05
now changed in (pugs) r22902 18:06
afk &
18:13 gryphon joined
dalek r32395 | coke++ | trunk: 18:13
: RT #48581 - remove [DEPRECATED] vtable type_keyed_str
diff: www.parrotvm.org/svn/parrot/revision?rev=32395
particle coke: 18:14
-Return the type number of the PMC indexed by a PMC, integer, or string key.
+Return the type number of the PMC indexed by a PMC or integer key.
ORLY?
purl YA RLY.
particle s/integer/string/
18:15 ambs joined 18:16 ambs left
Coke particle: I removed the string one. 18:16
... no?
(new) any typeofs that return int are going, neh? 18:17
18:19 magnachef joined
particle oh, i misread. yah. 18:20
pmichaud back 18:21
jonathan pmichaud: w/b
pmichaud: About to commit a load of .VALUE 18:22
pmichaud: Then I suggest reviewing my patches. ;-) 18:23
pmichaud okay, great, I'll take a look.
Coke valid_type_i_i ? 18:24
that's covered by deprecated type ids, neh?
jonathan pmichaud: erm...ouch....I've managed to make one spec-test infinite loop 18:25
pmichaud jonathan: just one?
purl One is none.
jonathan So far and I'm into the S29 now. 18:26
It was an IO one.
I'll tell you how much I'm failing of spectest in a moment
All sanity still pass.
pmichaud okay. if it's an IO test that doesn't surprise me too much.
jonathan Aye, that area is rather messy still. 18:27
pmichaud I'm even willing to live with an IO regression if need be.
jonathan pmichaud: Overall so far, just tossing in the changes, not incredibly much broken. 18:28
Failed 10/211 test scripts. 43/6377 subtests failed.
On spectest_regression.
pmichaud excellent. go ahead and commit that, and I can take a look.
jonathan It's going in right now....done.
pmichaud wow, a lot more changed than I expected (at least by looking at files that changed) 18:29
dalek r32396 | jonathan++ | rakon:
: [rakon] Implement !VALUE for a bunch of times and start calling it when doing item assignment (e.g. not to a Perl6Array or a Perl6Hash).
diff: www.parrotvm.org/svn/parrot/revision?rev=32396
jonathan pmichaud: Mostly defining !VALUE on the things I think need it (e.g. value types) 18:30
moritz jonathan: should I open a ticket for sub foo($x) {$x++} not croaking?
jonathan moritz: Yes, I'm not sure how we solve that yet though. ;-)
pmichaud moritz: a ticket would be fine -- I expect we can fix that when we fix increment/decrement
(since those are broken too.) 18:31
jonathan: in assignment, we also need to do a check for definedness 18:32
jonathan Of the LHS?
pmichaud no, the rhs
jonathan Right. The LHS is vivified.
pmichaud so that $x = undef; works
jonathan Yes, you're right.
pmichaud if the rhs is undefined, we can skip the type check.
jonathan More than that. 18:33
If the RHS is undefined, we need to look at the type to potentially choose the correct proto-object.
pmichaud oh, do we have to do that? 18:34
jonathan my Dog $x; # $x is a Dog
$x = undef; # $x is now a Dog proto again
erm, it's a Dog proto on line one
I was assuming stuff happened in between. :-)
pmichaud I don't think that $x = undef forces it to be a Dog proto again. 18:35
$x = foo_that_fails();
jonathan I thought that it did, since it's an undefined instance of the type.
Oh, hmm.
Interesting values of undef in typed values...
pmichaud exactly.
jonathan I think this is why Failure is a role.
I think that's what the spec says anyway... 18:36
There's not meant to be an Undef type.
pmichaud from S02: Variables with non-native types can always contain undefined values, such as Object, Whatever and Failure objects.
jonathan OK
But still, what if you do $x = undef;
What do we stick in there?
An Object of course, can work...
pmichaud undef currently returns a Failure.
jonathan But it's inconsistent.
pmichaud or we can switch it to return an Object.
jonathan my Dog $x; # $x must be a Dog proto here 18:37
pmichaud sure, that's no problem.
my Dog $x is the same as my Dog $x = Dog;
my $x is the same as my $x = Object;
jonathan Yes.
pmichaud my Dog $x simply means that $x is constrained to hold a Dog, or an undefined value. 18:38
jonathan So my Dog $x; $x = undef; # you think shouldn't have an undefined Dog here as in the proto?
I thought I'd read/heard somewhere that's how it should work.
I may be confused and we only do it like that at the point of declaration though.
pmichaud I think it may have changed recently (in response to issues of how to increment a protoobject) 18:39
jonathan OK
So let's just skip the type check, anyway.
pmichaud correct.
jonathan Do you want to add that, or shall I? 18:40
pmichaud you can do it -- I'm still reviewing changes.
jonathan OK
Should we change undef to return Object? 18:42
pmichaud Object still needs some work on it.
jonathan Not that it matters for now...
OK
pmichaud yes, I think I'd prefer to get assignment working first and then we can revisit Object.
jonathan OK.
pmichaud I'm also hoping to get the vtable functions (get_bool, get_string, etc.) working properly
jonathan Yes. Not to mention increment, decrement... 18:43
pmichaud those are actually pretty simple -- I could probably go ahead and add them.
dalek r32397 | coke++ | trunk: 18:44
: RT #48024 - remove valid_type_i_i opcode, which depends on long [DEPRECATED] integer type ids.
diff: www.parrotvm.org/svn/parrot/revision?rev=32397
jonathan Put in the patch for undef. 18:45
pmichaud but I'll wait until we're done with assignment. :-)
dalek r32398 | jonathan++ | rakon:
: [rakon] Allow assignment of undef value always.
diff: www.parrotvm.org/svn/parrot/revision?rev=32398
jonathan Yes. Let's triage the things we (uh, I ;-)) broke.
pmichaud since ObjectRef isn't a subclass of Object, I don't think we need the check for it in Object.!VALUE 18:49
or Perl6Array.!VALUE 18:50
jonathan Yes, but since ObjectRef delegates all of its methods, this is where we end up when we do have an ObjectRef. 18:51
pmichaud oh, I see what's happening, though.
yes, you're right.
But cannot Perl6Array and Perl6Hash simply inherit from Object.!VALUE ?
i.e., do they need their own !VALUE ?
I'm think the general case is that they simply inherit from Object 18:52
the value types are the "special case", even though there are more of them in the builtins.
jonathan No, because Perl6Hash inherits from Mapping, which has value semantics and so returns itself. 18:53
So we have to re-override to get the reference semantics.
Hash isa Mapping isa Object 18:54
pmichaud actually, Mapping promotes to Hash
but yes, I get the point. 18:55
it's almost worth defining a special !VALUE method on ObjectRef that intercepts all of those cases. 18:56
jonathan Well, we'd have to hack it into find_method.
Because we override that at the moment... 18:57
pmichaud don't we already do something similar for Scalar/Mutable?
jonathan No.
pmichaud then how do readonly/rw work ? 18:58
(methods on ObjectRef)
(methods on ObjectRef, that used to be on Mutable) 18:59
18:59 mberends joined
jonathan We used MutableVAR to handle that case. 19:00
pmichaud okay.
jonathan Though now Perl6Scalar is going away, that does get interesting again. 19:01
pmichaud well, I think we'll still have a VAR of some sort
jonathan Sure. I think it'll do stuff with the properties hash.
pmichaud exactly.
and we'll still have something kinda like Perl6Scalar to be able to deal with parameters. 19:02
(I think.)
jonathan Yes.
pmichaud oh. 19:03
perhaps !VALUE in Object/Hash/Array/Mapping/List should just return .item() ?
I'm even curious if !VALUE and .item are in fact the same at some point. 19:04
I kept them separate for now and in the description simply so that we didn't trap ourselves into believing they were the same before we conclusively proved it. 19:05
but in those classes where they have the same semantics, we should probably go ahead and treat them that way.
jonathan I removed the call to .item and replaced it with .'!VALUE' in infix:=
pmichaud yes, that's correct.
that's what I want to do for now. 19:06
but perhaps Hash.!VALUE should really simply do .tailcall self.'item'()
jonathan OK. So we've got
(9 subtests UNEXPECTEDLY SUCCEEDED), 1503 subtests skipped.
Failed 10/211 test scripts. 43/6378 subtests failed.
pmichaud This is excellent. jonathan++
jonathan pmichaud: But it also needs to make a ref to it, or should .item do that too?
pmichaud well, yes.
jonathan OK. And .item in List also? 19:07
pmichaud yes.
jonathan OK
pmichaud want to do that first or fix the failures?
jonathan Let's do that.
pmichaud actually, I'd like to know what the failures are, first.
they might shed some light on the overall issue. 19:08
jonathan I can nopaste
pmichaud yes, please.
nopaste "jonathan" at 85.216.157.73 pasted "currently failing" (15 lines) at nopaste.snit.ch/14496
jonathan t\\spec\\S12-class\\declaration-order.t we can ignore
t\\spec\\S16-filehandles\\io_in_while_loops.t - was the one I thought was infinite. Turns out maybe it's not ;-) 19:09
pmichaud say.t and undef.t are the ones that we should look at.
and assigning-r
jonathan Yes. 19:10
pmichaud (updating and trying those to understand them better)
dalek r32399 | coke++ | trunk: 19:12
: Remove usage of [DEPRECATED] typeof opcode.
: This opcode wasn't even used. Be nice if we had a -w flag that warned us about unused register assignments.
diff: www.parrotvm.org/svn/parrot/revision?rev=32399
jonathan One is about array stringification. 19:13
ok4-saystringifiesitsargs
That's from say.t
It may be some of the other tests use that to check expected array output, so fixing that may fix others.
pmichaud I'm guessing that the arrayref isn't stringifying properly, then? 19:14
19:14 chromatic joined
jonathan The code is just 19:15
my $arrayref = <ok 4 - say stringifies its args>;
say $arrayref;
So yes, I suspect so. 19:16
pmichaud oh!
we probably need to fix flatten
I'm surprised we didn't get more failures.
chromatic TimToady, I just had a conversation with Al Aho. What a fascinating guy! 19:17
Coke chromatic: You're just jealous your nick isn't alliterative.
chromatic I can't float either. 19:18
jonathan pmichaud: Oh, good point. :-)
Coke man is make test noisy. :| 19:19
jonathan pmichaud: I'm just going to take a break for 20-30 minutes to eat the pasta/bolog I've just cooked up.
particle al came up in a phone conversation i had last night
pmichaud that works for me -- I'll keep looking at this stuff, and I need to run another errand quickly
so 20-30 mins is about right.
jonathan nice 19:20
dalek r32400 | coke++ | trunk: 19:27
: remove usage of [DEPRECATED] integer typeof opcode.
diff: www.parrotvm.org/svn/parrot/revision?rev=32400
Coke anyone know what t/op/01-parse_ops.t is testing? 19:29
(it has a reference to typeof; when I remove various typeof ops, the test fails, and it is unclear why. 19:30
chromatic If it's what I think it is, it tests that IMCC recognizes various ops. 19:31
Coke hurm. I wonder if I'm missing a generated file here. lemme start from scratch. 19:32
chromatic You need to regenerate Parrot::OpLib::core.
Coke doing a realclean; that should do it. 19:33
particle yep 19:34
Coke ... nope. wtf. 19:39
chromatic Also remove 'typeof' from %parse_errors in the test. 19:41
Coke chromatic: yes, but why? 19:42
typeof is still an opcode...
chromatic Wish I could tell you. 19:43
jonathan pmichaud: back 19:45
Coke chromatic: that's the fix, though. ah well. 19:50
TimToady chromatic: yes indeed # re: AA 19:51
pmichaud back also 19:52
jonathan pmichaud: Any luck fixing up !flatten? 19:54
pmichaud jonathan: I'm thinking I may want to re-do list/item/flatten
I did a trace on what we have now, and there's a lot of building and unpacking of lists taking place 19:55
one thing I'm thinking is that cloning an ObjectRef should not be delegated
i.e., it should actually clone the Objectref
(this is separate from doing $ref.clone(), which *would* invoke the clone method.
jonathan You mean VTABLE_clone, right?
pmichaud yes. 19:58
jonathan OK, I can do that.
Rationale? Are you expecting doing it to fix something? 19:59
pmichaud well, if I do $b = (1,2,3); $a = $b; then I expect $a and $b to refer to the same object 20:00
if we have ObjectRef's clone vtable simply create a clone of the ObjectRef (and not the underlying object), then we get exactly what we expect
jonathan Oh, yes 20:01
Working on it. :-)
pmichaud does it work to simply keep the VTABLE_clone from being delegated, similar to what we do for set_prop and get_prop? 20:02
or does it need its own clone entry?
jonathan I think it needs its own clone entry.
pmichaud okay.
I haven't written many PMCs so I'm never quite certain. :-)
jonathan Well, otherwise the fallback is to freeze and then thaw it, but that's likely going to freeze what it refers to as well, and means we also have to override freeze and thaw and...well, no. :-) 20:03
dalek r32401 | coke++ | trunk:
: remove [DEPRECATED] opcodes: typeof_i_p, typeof_i_p_ik, typeof_i_p_k, typeof_s_i
: which all depend on integer type ids. 20:04
diff: www.parrotvm.org/svn/parrot/revision?rev=32401
pmichaud clone should be simple to write at any rate :-)
and it might not work out in the long run, but it seems natural at this point.
jonathan pmichaud: Should it matter if I don't carry the properties across? Since when we then do copy we ignore them anyway... 20:07
pmichaud we don't want the properties.
jonathan ok
pmichaud properties are part of the PMC (container), not the value.
jonathan OK, testing the change. 20:08
pmichaud can you go ahead and commit so I can play?
also, did you notice that there's now a C<Nil> type? ;-) 20:09
jonathan Done 20:10
Coke chip has closed ticket # 55580. whee
dalek r32402 | jonathan++ | rakon:
: [rakon] Make clone vtable method on ObejectRef clone itself rather than delegating.
diff: www.parrotvm.org/svn/parrot/revision?rev=32402
PerlJam "rakon"? 20:11
jonathan Yes, it was part of the answer to some question I asked on Tuesday I fear.
pmichaud that's fine, I'm glad it's official now.
jonathan pmichaud: See, I told you that nobody would understand the branch name. :-P
pmichaud it's okay, more reason for us to keep it short lived 20:12
PerlJam It's just the first time I've seen it.
pmichaud "rakon" is short for "rakontainer"
which is the branch where we're fixing rakudo's containers.
PerlJam okay
Coke ... hurm. I don't see them removed. perhaps it'll take a day or two. 20:16
20:19 jan joined
jonathan pmichaud: That clone chagne did some...interesting...things to our test results. 20:20
pmichaud oh, I bet it did. 20:21
jonathan (10 subtests UNEXPECTEDLY SUCCEEDED), 1503 subtests skipped.
Failed 8/211 test scripts. 69/6378 subtests failed.
We fail less test scripts, but more individual tests.
PerlJam jonathan++ woohoo! :)
pmichaud that's quite a bit better than I expected. :-)
assignment and object semantics need a rethink -- perhaps from the ground up.
jonathan Erm, isn't that just what we've been working on? 20:22
pmichaud yes.
but I mean the whole item/list/flatten/etc methods
jonathan Ah, OK.
pmichaud: The new failure is t\\spec\\S29-num\\rounders.rakudo 1 256 36 72 1-36 20:23
pmichaud that looks simple to fix. 20:24
dalek r32403 | coke++ | trunk:
: RT #48579 -- remove [DEPRECATED] vtable type_keyed_int
diff: www.parrotvm.org/svn/parrot/revision?rev=32403
jonathan OK, good.
We have less failures.
pmichaud i.e., I suspect it's a trivial thing that causes all of the failures.
jonathan Still the one with stringification.
pmichaud I'm really quite surprised we have so few.
jonathan Me too.
pmichaud the stringification is definitely a flattening issue.
jonathan OK
That may be what it all boils down to.
Oh! I need to pop to the store before it closes...it's just nearby, so won't be long at all... 20:25
Coke smacks svn. 20:26
pmichaud no problem, it's going to take me a few minutes to get in the right mindset (and close off the bool discussion in #perl6) 20:29
chromatic I read "pop to the store" and thought "Oh dear, not another exception handler problem." 20:35
Coke push_eh cliff 20:36
masak it could be if he didn't push to the store first :)
cotto EXCEPTION_FOOD_NOT_FOUND
dalek r32404 | coke++ | trunk: 20:42
: RT #48577 remove [DEPRECATED] vtable type_keyed
diff: www.parrotvm.org/svn/parrot/revision?rev=32404
jonathan RESUME # have nom now 20:44
dalek r32405 | cotto++ | trunk: 20:47
: [pipp] make grammar slightly smarter about PHP tags, plus various minor changes
diff: www.parrotvm.org/svn/parrot/revision?rev=32405
20:49 gryphon joined
cotto grrr. I got an email confirming my commit, but the svn command still hasn't completed. 20:51
pmichaud that happens sometimes.
cotto yeah. It's just annoying.
masak then the email is wrong, no? 20:54
cotto The commit was fine. It's just that my local wd didn't get updated. 20:55
pmichaud there's a handshake problem between perl.org's svn server and svn clients 20:57
the svn server finishes the commit, but the client never gets back a response saying "okay, server's finished"
so it just hangs there, or comes back with a "200 OK merge failure" or any of a number of oddities
21:05 purl joined
Coke long standing issue; there was a ticket open for a long time, but was closed because it hadn't happend in a few months. 21:06
tewk_ I'd say its 1/100 commits maybe less 21:07
Coke I see smolder.plusthree.com/app/public_pr...st_failure ... seems to be already fixed. 21:14
tewk_: are you committing from feather?
(on feather, it's happening about 8/10 atm.)
jonathan pmichaud: Well, I think we've just enumerated about every possible way to do the boolean stuff on #perl6... ;-) 21:16
Coke seen allison? 21:17
purl allison was last seen on #parrot 2 days, 2 hours, 6 minutes and 17 seconds ago, saying: heads to airport [Nov 4 19:11:15 2008]
pmichaud I'm thinking we just implement what makes the most sense to us for now, and let the test suite resolve any outstanding issues. 21:18
if it doesn't show up in the test suite, it's not really part of the spec. :-)
jonathan ;-) 21:19
Yeah, but after that discussion, I'm not sure what makes most sense any more. ;-)
particle be true to your bool! 21:25
Coke seen kjs? 21:28
purl kjs was last seen on #perl 136 days, 5 hours, 55 minutes and 27 seconds ago, saying: yo [Jun 23 15:33:30 2008]
Coke seen kj?
purl kj was last seen on #parrot 6 hours, 35 minutes and 36 seconds ago, saying: tewk++ # pirc builds on win *and* linux
Patterner true. false. filenotfound. 21:29
Coke see WhiteKnight? 21:36
seen WhiteKnight?
purl WhiteKnight was last seen on #parrot 22 hours, 39 minutes and 22 seconds ago, saying: a little too ambitious, as it turned out
jonathan pmichaud: How's flattening the bug going? 21:37
pmichaud pretty good -- just working through a few items 21:38
jonathan Great.
21:38 Aisling joined
pmichaud I'm sure I'll have it today/tonight somehow. :-) 21:38
that'll clean up a bunch of bugs
jonathan OK, great. 21:39
Is that going to be the majority that now fail, do you think?
pmichaud majority of what? ;-)
jonathan Majority of the ones in our branch! 21:40
pmichaud oh, yes, but I'm also talking about fixing a bunch of bugs in the test suite in the process
e.g., my $h = { a=>1 }; $h = 3; will end up being fixed.
jonathan Ah, I see.
Is that mistakes in the tests, or mistakes in our implementation? 21:41
pmichaud in our implementation.
jonathan OK
That example should just end up with $h holding the integer 3, right?
21:41 rdice_ joined
pmichaud yes. 21:41
jonathan OK.
pmichaud what happens at the moment (in trunk) is that $h has a Hash, so infix:= ends up trying to do a hash assignment.
in the branch $h will be an ObjectRef, so it'll just be replaced by the 3.
Coke is there some way to make 'make test' just stop whenever a test expected to pass fails? 21:42
jonathan ah, yes, that'll be better 21:44
pmichaud: So is there anything in particular in the branch you want me to look at, or should I leave you to flatten? 21:49
pmichaud I think you can leave me to flatten -- that's what I'll be doing tonight. Should have it done before you get up tomorrow. :-) 21:50
jonathan OK
pmichaud if things look clean, I'll merge to trunk.
jonathan Gotta get up early to head over to Vienna for day 1 of TCPW.
Mind if I send you over my patch for if foo() -> $x { ... } to see if you can make anything of what on earth is going wrong? 21:51
pmichaud sure, that'd be great. I might not be able to look at it until tomororw.
jonathan It works fine...until you write another statement (like a say) after the if block!
pmichaud I'm also interested in getting Junction fixed up a bit -- some of the patches that have been applied there are pretty suspect. 21:52
jonathan I'd rather just bite the bullet and fix dispatch.
pmichaud that could be done also. :-)
jonathan And then we can toss all the stuff that attempts to do it some other way.
I actually had written that as one of the things on the grant application I'm working on. 21:53
pmichaud getting that dispatch to work would be a big help, definitely.
jonathan Big bunch of stuff on dispatch, including sub methods too, which are in the same problem space.
Was going to put parametric roles on there too. 21:54
22:01 magnachef joined 22:03 TiMBuS joined 22:10 slightlyoff joined, slightlyoff left 22:13 contingencyplan joined, TiMBuS joined
jonathan moritz: Is it you that does the graph of Perl 6 test results for Rakudo? 22:14
moritz jonathan: yes
jonathan moritz: plz i can haz url?
moritz rakudo.de/
jonathan wants to put it in his talk for Twin City
pmichaud I haven't done any updates in a couple of weeks.
I'll do that tonight.
you can also get a graph from pmichaud.com/perl6
jonathan is that one any more up to date?
pmichaud it will be tonight :-) 22:15
jonathan ah, ok
I'll put the latest one in and try to update it tomorrow
moritz it's auto-generated from docs/spectest-progress.csv every 6 hour or so
pmichaud if you look at www.pmichaud.com/perl6/rakudo-tests...-10-23.png you'll see that I've changed the graph slightly 22:16
jonathan What's RSkip vs SSkip?
pmichaud the grey represents "total number of spectests"
Coke touches rakudo.
pmichaud the yellow represents "tests in spectest_regression"
moritz at least in the stacked graph
jonathan And the grey represents all spectests? 22:17
pmichaud so rskip is "tests skipped in regression suite" and sskip is "tests skipped outside of regression suite"
dalek r32406 | coke++ | trunk:
: bare .namespace is [DEPRECATED], use .namespace []
diff: www.parrotvm.org/svn/parrot/revision?rev=32406
pmichaud so I can see how quickly the entire spectest suite is growing, as well as the regression part
jonathan OK, makes sense.
pmichaud as of 10-23, we had about 9k tests in spectest
there's about 5k+ tests in the regression suite 22:18
we pass around 4400 of those.
jonathan OK, thanks
jonathan wonders what it is by now
pmichaud (er, 6k tests in regression suite)
I've already started the updates.
jonathan Thanks!
pmichaud it takes a bit of time to run them day-by-day 22:19
jonathan Oh, you run for each day? OK!
chromatic I'm working on a program that lets you schedule tasks. It might be nice.
jonathan hopes the latest graph has a bit more of an upward slope at the end
moritz it might be cron, not nice
pmichaud I've thought about doing that, but I like watching it manually
sometimes I catch things that prompt me to file tickets 22:20
I fear that the latest graph is probably somewhat flat -- hasn't been a lot of progress lately.
chromatic Not since the last release anyway.
pmichaud if I can get containers working in the next 5 hrs then we'll see an upward tick at the end :-)
chromatic I was just idly wondering if it's automatable. If it's not, then we have a problem. If it is and you prefer it this way, not a problem. 22:21
jonathan Levelled out at 25th September. ;-)
pmichaud I'm sure it can be automated -- I have a script that does most of the work. I just prefer manual for the moment.
jonathan Oh no, a bit later.
:-)
Coke if perl6 & nqp pass their tests, is it safe to close out '.namespace' vs. '.namespace []' ?
(in addition to 'make test', of course.)
jonathan Coke: It's had a deprecation cycle, I assume? 22:22
Coke yes.
pmichaud Coke: I think so, from a rakudo/nqp perspective. I don't know if any other languages are still using .namespace anywhere
jonathan I'd imagine so, then.
Coke =item * C<.namespace> (without brackets) [post 0.6.2]
jonathan Coke: Did a quick grep of the repo for .namespace\\n give anything?
Coke ... I think the "from a rakudo/nqp perspective" was obvious. I was asking for a slightly larger concensus. =-) 22:23
in the ticket, the concern was that it would break PCT; if those 2 are working, PCT isn't broken, neh?
pmichaud if those 2 are working, PCT is likely fixed. 22:24
Coke nicholas++ 22:25
22:29 slightlyoff joined 22:31 slightlyoff left
Tene Feels like I might be starting to swing back towards parrot hacking again. Maybe. 22:33
Which is good, as I'm off of work next week.
dalek r32407 | coke++ | trunk: 22:42
: RT #48549 [DEPRECATED] [PDD19] .namespace requires brackets
: Force .namespace to require brackets instead of allowing a bare directive.
: Fixup PCT to emit this (verified that nqp and perl6 still pass all tests)
: Update the documentation, fix the one core test that used the syntax.
diff: www.parrotvm.org/svn/parrot/revision?rev=32407
22:43 TonyC joined
pmichaud I'm wondering if the 'key' method in CodeString should return "[]" 22:44
instead of testing for '' explicitly in PCT
Coke pmichaud: it -is- returning [""]
PCT has a code path that doesn't use the .key() method.
pmichaud that path needs fixing then 22:47
Coke very likely. I took the patch of least resistance.
;)
it occasionally is using outerns = get_global '$?NAMESPACE' 22:48
as the string to put in the parrot .namespace directive.
pmichaud we should default that to '[]' then 22:49
i.e., $?NAMESPACE should be initially set to '[]' 22:50
then we don't end up with the case of it being an empty string.
Coke ok. have a fix. testing... 22:51
perl6.ops:63: warning: request for implicit conversion from 'void *' to 'struct PMC *' not permitted in C++ 22:54
chromatic That should be mem_allocate_typed, I think.
I meant to comment on the patch.
jonathan chromatic: Ah, yes, I expect you're right. 22:55
C++. So not a superset of C. :-) 22:56
chromatic C++ has more of a type system.
Coke pmichaud: fixed.
... as soon as svn complies.
pmichaud Coke++
jonathan chromatic: Yes, and BCPL had less of one... ;-) 22:57
jonathan wonders if anyone else encountered that languag
*language
chromatic C's type system comes from PDP assembly more than anything else.
dalek r32408 | coke++ | trunk:
: [PCT] default our NAMESPACE to the parrot representation of the top level NS so we don't have to do a fixup later.
diff: www.parrotvm.org/svn/parrot/revision?rev=32408
Coke chromatic: the type_ids branch is officially useless at this point, I think. =-)
(though trunk is still missing your fixup to remove '.Integer' and friends.) 22:58
chromatic: mind if I delete the branch?
(your patch is attached to a ticket somewhere.)
chromatic Go ahead.
That's an IMCC patch, right? 22:59
pmichaud jonathan: how hard would it be for us to implement 'is also'? 23:00
Coke chromatic: a bit, plus updates to anyone using .const .Sub 23:01
chromatic If you send me the ticket number, I'll try it on trunk.
pmichaud is the .const .Sub replacement syntax implemented yet?
chromatic I think I switched it to .const 'TypeName'
23:01 johbar joined
Coke pmichaud: It was part of the patch, IIRC 23:01
pmichaud okay.
I know that when I tried it in trunk it didn't work yet. 23:02
Coke chromatic: rt.perl.org/rt3/Ticket/Display.html?id=48024 23:03
chromatic Thanks!
23:04 PerlJam joined
dalek r32409 | coke++ | type_ids: 23:04
: Deleting crufty branch
: A lot of this work has now been applied to trunk, and most of what hasn't is
: available as patches (chromatic++) in RT. The branch itself hasn't been
: updated from trunk in some time.
diff: www.parrotvm.org/svn/parrot/revision?rev=32409
r32410 | pmichaud++ | rakon:
: [rakudo]: Clean up !flatten, !VALUE, and item in List/Array.
: * This resolves quite a few spectest failures for the branch.
diff: www.parrotvm.org/svn/parrot/revision?rev=32410
jonathan pmichaud: Not massively massively hard, but not trivial either.
I pretty much know how to do it. 23:05
Or at least, don't have any bits that I think would be incredibly hard.
To be able to add methods, it's easy. 23:06
Attributes are harder - I think the consensus was that it was meant to affect existing instances.
jonathan tries pmichaud's patch to see how much it fixes 23:07
Coke hey ack? I hit control like 30 seconds ago, mkay?
control-C even.
23:08 wolverian joined 23:09 pmichaud joined, leo joined
Coke is that a real leo sighting or a netsplit? 23:10
masak can netsplit produce fake leo sightings?
chromatic How can you tell when his birthday is anyway?
Coke when he returns and the opbots op him, yes.
masak ah. 23:11
Coke by that logic, I'm leo.
masak :)
I'm not.
jonathan pmichaud: Did you see my reply to your question about is also? 23:13
pmichaud jonathan: lost in the netsplit
dalek r32411 | coke++ | trunk: 23:14
: this op is [DEPRECATED]; make it squawk under './parrot -w'
diff: www.parrotvm.org/svn/parrot/revision?rev=32411
jonathan 00:04 <@jonathan> pmichaud: Not massively massively hard, but not trivial either.
00:05 <@jonathan> I pretty much know how to do it.
00:05 <@jonathan> Or at least, don't have any bits that I think would be incredibly hard.
00:06 <@jonathan> To be able to add methods, it's easy.
00:06 <@jonathan> Attributes are harder - I think the consensus was that it was meant to affect existing instances.
00:07 * jonathan tries pmichaud's patch to see how much it fixes
pmichaud I just need to add methods.
jonathan Oh. That's easy.
pmichaud in particular, I'd like to start writing the builtins in Perl 6.
'is also' is one of the few remaining obstacles. 23:15
Coke anyone else having feather time out on them?
s/time out/freeze/ 23:16
pmichaud me.
Coke locks up for seconds at a time. annoying.
jonathan Just should check with Allison if we are allowed to change the default semantics of Class PMC to have the classes open.
Or if she'd rather you had to pass in a flag saying they should be. 23:17
chromatic I thought that was the default semantic.
pmichaud I'm not sure I need even that.
I just want a method definition to generate the correct PIR 23:18
i.e., so that the resulting method goes into the correct namespace.
the builtins will undoubtedly be precompiled
jonathan Oh, so it may not be modification after instantiation. 23:19
In that case it's even easier. :-)
At least, to get something that basically works.
pmichaud basically I just need 'is also' to suppress generation of any code that creates the class (because it already exists)
-or-
it could go ahead and attempt to generate the class by silently fail. 23:20
s/by/but/
nopaste "pmichaud" at 76.183.97.54 pasted "current failing tests in rakon branch" (10 lines) at nopaste.snit.ch/14499 23:21
jonathan I prefer the first option.
(feather has issues...)
OK, 5 test files with regressions. 23:22
pmichaud I count 6.
jonathan t\\spec\\S12-class\\declaration-order.t doesn't count
It fails in trunk too 23:23
pmichaud right, I wasn't counting that.
jonathan oh, hmm
I just did a spectest_regression with your patch and got one less failing...hmmm
pmichaud but I suspect that S29-list/pick.t depends on random numbers.
so sometimes it fails and sometimes it does not.
jonathan No, I'm missing t/spec/S29-conversions/ord_and_ch
pmichaud did I fail to commit? 23:24
no, svn just messed up on my end.
jonathan I don't think so - I got chagnes to Array and List when I did svn up
And see less failures. 23:25
Just ain't geting that particular one.
pmichaud ah, ranges are having problem. 23:27
oh, maybe not. 23:28
hmmm.
23:29 bacek_ joined
pmichaud grrrrr 23:29
it looks like a make test harness issue again 23:30
if I run ord_and_chr directly it runs fine 23:31
if I run via "make t/spec/S29-conversions/ord_and_chr.t" it segfaults after test 54
23:32 davidfetter joined
jonathan :-| 23:32
pmichaud so I'm guessing that's not a real issue.
Coke t/pmc/fixedinterarray.t has some tests that use a deprecated opcode -and- the deprecated .FixedIntegerArray - anyone see an issue with removing those tests? 23:33
jonathan Ah, OK. Annoying though. :-(
chromatic Does the Makefile add any Parrot flags?
pmichaud chromatic: not as far as I know.
Coke be interesting to see if it fails with parrot and --runcore=gcdebug 23:34
particle pmichaud: is 54 the final test?
run the test outside the harness, then check the proc error code
davidfetter nin hao 23:35
masak nin hao, davidfetter. ni hao ma? 23:36
davidfetter hao le 23:37
davidfetter now just about out of mandarin
anybody else in beijing atm?
Coke ->
particle i'd be amazed if you were the only one in beijing atm, davidfetter
masak :)
davidfetter heh
23:38 dalek joined
davidfetter i should have been more specific, i suppose 23:38
23:41 kj joined 23:43 d4l3k_ joined
d4l3k_ r32412 | pmichaud++ | rakon: 23:44
: [rakudo]: circumfix:<[ ]> returns an ObjectRef
diff: www.parrotvm.org/svn/parrot/revision?rev=32412
cotto "200 OK" is not an error 23:48
23:49 PerlJam joined 23:50 pmichaud joined, d4l3k_ joined
pmichaud feather is definitely having issues. 23:51
Tene I can't get parrot to stop segfaulting on feather3 23:54
so no polyglotbot

Powered by Cro and the Raku® Programming Language.

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

Thank you!