% mdiep has joined #parrotsketch
<mdiep> when's the meeting? in an hour?
<leo> yep
<mdiep> great, thanks.
<chip> wtf?  oh yeah, it stuck to UTC.  I forgot!
* chip updates his kalendar
* chip should probably leave it, it'll increase chance of being early
<obra> heh
<obra> audrey won't be around today, but I have her report canned
% Coke has joined #parrotsketch
% allison has joined #parrotsketch
<obra> Hi gang!
<particle> 'lo
<obra> first up is audrey
<obra> she's not here
<leo> hel'
<obra> so, I'll paste in her report
<obra> 12:46 <obra> Oh. parrot sketch in 75 min
<obra> 12:46 <audreyt> can't stay up for that 'mfraid
<obra> 12:46 <obra> ok.
<obra> 12:47 <obra> is there anything you want to report?
<obra> 12:48 <audreyt> yes... mostly that librules, a C-based implementation of op table and its match/token/parser structure, has
<obra>                 been started today under pugs/src/rules/
% pmichaud has joined #parrotsketch
<obra> 12:48 <audreyt> in an attempt to enhance PGE::OPTable's performance and provide common layer for P5/PIR/Hs
<obra> 12:48 <audreyt> -based rules implementations
<obra> 12:49 <obra> ok.
<obra> 12:49 <audreyt> some tests would be most welcome - it could just be tests for the Parrot PGE::OPTable checked in parrot tree,
<obra>                 and I'll pickup from there.
<obra> 12:49 <obra> is this your code?
<obra> 12:49 <audreyt> yes.
<obra> 12:50 <obra> *nod*
<obra> 12:50 <audreyt> pmichaud said he would like to see the slow PGE::Match Cified
<obra> 12:50 <audreyt> and would also be happy to see the bottom layers dePIRized
<obra> 12:50 <audreyt> Judy proved to be a pretty good data structure API for C-land porting
<obra> 12:51 <audreyt> so I'm working with Judy for now, but if parrot later wants to link against it
<obra> 12:51 <audreyt> then parrot can either NCI Judy, or embed it, or provide an adapter API based on ResizablePMCArray and
<obra>                 ParrotHash
<obra> 12:51 <audreyt> but I think Judy makes a lot of sense for sparse mappings and arrays.
<obra> 12:52 <obra> *nod*
<obra> 12:52 <obra> url for Judy?
<obra> 12:52 <audreyt> judy.sf.net
<obra> 12:54 <obra> Thanks
<obra> er. going to restart that paste so patrick sees it
<obra> first up is audrey. she's not here. I'll paste in her report
<obra> 12:46 <obra> Oh. parrot sketch in 75 min
% chromatic has joined #parrotsketch
<obra> 12:46 <audreyt> can't stay up for that 'mfraid
<obra> 12:46 <obra> ok.
<obra> 12:47 <obra> is there anything you want to report?
<obra> 12:48 <audreyt> yes... mostly that librules, a C-based implementation of op table and its match/token/parser structure, has
<obra>                 been started today under pugs/src/rules/
<obra> 12:48 <audreyt> in an attempt to enhance PGE::OPTable's performance and provide common layer for P5/PIR/Hs
<obra> 12:48 <audreyt> -based rules implementations
<obra> 12:49 <obra> ok.
<obra> 12:49 <audreyt> some tests would be most welcome - it could just be tests for the Parrot PGE::OPTable checked in parrot tree,
<obra>                 and I'll pickup from there.
<obra> 12:49 <obra> is this your code?
<obra> 12:49 <audreyt> yes.
<obra> 12:50 <obra> *nod*
<obra> 12:50 <audreyt> pmichaud said he would like to see the slow PGE::Match Cified
<obra> 12:50 <audreyt> and would also be happy to see the bottom layers dePIRized
<obra> 12:50 <audreyt> Judy proved to be a pretty good data structure API for C-land porting
<obra> 12:51 <audreyt> so I'm working with Judy for now, but if parrot later wants to link against it
<obra> 12:51 <audreyt> then parrot can either NCI Judy, or embed it, or provide an adapter API based on ResizablePMCArray and
<obra>                 ParrotHash
<obra> 12:51 <audreyt> but I think Judy makes a lot of sense for sparse mappings and arrays.
<obra> 12:52 <obra> *nod*
<obra> 12:52 <obra> url for Judy?
<obra> 12:52 <audreyt> judy.sf.net
<obra> 12:54 <obra> Thanks
<obra> 12:57 <audreyt> other than that... p6ast draft#0 is produced with Lit, Undef, Code, Capture, Signature, Object, Call, Apply,
<obra>                 Var, Sym, Magic, Bind, Assign, Exp, Stmt forms
<obra> 12:58 <audreyt> the draft is currently a mess, but next week I'll work on something suitable for more serious code analysis.
<obra> 12:59 <audreyt> then we'll see how much, or all, of this can be translated to POST, and I think it helps to give that a
<obra>                 concrete syntax too (as in the AbsPIR)
<obra> 13:01 <obra> nod
<obra> 13:01 <audreyt> also, pugscapture.pmc may be an interesting start to be a PMC-level (instead of PIR-level) Capture/Match
<obra>                 object implementation. cognominal said he'd like to see it as part of base PMCs
<obra> 13:02 <audreyt> though I'd like more input from pm and leo re the applicability of this arrayhashscalarmonster implementation.
<obra> 13:02 <audreyt> we have some tests for it in capture.t though.
<obra> 13:02 <audreyt> ok, I think that's all
<obra> 13:03 <audreyt> oh, and I told pm that he can mv language/pugs/* into language/perl/*
<obra> 13:03 <audreyt> I mean language/perl6/*
<obra> 13:03 <audreyt> anytime he wants, and I agree there should just be a single language/perl6/ codebase in the parrot tree.
<obra> 13:03 <obra> *nod*
<obra> 13:04 <audreyt> though I'm not sure how to refer to that :)
<obra> 13:04 <audreyt> I mean, language/tcl is known as partcl
<obra> 13:04 <audreyt> I've been using "Parrot/Perl6"
<obra> 13:05 <audreyt> or "PGE/Perl6"
<obra> 13:05 <obra> nod
<obra> 13:06 <audreyt> but a codename (like punie, pugs, lrep, etc) may reduce confusion :)
<obra>  
<obra> And that's it
<obra> (Did I manage to get myself kicked for pasting too much?)
<obra> [End of audrey's report]
<obra> who wants to go next?
* obra picks [on] chip
<pmichaud> you're still here, obra :)
<obra> What's new?
<obra> oh good.
<obra> ok. if ENOCHIP, patrick, what's new?
<pmichaud> I have a longish report also, so will paste
<pmichaud> =pod REPORT
<pmichaud> -> The perl6/perl6.pbc parser is now a compiler
<pmichaud> -> Many people are now contributing tests and code (and I still need to make announcements to the various lists)
<pmichaud> -> Lots of things actually work, including [if|unless]/elsif/else, chained ops, short-circuit ops
<pmichaud> -> The full list is in http://svn.perl.org/parrot/trunk/languages/perl6/lib/grammar_optok.pge
<pmichaud> -> In fact, the grammar_optok.pge file is used to generate the operator precedence parser from a perl6-like syntax
<pmichaud> -> It also can specify the inline PIR to generate for each operator (if not specified, it generates a sub call)
<pmichaud>  
<pmichaud> -> The "rulec.pir" compiler has now become "pgc.pir", which can create generate the PIR for parse rules and operator precedence tokens from files using a perl6-like syntax.
<pmichaud> -> Thus the Perl 6 parsing grammar is almost completely specified by grammar_optok.pge and grammar_rules.pge.
<pmichaud> -> The current codegen goes straight from PAST->PIR; this will likely change in the future but I felt it was an easier baby step to take than going through POST.
<pmichaud> -> Some people will likely start to run into problems if they do not have ICU available in Parrot, because some string ops will not work on unicode strings w/o ICU
<pmichaud> -> I sent a message to chip and leo last week regarding passing "is rw" params -- some help there will be worthwhile
<pmichaud> -> The changes to namespace implementation will require a lot of refactoring of PGE code; overall this will be an improvement, but there will be a "break point" where existing users of PGE will have to convert.
<pmichaud> =end REPORT
<obra> wow
<pmichaud> I should clarify "The Perl 6 parsing grammar..."
<pmichaud> I mean there to say that the specification is performed mostly in those two files, not that I have most of the grammar specified :-)
<pmichaud> die "Okay, really done now."
<obra> Ok. so, how can folks best help you?
<pmichaud> tests and code are all welcomed
<pmichaud> I'm drinking from a firehose a bit because it's now at a level where many can participate, and there's a lot of low-hanging fruit
<obra> *nod* where arre folks sending contributions?
<pmichaud> we're targeting the pugs test suite -- however, the bulk of the suite relies on "Test.pm", which itself seems to want junctions and sub calls
<pmichaud> so, we'll be implementing some other tests on the side
<chip> and somewhere, Damian is smiling
<pmichaud> at the moment the contributors all already have parrot repo commit access
<obra> I wonder how much Test.pm has evolved since I last poked at it.
<pmichaud> after that contributions can come through p6c or directly to me
<particle> pm: we can port Test.pm to a friendlier subset of perl6, if desired
<obra> (Is it feasible to drop in an alternate Test.pm until you have junctions and sub calls)
<obra> heh
<pmichaud> that would likely be very worthwhile, if someone wants to implement it
* leo was just thinking the same
<pmichaud> sub calls should be available reasonably soon
<pmichaud> junctions ... well...
* pmichaud punts
<obra> heh.
<obra> Ok. Anything before I turn to chip?
<chromatic> I bet someone could shim Test.pm to run on the PIR Test::Builder pretty easily...
<pmichaud> I'll be very glad for someone to do that
<pmichaud> I'm generally trying to keep the perl6/STATUS and perl6/README files up to date -- they tend to say what I'm focused on
<pmichaud> but it's all happening very quickly
* pmichaud done
<obra> woot.
<obra> chip?
<chip> woot indeed.  It's been a good week
<chip> I've brought pdd21 and the namespace TODO into agreement with the code, i.e. the TODO is the definitive delta
<chip> I'm starting to think about making RT entries for the TODO entries that may take a while
<obra> you can likely automate that with a grep|mail
<chip> And the feedback has been of the good kind (I'm doing this and it almost works, etc.)
<chip> obra: yes modulo metadata.  even that though maybe.  gotta learn RT really
<chip> as in really learn
<chip> The morphing question still remains.
<obra> next time we're in the same place, I'm happy to give you a crash course.
<chip> If i haven't learned by YAPC, you can first beat me severely about the head and shoulders, then teach
<chip> The issue with morphin is that although it's clear that we can do without it if we have to, I'm not sure yet that removing it is a good idea, if that makes sense.  Removal is pretty much irrevocable.
<chip> What's the bitrot status of Ponie?
<obra> I'm not sure nick is around, but the last I heard the bitrot was composed of two things
<chip> (I ask because Ponie would be the hardest-hit by any PMC revision, esp. something serious like antimorph)
<obra> 1) They were on 5.9.2 or so
<obra> and 2) nick was a little worried about PMC revisions
<obra> but. ponie isn't getting active dev.
<obra> Parrot should do what parrot needs to do.
<chip> Yes, (2) is on my mind.
<chip> Indeed.
<obra> I've pinged nick. not sure if he's around
<obra> he's technically retired from ponie, but he's the best source of knowledge, still
* leo is not thinking about removing morph - Parrot core PMCs don't morph
<chip> I'll be happy to have him chime in on irc, but mail is OK too.
% Nicholas has joined #parrotsketch
<chip> leo: Let's have that discussion at end of #sketch or maybe over in #parrot - it's important but others must report
<Nicholas> Hi
<leo> okie - hi Nicholas 
<chip> oh, well, visiting dignitaries trump procedure
<obra> Nicholas: chip had a question for you
<chip> Nicholas: thanks for dropping in
<chip> Nicholas: Leo's PMC proposals would have had a significant affect on Ponie as is/was.  What was the reason why there would be upheavel - what effects would there be exactly, what would have to be redone?
<Nicholas> The proposals related to heads and bodies, and generational GC?
<chip> Nicholas: yeah.  replacing PMC + PMC_EXT + PMC_data() with variable-sized PMC (i.e. a PMC with a char data[] at the end)
<chip> (including the stuff currently in PMC_EXT)
<Nicholas> It was really that I had a reasonably good idea of how to bend Perl 5's data structures into the existing PMC framework
<Nicholas> and the timing was a spectacularly bad coincidence
<chip> { not surprising, as parrot 0.0 was influenced by topaz, which was designed to implement perl 5 }
<Nicholas> as in the very next task (give or take merging 5.9.3 release in) was starting on the PMC stuff
<Nicholas> so it was mostly a timing thing, w.r.t. stability
<Nicholas> I didn't want to be aiming at a moving target
<Nicholas> that was all
<chip> OK
<Nicholas> (as to the general question)
<chip> You were planning to morph PMCs to implement e.g. tying, right?
<Nicholas> PMC do already morph to implement typing
<chip> Right
<Nicholas> but I thought further and didn't mail p6i
<Nicholas> (or maybe I did)
<Nicholas> there's quite a difference between a PMC that is "I say I'm a Perl 5 scalar" which swaps vtables and internal represenation but presents a consistent API
<Nicholas> (and wants you to think that it's still the same)
<Nicholas> and morphing from "I'm a Scalar" to "I'm an Array"
<Nicholas> and really actually only the former is needed
<chip> Heh.
<Nicholas> the ability to swap vtables and represenation from a bounded group of options
<chip> OK.
<Coke> (side note: other languages have different boundaries on what's swappable.)
<chip> #sketch is for everyone and I've monopolized too much time.
<obra> Ok. we can come back later.
<chip> Nicholas: I'll ask more involved Qs in mail but this has been very helpful
<Nicholas> The only other thing that was potentially useful was to be able to find out if a PMC is in a bounded set, so that you know if this is "something that behaves in a sufficiently Perl 5 way"
<obra> chip: you blocking on anything?
<Nicholas> which I was wondering if it could be done by cheating, by saying "you must have this function pointer in this slot in your vtable"
<Nicholas> (er, sorry, done)
<chip> obra: Nope.  I'm having a lot of fun, btw.  :-)
<chip> Nicholas: {stored}
<obra> woot
<obra> ok. 
<obra> next up, allison
<allison> On punie, I finished up else/elsif blocks
<allison> I'm working on answering an email on the exceptions PDD at the moment
<allison> I'm going to try to put out a revised exceptions PDD by the end of the week
<allison> (got quite a few helpful comments)
<allison> not sure what to do next in Punie, maybe variables
<allison> or loops
<chromatic> Junctions.
<Nicholas> :-)
<allison> bah! history revisionist!
<allison> :)
<obra> .oO{lexicals}
<allison> that's all for me
<pmichaud> allison:  I could use an example of contexts
<obra> ok. blocking on anything? which PDD is next?
<allison> threads is the other one I'm currently working on
<leo> pdd00_int ;)
<allison> though, I keep swapping between it and events
<allison> should I start numbering these?
<chip> "int"?
<leo> there is no real spec about base types, nor scalarish types
<chip> allison: yes so we can talk about them please
<leo> num, str, complex, ...
<allison> shall I just start in sequence after the current highest numbered PDD?
<chip> allison: that's a good idea
<chip> er, pardon me
<allison> looks like that's 22, 23, 24, and 25
<chip> allison: yes please, and if something doesn't survive or get split etc. then we can just retire the number
<allison> ok
<allison> EOR
<obra> ok. *looks around*
<obra> Jerry?
<particle> firstly, i've been standing back in amazement watching how quickly perl6 is developing, on so many fronts (pge, tge, pugs, parrot, parrot/perl6.)
<particle> great work, all
<particle> patrick has made perl6 *very easy* to implement, and i'm quite grateful that he's made the entry barrier low enough for me to help.
<particle> so, i've been adding perl6 ops and pir bodies, playing non-icu guinea pig, and adding perl6 tests, in addition to the usual parrot cleanup/maintenance
<particle> otherwise, i (like many others) am waiting for news from yapc::na
<particle> ...on presentation acceptance
<particle> ZZ
<obra> coke?
<Coke> APL - adding in tests and code to support the vector-based ops ; Tcl - got it mostly working again with the (not so recent) namespace modifications. Still some issues to resolve; talking about any issues I find on the mailing list, adding test(s) to namespace, etc. Blocking on tuits, of course, and any dregs of partrick's time now that p6 is underway at full speed. Still no word on the YAPC talks, as particle noted. EOR
<obra> mdiep?
<chip> { I'm also hoping for YAPC news ... I'll be there whether or not I'm presenting }
<obra> nod
<pmichaud> coke++ on resolving the namespace issues before I have to deal with them.  :-)
<obra> chromatic?
<obra> ok. chromatic, mdiep: feel to pipe up if you return.
<obra> So. YAPC hackathon news.
<chromatic> I'm here.
<chromatic> Sorry.
<obra> s'ok. go for it
<chromatic> I have a tarball of Pheme ready to checkin, except for the weird namespace errors in the generated grammar.
<chromatic> If someone, perhaps someone in Texas, were to help me out, I could check it in soon.
<chromatic> http://wgz.org/chromatic/tmp/pheme.tar.gz
<particle> :)
<pmichaud> be glad to help (assuming I'm the texas person)
<obra> heh.
<chromatic> It could be a stupid mistake, but PGE doesn't seem to be able to find the generated subs for my rules.
<Coke> at a guess, use fully qualified names in your grammar.
<chromatic> Otherwise, it's a compiler for a very small subset of Scheme using PGE, TGE, PAST, POST, and PIR and it passes the defun lambda test.
<pmichaud> actually, I recommend against the fully qualified names
<chromatic> I threw those in because they made it work yesterday.
<leo> folks wait a bit with that ;)
<pmichaud> leo:  the fully qualified names in rules aren't likely to change :-)
<chromatic> That's all for me.
<leo> depends, what a fully qualified name is ;)
<obra> ok. anything else new and exciting, chromatic?
<mdiep> /me appears again
<obra> perfect timing, matt.
<obra> what's new?
<mdiep> mostly I've been trying to keep up with the flood of traffic on IRC and the lists. I have some comments for chip wrt namespace things that I'm hoping to get out today.
<mdiep> then I'll hopefully resume work on partcl and begin helping with perl6 as today's the last day of class, and only 3 exams stand between me and summer.
<mdiep> good work, everyone. things appear to be coming along at fantastic speeds.
<pmichaud> woot, perl6 help
<obra> Congrats
<mdiep> ^D
<obra> Ok.
<obra> so. my two items: YAPC Hackathon and SoC
<obra> The yapc hackathon will happen. 29 June to 1 July. We don't know where yet.
<obra> Please add yourself to the hackathon page at http://yapcchicago.org/wiki/index.cgi?HackAThon, along with a list of what you want to hack on or who you need to get cycles from
<obra> Virtual participation, while not idea, is encouraged and still wonderful, if you can't make it
<obra> Item the second: Google summer of code.
<obra> We're about to head into the second google summer of code. We need ideas for projects that would take a competent student two months of full time hacking to implement.
<obra> They should be concrete projects that we can actually judge delivery on and that will actually be helpful to P6/Parrot
<obra> If you send your ideas to me, I'll collate and forward them to robert who's maintaining the list
<chip> cool
<obra> ok. 
<obra> that's it for me
<chip> deadline for SoC
<obra> Questions? comments?
<obra> um. for projects, nick?
* leo has a few lines to report ;) 
<chip> obra: what's the SoC dealdine?
<obra> 14:53 <Nicholas> no, new FAQ says start May 23, Finish Aug 23
<obra> anything else?
<Nicholas> specifically see http://code.google.com/soc/studentfaq.html#46
<Nicholas> for their timeline. It's all quite tight
<obra> and if not, have a great week everyone
<pmichaud> wait, I want leo's report !
* leo just starts reporting now
<leo> * resynced after one week in .pt
<obra> oh. sorry!
<leo> * exception handling fixes and code cleanup in Getopt/Obj.pir
<obra> go for it leo
<leo> * implemented missing vtables in Resizable*Array
<leo> * various namespace bug fixes
<leo> * some Perl6 {op,}code hacking
<leo> * some Perl6 {op,}code hacking
<leo> * implemented nested class hierarchies (based on the NameSpace PMC as backing store): c1 = newclass  ['Foo';'Bar']         # also subclass c2 = newclass   'Foo'                # these can coexist o1 = new  ['Foo';'Bar'] o2 = new   'Foo' c3 = getclass  ['Foo';'Bar']
<leo> ugly
<leo>    c1 = newclass  ['Foo';'Bar']         # also subclass
<leo>    c2 = newclass   'Foo'                # these can coexist
<leo>    o1 = new  ['Foo';'Bar']
<leo>    o2 = new   'Foo'
<leo>    c3 = getclass  ['Foo';'Bar']
<leo> * allmost all done, except $I0 = isa o, ['Foo'; 'Bar']
<leo> EOR
<obra> ok. cool
* obra holds the floor open for another minute.
<obra> anything else?
<chip> leo++ for low feature latence
<Nicholas> IIRC someone was going to ask Coverity if they could add parrot to their projects. Is that ball in their court yet?
<leo> and I got a Q for allison
<allison> fire away
<chromatic> Nicholas, I asked them.  They will.
<leo> TGE / PGE / compiler tool chain Q:
<leo> can languages/perl6/lib/grammar_optok.pge provide:
<leo>   multi sub infix:+<int, int> is pir(...)  # or whatever the p6 syntax is
<leo>   multi sub infix:+<int, num> is pir(...) 
<leo> and that multi gets called for codegen of these types?
<allison> this is more of a patrick question, as I haven't been working on that part
<leo> s/that multi/one of these multis/ 
<pmichaud> part of the issue is that we don'tknow until runtime what the types are
<leo> but actions are called from TGE?
<leo> my int $a; ...
<allison> tge only compiles the grammar down to PIR code, it doesn't actually execute anything
<pmichaud> at the moment the "is pir" trait is just a hook for me to get code generated -- I don't know that it will live
<pmichaud> I'm having to think through the ramifications of using Perl6's param list to influence TGE.  They're somewhat different beasts
<leo> ok - it's not urgent now, I'm just curious
<pmichaud> for the moment I'm mostly interested in getting a pmc-based implementation able to do the pugs test suite :-)
<chromatic> Hmm, http://lambda-the-ultimate.org/node/1416
<allison> patrick: if it's a useful feature, it's useful, and maybe should be an addition to tge, or some kind of add-on tool
<allison> I need to spend some time looking at the perl6 implementation to see what it might need
<leo> allison: also a pointer to the Sub node (or some Context) would be great
<pmichaud> allison: yes, please do look when you get a chance -- I don't want to go too far astray without knowing that I'm going astray :-)
<pmichaud> really helpful would be knowing lvalue/list/scalar context, and the current sub
<leo> see also languages/perl6/lib/past2pir.tge
<leo>    # this shouldn't be a global, but an attribute of
<leo>    # this shouldn't be a global, but an attribute    # the PAST::Sub node
<leo> accessible from a Var or Lex Node
<obra> should this move back to #parrot?
<leo> likely
<pmichaud> see all next week
<Nicholas> chromatic: good. I wonder if coverity are a bit snowed under dealing with tweaking the scanner in the light of all the new feedback from the projects they already have. It seems to have a moderate false positive rate. But it is really useful at flagging up what might be problem, and is probably 75% accurate, which is a lot better than a poke in the eye with a sharp stick.
<Nicholas> (was waiting)
<leo> I'm aware of a lot of code, which would make the checker not really happy ;)
<pmichaud> chromatic: http://nopaste.snit.ch:8001/paste
* leo thinks that we might first try to fix basic items, like sprintf
<pmichaud> oops
<pmichaud> http://nopaste.snit.ch:8001/6983
<pmichaud> things should parse now
<chip> leo: sprintf is busted?  joy
<leo> there is snprintf almost everywhere
<leo> strcpy -> strlcpy ...
<chip> given licensing issues can we borrow code from Perl 5?
<allison> yes
<chip> BSD/MIT/X license projects too?
<allison> not directly
<allison> we'd need a contribution agreement
<obra> from each contributor to that project?
<chip> OK.  Well, the sv_setpvf* family has its own sprintf implementation and we maybe should grab it.  It will allow us to use format chars that speak directly to Parrot internal structures
<leo> chip: did you look at Judy license too - would it be ok?
<allison> obra: or, just from the project, or the person who wrote that code
<Nicholas> although said printf function was the subject of a recent security alert and is (IMO) way too complex
<allison> well, we wouldn't be shipping Judy, would we?
<Nicholas> so it might be safer to re-implement it carefully.
<allison> just making it a prerequisite?
<chip> Nicholas: granted people have been *&@!ing around with the code and doing stupid things like using signed vars for lengths
<chip> Nicholas: but I think I can fix it
<leo> if it's used in core structures, we'll have to
<leo> (I presume)
<chip> judy is LGPL
<Nicholas> chip: rather you than me. It's big enough to make my head hurt
<chip> allison: that's OK but reuqires a contrib agree?
<allison> so we can link against it
<chip> and we can distribute with it but we can't incorporate it?  pain.
* chip shakes his fist at the copyright gods
<allison> heh :)
<leo> chip: use hammer;
<Nicholas> chip: beware of provoking them. Acts of God may already be lined up for you: http://news.bbc.co.uk/1/hi/sci/tech/4916870.stm
<allison> Artistic allows proprietary versions, so it makes interacting with GPL'd code interesting
<obra> But this was LGPL, no?
<obra> Which is a whole different kettle of fish
<Nicholas> what, if we (hypotheitcally) aggregated Judy code under LGPL then you could in theory make a propriertary parrot (as granted under the Artistic licence), but would have to re-implement Judy?
<allison> the LGPL allows linking without being subject to the viral nature
* chip makes the sign of the c-in-circle and burns a Sony CD in sacrifice
<allison> so you can link against it, but that doesn't give you any greater ability to embed it
<obra> in this case, how is linking different than embedding?
<allison> you don't have to re-implement Judy, just don't ship it in parrot
<allison> make it a prerequisite like gcc
<chip> so the deal would be that source shipments have judy separate, but binary shipments that linked against judy would be *required* to make Judy source availalbe per LGPL
<Nicholas> that's how I read section 6 of http://www.gnu.org/copyleft/lesser.html
<chip> Hm
<allison> aye
<obra> If judy is key, it may be worth talking to the author
<allison> which is fine, because the Judy source is already available
<chip> obvoiusly so much becomes easier if we could get the copyright owners to allow Artistic
<chip> I don't think Judy is key for Parrot, but it would be a fine arrow in the quiver
<allison> I'm not clear on why we would need to embed Judy
<Nicholas> although section 6b is fun and I wasn't aware of it "Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible
<allison> linking to it should be plenty
<Nicholas> ie static embedding may prove "interesting". It's not clear if that's allowed from that section alone.
<chip> allison: I agree.  Administrivia required are inelegant, but will work.
<leo> Judy is currently not needed at all, but recent work from audreyt and future work (optimizations) might indicate that we want Judy
<leo> it *is" damned fast
<chip> I figured we should work out what we know about LGPL libs in general, not because Judy is key
<allison> right, but there's a difference between using Judy and checking Judy into the parrot repository
<allison> we can do one without the other
<chip> a-firmative
<allison> yeah, I need to work with roberta on a quick reference chart
<allison> "we can do X with Y license, and A with B license, etc..."
<leo> allison: that would really help
<chip> that'd be great so that this doesn't have to be re-explained, perhaps incorrectly at N-hand
<Nicholas> that would really help for all "perl" projects, given the number that are "under the same terms as perl"
<obra> Ok. I need to run. I'll catch you guys later.
<leo> see ya and thanks
<obra> allison: it might be interesting to have that for both Artistic 1 and Artistic 2.
<obra> Even if they're identical ;)
<leo> APL - Artistice Perl License?
<allison> heh :)
<leo> s/e// even
* chip would like to see licensing restrictions translated to APL.  Somebody once took the "Principles of Operation for the System/360" and translated it into APL.  It was remarkable for being even harder to understand than the original document.
<chip> well, we're at the 95 minute mark, maybe we should wander off...?
* pmichaud wanders off
<leo> but at the same level as lawyer speak I presume
% pmichaud has left #parrotsketch
<allison> catch ya'll next week
% allison has left #parrotsketch
<chip> cya all
% Nicholas has left #parrotsketch
% chromatic has left #parrotsketch
% Coke has left Coke!~wcoleda@host-69-95-19-3.roc.choiceone.net
% audreyt has joined #parrotsketch
% audreyt has left #parrotsketch
% particle_ has joined #parrotsketch
% particle has left particle!~particle@144.81.84.170