% leo has left leo!lt@feather.perl6.nl
% leo has joined #parrotsketch
% rafl has left rafl!~rafl@armitage.dreker.org
% rafl has joined #parrotsketch
% Coke has joined #parrotsketch
<obra> Hi gang
<particle_> hola
<leo> hi @all
<obra> patrick can't make it today
<chip> <arrival/>
<chip> hi
% ambs has joined #parrotsketch
% allison has joined #parrotsketch
<obra> okie. let's get rolling
<obra> leo: how's life in Wien?
<leo> I'm still in a superpostion of locations (Herrnbaumgarten|Vienna) 
<leo> currently Hbgtn.
<leo> end of the week Vienna and http://conferences.yapceurope.org/apw2006/
<leo> so I still don't have much parrot coding time
<leo> * implemented find_type t, ['some'; 'class'] keyed variant
<leo> * a lot of bug fixes related to MMD and nested class names and combinations of these
<leo> * test NameSpace.export_to() method
<leo> * new  NameSpace.parent() method - should that be .get_parent() ?
<leo> EOR
<obra> Chip?
<chip> Last week evaporated, to within epsilon.
<chip> Today looks good though.  Tomorrow, perhaps, too.
<chip> I've got a wacky goal, though: Edit all PDDs before YAPC.
<obra> ooh
<leo> woot
<chip> And now that I've told you, I have to do it  :-)
<chip> The story we tell at YAPC to gather minions should include something cool like that
<chip> EOR
<obra> Ok. cool
<obra> allison? how's life?
<allison> good
<allison> my time has been divided between TGE refactors and licensing
<allison> some time later today I'm going to push a collection of TGE refactors from my local SVK repository
<particle_> any api change?
<allison> * Updated TGE so it can compile the header information for the grammar
<allison> * Updated TGE so that the before-compile-time 'precompile' and the runtime 'compile' both use the same compile process
<allison> particle: no API changes this time, it's all hidden behind the abstraction
<allison> * Update Punie to remove the intermediate .pir files that only add header info for compiled TGE grammars
<allison> * various cleanups along the way
<allison> EOR
<allison> (oh, by "header info" I mean the .namespace directive and :load subroutine)
<obra> particle_: you around?
<chip> while waiting: obra, glad to hear that you're taking svk under your wing
<obra> Thanks.
<particle_> i'm here
<obra> We're all very psyched here.
<obra> particle_: how's stuff?
<particle_> not much going on for me this week
<particle_> i've been working towards some parser mods for perl6
<particle_> asked some questions of patrick
<particle_> haven't gotten the answers i need yet
<particle_> i understand he'll have time again shortly
<particle_> so i'm waiting patiently and working on yapc slides
<particle_> ooh, speaking of which...
<particle_> i noticed there hasn't been any changes to the official schedule
<particle_> so, chip's not 'officially' speaking wednesday, as we've previously planned
<particle_> if patrick's too busy, i'll take lead on follow ups to make sure that happens
<particle_> .end
<obra> That'd likely be useful. thanks, particle_ 
<allison> much appreciated, thanks
<chip> si
<obra> speakning of patrick
<obra> 13:14 <pmichaud> I will have to miss #parrotsketch today :-(
<obra> 13:14 <pmichaud> my report is that I'm continuing to work on arrays and multisubs, and I did
<obra>                  some work with Coke on APL
<obra> 1
<obra> Coke: you around?
<Coke> yes.
<obra> how's tricks?
<Coke> did some more work on APL this week - 2D arrays now render somewhat properly. 
<Coke> other minor updates to APL - need to work on getting my presentation ready, but there's a lot TODO in terms of implementation before YAPC, I think. 
* Coke submitted a lot of failing tests for parrot based on getting APL to use unicode sub names this week - leo has already made them all pass.
<Coke> EOR
<leo> well these aren't unicode  subnames at all ;)
<obra> :)
<obra> Who'd I miss?
<leo> just a collection of ascii chars like 'dyadic:\u2345'
<Coke> leo - uh, no. they're unicode now.
<leo> ah ok
<obra> And failing that: question time. 
<Coke> the subnames are now unicode:"dyadic:\u2345". Hence all the tests. =-)
<obra> What's on your mind, everybody?
<Coke> is there a plan for the hackathon?
<Coke> or are we going to figure it out when we get there?
<obra> Coke: basically, we've got the common rooms in the dorm.
<obra> There's free wifi.
<obra> We'll bring in food
<obra> Patrick has been prepping tasks and designs.
<Coke> there we go. that's what I was looking for, tasks - is this primarily with perl6 in mind? or parrot in general?
<obra> Anything that advances the state of perl6 and tickles your fancy
<obra> Hacking APL or TCL helps parrot. which helps p6.
<chip> &rho;&rho;&rho;'YOUR BOAT'  <- the only APL/English pun I know
<chip> Good contextual design requires seeing people using the system and watching waht they actually do.  For me the hackathon is a combination of feedback, brainstorming, and observation
<chip> and writing so we don't forget what we've come up with
<obra> Scariest moment of the YAPC::Asia hackathon for me: having Matz sit down next to me and watch me try to debug something
<chip> hehehe
<chip> Point taken: I'll try to be unthreatening, if not unobtrusive
<chip> As a default task list we could use the RT.
<chip> Debian guys call this kind of thing a "bug-squashing party"
<obra> Cool.
* Coke points chip at the enormous # of PDD-related bugs.
* Coke ducks.
<obra> ok. anythign else?
<chip> but look, there's a straw in *your* eye!
<particle_> ingy's setting up a 'house of code' in seattle
<chip> ?
<obra> a house of code?
<particle_> he's moved here
<particle_> and is renting a house
<chip> ISTR something like that was once attempted in Portland
<particle_> which he wants to have full of hackers of all types
<particle_> i'll be promoting parrot there, when it gets off the ground (so to speak)
<obra>   cool
<allison> neato
% woggle has joined #parrotsketch
<particle_> howdy woggle
<obra> Woggle. Hello. We're just wrapping up, but have time for your replort.
<obra> How's the hacking?
<woggle> Okay.
<woggle> I'm working on creating some frontend stuff (opcodes, PMC types) and an implementation for them to call sufficient to make sure that they call the right things.
<woggle> The interface being what I attached to my post to the list.
<woggle> I guess to do that 'right' I'm going to need to annotate the vtable so I can have a better idea what is a read and a write, and I probably should be asking about the correct way to do that.
<woggle> I mean, the obvious thing is to extend the existing annotations ([MATH], etc.), which I suspect won't be a problem since no one seems to use them.
<woggle> I've also been checking over what I'll have to do when I implement deep backend stuff to make sure my frontend is sufficient to support something reasonable.
<chip> Hrm.
<chip> Do you mean read/write in the C++ const humpty-dumpty sense, or in the "absolutely no mutation of the bit pattern allowed" sense?
<woggle> The only issue I can think of is that I'd like to be able to throw some exception to say 'oh, I detected your transaction was invalid while preforming a write for you, please go to retry'. But supporting that would require the exception implementation to be stable, which it doesn't seem to be yet.
<Coke> Oh, I had a thought about inter language interoperability and how PMCs actually may actually make this more difficult.
<woggle> chip: As in 'absolutely no unthreadsafe mutation of the bit pattern'.
<woggle> I don't, however, think it would be particular bad to tell people they can only use certain types through STM directly.
<woggle> s/particular/particularly/
<chip> woggle: consider keyed fetch on a dbm-tied hash.  it's unquestionably a read action, but it doesn't modify the user-visible state of the object, only an internal cache
<chip> ah, the type restriction ... interesting
<chip> s/but/because/
<chip> and the "threadsafe" is interesting too, because if you have a boolean that you choose to implement with volatile sig_atomic_t, then you could have a threadsafe assignment operator
<chip> so "threadsafe" is the real predicate you're interested in, not "read".
<chip> ?
<woggle> The STM implementation can't really work the magic to make transactional access to complex data structures efficient anyways, so people wanting STM-usable complex data structures will probably reimplement them to use more values underneath.
<woggle> chip: The access should also not cause a conceptual change to the state of the object.
<chip> ok
<chip> cancel that, then.
<woggle> s/values/STM-wrapped values/
<chip> I was hoping not to have to "go there" on read vs. write operations; leo's been "suggesting" (ahem) that value objects need this, and it's possible there's enough overlap with the STM requirement that I actually will have to bite the bullet.  TO the extent you can soften the bullet up a little, that'd be nice
<woggle> I can air on the side of caution and do writes when I don't need to, but each write that isn't actually a write will require a copy and cause extra, unneeded retries.
<woggle> I also aim to provide a more explicit interface which can avoid this whole 'magically know if it's a write' thing.
<woggle> But I think people would find that inconvenient.
<chip> would it require them to make a call when they realize the caller wants them to modify their own state?
<obra> ok. is this discussion better on #parrot?
<leo> the more that it would break existing transparency of interfaces
<chip> actually yes I think
<leo> yep
<chip> {re #parrot}
<obra> ok
<obra> A brief report from chromatic:
<obra>  can't seem to get on IRC from my parents' house, but I don't have much to                      
<obra> report.  After the latest keyed class and object changes, I've been patching                     
<obra> Pheme to use keyed namespaces.  Unfortunately, I run into a segfault and                         
<obra> weird multidispatch failures that I can't reproduce in a short test case.                        
<obra>                                                                                                  
<obra> It feels a lot like the multi/PBC error that Patrick and I eventually                            
<obra> reproduced a while back.  I'll try to get on #parrot with a patch or some                        
<obra> code to demonstrate it.                                                                          
<obra> anyone have anything else before I bang the gavel? Oh. Next week, I may be on an airplane
<obra> allison: could you ringlead in my absence?
<allison> sure
<chip> "all rise for the left on-a-tear obra"
<obra> Heading to Oslo for NPW
<obra> Thanks
<obra> ok.
<obra> catch you all "soon"
<leo> obra: thanks
<chip> thanks man
<Coke> Довиждане.
<obra> Is that APL? </rimshot>
<allison> ah, the joys of unicode :) I can just read that too, even though I mainly did handwritten russian
<Coke> it's not even russian! =-) (at least, not intentionally) Ironically, I don't think APL supports non-ascii chars.
<allison> then I can't just read that :)
<obra> doesn't work for me in irssi
% ambs has left #parrotsketch
<allison> the best I can make it out is "Dovujdane"
<obra> Ah :)
<Coke> dovizhdane (good bye)
<allison> ah, so I was right
<obra> once allison said that, I got it. I got al ot of Ds with ahshes.
<obra> Coke: what slavic language?
<Coke> bulgarian.
<allison> different language in a similar famly>?
<allison> ah
<obra> yeah, allison
<allison> right
% particle_ has left particle_!~particle@144.81.84.131
% allison has left allison!~chatzilla@sub17-30.member.dsl-only.net
% particle has joined #parrotsketch
% Coke has left Coke!~wcoleda@host-69-95-19-3.roc.choiceone.net