% contingencyplan has joined #parrotsketch
% contingencyplan_ has left contingencyplan_!~contingen@cpe-76-186-27-146.tx.res.rr.com
% rdice has joined #parrotsketch
% allison has joined #parrotsketch
% cotto_work has joined #parrotsketch
% jhorwitz has joined #parrotsketch
% Coke has joined #parrotsketch
% barney has joined #parrotsketch
% Infinoid has joined #parrotsketch
<Coke> Happy Tuesday, parroteers.
<Infinoid> happy Wednesday Eve, Coke
% chromatic has joined #parrotsketch
<chromatic> Good day everyone.
<Coke> ~~
<allison> good evening
<barney> hi
<Coke> we have enough folks to start on the reporting. chromatic?
<chromatic> Alrighty, let's begin.
<chromatic> allison?
<Coke> ... I see what you did there.
<allison> - Launched the Strings PDD out of draft.
<allison> - Found Bob's message on inferior runloop, but haven't replied yet.
<allison> - Working on the Concurrency branch, will have some tasks for chromatic (or others) tomorrow.
<allison> EOR
<barney> - Applied rotty's riaxpander patch to Eclectus.
<barney> - Added nqp/bootstrap/t/harness.
<barney> The '-files' import option for P::T::Harness broke unified languages testing for Eclectus.
<barney> .eor
<chromatic> I've spent my week optimizing.  Rakudo's about twice as fast as it was.
<chromatic> Also I've identified a few other slow parts, and we're removing some dead code as a result.
<chromatic> Coke?
<Coke> Minor cleanups / code removals in progress:
<Coke> - cleanup op syntax patch
<Coke> - type_ids branch
<Coke> .eor
<chromatic> Infinoid?
<Infinoid> * I've gotten a running start on the "M2 Bytecode format" milestone.
<Infinoid> * Working in the "pdd13pbc" branch, I've got stub PMCs in place, next step is to flesh them out.
<Infinoid> * I've posted my game plan to the list, and broken out the stages into RT tickets, if anyone is interested.
<Infinoid> * Meanwhile, in trunk: applied some stuff from RT: IMCC and OpenGL.  Fixed some fallout from OpenGL.
<Infinoid> * Fixed a couple of minor breakages in lua and rakudo.  Fix a couple of codingstd issues.
<Infinoid> * Several g++ fixups.  Lots of weird stuff... typos in preprocessor macros, disappearing globals, symbol mangling, consting.
<Infinoid> * In the ongoing battle against g++, I've started consting the "SELF" parameter for a few vtable methods.
<Infinoid> * Not sure how far I should go with that, or even if its the right way to go.
<Infinoid> * Reserving a question ticket for that.
<Infinoid> 1;
<chromatic> jhorwitz, are you here?
<jhorwitz> just lurking today.  returning to form after weeks of $DAYJOB monopolizing my time and a vacation. 
<chromatic> particle?
<particle> released 0.6.1.
<particle> too busy vacationing to keep up with parrot development
<particle> last few days windows builds have been broken
<particle> now it builds but tests are broken
<particle> working on a fix
<particle> .ned
<particle> heh.
<chromatic> pmichaud?
<pmichaud> * improved PGE code generation a bit
<pmichaud> * removed the saveall/restoreall opcodes, eliminated a lot of dead code
<pmichaud> * created a branch for removing the rest of the user stack ops, have already done it with no problems
<pmichaud> * however, DEPRECATED.pod indicates we don't remove those until post-0.7.0, so it'll have to stay in the branch for now
<pmichaud> * looking at improvements to bsr/ret, since PGE uses those opcodes very heavily
<pmichaud> * normally I don't get into parrot core stuff, but in this case I think it's useful because I'm also looking at PGE redesigns for longest-token-matching and it's helpful to know more about Parrot internals (and these are relatively straightforward thus far)
<pmichaud> * still need to push out the rakudo milestones document -- it's in my head but needs fingers to pound a keyboard.  that should happen tonight.  definitely by tomorrow afternoon.
<pmichaud> reserving two question tickets.
<pmichaud> eor
<chromatic> tewk?
<chromatic> Tene?  PerlJam?
<chromatic> Okay, let's go to question time then.
<chromatic> Infinoid, go ahead.
<Infinoid> Ok.  I've done some consting of vtable methods, and have some more to go.
<Infinoid> I've run into some cases that make me less sure of this approach.
<Infinoid> At first glance, isa(), get_class(), name(), type() appear pretty easy to const
<Infinoid> but some of the implementations of those vtable methods call, for instance, get_string()
<Infinoid> ...which I'm pretty sure shouldn't be consted.
<Infinoid> So I want some opinions.  Should there be strict rules about what the above listed methods can call?
<Infinoid> Or is this the wrong approach entirely?
<chromatic> Are you consting only SELF or other arguments?
<Infinoid> I am only consting SELF
<chromatic> Why shouldn't get_string() be const?
<Infinoid> it might be generated lazily from an array, or read lazily from a network socket
<pmichaud> what if we did get_string() on a lazy.... right
<particle> i really don't think any vtable methods should be const. but whatever... as long as it's documented in the pmc pdd.
<Infinoid> it's fairly easy to contrive a case for get_string being non-const
<pmichaud> I even have concerns about SELF being const
<Infinoid> also, an expensive stringification process might want to cache the result
<chromatic> Is this const *SELF or const * const SELF or * const SELF?
<allison> Infinoid: why did you start making SELF const?
<allison> g++ was complaining?
<Infinoid> chromatic: const PMC *pmc (in the generated .c)
<Infinoid> allison: g++ was complaining, but so does gcc
<Infinoid> some functions in parrot are declaring themselves with a consted PMC pointer, and then turning around and calling VTABLE methods
<Infinoid> which violates the whole "const" contract.
<allison> we certainly don't want to restrict what functions can be called from within various vtable functions
<Infinoid> agreed
<Infinoid> I posted RT #53066 about this, and was mostly warnocked.  Andy had an implementation concern, but I feel its mostly a design question
<allison> I'd push the bug back a level and say that any PMCs that call vtable functions shouldn't be const
<chromatic> That's going to remove a lot of const from the rest of the system.
<Infinoid> its easy to back out the vtable consting work I've done so far.  so far I'm hearing that backing it out is the way to go.  right?
<Infinoid> ...and then start un-consting the stuff that calls vtable methods
<pmichaud> s/any PMCs/any functions/
<allison> chromatic: well, what's the benefit of adding const, when the vtable function can modify the PMC?
<pmichaud> oh, I see... "any PMCs" works too
<Infinoid> any function which can modify the PMC, or which calls something which can modify the PMC, really shouldn't be declaring that PMC as const.  period.
<particle> PMCs are never const.
<chromatic> Yeah, but the argument seems to be in part "Oh, someone might someday eventually call something from here which might modify the pointer, so we can't ever use const."
<Infinoid> its about modifying the struct, not the pointer
<Infinoid> const PMC *pmc, not PMC * const pmc
<chromatic> Right.
<allison> the argument is only for cases that currently warn about const
<allison> we can't const the vtable functions for some PMCs and not for others
<pmichaud> unless we want to declare certain vtable methods as definitively and always being const.... right
<Infinoid> and of course, those warnings turn to errors for g++
<chromatic> I'm fine with removing (or reviewing) const where we cast it away.  That's pretty clear.
<allison> so, we have to make a blanket decision for all vtable functions
<chromatic> I just hate to make decisions based on an attempt to predict the future.
<Infinoid> allison: the question was whether certain vtable functions should be const, not whether vtable functions for certain PMCs should be const
<Infinoid> chromatic: true.
<allison> Infinoid: right, but the fact is that since we can't distinguish between individual PMCs, then they can never be const, because we don't want to impose that decision on other PMCs
<allison> chromatic: actually, the decision is to explicitly not try to predict the future
<Infinoid> makes sense.
<pmichaud> putting 'const' on a PMC doesn't say it can't ever be modified, it's simply a contract that the current function won't do anything that might modify it
<Infinoid> ok, I'll back it out.  that'll solve some current warnings and give me a starting point for future work.  (detecting currently casted-away consting issues will be fun.)
<pmichaud> the PMC could still be non-const to a caller 
<Infinoid> yes, absolutely.  for each function call boundary, const-ness should only increase
<allison> pmichaud: right, but the problem here is with non-const vtable functions called by the function that const'd the PMC
<chromatic> Does const PMC mean that we won't modify the contents of the struct directly or the contents of the contents of the struct?
<chromatic> That is, can we assign to the struct pointed to by the data pointer of the PMC struct even if the PMC struct is const?
<pmichaud> allison:  right -- if a function is calling a non-const vtable function, then it cannot const the PMC
<Infinoid> chromatic: good question.
<pmichaud> and if we presume that nearly all vtable functions are non-const (which I think is the correct assumption), then functions that call vtable functions should not be consting the PMCs
<Infinoid> yep, and I will be un-consting those.
<Infinoid> thanks!  EOQ.
<chromatic> When we're talking about modifying the PMC, we're probably not talking about modifying what it contains directly -- we're talking about modifying things accessible through its data pointer, which presumably we're not replacing.
<particle> that's not 100% guaranteed
<particle> let's hold off on that optimization for later, chromatic
<pmichaud> is it really an optimization?  I tend to think of const a more of a defensive programming measure.
<pmichaud> (yes, I know that 'const' gives compilers room to optimize, but I don't think that's common in the cases we're discussing)
<Infinoid> the warnings gcc will emit just for having called the non-const function will be a good indicator that the PMC or values pointed to by the PMC may be modified
<Infinoid> so the warning will raise a flag for both
<chromatic> I'm comfortable with backing out the vtable consting for now.
<chromatic> ... provided we don't end up with messier code trying to work around g++ errors.
<Infinoid> show me a software project with no "const" at all, and I'll show you a project free of messy const warnings :)
<allison> are we talking about "const PMC *foo" or "PMC * const foo"?
<Infinoid> the former, allison
<chromatic>  const PMC *pmc
<allison> just checking, everything we said stands
<Infinoid> agreed, preparing to back out the const vtable patches and fix up the callers.
<Infinoid> thanks!
<chromatic> Shall we move on to pmichaud's questions then?
<allison> yes
<chromatic> pmichaud, go ahead.
<pmichaud> q1:   I was a bit surprised to see that the user stack ops are post-0.7.0 deprecated.  Do we expect that to occur soon, or is there a strong reason for holding them a long time?
<allison> mainly just a desire to save major feature changes for more major versions
<allison> there's no reason 0.7.0 can't be the May or June release
<chromatic> <pumpking_hat>kill 'em</pumpking_hat>
<allison> yeah, I say go for it
<pmichaud> at any rate, I've removed and/or identified all of the user_stack opcode usage in trunk, so whenever we do decide to get rid of them it should be straightforward to do so
<particle> kill them now (more)
<chromatic> If we can roll the branch back in in the next week or two, I'm all for it.
<allison> better to roll branches in quickly
<pmichaud> I was actually just going to remove the branch.
<particle> the 0.7.0 designation in DEPRECATED was made from a previous release plan
<pmichaud> with where things are now, I can remove the user stack ops directly from trunk with no problem.
<pmichaud> i.e., it can occur at any point you all say it should. :-)
<particle> we released 0.7.0 functionality in 0.6.0
<allison> so say we all
<Coke> particle: there is a big difference between adding and removing things early.
<chromatic> . o O (allison is a Cylon)
<particle> coke: we renumbered the releases
<particle> but not the files that referenced the old release numbers
<Coke> I don't see a problem with it, just make sure it goes in the news with some kind of special notification that it was removed ahead of time.
<particle> it's a documentation error
<particle> just happens to be in an important file
<pmichaud> documentation error, but also a promise of sorts
<pmichaud> "these ops will exist until the 0.7.0 release".  The fact that we renumbered releases isn't highly relevant
<pmichaud> that said, I'm greatly in favor of killing it.  :-)
<chromatic> Everyone working out of the tree knows the risks.
<allison> removing the user stack ops is a significant change, and a good reason for a version bump
<particle> Failed 45/580 test scripts. 216/11212 subtests failed.
<pmichaud> okay.  So, I'm hearing we can go ahead and get rid of them now.
<particle> these are the risks :)
<allison> pmichaud: yes, do it
<pmichaud> they have been listed as deprecated, we're just doing it out-of-sync with the number releases
<pmichaud> so it's not like we're springing it upon people unawares
<pmichaud> okay, it will be done.
<pmichaud> Q2.
<pmichaud> I'm running into a couple of places where it will be useful to have a hash function (e.g., md5sum)
<pmichaud> there's already a MD5 library written in PIR in runtime/parrot/library/Digest/MD5
<pmichaud> I'm fine with using this library -- however, it's currently written with global functions
<pmichaud> I would like to either (1) refactor the library to be OO, so we aren't polluting namespaces
<pmichaud> (2) decide that we're going to use a non-PIR based library for computing md5sums
<pmichaud> (3) figure out another standard way that we want to produce unique identifiers
<pmichaud> (end of options)
<pmichaud> I'm in favor of #1 for now.
<particle> fperrad created a uuid library
<allison> wasn't the md5 unique identifiers a temporary hack?
<particle> he's using it for lua iirc
<particle> happened last week
<pmichaud> allison:  it may be a temporary hack, but I think it may end up being for largish values of temporary
<allison> particle: right, but these identifiers have to be unique even between different runs of Parrot
<pmichaud> for the cases I'm looking at, I'm not worried about collisions
% paco has joined #parrotsketch
<pmichaud> even across different runs of parrot
<chromatic> even across different machines
<particle> how does md5sum give you something unique across runs of parrot?
<pmichaud> it depends on what you're summing, of course
<pmichaud> as long as the possible colliding things produce unique md5sums, you're safe.
<allison> back to the original question: global functions are evil and should die. OO PIR, or a C library, or a C PMC would all be an improvement
<chromatic> #1 sounds easiest to me
<pmichaud> I can do OO pir fairly quickly, based on what we have now.
<particle> oo pir
<allison> pmichaud: then do that
<Coke> ... if OO pir is a goal of the libraries, there's a LOT of cleanup to do.
<allison> further refactors can come later
<pmichaud> the only reason I consider the other options are speed, but the cases I'm looking at won't matter much
<Coke> (someone should write that down.)
<pmichaud> I'm also not trying to establish that all libraries should be OO -- just this one.
<allison> coke: just not global, namespace polluting libraries
<chromatic> Someone should write a ticket tracking system in OO PIR.
<particle> we can make an md5 pmc in c if we need speed
<chromatic> I thought we already had that with the crypto libraries.
<particle> just write an md5 pmc in pir for now
<particle> on every platform?
<pmichaud> most md5 implementations I've seen are already OO-ish, so this one ought to be as well
<allison> particle: yeah, that would be the next stage of refactor
<pmichaud> I was a little surprised that it wasn't (but also know that the MD5 implementation was probably pre-OO-parrot)
<pmichaud> anyway, I have my answers.  Thank you all.
<chromatic> Any more questions?
<particle> i have a comment about GSoC
<particle> the final list is out and published
<particle> tpf got six slots
<particle> two are parrot projects, and one is perl 6
<particle> "Native Call Interface Signatures and Stubs Generation for Parrot" - tewk
<pmichaud> tewk++
<particle> "Incremental Tricolor Garbage Collector" - wknight8111
<pmichaud> wknight++
<particle> "Flesh out the Perl 6 Test Suite" - adrian kreher
<particle> also, i hear ASF (apache) has a project related to parrot too
<particle> i don't have the exact title, but it's senaka, integrating the Harmony GC with parrot
<Infinoid> "Build a garbage collector for C/C++ programs on the top of Harmony"
<particle> so, there's possibly some overlap with the gc projects we'll have to manage this summer
<particle> that means we may each learn more than we want to about parrot gc
* Infinoid has bought a nice thick GC book for this purpose.
<allison> which one?
<Infinoid> "Garbage Collection: Algorithms for Automatic Dynamic Memory Management"
<Infinoid> ISBN-10: 0471941484
<allison> yeah, that's a good one
<chromatic> Anything else?
<Coke> not here.
<pmichaud> not here.  I've had too much fun already.
<Infinoid> thanks, all!
<chromatic> Okay, thanks everyone.  Same time next week.
% Infinoid has left #parrotsketch
% cotto_work has left #parrotsketch
% allison has left #parrotsketch
<paco> NotFound: quizas te interese el canal #parrotsketch del servidor que de tije alli, por lo visto ahi se dicute detalles de implementacion : "Incremental Tricolor Garbage Collector" - wknight8111
<paco> upss .. sorry
% chromatic has left #parrotsketch
<paco> not for this channel ..
% barney has left barney!~bernhard@dslb-084-058-102-180.pools.arcor-ip.net
% Coke has left #parrotsketch
% jhorwitz has left #parrotsketch
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
% rdice has joined #parrotsketch
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
% cognominal has left #parrotsketch
% cognominal has joined #parrotsketch
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% contingencyplan has joined #parrotsketch
% particle has left particle!~particle@c-24-19-3-148.hsd1.wa.comcast.net