% moritz has joined #parrotsketch
% Whiteknight has joined #parrotsketch
% cognominal has left cognominal!~cognomina@82.67.232.89
% rdice has joined #parrotsketch
% tewk has joined #parrotsketch
% Whiteknight has left Whiteknight!~Whiteknig@c-71-230-33-251.hsd1.pa.comcast.net
% davidfetter has joined #parrotsketch
% particle has joined #parrotsketch
% cognominal has joined #parrotsketch
% Auzon has joined #parrotsketch
% DietCoke has joined #parrotsketch
% Whiteknight has joined #parrotsketch
% NotFound has joined #parrotsketch
% jhorwitz has joined #parrotsketch
% allison has joined #parrotsketch
% cotto_work has joined #parrotsketch
% smash has joined #parrotsketch
% barney has joined #parrotsketch
% pmichaud has joined #parrotsketch
% chromatic has joined #parrotsketch
% wknight8111 has joined #parrotsketch
<DietCoke> Hello, everyone.
* jhorwitz waves
<pmichaud> Hello!
<allison> hi
<smash> greetings
<davidfetter> ahlan wa sahlan
% jonathan has joined #parrotsketch
* moritz waves hi
<Tene> Last #ps was on June 10?
* barney waves ho
<DietCoke> there was no PS last week due to yapc::na
<pmichaud> yes, last #ps was June 10.
<DietCoke> speaking of yapc...
<DietCoke> It was nice meeting a lot of you this past week (some of you for the
<DietCoke> first time!). We've had a lot of movement behind the scenes for parrot
<DietCoke> in that time, which I suspect others will cover in their reports.
<DietCoke> let's go allison, particle, jhorwitz, chromatic, pmichaud and then I'll figure it out after that.
<allison> - The hackathon was very productive, and it was great to spend time talking with Parrot hackers.
<allison> - I added 2 new opcodes for patrick (on the pdd25 branch) that allow rapid branchs/returns within a subroutine. Currently named 'pbj' and 'pbr', but probably going to change to 'local_branch' and 'local_branch_return' (or something equally lengthy and descriptive).
<allison> - The rest of my time has been spent on debugging the pdd25 branch. The number of failing tests keeps dropping, but still a few to go.
<allison> EOR
<particle> had a few commits over yapc, nothing to brag about
<particle> face-to-face meetings at yapc were very productive
<particle> mainly doing parrot foundation setup work, expect that to continue
<particle> won't have much time for parrot development work until my job situation settles down (no eta)
<particle> .end
<jhorwitz> YAPC talks went well.  Had lots of positive feedback.
<jhorwitz> Not surprisingly, the concept of mod_lolcode generated a lot of excitement, so I worked on it and it's now bundled with mod_parrot.  Will have live demos for OSCON.
<jhorwitz> Focus now is on expanding mod_parrot's access to apache data structures to pave the way for other volunteers to work on higher level stuff like mod_perl6.
<jhorwitz> EOR
<chromatic> Applied a lot of patches and closed some bugs.
<chromatic> Spending some time in IMCC -- made a couple of optimizations and plugged some memory leaks.
<chromatic> I'm not sure it's worth anyone's time doing more fixes in IMCC; it's just wrongly designed in a lot of ways that'll take a lot of energy to tease apart.
<chromatic> I'd really like to help with pdd25cx, but it's not clear what to do or where to start, and I hate to see it slip another release.
<chromatic> Still working with wknight8111 on the new GC; it's getting close.
<chromatic> EOR
<pmichaud> ** Rakudo spectest_regression:  66 files, 849 passing tests  (+7, +144 from 06-10)
<pmichaud> == Overall
<pmichaud> : Very productive YAPC::NA, glad to see so many of you there
<pmichaud> == Parrot stuff
<pmichaud> : Fixed get_parrotclass method of P6object to avoid MMD
<pmichaud> : Recognize CCLASS_NEWLINE and CCLASS_ANY for unicode strings on systems w/o ICU
<pmichaud> : Spent a lot of time tracking down lexical and :outer issues
<pmichaud> == PCT stuff
<pmichaud> : Updated HLL compiler to automatically transcode source to a fixed-width representation when possible (for faster parsing)
<pmichaud> == PGE stuff
<pmichaud> : Added .chars method to Match objects
<pmichaud> == NQP stuff
% cjfields_ has joined #parrotsketch
<pmichaud> : No changes to NQP -- it just works
<pmichaud> == Rakudo stuff
<pmichaud> : Lots of test updates
<pmichaud> : Updated Range class
<pmichaud> : Added implementation for Complex
<pmichaud> : Added an implementation of ternary ?? !!
<pmichaud> : Many grammar refactors to more closely align with STD.pm
<pmichaud> : Fixed named 0-ary parsing
<pmichaud> : Removed some obsolete rules from grammar
<pmichaud> : Rakudo now parses utf8 characters in source (transcoding to iso-8859-1 for speed when possible)
<pmichaud> : Created docs/spectest-progress.csv to keep track of spectest progress
<pmichaud> : tools/test_summary.pl now also summarizes the reasons for skipped tests
<pmichaud>  
<pmichaud> Queue two items for discussion.
<pmichaud> EOR.
* Tene balances a book on DietCoke's head.
* Tene goes now.
<Tene> * Missed YAPC::NA because I needed to find a new place to live
<Tene> * Cardinal parses more competently and about 80% faster
<Tene> * Cardinal hashes can now do some rubyish magic with default values
<Tene> * Start of a smalltalk implementation, under the name ChitChat
<Tene> * Modified the evalbot from #perl6 to support --target={parse,past,pir} and uploading to pastebin for parrot languages
<Tene> * polyglotbot is running in #parrot and supports (kind of) abc APL bf cardinal chitchat lolcode lua perl6 pheme plumhead punie pynia squaak tcl
<Tene> * I don't think it's actually rebuilding the parrot tree, and it needs a couple of minor fixups I'm unlikely to get around to.  It's running on feather3.
<Tene> * Started working on implementing gather/take, but I'm apparently blocking on pdd25cx, I think
<Tene> * KTHXBAI
* allison queues questions for tene and chromatic
* barney kicks in
<barney> Migrated Plumhead from TGE to NQP.
<barney> .eor
* tewk goes now.
<DietCoke> I have a $DAYJOB issue; I tag allison.
<tewk> NCI GSoC
<tewk> * Split CPP(pre-processing) out of c99.
<tewk> * Using gcc to pre-proccess c code right now.
<tewk> * moved c99 to compilers/ncigen
<tewk> * Added alot of gnu extension support to c99 parsing.
<tewk> * Figuring out PCT so I can generate PIR signatures
<tewk> EOR
<allison> DietCoke: okay
<Whiteknight> I'll go then, since it's a free-for-all
<Whiteknight> * I updated docs/memory_internals.pod to be less wrong.
<Whiteknight> * Worked on some other docs, and function-level documentation
<Whiteknight> * Did a little IMCC work, and got .macro_const working in *.PIR files
<Whiteknight> * The new GC is "code complete" and compiles, but doesnt work properly yet
<Whiteknight> EOR
* jonathan goes
<jonathan> * On last week's Rakudo day...
<jonathan> ** Did some refactoring and STD.pm tracking
<jonathan> ** Got the does operator for roles in place
<jonathan> ** Support for anonymous enum constructor
<jonathan> ** Variety of type variable stuff - we can now write generic subs/methods
<jonathan> * Parrot core
<jonathan> ** Maybe got :instanceof sorta working
<jonathan> * Meta
<jonathan> ** Need some brain cycles to finish working out how to implement type-parameterized roles; I'm part of the way there, but have been too sick to think about anything hard for the last few days :-|
<jonathan> ** Doubt I'll do that on the next Rakudo day (which will hopefully be on Thursday); will maybe look at getting the Method / Sub etc stuff in place, and maybe signature objects too, since they're likely useful for MMD.
<jonathan> EOR
<allison> have we missed anyone?
<allison> okay, questions, pmichaud had 2
<pmichaud> from my post to the mailing list: Any thoughts about short-term fixes for :outer() handling?  (RT#56274)
<pmichaud> also related to the discussion: I now know why RT#56184 is a problem and we may need some substantial re-thinking somewhere.
<pmichaud> (although fixing RT#56274 may obviate the need to worry about #56184 for a while.)
<allison> on RT#56274, is this as an alternative to md5 hashed sub names?
<pmichaud> no.  they are totally unrelated.
<pmichaud> (we could potentially make use of this as an alternative to md5 hashed subnames, but 56274 is really a separate and more problematic issue)
<pmichaud> for those who didn't read my mailing list post:   :outer(...) doesn't give sufficient resolution.
<allison> but the solution is essentially to have some unique name or id for every sub
<allison> whether we tack on the the namespace, or generate a unique id
<pmichaud> if I have   .sub 'foo' :outer('bar')    and there are multiple .sub 'bar' in the compilation unit, then 'foo' always attaches to the first 'bar'.
<allison> by compilation unit, do you mean file?
<pmichaud> yes.
<pmichaud> (although it could be a string with PIR code.)
<allison> and, you have multiple subs because you have, say methods and regular subs with the same sub name?
<pmichaud> yes.  or subs that are :multi
<Tene> or multiple namespaces.
<pmichaud> and that's what really makes this different from the md5 issue -- where I needed a way to locate otherwise anonymous subs.
<pmichaud> in this case I _have_ to use the supplied name, or do lots of name mangling.
<allison> multiple namespaces is fixable by using full sub names, but the method/sub/multi problem is more complex
<allison> the first quick fix didn't work out, is there another short-term solution we could use?
<Whiteknight> couldn't we do name-decoration for multis, like we do for similarly-named ops?
<allison> yes, name decoration for type of sub could work (not ideal in the long-term)
<pmichaud> at the moment it's the sub-in-separate-namespaces that is causing the most difficulty.
<allison> how about a simple user-defined id token
<pmichaud> that's what I proposed in my mailing list message, yes.
<Whiteknight> .sub MySub :theycallme('Ishmael'), like that?
<allison> so, you set the token on the sub, and then refer to it :outer.
<pmichaud> yes.  I proposed  :lexid or somesuch
<allison> yup, that works for me, especially since the problem is local to a file
<allison> make it so
<jhorwitz> mod_parrot assumes that sub names in PIR are the same as in the HLL.  as long as that assumption is still valid, then +1.
<allison> yeah, it wouldn't affect the sub name
<chromatic> I like :lexid
* jhorwitz seconds
<Tene> and :outer could fall back to sub name if it can't find a given lexid
<pmichaud> actually, any sub that doesn't provide :lexid uses its name as the lexid
<allison> it would only affect the way the sub is treated for looking up :outer
<pmichaud> the patch I tried would always look for the most recent version of a sub, as opposed to the first.
<pmichaud> That "worked", except that it only worked for .pir files and not .pbc
<allison> yeah, you can't count on compilation order
<pmichaud> (I don't know enough about bytecode formatting to know what is needef ro .pbc)
<pmichaud> er, *needed for .pbc)
<allison> :lexid is preferable
<particle> anonymous subs can have a lexid, yes?
<pmichaud> yes, please.
<chromatic> Sure, why not?
<particle> and, by default, what's the lexid of an anonymous sub?
<allison> yes, so it solves an earlier problem we had of how to have :outer subs referring to an anoymous sub
<pmichaud> default lexid of anonymous sub could be PMCNULL (i.e., doesn't have one)
<allison> particle: it has none by default
<pmichaud> just like it doesn't have a name.
<particle> but for named subs, lexid is the name of the sub
<pmichaud> for named subs lexid defaults to name of sub
* particle asks leading questions to get to the heart of the matter
<allison> right, and anonymous subs have no name, so thaey have no lexid
<particle> it's a bit confusing, since anon subs do have a name in the source file
<allison> you have to specify a lexid for an anonymous sub if you want to define an outer block for it
<particle> but that's just syntax
<particle> and it's specced
<pmichaud> if anon sub has a name in the source file, then that's its lexid
<pmichaud> there's no real conflict there.
<allison> particle: they do, but only because parrot requires some name
<particle> you don't want anon subs to have a lexid by default. period.
<particle> even if they have a name in the pir
<pmichaud> why not?
<allison> if they have a name in pir, the :lexid can default to it, might as well since it's there
<particle> .sub 'foo' :anon ; ... ; .sub 'foo' ; ...
<pmichaud> any sub that expects to be an outer should provide a :lexid
% cognominal has left cognominal!~cognomina@82.67.232.89
<pmichaud> in the case you just gave, .sub 'foo' should provide a :lexid
<pmichaud> failing to provide a :lexid is asking for trouble.  :-)
<allison> but if the name is something like .sub '' :anon (which may not even be valid at the moment, but should be) then it has no :lexid
<pmichaud> and one could conceivably do   .sub 'foo' :anon :lexid('')
<particle> .sub 'foo' without :anon has a default lexid of 'foo'
<particle> .sub 'foo' :anon must specify a lexid or it has none
<allison> particle: yes, and so does .sub 'foo' :anon
<pmichaud> particle:  why require .sub 'foo' :anon to specify a lexid?
<allison> we'll keep it consistent for sanity
<pmichaud> there's no conflict if it has one.
<particle> there's no conflict if two subs have the same lexid?
<pmichaud> yes, there's a conflict if two subs have the same lexid.
<pmichaud> but
<pmichaud> any sub that expects to be an :outer should provide a unique lexid.
<pmichaud> regardless of being :anon or not.
<pmichaud> the "default lexid" is simply to keep existing code working.
<particle> so, how do we check for unique lexids?
<particle> what about evaled subs?
<pmichaud> we don't have to check for unique lexids -- that's the responsibility of whatever is generating the code.
<pmichaud> evaled subs are no different.
<Whiteknight> a lexid hash would associate a single function with a single lexid
<pmichaud> keep in mind that they only need to be unique within compilation unit, at least with the current implementation of lexicals.
<pmichaud> (since :outer doesn't cross comp unit boundaries)
* DietCoke returns.
<tewk> So you can't eval a sub that has a pre-existing :outer
<pmichaud> tewk: in the current implementation, that's correct.
<pmichaud> even so, I'm not worried about being able to generate unique lexids.
<particle> if my code generator creates an anon sub with the same name as a named sub, neither of which specify :lexid, there's a collision
<pmichaud> if your code generator is generating subs w/o :lexid, it's broken.
<allison> which there already is now, :lexid just gives us a way to resolve the collision when there is one
<particle> ok, so the default is just for humans with silly little code, and code generators will always specify :lexid
<pmichaud> particle: yes.
<particle> that works for me.
<allison> yeah
<particle> just needs to be documented as such
<pmichaud> code generators don't have to specify :lexid if they know that a block doesn't have any lexically nested subs.
<pmichaud> but it's easier to just always generate one.
<DietCoke> Do we have a volunteer to implement this schemne?
<pmichaud> that was my next comment -- Rakudo is blocked on a lot of tests due ot this.
<chromatic> If someone writes up what needs to happen, I'm happy to poke at this.
<chromatic> I've already gone negative on my SAN stat due to recent IMCC work.
<pmichaud> essentially  we're unable to handle lexically nested subs
<pmichaud> I think jonathan also indicated he might work on it.
<DietCoke> pmichaud: can you summarize on the ticket the new :lexid() and its interaction with :outer, then c or j can claim it as a todo.
<pmichaud> will do immediately following this meeting.
<DietCoke> I'd even be willing to write up a doc patch if someone else writes up the code. =-)
% cognominal has joined #parrotsketch
<pmichaud> my next question is much simpler:  Any thoughts on ETA to merging the pdd25cx branch into trunk?
<allison> the last 6 failing tests are nasty
<allison> some of them I may just todo, if I can demonstrate that all the languages are working even with those tests failing
<allison> the biggest thing right now is a few PGE failing tests, and TCL failing to compile
<pmichaud> I couldn't figure out the PGE failing tests.
<chromatic> If you wrote up some information on them, I (and I can guess that NotFound too) would be happy to look at them.
<DietCoke> I suspect those are related.
<pmichaud> but I didn't look on it much past the hackathon, so I can look again.
<DietCoke> I'll take a look and see if I can narrow down what is causing tcl to fail to build.
<allison> chromatic: okay, though I don't have much more to say than what's immediately obvious from running the failing tests
<pmichaud> when I last looked at the hackathon, the failures I was getting were pretty opaque.  But I need to look again.
<allison> chromatic: I'll be in Seattle Wednesday night, if you want to do some interactive debugging
<DietCoke> Let's track any blockers on this ticket: http://rt.perl.org/rt3/Ticket/Display.html?id=54930
<allison> Portland, I mean
<allison> That was my queued question for chromatic
<allison> The one for tene was what he needed from the pdd25cx branch
<pmichaud> allison:  resumable exceptions
<Tene> pmichaud++
<allison> ah, okay, yes, that should work after the merge
<pmichaud> we want resumable exceptions for gather/take
<allison> (resumable at a PIR opcode, not resumable at a random C instruction)
<Tene> How should I be getting the continuation to invoke from the exception?
<allison> Tene, it's passed in when you call 'throw'
<jonathan> (implementing lexid) if it's not done by my Rakudo day on Thursday, I can look at it then
<Tene> How should I get it in the exception handler?
<pmichaud> does pdd25 not say?  or is pdd25 out of date?
<Tene> Not that I could find.  I'm checking again.
<pmichaud> sorry, pdd23 is exceptions.
<pmichaud> Tene:  "handled" opcode
<pmichaud> exception handlers receive a continuation as a parameter, which they can then invoke.
% blah has joined #parrotsketch
<Tene> ""Active exception handlers (if any) will be invoked with EXCEPTION as the only parameter.
<pmichaud> aha, pdd23 is internally inconsistent.
<allison> yes, the return continuation is stored in the exception
% blah has left blah!~blah@82.67.232.89
<pmichaud> so, how do we get the continuation from the exception?
<allison> sorry, interrupted
<allison> I'll set up a test case as an example
<pmichaud> that would be awesome.
<DietCoke> allison: tcl builds in pdd25cx. interactive version seems to work. 'make test' hangs on the first test.
% cognominal has left cognominal!~cognomina@82.67.232.89
<allison> DietCoke: okay, thanks
<pmichaud> I'll look at pge issues tonight.
<pmichaud> any other outstanding questions or discussion points?
<pmichaud> or did we get them all?
<pmichaud> I'd also like to welcome moritz++ as a new committer.
<moritz> thanks pmichaud ;)
<wknight8111> moritz++
<DietCoke> allison: I have a backtrace for you.
<DietCoke> looks like a loop of handler invocations.
<DietCoke> http://nopaste.snit.ch/13383 :: I just stopped cutting and pasting at #100
<allison> okay, I've seen that elsewhere
<allison> generally when a different exception is thrown in the middle of handling another exception
<DietCoke> I do that a bit as I often want to translate an exception from parrot-speak to tcl-speak.
<DietCoke> I'm not sure when "in the middle" occurs, though: once I call get_results, aren't I done handling?
<allison> catch an exception and throw it differently?
<DietCoke> there's no op to say "my handler is over."
<DietCoke> s/it/or a new one/
<DietCoke> I can probably track down where in PIR this is happening.
<allison> it's any time before the handler is popped
<allison> oh, I bet you're using scoped handlers
<pmichaud> doesn't a handler get popped upon catching an exception...?
<allison> handlers are persistent, like event handlers
<pmichaud> is this strictly for the   "push_eh $P0"  sort of handler, or also "push_eh label" ?
<DietCoke> ... er, how does that work?
<pmichaud> because if I try to pop_eh after a push_eh label, I get an error.
<DietCoke> I often do push_eh/pop_eh with labels.
<DietCoke> seems to go  off the rails in *** switching to BYTECODE_src/PCT/HLLCompiler.pir
<allison> under the old implementation, yes
<DietCoke> # Back in sub 'parrot;PCT::HLLCompiler;init', env 823068c
<DietCoke> it invokes that several hundred times before, I think, running out of memory and failing an assertion.
<pmichaud> HLLCompiler?  in tcl?
<Tene> I get 8 errors in 'make test' in pdd25cx
<DietCoke> I'm as surprised as you are. =-)
<allison> I can keep the old functionality for backward compatibility
<DietCoke> if there's a new/better way to do this, I can update code in the branch, that's nt a problem.
* particle points to #parrot
<particle> seems like the meeting's over, no?
<DietCoke> I agree.
<Tene> Oh, no allison there.
% cognominal has joined #parrotsketch
<Tene> allison: can you tell me which of the failures in here you're not also seeing: http://nopaste.snit.ch/13384 ?
<allison> tene: I'm seeing all of those
<Tene> Hm.  I thought you said 6.
<Tene> Nevermind.
% cotto_work has left #parrotsketch
<allison> sorry, 6 root causes (I divided up the failing tests by symptoms)
<Tene> ahh, clever.
<pmichaud> (presuming that the pge failures are due to the other ones. :-)
<allison> I have to go, DietCoke, I'll think of an alternative for you. With resumable exceptions we can't just delete handlers once they've been called once, because we may resume in a loop, and throw the same exception on the next iteration after the loop
<DietCoke> Ok. if I have to add something to clear the _eh from inside my handler, I can do that. I wonder if that's the cause of some of the other issues you're seeing.
<DietCoke> ~~
<allison> yes, it likely is the cause of one, now that I think about it
<Tene> doesn't rethrow do that, or does rethrow only work on the same exception object?
<allison> clearing the handler from inside the handler would work
<pmichaud> I don't have a problem with clearing the handler (pop_eh?) inside the handler -- it was really what I expected to be doing.  But that didn't seem to work in current Parrot.
<allison> tene: rethrow isn't the same as throwing a different exception expecting the same handler
% cjfields_ has left #parrotsketch
<DietCoke> pmichaud: yah, that doesn't work in trunk.
<DietCoke> it was pre-cleared.
<allison> pmichaud: it doesn't work in current parrot, because current parrot does delete the handler as soon as it retrieves it
<allison> (one of many reasons exceptions weren't resumable before)
<pmichaud> right, no problem.
<pmichaud> just need to know what to switch to :-)
<DietCoke> Want us to start adding in the pop_eh's in the branch?
<DietCoke> (It's not just tcl using that style.)
<allison> DietCoke: see if it fixes the failing test, and if so, add it
<pmichaud> pge and pct have quite a few push_eh's that don't have pop_eh's
<pmichaud> (at least, don't have them when the exception is caught)
<allison> if it doesn't fix the failing test, then it's not needed
<DietCoke> well, I'm going to have to add it in a LOT of places to verify that it worked. =-)
<allison> pmichaud: that could very well explain the failing PGE tests
<DietCoke> let's give it a shot, we can always rollback.
<allison> DietCoke: just the ones relevant to that first failing test should do the trick
<DietCoke> that will still take some time, but ok. =-)
<pmichaud> I'll have to do mine a bit later -- have other tasks on my stack that need to be addressed first.
<pmichaud> (but should get to it tonight/tomorrow morning)
<DietCoke> I'll plan on putting them in right after any .get_results in the label.
<allison> okay, I have a shorter way to test this...
<DietCoke> (auto delete the handler!)
<allison> committing a fix that deletes the handler when it's first invoked
<allison> hold on
<allison> (we can always change it later when we need it for more complex resumable exceptions
<allison> try r28685
<allison> and, I really have to go now, I have a meeting in 3 hours, in a town that's 3.5 hours drive from where I am now
<DietCoke> gogogo
<moritz> get a helicopter ;)
<allison> email me the results of testing :)
% allison has left #parrotsketch
% jhorwitz has left #parrotsketch
% chromatic has left #parrotsketch
% smash has left smash!~smash@gil.di.uminho.pt
% Auzon has left #parrotsketch
% NotFound has left #parrotsketch
% barney has left barney!~bernhard@dslb-084-058-131-114.pools.arcor-ip.net
% jonathan has left #parrotsketch
% Whiteknight has left Whiteknight!~Whiteknig@c-71-230-33-251.hsd1.pa.comcast.net
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
% japhb has left japhb!~geoff@76-191-190-8.dsl.static.sonic.net
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% japhb has joined #parrotsketch
% rdice has joined #parrotsketch
% japhb has left japhb!~geoff@76-191-190-8.dsl.static.sonic.net
% japhb has joined #parrotsketch
% particle has left particle!~particle@c-98-232-28-49.hsd1.wa.comcast.net
% davidfetter has left davidfetter!~davidfett@start.fetter.org
% rdice has left rdice!~richarddi@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com
% particle has joined #parrotsketch
% cognominal has left cognominal!~cognomina@82.67.232.89
% paco has left paco!~chatzilla@139.Red-80-36-122.staticIP.rima-tde.net
% pmichaud has left pmichaud!pmichaud@feather.perl6.nl
% ilbot2 has left ilbot2!moritz@faui2k3.org
% PerlJam has left PerlJam!duff@193.200.132.135
% moritz has left moritz!moritz@ssh.faui2k3.org
% leo has left leo!lt@feather.perl6.nl
% cognominal has joined #parrotsketch
% pmichaud has joined #parrotsketch
% moritz has joined #parrotsketch
% paco has joined #parrotsketch
% leo has joined #parrotsketch
% ilbot2 has joined #parrotsketch
% PerlJam has joined #parrotsketch
% japhb has left japhb!~geoff@192.82.17.44
% japhb has joined #parrotsketch
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com