% dduncan has joined #parrot
<dduncan> I don't know if this is a known problem, but with the new Parrot 0.5.3 on CPAN, I find that the make is just stopping at certain times, where a ctrl-c unsticks it ... the first place is in perl Configure where it is checking for exuberant ctags ... system is Mac OS X Intel 10.5.2
<dduncan> I didn't have any such problems with Parrot 0.5.1 on slightly older OSs
<dduncan> 10.5.1 I think
<dduncan> is this known or should I try and narrow down a test case?
<dduncan> it also froze at a point during make
<dduncan> froze as in CPU usage is none, either case
% iblechbot has joined #parrot
<cognominal_> dduncan, I get that problem wen I get parrot with git, another when I get it with svk, it runs fine when I use rsync or svn.
<cognominal_> I have so much to read to get in speed that I don't bother to investigate right now.
<dduncan> in my case, I'm using the CPAN package
<dduncan> no worries
<dduncan> still if the cause is yet unknown, I could help more by trying 0.5.1 again under the current OS, to help rule out that the OS change was the problem
<cognominal_> also the prompt when using rakudo interactively has disappeared
% jjore is now known as jjore_away
% jjore_away is now known as jjore
<lathos> How's Parrot at cross-compiling?
<lathos> Or being cross-compiled.
<lathos> Oh, heck, looks like I'm going to need a native compiler anyway. Stupid stuff time.
% ruoso has joined #parrot
% contingencyplan has joined #parrot
<cognominal_> lathos: parrot is VM that can be JITted, I don't understand where cross-compiling fits here
% wknight8111 has joined #parrot
% AndyA has left AndyA!~andy@82.152.157.85
<lathos> I know what Parrot is. I don't know how to compile it for a machine I'm not currently running.
% AndyA has joined #parrot
<lathos> Ah well, here we go: Links are now set up to build (on i386-apple-darwin9.0.0) a native compiler for arm-apple-darwin.
<lathos> This can only end in tears.
% mire_ has joined #parrot
% dduncan has left #parrot
<svnbotl> r26065 | fperrad++ | trunk:
<svnbotl> : [WMLScript]
<svnbotl> : - add a pod coda
<svnbotl> r26066 | fperrad++ | trunk:
<svnbotl> : [Lua]
<svnbotl> r26067 | fperrad++ | trunk:
<svnbotl> : [Lua]
<svnbotl> :  - PCM LuaThread : add getfenv/setfenv methods
<svnbotl> r26068 | fperrad++ | trunk:
<svnbotl> : [emacs]
% mire__ has joined #parrot
% mire_ has left mire_!~Frodo@225-171-222-85.adsl.verat.net
% mire_ has joined #parrot
% mire__ has left mire__!~Frodo@29-171-222-85.adsl.verat.net
% mire__ has joined #parrot
% mire_ has left mire_!~Frodo@75-170-222-85.adsl.verat.net
<svnbotl> r26069 | jonathan++ | trunk:
<svnbotl> : [rakudo] Make it so you can write expressions such as my $x = <-> $y { ... }. Note that it should work for -> as well as <->, but at the moment the first is a parse error; my guess is that it's going for prefix:- rather than the longer token ->.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26069
<svnbotl> r26070 | jonathan++ | trunk:
<svnbotl> : [rakudo] Make .foo call $_.foo.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26070
% slightlyoff has left slightlyoff!~slightlyo@204.14.154.209
% kid51 has joined #parrot
<lbr> lathos: iphony parrot?
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% GeJ has joined #parrot
% GeJ_ has left GeJ_!~geraud@edna.nealab.net
% dwave_ has left dwave_!~asksolem@pat-tdc.opera.com
% dwave has joined #parrot
<svnbotl> r26071 | fperrad++ | trunk:
<svnbotl> : [Lua]
<svnbotl> :  - fix PMC LuaThread (sorry)
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26071
% teknomunk has left teknomunk!~teknomunk@kerr-dip0.nat.okstate.edu
% mncharity has left mncharity!~jobsearch@c-76-24-29-201.hsd1.ma.comcast.net
% amoore has left amoore!~amoore@CPE-24-163-202-170.kc.res.rr.com
% Dave has left Dave!~dave@pool-141-153-244-48.mad.east.verizon.net
% avar has left avar!avar@hlagh.mtfnpy
% jdv79 has left jdv79!~jdv79@u10570642.ul.warwick.net
% Crassworm has left Crassworm!~jlewis@69.25.196.248
% Khisanth has left Khisanth!~Khisanth@151.204.136.50
% spinclad has left spinclad!~rhale@209-6-140-232.c3-0.bkl-ubr2.sbo-bkl.ma.cable.rcn.com
% jrockway has left jrockway!~jrockway@dsl092-134-178.chi1.dsl.speakeasy.net
% cxreg has left cxreg!~count@62.f9.1243.static.theplanet.com
% zev has left zev!~zev@CYBERTRON.MIT.EDU
% BitPoet has left BitPoet!BitPoet@flachratte.de
% Tene has left Tene!~tene@castro.iodynamics.com
% tewk has left tewk!~tewk@ekstrom.org
% Sartak has left Sartak!~sartak@69.25.196.249
% rjbs has left rjbs!rjbs@zodiac.codesimply.com
% drforr_ has left drforr_!~drforr@eldwist.darkuncle.net
% dwave has left dwave!~asksolem@pat-tdc.opera.com
% ruoso has left ruoso!~ruoso@mail.verticalone.pt
% Patterner has left Patterner!~Psyche@e177227082.adsl.alicedsl.de
% marmic has left marmic!~chatzilla@89-253-66-101.customers.ownit.se
% Maddingue has left Maddingue!~Maddingue@profane.mongueurs.net
% c9s_ has left c9s_!~c9s@163.26.225.208
% klapperl_ has left klapperl_!~k@franz.ak.mind.de
% jq has left jq!~jquelin@merlin.mongueurs.net
% dalek has left dalek!dalek@feather.perl6.nl
% skv_ has left skv_!~skv_@87.242.97.68
% mj41_ has left mj41_!chatzilla@pc-jurosz.ro.vutbr.cz
% bgeron_ has left bgeron_!bgeron@toad.stack.nl
% svnbotl has left svnbotl!diakopter@feather.perl6.nl
% nnunley has left nnunley!~nnunley@seatbelt.jerakeen.org
% lidden has left lidden!~stefan@puce.campus.luth.se
% leo has left leo!lt@feather.perl6.nl
% pmichaud has left pmichaud!pmichaud@feather.perl6.nl
% PerlJam has left PerlJam!duff@feather.perl6.nl
% jonathan has left jonathan!jonathan@feather.perl6.nl
% kismet has left kismet!kismet@packetsync.com
% pjcj has left pjcj!~pjcj@84-73-177-217.dclient.hispeed.ch
% shorten has left shorten!~xrl@203.141.139.231.static.zoot.jp
% GeJ has left GeJ!~geraud@edna.nealab.net
% mire__ has left mire__!~Frodo@41-169-222-85.adsl.verat.net
% AndyA has left AndyA!~andy@82.152.157.85
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-199-24.dynamic.mnet-online.de
% lathos has left lathos!~simon@morison.arjam.net
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
% ilbot2 has left ilbot2!moritz@faui2k3.org
% rafl has left rafl!~rafl@62.75.161.67
% uniejo has left uniejo!~uniejo@langebro.adapt.dk
% integral has left integral!bsmith@adsl-212-20-244-147.lumison.co.uk
% cognominal_ has left cognominal_!~cognomina@82.67.232.89
% clunker has left clunker!~tomi@seatbelt.jerakeen.org
% lbr has left lbr!lbr@tux.nerdheaven.dk
% wolverian has left wolverian!wolverian@feather.perl6.nl
% Juerd has left Juerd!juerd@feather.perl6.nl
% szbalint has left szbalint!comet@dev.perl.hu
% MagNET has left MagNET!MagNET@Hunger.hu
% TonyC has left TonyC!~tony@202-154-105-237.people.net.au
% confound has left confound!hdp@floe.aq
% dngor has left dngor!abuse@adsl-068-213-211-142.sip.bct.bellsouth.net
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% Ademan has left Ademan!~dan@h-68-167-207-248.snfccasy.dynamic.covad.net
% po_boy has left po_boy!~amoore@65.165.109.82
% Coke has left Coke!~coke@cpe-72-228-52-192.nycap.res.rr.com
% nopaste has left nopaste!~opaste@202-154-105-237.people.net.au
% Alias_ has left Alias_!adam@124.188.112.79
% jjore has left jjore!~jjore@c-24-16-241-176.hsd1.mn.comcast.net
% particle has left particle!~particle@c-24-19-3-148.hsd1.wa.comcast.net
% cout has left cout!~cout@c-68-58-247-49.hsd1.sc.comcast.net
% arcady has left arcady!~arcady@dsl092-065-167.bos1.dsl.speakeasy.net
% TimToady has left TimToady!~larry@host01a.appflux.net
% rblackwe has left rblackwe!rblackwe@where.is.allmydata.net
% kid51 has left kid51!~jkeen@pool-71-247-41-158.nycmny.east.verizon.net
% Andy has joined #parrot
% kj has joined #parrot
% wknight8111 has joined #parrot
% dwave has joined #parrot
% GeJ has joined #parrot
% mire__ has joined #parrot
% AndyA has joined #parrot
% contingencyplan has joined #parrot
% uniejo has joined #parrot
% Ademan has joined #parrot
% Patterner has joined #parrot
% lathos has joined #parrot
% rafl has joined #parrot
% ilbot2 has joined #parrot
% IllvilJa has joined #parrot
% teknomunk has joined #parrot
% po_boy has joined #parrot
% Coke has joined #parrot
% mncharity has joined #parrot
% integral has joined #parrot
% Maddingue has joined #parrot
% nopaste has joined #parrot
% marmic has joined #parrot
% c9s_ has joined #parrot
% klapperl_ has joined #parrot
% jq has joined #parrot
% dalek has joined #parrot
% skv_ has joined #parrot
% mj41_ has joined #parrot
% bgeron_ has joined #parrot
% Alias_ has joined #parrot
% jjore has joined #parrot
% lbr has joined #parrot
% svnbotl has joined #parrot
% particle has joined #parrot
% Dave has joined #parrot
% avar has joined #parrot
% cout has joined #parrot
% nnunley has joined #parrot
% jdv79 has joined #parrot
% arcady has joined #parrot
% kismet has joined #parrot
% Crassworm has joined #parrot
% TimToady has joined #parrot
% lidden has joined #parrot
% rblackwe has joined #parrot
% clunker has joined #parrot
% Khisanth has joined #parrot
% confound has joined #parrot
% spinclad has joined #parrot
% leo has joined #parrot
% pmichaud has joined #parrot
% PerlJam has joined #parrot
% jonathan has joined #parrot
% jrockway has joined #parrot
% shorten has joined #parrot
% szbalint has joined #parrot
% pjcj has joined #parrot
% MagNET has joined #parrot
% TonyC has joined #parrot
% Juerd has joined #parrot
% wolverian has joined #parrot
% dngor has joined #parrot
% cxreg has joined #parrot
% drforr_ has joined #parrot
% zev has joined #parrot
% tewk has joined #parrot
% BitPoet has joined #parrot
% Tene has joined #parrot
% rjbs has joined #parrot
% Sartak has joined #parrot
% jhorwitz has joined #parrot
% gryphon has joined #parrot
% Andy has left Andy!~Andy@64.81.227.163
<lathos> Coke: It's not possible with Configure in its current form, since it tries to run the C programs it compiles. Which obviously won't work on a cross-compiler.
<kj> anybody who knows what this means: "positional inside named args at position 2" ?? I keep getting this when trying to parse string literals.
% po_boy is now known as amoore
% silug has joined #parrot
<particle> kj: it's a pcc error
<particle> lathos: i believe you can manually create a Parrot::Config::Generated with the values you want... but you may also need to create config.fpmc and config.h
<kj> I thought so; I have a language that has a rule quote, generated by the mk_language_shell script
<kj> but somehow it's failing on that. If i replace <string_literal: "> by <-["]>, it goes away
<kj> obviously, I just want to use the built-in string_literal rule
<kj> it seems there's something wrong with string_literal, but OTOH, that's hard to imagine, as it's so widely used, and apparently noone else has had problems
<particle> this is before pir is generated?
<kj> yeah
<particle> do you mean to use quote_expression?
<kj> ehm. not sure what you mean. 
<kj> I just used mk_language_shell
<kj> and then extended that generated grammar
<particle> <quote_expression: ...> .... ah.
<kj> (trying to implement the example language for the DLR, ToyScript)
<kj> mostly done, butthe operator table doesn't like me today, and string handling doesn't work
<pmichaud> good morning
<purl> Is it morning again?  YAWN...
<kj> morning
% ruoso has joined #parrot
<pmichaud> particle++ # removing fudge-deprecated compiler directives
<particle> i'd like to have the time to do real work on rakudo :(
<pmichaud> me too.  I'm hoping things clear up this week.  But it's not looking promising :(
<kj> ah. note to self: DO NOT name a rule "new"
<kj> *i knew it*
<pmichaud> yes, I need to get PGE to use MMD for the rules it generates
<kj> I was planning to check out the DLR, but I got distracted by their example language, toyscript. figured it'd be nice to know what is easier to use: PCT or DLR's stuff
% Andy has joined #parrot
% cognominal_ has joined #parrot
% uniejo has left uniejo!~uniejo@langebro.adapt.dk
<wknight8111> have the parrot group applied to google's summer of code?
<wknight8111> or would that be through the perl foundation?
<particle> tpf
<pmichaud> in the past we've done it via tpf
<wknight8111> that's what 
<wknight8111> i've figured
<purl> That's *WRONG!*
<wknight8111> sorry purl
% camgirl29 has joined #parrot
% lola22 has joined #parrot
<lathos> Whoa, who made this #spambot?
% camgirl29 has left camgirl29!~camgirl29@d033.dhcp212-198-248.noos.fr
% lola22 has left lola22!~lola22@d033.dhcp212-198-248.noos.fr
% iblechbot has joined #parrot
<Tene> Aw, lathos scared away the camgirl.
<particle> jhorwitz: poke
<jhorwitz> particle: ouch
<particle> I CAN HAZ MOD_LOLCODE??
<Tene> A friend that I'm visiting in Detroit is trying to persuade me to give a presentation on Parrot at penguicon.
<jhorwitz> I CAN HAZ TUITS?  :)
<pmichaud> presentation++
<particle> VISIBLE TUITS
<kj> pmichaud: when running a langauge on a command line, would it be useful to have a special TOP rule for that?
<pmichaud> kj:  I don't quite understand
<jhorwitz> particle: thanks! 
<kj> well, when you run a language on a commandline, so in interactive mode...
<jhorwitz> particle: i can slap together a registry-style lolcode pretty quickly
<kj> there's usually some special rules available
<kj> for instance, handling line-oriented languages
<kj> and some languages print the result
<kj> so for instance, python, when entering "42", it will print the result
<pmichaud> languages/abc does that
<pmichaud> so does languages/APL
<kj> let me check if that's what i'm thinking of.
<pmichaud> well, the real tricky part to interactive mode is being able to deal with multi-line inputs
<kj> right, handling for instance the "\", (to continue on the next line)
<pmichaud> well, in some interactive modes there isn't even a \
<pmichaud> (for some languages)
<kj> yeah. right.
<particle> jhorwitz: registry-style is enough for now
<pmichaud> they just know based on context that there's more to get
<kj> right. for instance, Lua i think will print the 2nd commandline prompt, which is "..." instead of ">>" (or somehting like that)
<pmichaud> at the moment I'm encouraging such things to be handled in hll-specific subclasses of HLLCompiler, rather than try to get HLLCompiler to handle it.  At least until we have an idea of a generic way of doing it.
<Tene> How possible would it be to implement something like "This text started to match this rule, but ran out of input" and throw a resumable exception that can be resumed when there is more input to continue matching?
<pmichaud> might be able to do something in the <ws> rule
<Tene> I might have hacking time tonight... was too exhausted last night when I finally got back to my hotel.
<pmichaud> essentially I think that <ws> could detect end-of-input and throw an exception that gets caught by the interactive mode of HLLCompiler.  The interactive mode could then get more input, add it to the source string (this part might be tricky), and then resume the match from where it left off.
<pmichaud> actually, as I'm thinking about it, this is a *really* good idea
<pmichaud> in fact, we might not even need the exception, since matching is resumable
<pmichaud> although the exception makes it a bit easier to track
% peeps[work] has joined #parrot
% marmic has left marmic!~chatzilla@89-253-66-101.customers.ownit.se
% marmic has joined #parrot
% jjore is now known as jjore_away
% jjore_away is now known as jjore
<svnbotl> r26072 | kjs++ | trunk:
<svnbotl> : [c99] minor grammar fixes.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26072
<Coke> Folks, I will be in meetings this afternoon and will have to miss parrotsketch.
<Coke> pmichaud: HLLCompiler stuff ; that's basically what tcl is doing now.
<Coke> real tcl (not sure about partcl) goes further and changes the prompt for secondary input.
% Theory has joined #parrot
* Coke yawns.
* Tene props Coke's mouth open with a blue marker.
% cotto__ has joined #parrot
* Coke yawns totorically.
% parrot-poke has joined #parrot
% cotto_ has left cotto_!~cotto@tide536.microsoft.com
% cotto_ has joined #parrot
% cotto__ has left cotto__!~cotto@tide536.microsoft.com
% Theory has left Theory!~Theory@h-67-101-3-107.sttnwaho.dynamic.covad.net
% Theory has joined #parrot
% Theory has left Theory!~Theory@h-67-101-3-107.sttnwaho.dynamic.covad.net
% Theory has joined #parrot
% kjs_ has joined #parrot
% kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl
% Psyche^ has joined #parrot
% kjs_ has left kjs_!~IceChat7@ip565fd420.direct-adsl.nl
% kj has joined #parrot
% Patterner has left Patterner!~Psyche@e177227082.adsl.alicedsl.de
% Psyche^ is now known as Patterner
% sjansen has joined #parrot
<TimToady> pmichaud: I've just added a <vws> rule to STD that makes it possible to capture control at the vertical whitespace boundary via either context var or method override.
% Theory_ has joined #parrot
% Theory has left Theory!~Theory@h-67-101-3-107.sttnwaho.dynamic.covad.net
% dngor has left dngor!abuse@adsl-068-213-211-142.sip.bct.bellsouth.net
% workbench has left workbench!abuse@adsl-068-213-211-142.sip.bct.bellsouth.net
% barney has joined #parrot
<pmichaud> TimToady: excellent
<jonathan> hi all
<pmichaud> hello, jonathan.  some terrific patches to rakudo this week -- thanks
<jonathan> pmichaud: Welcome, it's fun.
<jonathan> Am sure some will need tweaks...
<spinclad> #ps?
<purl> i guess #ps is where I can say "okay, these issues are really troubling/annoying/blocking"
<jonathan> I'm pondering working towards refactoring the type hierarchy so we have stuff under Any.
<pmichaud> well, when I first looked at most of them I thought "oh, that's not quite right -- need some tweaks"... then after starting to add the "tweak" I said "oh, it's right after all."
<spinclad> purl, #ps is also #parrotsketch, where committers can talk and bystanders can listen
<purl> okay, spinclad.
<jonathan> I've been meaning to do that for a while, and keep putting it off in favor of easier stuff. :-)
<pmichaud> there's quite a bit of object/class refactoring that needs to be done
<jonathan> Aye.
<pmichaud> I looked at .HLL mapping on the trip to brussels, and decided we can't really do it effectively until we get all of the class stuff cleaned up
<pmichaud> so, getting classes implemented more properly is high on my list
% chromatic has joined #parrot
<jonathan> Examples of what needs cleaning up?
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
<jonathan> I may be able to do some bits of that.
<pmichaud> well, I don't like having the "!keyword_has" methods in Object.  They work for now, but class construction really needs a more holistic view
<pmichaud> in particular, we need to make sure that protoobjects are created after each of the attributes are added
<pmichaud> (or after all of the attributes are added)
<pmichaud> maybe that's happening already, but it didn't look like it on my first scan
<chromatic> #ps time
<jonathan> I had to make sure instantiation was after attributes.
<jonathan> oops
<jonathan> I had to make sure the protoobject was created after all the attributes where added.
<jonathan> If you add more after the call to make_proto, you get a "class already instantiated" error.
<pmichaud> correct
<jonathan> OK, that's what I *think* I've implemneted.
<pmichaud> I want to clean up make_proto to be able to handle that more cleanly also
<pmichaud> anyway, Object/Any just need a re-think
<jonathan> Any isa Object, and Any is what things inherit from by default?
<jonathan> Other than Junction?
<pmichaud> yes, but I also mean for the private methods
<pmichaud> i.e., what methods exist for creating new classes, adding attributes, establishing protoobjects, etc.
<jonathan> Ah, the !has_keywords and make_proto stuff?
<pmichaud> yes
<Tene> orite, it's tuesday.
<jonathan> I was going on S12's mentioning that the meta-class was responsible for evaluating the keywords in a class definition.
<jonathan> But it felt a bit hand-wavey.
<pmichaud> oh, I hadn't seen that.  Is it newish?
<jonathan> Don't think so.
<pmichaud> I'll have to go and look for that.
<jonathan> "In either case, the code represented by ... executes at compile time as the body of a method of the metaclass, which is responsible for interpreting the keywords of the class definition. (And since a class is also a module, it also handles any module-oriented keywords. You can export subs from a class at "use" time, for instance.)"
<jonathan> In the Classes section, really near the start.
<pmichaud> ah
<jonathan> Well, the classes section is near the start. That paragraph is towards the middle/end of the classes section.
<jonathan> I can't find anything more specific, but I figure that this is the way that you get to implement your own class system.
<pmichaud> my reading caught the "executes at compile time" part but missed the "as the body of a method of the metaclass"
<pmichaud> "executes at compile time" is the same for module bodies as well
% Theory_ has left Theory_!~Theory@h-67-101-3-107.sttnwaho.dynamic.covad.net
<chromatic> (Broke MANIFEST) -- he's one of us now!
% Theory has joined #parrot
<jonathan> I'm not entirely sure what the "as the body of the metaclass" really means.
<pmichaud> as the body of a method of the metaclass :-)
<particle> i'm sure TimToady's lurking and will help clear up the spec
<jonathan> Ah, a method of...
<jonathan> Which method? :-)
<pmichaud> we get to define that :-)
<jonathan> Aha.
<pmichaud> at least, so far we get to define it :-)
<jonathan> I say we define some worker methods like keyword_worreva too. ;-)
<pmichaud> I see now where you came up with "!keyword_has" though
<pmichaud> that clears things up for me a bit, so I can review with that in mind
<jonathan> Sure. It's one of my "it may not be right, but it should be in the right kinda direction" things.
<pmichaud> anyway, I need to refactor Object and Protomaker and a few other items in order to work well with .HLL, so I'll probably tackle Any at the same time
<pmichaud> also I want to get rid of Perl6Str and just make it Str
<particle> need hll for that
<TimToady> really, all that's trying to say is that somebody somewhere has to decide what words like "has" mean, and that's probably the metaclass somehow
<TimToady> since, for instance, a role provides a different meaning of "has" that delays interpretation to composition
* particle wonders if trait_auxiliary:is can be easily made to support 'is export'
<pmichaud> which means that jonathan's implementation is following the spec
<pmichaud> so, jonathan++, again
<pmichaud> TimToady: your explanation makes sense, thanks
% IllvilJa has joined #parrot
<TimToady> and in theory a user can define a "myclass" keyword that redefines even the keywords that are recognized inside, but then we're actually tweaking syntax, not just retargeting semantics
<jonathan> particle: I think is export is not hard; I demonstrated how it can be done before.
<TimToady> and, in fact, in the current grammar, "has" is recognized everywhere, but just has no meaning outside of class/role
<pmichaud> TimToady: would "has" outside of a class or role toss an exception?
<jonathan> I guess compile time error?
<TimToady> yes
<pmichaud> same for things like "method"?
<TimToady> and sub, and pretty much all declarators
<jonathan> TimToady: Should you be able to write "self" and $.foo outside of a class or role definition?
<pmichaud> well, "sub" is good inside of any block, isn't it?
<jonathan> Like, $x = -> { self.bar(); }; $obj.$x();
<TimToady> sure, but that just means there's always a way to interpret it
% cognominal_ has left cognominal_!~cognomina@LNeuilly-152-21-102-165.w193-253.abo.wanadoo.fr
<TimToady> something is doing the declarational semantics at compile time somewhere
<chromatic> vague!
<spinclad> but precisely vague
<TimToady> jonathan: sure, you can write self outside of a method, if you want an error :)
<jonathan> A compile time one?
<TimToady> we know the signature of the current &?ROUTINE, so we know whether it has an invocant parameter
<jonathan> Ah, good point.
<TimToady> so I would think it would be detectable at compile time pretty easily
<jonathan> OK.
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
<TimToady> I don't think we want to go down the route of self being so smart it outsmarts the optimizer
<jonathan> Agree.
<jonathan> I need to re-do the way "self" works.
<pmichaud> well, PCT needs a good representation of "self", also
<jonathan> The current way I implemented it is...very...wrong.
<pmichaud> I haven't decided if "self"  is  a ::Val,  ::Var, or ::Op
<jonathan> Though I only just realized that.
<TimToady> and $.foo is just rewritten to $(self.foo)
<jonathan> Sure, that's what I implemented it as; both should make the same PAST.
<jonathan> But $.foo(...) doesn't work yet.
<jonathan> Need to peek at STD to see how it's parsed.
<TimToady> on export, with pugs we found it convenient to simply alias the exported item into a subpackage with the same name as the export tag
<TimToady> then importing a tag is simply reading the symbols out of the subpackage
<TimToady> and aliasing those into the current context
<TimToady> besides being simple, makes it really easy to introspect the subpackage
<TimToady> perhaps we could refine that
<Tene> parrot-poke?
<TimToady> given the tweak I just made to S11
<chromatic> parrot-poke 53280, 0
<TimToady> all tagsets could alias to Interface::TAG
<pmichaud> mmmmm
<TimToady> so that the Interface subpackage is all of the collected external interface in one spot
<TimToady> much like Ada separates into externals and internals
<TimToady> but Ada forces this on the user
<TimToady> whereas we just distribute the info via "is export"
<TimToady> and let the compiler pull out the interface for us
<pmichaud> I like
<TimToady> maybe Export::MyTag and such
<TimToady> or better, export::MyTag
* jonathan thinks there is more to "is export" than creating a multi-sub from a method
<TimToady> to not conflict with user-define subpackages that are generally capitalized
<TimToady> I suspect multies are automatically exported
<TimToady> probably...
<TimToady> is export is for other stuff that wouldn't automatically be exported
<jonathan> Aha, OK.
<particle> to prevent that, you'd do is !export??
<jonathan> I only remember the reference to it in S12.
<TimToady> there's no spec about autoexporting multis
<chromatic> It depends on how multi the multi is.
<jonathan> "However, you may use is export on a method definition to make it available also as a multi sub."
<TimToady> lemme think about that a bit more
<TimToady> yes, ordinarily a method is not exported
<TimToady> so it falls into the "ordinarily not exported" case
<TimToady> methods don't need to be exported to another symbol table
<TimToady> since the dispatcher can find them right where they are
<TimToady> (given appropriate typology)
<particle> only my method (...) { ... }
<Tene> Does anyone think that diagrams like http://pleasedieinafire.net/~tene/perl6.png are useful enough that it would be a good use of time to write a script to generate directly from grammar definitions?
<pmichaud> depends on how hard it is to write the script :-)
<TimToady> it's possible we shouldn't overload "is export" on methods
<particle> shouldn't be too hard to write
<TimToady> and use "is multi" or some such
<pmichaud> there are some rule calls that aren't "obvious" from a simple reading of grammar.pg
<TimToady> but we probably want to discourage aliasing of methods into other classes
<pmichaud> for example, rules written in PIR
<pmichaud> but if there's a way to have those manually added to the ones automatically found in grammar.pg, it'd probably work
<particle> approximations are better than nothing
<TimToady> people should use roles to write generic methods, not method aliases
<TimToady> biab &
<particle> pmichaud: and the pir rules could be colored or have a dashed border to show that they may be incomplete
<parrot-poke> Tene: question for me? I'm just a hanger-on so far who only plays with stuff, but very interested in parrot and rakudo
<Tene> parrot-poke: I was just curious about who you were.  The name seemed to suggest a utility bot of some sort.
<particle> ...until there's a better parser.
<Tene> particle: that would be completely possible, especially if they're manually added.
* particle has created DAGs from free-form data before
<pmichaud> there aren't that many "manually added" ones
<pmichaud> mostly having to do with quote rules
<Tene> I have three or four hours per day while I'm teaching class that I'm just idly sitting around while students work on labs.  I haven't been able to do real parrot work then, though, as I always have to have some minimal concentration focused on watching for signals from students.
<TimToady> oh, hey, it's already specced to use the EXPORT module, so some earlier me already thought of this. :)
<TimToady> s/module/subpackage/
<jonathan> TimToady: Which synopses?
<particle> tene: you should probably weight TOP so it shows up first
<TimToady> S11 "Exportation"
<jonathan> Thanks, will try and get that stuff into my head.
<pmichaud> me too
<particle> *phew* then i can ignore it for a while
<particle> :)
<pmichaud> I have to figure out how to match it with what we're doing in Parrot 
<pmichaud> but that just takes a bit of thinking time
<pmichaud> oh, I had a STD.pm question
<pmichaud> any particular reason that  anglewords and shellwords aren't using quotesnabber?
% Theory has left Theory!~Theory@h-67-101-3-107.sttnwaho.dynamic.covad.net
<svnbotl> r26073 | kjs++ | trunk:
<svnbotl> : [docs] update pct docs to mention 'infix:<<' as a way of writing instead of french quotes, which are hard to write.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26073
<jonathan> pmichaud: Did you see my commit message about the -> parse issue?
<jonathan> No hurry on it, just wanted to make sure you'd spotted it, because I think you'll be able to deal with it much more easily than i could.
% wknight8111 has joined #parrot
<svnbotl> r26074 | bernhard++ | trunk:
<svnbotl> : [Plumhead]
<svnbotl> : Update notes about Plumhead antlr3.
<svnbotl> : Regenerate Java classes with antlr.3.0.1
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26074
% dngor has joined #parrot
% cognominal_ has joined #parrot
% schmalbe has joined #parrot
% barney has left barney!~bernhard@dslb-084-058-177-183.pools.arcor-ip.net
<TimToady> pmichaud: just removed anglewords and shellwords entirely; quotesnabber(":qq",":ww") and such should be supplying the proper split semantics
<TimToady> thanks
% workbench has joined #parrot
<TimToady> (also, the circumfix defs were redundant with the quote defs)
<pmichaud> TimToady:  yay!
<pmichaud> you have no idea how happy that makes me :-)
<svnbotl> r26075 | chromatic++ | trunk:
<svnbotl> : [src] Improved performance of utf8_set_position() by about ten percent.
<svnbotl> : Avoided calling it from the two hottest paths in NQP when unnecessary.
<svnbotl> : The result is that generating Rakudo's parser actions is a whopping 2.5%
<svnbotl> : faster.  Further improvements may have to come from upgrading to fixed-width
<TimToady> pmichaud: yes I do :P
<chromatic> Can you kill variable-width encodings too?
<pmichaud> he did -- see S02.  
<chromatic> and I quote: yay
<pmichaud> Parrot just hasn't caught up with it yet. :-P
<pmichaud> chromatic: what files changed for your utf8 patch -- was it encodings/utf8 ?
<chromatic> Yes.
<pmichaud> okay, good, we shouldn't conflict then
<chromatic> A quarter of the time we spend generating PIR from NQP when building Rakudo goes into skipping ahead in UTF-8 strings.
<chromatic> ... but now it's time to try to profile PIR.
<pmichaud> well, I'm not surprised at the skipping-ahead cost -- every 'substr' operation essentially requires a skip
<chromatic> I tried to reduce the need for some of those.
<pmichaud> converting to fixed with should be a huge improvement
<chromatic> Definitely.
<purl> Absolutely!
<pmichaud> *width
<chromatic> I even unrolled a loop by hand to see if there were any possible improvements there.
<chromatic> (made things worse)
<Coke> chromatic++
<chromatic> For making things worse?
<chromatic> We'll call that the Tcl syndrome.
<Coke> no, for the speed improvements.
<Coke> I despair of tcl ever passing all tests in two concurrent releases.
<chromatic> It's a huge wad of code right now.
<Coke> yesssss?
<chromatic> I just have an easier time profiling and fixing bugs that Rakudo or Pheme tickle than I do Tcl or Lua bugs is all.
<Coke> ah. yup.
<Coke> chromatic: when I get [oops; continuation 0x75a3f8 of type 23 is trying to jump from runloop 530 to runloop 1]
<Coke> ... what does this mean to me, the HLL implementor.
<chromatic> Something's wrong in Sub, Continuation, or RetContinuation.
<Coke> so, I'm tcling a bug in parrot, then?
<chromatic> Almost certainly.
<purl> somebody said almost certainly was likely probably causing some problems, maybe
<chromatic> Unless you have a TclSub PMC or something.
<jonathan> I see that in Rakudo occasionally, too.
<Coke> chromatic: ... i do1
<chromatic> rgrjr's probably the best one to ask, then leo.
<chromatic> I looked at the context code and fled for the relative safety of the GC.
<chromatic> ... which should scare even you.
<Coke> it's a PIR subclass of Sub.
<chromatic> No fiddling with the gooey pink innards of the C data structure inside Sub?
<Coke> nope. just adding attributes to a sub.
<chromatic> That's probably not it then.
<Coke> (like "here's my HLL source".)
<Coke> Ok.
<jonathan> If it's any help, I only ever saw it in Rakudo on an exception throw.
<chromatic> For annotation on a wiki or in documentation somewhere: the easiest way to debug Parrot problems from an HLL is to dump the HLL source to PIR, then cut down the test case based on that.
<chromatic> Yeah, exceptions do weird things with contexts.
<jonathan> I suspect that'll be where the bug is.
<Coke> chromatic: for HLL's that use the PCT, sure. =-)
<chromatic> For all HLLs.
<chromatic> Unless the HLL calls Parrot's C functions directly, it has to generate PASM or PIR somehow.
<Coke> yes, but if they're not using PCT's, it no longer is the "easiest" way, necessarily, from the HLL tsandpoint.
<Coke> But yes, certainly, if we can provide a PIR example, surely.
% arbingersys has left arbingersys!~arbingers@66-193-42-195.static.twtelecom.net
<chromatic> Sure, I'm sympathetic to that point of view.
<kj> any lolcode developers around?
<Coke> vaguely.
<kj> i'm missing a file builtins/math.pir
<kj> is it me, or is it just missing
<Coke> I blame Tene!
<Coke> (yes, I don't see it in src/builtins/math.pir here on a recent update)
<kj> i just updated. nothing.
* Tene looks
% cotto__ has joined #parrot
<Tene> I guess I forgot to commit it?
<Tene> That doesn't seem likely.
<kj> RLY
<kj> well. it's not here :-)
<Tene> I thought I remembered seeing it...
<Coke> perhaps you forgot to svn add it?
<Coke> (in which case the commit would happily ignore it.)
<Tene> Looks like.
<purl> looks like is a type of verb
<Coke> purl, forget looks like
<purl> Coke: I forgot looks like
<Coke> chromatic: if I use tcl's --pir option, I can't seem to regenerate my runloop error.
<Tene> 'kay, I'll commit it shortly.  Thanks, kj.
<chromatic> Those are the ones I hate the msot.
<chromatic> most
% cotto_ has left cotto_!~cotto@tide536.microsoft.com
<particle> where's our disassembler?
<kj> tene: istr lolcode had a try/catch using "oh noes" or whatever syntax. guess I'm wrong
<Coke> wtf. I had, apparently, an unneeded clone that was screwing me up.
<chromatic> Or it could be that.
<jonathan> Hmm. We have...
<jonathan> INTVAL does(STRING* method)
<jonathan> But not a does_pmc variant of that.
<jonathan> Like isa and isa_pmc
<svnbotl> r26076 | bernhard++ | trunk:
<svnbotl> : [Plumhead]
<svnbotl> : Slight beautification of GenPastPir.g
<svnbotl> : Regenerate Java code with antlr
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26076
<Tene> http://pleasedieinafire.net/~tene/generated_perl6.png
<Tene> generated by:
<Tene> http://pleasedieinafire.net/~tene/gg.pl
<Tene> Someone propose a syntax for comments to indicate a PIR call to a rule.
% teknomunk has left teknomunk!~teknomunk@kerr-dip0.nat.okstate.edu
<Coke> chromatic: found another place where I'm getting the runloop error.
<Coke> (same error, found another way to trigger it.)
<chromatic> It's because you're calling clone too many times again.
<svnbotl> r26077 | bernhard++ | trunk:
<svnbotl> : [Rakudo]
<svnbotl> : Rakudo does not use PAST-pm, so don't mention it in ROADMAP.
<svnbotl> r26078 | tene++ | trunk:
<svnbotl> : Oops.  Forgot to add builtins/math.pir for lolcode.
<Coke> but I can only trigger it in interactive mode, or when using tcl.pbc; if I generate the pir and run that, I get the expected exception.
<chromatic> Curious.
* purl gives the small curious key to Bilbo. Thorin sits down and starts singing about gold.
<Coke> most curious.
<chromatic> One difference between PBC and PIR is that what we thaw out of PBC may not always completely match what's in memory as PIR.
<chromatic> ... if we don't restore as constant.
<jonathan> On Rakudo, it only ever occurs in interactive mode too.
<chromatic> The way to debug that is to catch the exception in gdb, figure out which thing is getting called incorrectly, and then trace whatever creates that PMC to figure out where it gets created and why.
<chromatic> My guess is that it'll get created from thawing PBC and it should be constant.
<chromatic> But that's just a guess.
<Coke> good thing I use a custom op to throw my exception. should make it easy to gdb.
<nopaste> "coke" at 72.228.52.192 pasted "?" (4 lines) at http://nopaste.snit.ch/12401
<Coke> ah. should have stepped instead of nexted.
<chromatic> A cast to nothing?
<chromatic> or is the expression on the next line?
<leo> chromatic: I'd recommend to just for now ignore that constant flag on PMC/String creation and sort out other (maybe) bugs first 
<leo> hi all btw
<Coke> chromatic: it was on teh next line.
<chromatic> leo, that should prove if we're marking all PObjs appropriately anyway...
<Coke> Ok. the issue is in throw_exception (src/exceptions.c:567) address = VTABLE_invoke(interp, handler, exception);
<Coke> run that line in this scenario, and I get the runloop error.
<chromatic> handler may be wrong
<leo> the state of current constant pools is just adding another level of complexity, which isnÄ'tpropriate at this time
<leo> it's an optimization anyway
<Coke> anything in particular I could poke at in handler?
<leo> ignoring the flag for now is easy
<leo> just keep the code and fix it later
<leo> my 2 c
<chromatic> See what creates handler, and what it should be, and if it looks invalid.
<chromatic> leo, I'll try that.
<svnbotl> r26079 | bernhard++ | trunk:
<svnbotl> : Set svn properties for new file.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26079
<leo> well, some PMCs might need mark vtables which they don't have yet, because these PMCs where all constant now - but as mailed - the mark vtable is really needed (except when the marking is defaulted inside dod.c)
<leo> s/where/where/
<leo> arg were
<chromatic> What did you think of rgrjr's purify() idea?
<cotto__> purl, karma for bernhard
<purl> bernhard has karma of 1489
<leo> as he said  their are more levels of the term "constant"
<cotto__> purl, karma for Coke 
<purl> coke has karma of 1745
<leo> currently just the GC issue is interesting for me
<cotto__> purl, karma for purl
<purl> A hell of a lot more than you cotto__, that's for sure!
<leo> constant_pool allocation that is
<leo> nothing else
<purl> nothing else is that big
<Coke> purl, forget nothing else
<purl> Coke: I forgot nothing else
<leo> immutable or not doesn't change that
<cotto__> purl--
<purl> cotto__: what?
<leo> _but_ a constant (GC-wise) PMC _shall_ not have non-constant items#
<svnbotl> r26080 | bernhard++ | trunk:
<svnbotl> : [lolcode]
<svnbotl> : Make PIR coda codingstd happy.
<svnbotl> r26081 | jonathan++ | trunk:
<svnbotl> : [rakudo] Implement smart-match for classes.
<leo> when it's impractical then don't allocate constant PMCs
<chromatic> It's the two-phase header allocation and initialization that makes this troublesome.
<leo> but for internal structures you know what you are doing, then you _might_ allocate _all_ children as constants too
<leo> if this isn't given then don't allocate constant items - of if later some shorter-lived stuff might be added or ...
<chromatic> Yeah, but everything that allocates children within a PMC has to check if the parent is constant and use a different allocator/initializer for the children.
% schmalbe has left schmalbe!~bernhard@dslb-084-058-165-149.pools.arcor-ip.net
<leo> nope - if children are added the 'adder' (inside parrot core code) has to know, if the parent is a _true_ parrot constant PMC
<chromatic> I think we're saying the same thing.
<leo> no checking and such IMHO
% Andy is now known as AndyAway
<leo> that's a matter of internal structure policies
<chromatic> The Sub PMC doesn't create all its children as constant right now.
<chromatic> Maybe that's a bad example.
<chromatic> The String PMC doesn't create its STRING as constant now by default.
<leo> last when I checked Namespace inside Sub was such a thingy
<leo> oh ...
<leo> yep
<chromatic> If the String PMC gets created as constant, it has to contain a constant STRING.
<leo> STRINGs aren't constant
<leo> yep
% jhorwitz has left jhorwitz!~chatzilla@68.163.20.62
<chromatic> If we used rgrjr's idea, we could take a PObj we know needs to be constant and, after constructing it fully, promote it and all of its PObj children recursively to constants.
<leo> if there ist the slightest chance that a non-constant item might be added to a const PMC, then don't allocate that PMC as a constant - my advice
<chromatic> Exactly.
<leo> you can't prmote it - that would change the address of that PMC which is a nono
<chromatic> You can promote it if you're the one who created it and you know nothing else has a pointer to it yet.
<Coke> (tangent) (strings aren't constant) there was a proposal at one point to eliminate strings and just have Strings. Is that still on the table?
<leo> not without another indirection in PObj structures
<leo> yes, just in that case - but are still constructing that PMC and haven't returned the address of it
<chromatic> This would be after the construction.
<chromatic> When storing a Sub into the packfile structure, for example.
<leo> then the next instruction might have already "published" the address
<chromatic> PIR instruction or C instruction?
<leo> this looks rather error-prone to me
<leo> opcode
<chromatic> I agree, we can't do it reliably between opcodes.
<chromatic> I meant from the C level.
<leo> from C code level, the C code has to know, if a constant object shall be constructed or not - by delivering on the constant flag
<leo> that's it IMHO
<chromatic> Yes, but that pushes the responsibility of allocating all children PObjs as constant to every place in every PMC that might allocate children.
<chromatic> That includes dynpmcs.
% kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl
<leo> siteds of construction of internal structures should know that policy
<leo> if not then just don't use constant PMCs ;)
<chromatic> Sure, we can publish the policy... but I don't want to debug dozens of dynpmcs that accidentally get that wrong.
<chromatic> I'd like to make it so easy to do the right thing that people don't even have the temptation to do the wrong thing even by accident.
<leo> you can check that with GC_DEBUG, if these PMCs have a mark vtable, which is walking the children
<chromatic> Sure, I know how to debug this type of problem.  I don't want to have to think about having to debug it though.
<chromatic> If we can design the system such that these types of problems never occur, even better.
<leo> with refcounting you got this problem on each allocation, with our GC system the problem is minimized to crate a proper mark vtable
<leo> but it can't reduced beyond that IMHO
<particle> no constants, no problem.
<chromatic> Or only constants in places where you *know* that it's safe to promote a PObj to a constant.
<leo> except performance and space troubles later - yes ;)
<particle> yes, when we get to 0.50+ we'll need performance and space optimizations
<particle> then constants++
<leo> chromatic: yes, indeed - that might need some changes in e.g. Sub internals to fix current problems
<chromatic> I'm sure it will.
<spinclad> (but we're already at 0.5+?)
<chromatic> 5 < 50
<leo> *g*
<chromatic> With regard to getting mark() right, I think we can almost always autogenerate it from the new PDD 17 attribute declarations.
<spinclad> (will we *ever* hit 50?)
<spinclad> (before we jump to 1?)
<chromatic> 0.50 is probably the point TPF rents me for a month and locks me in a room with various snack foods and won't let me out until I either say "We need to fix these things" or "Where's Leo?  He needs to fix this one."
<leo> I'll take a sabbatical then a dayjob ;)
<spinclad> (ah.  0.50: the boundary between the first two 80%s)
<leo> anyway - roger has brought up a point of the term constant:
* leo is seeing these defs:
<leo> constant PMC: allocate in constant pool - a GC tern 
<leo> term
<leo> immutable: contents doesn't change - is sharable threadwise
<leo> these 2 concepts are orthogonal
<leo> .
<leo> some internaĂl parrot structure have both properties - some don't
<chromatic> Aren't constants also immutable?
<chromatic> But not vice versa.
<leo> no
<leo> you can add as many constant items to a constant PMC as you like, as long as these items are constant too
<leo> it's just a GC term
<leo> as long as     PObj_constant_FLAG          = POBJ_FLAG(12),
<leo> ... involved
<chromatic> Oh.  I was thinking of swapping to the RO vtable when purifying a constant.
<leo> this would be ok for immutable := r/o constants, yes
<chromatic> That's what I had in mind.
<leo> but as said, currently it's a matter of not considering these PMCs during GC, not more
<chromatic> Right.
<leo> it's a policy thingy what is long living in the interpreter that it might be constat
<leo> e.g. the packfile with all the Subs
<leo> but not the 'eval'ed code
<chromatic> Right.
<chromatic> Probably Class PMCs.
<leo> yep
<leo> but what about dynamically built clases 
<leo> and so on
<leo> this needs a clear policy
<leo> reflected in C-structures and code
<chromatic> and lots of revising the PackFile code.
<leo> Sub was ok some time ago, then Namespaces arrived and the first breakage did happen
<chromatic> Which is kind of a mess anyway.
<leo> yep
<leo> packfile code the started marking Sub structs
<leo> then
<chromatic> I looked at mark_1_sub or whatever it is.
<leo> so some C structures aren't yet capable of dealing with constant PMCs
<chromatic> I can't convince myself that it's getting all constants in all PackFile segs.
<leo> yep that one
<chromatic> mark_1_seg
<leo> yep
<chromatic> If walking the pointer from the first packfile really works... maybe.
<leo> well, subs are marked from context code too
<chromatic> True.
<chromatic> and I suppose we could walk the constant pools during sweep and flip the live flag back to zero, but why have constant pools then?
<leo> and should be cleaned up if the context vanishes because of some eval-ish code
<chromatic> Anyone want to write a Scheme VM instead?
<leo> chromatic: indeed  - if it's not totally clear that these PMCs are persistent for the interpreter lifetime then don't create these constant
<chromatic> I can live with that rule.  I can't live without some food now though.
<chromatic> Thanks for the thoughts, leo.
% chromatic is now known as chromatic_lunch
<leo> welcome
% particle is now known as technicolor_yawn
% technicolor_yawn is now known as musical_fruit
% musical_fruit is now known as particle
<jonathan> .oO(WTF?)
<particle> ...riffing on chromatic's nick...
<jonathan> ...
<jonathan> :-)
<jonathan> Hmm. Looks like vtable method does isn't implemented anywhere.
% Andy has joined #parrot
% zaphod has joined #parrot
% x has joined #parrot
% peeps[work] has left peeps[work]!~peepsalot@bwext.kpimdp.com
% peeps[work] has joined #parrot
% chromatic_lunch is now known as chromatic
% kid51 has joined #parrot
% peeps[work] has left peeps[work]!~peepsalot@bwext.kpimdp.com
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
% Limbic_Region has joined #parrot
% iblechbot has left iblechbot!~iblechbot@110.4-dial.augustakom.net
% Theory has joined #parrot
<zaphod> I haven't been able to find anything in the docs or tests about this so far.  How is :multi(...)  in PIR supposed to interact with inheritance? 
% DarkWolf84 has joined #parrot
<chromatic> Right now it uses Manhattan distance, so... not well.
<zaphod> right now I'm getting that when a subclass declares a multi of the same name as the superclass the super's versions of the method are not in the subclass
<chromatic> Probably because of how we store them in namespaces.
<chromatic> Yick.
<chromatic> I could give you a workaround, but you probably don't want it.
<jonathan> This comes back down to the issue of, we do the real dispatch on invoke.
<zaphod> is the workaround to make a copy of the parent's Multisub for the child class?
<chromatic> Yep.
<zaphod> ugh
<chromatic> Could be worse.
<purl> Could be Java.
<jonathan> purl++
<chromatic> You don't want to know what it takes to make exporting multis into a namespace where you already have variants of that multi.
<zaphod> I tried getting around it by putting a default multi in the child class and then calling to the super with callmethodsupercc...then I discovered that callmethodsupercc wasn't implemented :P
<zaphod> Then I found the Super PMC (and then discovered that it is deprecated) which solves it as well
% x has left x!~chatzilla@host86-139-25-133.range86-139.btcentralplus.com
% iblechbot has joined #parrot
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-199-64.dynamic.mnet-online.de
% zaphod has left zaphod!~zaphod@p5B07EA48.dip.t-dialin.net
% cotto__ has left cotto__!~cotto@tide535.microsoft.com
% cotto_ has joined #parrot
% mncharity has left mncharity!~jobsearch@c-76-24-29-201.hsd1.ma.comcast.net
% Andy has left Andy!~Andy@64.81.227.163
% jjore is now known as jjore_away
% jjore_away is now known as jjore
<svnbotl> r26082 | jkeenan++ | trunk:
<svnbotl> : Remove Test::Simple, Test::More and Test::Builder from the Parrot distribution.  All are available in Perl 5.8, which is the minimum version required for building Parrot.  Fix one test file.  See http://rt.perl.org/rt3/Public/Bug/Display.html?id=38262.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26082
% sjansen has left sjansen!~sjansen@hq-nat2.gurulabs.com
<chromatic> Do we need to update META.yml and Bundle::Parrot now?
% Theory has left Theory!~Theory@dsl093-038-250.pdx1.dsl.speakeasy.net
% silug has left silug!~steve@ppp-70-225-73-194.dsl.covlil.ameritech.net
<kid51> chromatic:  I don't know what META.yml is all about, but, from looking at its contents, I suspect the answer is Yes.  Because the directory lib/Test/ no longer exists.  As for Bundle::Parrot, I suspect the answer is No.  Isn't that for non-core modules that are desirable but not mandatory?
% kid51 is now known as kid51_afk
% kid51_afk has left kid51_afk!~jkeen@68.237.8.82
<chromatic> If Parrot::Test relies on the output from a specific version of Test::Builder, we should mark that as a minimum dependency.
% Theory has joined #parrot
% kid51 has joined #parrot
<svnbotl> r26083 | jkeenan++ | trunk:
<svnbotl> : Deleting 'lib/Test' from no_index because the directory itself has ceased to be.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26083
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% parrot-poke has left parrot-poke!~mollusk@user-112vvlr.biz.mindspring.com
<svnbotl> r26084 | jkeenan++ | trunk:
<svnbotl> : Tagging trunk at r26083 so that the tcif can be synched to it.
<svnbotl> r26085 | jkeenan++ | trunk:
<svnbotl> : Deleting superfluous tag tcif-25845
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26085
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
% skv_ has left skv_!~skv_@87.242.97.68
% skv_ has joined #parrot
% skv_ is now known as skv
% svnbotl has left svnbotl!diakopter@feather.perl6.nl
* kid51 must sleep
<purl> $kid51->sleep(8 * 3600);
% kid51 has left kid51!~jkeen@pool-68-237-8-82.ny325.east.verizon.net
% svnbotl has joined #parrot
% Theory has left Theory!~Theory@64.122.42.219
<svnbotl> r26087 | chromatic++ | trunk:
<svnbotl> : [config] Use PMC type names, not dotted constants, when creating the
<svnbotl> : configuration PMC.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26087
% gabriel has joined #parrot
% Coke has left Coke!~coke@cpe-72-228-52-192.nycap.res.rr.com
% DarkWolf84 has left DarkWolf84!~dwolf@89.215.234.147
% uniejo has joined #parrot
<spinclad> re constant == not considered for GC:  an approach i've seen involved not flagging items but letting a generational compacting GC do its job on them, producing a well-localized, compact layer, depending on earlier = more core layers, and rarely to be considered for GC again.  all this would fall out of such a GC system once it's ready.  (more)
<spinclad> meantime i wonder if the cost of misflagging and correct flagging may for now outweigh the benefit of shortening GC.
<chromatic> Probably.
<purl> Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look harder.
<spinclad> (btw was my first line complete for you? should have ended in '(more)')
<chromatic> yes
<spinclad> (kthx)
% arcady has left arcady!~arcady@dsl092-065-167.bos1.dsl.speakeasy.net