% particle_ has joined #parrotsketch
% particle has left particle!~particle@144.81.84.242
% particle_ is now known as particle
% particle has left #parrotsketch
% particle has joined #parrotsketch
<spinclad> particle: I see Tweety is back.  Will you replay last week's log?  (or I could...)
% spinclad is now known as |
<|> Replaying last week's log (which includes that of the week before, too):
<|> From 2007-01-30 (times are EST, UTC-0500):
<|> 13:27:13 -!- allison [~chatzilla@125-238-49-58.broadband-telecom.global-gateway.net.nz] has joined #parrotsketch
<|> 13:27:39 < smash> greetings all
<|> 13:27:46 < allison> hi smash
<|> 13:28:01 < particle> wb allison
<|> 13:28:34 < allison> hiya
<|> 13:32:54 -!- chromatic [~chromatic@sub17-30.member.dsl-only.net] has joined #parrotsketch
<|> 13:33:07 < chromatic> No Tweety?
<|> 13:33:22 < particle> nope, two weeks in a row
<|> 13:34:07 < pmichaud> hello, all
<|> 13:34:31 < particle> seems jesse's not around
<|> 13:35:50 < particle> i can start with last week's status for everyone who sent it to me, if you wish
<|> 13:36:16 < chromatic> Sounds good.
<|> 13:36:22 < particle> allison:  
<|> 13:36:22 < particle>  - I've been working on the Objects PDD.  
<|> 13:36:22 < particle>  - Which included starting on implementing Leo's CStruct proposal.  
<|> 13:36:22 < particle>  Currently calling the PMC ParrotBase, may call it ParrotMeta. 
<|> 13:36:33 < particle>  chromatic:  
<|> 13:36:33 < particle>  - implemented all NameSpace PMC methods from PDD 21 (with tests)  
<|> 13:36:33 < particle>  - implemented exceptions in same, where Allison found them useful, though she hasn't added them to the PDD yet 
<|> 13:36:45 < particle> I could use help in testing interactions with the .HLL directive, if anyone   has ideas on how to make that work. 
<|> 13:36:55 < particle>  coke:  
<|> 13:36:55 < particle>  - Started dialog on [trace], and sub profiling.  
<|> 13:36:55 < particle>  - >< to moving all the perl pmcs into languages/perl5 (complete with makefile and tests)  
<|> 13:37:06 < particle>  mdiep:  
<|> 13:37:06 < particle>  didn't get anything done this week because:  
<|> 13:37:06 < particle>  - school work has been all-consuming  
<|> 13:37:06 < particle>  - busy celebrating my 21st birthday  
<|> 13:37:17 < particle>  particle:  
<|> 13:37:17 < particle>  - released parrot 0.4.8 -- "Eponymous"  
<|> 13:37:17 < particle>    + ran into some annoyances with cpan indexer -- will work to resolve  
<|> 13:37:17 < particle>    + 'make release' is not portable -- will enter ticket  
<|> 13:37:17 < particle>    + otherwise, things went smoothly  
<|> 13:37:17 < particle>  - renamed 'clip' directory to 'draft'  
<|> 13:37:19 < particle>  - submitted draft of component/interface stability classification -- will apply  
<|> 13:37:19 < particle>  - continued work on roles & responsibilities doc -- almost ready for review 
<|> 13:37:28 < particle> that's all from last week
<|> 13:37:53 < allison> thanks for doing that rename
<|> 13:38:12 < particle> that was the easy part :)
<|> 13:39:01 < particle> why don't we go alphabetical this week: allison, chromatic, Coke?, leo_?, mdiep_?, particle, pmichaud
<|> 13:39:16 < allison> ok
<|> 13:39:29 < allison> between meetings travel and a cold it's been a light week for me
<|> 13:39:37 < allison> but I've been working on the I/O PDD
<|> 13:39:46 < allison> and on the parrotbase pmc
<|> 13:39:58 < allison> EOR
<|> 13:40:31 < chromatic> Ditto on the lack of time, but I have two questions for question time.
<|> 13:40:54 < particle> coke? leo? mdiep?
<|> 13:41:21  * particle will go ahead, they can report if they wander in late
<|> 13:41:32 < particle> ~ applied approved parrot component/interface stability classification doc 
<|> 13:41:32 < particle>   : TODO document classification of existing components and interfaces 
<|> 13:41:32 < particle>   : NOTE document coding practices (i'd like to talk a bit about that later) 
<|> 13:41:41 < particle> ~ sent patch with pdd22 questions and spec-based tests to p2 for comment 
<|> 13:41:41 < particle>   : TODO continue reviewing spec and adding tests 
<|> 13:41:47 < particle> ~ committed parrot roles & responsibilities doc to repo
<|> 13:41:54 < particle> ~ heavily refactored Parrot::Distribution and added tests
<|> 13:42:01 < particle> ~ added new pge-based pir parser courtesy of klaas-jan stol
<|> 13:42:07 < particle> ~ discussed make replacement (with miniparrot-only dependency) with coke++
<|> 13:42:13 < particle> ~ TODO brainstorm on oscon presentation topic ideas
<|> 13:42:16 < particle> .end
<|> 13:42:51 < pmichaud> busy week for me, with lots of non-code-related tasks
<|> 13:43:00 < pmichaud> in past-pm and perl6 I finally got references working
<|> 13:43:18 < pmichaud> many thanks to mdiep++ for quick responses to the various issues I was running into with the assign op
<|> 13:43:39 < pmichaud> on friday I gave a presentation about parrot (and some perl6) to a group at freescale semiconductor in austin
<|> 13:43:50 < pmichaud> (also austin.pm was invited, and people from ibm, sun, etc.)
<|> 13:44:01 < pmichaud> lots of very good questions about parrot, lots of people seeing that this could serve a real need for them
<|> 13:44:16 < pmichaud> I'll put my presentation slides online a bit later today
<|> 13:44:44 < pmichaud> the next (and last) few steps on perl6 are for loops (iterators), end blocks, and the use statement
<|> 13:44:49 < pmichaud> oh, and bareword class names
<|> 13:45:01 < pmichaud> EOR
<|> 13:45:45 < particle> is anyone blocking on anything?
<|> 13:45:53 < pmichaud> <-- time
<|> 13:46:10 < allison> ditto
<|> 13:46:20 < allison> but other than that, no
<|> 13:46:38 < pmichaud> (time is really a pseudoblock, I'm mainly blocking on time with maskable interrupts)
<|> 13:47:16 < particle> let's move on to questions. c, you had two
<|> 13:47:42 < chromatic> Actually four now, but let's go.
<|> 13:48:13 < chromatic> 1) I get a lot of test failures relating to newlines.  Do we have or should we add a little utility to set svn permissions on new files appropriately to avoid this?
<|> 13:48:57 < particle> i can't remember if we have one, but we should
<|> 13:49:00 < pmichaud> do we have a test for newlines?
<|> 13:49:10 < chromatic> We do have a test for newlines; it runs as part of make smoke.
<|> 13:49:12 < particle> svn:eol-style
<|> 13:49:41 < chromatic> 2) What's the purpose of the roles and responsibilities document?
<|> 13:50:42 < particle> for one, it's a guide to folks unfamiliar with the project as to who's involved
<|> 13:50:56 < particle> it came out of discussions between allison and i related to chip's disappearance
<|> 13:51:07 < allison> yup
<|> 13:51:08 < particle> it lead to the formation of the 'release manager' role
<|> 13:51:30 < allison> we figured since we were adding new roles, it might need some explanation
<|> 13:51:30 < particle> --something that was previously a part of 'pumpking' duties
<|> 13:51:40 < particle> allison: precisely
<|> 13:51:50 < chromatic> Okay.
<|> 13:51:53 < allison> and, a lot of it was clarifying our own thinking
<|> 13:52:05 < allison> if the pumpking isn't the release manager,
<|> 13:52:17 < allison> then what are the responsibilities of the pumpking?
<|> 13:52:26 < allison> basically "lead developer"
<|> 13:52:49 < pmichaud> also, I suspect pumpking is the final arbiter of some items
<|> 13:53:14 < allison> aye
<|> 13:53:22 < chromatic> 3) Should we add a Makefile.PL for the CPAN distribution at a release?  Configure.pl confuses CPAN.pm.
<|> 13:53:49 < particle> the cpan upload process could have been smoother, from my perspective
<|> 13:54:00 < particle> if Makefile.PL will help with that, then sure
<|> 13:54:13 < allison> particle: what were the complexities involved?
<|> 13:54:17 < chromatic> It could possibly be a copy of Configure.pl.
<|> 13:54:35 < allison> chromatic: only if Configure.pl can be run with the same options
<|> 13:54:41 < particle> i got failure messages from the cpan indexer, due to META.yml problems
<|> 13:54:57 < particle> Makefile.PL could just call Configure.pl
<|> 13:55:03 < allison> oh, hmmmm...
<|> 13:55:17 < allison> yes, a proxy set up probably makes most sense
<|> 13:55:22 < chromatic> All a CPAN Makefile.PL needs to do is create a Makefile.
<|> 13:55:26 < chromatic> That's what Configure.pl does!
<|> 13:55:35 < allison> is parrot's META.yml autogenerated?
<|> 13:55:43 < particle> the failure messages led me to believe the distro was bad--so i fixed META.yml manually and resubmitted
<|> 13:56:01 < particle> allison: not as far as i'm aware. if so, it's not in the release instructions
<|> 13:56:04 < chromatic> Were they failure messages about lacking permissions to update certain distros, such as Test::Simple?
<|> 13:56:22 < particle> yes, something like that
<|> 13:56:23 < chromatic> It could be that META.yml needs a noindex (or whatever it is) directive for bundled modules.
<|> 13:56:36 < chromatic> As far as I know, that doesn't block the upload.  It's just a warning.
<|> 13:56:44 < particle> yeah, i found that out
<|> 13:56:59 < particle> but too late, i had already uploaded a new tarball
<|> 13:57:30 < particle> things like Parrot::Docs::HTMLPage and other Parrot::* failed
<|> 13:57:38 < allison> particle: worth adding a note to the release instructions?
<|> 13:57:57 < chromatic> Andreas might know more about that error.
<|> 13:58:02 < particle> yes. of course, i'd like to add the correct note, and wasn't sure what that was...
<|> 13:58:56 < allison> yeah
<|> 13:59:11 < allison> or, alternatively, figure out what we need to do to fix META.yml
<|> 13:59:19 < particle> i'll put a note in there about ignoring index failure messages and cleaning up afterwards
<|> 13:59:43 < particle> (until META.yml is fixed)
<|> 14:00:04 < chromatic> Then back to Makefile.PL/Configure.pl.
<|> 14:02:05 < chromatic> Or, alternately, question #4.
<|> 14:02:08 < particle> Makefile.PL should run Configure.pl -- it can live in the distro permanently for all i care
<|> 14:02:13 < chromatic> Why should it run it?
<|> 14:02:30 < allison> so we're not maintaining two copies of Configure.pl
<|> 14:02:41 < chromatic> That's the only answer I could come up with.  That works.
<|> 14:02:49 < allison> and so the dummy Makefile.PL can handle any different options syntax
<|> 14:02:55 < allison> translating
<|> 14:03:14 < particle> agreed
<|> 14:03:23 < chromatic> 4) PIR doesn't have class methods.
<|> 14:03:24 < chromatic> Should it?
<|> 14:03:30 < allison> yes
<|> 14:03:43 < chromatic> On class literals?
<|> 14:03:46 < pmichaud> can't one simply call a class method on the class object itself?
<|> 14:03:48 < allison> technically PIR does have class methods
<|> 14:03:49 < particle> urk
<|> 14:04:00 < allison> but they're indistinguishable from object methods
<|> 14:04:20 < allison> and currently implemented as opcodes
<|> 14:04:24 < pmichaud> $P0 = getclass 'Foo'; $P0.'xyz'()
<|> 14:04:25 < chromatic> o = 'SomeClass'.'new'()
<|> 14:04:31 < allison> yes
<|> 14:04:37 < allison> that's already in the draft PDD
<|> 14:04:51 < particle> yes to chromatic? pmichaud? both?
<|> 14:04:54 < chromatic> okay.  I'll read what's on your hard drive next time before asking questions.  :)
<|> 14:04:55 < allison> (look at recent tickets attached to the objects PDD
<|> 14:05:04 < allison> yes to chromatic
<|> 14:05:15 < allison> not sure what patrick's going for
<|> 14:05:22 < pmichaud> just what exists now
<|> 14:05:25 < particle> right
<|> 14:05:34 < particle> i know patrick's way works
<|> 14:05:42 < particle> why do we need another?
<|> 14:05:45 < allison> ah, the semicolon represents two lines, oday
<|> 14:05:56 < pmichaud> (right, that's the irc convention for newlines in PIR :-)
<|> 14:06:10 < particle> imo it should be the pir convention, too
<|> 14:06:10 < chromatic> That's it for me.
<|> 14:06:30 < allison> particle: you want to add semicolons to assembly language?
<|> 14:06:37 < chromatic> They're for comments.
<|> 14:06:43 < particle> it's not assembly language anymore
<|> 14:06:44 < chromatic> Just like McCarthy indented.
<|> 14:07:02 < particle> .local string foo ; foo = 'abc'
<|> 14:07:03 < allison> so, for chromatic: I don't intend to have methods called on bare strings
<|> 14:07:11 < particle> *phew*
<|> 14:07:13 < chromatic> How about quoted strings?
<|> 14:07:20 < allison> nope
<|> 14:07:30 < allison> for all it's charms, PIR really is an assembly language
<|> 14:07:31 < chromatic> Double-quoted strings?
<|> 14:07:38 < allison> c: nope
<|> 14:07:40 < particle> 'NO'.say
<|> 14:07:41 < chromatic> Dotted strings?
<|> 14:07:53 < allison> heh, no :)
<|> 14:07:55 < particle> how about no methods on constants
<|> 14:08:06 < chromatic> Just checking.
<|> 14:08:18 < allison> particle: basically
<|> 14:08:23 < allison> you only have methods on PMCs
<|> 14:08:28 < particle> i should say, values
<|> 14:08:34 < allison> the PMC may represent a constant in an HLL
<|> 14:08:44 < allison> and if so, you can call a method on it
<|> 14:08:56 < allison> (that's how we implement ruby constants with methods)
<|> 14:09:34 < allison> but parrot itself doesn't have that magic for any types except PMCs
<|> 14:09:38 < pmichaud> fwiw, I expect that the 'getclass' approach will be what perl6 uses
<|> 14:10:09 < chromatic> I'll save my related question for the Objects PDD.
<|> 14:10:10 < chromatic> Thanks.
<|> 14:10:24 < allison> yeah, my impression is that generating the extra line to do the lookup separately from the method call is not a problem
<|> 14:11:04 < chromatic> I'm thinking specifically about constructors.
<|> 14:11:21 < allison> me too, since that's the primary context for wanting class methods
<|> 14:11:27 < pmichaud> for perl6 it's likely to be   $P0 = getclass 'Foo';  $P1 = $P0.'new'(....)
<|> 14:11:39 < pmichaud> matt and I had a thread about this last fall
<|> 14:11:44 < pmichaud> (in p6i)
<|> 14:12:35 < particle> $P0 = get_namespace ['Foo'] ; $P1 = $P0.'new'(...)  # let's hope not
<|> 14:12:53 < chromatic> Seems like that's redundant.
<|> 14:12:59 < chromatic> $P0 should already be an object.
<|> 14:13:09 < allison> that's a comment about the "merging namespaces and classes" proposal?
<|> 14:13:20 < particle> yes
<|> 14:13:45 < allison> however they're implemented, I expect 'getclass' would be the sanest way to get a class object
<|> 14:14:08 < pmichaud> (some hll's would actually have the class objects in a lookup table by name)
<|> 14:14:11 < allison> I suspect it makes the most sense for namspace to 'have a' class object
<|> 14:14:35 < pmichaud> $P0 = lookuptable['Foo'];  $P1 = $P0.'new'()
<|> 14:14:38 < chromatic> Or vice versa?
<|> 14:14:57 < particle> right, we were previously talking class-has-a-namespace
<|> 14:15:16 < allison> pmichaud: aye, but there's no reason for that not to have 'getclass' as syntatic sugar
<|> 14:15:40 < allison> p & c: well, it's really a two way link
<|> 14:15:54 < allison> the class has to know what it's namespace is
<|> 14:16:05 < allison> and the namespace needs to be able to retrieve it
<|> 14:16:07 < chromatic> Why does the namespace care?
<|> 14:16:12 < allison> its class
<|> 14:16:23 < allison> because the namespace defines the name of the class
<|> 14:16:26 < chromatic> The NameSpace PMC?
<|> 14:16:44 < allison> so, if you're looking up a class by name in the symbol table, you're looking it up in the namespace PMC
<|> 14:17:10 < allison> Parrot currently has a separate registry for class names
<|> 14:17:24 < allison> but, it's kind of broken
<|> 14:17:42 < allison> and it just makes more sense to store all hll names in the same structure
<|> 14:18:20  * particle just thought of ['Foo'].'new'(...)
<|> 14:18:20 < chromatic> There are reasons to have a namespace not attached to a class.
<|> 14:18:27 < allison> when chip and I have talked about "merging classes with namespaces" there are several ways to do it, but that's the core problem
<|> 14:18:53 < allison> chromatic: elaborate
<|> 14:19:24 < allison> I mean, there's the obvious "some namespaces are just modules, not classes"
<|> 14:19:26 < chromatic> If you're not using objects, for one, but you want to separate your functions into namespaces.
<|> 14:19:52 < allison> right, so it's not required for every namespace to have an associated class
<|> 14:20:08 < chromatic> Okay.
<|> 14:20:33 < allison> but if you have a class associated with a namespace, is there a reason not to mark that association in the namespace?
<|> 14:21:11 < pmichaud> possibly related question:  if I have a class called ['Foo';'Bar'], what does the 'Bar' entry in Foo's symbol table reference?
<|> 14:21:22 < pmichaud> (where 'Foo' is a namespace)
<|> 14:21:32 < particle> a namespace, no?
<|> 14:21:36 < allison> it references another namespace pmc
<|> 14:21:38 < allison> yes
<|> 14:22:01 < pmichaud> so, in Perl 6,   if I do   $::Foo<Bar>  I'm not going to get the class?  Or I have to do magic to make it return me the class?
<|> 14:22:21 < allison> that entirely depends on how you implement that syntax
<|> 14:22:37 < pmichaud> okay, suppose  $x = 'Bar';  $::Foo<$x>
<|> 14:22:39 < allison> PIR will provide a way to get at both the namespace PMC and the class object
<|> 14:23:09 < allison> pmichaud: is this PIR or Perl6?
<|> 14:23:14 < pmichaud> perl 6 here, sorry
<|> 14:23:19 < particle> what does getclass do if you pass it a namespace pmc?
<|> 14:23:22 < allison> (adding semicolons to PIR is confusing ;)
<|> 14:23:37 < pmichaud> (I'll start using slashes or backslashes then for PIR)
<|> 14:24:36 < allison> I'd say
<|> 14:24:38 < allison> $P0 = getnamespace 'Foo'
<|> 14:24:39 < allison> $P1 = $P0.getclass()
<|> 14:24:40 < chromatic> Right now getclass should complain because there's no getclass_p opcode.
<|> 14:25:13 < pmichaud> anyway, I'll figure that part out when I get there.  In p6, at least, classes and namespaces are relatively synonymous
<|> 14:25:29 < allison> We could add an alternate so that
<|> 14:25:30 < allison> $P1 = getclass $P0
<|> 14:25:32 < allison> does the same thing as the direct method call on the namespace object
<|> 14:25:53 < particle> that's in the ns-hasa-class world
<|> 14:26:14 < particle> i suppose it could work either way, nm
<|> 14:26:21 < allison> pmichaud: what you can be sure of is that there will always be a way to retrieve either the namespace object or the class object, no matter how they're linked
<|> 14:26:33 < allison> particle: right, it doesn't matter which way they're stored
<|> 14:26:41 < pmichaud> allison: that works for me.  I can then prioritize whichever is easiest / most useful
<|> 14:26:45 < pmichaud> and get from one to the other
<|> 14:26:51 < allison> just that the class and namespace both know that they're linked to the other
<|> 14:27:33 < chromatic> And I thought PDD 21 was almost done.
<|> 14:27:42 < allison> it is
<|> 14:27:50 < particle> pm: i expected you to talk about assign vs bind... have you resigned yourself to the current state?
<|> 14:27:52 < allison> this only adds one method to the API
<|> 14:28:13 < particle> allison: hope you've found my pdd22 notes/tests helpful
<|> 14:28:14 < pmichaud> particle:  I'm resigned to the current state
<|> 14:28:29 < pmichaud> particle:  what I've been looking for is more optimization than implementation, so it can wait
<|> 14:28:40 < allison> particle: indeed
<|> 14:29:11 < allison> particle: I committed them, didn't I?
<|> 14:29:19 < particle> did you? didn't notice
<|> 14:30:10 < particle> no, i sent a second round, i think you missed them
<|> 14:30:17 < pmichaud> assign vs. bind summary:  the code that we have to generate for assignment operations seems pretty ugly -- nine PIR statements per assignment.  Having specialized opcodes for this would seem to be very useful (and give a significant speed boost).  But past-pm can continue to generate the long sequence for the foreseeable future
<|> 14:30:36 < allison> r16620: In I/O PDD, apply patch and answer questions from particle++.
<|> 14:30:41 < particle> allison: see mail titled "[PATCH] PDD22 spec notes and ParrotIO tests"
<|> 14:30:50 < particle> ...sent yesterday
<|> 14:31:11 < pmichaud> also, I'm sure everyone here knows this already, but don't forget that OSCON proposals are due Feb 5 :-)
<|> 14:31:35 < allison> particle: ah, awesome, thanks!
<|> 14:31:50 < allison> yeah, who is submitting for OSCON and what?
<|> 14:31:59  * particle needs to brainstorm about oscon topics
<|> 14:32:10 < pmichaud> I will undoubtedly have a parrot compiler tools overview
<|> 14:32:19 < allison> I should do the Parrot overview talk, but I just don't think I'll be able to do a talk and run the conference at the same time
<|> 14:32:20 < pmichaud> i.e., walking through the entire process of building a compiler in parrot
<|> 14:32:27 < chromatic> I could do the Parrot overview talk.
<|> 14:32:28 < allison> pmichaud: excellent!
<|> 14:32:37 < allison> chromatic: okay, sounds good
<|> 14:32:39 < pmichaud> (pge, tge, past-pm, using languages/abc as an example, with parts of perl6 thrown in)
<|> 14:32:46 < pmichaud> and, of course, a status-of-perl6 talk
<|> 14:32:57 < allison> chromatic: I'm happy to do the talk with you (as co-speaker)
<|> 14:33:00 < particle> pm: i could join you on that
<|> 14:33:13 < pmichaud> particle: that'd be great.  I'll be happy to join/help with any other talks people might want to do
<|> 14:33:36 < chromatic> Great, with the conference chair on my talk I can't fail!
<|> 14:34:08 < allison> ok, it sound's like we've hit the most important set of subjects
<|> 14:34:29 < particle> we may need to get some coordinated time for writing proposals this week
<|> 14:34:40 < particle> wiki? private mails?
<|> 14:34:41 < pmichaud> I should be around all week
<|> 14:34:49 < pmichaud> irc/mail/wiki all work for me
<|> 14:35:13 < particle> also, next tuesday i'll be out on jury duty
<|> 14:35:20 < allison> ok
<|> 14:35:40 < chromatic> Let's make Jesse be in charge then.
<|> 14:35:46 < particle> please! :)
<|> 14:35:47 < allison> fall back for running the meeting: jesse, chromatic, me, somebody else
<|> 14:36:37 < allison> ah, it won't be me, I'll be on a plane to South Africa
<|> 14:36:54 < chromatic> I'll do it.
<|> 14:36:59 < particle> allison: trade you!
<|> 14:37:18 < allison> particle: sounds like a great trade ;)
<|> 14:37:39 < allison> c: I'll send my report to you
<|> 14:37:47 < chromatic> Okay great.
<|> 14:37:54 < particle> allison: if you don't commit first, i'll commit the pdd tests tomorrow
<|> 14:37:57 < particle> c: i'll do the same
<|> 14:38:09 < chromatic> Oh that reminds me.
<|> 14:38:23 < chromatic> 5) Does anyone have a better idea how to test the namespace PDD with regard to HLLs?
<|> 14:38:31 < allison> particle: okay
<|> 14:38:35 < chromatic> I couldn't figure it out, but I was on an airplane.
<|> 14:39:12  * particle still has to review pdd21 for testability
<|> 14:41:52 < allison> particle: looks like some of the patch to the I/O pdd is questions
<|> 14:42:07 < allison> particle: so I'll go through and answer them today, and commit tonight
<|> 14:42:19 < particle> fab!
<|> 14:42:35 < particle> the answers to those questions will have consequences for the tests
<|> 14:43:23 < allison> ok. I'll apply and commit the pdd part, and let you commit the tests
<|> 14:43:42 < particle> hey, feel free to change the tests! :P
<|> 14:43:54 < particle> but your way works fine, too :)
<|> 14:48:02 < allison> sounds like we're wrapping up. Thanks everybody!
<|> 14:48:07 < chromatic> until next week
<|> 14:48:13 < pmichaud> see you all next week
<|> [Done]
% | is now known as spinclad
<spinclad> [Hmm. only some got through. continuing slowly to try to avoid flooding. thought irssi took care of that...]
<spinclad> [ah, never mind, all done]
% particle has left particle!~particle@144.81.84.129
% particle has joined #parrotsketch
% particle has left particle!~particle@c-24-19-12-148.hsd1.wa.comcast.net
% particle has joined #parrotsketch
% particle has left particle!~particle@24.19.12.148
% spinclad has left spinclad!~rhale@209-94-133-172.c3-0.bkl-ubr2.sbo-bkl.ma.cable.rcn.com
% spinclad has joined #parrotsketch
% spinclad has left spinclad!~rhale@209-94-133-172.c3-0.bkl-ubr2.sbo-bkl.ma.cable.rcn.com