% Zaba has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% bacek has joined #parrot
% masak has joined #parrot
% barney has joined #parrot
% uniejo has left uniejo!~uniejo@193.88.64.250
% bacek has left bacek!~bacek@122.110.31.242
% barney has changed the topic of #parrot to: "Parrot 0.6.4" release is underway, please update NEWS and PLATFORMS
% barney has changed the topic of #parrot to: "Parrot 0.6.4: St. Vincent Amazon" release is underway, please update NEWS and PLATFORMS
% uniejo has joined #parrot
<dalek> r29470 | bernhard++ | trunk:
<dalek> : [build] clean up generated directory lib/Parrot/OpLib
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29470
% iblechbot has joined #parrot
<barney> chromatic++  for editing NEWS
<moritz> barney++ # taking care of the release
% Debolaz has joined #parrot
<barney> pmichaud++ see above
<nopaste> "moritz" at 89.13.227.19 pasted "failure in t/tools/dump_pbc.t" (8 lines) at http://nopaste.snit.ch/13579
<moritz> anyone else seeing that?
<dalek> r29471 | fperrad++ | trunk:
<dalek> : [Pipp]
<dalek> : - add PCRE version
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29471
% bacek has joined #parrot
% bacek has left bacek!~bacek@122.110.29.171
% bacek has joined #parrot
* barney wonders whether the Bugday is worth announcing
<moritz> in case of doubt, it is ;-)
% bacek has left bacek!~bacek@122.110.78.11
<masak> oh, is it Release Day today?
<dalek> r29472 | bernhard++ | trunk:
<dalek> : [distro] Regenerated MANIFEST.SKIP
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29472
<moritz> masak: yes
<masak> \o/
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<moritz> hey, rakudo has +950 passing spectests since last release ;-)
<masak> that's really not bad.
<masak> [++] @devs
<masak> hm, that's not right :)
<masak> <<++>> @devs
<moritz> @devs >>++;
<masak> ah, right :)
<masak> Perl 6 is implemented faster than I can learn it these days :)
<moritz> that's partly true for me as well
<moritz> for example I never used generics in Perl 6, and they are implemented now
<moritz> and all this role and class stuff - I know some of it, but not really in depth
<masak> ah, yes. generics
<masak> is there a convincing use case for generics? I mean, Perl 5 is a very weakly typed language, and suddenly in Perl 6 we have generics. what are they intended for?
<moritz> give the type fetishists what they want? ;-)
<masak> hehe
<masak> are there things like Java's <? extends T> and <? super T> in Perl 6's generics capabilities?
* masak has to go read up on Sxx
<moritz> situations like "return something of the same types as you gave me" and "expect two parameters of same type" aren't all that uncommon
<masak> true
<moritz> masak: maybe there's also something interesting on http://www.dlugosz.com/Perl6/ , ISTR that he worked a bit on generics
<masak> good idea
<purl> masak: Good Idea: Stopping to smell the roses. Bad Idea: Stopping to feel the roses.
<masak> purl: your wisdom baffles me sometimes
<purl> masak: excuse me?
<masak> ...and sometimes not.
% skv has left skv!~skv_@87.242.97.68
% bacek has joined #parrot
<barney> make fulltest    looks fine under Linux
* barney is about to commit changes for Parrot 0.6.4
% tuxdna has joined #parrot
% tuxdna has left tuxdna!~saleem@122.163.54.90
% Zaba has joined #parrot
<dalek> r29473 | bernhard++ | trunk:
<dalek> : Changes for Parrot release ....
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29473
% tuxdna has joined #parrot
<dalek> r29474 | bernhard++ | trunk:
<dalek> : [docs] Pop up editor for commit message. Pasting with -m option is dangerous.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29474
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<dalek> r29475 | fperrad++ | trunk:
<dalek> : [PLATFORMS]
<dalek> : - MinGW gcc 3.4.5 updated
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29475
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-197-166.dynamic.mnet-online.de
<dalek> r29476 | bernhard++ | trunk:
<dalek> : [docs] don't recommend to use '-s',capture more verbose output from 'make'
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29476
% bacek has left bacek!~bacek@122.110.69.220
<dalek> r29477 | bernhard++ | RELEASE_0_6_4:
<dalek> : tagged release 0.6.4
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29477
% iblechbot has joined #parrot
% uniejo has left uniejo!~uniejo@193.88.64.250
% kj has joined #parrot
% ruoso has joined #parrot
% barney has changed the topic of #parrot to: "Parrot 0.6.4 "St. Vincent Amazon" Released | http://parrotcode.org/ | 15/648/80 new/open/stalled tix | logged in http://irclog.perlgeek.de/parrot/today".
<dalek> bernhard.schmalhofer@gmx.de | Parrot:
<dalek> link: http://www.perlfoundation.org/parrot/index.cgi?parrot
<barney> Parrot 0.6.4 flies, http://en.wikipedia.org/wiki/St._Vincent_Amazon
<moritz> barney++
% bacek has joined #parrot
<bacek> congratulations everyone
<masak> cheers!
<dalek> r29478 | jkeenan++ | parallel:
<dalek> : Correct wrong no. of tests in plan.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29478
% mj41 has left mj41!~chatzilla@pc-jurosz.ro.vutbr.cz
% uniejo has joined #parrot
<dalek> r29479 | jkeenan++ | parallel:
<dalek> : Consolidate multiple test files per configuration step into a single file.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29479
% mj41 has joined #parrot
<bacek> perl6: say log(-1+0i,)
<polyglotbot> OUTPUT[0␤]
<bacek> perl6: say sqrt(-1+0i,)
<polyglotbot> OUTPUT[6.12303e-17+1i␤]
<moritz> that's better ;)
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-199-11.dynamic.mnet-online.de
* barney just bought ticket for YAPC::EU
<moritz> so sad that I can't go there :(
<pmichaud> barney: ping
<pmichaud> jonathan: wednesday I'll be gone all day on a business trip, so thu or fri are better
<pmichaud> barney: you now have comaint on the modules in question -- try requesting a reindex
<moritz> pmichaud: you accidentially duplicated the "added generic type declarations" lines in NEWS
<moritz> but I noticed only after the release
<pmichaud> moritz: oops.  chromatic and I ended up editing NEWS at the same time and so I had to go clean up the conflicts
<pmichaud> and I guess I missed one.
<pmichaud> it's not too bad -- we'll just claim we added generics in two steps.  :-)
<pmichaud> "twice as generic as before!"
<moritz> should I remove one? or is NEWS a historical document that shouldn't change in retrospect?
<moritz> lol
<pmichaud> remove one.
<nopaste> "bacek" at 58.111.0.124 pasted "Complex.log() implementation for pmichaud/moritz" (30 lines) at http://nopaste.snit.ch/13583
% wknight8111 has joined #parrot
<particle> message kid51 re #56928: i haven't built parrot in two weeks, and i trust andy dougherty, so if it looks like it works fire away
<purl> Sorry, I've never seen kid51 before.
<dalek> r29480 | moritz++ | trunk:
<dalek> : [NEWS] removed (nearly) duplicate line
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29480
<moritz> bacek: I just wonder if they should really go into src/builtins/any-str.pir
<bacek> moritz: actually no.
<bacek> And forget this patch for the moment.
<purl> bacek, I didn't have anything matching this patch for the moment
<pmichaud> complex methods we've been putting into Complex
<bacek> It didn't work in 'clean' checkout
<moritz> pmichaud: ok, thanks for clarifying
<moritz> bacek: applies cleanly nonetheless, testing now
<pmichaud> =item sqrt should probably read =item log   :-)
<moritz> pmichaud: already fixed that locally
<bacek> moritz: test will fail
<pmichaud> moritz++
<moritz> I noticed, yes ;)
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<nopaste> "bacek" at 58.111.0.124 pasted "Correct Complex.log() implementation for pmichaud/moritz" (101 lines) at http://nopaste.snit.ch/13584
<bacek> much better version :)
% Zaba has joined #parrot
<bacek> moved log() to any-num
<bacek> +exported from Complex.
<pmichaud> I've been keeping the functions in alphabetical order inside of any-num.pir
<pmichaud> other than that, the patch looks good.
<bacek> pmichaud: ouch. Didn't notice it. I'll change patch
<bacek> pmichaud: 'int()' in wrong place :)
<pmichaud> I left int() next to truncate, though
<pmichaud> since they're really the same thing.
<pmichaud> but I guess it can be alphabetized also.
* barney requested reindexing
<nopaste> "bacek" at 58.111.0.124 pasted "#3 Correct Complex.log() implementation for pmichaud/moritz" (125 lines) at http://nopaste.snit.ch/13585
<bacek> with reordered functions ( int() as well)
<moritz> bacek: ok, I'll smoke & apply 
<moritz> bacek++
<moritz> ./rakudo -e 'say log(-1+0i)'
<moritz> 0+3.14159i
<bacek> log10 is harder... I can just '!EXPORT' it...
* moritz wonders if we should start implementing the two arg form of log
<moritz> and we need to test it
% gryphon__ has joined #parrot
% wknight8111 has left wknight8111!~chatzilla@66.252.102.38
% wknight8111 has joined #parrot
% Zaba_ has joined #parrot
<bacek> pmichaud: How I can invoke parent's method from child's override?
<particle> SUPER:: ??
<pmichaud> there's not a way to do it at present.
<pmichaud> at least, not that I'm aware of.
<pmichaud> do you mean a parent's vtable method or just a parent method?
<pmichaud> (a parent method in PIR)
<bacek> just method
<pmichaud> given that  class Foo is a parent of Bar
<pmichaud> if you have Foo's protoobject
<pmichaud> you can do
<pmichaud> $P0 = find_method fooproto, 'methodname'
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<pmichaud> bar.$P0(...)
<pmichaud> i.e., look up the parent method specifically and invoke it
<bacek> will it work for vtable? like bar.$P0(self,..)?
<pmichaud> no, it doesn't work for vtable, since find_method doesn't retrieve vtable methods
<bacek> ok, thanks
<pmichaud> also, you don't need to pass self, since bar is self
<pmichaud> (I meant 'bar' here to be an instance of class Bar)
<bacek> ah, ok.
<pmichaud> so I probably should've said
<pmichaud> self.$P0(...)
<bacek> pmichaud: so, I assume, using this technique we can implement authothreading for Junctions?
<bacek> override 'find_method' in Junction and construct proper closure on fly.
<bacek> Or my thought totally wrong?
<dalek> r29481 | moritz++ | trunk:
<dalek> : [rakudo] add Complex log() and re-arranged any-num.pir, bacek++
<dalek> : Patch Curtesy of Vasily Chekalkin <back at bacek.com>
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29481
<pmichaud> you mean autothreading for methods on junctions?  yes, essentially we'll override find_method, I suspect.  But even then it'll be a bit tricky.
<moritz> can we add bacek to CREDITS to shorten the attribution in the commit messages?
<bacek> moritz: jonathan did it already
<pmichaud> the attributions are supposed to be that way for anyone w/o a commit bit
<pmichaud> at least, that's what I was once told
<moritz> pmichaud: ok
<bacek> moritz: and you've made typo in my email :)
<moritz> oh dammit, sorry
<moritz> somehow copy&paste doesn't work in the vim instances that "svn ci" spawns
<moritz> so I retype it every time, and hope I don't amke a mistake
<moritz> moritz--
<particle> missppeelled "courtesy" also
<bacek> moritz: no worries (It was first phase that I learned to say in all situations in Australia :)
<moritz> me-- again
<bacek> karma me
<purl> bacek has karma of 52
<bacek> karma (me)
<purl> (me) has neutral karma
<bacek> not so bad :)
<bacek> pmichaud: I failing to implement 'log10()' for Complex... There is log10 implementation in src/pmc/complex.pmc, but I can't call it from rakudo's Complex.log10
<pmichaud> I don't see log10 in complex.pmc
<moritz> ok, here begins the fun: log(-1i) -> 0-1.5708i. The test checks for 1i*pi*1.5, which is also correct, but on a different complex plane. What should I do?
<moritz> should we standardize on one complex plane? or adapt the tests to deal with any complex plane?
<pmichaud> what do most other languages do?  To me, standardizing on one complex plane sounds right, but I'd check with p6l
<moritz> Mathematica returns the same result as Rakudo
<moritz> but I don't know if it does so consistently
<bacek> pmichaud: my bad... sorry
<bacek> perl6: say ((1|2) + (3&4)).perl
<polyglotbot> OUTPUT[get_string() not implemented in class 'Junction'␤current instr.: 'infix_junction_helper' pc 7790 (src/gen_builtins.pir:5050)␤called from Sub '_block11' pc 67 (EVAL_13:21)␤called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806 (src/PCT/HLLCompiler.pir:481)␤called from Sub
<polyglotbot> ..'parrot;PCT::HLLCompiler;evalfiles' pc 1088 (src/PCT/HLLCompiler.pir...
<pmichaud> it should be possible to write .perl for Junction
<moritz> perl6: say ((1|2) + (3&4)).values
<polyglotbot> OUTPUT[get_string() not implemented in class 'Junction'␤current instr.: 'infix_junction_helper' pc 7790 (src/gen_builtins.pir:5050)␤called from Sub '_block11' pc 67 (EVAL_13:21)␤called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806 (src/PCT/HLLCompiler.pir:481)␤called from Sub
<polyglotbot> ..'parrot;PCT::HLLCompiler;evalfiles' pc 1088 (src/PCT/HLLCompiler.pir...
<pmichaud> note that ((1|2) + (3&4)).values would likely still be a Junction
<pmichaud> (a List of junctions, anyway)
<Zaba_> I find the fact that | and & are no more binary or/and kinda confusing
<masak> which one takes priority, '|' or '&' ?
<moritz> masak: & probably
<masak> ok, so a list of two | junctions then
<masak> (4|5, 5|6)
<pmichaud> yes, that seems right
<masak> there oughta be a method to deeply de-junctify a value
<pmichaud> masak: so, what would we get in the case of the above?
<masak> pmichaud: I don't know exactly. something well-behaved. maybe a List subclass that indicates that it contains and-ed values, and the elements similarly instances of a subclass indicating or-ed values
<masak> or if we prefer to not subclass, separate classes for that. or something else.
<masak> perhaps something akin to the inner structure of $/
<pmichaud> sure, those can work
% wknight8111_ has joined #parrot
<masak> if the $/ alternative is feasible, I like that one the best
<pmichaud> although "a List subclass that indicates that it contains and-ed values"  sounds a lot like and(), with the exception of not being a List subclass :-)
% wknight8111 has left wknight8111!~chatzilla@66.252.102.38
<bacek> moritz: autothreading not implemented for Junctions (yet)
% wknight8111_ is now known as wknight8111
% wknight8111 has left wknight8111!~chatzilla@66.252.102.37
<pmichaud> we had autothreading for junctions implemented at one point but it slowed things down a fair bit
<pmichaud> so I disabled it until we do more work on dispatching in general
<bacek> pmichaud: why it slowed things?
<masak> pmichaud: the exception being that I can examine a List object, whereas a junction behaves like a value with MPD
<pmichaud> well, I can examine a Junction, too, with:    $junc.values[3]
<pmichaud> and for "nested junctions", it's then    $junc.values[0].values[1]     which looks a lot like $/  :-)
% britneypire has joined #parrot
<pmichaud> (autothreading on junctions) -- actually, I'm guessing that methods don't autothread over the invocant
<pmichaud> now that I think about it a bit more
<pmichaud> so there's no need to overload find_method
<masak> pmichaud: I'm pretty happy with that
% britneypire has left britneypire!~britneypi@212-198-248-33.rev.numericable.fr
<masak> what's the way to test whether what I'm holding is radioac... er, junctive?
<pmichaud> $x ~~ Junction
<pmichaud> ?
<masak> but of course. thanks.
<masak> that means that I can write my deep dejunctifier, should I ever need it
<masak> I'm contented.
<bacek> pmichaud: last 4 tests in S29-str/index.t...
<Zaba_> does $x ~~ SomeClass return true whether $x is of SomeClass?
<moritz> Zaba_: yes
<Zaba_> nice.
<Zaba_> no .isa()?
<moritz> I think there's .isa also, but ~~ does more
<Zaba_> I know that ~~ is used for regex matching too
<moritz> for example if SomeClass is actually a role, and $x does SomeClass, ~~ will return True and .isa will false
<Zaba_> oh.
<Zaba_> interesting.
<moritz> so $obj ~~ Type actually checks if "$x is of type Type", for a useful value of "is of type"
<Zaba_> $obj ~~ Something checks whether $obj is of type Something, or does role Something, and that's all?
<pmichaud> depends on what Something is, but yes.
<moritz> if Something is a type name, yes
% jhorwitz has joined #parrot
<dalek> r29482 | pmichaud++ | trunk:
<dalek> : [rakudo]: spectest-progress.csv update, 95 files, 1695 passing tests
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29482
<bacek> moritz: around?
<purl> nope.
<moritz> bacek: partially
<purl> partially is already too much w/o proper locking or shared PMCs
<moritz> purl, forget partially
<purl> moritz: I forgot partially
<moritz> purl, forget around?
<purl> moritz: I forgot around
<pmichaud> barney: let me know if the reindexing fails/succeeds
<jonathan> pmichaud: OK, maybe we make it Friday so I get a full day on it.
<pmichaud> jonathan: works for me
<japhb> Congrats to everyone on the Parrot release!
<jonathan> (backtrack) methods called on a junction are methods on the junction object itself
<japhb> Anyone happen to know what the news item '+ improved IMCC register allocator' referred to?  Improved how?
<nopaste> "bacek" at 58.111.0.124 pasted "2-args log implmentation for moritz" (72 lines) at http://nopaste.snit.ch/13586
<pmichaud> note that the "2-arg" implementation is really supposed to be done with an optional arg :-)
<moritz> does it make a difference?
<jonathan> pmichaud: How's things on the lexicals/closures? I saw the post on p6l...
<pmichaud> jonathan: no response on p6l yet.  Until I get a response there, I'm not sure I can progress
<pmichaud> moritz: S29 shows log as having a named arg
<bacek> pmichaud: logick is quite different. My first version was with optional arg. But this one is much easy to understand (for me at least)
<jonathan> pmichaud: OK. Bob seems to have put a patch in that keeps us and him happy for now, though.
<pmichaud> jonathan: I agree, so I may just let it simmer a while
<jonathan> OK.
<pmichaud> however, I think we may quickly run into difficulty with recursion
<pmichaud> or closures
<purl> Closures make washort's CS teacher happy
<pmichaud> or both
<jonathan> The recursion example that used closures that I hand-compiled worked... :-)
<jonathan> There are other cases though, that I'm not convinced will. Well, I guess we can just find what's broken and add them to tests as fudged.
<Zaba_> hand-compiled?
<jonathan> Zaba_: I took the source in Perl and wrote PIR that was close to what I'd expect it to compile down to.
<Zaba_> aha
<pmichaud> jonathan: I'm worried about something like      if cond { $a = &foo; }
<jonathan> pmichaud: Does that do a newclosure on foo?
<pmichaud> by definition, the newclosure generated for &foo won't be in the same scope that defines foo
<jonathan> Right.
<NotFound> Someone wants to look at the .parrot_current_rev issue before releasing?
<pmichaud> NotFound: I think the release already happened.
<NotFound> Then not ;)
<pmichaud> jonathan: that simple case is why I think that newclosure as presently constituted can't solve our problems
<pmichaud> (unless we do lots of really odd manipulations to move the newclosure operation out of the nested block)
<pmichaud> anyway, on sat/sun I was feeling fairly comfortable that I could come up with a clean spec, but I really need an indication of what happens for the examples I posted to p6l
<jonathan> pmichaud: OK, I think clone is what we actually want to emit.
<jonathan> (for reference taking)
<pmichaud> I agree.
% cognominal has left cognominal!~cognomina@82.67.232.89
<jonathan> OK
<jonathan> Guess we can arrange later on, what I look at on Friday
<pmichaud> I'll have time to think about things while on the planes tomorrow
<jonathan> If you've no particular goals, I may do anonymous classes, which should be easy-ish.
<jonathan> OK.
<pmichaud> today is a little hectic preparing for trips and getting ready for extended travels starting next week
<jonathan> Sure, I'm pretty busy today too.
<pmichaud> originally my trip tomorrow was for one 90 minute meeting.  In the past 24 hours it's increased to be four meetings (ranging from 30 mins to 120 mins)
% cognominal has joined #parrot
% iblechbot has joined #parrot
<jonathan> Ouch!
<pmichaud> well, they all pay pretty well.  :-)
<jonathan> Getting paid = good. :-)
<pmichaud> afk, errands
% kjs_ has joined #parrot
% DietCoke has joined #parrot
<DietCoke> I need some PCT guidance.
% kj has left kj!~IceChat7@193.1.100.109
<DietCoke> ee.
% tuxdna has left tuxdna!~tuxdna@122.163.54.90
* Tene prods DietCoke 
<DietCoke> For tcl, my plan is to fake the non grammar by pretending the builtin functions are originally part of the language syntax.
<Tene> Right.
<DietCoke> but I don't want to paint myself into a corner when I have to implement [rename], (which lets you rename even the builtins). So I was thinking that I was going to need a sub somewhere that corresponded to the runtime version... but I think if I am going to support changing the grammar anyway (to remove things), I can just make rename support changing the grammar so that [rename puts say] DTRT.
<DietCoke> ... so I think I just talked myself down from a ledge there.
<DietCoke> so, "we'll be able to update the grammar at runtime at some point, right?"
<DietCoke> (I also need to allow user defined proces to re-parse themselves if they're invoked after the grammar changes. and also only run one command at a time.)
<NotFound> DietCoke: will not be easier to not trying to fake the non grammar?
<DietCoke> also, how do I mark a string literal in a grammar so my action can tell if it was present?
<DietCoke> NotFound: ... I can't parse that.
<Tene> DietCoke: $<foo>='zomglolwtf'  ?
<NotFound> DietCoke: if tcl parsing is oriented to runtime, trying to do it at compile time can be impossible.
<moritz> DietCoke: don't parse things at the language level you don't have to parse, and internally have a number of parsing helper functions?
% Zaba has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<Tene> You could take the approach I'm moving lolcode away from.  ;)
<pmichaud> back
<DietCoke> NotFound, moritz: at which point, what's the point of using PCT?
<NotFound> DietCoke: maybe none.
<DietCoke> I will refrain from making a snarky comment about dynamic language support. =-)
<moritz> DietCoke: dunno.
% uniejo has left uniejo!~uniejo@193.88.64.250
% teknomunk has joined #parrot
<DietCoke> in trunk, partcl does the runtime dispatch just fine. I was trying to use PCT to provide some pre-compiled versions of the standard builtins.
<DietCoke> (rather than having to handroll PIR for everything, which I'm doing now.)
<DietCoke> Abusing the grammar in this fashion seemed a reasonable compromise. I'm open to suggestions.
<NotFound> DietCoke: You can't just call the standard builtins in the same way as user defineds?
<DietCoke> yes. I can. see trunk.
<NotFound> So what are you trying to do, pre-compile the calls to them?
<DietCoke> Trying to unroll them for speed.
<DietCoke> puts $a -could- compile down to "say $P1" if we were clever.
<moritz> HLL JITting ;)
<DietCoke> right now it compiles down to an insane amount of PIR plus the entire tcl runtime.
<NotFound> DietCoke: A nigthmare solution can be to make an opcode for each buitin, an have the implementation for that opcode check at runtime if the function has been redefined.
<DietCoke> that would involve writing the builtins in C which is even worse than writing them in PIR. =-)
<NotFound> You can at the same time build a way to define opcodes implemented in pir ;)
<DietCoke> So, anyway, back to my PCT approach. =-)
% donaldh has joined #parrot
<DietCoke> tene: something like:     'puts' $<nonewline>=[ '-nonewline'?  ] <value> ';'
<DietCoke> ?
<DietCoke> pmichaud: should we be calling NQP files ".pm" ?
<DietCoke> (as opposed to ... .nqpm, I suppose.)
<Tene> $<nonewline>=['-nonewline']? is what I was thinking
<Tene> or [$<nonewline>='-nonewline']?
<Tene> NQP is a subset of Perl 6.  All NQP programs are valid Perl programs with the same meaning, yes?
<Tene> .oO(Should NQP's test suite also be running the tests with rakudo?)
<DietCoke> Tene: my current annoyance is that all my editors want to treat it as perl5 source.
<NotFound> Maybe the answer is "Not Quite" X-)
<moritz> DietCoke: # vim: ft=perl6
<moritz> modelines++
<moritz> of course that only works for vim, though
<Tene> I have plans to work on lolcode and cardinal again tonight.
<Tene> I plan to have lolcode generating a normal AST by the end of the week and completely removing the ugly runtime lookup stuff.
<Tene> I should be able to then take that same approach to improve cardinal quite a bit.
<pmichaud> DietCoke: I'm calling them .pm, yes.  In theory anything that NQP compiles Perl 6 should be able to compile.
% teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net
<pmichaud> what does [rename] do, exactly?
<pmichaud> if I rename a builtin, does it stay that way permanently?
<DietCoke> moritz: that should be added to the language shell.
<DietCoke> pmichaud: yes.
<pmichaud> so, just replace the existing builtin with the new one
<DietCoke> which is fine when everything is runtime dispatch.
<DietCoke> Not so fine if the grammar is at all smart about the builtin processing.
<pmichaud> where "grammar is smart" means...?
<DietCoke> let's say I define [if] in the grammar to take advantage of the if past nodes.
<DietCoke> then someone calls rename.
<DietCoke> say, [rename if iffy]
<DietCoke> so if I've added it to the grammar, I have a lot of things to update when that happens, and there may not be a simple builtin func to call at that point.
<DietCoke> (whereas in trunk, everything is a sub. I just change the name of the sub in the  main:: namespace.)
<moritz> can you have a symbol table that is updated at parse time?
<pmichaud> I'd probably start by not using the if past nodes
<pmichaud> i.e., keep [if] as a runtime op for now
<pmichaud> yes, this might mean that pct is not very useful for tcl
<moritz> then you could parse for an identifer, and check if it's the current name for 'if'
<pmichaud> we don't really have the concept of 'thunks' yet in parrot or pct
<DietCoke> I guess I'm not seeing the value of pct for me at all, then. =-)
<pmichaud> there might not be one.
<pmichaud> once we have protoregexes, though, it might be easier to redefine 'if'
<pmichaud> and other "keyword"-like tokens
<pmichaud> ....actually
<pmichaud> come to think of it
<purl> well, come to think of it is how the zombie monkies come in the night and pluck the brains from unsuspecting children while they sleep
* pmichaud smiles evilly
<pmichaud> you probably don't want to change the grammar as much as you want to change the action method -- the part that produces the PAST
<pmichaud> and *that's* very easy to do.
<DietCoke> I do want to change the grammar.
<pmichaud> because 'if' parses differently after it's been renamed?
<pmichaud> oh, because the keyword itself has changed
<pmichaud> so, you want to dynamically look up keywords from a hash or array
<DietCoke> if my grammar has 'puts [$<nonewline>=-nonewline] <value>' before, and someone creates a user defined proc called puts that overrides it, I can't have that nonewline stuff in the grammar anymore.
<pmichaud> okay
<pmichaud> you're definitely after protoregexes then
<DietCoke> Was hoping to use PCT to avoid a lot of the manual argument mangling I have to do.
<pmichaud> with a protoregex you'd have    term:puts { $<sym> [$<nonewline>=-nonewline] }   in the original grammar
<DietCoke> er, I was missing a ? there.
<pmichaud> but after someone redefines puts it'd replace that rule with something less specific
<pmichaud> i.e., you'd end up with a derived grammar
<pmichaud> and then parse using the derived grammar.  Perl 6 will be doing the same thing.
<DietCoke> I figured in that case, I'd just have a default "command" dispatch, and by removing puts, it would fall back to the current trunk-like behavior.
<pmichaud> that can work also.
<pmichaud> is -nonewline part of the grammar normally in Tcl?
<DietCoke> grammar? no.
<DietCoke> it's an argument to puts.
<pmichaud> so why is it parsed specifically in the grammar?
% cognominal has left cognominal!~cognomina@82.67.232.89
<DietCoke> so I don't have to do by hand when redefining puts isn't something that happens all the time.
<pmichaud> can't the default puts (function) simply parse -nonewline as part of its arguments?
<DietCoke> ... I keep having the same conversation over and over here. =-)
<DietCoke> yes. that's what I'm doing in trunk right now.
<pmichaud> I'm missing something.
<DietCoke> I am trying to generate more efficient bytecode.
<pmichaud> I'm questioning why 'puts' appears in the grammar at all, if the builtin sub already does the argument processing
<DietCoke> I don't want the builtin sub.
<DietCoke> I am forced to have it in trunk.
<pmichaud> you want something more efficient
<pmichaud> okay, I got back to what I said earlier, then
<DietCoke> so puts doesn't appear in trunk's grammar.
<pmichaud> you don't want to do the "more efficient" part in the grammar -- you want to do it in the action methods
<DietCoke> it only appears in the tcl_pct's branch's grammar.
<pmichaud> let the action method decide if it's safe to use the more efficient version or to use the built-in version
<moritz> DietCoke: can the rename be traced at compile time?
<DietCoke> and where would I define this more efficient version?
<NotFound> DietCoke: A fast an efficient tcl will not be counter-natural? X-)
<moritz> DietCoke: or can you do stuff like if rand < 0.5 [rename foo bar]?
<DietCoke> moritz: sure you cna.
<pmichaud> we don't need to trace the rename at compile time
<pmichaud> unlike many of the other compilers we're working with, tcl's model would likely be "parse one command, execute it"
<DietCoke> (especially if we're running the compiler after every command anyway)
<pmichaud> i.e., it's more of an interpreter than a compiler.
<DietCoke> pmichaud: by doing this in the actions, though, i'd always need to have a fallback of a runtime version of a command, no?
% cognominal has joined #parrot
<pmichaud> DietCoke: no.
<pmichaud> in the actions you can do:   the equivalent of
<pmichaud> if sub puts exists then  generate past to call that sub
<pmichaud> else generate past to do XYZ directly
<NotFound> pmichaud: Wait for the day I implement a Basic line oriented, able to modify his own code by POKE. That day you'll know what a pure interpreter is X-)
<pmichaud> i.e., inside the action methods we can query the state of the current runtime and choose to do different things based on that
<DietCoke> pmichaud: I'd need something to keep track of renames and be able to dispatch based on that. the original builtin 'puts' could be renamed to 'say', e.g. That approach might work. So then I could write my "compiled" versions in NQP/past instead of how I do it now. 
<pmichaud> DietCoke: correct.
<pmichaud> and PAST even allows inlined PIR segments
<DietCoke> what about user-defined procedures? My original plan was to basically recompile them if someone had called 'rename' anywhere.
<DietCoke> (since if they call puts and someone's called rename since the proc was defined, it needs to use the new behavior.)
<pmichaud> DietCoke: it might be worthwhile to keep the PAST tree around
<pmichaud> in fact
<pmichaud> hmmmm
<pmichaud> (thinking)
<pmichaud> I think I have to go back to my earlier comment, that I'd start by doing the builtins as subs and then figure out ways to optimize after that :-)
<DietCoke> "that's trunk"
<pmichaud> yes, I got that part.  :-)
<DietCoke> except mdiep and I handrolled our own way of optimizing things.
<pmichaud> if you already have the builtins in trunk, then doing a first cut of a simple pct-version is easier too, yes?
<DietCoke> not for me, no. =-)
<DietCoke> my pct-fu is "start with a brand new empty shell"
<DietCoke> I would not be averse to someone trying out PCT against tcl as it stands today, but I suspect that'd be non-trivial for me to do.
<pmichaud> this is something I would _love_ to sink my teeth into, honestly, and I probably will at some point.  But it'd be late august before I can do it
<DietCoke> maybe I can bug tene into doing it. =-)
<dalek> r29483 | cotto++ | trunk:
<dalek> : [pmc] add resizablebooleanarray test, fix codingstd goof
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29483
<pmichaud> erands -- bbiaw
% AndyA has left AndyA!~andy@ca93nt.hexten.net
% AndyA has joined #parrot
% Infinoid has left Infinoid!infinoid@quack.glines.org
% Infinoid has joined #parrot
<barney> pmichaud: reindexing worked for the individual module, but http://search.cpan.org/~bschmal/parrot-0.6.4/ is still said to be unauthorized
% rlb3 has joined #parrot
<dalek> r29484 | coke++ | trunk:
<dalek> : update ticket pointer to new system.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29484
% Zaba_ has joined #parrot
% masak has left masak!~user@130.238.45.242
<particle> barney: you need to submit a request to reindex iirc
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<particle> i forget if that's via pause, or if you need to email brian_d_foy et al
<DietCoke> we should write that down if it's not already in the doc.
<particle> i think brian wrote a doc about it
<particle> docs/project/pause_guide.pod
<barney> I reindexed parrot-0.6.4.tar.gz. Right now I requested to reinedex parrot-0.6.4.meta
% sjansen has joined #parrot
% julian_ has joined #parrot
% cjfields has joined #parrot
<dalek> r29485 | julianalbo++ | trunk:
<dalek> : Update .parrot_current_rev in Configure if possible
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29485
% paco has joined #parrot
<dalek> r29486 | julianalbo++ | trunk:
<dalek> : Update .parrot_current_rev in Configure if possible-fix
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29486
% Zaba has joined #parrot
<dalek> r29487 | bernhard++ | remove_getfd:
<dalek> : #48310: [DEPRECATED] getfd opcode
<dalek> : Create branch 'remove_getfd' for working on RT #48310
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29487
% paco has left paco!~user@dy022235.etu.univ-rennes1.fr
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<dalek> r29488 | julianalbo++ | trunk:
<dalek> : Update .parrot_current_rev in Configure if possible-fix 2
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29488
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<Tene> I don't think I did anything this week for #ps
* Tene reads svn log
<Tene> orite, lolcode switches for jhorwitz
<Tene> purl: parrotsketch?
<purl> parrotsketch is a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch
<Tene> 1.5 hr
<DietCoke> tene: if you're bored you could figure out why ../../parrot tcl.pbc library/tcltest/tcltest.tcl is losing track of a command name and replacing it with a $P register.
% chromatic has joined #parrot
<DietCoke> (or convert tcl in trunk over to using PCT with as little other modifications as possible.)
<barney> Tene: or look at RT #56828
<dalek> r29489 | julianalbo++ | trunk:
<dalek> : Update .parrot_current_rev in Configure if possible-fix 3
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29489
<barney> http://search.cpan.org/~bschmal/parrot-0.6.4/ is now authorized
<moritz> YaY
<dalek> r29490 | moritz++ | trunk:
<dalek> : [rakudo] add and test Str.trans, cjfields++
<dalek> : Patch courtesy of Chris Fields <cjfields at uiuc.edu>
<dalek> : Adds one file to spectest_regression, +37 passing tests
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29490
<NotFound> That's odd. If I don't make an update after the commit, svn info does not reflect the commited rev number.
<moritz> NotFound: that's because your revision number could be out of date
<moritz> NotFound: if somebody changed other parts of the repo between your last 'svn up' and 'svn ci'
<NotFound> moritz: but svn knows what is the number, it tells it at commit end.
<moritz> NotFound: yes, but the rest of your repo is not in that state
<NotFound> Ah, yes, I see the point.
% gryphon__ has left gryphon__!~gryphon@dsl-209-221-185-54.zipcon.net
<Tene> DietCoke: and if I'm not bored?
<DietCoke> Then I presume you have other things to work on.
<NotFound> Someone can test this last commit and tell if Configure.pl shows the correct revision number?
<cotto_work> NotFound, looks ok to me on linux/x86
<cotto_work> of course, the arch shouldn't make much difference for something like that
% cjfields_ has joined #parrot
<moritz> should Configure.pl print the revision number?
<cotto_work> it should be part of Configure.pl's output
<dalek> r29491 | coke++ | trunk:
<dalek> : [tcl] Remove some useless global lookups (these are now done in the TGE
<dalek> : step and are, as far as I can tell, not needed here. All tests pass.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29491
<NotFound> moritz: It already printed it, I don't touch that part.
<moritz> ah yes
<moritz> grep++ ;-)
<NotFound> In any case, it must not print a wrong one.
<DietCoke> cotto_work: it might if he's somehow using the svn binary where we don't have one.
<DietCoke> (no clue if he is, though.)
% cjfields has left cjfields!~cjfields@newrad.igb.uiuc.edu
<NotFound> If svn is not used, the package must include a .parrot_current_rev file.
% Theory has joined #parrot
<DietCoke> if it's a package, it should  be a release #, not a rev number we're using to track things.
<NotFound> A snapshot package, I mean.
<DietCoke> (unless someone is constructing packages based on svn revision, which would be... odd.
% iblechbot has left iblechbot!~iblechbot@189.18-dial.augustakom.net
<DietCoke> what is "a snapshot package" ?
<NotFound> A daily snapshot of the repo.
<Infinoid> http://svn.perl.org/snapshots/parrot/
<DietCoke> We can probably have robert include that, sure.
<moritz> barney: I've seen no announcement on perlmonks.org - are you going to do that also?
<NotFound> tjh++
<dalek> r29492 | bernhard++ | remove_getfd:
<dalek> : [codingstd] Remove hard tab.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29492
<barney> moritz: I'm not active there, so I skipped that. Please go ahead and announce it there.     Same for Reddit, Slashdot ...
<moritz> barney: ok, I'll post to perlmonks later
* DietCoke wonders if the .HLL mapping stuff is going to catch anyone's eye.
<DietCoke> barney: wrong branch?
<NotFound> Comments or ideas about pdb renaming?
<DietCoke> NotFound: perhaps pbc_debug to stick with our newfound pbc naming scheme.
<barney> DietCoke: trunk wasn't up to date
<NotFound> Parrot Byte Code debug? Makes sense.
<dalek> r29493 | bernhard++ | trunk:
<dalek> : [codingstd] remove hard tab
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29493
<cotto_work> just out of curiosity, how many people here use awk regularly?
<cotto_work> (N/y)
<NotFound> cotto_work: directly, or by using shell scripts that uses it?
<barney> re: pbc_debug    Can't we debug PIR as well?
<cotto_work> directly
<NotFound> barney: actually not.
<jhorwitz> DietCoke: what .HLL mapping stuff?
<NotFound> But what I mean is that it debugs at bytecode level, so the name makes sense.
<barney> pbc_debug++
<DietCoke> jhorwitz: .HLL_map doesn't seem to work anymore.
<jhorwitz> ah
<jhorwitz> i thought there was progress i didn't hear about...
<jhorwitz> but this is anti-progress
<DietCoke> nope. used to work, stopped some thousands of revisions ago. =-)
<DietCoke> I think I'm failing some of the tcl spec tests as a result.
<DietCoke> chromatic: ping
<cjfields_> I think pmichaud is working on that (.HLL mapping)
<cjfields_> maybe on a branch, but I'm not sure
<DietCoke> he's working on it for -pct- IIRC, not for the .HLL_map directive.
<DietCoke> so PCT can keep track of some of this before things ever get to aprrot.
* DietCoke stares at the mess that parcl is.
<DietCoke> "partcl"
<chromatic> on the phone with Anders Heljsberg
<DietCoke> Anders Heljsberg is he lead architect of C#
<DietCoke> no, Anders Heljsberg is the lead architect of C#
<purl> okay, DietCoke.
<particle> all we need... c# on parrot.
% Zaba has joined #parrot
% kjs_ has left kjs_!~IceChat7@193.1.100.109
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<NotFound> monoparrot X-)
% donaldh has left donaldh!~chatzilla@proxy-sjc-2.cisco.com
% donaldh has joined #parrot
<chromatic> I wouldn't worry about that just yet.
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<DietCoke> I would be happy with anything on parrot at this point. ^_-
<chromatic> pancakes?
<purl> i guess pancakes is "Don't! take pancakes off my plate and ruin my day."
* DietCoke feels like crap and ponders just going home now.
<moritz> I'll not be available for #parrotsketch tonight
<NotFound> tools/dev/mk_language_shell.pl anything
<NotFound> That makes you happy?
* DietCoke presumes NotFound is joking.
<particle> moritz: feel free to pre-paste your report
<Tene> Looks like I might not be here for #ps
<NotFound> DietCoke: Trying, at least
<pmichaud> I've been working on getting PCT to understand HLL namespaces in preparation for using .HLL and .HLL_map, but I'm not using .HLL_map yet.
<pmichaud> (not even in the branch)
<pmichaud> but I'm hoping we can start using it soon.
<pmichaud> thus it better work :-)
% wknight8111 has joined #parrot
<DietCoke> pmichaud: pretty sure it's ingored completely these days.
<DietCoke> "ignored"
<DietCoke> but I'll be happy to find myself proven wrong. =-)
<NotFound> Did we have some test for it?
<chromatic> I remember unbreaking it at least once.
% apeiron has left apeiron!~apeiron@c-76-124-253-113.hsd1.pa.comcast.net
<DietCoke> Well, part of the problem is that there's no defined set of what it's supposed to do. (ticket open for that)
<DietCoke> so you may have fixed part of it, but not the part I cared about.
<NotFound> t/library/hllmacros.t ?
<DietCoke> ... that's something else entirely.
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
<DietCoke> (which I did add tests for, after it lay broken for years. =-)
<chromatic> Yeah, it's difficult to unbreak things without tests.
<DietCoke> it's hard to write tests without a spec. =-)
<DietCoke> (yes, yes, I could just go write the spec. sometimes I like just being the crotchety HLL programmer.)
<DietCoke> chromatic: see tcl's runtime/builtin/list.pir for an example of a HLL_map workaround.
<DietCoke> (at one point, :slurpy gave me a TclList instead of a ResizablePMCArray)
<NotFound> chromatic: did you look at the last messages about RT#39669?
<DietCoke> (trying without it now)
<wknight8111> (unbreaking things)++
<DietCoke> nope, still borked.
<chromatic> NotFound, I think RT #39669 is okay now.
<chromatic> Let me review the tests, but I think you're right.
<NotFound> (closing old tickets)++
<DietCoke> chromatic: I'll see about adding a test for the particular HLL_map feature that's borked there.
<chromatic> NotFound, close it.
<chromatic> DietCoke, thanks.
<NotFound> Good.
<wknight8111> "nope, still borked" is like the catch phrase for my entire project
<chromatic> #ps in 3
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
<chromatic> japhb: the register alligator improvements are that it wastes less memory and has a smaller t in its awful O(t * n^8) behavior.
<japhb> n^8 ?!?
<japhb> Holy cow
<purl> Holy cow is here's the play at the plate... holy cow, I think he's gonna make it!
<japhb> I honestly don't think I've ever seen an algorithm between n^5 and 2^n before
<japhb> I heard about an n^7 once ...
<chromatic> 8 could be an estimate.
<chromatic> t is at least 8
<chromatic> n^4 is more likely though.
<japhb> sigh, afk again ... I'll have to ask more about it later, I guess.
<chromatic> If you're motivated, you could own it.
% wknight8111_ has joined #parrot
% wknight8111 has left wknight8111!~chatzilla@66.252.102.38
% wknight8111_ is now known as wknight8111
% julian_ is now known as jjore2
% DietCoke has left #parrot
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Theory has left Theory!~Theory@h-67-101-1-55.sttnwaho.dynamic.covad.net
% cjfields_ has left cjfields_!~cjfields@cjfields.igb.uiuc.edu
<dalek> r29494 | bernhard++ | trunk:
<dalek> : [docs] Add escape sequence \" in double quoted strings.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29494
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
<dalek> r29495 | allison++ | trunk:
<dalek> : [pdd] Clarification on literal strings from #parrotsketch meeting.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29495
% chromatic is now known as chromatic_lunchy
% barney has left barney!~bernhard@p549A01E6.dip0.t-ipconnect.de
% wknight8111 has left wknight8111!~chatzilla@66.252.102.37
<japhb> chromatic_lunchy: motivated, yes.  Have time, not so much (I haven't even had OpenGL hacking time, and that's saying something).  Still ... is there already an RT open for it?
<japhb> (er, it == register allocator algorithmic slowness)
% iblechbot has joined #parrot
% Theory has joined #parrot
% iblechbot has left iblechbot!~iblechbot@204.4-dial.augustakom.net
% Sartak has joined #parrot
<dalek> r29496 | julianalbo++ | trunk:
<dalek> : Rename pdb to parrot_debugger after Reini Urban suggestions and later discussion
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29496
% chromatic_lunchy has left chromatic_lunchy!~chromatic@nat-147-1.oreilly.com
% grim_fandango has joined #parrot
% ruoso has left ruoso!~ruoso@201.45.49.162
% chromatic has joined #parrot
<chromatic> japhb, no real ticket anywhere.
<chromatic> I sent a message to the list three weeks ago about it.
<japhb> If you've still got it in your sent mail, just resend it to parrotbug.  :-)
<NotFound> I think there is a ticket that mentions that some routines are unable to handle register numbers greater than 255
<NotFound> Beacuse they use an unsigned char for the number.
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<Tene> NotFound: limiting registers to 255 keeps that n^8 in the register allocator low. ;)
<dalek> r29497 | Whiteknight++ | gsoc_pdd09:
<dalek> : [gsoc_pdd09] update to trunk r29495
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29497
% jhorwitz has left jhorwitz!~chatzilla@96.245.16.45
% Zaba has joined #parrot
<chromatic> The problem with the n^8 is that IMCC uses SymReg everywhere for any kind of symbolic entity in PIR, not just registers -- constants, Subs, everything.
<NotFound> Tene: don't know if the limit in the amount of registers is reasonable, but the in his numbers is not.
<chromatic> That means when the alligator wants to look at all registers, it has to loop through all of the SymRegs in the current compilation unit and filter out only register registers.
<chromatic> Oh, and if it wants to look at only P-regs or S-regs, it still has to loop.
<chromatic> And loop.  And loop.  And loop.
<leo>  another historic design flaw - greetinx all
<chromatic> Anyway, my conclusion in that message was that fixing it meant rewriting a lot of IMCC, which may not be worth it.
<Whiteknight> ...and that brings us back to the bigger question: How much work needs to be done to make PIRC take over the job?
<chromatic> We need a good way to generate PBC in memory or on disk.
<chromatic> POST -> PBC would be most ideal.
<chromatic> For various reasons which should be obvious.
<leo> register allocation written in PIR???\
<NotFound> The pdd about pbc format reflects the current state or the intended changes?
<chromatic> Why not write one in PIR?
<leo> speed?
<purl> speed is, like, too subjective, I think
<leo> HA
<leo> soryy, but the best efforts in C so far are slow
% Zaba_ has joined #parrot
<leo> with PIR you take a factor of x200 (average interpreter slowdown for Joe Averages's code)
<chromatic> Our best efforts in C are algorithmically awful.
<chromatic> Even the naive allocator.
% cjfields has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<leo> there is only compilers/imcc/reg_alloc.c - where are the others?
<chromatic> There are two allocators in there.  The interesting one is #defined out.
* Whiteknight sees a massive need for function-level documentation in reg_alloc.c
% cjfields has left cjfields!~cjfields@cjfields.igb.uiuc.edu
<leo> is still the vanilla_reg_alloc in charge?
<chromatic> Yes.
% toft has joined #parrot
% toft has left #parrot
<leo> well, if there's a faster C algorithm (which is hard) then you could translate that to PIR ;)
<chromatic> It wouldn't surprise me if a better implementation of the same algorithm would be faster.
<leo> different algorithm, yes
<leo> or moving the inner loops re (I,P,N,S) outside
% Zaba has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<Whiteknight> is there a standard error-message function I can call that doesn't require an interp parameter?
<Whiteknight> i know internal_exception does it, but I thought that function was being phased out
% Zaba_ has joined #parrot
<chromatic> You don't have an interpreter?
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<Whiteknight> in config/platforms/win32/env.c:Parrot_setenv
<Whiteknight> I'm fixing that function up and want to fill in some of the warnings slots, but no interp argument
<NotFound> internal_exception is intended to just die with a more or less nice message, I think.
% Zaba has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<Whiteknight> yeah, but I heard that internal_exception was being phased out
<Whiteknight> maybe i misunderstood that error
<NotFound> By the way, GetEnvironmentVariable is macro that can map to the unicode or ansi version. The current Parrot_getenv interface is not able to handle encoding and charset issues.
<NotFound> Whiteknight: maybe a change in name, but we always need a way to say "Completely unable to keep working in a sane way"
<Whiteknight> I'll use internal_exception now, then. We can ack it later if we want to change it
<NotFound> Under the current interface, you can only do that, or just ignore the errors.
<chromatic> Whiteknight, it gets renamed in pdd25cx.
<NotFound> Not ignoring we can at least know possible problems.
<chromatic> At least, if I'm not confusing internal_exception and real_exception.
% teknomunk has joined #parrot
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Limbic_Region has joined #parrot
<Whiteknight> anybody want to give a second opinion on rt#56968? I think we can close it pretty quick unless there's a problem
<Whiteknight> I'm going to need to check out pdd25cx and play around with it i guess
% Zaba has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<chromatic> Go ahead and remove it, Whiteknight.
<Whiteknight> That's all I needed to hear
<Whiteknight> I found this while trying to clean out my rt backlog, so I'm not shirking my GC duties
<chromatic> You can clean out my RT backlog too.  I don't mind.
<chromatic> I'll probably be useless next week too; Foo Camp + working in the office + OSCON = tired.
<NotFound> It hink that if we want a warning function able to be called without an interpreter if mus be declared in extern.h and follows his guidelines.
<NotFound> s/if mus/it must
<chromatic> How do we know which filehandle to print the warning to without an interpreter?
<NotFound> Just ignore, or write something to stderr.
<Whiteknight> I agree. last ditch effort -> spam stderr
<Whiteknight> at that point, you have bigger problems to solve then proper logging of your output handle
<NotFound> But while we don't know if we want, do not write it.
<NotFound> The function, not the message ;)
<chromatic> Right.
<dalek> r29498 | Whiteknight++ | trunk:
<dalek> : [core] Remove function Parrot_warn_s, which was unused except in a few tests. Also, remove those tests.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29498
% Psyche^ has joined #parrot
<cotto_work> does taking a ticket mean I *will* fix it, or just that I intend to when I get the tuits?
% Patterner has left Patterner!~Psyche@e177234083.adsl.alicedsl.de
% Psyche^ is now known as Patterner
<Whiteknight> I've been interpreting it as the late
<Whiteknight> later *
<NotFound> cotto_work: I think is just way of saying: if you start to work in this, talk with me first, please.
<Whiteknight> or "I'm going to lead the way"
<NotFound> At least it is how must be seen, whatever the intention of the owner.
% kid51 has joined #parrot
<NotFound> The intention, looks like is almost always the second.
<NotFound> When I take the pdb rename some hours ago, it was the first ;)
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% ruoso has joined #parrot
<kid51> purl is apparently no longer handling private messages
<Whiteknight> purl is lazy
<Whiteknight> purl?
<purl> yes, Whiteknight?
<kid51> purl, why did you tell me:  "Sorry, I've never seen particle before."?
<purl> kid51: bugger all, i dunno
% teknomunk_ has joined #parrot
% teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net
<dalek> r29499 | jkeenan++ | trunk:
<dalek> : Merge noautopack branch into trunk per http://rt.perl.org/rt3/Ticket/Display.html?id=56928.  This deletes configuration step auto::pack and an associated test file.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29499
<dalek> r29500 | jkeenan++ | noautopack:
<dalek> : Branch has been merged into trunk and is no longer needed at head.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29500
<dalek> r29501 | jkeenan++ | noautopack-29452:
<dalek> : Branch to which tag corresponded has been merged into trunk, so tag may be
<dalek> : deleted.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29501
% bacek_ has joined #parrot
<dalek> r29502 | jkeenan++ | parallel:
<dalek> : Correct two errors:  "my" variable ... masks earlier declaration in same scope.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29502
% AndyA has left AndyA!~andy@ca93nt.hexten.net
% donaldh has left donaldh!~chatzilla@proxy-sjc-2.cisco.com
% donaldh has joined #parrot
% AndyA has joined #parrot
% Psyche^ has joined #parrot
% Patterner has left Patterner!~Psyche@e177227117.adsl.alicedsl.de
% Psyche^ is now known as Patterner
% Zaba has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<kid51> I've got my coverage reports working again:  http://thenceforward.net/parrot/coverage/configure-build/coverage.html
% kid51 is now known as kid51_at_dinner
<Whiteknight> chromatic, you still here?
<chromatic> Briefly.  What's on your mind?
<Whiteknight> just going to invite you, if you have some tuits, to take a  look at my branch
<chromatic> Give me 15 - 20 to get back to my hotel and I will.
<Whiteknight> I gutted the sweep code, simplified it down to nothingness, and I'm still getting prematurely freed PMCs
<Whiteknight> no rush, but I'm basically blocked on this
<chromatic> Okay.
<chromatic> Did you follow my "How to debug GC problems" guide?  (sorry, I have to ask)
% chromatic has left chromatic!~chromatic@nat-147-1.oreilly.com
<Whiteknight> Yeah, but I'll read it again and make sure I'm not missing anything
% AndyA has left AndyA!~andy@ca93nt.hexten.net
% bacek has left bacek!~bacek@pa58-111-0-124.pa.nsw.optusnet.com.au
% AndyA has joined #parrot
<Limbic_Region> Whiteknight - they have pills for that
<Limbic_Region> premature freeing that is
% chromatic has joined #parrot
<Whiteknight> it's the number one problem among male programmers
<chromatic> GC?
<purl> GC is the boehm conservative garbage collector at http://reality.sgi.com/boehm/cg.html or a really really bad perl "programmer" or GrandCentral.com
<Whiteknight> purl can be remarkably unhelpful sometimes
<purl> Whiteknight: huh?
<Whiteknight> purl, GC is also branches/gsoc_pdd09
<purl> okay, Whiteknight.
<Whiteknight> purl, GC is also a travesty against god
<purl> okay, Whiteknight.
<Limbic_Region> Whiteknight - consider that purl's factoid database is cross channel - so certain entries don't make sense out of context (#parrot)
<Whiteknight> it's my goal to ensure that none of them make sense to anybody
<Limbic_Region> Whiteknight++
<Whiteknight> I'm failing all the PGE tests, which makes sense because I can't build PGE
<Whiteknight> a lot of other tests are passing though, so that's reassuring
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
% s1n has joined #parrot
% Zaba_ has joined #parrot
% kid51_at_dinner has left kid51_at_dinner!~jkeen@pool-71-247-46-24.nycmny.east.verizon.net
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Theory has left Theory!~Theory@c-67-160-131-113.hsd1.or.comcast.net
<chromatic> Whiteknight, see t/op/string.t
<chromatic> Some interesting failures there; they look suspicious.
<Whiteknight> the string subsystem has been bonkers for a while though. I suspect the same kinds of offset failures from the compacting code are coming into the rest of the string system
<Whiteknight> you are right, lots of interesting failures
<chromatic> Did you re-enable compacting?
<Whiteknight> no
<Whiteknight> i am making the blind assumption that compacting isn't necessary for proper operation
% Zaba has joined #parrot
<Whiteknight> Certainly bad for efficiency to disable it, but I don't think it's strictly necessary
<chromatic> Agreed.
<chromatic> That means compacting isn't the problem here.
<Whiteknight> A good test might be to disable compacting in my trunk checkout and run the test suite there
<Whiteknight> but that's time I would rather not waste right now
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<chromatic> The good news is that most of the string tests are small and self-contained, so they'll be easy-ish to fix.
<chromatic> Compared to PGE anyway.
<Whiteknight> Of course, disabling the compacting code doesn't necessarily fix that problem we were having with string pointers being messed up
<Whiteknight> so maybe it's just hiding a symptom, not the problem
<chromatic> Right.
<Whiteknight> with compacting enabled, it makes it to the same point in the build process. I'll debug to see if I am getting the same segfault
% kid51 has joined #parrot
<Whiteknight> ...yes, exact same error at the same point. The compacting code isn't affecting it at all
<chromatic> Good to know, but let's leave the compacting code off for now.
<dalek> r29503 | chromatic++ | gsoc_pdd09:
<dalek> : [src] Fixed some codingstandards violations.  No functional changes.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29503
<chromatic> ./parrot t/op/string_3.pasm
<chromatic> should print 4
<chromatic> If I set a breakpoint at Parrot_length_i_s and step into string_length, the string looks correct.
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
<chromatic> If I set a breakpoint after that at Parrot_print_i and look at the contents of IREG(1), it's also correct.
% kid51 has left kid51!~jkeen@pool-71-247-46-24.nycmny.east.verizon.net
<chromatic> Within PIO_printf, the string created for printing is also correct.
<chromatic> Hmm.
<chromatic> AHA
<Whiteknight> !!!?
<chromatic> if I add print "\n" to the end of the code, it prints
<chromatic> so we're not flushing a buffer
<chromatic> PROBABLY
<chromatic> because the buffer gets flushed during destruction?
% cjfields has joined #parrot
<Whiteknight> You think that's the case?
<chromatic> That explains a lot of these failures.
% Andy has joined #parrot
<chromatic> PIO by default is line buffered, but when Parrot exits it needs to flush these buffers.
<chromatic> That's good though.
<chromatic> It means at least this part of strings isn't broken.
<Whiteknight> Sweep code for strings and the sized pools is disabled
<Whiteknight> and the finalization is caput
<chromatic> I think it's PIO finalization that we're missing here.
<Whiteknight> I can't enable finalization as-is without introducing new order-of-destruction errors
<chromatic> Even sweeping backwards?
<Whiteknight> it sweeps starting at the last arena
<Whiteknight> but in each arena, it sweeps back-to-front
<Whiteknight> I could redo that tonight/tomorrow and try it again
<chromatic> It works in trunk, so the algorithm can't be entirely wrong.
<chromatic> ./parrot t/op/gc_4.pasm
<chromatic> There's a segfault.
<chromatic> src/scheduler.c:692
<chromatic> sched_struct->wait_index gets reaped early (its vtable is 0xdeadbeef)
<Whiteknight> yeah, that's like errors I was seeing
<Whiteknight> somehow, some PMCs are still being sweeped early
<Whiteknight> which means either my crippled sweep code is still wrong, or my mapping from card<->pobj isn't correct
<chromatic> Is pobject_lives calling mark appropriately?
<Whiteknight> it should be, it looks it to me
<Whiteknight> I'm thinking about ditching the separate cards and using the PObj flags like in PDD09
<Whiteknight> We lose some speed in the sweep (at least, when the sweep is running at full-speed), but other then that cache locality should keep the cost low
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<chromatic> Let's benchmark it when we get it working.
% Zaba has joined #parrot
<chromatic> Interesting.
<chromatic> The scheduler gets marked and marks its kids, but they get swept and it doesn't.
<chromatic> How confident are you of your state transitions?
<Whiteknight> becoming less and less
<chromatic> The child PMCs of the Scheduler are mostly all ResizablePMCArrays.
<Whiteknight> I've kept state transitions to a minimum for this exact reason
<Whiteknight> those would trigger the PObj_data_is_PMC_array flag
<chromatic> I'm just waiting for something to click in your head again while I explore.
<Whiteknight> I'm racking my brain here, it all seems like it should work
<chromatic> Here's my strategy.
<chromatic> I'm going to look for a fork and see if there are still cookies in the lobby.
<chromatic> You (if you want) should set a breakpoint in Parrot_Scheduler_mark, grab the address of one of the child PMCs, and then set a conditional breakpoint somewhere in the sweep code to check for the conditions which trigger the sweep for that PMC.
<chromatic> And also hope that there are cookies in the lobby, because I want one and I don't really want to walk across the street to the grocery store.
<Whiteknight> Okay. I probably don't have the time tonight, but I can do that tomorrow 
<Whiteknight> shit, if we can get this resolved I'll bake you a batch of cookies
<Whiteknight> quick question, in gdb if I have the address of a PObj, how can I look at the adjacent header?
<Whiteknight> can I do pointer arithmetic on it?
<chromatic> I believe so.
<chromatic> (no cookies, but I did find a microwave and plastic utensils, so not all a failure)
<Whiteknight> Okay, I'll play with that. If I can see the header, I can find the corresponding card and track when it gets updated
<chromatic> Looks like setting a conditional breakpoint on Parrot_dod_free_pmc will catch the point at which we collect the PMC.
<Whiteknight> right, but even for simple programs we call that function a hundred times or so
<chromatic> break Parrot_dod_free_pmc if pmc == 0x822a52c
<Whiteknight> can you do that?
* Whiteknight is still a gdb newbie
<chromatic> You can and it's awesome.
% Zaba_ has joined #parrot
<s1n> conditionals rock
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<chromatic> and it's getting called from gc_it_sweep_PMC_arenas
<chromatic> mark == GC_IT_CARD_WHITE is true
<chromatic> #  define IT_HDR_to_PObj(p) ((PObj*)((Gc_it_hdr*)(p)+1))
<chromatic> Is that right?
<chromatic> The PObj is one byte after the GC header?
<Whiteknight> it's pointer arithmetic, it's 1 Gc_it_hdr after it
<Whiteknight> Let me throw in some more parens there and see if that fixes anything
<chromatic> You don't need sizeof (Gc_it_hdr)?
<Whiteknight> no, in C pointers and arrays are interchangable, the compiler does the sizeof calculations for pointers automatically
<Whiteknight> p + 1 == p[1]
<chromatic> Where's the array though?
<Whiteknight> it doesn't matter where, C just does the pointer arithmetic as if it were an array
<Whiteknight> at least, it's supposed to
<chromatic> Right, but how does C know in this case that 1 means sizeof (Gc_it_hdr)?
<Whiteknight> because of the cast to (Gc_it_hdr*) I jammed in there
<Whiteknight> we cast the pointer to (Gc_it_hdr*), then add 1, and then cast the result to (PObj*)
<Whiteknight> The PObj_to_IT_HDR macro does the process in reverse
<chromatic> Ah, so that's why you wonder if adding more parentheses might help.
<Whiteknight> right
<Whiteknight> in (cast)p + 1, I can't remeber whether (cast) or + bind more tightly
<chromatic> I never trusted casts like that myself.
<Whiteknight> I assumed the cast did
<chromatic>     /* Increase allocated space to account for GC header */
<chromatic>     pool->object_size += sizeof (Gc_it_hdr);
<Whiteknight> right, I allocate the headers directly next to the objects, so the allocated space needs to be big enough for both of them
<Whiteknight> ...and more parenthesis produces the same segfaults
<chromatic> I modified the macros.
<Whiteknight> that's fine, modify away
<Whiteknight> by the time I'm done debugging, not a shred of my original design is going to be left
<Whiteknight> of course, that's probably for the best
<chromatic> Hash problems.
<chromatic> Blah.
<chromatic> #  define PObj_to_IT_HDR(o) ((Gc_it_hdr *)((o)        - sizeof (Gc_it_hdr)))
<chromatic> #  define IT_HDR_to_PObj(p) ((PObj *)((p)             + sizeof (Gc_it_hdr)))
<chromatic> #  define cPObj_to_IT_HDR(o) ((const Gc_it_hdr *)((o) - sizeof (Gc_it_hdr)))
% cjfields_ has joined #parrot
<Whiteknight> just to be sure, cast the arguments to (char*) to make sure it's all in bytes
<Whiteknight> ((Gci_it_hdr *)((char*)(o) - sizeof(Gc_it_hdr)))
<Whiteknight> beyond that, I'm fine with the change
<chromatic> Ah, much better.
% cjfields has left cjfields!~cjfields@adsl-76-199-4-241.dsl.chmpil.sbcglobal.net
% cjfields has joined #parrot
<chromatic> That didn't fix anything though.
% sjansen has left sjansen!~sjansen@75-169-83-227.slkc.qwest.net
<Whiteknight> Okay, don't waste any more of your time. I'm going to bed. I'll get into gdb nirvana tomorrow after work and see if I can find anything
<chromatic> Okay.
<chromatic> Hmmm.
<chromatic> Here's a thought.
<Whiteknight> ?
<chromatic> Are you flipping all marked cards back to unmarked when you sweep?
% cjfields_ has left cjfields_!~cjfields@vpn3-144201.near.uiuc.edu
<Whiteknight> yes, right during the sweep. If it's white, we free them, and if it's black we switch it to white
<Whiteknight> I could separate that out into two steps, but since I differentiate between free and white cards, I can't do a memset
<chromatic> Makes sense.
<chromatic> I see the code now.
<Whiteknight> I do that so in the sweep code I don't  try to finalize anything that's already free
<Whiteknight> but I suppose i can determine that a different way
<chromatic> I ran into this when I was working with constants.
<chromatic> If something's already marked live, we don't mark its kids.
<chromatic> So if the Scheduler gets created and doesn't have its card flipped, the second GC run will sweep up its kids.
<Whiteknight> But every time the scheduler is marked, the kids should be marked during the trace too
% cjfields has left cjfields!~cjfields@adsl-76-199-4-241.dsl.chmpil.sbcglobal.net
<Whiteknight> I could be more aggressive marking the kids in pobject_lives or something
<chromatic> Let me try that.
<chromatic> Doesn't seem to fix it either.
<Whiteknight> I must have some mixup in the trace code, it must not be marking children black like I think it should be
<chromatic> Seems as plausible as anything.
<Whiteknight> Okay, i'm definitely heading to bed now. Thanks for everything tonight. I'll run with some of your suggestions tomorrow and see what happens
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
% verve has left verve!a5847f73@67.207.141.120
<Whiteknight> goodnight
<chromatic> good luck!
<purl> it has been said that good luck is all I can say.
% Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% tjh has joined #parrot
% cjfields has joined #parrot
% Zaba has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% cjfields has left cjfields!~cjfields@adsl-76-199-4-241.dsl.chmpil.sbcglobal.net
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% tjh has left tjh!~chatzilla@user-0cdfo61.cable.mindspring.com
% teknomunk_ has left teknomunk_!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net
% verve has joined #parrot
% Theory has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
% Ademan has joined #parrot
% grim_fandango has left grim_fandango!~matt@bas2-kingston08-1167935462.dsl.bell.ca
% iblechbot has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
% davidfetter has left davidfetter!~davidfett@start.fetter.org
% Ademan has left Ademan!~dan@h-68-167-207-88.snfccasy.dynamic.covad.net
<Tene> I just pulled out all of the expr-parse and var-or-function mess in lolcode.
<Tene> All tests pass.
<purl> Time to write more tests!
<Tene> purl++
% verve has left verve!a5847f73@67.207.141.120
% verve has joined #parrot
<cotto_home> purl++ indeed
% Ademan has joined #parrot
% Andy has left Andy!~Andy@64.81.227.163
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-200-40.dynamic.mnet-online.de
% Psyche^ has joined #parrot
% Patterner has left Patterner!~Psyche@e177235033.adsl.alicedsl.de
% Psyche^ is now known as Patterner
% teknomunk_ has joined #parrot
% Theory has left Theory!~Theory@c-67-160-131-113.hsd1.wa.comcast.net
% Zaba_ has joined #parrot
% teknomunk_ has left teknomunk_!~teknomunk@r74-195-245-171.stl1cmta01.stwrok.ok.dh.suddenlink.net
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% donaldh has left donaldh!~chatzilla@proxy-sjc-2.cisco.com
% donaldh has joined #parrot
% uniejo has joined #parrot
% uniejo has left uniejo!~uniejo@193.88.64.250
% uniejo has joined #parrot
<dalek> r29504 | fperrad++ | trunk:
<dalek> : [install]
<dalek> : - clean up test.php
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29504
<dalek> r29505 | fperrad++ | trunk:
<dalek> : [Lua] shootout
<dalek> : - more TODO & SKIP
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29505
% Zaba has joined #parrot
% bacek has joined #parrot
% Ademan has left Ademan!~dan@h-68-164-169-199.snfccasy.dynamic.covad.net
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au
% verve has left verve!a5847f73@67.207.141.120
% UltraDM has joined #parrot
% Ademan has joined #parrot
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% chromatic has left chromatic!~chromatic@216-31-236-219.static-ip.telepacific.net
% Ademan has left Ademan!~dan@h-68-164-169-199.snfccasy.dynamic.covad.net
% barney has joined #parrot