% rafl has left rafl!~rafl@armitage.dreker.org
% rafl has joined #parrotsketch
% particle_ has joined #parrotsketch
% particle has left particle!~particle@144.81.84.209
% particle has joined #parrotsketch
% particle_ has left particle_!~particle@144.81.84.209
% ptc has left ptc!~cochrane@130.75.117.210
% particle has left particle!~particle@144.81.84.209
% particle has joined #parrotsketch
% particle_ has joined #parrotsketch
% particle has left particle!~particle@144.81.84.209
% particle_ has left particle_!~particle@c-24-19-12-148.hsd1.wa.comcast.net
<spinclad> well, i've convinced myself i should go ahead.  This is the log of the #parrotsketch meeting of November 7 (times are in GMT-0500):
<spinclad> 13:02:04 < obra> hi gang
<spinclad> 13:02:04 < obra> hi gang
<spinclad> 13:02:04 < obra> hi gang
<spinclad> 13:02:04 < obra> hi gang
<spinclad> 13:02:13 < allison> hi obra
<spinclad> 13:02:21 < leo_> hi obra 
<spinclad> 13:02:32 < chromatic> Hello.
<spinclad> 13:03:57 < obra> how are folks?
<spinclad> 13:04:21  * leo_ is hungry - came just home ;)
<spinclad> 13:04:46 < obra> go grab a snack. I'll let you go last ;)
<spinclad> 13:05:25 < leo_> na - I'll "cook" something
<spinclad> 13:05:34 < obra> we're birdless today. so I'll repost logs later.
<spinclad> 13:05:46 < chip> <cheep/>
<spinclad> 13:05:54 < leo_> hi cheep
<spinclad> 13:07:23 < particle> hey all
<spinclad> 13:07:25 < obra> so. chip.
<spinclad> 13:07:29 < obra> what's new and exciting?
<spinclad> 13:07:56 < particle> btw i have patrick's report as well as mine
<spinclad> 13:08:04 < chip> hi
<spinclad> 13:08:36 < chip> Done: No change, unfortunately.
<spinclad> 13:08:56 < chip> Coming before the hackathon: Release.
<spinclad> 13:09:31 < chip> ^D # *sigh*
<spinclad> 13:10:00 < obra> What are you hoping to hack on at the hackathon?
<spinclad> 13:10:14 < chip> HLL-specific class names tops the list
<spinclad> 13:10:54 < obra> Cool
<spinclad> 13:11:06 < chip> that's th eonly thing off the top of my head.  My TODO lists are a bottomles swell of ideas, of course
<spinclad> 13:11:10 < obra> *nod*
<spinclad> 13:11:22  * tewk suggests variable sized PMCS and a rewrite of ParrotObjects.
<spinclad> 13:11:38  * obra points to allison as next.
<spinclad> 13:11:49 < allison> I'm at the Ubuntu Developer Summit again today. I don't know what they're smoking, but I want some. :) (Some c
<spinclad> ool ideas for automatic mirror selection in their CPAN equivalent, BTW.)
<spinclad> 13:11:52 -!- ptc [~cochrane@130.75.117.210] has joined #parrotsketch
<spinclad> 13:12:11 < allison> I'm nearly through reviewing the Bytecode PDD and will move it out of clip later today. Let me know of any out
<spinclad> standing questions when we get to questions. (I have one.)
<spinclad> 13:12:59 < allison> I've tasked particle with some delegated design work for the hackathon.
<spinclad> 13:13:05 -!- pmichaud [pmichaud@feather.perl6.nl] has joined #parrotsketch
<spinclad> 13:13:17 < allison> Which he may talk about.
<spinclad> 13:13:20 < allison> EOR
<spinclad> 13:14:22 < obra> particle: what'cha up to?
<spinclad> 13:14:35 < particle> ~ i'm happy to report paul got his commit bit, and has been cleaning up code ever since :) ptc++
<spinclad> 13:14:44 < particle> ~ lots of discussion this week with core committers and design team, on topics including pmc design, oo, and 
<spinclad> io
<spinclad> 13:14:53 < particle> ~ i have a concrete list of goals for chicago hackathon, including: 
<spinclad> 13:14:53 < particle>  ~ list of problems and proposed solutions for pmcs (from allison) 
<spinclad> 13:14:53 < particle>  ~ discuss and write spec for IPC::Run-like control of parrot interp (from allison) 
<spinclad> 13:14:53 < particle>  ~ review pcc argument processing 
<spinclad> 13:14:53 < particle>  ~ debug Parrot::Embed on win32 with chromatic 
<spinclad> 13:14:53 < particle>  ~ finalize design of smartlinks object model 
<spinclad> 13:15:03 < particle> ~ haven't gotten the time to classify test failures yet, this is getting annoying -- i'd really like to reset my ENOTIME flag 
<spinclad> 13:15:13 < particle> ~ speaking of release prep, i entered some tickets in rt hoping somebody would grab them and help out with simple tasks like NEWS and CREDITS updates 
<spinclad> 13:15:20 < particle> ~ the usual bugfixes and code cleanups
<spinclad> 13:15:22 < particle> .end
<spinclad> 13:15:37 < obra> pmichaud: how goes prep for the texas branch of the hackathon?
<spinclad> 13:15:59 < pmichaud> it goes fine, although some Parrot core features are starting to slow me up a bit
<spinclad> 13:16:02 < pmichaud> report:
<spinclad> 13:16:10 < pmichaud> * Added <-alpha>, <alnum-[0]>, <alpha+digit-[J0]> etc. regexes to PGE.
<spinclad> 13:16:10 < pmichaud> * Updated the tcl grammar for changes in enumerated character class syntax
<spinclad> 13:16:10 < pmichaud>   (spaces in <[...]> must now be escaped).
<spinclad> 13:16:10 < pmichaud> * Fixed many cases in perl6 and APL where hashes now return NULL 
<spinclad> 13:16:10 < pmichaud>   instead of None.
<spinclad> 13:16:13 < pmichaud> * Helped debug c89/const conflicts in Tcl.
<spinclad> 13:16:15 < pmichaud> * Added a capture PMC to the core.
<spinclad> 13:16:18 < pmichaud> ** Capture exposes a lot of issues with Parrot objects and inheritance.
<spinclad> 13:16:20 < pmichaud> * Worked on new implementation of PAST
<spinclad> 13:16:23 < pmichaud> ** I think PAST nodes really should be based on Captures, but the
<spinclad> 13:16:25 < pmichaud>    PMC/object issues above are a bit of a block for that.
<spinclad> 13:16:28 < pmichaud> ** I'm planning to implement Capture in PIR (instead of a PMC) in
<spinclad> 13:16:30 < pmichaud>    order to keep from blocking on this for now.
<spinclad> 13:16:33 < pmichaud> * Still awaiting resolution on HLL classnames and namespaces.
<spinclad> 13:16:35 < pmichaud> * Long discussion yesterday with particle and tewk about implementing
<spinclad> 13:16:38 < pmichaud>   CodeString in C (potentially significant performance gain there) and 
<spinclad> 13:16:40 < pmichaud>   handling slurpy/named parameters in PMC methods.
<spinclad> 13:16:43 < pmichaud> * Worked on switching perl6 to use new :init pragma (tewk++),
<spinclad> 13:16:45 < pmichaud>   as of 16:38 UTC :init wasn't working for subs in .pbc files.
<spinclad> 13:16:48 < pmichaud> * Worked on switching PGE to use new :vtable pragma (jonathan++),
<spinclad> 13:16:50 < pmichaud>   but it also doesn't work for .pbc files.  Example to be posted
<spinclad> 13:16:53 < pmichaud>   to RT #40626.
<spinclad> 13:16:55 < pmichaud> * Plan for this week: new PAST, adapt perl6 to new PAST implementation,
<spinclad> 13:16:58 < pmichaud>   have notes and tasks for hackathon attendees this weekend.
<spinclad> 13:17:00 < pmichaud> EOR
<spinclad> 13:18:45 < obra> chromatic: you're up
<spinclad> 13:18:55 < chromatic> I'm writing notes on various concurrency models right now.
<spinclad> 13:19:05 < chromatic> I made a list of three hackathon goals and sent that to various people.
<spinclad> 13:19:30 < chromatic> I agree with the "Wow, the object model just isn't quite there" comments; I have various tickets about that, especially with regard to PBC.
<spinclad> 13:19:33 < chromatic> That's all.
<spinclad> 13:20:44 < obra> mdiep: you around?
<spinclad> 13:21:01 < obra>  
<spinclad> 13:22:11 < obra> leo_: ?
<spinclad> 13:22:14 < leo_> * tried to fix inerhitance problem, when a PMC is subclassed
<spinclad> 13:22:15 < leo_> - managed to cure just one level, the default implementation hurts badly
<spinclad> 13:22:15 < leo_> - removing the default redirection is probably the way to go (e.g. get_integer_keyed_int => get_integer_keyed)
<spinclad> 13:22:18 < leo_> ^D
<spinclad> 13:24:02 -!- obra is now known as jonathan_
<spinclad> 13:24:05 < jonathan_> I'm on my way to the Chicago Hackathon via Cambridge to see friends from my uni days, so can't make the meeting.
<spinclad> 13:24:25 < leo_> *g*
<spinclad> 13:24:27 < jonathan_> * Frustrating week of not really solving anything despite plenty of time trying to.
<spinclad> 13:24:30 < jonathan_> * Attempted a fix to the PMC subclass problem. Learned plenty about how subclassing of PMCs works. Concluded that it sucks. Leo stuck in a workaround, but we need a real solution. Hope the objects PDD will give that.
<spinclad> 13:24:34 < jonathan_> * Added an experimental op to run an invokable in another interpreter, to help particle with porting tests to PIR (it'd be nice to run the tests in a clean interpreter). Kinda works, but not completely. And not sure why exactly, yet.
<spinclad> 13:24:39 < jonathan_> * Poked Allison for approval to work on bytecode PDD implementation at the Hackathon, if that's what appears to be the right thing to work on when I'm there. But, I'll work on whatever's useful.
<spinclad> 13:24:43 < jonathan_> EOR
<spinclad> 13:24:44 < jonathan_> (jonathan mailed me his report)
<spinclad> 13:24:46 -!- jonathan_ is now known as obra
<spinclad> 13:24:52 < obra> who'd I miss?
<spinclad> 13:25:00  * tewk 
<spinclad> 13:25:22 < obra> hey tewk. sorry :) 
<spinclad> 13:25:23 < obra> how are things?
<spinclad> 13:25:31 < tewk> Checked in working :init code.
<spinclad> 13:25:31 < tewk> Checked in broken CodeString PMC.  I have a patch which makes PGE::CodeString, a PIR class, inherit from CodeString PMC which inherits from String PMC.
<spinclad> 13:25:35 < tewk> The STRING* of String PMC doesn't seem to be getting initialized and core dumps when the CodeString PMC's emit function is call.
<spinclad> 13:25:38 < tewk> I'm looking into it.
<spinclad> 13:25:40 < tewk> Cardinal needs attributes that can be added to class after objects have been instanciated.  ( Hash based storage of attributes ).
<spinclad> 13:25:43 < tewk> Does support for that exist anywhere or should I just code up my own RubyClass and RubyObject.
<spinclad> 13:26:10 < tewk> I'm trying to get smokes running for Test::TAP::Model::VERSION > 0.50
<spinclad> 13:27:00 < tewk> Looking forward to helping to get objects working.
<spinclad> 13:27:02 < tewk> EOR
<spinclad> 13:27:19 < obra> ok. question time.
<spinclad> 13:27:26 < obra> I think allison is first
<spinclad> 13:27:30 -!- coke [~coke@cpe-72-228-52-192.nycap.res.rr.com] has joined #parrotsketch
<spinclad> 13:27:38 < obra> or first. actually.
<spinclad> 13:27:42 < obra> coke! how are things?
<spinclad> 13:28:12 < coke> er...
<spinclad> 13:28:18  * particle has a comment and two questions
<spinclad> 13:28:23 < coke> busy. nothing else to report. =-)
<spinclad> 13:28:37 < obra> okie
<spinclad> 13:28:46  * chromatic idly wonders if the lack of super() hurts CodeString.
<spinclad> 13:28:52 < obra> allison: your question. then particle. then chromatic
<spinclad> 13:29:01  * mdiep arrives, belatedly
<spinclad> 13:29:25 < allison> Bytecode PDD question: What version number is this new version of Parrot bytecode? Scan through PBC_COMPAT and increment to a number that roughly matches the criteria in the PDD?
<spinclad> 13:30:04 < allison> We've never kept bytecode version numbers before.
<spinclad> 13:30:44 < particle> why not make it the version number of parrot at time of release?
<spinclad> 13:30:48 < allison> But I think it's the right way to go, to allow for external bytecode interepreters (e.g. embedded in a cell phone, etc.)
<spinclad> 13:31:18 < allison> I was typing the answer as you typed the question.
<spinclad> 13:31:38 < allison> Not every bytecode interpreter will be part of Parrot.
<spinclad> 13:31:44 < chip> Debian kernels ahve an interesting approach
<spinclad> 13:32:00 < leo_> we now have the parrot (major,minor) in the pbc, but that doesn't cover changes of PBC_COMPAT - i.e. all such changes shall change the PBC version
<spinclad> 13:32:12 < allison> It also gives us a way of marking major and minor changes to the bytecode format. (Which don't happen on the same cycle as the major and minor changes of Parrot)
<spinclad> 13:32:18 < chip> They version their kernel module packages with the kernel version that breaks binary compatibility with previous versions
<spinclad> 13:32:19 < particle> allison: i understand, but the builtin could match parrot. that is, unless we offer multiple bytecode interpreters in core
<spinclad> 13:32:45 < allison> particle, that is one possibility
<spinclad> 13:33:28 < allison> we do guarantee that after the 1.0 release we will always provide a way to read older versions.
<spinclad> 13:33:35 < leo_> and of course: are we speaking of past 1.0 parrot or for todays .pbc compat?
<spinclad> 13:34:24 < allison> from 1.0 onward
<spinclad> 13:34:57 < allison> hence the question of whether we should retroactively number them
<spinclad> 13:35:33 < allison> I'm in favor of it for historical sanity
<spinclad> 13:35:54 < particle> me too. versioning is *important*
<spinclad> 13:36:20 < allison> Can I read the quiet as a resounding "don't care", in which case we'll go with retroactive numbering.
<spinclad> 13:36:30 < chromatic> Retroactively number bytecode versions for all of the people who haven't targeted Parrot yet?
<spinclad> 13:36:33 < chromatic> Is that really a problem?
<spinclad> 13:37:00 < tewk> So the bytecode PDD should support something like rails's db schema migrations except bytecode migrations?
<spinclad> 13:37:20 < tewk> POST 1.0 that is.
<spinclad> 13:37:51 < allison> The question is really: we've just added separate bytecode numbering, do we call the new version 0.1, or do we call it 42.5, or whatever the version would be going by the current numbering scheme?
<spinclad> 13:38:12 < chromatic> Ah.  Sign me up for "don't care" then.
<spinclad> 13:38:45 < allison> tewk: yes, that's the idea
<spinclad> 13:38:53 < obra> Sounds like the architect needs to just make a call ;)
<spinclad> 13:39:03 < allison> done
<spinclad> 13:39:24 < allison> I have 2 comments, but can wait til after questions
<spinclad> 13:39:31 < obra> ok. particle?
<spinclad> 13:39:47 < particle> i'll be happy to give the floor to mdiep if he has a report
<spinclad> 13:39:55 < obra> okie
<spinclad> 13:40:03 < mdiep> * talked PMCs with jonathan, pmichaud, and particle on IRC
<spinclad> 13:40:04 < mdiep> * trying to figure out how variables work in Forth and how to implement them
<spinclad> 13:40:04 < mdiep> * really busy with school until this weekend at the hackathon
<spinclad> 13:40:11 < mdiep> ^D
<spinclad> 13:40:19 < obra> back to particle
<spinclad> 13:40:52 < particle> i forgot to say i've been planning a parrot intro at the hackathon. ENOTIME still applies.
<spinclad> 13:41:07 < particle> leo: will you be available during the weekend? it'd be nice to have you online
<spinclad> 13:41:21 < leo_> yep, I'll be on IRC
<spinclad> 13:41:26 < particle> fantastic
<spinclad> 13:41:30 < particle> pmichaud: are you still targeting perl6-only for the initial PAST impl?
<spinclad> 13:42:06 < pmichaud> particle: no.  I'm writing a past impl within the perl6/ tree, but I'm thinking that other languages could start porting to it very soon
<spinclad> 13:42:16 < particle> ok, great!
<spinclad> 13:42:27 < pmichaud> i.e., the past is going to be in languages/perl6/past/ to begin with, but will eventually move to compilers/past/ once we have the dependencies worked out
<spinclad> 13:42:55 < pmichaud> but it will be mostly a standalone library, so that a compiler can just do   load_bytecode 'PAST.pbc'   and everything is loaded
<spinclad> 13:43:04 < pmichaud> although it may be part of a more generic   load_bytecode 'Compiler.pbc'
<spinclad> 13:43:51 < particle> oh, i've been thinking about a seperate svn repo for the hackathon, so we can get an integration environment. then core committers can sync with the parrot repo after review. sound good?
<spinclad> 13:43:51 < pmichaud> EOA
<spinclad> 13:44:18 < pmichaud> I don't understand the need for a separate svn repo
<spinclad> 13:44:26 < particle> this will allow newbies to commit and share amongst each other during the hackathon
<spinclad> 13:44:32 < pmichaud> ohhhh
<spinclad> 13:44:33 < particle> (along with us)
<spinclad> 13:44:41 < chromatic> Bidirectional sync may be tricky.
<spinclad> 13:44:47 < allison> we might as well get them used to creating and applying patches, no?
<spinclad> 13:44:58 < obra> having a place that everyone at the hackathon can commit to will greatly speed up activity _at_ the hackathon.
<spinclad> 13:45:03 < particle> will they get commit bits in situ?
<spinclad> 13:45:34 < particle> chromatic, i'm okay with one-way sync against a parrot branch, i think
<spinclad> 13:45:34 < allison> how about just making it a branch?
<spinclad> 13:45:48 < allison> we can give separate commit permissions on branches
<spinclad> 13:45:56 < obra> whether or not it's syncced directly back to the master repository is up to chip+allison. but having one available there for everyone in attendance to commit to is a huge boon to devlopment
<spinclad> 13:45:57 < particle> fabulous.
<spinclad> 13:46:03 < coke> branch++
<spinclad> 13:46:24 < pmichaud> I agree, the branch idea works best
<spinclad> 13:46:35 < pmichaud> make it easy for us off-site hackathoners to stay synced
<spinclad> 13:46:39 < particle> ok, great. we'll do the branch post-release (or pre-hackathon, whichever comes first)
<spinclad> 13:47:41 < leo_> just a comment:
<spinclad> 13:47:42 < leo_> tewk: The Plan for Perl6 is: add another "internal" attribute slot, which isa Hash, and stuff runtime attrs there.
<spinclad> 13:47:45 < leo_> This would be done in subclasses of Parrot{Class,Object}, which deal with {get,set}attribute.
<spinclad> 13:47:58 < obra> (I think chromatic is up next)
<spinclad> 13:48:01 < coke> I might almost suggest having a pugs-style branch that's a free for all.
<spinclad> 13:48:26 < chromatic> Would fixing super() fix the problems in the CompileString PMC?
<spinclad> 13:48:55 < allison> ah, this brings me to my comment
<spinclad> 13:49:10 < allison> May I interject?
<spinclad> 13:49:22 < chromatic> That's a separate question.  obra?
<spinclad> 13:49:33 < obra> sure
<spinclad> 13:49:40 < allison> So, the biggest thing I asked particle to do at the hackathon is get people together for a 1 hour discussion on objects. Collect the biggest problems, and the top proposed solutions. Keep the meeting short, this is a fast iteration. It will help keep things short and to the point if everyone who knows of object issues makes a quick list ahead of time.
<spinclad> 13:49:56 < allison> This looks like a question for the hackathon discussion.
<spinclad> 13:50:08 < allison> proceed, chromatic
<spinclad> 13:50:12 < chromatic> Fun related question: Perl 5 objects.  Ouch.
<spinclad> 13:50:49 < chromatic> Should I list their requirements in the Objects PDD clip?
<spinclad> 13:50:59 < allison> sounds good, go for it
<spinclad> 13:51:56 < obra> what's next?
<spinclad> 13:52:03 < tewk> pugs style branch ++
<spinclad> 13:52:18 < pmichaud> when is the objects discussion likely to take place?
<spinclad> 13:52:34 < chromatic> Saturday, 10 am, cage-match style!
<spinclad> 13:52:40 < particle> it'd be great to schedule it when everyone's available
<spinclad> 13:52:52 < particle> i'll make sure it happens that way
<spinclad> 13:53:18 < particle> or, i'll have seperate conversations with those who can't make it
<spinclad> 13:53:21 < pmichaud> I'm unavailable Saturday 9:30am - 8:30pm
<spinclad> 13:53:33 < obra> (same timezone?)
<spinclad> 13:53:34 < particle> you'll all get the doc to review, also
<spinclad> 13:53:40 < pmichaud> however, I'll have my observations typed up for you before then
<spinclad> 13:53:43 < pmichaud> I have a lot of them
<spinclad> 13:53:50 < leo_> hackathon is at which TZ?
<spinclad> 13:53:52 < particle> pmichaud++ # perfect
<spinclad> 13:53:53 < obra>  
<spinclad> 13:53:53 < allison> pmichaud: excellent :)
<spinclad> 13:54:05  * pmichaud is CST, same as Chicago
<spinclad> 13:54:10 < leo_> k
<spinclad> 13:54:13 < particle> leo CST = GMT - 6
<spinclad> 13:55:10 < allison> One final comment: There are a few TODOs left in the Bytecode PDD, that need to be cleared up (filled in and/or deleted). This is a good hackathon task (* allison looks at particle for list keeping).
<spinclad> 13:55:30  * particle updates his hiveminder todo
<spinclad> 13:55:49 < pmichaud> I have a comment/question also
<spinclad> 13:56:06 < obra>   go ahead
<spinclad> 13:56:45 < pmichaud> during the week particle pointed out that obra's status matrix was to be commented upon by all of us -- i.e., to have several people independently check each box of the matrix (even those that have already been checked).  Is that still the case?
<spinclad> 13:56:53 < pmichaud> and I think we need an x86_64 row in the matrix
<spinclad> 13:57:02 < obra> pmichaud: it's still the case.
<spinclad> 13:57:06 < obra> I'm still collecting
<spinclad> 13:57:22 < pmichaud> okay, I hadn't realized that we would have multiple checks for each box
<spinclad> 13:57:34 < obra> Is x86_64 one of [BWhere's the canonical list of 1.0 target platforms?
<spinclad> 13:57:53 < leo_> sure - I'm using it ;)
<spinclad> 13:58:10 < obra> part of the point is to make sure that we don't get into the situation of one person saying something is done without any sort of cross-check
<spinclad> 13:58:13 < particle> hrmm, could we say smoke.parrotcode.org/smoke contains canonical list?
<spinclad> 13:58:33  * obra points to allison and chip
<spinclad> 13:59:03 < allison> of platforms we are currently targeting, or platforms we plan to target?
<spinclad> 13:59:03 < pmichaud> given that we've had enough errors pop up that are unique to x86_64, and that it's becoming a more popular platform, I think it deserves special mention
<spinclad> 13:59:20 < obra> platforms that 1.0 should work on
<spinclad> 13:59:30 < pmichaud> for much of the early part of this year I would run into errors on x86_64 that nobody else would encounter
<spinclad> 14:00:07 < allison> er, I'd say it should work on quite a few more than are currently listed in smoke.parrotcode.org/smoke
<spinclad> 14:00:16 < particle> yes, indeed.
<spinclad> 14:00:23 < pmichaud> allison:  I think we need an updated list then :-)
<spinclad> 14:00:40 < allison> Pull it from Perl 5
<spinclad> 14:00:41 < obra> I want a list staked in the ground.
<spinclad> 14:00:49 < obra> allison: do you want to run on Dynix and Eunice?
<spinclad> 14:00:51 < allison> we can then decide if some should be knocked off
<spinclad> 14:00:52 < particle> there's been mention of working with the PITA folks to smoke parrot, but nothing's happened there yet.
<spinclad> 14:01:47 < leo_> $ cat PLATFORMS # in parrot repo is stripped down to recent reports
<spinclad> 14:01:48 < allison> obra: I'm okay with knocking Dynix and Eunice off (but we should give users a chance to object, if any are still living :)
<spinclad> 14:01:49 < obra> pmichaud: I'm happy to ammend the matrix, though if we get to more than 6-7 platforms, I think that the test matrix needs to get broken out
<spinclad> 14:02:21 < particle> i think the matrix should stick (now) to dev platforms, which number ~5
<spinclad> 14:02:33 < allison> chromatic: I've seen him, but haven't talked to him
<spinclad> 14:02:44 < particle> the list can grow as platform support extends
<spinclad> 14:02:54 < obra> allison: can you canonize "parrot 1.0 should run everywhere perl5 does, modulo specific removals" into spec?
<spinclad> 14:03:05 < allison> particle: yes, that's fine, we can add others later
<spinclad> 14:03:12 < chromatic> "No porters for the platform, no porting to that platform."
<spinclad> 14:03:20 < allison> obra: it's not in there yet? I'll look.
<spinclad> 14:03:32 < allison> It's certainly been the goal from the beginning.
<spinclad> 14:03:35 < particle> try the overview pdd, or maybe readme.
<spinclad> 14:03:41 < allison> ok
<spinclad> 14:03:43 < obra> I'd been led to believe that Parrot 1.0 had a much more limited target than "everywhere perl5 runs"
<spinclad> 14:03:52 < allison> by whom?
<spinclad> 14:03:59 < allison> nevermind :)
<spinclad> 14:04:04 < particle> how about "everywhere perl 6 runs" :)
<spinclad> 14:04:07 < obra> It was before your tenure ;)
<spinclad> 14:04:17 < obra> particle: cool! haskell backend!
<spinclad> 14:04:29 < allison> particle: isn't that a bit of a self-referential list?
<spinclad> 14:04:32 < particle> parrot on javascript
<spinclad> 14:04:39 < particle> yes, that's the idea.
<spinclad> 14:04:42 < allison> lol :)
<spinclad> 14:04:59 < obra> ok. what else?
<spinclad> 14:05:37 < allison> and chromatic: yes, we will be limited by where we can beg/borrow/steal porters
<spinclad> 14:05:55 < chromatic> I prefer a preemptive threat.
<spinclad> 14:06:07 < obra> allison: if we can't get a porter for a given platform, does that remove it from the 1.0 list or delay 1.0?
<spinclad> 14:06:08 < allison> may go 1.0 with fewer, and rely on release enthusiasm for porting boost
<spinclad> 14:06:09 < particle> speaking of which... are we ready to beg/borrow/steal porters from p5p or anywhere else?
<spinclad> 14:06:10 < chromatic> "If you care about your platform, you'd better run a smoke once in a while."
<spinclad> 14:06:41 < obra> And if so, what is the minimal list that we CAN NOT ship 1.0 without?
<spinclad> 14:06:52 < allison> particle: anytime, but may need more done before they get enthusiastic
<spinclad> 14:07:21 < chromatic> Minimal list: at least one more platform than GHC 6.6.
<spinclad> 14:08:01 < allison> obra: versions of Linux, Windows, and MacOSX released within the past 2 years
<spinclad> 14:08:14 < allison> absolute requirement
<spinclad> 14:08:25 < obra> cool.
<spinclad> 14:08:35 < obra> That's what I'm looking for.
<spinclad> 14:08:37 < allison> (which includes testing multiple distros of linux, etc)
<spinclad> 14:08:47 < coke> *bsd?
<spinclad> 14:08:53 < allison> yes
<spinclad> 14:08:57 < particle> solaris? aix?
<spinclad> 14:09:00 < allison> and solaris
<spinclad> 14:09:10 < obra> 2 years before now or 2 years before 1.0?
<spinclad> 14:09:11 < allison> don't care about aix, but if someone does we add it :)
<spinclad> 14:09:18 < allison> before 1.0
<spinclad> 14:09:19 < obra> (if the latter, it means we could, in fact be only x86 porta.ble..ok)
<spinclad> 14:09:20 < pmichaud> so, essentially pc-based and mac-based platforms
<spinclad> 14:09:36 < allison> that's the core list
<spinclad> 14:09:37 < obra> allison: ok. now that's the list I want canonized. ;)
<spinclad> 14:09:43 < chromatic> Throw in a BE platform there too, just for giggles.
<spinclad> 14:09:50 < allison> but if we ship with only that, it'll be pretty pathetic :)
<spinclad> 14:10:06 < obra> allison: sure. But there's release goal and there's showstopper.
<spinclad> 14:10:10 < allison> yup
<spinclad> 14:10:15 < chromatic> Alternately, get it into Debian and let their porters struggle for a bit.
<spinclad> 14:10:34 < obra> I'd at least rather have a good parrot on those platforms than hold up the release 9 months to add System34 ;)
<spinclad> 14:10:38 < particle> well, we're debian already
<spinclad> 14:10:41 < allison> the others are nice to have, desirable, but we'll take whatever porters we can get
<spinclad> 14:10:46 < allison> obra: agreed
<spinclad> 14:10:48 < obra> allison++
<spinclad> 14:11:16 < leo_> rafl (debian porter of parrot) has some funny error report BTW on e.g. ia64
<spinclad> 14:11:21 < pmichaud> I think that as we get nearer to 1.0 release we'll have more interest and porters
<spinclad> 14:11:40  * particle looks forward to release 0.5
<spinclad> 14:11:43 < allison> pmichaud: exactly
<spinclad> 14:11:51 < particle> *halfway there* :)
<spinclad> 14:12:35 < rafl> leo_: And I'm not able to debug it because of a gdb bug.
<spinclad> 14:12:46 < leo_> indeed
<spinclad> 14:13:20 < obra> ok. what's next?
<spinclad> 14:13:42 < pmichaud> EOQ
<spinclad> 14:13:56 < obra> have a great hackathon, everybody!
<spinclad> 14:14:05 < pmichaud> yes, looking forward to the hackathon
<spinclad> 14:14:17 < obra> when tweety is back, I'll replay the logs
<spinclad> 14:14:39 < pmichaud> please do, I missed the first part of #parrotsketch
<spinclad> 14:15:48 < allison> thanks jesse!
<spinclad> 14:17:17 < leo_> thanks obra 
<spinclad> </REPLAY>
<spinclad> (sorry for the stutter at the start)
<obra> spinclad: thanks