% particle_ is now known as particle
% particle has left particle!~particle@144.81.84.133
% particle has joined #parrotsketch
<obra> Parrot sketch in an hour and 10 minutes
<obra> T - 6 minutes
% Coke has left Coke!~coke@cpe-72-228-52-192.nycap.res.rr.com
% coke has joined #parrotsketch
% coke is now known as Coke
% allison has joined #parrotsketch
% mdiep has joined #parrotsketch
% pmichaud has joined #parrotsketch
% jane has joined #parrotsketch
<particle> hi all
<obra> hi particle
% chromatic has joined #parrotsketch
<allison> hi jerry
<mdiep> hello
<obra> roll call. Who's actually around?
<Coke> pong
<obra> leo_, tewk, you here?
<chromatic> I'm here.
% davidfetter has joined #parrotsketch
<obra> Let's start with reports, then I'd like to talk for a bit about release engineering.
<obra> particle, allison, pmichaud, mdiep, cooke, chromatic 
<particle> happy new year all.
<particle> ~ our test coverage stinks. i'm working on it, but i'd like to do it in pir
<particle> ~ started process of converting test files to pir. it's a long journey which will not be completed without some additional parrot infrastructure (as previously discussed.) in the meantime, i'll do what i can
<particle> ~ added a number of tests for non-branching comparison opcodes
<particle> ~ there seems to be a platform-specific bug with heredocs and crlf... need to investigate further (i'll start by committing a test file exposing the bug)
<particle> ~ some c code cleanup to get t/codingstd/c_parens.t to pass. this file is still failing due to both some unfinished cleanup and also problems with the tests. i'd like pmichaud's time to help with regex magic.
<particle> ~ applied a makefile fix to improve msvc build output (ron blaschke)++
<particle> .end
* allison has a question for particle later
<allison> - I finished off the port of Punie to PAST-pm. All non-TODO tests are now passing, and it's ready to start up new development.
<allison> - I did a good bit of reading on async I/O and concurrency (sent a few links to the list).
<allison> - This led to one mental breakthrough, the idea of a central concurrency scheduler that handles all the different concurrency models through an abstraction interface.
<allison> - It also lead to me plugging in the last bit of the I/O PDD, so I'm moving it out of clip, ready for a final round of comments.
<allison> EOR
% bernhard has joined #parrotsketch
<allison> is pmichaud here?
<particle> pmichaud mentioned that he *may* not make it
<obra> he joined rought around when you did
<mdiep> he was on #parrot before we started
<pmichaud> I'm here
<pmichaud> sorry -- I'm in constant interruption mode
<pmichaud> (kids want lunch)
<obra> shoudl we skip you for now?
<pmichaud> I can give a quick report, which is that kids+holidays have prevented me from doing much on parrot.  They go back to school tomorrow
<pmichaud> I should be back on parrot again on thursday
<pmichaud> EOR
<mdiep> Parrot:
<mdiep>  * Added PASM socket constants
<mdiep>  * Added TCPStream to repo
<mdiep>  * Pending Patches:
<mdiep>    - Return port number from bind
<mdiep>    - RT#41128: Fix #41122: ParrotObjects don't call init_pmc
<mdiep> Tcl:
<mdiep>  * Made the tcl tests runnable from anywhere in the parrot tree
<mdiep>  * Added a simple event loop
<mdiep>  * Got an IRC bot working (jane in this room)
<mdiep>  * Fixed several namespace bugs
<mdiep>  * Added support for {expand} syntax
<mdiep> And now for a demo....
<mdiep> expr 4*sin(1)
<jane> mdiep: 3.365883939231586
<mdiep> :-)
<mdiep> ^D
<pmichaud> mdiep++    
<davidfetter> w00t
<obra> mdiep++ #showoff
<Coke> [tcl]
<Coke> - rework on test_more harness to simplify maintenance, led to:
<Coke> - fixing a number of small bugs that were caused by parrot exiting instead of throwing a catchable exception. 
<Coke> - added support for {*} - trivial after mdiep's {expand}. (same thing,
<pmichaud> (could this bot also do perl6 evals?)
<Coke>   new name - we're on the bleeding edge of tcl here. =-)
<Coke> getting very close to 17% of tcl's test suite (some new features, new
<Coke> syntax (yes, tcl has syntax now. :|), some improvements to our harness).
<Coke> exit;
<mdiep> pmichaud: with a small amount of work, yes.
<chromatic> - did some implementation/testing work on namespaces
<chromatic> - fiddled with HLLCompiler for Punie, but couldn't get it to go
<chromatic> - argued with Allison over events and release engineering
<chromatic> - think there may be a solution for Parrot::Embed on in-tree builds
<chromatic> that's it
<allison> s/Punie/Pheme/?
<chromatic> Yes, that one.
<obra> Ok. So a topic near and dear to everbody. Parrot releases. 
<chromatic> releases++
<obra> Chip is somewhat MIA, though I have reports that he's happy and healthy.
<obra> Allison had a proposal for starting to split up some of the release engineering duties to make it easier to get regular releases out.
<obra> (And tying those releases at least somewhat to the results of regular hackathons/bugathons)
<obra> at the same time, I'd prodded particle to start poking at what we'd need to do for a next release candidate.
<obra> ...it sounds like lots of folks were sort of pondering the same thing at the same time, which is generally a good sign.
<obra> allison: are you up for describing your plan?
<obra> or "idea" if I'm jumping the gun by calling it a "plan"
<allison> the general idea is "don't put all your eggs in one basket"
<allison> so, get several people up to speed on making releases
<pmichaud> do we know what it takes to do a release?
<allison> and do releases in a round-robin fashion, so no one person gets burned out
<pmichaud> (I don't)
<particle> heh. so far, we have two people. neither of which has time for parrot lately :/
<allison> chip has supplied some good documentation
<particle> pmichaud: yes, see RELEASE_INSTRUCTIONS
<pmichaud> I will gladly do some releases; since I'm wanting to tie perl6 releases to parrot releases it makes sense for me to do at least some of them
<allison> and, to get started we'll pull in Leo, and Chip if possible to make sure the new release managers know what to do
<chromatic> (and being able to deprecate features and replace them with PDD-compliant features in a timely fashion).
<allison> pmichaud: good, you were on my list
<Coke> I happy to do one in a while.
<Coke> I also english well.
<particle> i'll join @pumpkings
<allison> :)
<allison> excellent
<mdiep> me too
<pmichaud> if particle/mdiep/coke can also do a few once in a while, I think we have it covered
<obra> ok. so. patrick, you do mondays, coke, tuesdays, particle, wednesday, allison thursday, chromatic friday.
<obra> weekends, the tree can be unfrozen for hacking
* obra waits to get smacked
<allison> heh :)
* particle picks up a brick
<Coke> being Pm is punishment enough.
<pmichaud> wait, if I have monday, that means I have all of the hard work!!!! :-)
<obra> Coke: that's not nice to patrick ;)
<Coke> er, PM
<chromatic> He'll have to start checking in TODO tests then, not just failing ones.
<obra> ok. so. the real question is "who's first?"  I'm tempted to nominate particle, if he's up for it.
<allison> agreed
<pmichaud> I definitely will take the second spot
<particle> i'll take it, but being non-linux i'll need some help
<pmichaud> particle -- would having a linux account help?
<mdiep> that's what #parrot is for :-)
<allison> particle: that's one advantage of having multiple release managers
<particle> well, i have a feather account, but i hate putty
<obra> and we'll need a rough schedule.
<particle> let's say mid-month
<pmichaud> fwiw, I like the "monthly release" approach.  mid-month works good
<allison> I'd like to learn the process on the first release anyway, so I can work with you and do linux testing
<particle> that ought to be enough time to get tests passing
<particle> great. we'll meet in #parrot starting after this meeting
<pmichaud> please log it
<allison> ideally, we'll schedule the hackathons to immediately preceed the release freeze
<obra> ok. so targeting, say, 16 Jan?
<allison> s/hackathons/bugathons/
<pmichaud> are we doing a january bugathon?
<chromatic> We should.
<pmichaud> that sounds like a terrific idea.. bugathon, then release
<particle> yes. bug day, then release on 16th
<allison> let's say a lightweight bugathon Jan 13th?
<particle> btw before the bug day, please enter any outstanding bugs that haven't made it into rt yet
<pmichaud> I always rt bugs as soon as I find them :-)
<allison> eventually, we probably want about a week between bug squashing and release, but we're following right on another bug squashing session this time
<particle> end-of-day 'make smoke' reports from bug day will be of great help
<pmichaud> and it will be great to note the contributions from bugdays in the release announcements on the mailing lists
<allison> obra, did you pick a Tuesday intentionally to coincide with parrotsketch?
<obra> yes
<obra> and to give a day after the bugathon for smokes
<obra> but I don't actually care; if that's bad, say so
<obra> but it gives us a last minute discussion forum
<allison> nope, just looking ahead to future months and duplicating
<particle> let's set the precedent, then follow it :)
<chromatic> We need to get PAUSE permissions for all uploaders.
<particle> c: that was my next thought. chip can do this iirc, anyone else here who has that authority?
<obra> chromatic: I'll sort it for particle and pm for the moment. once they're on there, they can add more
<Coke> I have a PAUSE id. not sure if we need special perms re: parrot.
<obra> you will, but that's getting sorted. once we have more people who are comaints, they can fix it on pause
<obra> particle/patrick, what are your pause IDs?
<particle> particle
<pmichaud> pmichaud, I think
<allison> so, tentatively, Feb 20th (patrick), Mar 20th (mdiep), Apr 17th (allison), May 15th (chromatic), June 19th (coke)
<pmichaud> oh wait
<obra> yep.
<pmichaud> I don't think I have one
<obra> er. no.
<obra> http://search.cpan.org/~pmichaud/
<obra> is the OTHER pmichaud
<allison> standardizing on the 3rd Tuesday of the month
<pmichaud> I'll get a PAUSE id :-)
<obra> ok
* mdiep needs to get one too
<particle> 3rd tuesday is also my perl mongers meeting date
<Coke> I can go sooner if needs be.
<Coke> mittwoch is painful, but doable.
<particle> request a pause account: http://pause.perl.org/pause/query?ACTION=request_id
<allison> coke: I just randomly shuffled
<allison> anyone who has a conflict we can swap
<allison> anyone who needs more time to get pause id's set up we can swap
<obra> I've just sent off a request to ANDK to do sme permissions shuffling
<allison> anyone who has vacation scheduled we can swap
<allison> anyone who randomly wants to swap we can swap :)
<obra> allison: want to check that list of release dates into the repo?
<allison> yah, where?
<obra> say in a schedule inside the RELEASE_INSTRUCTIONS?
<pmichaud> (check in release dates)++
<particle> perhaps in a document we can put on the website
<allison> When we make the next release we can include the future release dates in the text blurb on the main page
<obra> ooh. commitment
<obra> ok. what's next? questions?
<Coke> anything that needs to be updated on a regular basis on the website, create a pod file, and I'll link to it from the website.
* particle has a question for pmichaud
<Coke> then you don't need the scarce resource of me or robrt.
* mdiep wants to know if anyone has any objects to his pending patches
<mdiep> err, s/objects/objections/
<pmichaud> mdiep:  no objections
<Coke> not if they don't break tcl! =-)
<allison> ticket #?
<mdiep> allison: 41128
<mdiep> the other doesn't have a ticket #, since it's not complete. but the idea is to return the port number from the bind opcode
<chromatic> Instead of a method to get the port number from the socket?
<particle> mdiep: if bind fails, return -1? throw exception?
<allison> looking  now (my email account is randomly dropping messages from the parrot lists)
<mdiep> particle: return -1 (that's what it does now)
<particle> oh, btw, didn't we want a pragma for exception vs return code semantics?
<mdiep> chromatic: yes, although that may not be a bad idea either. but there's no real "socket" PMC
<allison> go ahead and commit 41128
<allison> looks good
<particle> pmichaud: i'd like to see PGE::CodeString moved to runtime/parrot/library, so i can use it for testing. any comment?
<mdiep> how about dropping the PGE:: from the front?
<pmichaud> particle:  I'd create it as a standalone "CodeString" class
<allison> a socket object is a ParrotIO object
<pmichaud> then PGE can migrate to using that
<particle> pmichaud: i hoped you'd say that. great, will do.
<allison> mdiep, we've been standardizing on returning -1 from the I/O opcodes
<mdiep> the socket number will only ever be positive, so that doesn't conflict with returning -1 on error
<allison> though, the asynchronous ones will return a status object that takes method calls, and returns various values in string, integer contexts
<particle> sounds like an exception to me
<allison> particle: yes, ultimately
<particle> allison: you had a question for me?
<allison> but exceptions and asynchronous operations don't play well together
<allison> particle: yeah
<allison> it was: would a lightweight language for testing be a valuable addition? Writing tests in PIR could be a little clunky.
<particle> yes, it is clunky
<chromatic> Is that a failure of PIR or a failure of the abstractions we have for testing?
<particle> using CodeString will allow me to autogenerate code, and especially branch logic
<allison> mdiep: I'd rather see bind return a status object that allows access to the port number through a method call than have it return an integer with layered meanings
<particle> so i can generate eg. ok/nok label pairs for each test
<particle> chromatic: it's an abstraction failure
<allison> mdiep: or for that matter, have the port number accessible as a method call on the socket object
<particle> i'm not sure we need a full-on language, but some utilities would be quite helpful
<Coke> a lightweight language for testing would involve having PGE available for testing everything. I think I'd rather stick to PIR.
<mdiep> allison: okay. I'll investigate more.
<Coke> particle: macros, perhaps additions to the existing test classes.
<allison> coke: agreed on keeping the dependencies light
<allison> at least for testing core Parrot code
<particle> allison: how are the meanings "layered"? positive integer is success w/port number. negative one is error
<particle> that's standard c
<allison> particle: parrot != C
<allison> it's one of the worst features of C
<particle> ok. that's fine. what about i/o then?
<allison> more detailed question?
<particle> you said: "mdiep, we've been standardizing on returning -1 from the I/O opcodes"
<particle> will this standard... stand?
<allison> particle: that was the decision earlier, when we figured out that exceptions would wreak havoc on async I/O
<allison> particle: I'm not entirely happy with -1 return codes
<particle> ok, but they could return an object with methods
<allison> yes, the status object
<particle> which may just be a subclass of Exception
<allison> it's not related to exception
<allison> it's not thrown
<allison> it's not even active
<chromatic> it returns -1 on get_integer
<allison> and it's only accessible to the calling code
<allison> chromatic: on a failure, yes
<particle> ok. will this make embedding/extending much harder?
<allison> or maybe 0
<allison> because it's a failure that's not handled as an exception?
<particle> yes, that, and that it's not the way c does it
<allison> the idea was to make it possible to turn on exceptions when you want them
<allison> either globally, or for an individual I/O operation
<Coke> I don't particularly like on or off exceptions.
<obra> this should likely go back to #parrot
<allison> C doesn't exactly throw exceptions
<allison> yeah
<obra> Are there other questions for the sketch?
<Coke> I'd rather we did them uniformly.
<Coke> not #parrot - the list.
<particle> i have a few questions wrt the upcoming release
<obra> ok. particle: shoot
<particle> first, any showstoppers you're aware of?
<allison> coke: I'm about to start up a final round of comments on the I/O PDD, so we'll wrap the discussion in there
<particle> also, i think without some heavy c coding, these releases will all be bugfix-only. we have a few pdds which remain unimplemented.
<particle> that's a problem.
<allison> the releases will include features as we develop them
<particle> ...especially with an io pdd to be approved shortly
<allison> I'm going to start hacking on some of the approved PDDs
<particle> allison: ok, it shouldn't affect january's release, anyway. i'm just pining for more c programmers, as usual.
<allison> perhaps we can have a "feature development" saturday?
<Coke> nothing wrong with atargetting language development either: can get some perl6 or tcl or <> development done as a major item for a release.
<allison> in addition to "bug squashing" saturday?
<particle> (focused hacking)++
<mdiep> how about a "write tests for approved pdds" saturday?
<allison> mdiep: that can happen at the same time
<allison> so everybody can participate, whether they're into C coding or not
<leo_> hi folks - greetinx @all
<Coke> suggestion: get all this onto the wiki.
<Coke> leo!
<Coke> we were just hoping we'd get a c programmar!
<allison> coke: which wiki?
<particle> http://rakudo.org/parrot/index.cgi?parrot
<leo_> I saw the note re release above - if you have any questions please just ask
<particle> thanks, leo. will do.
<Coke> allison: parrotcode.org -> wiki
% jane has left jane!~jane@66.37.169.171
<allison> coke: ah rakudo, okay, we've had several over the years
<obra> ok. anything else?
<obra> if not, I'll release you all until next week
<particle> cya
<allison> cya
<chromatic> thanks
<obra> see you all
<leo_> cya
<allison> particle: are we catching leo on #parrot?
<particle> join #parrot for discussion of next release
<leo_> yep
% chromatic has left #parrotsketch
% pmichaud has left #parrotsketch
% Coke has left #parrotsketch
% bernhard has left bernhard!~bernhard@p549A2D81.dip0.t-ipconnect.de
% particle_ has joined #parrotsketch
% particle has left particle!~particle@144.81.84.133
% particle_ is now known as particle
% mdiep has left #parrotsketch
% davidfetter has left davidfetter!~davidfett@start.fetter.org
% davidfetter has joined #parrotsketch
% particle_ has joined #parrotsketch
% particle has left particle!~particle@144.81.84.133