Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2008-06-24

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

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

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary