% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.or.comcast.net
% Zaba_ has joined #parrot
% bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au
% Ademan has left Ademan!~dan@h-68-167-207-98.snfccasy.dynamic.covad.net
% bacek has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% masak has joined #parrot
% slightlyoff has left slightlyoff!~slightlyo@204.14.154.209
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
% tetragon has joined #parrot
<cizra> http://www.parrotcode.org/docs/imcc/imcfaq.html says that Named variables are either local or namespace qualified. Currently IMCC only supports locals transparently.
<cizra> What does that "transparently" mean?
% tetragon has left tetragon!~seneca@gw-312-705.somanetworks.com
% iblechbot has joined #parrot
<moritz> probably "without further action from the user"
% IllvilJa has joined #parrot
<cizra> I still don't understand.
<cizra> Oh. Right. Emphasis on "only". That is, namespace-qualifieds aren't as well supported.
% bacek has left bacek!~bacek@mcas-151.usr.optusnet.com.au
% slightlyoff has joined #parrot
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
% slightlyoff has left slightlyoff!~slightlyo@204.14.154.209
% particle1 has left particle1!~particle@c-98-232-7-104.hsd1.wa.comcast.net
% skv has joined #parrot
% Ademan has joined #parrot
% bacek has joined #parrot
% jan has left jan!~chatzilla@89-253-66-101.customers.ownit.se
% jan has joined #parrot
% jan_ has joined #parrot
% jan_ has left jan_!~chatzilla@89-253-66-101.customers.ownit.se
<bacek> t/spec/S16-filehandles/connect.t................   4    4    0    0    0    4
<bacek> pmichaud, we should remove this test from spectest_regression..
<bacek> It's useless.
<bacek> probably S29-num/complex.t too.
<bacek> t/spec/S29-str/sprintf.rakudo...................  37   37    0    0    0   37
<bacek> yak...
<bacek> all 37 tests skipped...
<jonathan> pmichaud did some work on complex numbers recently, so we should have something in spectest_regression to check what works so far.
<pmichaud> I think it's already there.
<bacek> jonathan, ok, I'll test check it.
<pmichaud> t/spec/S29-num/complex.rakudo................... 129  129    3    0    1  125
<pmichaud> 3 pass, 1 todo, 125 skip
<pmichaud> the 125 skip will be a lot less as soon as I get  -> working in infix position.
<pmichaud> although now that I look at that (what I just wrote) I'm not sure why -> doesn't work already.
<jonathan> Gets parsed as infix:-
<jonathan> And wants a term, not a >
<pmichaud> but it would need another term in order for that....
<jonathan> I think.
<pmichaud> and since there's no other term available, it should backtrack.
<jonathan> Yeah, but it doesn't backtrack.
<jonathan> Oh?
<jonathan> I didn't think the parser backtracked...
<jonathan> Apart from in a few cases...
<pmichaud> the operator precedence parser returns the longest complete expression
<jonathan> Oh, OK.
<pmichaud> (at least, it's supposed to.)
<pmichaud> I'll play with that this morning.
<jonathan> But -> isn't known to the operator precedence parser.
<jonathan> It's only in the grammar.pg
<jonathan> Cool, would be nice to have fixed. :-)
<pmichaud> -> doesn't have to be known to the operator precedence parser
<pmichaud> all the opp needs to know if that -> doesn't parse as part of a valid expression in operator position
<pmichaud> s/if/is/
% IllvilJa has joined #parrot
<jonathan> OK
<jonathan> I'll leave you, to investigate. :-)
<pmichaud> don't leave me!!!!!   er.... OK.  :-)
<jonathan> ...
<pmichaud> man I have lots of email today. :-|
<bacek> pmichaud, (about S29-num/complex.t) all other tests depends on unpolar(), which not implemented yet.
<bacek> pmichaud, yak... 3 days ago..
<pmichaud> I added unpolar().  :-)
<pmichaud> even cis() depends on unpolar().  :-)
<masak> what's unpolar()?
<pmichaud> convert from polar coordinates to rectangular (in imaginary space)
<purl> I don't know how to convert from polar coordinates to rectangular (in imaginary space).
<pmichaud> purl, I do -- use unpolar!  :-)
<pmichaud> see S29.  :-)
<masak> ok
<masak> is 'unpolar' a more clear name than 'rectcangular'?
<masak> it's not too often that things are specified by what they ain't
<pmichaud> yes, 'unpolar' was very unfamiliar to me as well.
<masak> the name is doubleplus-ungood, if you ask me
<Zaba_> polar2rectangular would work out :>
<masak> or even 'torect'
<masak> or even just 'rect()'
<masak> yes, I think 'rect()' is in the sweet spot
<masak> I'm afraid 'unpolar()' would become very unpopular ;)
% Whiteknight has joined #parrot
<dalek> r28226 | Whiteknight++ | gsoc_pdd09:
<dalek> : [gsoc_pdd09] updating to trunk r28225
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28226
<bacek> > say 4.unpolar()
<bacek> Method 'unpolar' not found for invocant of class 'Int'
<pmichaud> it's only defined on Num at the moment.
<bacek> pmichaud, got it... 
* bacek still try to understand why Int is not a Num...
<pmichaud> because Parrot doesn't have it that way in the hierarchy
<masak> but it should be, right?
<pmichaud> I don't know.  I haven't investigated that part of the spec.
<bacek> pmichaud, copy-paster unpolar in Int works fine :)
<pmichaud> I don't plan to duplicate methods if I can avoid it.
<pmichaud> as things stand now in rakudo, 4.unpolar will probably start working when we get method fallbacks working.
<pmichaud> or when we figure out the relationship between Int and Num
<Whiteknight> "make perl6" just failed for me. Segmentation fault.
<bacek> pmichaud, probably Int is Num... It's DWIM-style
<masak> I would sure hope it is
<pmichaud> yes, but I don't think that Int should carry around Num's attributes.
<pmichaud> otherwise... what's the point?
<pmichaud> so it's not a simple  "Int isa Num" relationahip.
<pmichaud> *relationship
<bacek> Num-to-Int autocoercion is an explicit exception built into the
<bacek> language.  Perl 5 programmars would lynch us if we broke it.  But yes,
<bacek> it's basically cheating.
% tetragon has joined #parrot
<bacek> Guess who :)
<bacek> (I know that it in backward direction, but I just like this quote)
<bacek> pmichaud, pugs says that Int isa Num.
<DietCoke> Nom isa Nom
<DietCoke> ... lolcode needs the ... operator, except we can call it nom nom nom.
* DietCoke <- dork
% TiMBuS has joined #parrot
<bacek> probably bang bang bang is better name :)
<bacek> Newly passing tests:
<bacek> S29-list/join.t
<bacek> S29-list/reduce.t
% particle has joined #parrot
% tetragon has left tetragon!~seneca@216.126.67.44
% iblechbot has left iblechbot!~iblechbot@103.17-dial.augustakom.net
<pmichaud> bacek: I'm not saying that we won't fix Int to Num autocoercion, I'm just saying it's not immediately obvious how to do it.
<bacek> pmichaud, adding Num as parent of Int didn't brake spectest_regression :)
% radhios has joined #parrot
<bacek> but probably autocoerce Int-to-Num will work too
<pmichaud> bacek: where did you find that quote, btw?
<bacek> Larry's mail
<pmichaud> recent email?
<pmichaud> on a mailing list?
<pmichaud> i.e., I'd like to read the surrounding conversation
<bacek> just a sec. I'll find it again :)
<bacek> http://groups.google.com/group/perl.perl6.language/browse_thread/thread/a79c24e250dbdafc
<shorten> bacek's url is at http://xrl.us/bmsmg
<bacek> Jan, 2007
<pmichaud> thanks.
<bacek> what is semantic of '<:'???
<pmichaud> in what context?
<bacek> Int <: Num
<pmichaud> oh, I have no idea.
<pmichaud> that's often true for me when looking at things TSa writes.
<pmichaud> it's not a Perl 6 operator.
<pmichaud> original is a very long thread.
<pmichaud> http://www.nntp.perl.org/group/perl.perl6.language/2007/01/msg26860.html
<shorten> pmichaud's url is at http://xrl.us/bmsmt
* bacek wants something like xmlschema-0 for perl6...
<bacek> It was so easy to implement XQuery compiler when I had full spec...
<bacek> s/0/2/
<bacek> http://www.w3.org/TR/xmlschema-2/type-hierarchy.gif
<pmichaud> (int-to-num)   I'm guessing that fallback methods will handle a lot of this for us.
<pmichaud> either that or we'll explicitly import certain methods into the Int/Num/Str scopes.
<pmichaud> that's about all I'm prepared to worry about for now.  :-)
<pmichaud> (on that topic.)
<DietCoke> (full spec) that is exactly why I concentrated on tcl instead of perl6 for so long. =-)
<bacek> yep. Fallbacks should solve all this problems...
<bacek> DietCoke, why not Smalltalk? :)
% gryphon has joined #parrot
<DietCoke> probably would have been easier, in retrospect.
% donaldh has joined #parrot
<bacek> afk # sleep... probably...
<bacek> pmichaud, JFYI, there is few tickets in RT for various List improvements.
<pmichaud> yes, I know.  Still need to look at those.
<bacek> pmichaud, ok.
* bacek ... need... more... karma... :)
<bacek> must sleep
<purl> $bacek->sleep(8 * 3600);
<bacek> Ho. Purl is back
<masak> and funny, for once
<DietCoke> purl,funny?
<purl> i guess funny is at http://www.denounce.com or at http://www.pimpdaddy.com or at http://www.pimpcity.com/humor/underpants.html or [11:09] <Chris-> but can all browsers access perl files.. i expect so or at http://www.callahanonline.com/ or at http://www.userfriendly.org/ or http://www.rahoi.com/2006/03/may-i-take-your-order.php
% nnunley has left nnunley!~nnunley@seatbelt.jerakeen.org
% nnunley has joined #parrot
% jhorwitz has joined #parrot
% Khisanth has left Khisanth!~Khisanth@pool-68-237-111-126.ny325.east.verizon.net
% Khisanth has joined #parrot
% iblechbot has joined #parrot
<DietCoke> NotFound: IANACP, but shouldn't
<DietCoke> +    STRING *full_name = 0;
<DietCoke> be
<DietCoke> +    STRING *full_name = NULL; ?
% TiMBuS has left TiMBuS!~Hurf@123-243-167-27.static.tpgi.com.au
<pmichaud> for better C coding style, yes.
% particle1 has joined #parrot
<DietCoke> NotFound: in general, the patch looks good to me, though.
% particle has left particle!~particle@c-98-232-7-104.hsd1.wa.comcast.net
<jhorwitz> DietCoke: started working on tcl registry scripts.  getting segfaults.  will debug to see whose problem it is.  ;-)
<DietCoke> me, you, or parrot, neh?
<DietCoke> I have a dynops file.
<particle1> NotFound: are Parrot_string_free_cstring and *_get_* in the strings pdd, or is this an api change that requires a pdd update?
<jhorwitz> DietCoke: i'll make sure that's being pulled in.
% particle1 is now known as particle
<particle> jhorwitz: sorry about yesterday, my phone line went dead and i had to fix it
<jhorwitz> np
<pmichaud> jhorwitz: fwiw, rakudo now has 'return'
<particle> pmichaud: did you get multivalue return working?
<jhorwitz> pmichaud++
<jhorwitz> pmichaud++
<jhorwitz> pmichaud++
<pmichaud> not yet.  I know how to do it, just want to figure out the appropriate factoring.
* particle also had to rebuild his computer, so has lost a bunch of irc history
<Whiteknight> no he didnt, and he refused to use my naive and terribly inefficient methods to do it
<particle> but now #parrot is logged, so nbd
<pmichaud> :-)
<particle> Whiteknight: how rude!
<Whiteknight> i know, right?
<jhorwitz> particle: bad day at the office, eh?
<pmichaud> yes, I'm wanting to avoid creating a hash/array for every return operation :-)
<particle> jhorwitz: to say the least...
* particle is installing parrot development dependencies atm
* particle thinks pmichaud is lazy
<PerlJam> having return means we can "easily" get to gather/take I think.  (since take is a fancy return)
<pmichaud> it's one of my vices and virtues, yes :-)
<Whiteknight> which synopsis is gather/take defined in?
<PerlJam> Whiteknight: S04 I think
<Whiteknight> i like to keep up on perl6, my interest in that is what lead me to parrot in the first place
<pmichaud> I haven't quite figured out gather/take yet.
<PerlJam> It's the same one that talks about "contend" (and is the only reference to contend that I can find anywhere)
<pmichaud> > for 1..10 -> $a { print "$a "; }; say "done";
<pmichaud> 1 2 3 4 5 6 7 8 9 10 done
<pmichaud> yay.
<dalek> r28227 | pmichaud++ | trunk:
<dalek> : [pge]:
<dalek> : * Fix backtracking bug in OPTable.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28227
<PerlJam> pm: I thought I understood gather/take until the description was reformulated to talk about Captures and such.  Now I'm fairly sure I don't quite understand them anymore.  :)
<PerlJam> But most of the magic seems to be in take and take is a fancy return AFAICT
<Whiteknight> From what I am gathering, the capture is implied based on the arguments you pass to take
<PerlJam> Whiteknight: was that a pun?  :)
<Whiteknight> ...not intentionally...
<PerlJam> Whiteknight: the last time I looked at it, it seemed the take is a no-op in a way except that it affects the return value of the gather.  i.e.   $a = $b;  is exactly the same as $a = take $b;  except that the later adds a Capture of $b to the return value of an enclosing gather.
<jonathan> pmichaud: That patch, looks like it was more frustrating to work out why was needed, than to write. ;-)
<PerlJam> but what happens when you call take without an enclosing gather?  I have no idea.
<pmichaud> jonathan: you would be entirely correct.
<jonathan> pmichaud++ # finding the bug
<masak> PerlJam: that would be an error, methinks
<PerlJam> and what if you go   gather { foo(); };  sub foo { ... take $bar }   ?
<Whiteknight> PerlJam, okay, I can see that
<jonathan> Does that mean my $x = -> $a { say $a } works now?
<masak> PerlJam: also, I'd not describe take as a no-op, since it's lazy, so take works a bit like yield in ruby
<pmichaud> was that not working before?
<pmichaud> (I don't know if it works now.)
<masak> PerlJam: that works. gather is a dynamic construct
<jonathan> It wasn't; I thought that was the bug you were chasing, actually.
<masak> I was on #perl6 when they decided that years ago
<pmichaud> well,   for 1..10 -> $a { say $a; }  works now and didn't before.
<pmichaud> my $x = -> $a { say $a; }   doesn't work
<jonathan> Ah.
<jonathan> plzicanhazfix? ;-)
<pmichaud> I don't know why that one would be failing.
<pmichaud> oh, yes I do.
<pmichaud> Yes, that's a different bug from the for 1..10 ->   one
<pmichaud> fixing  my $x = -> $a { say $a; }   will require a bit of OPTable refactoring.
<pmichaud> (the difference is the use of -> in term position versus operator position)
% uniejo has left uniejo!~uniejo@langebro.adapt.dk
<jonathan> Ah, ok
<jonathan> If it's a pain to do now, I'm not in a huge hurry for it.
<pmichaud> it's a small pain.
<pmichaud> I was thinking the two were the same bug, but apparently not.
<PerlJam> masak: that feels wrong to me for some reason.
<masak> PerlJam: the dynamicness?
<PerlJam> masak: yes.
<masak> the feeling will pass, I hope
<masak> it's wonderful!
<pmichaud> I agree that 'take' sounds more like .yield than return.
% Zaba has joined #parrot
<pmichaud> but it's essentially the same concept.
<PerlJam> pmichaud: except that yield suspends execution and take doesn't, it just grabs a Capture of its args.
<masak> PerlJam: take essentially suspends execution, yes
<pmichaud> PerlJam: except that I think that gather/take is lazy, which means we don't take until we need it.  :-)
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<masak> PerlJam: more correct to say that a request to a gather/take instigates execution :)
<PerlJam> gather/take,contend,async,lazy are all "do-like" things that all seem underspecced to me  (in that they evoke more questions than answers :)
<masak> PerlJam: in such a case, questions are exactly what is needed, so ask away
<PerlJam> well, I'm only going by memory rather than the spec, so I might just be way off base.
<masak> true.
<pmichaud> actually, some of us are noticing that questions on p6c are taking an awfully long time to get responses/answers.
<PerlJam> pm: so answer them faster!  ;)
<pmichaud> pj:  in many cases I'm the one asking the questions.  :-)
% cognominal has left cognominal!~cognomina@82.67.232.89
<PerlJam> I've noticed.
<PerlJam> But if Larry can talk to himself on mailing lists, you can too
<pmichaud> ...except I don't do language design.  :-)
<PerlJam> Larry has the toughest job.
<masak> indeed
<masak> maybe he's unusually busy right now
<DietCoke> another con coming up shortly.
* DietCoke hits the mailing list.
* DietCoke finds that the pdd25 branch is still horked.
<pmichaud> oh, I do believe he's busy, yes.
<pmichaud> afk, errands.
% Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% Whiteknight has joined #parrot
% jan_ has joined #parrot
<tewk> pmichaud: Is there a definition of \w or <wb> anywhere?
% masak has left masak!~user@130.238.45.242
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% rdice has joined #parrot
<particle> tewk: like a spec, or in the code?
* particle tries to get his env set up faster for parrot develoment
<tewk> particle: either, I guess.  I have a rule for builtin types that includes "int" however it matches against "int32_t", which it shouldn't
<particle> ah, you need to anchor the end of word
<tewk> I'd like to put  <?wb> at the end of the builtin_types rule
<particle> take a look at languages/squaak/src/parser/grammar.pm:191
<particle> token keyword { ['and'|'or']>> } # note the anchor
<tewk> I thought <?wb> and >> where the same but I'll try >>
<particle> i believe they are the same
% davidfetter has joined #parrot
<DietCoke> huh. I'm on the smolder-users mailing list.
<DietCoke> nifty: I am shoving all the mail from my desktop into my gmail account. I am now seeing current followup RT messages having history that wasn't there a week ago before i started this.
% Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% Theory has joined #parrot
<tewk> Who wants to write me a chomp opcode?
<confound> chompcode
<DietCoke> substr not good enough for ya? =-)
<DietCoke> ah, chomp, not chop.
<DietCoke> I could whip up a dynop for you.
<tewk> I could really use it, I just don't want to get off task.
<DietCoke> if this were tcl, I'd put it in my pre-existing ops file.
<DietCoke> if you can get another committer to say we need it in core, I'll add it there. =-)
<tewk> You write the op, I'll get it in as a core op, unless some one objects.
<particle> tewk: you need an opcode, or can you use a pir lib?
<tewk> There are experimental core ops, it could be a pir lib too.  We have substring, chopn as opcodes.  chomp seems like a primitive string op.
<tewk> It is definitely usefull as a pir debugging aid.
<particle> i think it exists today in pir
<particle> that's why i ask
<tewk> ahh, where
<purl> it has been said that ahh, is there a var that holds the total number of parms ?
<particle> i don't have ack installed yet
<particle> probably under runtime/parrot/library
<NotFound> runtime/parrot/library/String/Utils.pir
<tewk> I still think it should be an op, but pir would work for the time being.
<DietCoke> hokay.
<tewk> I'm hacking PGE to provide ugly trace functionality, but I can probably find a place to generate the pir include.
<tewk> offtopic, but tewk loves git.  I won't ever go back.
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
* confound too
% Zaba has joined #parrot
<NotFound> Someone bored can try my last patch in #44499 and do some benchmarking?
<tewk> rebasing is so easy, backingup local branches to arbitrary locations is easy too. 
% cjfields has joined #parrot
% particle1 has joined #parrot
<particle1> jhorwitz, DietCoke: how's the heat?
<jhorwitz> brutal
<particle1> SEATTLE -- A foot of new snow is expected Monday night for the west slopes of the north and central Cascades, the National Weather Service said in a heavy snow warning issued Monday morning.
% particle has left particle!~particle@c-98-232-7-104.hsd1.wa.comcast.net
<particle1> that's 40mi from here
% particle1 is now known as particle
<particle> we had ski resorts open on memorial day
<particle> unreal.
* jhorwitz makes an offering to his A/C compressor
<TimToady> maybe I can afford to fix my A/C this year...
<TimToady> pmichaud: I would prefer that language design questions show up in p6l, which I tend to read more frequently than p6c
<TimToady> where frequently is currently defined as less infrequently...  :/
% paggas has joined #parrot
<DietCoke> it's 90 here today.
<TimToady> was 96 here yesterday
<particle> it was 59 here yesterday
<DietCoke> TimToady: would it help if there were a queue of some kind that had a list of "things that need larry"? or is the mailing list fine?
<DietCoke> whatever's easiest for you, we can adapt.
<TimToady> p6l is best for that
<TimToady> if I don't answer something there it's usually because I'm still thinking about it
<TimToady> as opposed to not having noticed it
<particle> that's no excuse!
<particle> :P
<TimToady> well, it's getting to the point where all the easy questions have been answered, so all you ever ask is hard questions :P
<DietCoke> "why didn't you invent tcl!?"
<TimToady> John beat me to it
<particle> let's hope you beat john to perl 6
<DietCoke> bah, they're coming up on tcl 9!
<DietCoke> is just glad we didn't go the sun numbering route.
<cotto-work> NotFound, what kind of benchmark were you hoping for?
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
<cotto-work> it looks like make && make perl6 are fine with the patch
<cotto-work> s/are/works/
<particle> i had no idea parrot was born of al qaeda: http://search.cpan.org/~simon/parrot-0.0.1/
<NotFound> cotto-work: forget it, I think now that the speedup I was seeing was an illusion.
<purl> NotFound, I didn't have anything matching it, i think now that the speedup i was seeing was an illusion
<cotto-work> done
<NotFound> But anyway, it avoids a lot of leaking.
* DietCoke stares blankly at particle.
<DietCoke> (to be clear, I obviously don't think that just because they have a higher release number that they're better. =-)
<cotto-work> funny that purl doesn't ignore answers addressed to other irc users
<DietCoke> didn't Andy define a macro for string comparison? hurm.
<Andy> STREQ and STRNEQ
<Andy> rather than using strcmp() as a boolean
<DietCoke> ah, there they are.... and here they are here.
<DietCoke> ah. those are just for cstrings?
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
<DietCoke> (for parrot stuff, I can use string_equal, etc?)
<DietCoke> if (string_equal(a,b)==0) seems like bad C form, though.
* DietCoke thinks that if (! string_equal(a,b) ) is more idiomatic, yes?
<NotFound> DietCoke: agree.
* TimToady thinks strEQ is best :)
<DietCoke> NotFound: if you're bored, you could patch a great deal of src/pmc/*.pmc with that style update.
<particle> cage ticket?
<NotFound> DietCoke: What update?
<purl> update is fine it's just that people don't apply the updates or the sql-ism for it
<DietCoke> NotFound: nevermind. string_equal has return values like strcmp, so that usage is better. ah well
* DietCoke thinks we should change string_equal to just return true or vfalse, there's always string_compare if we want that return value, no?
<NotFound> We don't have discussed yet that function name?
<DietCoke> NotFound: I can't parse that send.
<DietCoke> on a different tack, what the hell benefit does the ATTR declaration give us? =-)
<NotFound> The name is completely mileading with the usage.
* DietCoke throws away this patch to tcl.
<Infinoid> NotFound: oh, I've noticed that too.  string_equal implies that it should return true when the strings are equal, but it does the opposite.
<NotFound> if ((s1 == s2) || (!s1 && !s2)) ---> What?
<NotFound> This is not the same as (s1 == s2) ?
<DietCoke> if the strings are equal or they're both null... wouldn't they be equal if they were both null?
<DietCoke> seems like.
<particle> no
<particle> not all OSes treat null comparison as eq, do they?
<particle> s/eq/==/
% paggas has left paggas!panagos@adsl27-180.lsf.forthnet.gr
<particle> i'd have to check the c89 spec
<Infinoid> uh, they should
<Infinoid> I think its a compiler thing, not an OS thing
<particle> oh, yeah, maybe compiler
<particle> that's what i think i meant. Infinoid++
<particle> could be a pessimization, check 'blame'
<DietCoke> if it's there for a reason, it should be commented.
<Infinoid> "Two null pointers, converted through possibly different sequences of casts to pointer types, shall compare equal." -- http://rm-f.net/~orange/devel/specifications/c89-draft.html
<Infinoid> (whether that's authoritative or not, I dunno, but it matches my expectations.)
<pmichaud> Parrot's "string_equal" function is totally misnamed.
<NotFound> More questions: a null STRING * is equal to an empty string? The code says yes.
<pmichaud> string_equal returns 0 when the strings are equal.  But apparently it's been like that since ~r4000 or so.
<DietCoke> Seems like a good cage task. 
<Infinoid> it would seem a lot more intuitive to call it "Parrot_strcmp" or somesuch
<NotFound> And to make the thing more funny, it returns 1 in both null-non null cases.
<DietCoke> HA!
<TimToady> anybody know if there's going to be hackathonery around OSCON?
<pmichaud> TimToady: if there is, it will be the saturday following.
<particle> aye
<pmichaud> I haven't heard the story for sunday yet.  I've reserved a room for Sunday night just in case (although my flights are currently booked for Sun also -- but those can be moved.)
<NotFound> But using strcmp style when we are interested only in equality is a vaste of time.
<TimToady> Glo is trying to figure out hotel dates...
<TimToady> .oO(strEQ)
<nopaste> "particle" at 98.232.7.104 pasted "win32+msvc svn head test failure report :(" (80 lines) at http://nopaste.snit.ch/13223
<pmichaud> the   string_equal(a,b) == 0    test is used quite a bit in Parrot.
<pmichaud> I agree that something like strEQ would be worthwhile, as longas there's not too much confusion with STREQ
<pmichaud> when I first saw   string_equal(a,b) == 0   (about 10 days ago)   my initial thought was  "What the ...?!?!"
<NotFound> But is a PARROT_API function, it must be prefixed.
<pmichaud> TimToady: okay, I'll start posting my language+spec interpretation questions to p6l
<tewk> With a name like string_equals one would think the result would be a boolean. instead we get a inverted boolean result.
<pmichaud> (instead of p6c)
<NotFound> Yes, to more confussion it does nor work really like strcmp: return 1;       /* we don't care which is bigger */
* pmichaud starts writing his #parrotsketch report.  60 mins for those keeping score.
* particle can't build perl 6
<NotFound> pdd28_strings reflects the current state?
<pmichaud> pdd28_strings reflects the wannabe state.
<pmichaud> i.e., it's a design spec but not yet implemented (iiuc)
<NotFound> Then the current implementation of string_equal is broken, IMO.
<NotFound> strlen - The length of the string, in bytes. {{NOTE, not in characters
<NotFound> So the string can be character-equal and string_equal report as not equal.
<Tene> #ps in 1 hour?
<particle> affirmative
<NotFound> And the =item says: Compares two Parrot strings, performing type and encoding conversions if necessary.
<NotFound> But the checked conversion is done *after* length comparaison.
% barney has joined #parrot
% Whiteknight has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
% Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% Whiteknight has joined #parrot
% wknight8111 has joined #parrot
% Ademan has left Ademan!~dan@c-69-181-114-208.hsd1.ca.comcast.net
% donaldh has left donaldh!~chatzilla@proxy-sjc-2.cisco.com
% donaldh has joined #parrot
<barney> Anybody knows have variable name are aliased in PAST. I tried creating an node with :pasttye('bind') and :name('infix::=') but that acted like a value assignment
% purl has left purl!purl@sentient.life
<pmichaud> :pasttype('bind') means the :name isn't going to be used for anything.
<pmichaud> a 'bind' node expects a PAST::Var as its first child, and some other expression as its second
<pmichaud> the first child is then bound to the second
% purl has joined #parrot
<barney> And how do I distinguish between assignment and aliasing ?
<pmichaud> assignment is done using an 'assign' or 'copy' opcode
<pmichaud> i.e., replace an existing PMC with a new value.
<tewk> pmichaud: I've got myself in a pge corner again.  I added >> to builtin_type so int32_t wouldn't parse as int. int32_t now parses but int doesn't.  I take out the >> and int parses but not int32_t.
<particle> umm, huh?
<particle> tewk: you have included 'int32_t'|'int' ??
<NotFound> Again on strings, the string_substr function is called by several opcodes with unchecked string register values, but does not allow a null string argument.
<particle> notfound: these items would all make excellent cage tickets
<particle> "this looks funny, what should it be converted to?" type things
<tewk> No there is a rule for parsing builtin types (int) and a different rule for parsing typedefed types.
<particle> tewk: where's the code?
<purl> well, the code is "THE CODE, I NEED THE CODE!!"
<NotFound> particle: I think that deciding if to change the signature of public api functions is not a simple cage cleaning.
<particle> notfound: yeah, i guess you're right. but they're excellent list questions or rt tickets
<particle> much better there than over irc, because more folks will be able to respond
<NotFound> Agree.
% chromatic has joined #parrot
% chromatic has changed the topic of #parrot to: Parrot 0.6.2 "Reverse Sublimation" Released | http://parrotcode.org/ | 6/661 new/open tix | logged in http://irclog.perlgeek.de/parrot/today
<NotFound> I think will be better to completely drop the nonnull parameter usage. It's almost impossible to check his correct usage from jit.
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<barney> After binding, with pasttype('bind'), a Past::Var $a to a Past::Var $b shouldn't $a change when $b is changed?
<DietCoke> questions can also go to the tracking with [RFC] in the subject.
<chromatic> NotFound, did you ever send in a CLA?
<DietCoke> PS in 5.
% Ivatar has joined #parrot
<pmichaud> barney: depends on how $b is being changed.  If $b is rebound, that doesn't affect $a.
<pmichaud> i.e., $a still remains bound to whatever $b was bound to before the rebind
<NotFound> chromatic: not yet, I expect to send it this week.
<pmichaud> NotFound: Send it in!  You may already be a winner!
<pmichaud> (probably only makes sense in the U.S.)
<DietCoke> ... if there. =-P
<barney> pmichaud: Yes, $b is rebound. That explains it.
<DietCoke> (me does get it, just poking. =-)
<pmichaud> #parrotsketch on now (for those who are interested)
% Zaba has joined #parrot
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<DietCoke> pf-proposals TV shield distributor wanted
<Tene> DietCoke: how urgently do you care about the ATTR stuff?  I just read the mails about it.
<DietCoke> tene: meh.
<DietCoke> I care more about the HLL stuff.
<chromatic> It's probably 90 minutes of work.
% Zaba has joined #parrot
<DietCoke> DOOOO it.
% allison has joined #parrot
<Tene> Maybe I'll try to finally churn through the builtins in the class hierarchy.
<Tene> for cardinal
<pmichaud> afk 
<Whiteknight> allison, question for you
% cognominal has joined #parrot
<allison> whiteknight: yes?
<Whiteknight> would it be worthwhile, perhaps in the distant future, of turning the GC into a PMC?
<PerlJam> Whiteknight: and then the GC and collect itself?  :)
<Whiteknight> well, the scheduler is a PMC now, which is motivation for the question
<allison> whiteknight: I'm trying to think of the possible benefits...
<Whiteknight> plus, we would be able to hot-swap GCs during run time, convert GC-related opcodes to PMC methods, etc
<PerlJam> s/and/can/  weird brain-o there
<allison> GC at the moment is a pile of function pointers, and some state data
<allison> but, it's a different set of function pointers than the standard vtable set
<Whiteknight> "pile of function pointers" -> methods or vtables
<allison> aye
<Whiteknight> true, it would require a little fudge
<allison> so it's definitely conceptually close to an object
<Whiteknight> I'm mostly thinking about testing, I'm looking for interfaces that would let us look into the GC for testing
<allison> I think the only benefit of making it a PMC would be related to reclaiming the memory it uses, but there's only on GC "object" for each interpreter
<Whiteknight> Anyway, this is a long way off in any case, definitely post-1.0. I could leave a few openings to prepare for it though
<Whiteknight> true, but different compilers might like different GC cores, and we could hot-swap on an eval
% Zaba_ has joined #parrot
<allison> definitely keep it in mind, especially when thinking about respecting the encapsulation boundaries of the GC
<allison> that'll give us cleaner code, even if the GC always remains as a unique kind of "object"
<PerlJam> It also sounds like you could have a GCed form of "shared memory" between interpreters.
<Whiteknight> okay, thanks for the feedback, this isn't anything i'm going to try any time soon
<cotto-work> allison, will #parrotsketch be at the same time next week?
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<PerlJam> you guys could do #ps in person if everyone goes to yapc  :)
<allison> cotto-work: we didn't make a final call in the meeting, we often skip the weekly meetings in the middle of conferences
<cotto-work> good to know
<particle> oops, missed parrotsketch
* particle notices tewk missed it too :(
<DietCoke> Executive decision, no PS.
<allison> okay, no PS next week
<DietCoke> I would like to see a writeup to the list of "what happened in parrot at yapc", though.
<Tene> Fine, I'll just hold #ps without you guys!
* cotto-work struggles to avoid executed parrot jokes
% Zaba has joined #parrot
<tewk> tewk:  was there just quiet.  I read parrotsketch religiously
<particle> tewk: you're supposed to report your weekly soc status there
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<tewk> Will do, last week was a little slow.  I've been spending my time fighting with PGE.
<wknight8111> last week was slow for me too. I've been fighting with comcast
% davidfetter has left davidfetter!~davidfett@start.fetter.org
% barney has left barney!~bernhard@dslb-084-058-096-066.pools.arcor-ip.net
<particle> why don't you two let comcast and pge fight it out?
* DietCoke finds noodles that have 0 calories.
<DietCoke> ... that's a lot of fiber.
% NotFound has left NotFound!~julian@50.Red-213-96-228.staticIP.rima-tde.net
% NotFound has joined #parrot
% sjansen has joined #parrot
<tewk> pmichaud: ping
<nopaste> "tewk" at 155.97.237.62 pasted "PGE >> troubles" (47 lines) at http://nopaste.snit.ch/13226
% cjfields has left cjfields!~cjfields@newrad.igb.uiuc.edu
<tewk> particle: I have a diff you can look at, but the above nopaste is a smaller illustration of my problem.
<particle> tewk: why use a rule and not a token?
<particle> for builtin_type?
<avar> How is "$builtin_type <ws> >>" supposed to match "int Oid;" ?
<tewk> I guess I could add an explicit <ws> between unsigned and int.
<tewk> avar thats my problem! Thanks.
<tewk> so should I write <builtin_type>>> or move the >> inside builtin_type and make builtin_type a token.
<particle> yes
<tewk> the latter I take it.
<particle> i'd make it a token, and put >> inside
<tewk> I had >> inside to start with.  I made it a rule because of the whitespace between <signed> and int, but I guess I can add that <ws> explicitly.
<tewk> Going to try it.
<tewk> Works avar++ particle++.
<particle> use <.ws> you don't need to capture it
<tewk> I wasted half a day on that one.
<avar> That should teach you to enslave irc people to write your code for you
<tewk> My problem is that I write serious PGE code once every six months and I forget everything after a month of not using it.
<particle> yeah, that is a problem
<pmichaud> file an rt ticket :-)
<particle> to:parrotbug@parrotcode.org\nsubject:write more pge\n\ndear self...
<NotFound> Maybe is better to forget all, that way you can learn the changed syntax without interferences X-)
<particle> bank &
<tewk> When things click in PGE, it is one of the most productive tools I've ever used.
<Tene> I've never really tried using anything else for parsing.
<Tene> much.
% barney has joined #parrot
% barney has left barney!~bernhard@dslb-084-058-176-219.pools.arcor-ip.net
% pjcj has left pjcj!~pjcj@84-73-177-217.dclient.hispeed.ch
<tewk> There are a lot of cool parsing tools/projects out there.  Very few are maintained at production quality over time.
% sjansen has left sjansen!~sjansen@hq-nat2.gurulabs.com
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<tewk> How do I do a charcter class in PGE these days that accepts an X or a x?    <[xX]>?
<pmichaud> yes.
% davidfetter has joined #parrot
% slightlyoff has joined #parrot
% sjansen has joined #parrot
% jhorwitz has left jhorwitz!~chatzilla@96.245.16.45
<tewk> I just parsed 4880 line c program including system headers and it only took 1:30  :).
<Infinoid> ooo
<DietCoke> if I have a macro helper(.foo), and invoke it like .helper('foo'), is there a way to get that to create a named pmc called helper_foo ?
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
<DietCoke> (I'm try to remove a bunch of boilerplate that looks up something in another namespace and provides a local pmc you can use to invoke it.)
<tewk> I'm parsing a 8000 line program and spending all my time in gc :(
<tewk> 150m RSS has been running for almost 10 minutes.
<Tene> Hm.  It might be fun to add Role support to cardinal, even though afaict it doesn't exist in ruby.
<tewk> ruby has mixins, which are similar to roles.
<chromatic> gack
<Tene> Similar, eh?
* Tene reads.
<jonathan> You can implement mix-ins with inheritance.
<chromatic> "When I suggested roles, I can tell you that I did not have mixins in mind."
<jonathan> :-)
<chromatic> Nor interfaces.
* Tene teach again bbiab.
<jonathan> Sure, but roles can be used to provide both of those too.
<tewk> Could be a bug in my code as well, but I'm in GC a lot.
<chromatic> You can drive in nails with a dull rock, but that doesn't make it a substitute for a hammer.
<chromatic> Not a *good* substitute that is.
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
<chromatic> tewk, your app should spend 25-40% of its time in GC.
<NotFound> Adding roles to RPG will be great X-)
<tewk> Well its still going so it might a bug I've introduced.
<cotto-work> chromatic, is that typical of CG-ed (dynamic) languages?
<cotto-work> s/CG/GC/
<Whiteknight> I would hope it would be towards the low end of that count, and possibly further then that
<chromatic> 10% is more reasonable.
<tewk> Its typical of unoptimized runtimes (parrot) and naive GC implmentations.
<chromatic> Our sweep is very inefficient, and global stop the world mark and sweep is somewhat inefficient.
<Whiteknight> for applications that aren't too memory intensive, GC should be negligible
<chromatic> Also for long-running applications, where there are many small allocations.
<chromatic> (In that case, avoiding memory fragmentation is a benefit.)
% IllvilJa has joined #parrot
% Limbic_Region has joined #parrot
% Khisanth has left Khisanth!~Khisanth@pool-68-237-111-126.ny325.east.verizon.net
% Khisanth has joined #parrot
<tewk> chromatic: something must be leaking somewhere, my parser is making progress but slowly.
<tewk> What can I do to profile it or provide more information?
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-205-124.dynamic.mnet-online.de
<chromatic> If you can pare down the parse file to something that runs in 30 seconds or so, you can run callgrind on the parse and see what happens.
<chromatic> A few minutes with kcachegrind should show some interesting data.
<chromatic> This presumes you're on a platform with valgrind and kcachegrind.
<tewk> It starts out fast and progressively gets slower.
<chromatic> We should be able to see trends though.
<chromatic> The problem with an O(2n) GC (and yeah, lots of handwaving to get it there) is that it gets expensive as n goes up.
<chromatic> ... but it's never *not really* expensive.
<chromatic> So it should show up in any profile that does something useful.
* tewk goes to try and find a ~30 second file to parse
% allison has left allison!~chatzilla@dsl-241-62-167.telkomadsl.co.za
% cjfields has joined #parrot
<chromatic> 15 might be better.  I've been using the Rakudo actions.pm file for profiling these past few months.
% cjfields has left cjfields!~cjfields@newrad.igb.uiuc.edu
% jan has left jan!~jan@89-253-66-101.customers.ownit.se
<chromatic> It takes about 10 minutes to run a callgrind profile, which isn't too bad.
% chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net
% chromatic has joined #parrot
% Ivatar has left Ivatar!~graham@tu055.demon.co.uk
% radhios has left radhios!~roberto@200.47.67.169
% Eevee has left Eevee!~eevee@c-67-160-3-54.hsd1.wa.comcast.net
% Eevee has joined #parrot
% Eevee has left Eevee!~eevee@c-67-160-3-54.hsd1.wa.comcast.net
% ank has joined #parrot
% Eevee has joined #parrot
% chromatic is now known as chromatic_away
% Whiteknight has left Whiteknight!~Whiteknig@c-71-230-33-251.hsd1.pa.comcast.net
% TiMBuS has joined #parrot
% grim_fandango has joined #parrot
% Eevee has left Eevee!~eevee@c-67-160-3-54.hsd1.wa.comcast.net
% Eevee has joined #parrot
<DietCoke> is there any pir syntax to call something directly from another namespace?
% slightlyoff has left slightlyoff!~slightlyo@204.14.154.209
% AndyA has left AndyA!~andy@82.152.157.85
% donaldh has left donaldh!~chatzilla@proxy-sjc-2.cisco.com
% donaldh has joined #parrot
<jonathan> DietCoke: Not that I know of; you need to look it up and then $P0(...)
% Zaba has joined #parrot
* jonathan sleeps
% AndyA has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% bacek_ has joined #parrot
% bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au
% bacek_ has joined #parrot
<DietCoke> ... you can't use [] in a macro!?
* DietCoke cries.
<DietCoke> (oh, right, this is why I haven't hacked on tcl in ages. =-)
<DietCoke> (... because I keep making wild claims about things that aren't true?)
% chromatic_away has left chromatic_away!~chromatic@sub17-30.member.dsl-only.net
% Whiteknight has joined #parrot
<Whiteknight> what is qpsmtdp?
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
<dalek> r28228 | coke++ | trunk:
<dalek> : [tcl] Delete unused file.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28228
% Whiteknight has left Whiteknight!~Whiteknig@c-71-230-33-251.hsd1.pa.comcast.net
% chromatic has joined #parrot
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
% Whiteknight has joined #parrot
% bacek__ has joined #parrot
% bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au
% rdice has joined #parrot
% gmansi has left gmansi!~gmansi@190.55.35.246
% ruoso has left ruoso!~ruoso@a81-84-237-13.cpe.netcabo.pt
<DietCoke> hey,c.
% gmansi has joined #parrot
<bacek__> morning...
<chromatic> pong
% ank has left ank!~ank@ppp59-167-200-77.lns1.hba1.internode.on.net
<DietCoke> you get my cell?
<DietCoke> ohloh--
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
% Eevee has left Eevee!~eevee@c-67-160-3-54.hsd1.wa.comcast.net
<tewk> chromatic:  http://tewk.com/nci.callgrind.out
<tewk> I ran it without any special commandline parameters
% kid51 has joined #parrot
% particle1 has joined #parrot
% Eevee has joined #parrot
% kid51 has left kid51!~jkeen@68.237.19.212
% particle has left particle!~particle@c-98-232-7-104.hsd1.wa.comcast.net
% kid51 has joined #parrot
% schobes has joined #parrot
% schobes has left #parrot
% Whiteknight has left Whiteknight!~Whiteknig@c-71-230-33-251.hsd1.pa.comcast.net
% grim_fandango has left grim_fandango!~matt@bas2-kingston08-1167934364.dsl.bell.ca
% grim_fandango has joined #parrot
% kid51 has left kid51!~jkeen@pool-68-237-19-212.ny325.east.verizon.net
<chromatic> tewk, a lot of bsr calls.  Those can get a little expensive.
<chromatic> 36% of all GC runs are due to those.  That's probably something worth optimizing in your grammar.
% sjansen has left sjansen!~sjansen@hq-nat2.gurulabs.com
<chromatic> Looks like 20% of all GC runs are due to get_string calls on PMCProxy.
<chromatic> 90% of those are getting object attributes, which I'd like to make somewhat cheaper.
<chromatic> Another ~10% of GC runs come from calling name on Object PMCs.
<chromatic> Looks like 3% of the immediate runtime costs come from converting String PMCs to STRINGs in the calling conventions.
<chromatic> Avoiding that could get you 5-7% improvement.
<chromatic> My (informed) guess is that you have a lot of backtracking in your grammar, and a couple of careful optimizations there could speed things up significantly.
% rdice has left rdice!~richarddi@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com
% davidfetter has left davidfetter!~davidfett@start.fetter.org
% tetragon has joined #parrot
% grim_fandango has left grim_fandango!~matt@bas2-kingston08-1167934364.dsl.bell.ca
% petdance has joined #parrot
% cotto_home has left cotto_home!~cotto@75-92-237-130.sea.clearwire-dns.net
% bgeron has joined #parrot
% bgeron_ has left bgeron_!bgeron@toad.stack.nl
<pmichaud> (backtracking grammar) -- yes, while tracking down a bug in PGE earlier today, I noticed quite a few bsr calls that I think we could improve on
<pmichaud> also, things will be *much* better when we have protoregexes and ltm
<pmichaud> because we can eliminate a ton of branches and backtracking
<chromatic> If you want another speedup in Rakudo parsing, fix a couple of those easy bsrs.
<pmichaud> yes
<pmichaud> currently each alternation in rules stores another backtrack point (bsr)
<pmichaud> at least, I *think* that's what happening, based on the trace I did
<pmichaud> so, an alternation with five branches ends up with four bsrs, where only one (at a time) is really needed.
<pmichaud> with protoregexes we can eliminate quite a few of those alternations
<pmichaud> but we can also generalize alternation to be a list operator instead of binary
<chromatic> If any of those are an hour or less of work, you could save a fair amount of amortized development time.
<chromatic> (The rules change when pdd25cx merges though.)
<pmichaud> protoregexes are definitely more than an hour.  Fixing Alt may be O(hour)
<pmichaud> what changes in pdd25cx merge?
<chromatic> There's no bsr/Stack_Chunk_t mess in pdd25cx.
<chromatic> So the GC characteristics of backtracking have changed somewhat.
<pmichaud> ah, yes.  But what we have instead is a bit heavier, so avoiding bsrs (or their replacement) is an even bigger win, I should think
<pmichaud> at any rate, I'm sure there will always be grammars that take the alternation approach instead of the protoregex approach, so this is a particularly useful optimization to add.
<chromatic> It's a good policy in general, but I'm not going to guess until I measure it.
<pmichaud> I was a bit surprised to see strings of 11 or so bsr's in a row.  :-)
<chromatic> That's not good.
<pmichaud> anyway, that'll be a good project for tomorrow.  far too many interesting things to work on these days :-)
<pmichaud> and I need to write some journal posts.
<chromatic> Me too.
<dalek> r28229 | chromatic++ | trunk:
<dalek> : [lib] Fixed a memory leak in isa_hash initialization for PMCs;
<dalek> : parrot_new_hash() allocates Hash memory already, so there's no need to allocate
<dalek> : it here.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28229
% tetragon has left tetragon!~seneca@76-10-171-48.dsl.teksavvy.com
<pmichaud> afk for a while
<dalek> r28230 | chromatic++ | trunk:
<dalek> : [src] Changed several runtime constant strings to compile-time constant strings.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28230
% chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net
% Eevee has left Eevee!~eevee@c-67-160-3-54.hsd1.wa.comcast.net
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Eevee has joined #parrot
% donaldh has left donaldh!~chatzilla@proxy-sjc-2.cisco.com
% donaldh has joined #parrot
% Eevee has left Eevee!~eevee@c-67-160-3-54.hsd1.wa.comcast.net
% petdance has left petdance!~Andy@64.81.227.163
<dalek> r28231 | chromatic++ | trunk:
<dalek> : [PDDs] Cleaned up PDD formatting errors from the codingstd tests.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28231
% Eevee has joined #parrot
% uniejo has joined #parrot
% Psyche^ has joined #parrot
% Patterner has left Patterner!~Psyche@e177229038.adsl.alicedsl.de
% Psyche^ is now known as Patterner
% Eevee has left Eevee!~eevee@c-67-160-3-54.hsd1.wa.comcast.net
% Eevee has joined #parrot
% Zaba has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<spinclad> BREAKING NEWS: Parrot hijacks CPAN, attacks New York!   # http://search.cpan.org/~simon/parrot-0.0.1/
<spinclad> [as noted by particle earlier]
% allison has joined #parrot