Camelia, the Perl 6 bug

IRC log for #parrot, 2008-11-06

Parrot | source cross referenced

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

All times shown according to UTC.

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

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

Parrot | source cross referenced