% cognominal has left cognominal!~stef@cac94-1-82-67-232-89.fbx.proxad.net
% cognominal has joined #parrotsketch
% Coke has joined #parrotsketch
% Coke has left Coke!~wcoleda@cpe-24-194-223-228.nycap.res.rr.com
% Coke has joined #parrotsketch
% particle has joined #parrotsketch
% audreyt has joined #parrotsketch
% leo has joined #parrotsketch
% Nicholas has joined #parrotsketch
% Coke has left Coke!~wcoleda@host-216-153-142-9.alb.choiceone.net
% mdiep has joined #parrotsketch
% mdiep has left mdiep!~mdiep@c-24-11-80-190.hsd1.mi.comcast.net
% mdiep has joined #parrotsketch
% Coke has joined #parrotsketch
% allison has joined #parrotsketch
<audreyt> greetings folks :)
<allison> hi
<leo> hi all
<particle> howdy
<audreyt> allison: I'm so glad you're here :) last week there's some discussions proxied via chromatic :)
<mdiep> hello
<allison> audrey: excellent
<mdiep> it appears that neither of our moderators are here
<Nicholas> Can we run without them?
<allison> yes
<allison> is logging automatic?
<audreyt> I think so
<audreyt> I'm keeping local log too
<allison> ok, cool
<allison> so, who wants to start?
* audreyt notes "al" sorts before "au"
<allison> ok, mine's quick
<allison> I started up work again last week.
<allison> Worked some on using PGE's operator precedence parser in Punie.
% chromatic has joined #parrotsketch
<allison> Dropped Patrick a note about a snag, and went on to work on capturing string values and comma separated expressions.
<allison> I'll finish that off this week.
<allison> EOR
<allison> which brings us to au :)
<allison> and I'll hand off running the meeting to chromatic :)
<allison> aye
<audreyt> :)
<audreyt> ok... I cloned enough of operator precedence parser and rules engine to parse grammars using rules
<audreyt> made the new pugs runtime's minilanguage (not unlike Punie/perl1 in feature set) to use it for parsing
<allison> cool
<audreyt> also implemented p6 "repr" types in the new runtime using the PMC interfaces design posted by leo a couple weeks ago
<audreyt> currently only Opaque, Scalar, Array and Hash PMCs ported over
<audreyt> IO and OS coming soon
<audreyt> this should allow a much closer mapping between PILN (roughly equivalent to POST) and PIR emission
<audreyt> I'm looking at codegen to new lexpad code at this moment; seems straightforward
<audreyt> (not sure if it makes sense to compile it the other way around -- from POST to PILN -- but we can talk about it later)
<audreyt> also, porting the above stack to Perl5 in this ongoing hackathon
<audreyt> in particular the rules engine, which should give rise to a more stable rules implementation than the now-defunct Perl6::Rules
<audreyt> once we regain PIR codegen, Pugs 6.2.11 will be released, circa this weekend.
<audreyt> end of report.
<chromatic> Is anything blocking you?
<audreyt> I'd like some understanding of POST's status. the compiler tools roadmap says POST is isomorphic to PIR
<audreyt> but last week you said something else iirc
<audreyt> otherwise nothing else
<chromatic> Question noted.  Are you having fun?
<audreyt> yeah :)
<chromatic> Good.  Next up, that Chip fellow, if he exists.
<chromatic> If not, I have nothing to report and now it's Coke's turn.
<Coke> Aren't I just lurking?
<chromatic> I thought you were hacking on Tcl in Parrot, which counts.
<Coke> I'll defer to mdiep this week, and plan for next, then. =-)
<chromatic> Alright.  Leo?
<leo> - Released 0.4.1
<leo> - A lot of late hacks for 'make install' and shared build
<leo> - Enhanced design docs, incl. implementation.pod
<leo> That's it - EOR
<chromatic> Are you blocking on anything?
<leo> yeah I need chip for some decisions WRT these design docs
<chromatic> Are you having fun otherwise?
<leo> yes, except currently: it has 9C here oil heating is b0rked
<leo> (but plumber is already here)
<audreyt> leo: where is this implementation.pod you speak of?
<chromatic> Turn of ccache and you'll warm up again in no time.
<leo> ~lt/dev-doc on feather
<audreyt> k
<leo> ccache in on always ;-)
<chromatic> Next up, mdiep.
<chromatic> Or maybe Nicholas.
<Nicholas> Leo sent me his design proposals. I read the PMC proposal. The very next task on the ponie roadmap  http://svn.perl.org/ponie/trunk/Roadmap
<Nicholas> is to rearrange the structures of the Perl 5 data inside the PMCs (search for "rearrange structures")
<Nicholas> hence as Leo is proposing a PMC re-arrangement, that blocks ponie (too)
<Nicholas> but it's also blocking on finding a replacement pumpking
<Nicholas> that's mostly it.
<Nicholas> apart from we're being logged here: http://www.parrotcode.org/misc/parrotsketch-logs/irclog.parrotsketch-200601/irclog.parrotsketch.20060109
<chromatic> Are you having fun?
<Nicholas> EOR
<Nicholas> I'm not doing anything, so it's tricky to answer. But if I were trying to do things I would not, because I'd be blocked on something that doesn't seem to be moving
<Nicholas> well, actually I'm doing perl 5 stuff, but that's not the topic here
<chromatic> Alright.
<chromatic> particle?
<particle> the shared build patches leo mentioned caused a lot of windows debugging, mostly provided by me. jonathan worthington stepped up with a solution, though.
<particle> also, some OS.pmc changes have required rebuild/retesting on windows. all this speaks to (imo) a shared win dev box.
<particle> so then people won't be blocking on me to test their changes
<particle> i've made little progress on the test suite, mostly due to lack of time.
<particle> ZZ
<chromatic> Are you blocking on anything besides time?
<particle> no.
<chromatic> Are you having fun?
<particle> yes. my only reason to work on parrot is to have fun. :)
<chromatic> Good.
<chromatic> Chip, you're up now.
<chip> Hey guys.  Yes, I continue to exist.  :-)  
<particle> !
<leo> hey
<mdiep> excellent!
<chip> Real life mugged me a couple of weeks ago ... not me personally, but someobdy close to me, has a bit of an interesting situation that required a lot of my time.  
<chip> I got back to Parrt about a week ago, and I'm >< this close to checking in a namespace pdd.  I also have Leo's proposals to review
<chip> I'm not blocking on anything, but I would be pleased at the generosity of the universe if I could find a review of the last, oh, three weeks of parrot structural changes.  Not that I can't catch up on them as needed
<chromatic> Are you having fun?
<chip> well, I have a lot of fun when I hit on all cylinders.  I'm beginning to think that Allison's "Parrot Day" idea is worth trying
* particle must have missed that idea
<chromatic> Allison, can you explain that after Matt reports?
<allison> ok
<chromatic> Matt?
<chip> She did it for herself: On a project (might not have been Parrot) she overcame inertia by dedicating X hours (4?) on a specific day each week to Parrot
<chip> oh yeah she's here.  we'll see how my memory works :-)
<mdiep> my iBook broke on Christmas day, somewhat impairing my ability to work on parrot-y things, but work continued thanks to ssh+screen. I've just got the iBook back today.
<mdiep> but work has continued to inline commands in partcl
<mdiep> recently, coke has been working on a templating system for said commands, significantly reducing the amount of work and code necessary.
<mdiep> development is picking back up in speed again
% PerlJam has joined #parrotsketch
<chromatic> Are you blocking on anything?
<mdiep> just the namespace pdd, which chip just reported about
<chromatic> Are you having fun?
<mdiep> yup!
<chromatic> Good.  Audrey, you had the first question.
<audreyt> aye. my question was: comptools says POST<->PIR has isomorphism
<audreyt> which seemed to suggest that the PIR concepts (lexpads, namespaces, invocation) maps directly to POST
<audreyt> but last week chromatic mentioned it's now driven by HLL demands, which I don't quite comprehend
<audreyt> so: what's the plan, and how can I help?
<chromatic> Allison?
<audreyt> (sorry, network is laggy)
<allison> It's isomorphic in the sense that POST needs to be able to represent all the directives and instructions in PASM
<allison> it's not isomorpic with PIR, in that it's a different kind of syntatic sugar
<allison> not sure what chromatic meant by "driven by HLL demands"
<allison> PAST is closest to the HLL
<allison> POST is likely to have some things a little different, like the .sub .end pair is likely to be a node in POST, instead of two separate instructions
<allison> s/instructions/directives/
<chromatic> I believe my point was that the current version of POST in the Parrot tree reflects only what you need for Punie so far.
<allison> ah, yeah, mostly
<allison> though, I expect the final form will be about equivalent to Pugs' PIR Tree
<allison> (roughly)
<audreyt> okay... so the way I could help most is to update the PIR tree to reflect new PIR concepts
<audreyt> and make sure it does correspond to PASM (i.e. generates valid code)
<allison> aye
<audreyt> instead of trying to map with POST's alternate model
<audreyt> okay, thanks :)
<particle> i have a question
<chromatic> Go ahead.
<particle> are there plans to take audrey's work on the pugs port of PGE and backport any extensions to patrick's implementation back to PIR?
<particle> or will the new port be the main target for new functionality, and PGE eventually be retired?
<audreyt> I can maintain a list of deltas with PGE/OpTable -- currently there's list-associativity and improved null term support -- and post them to p6c
<audreyt> and if pmichaud or other hackers can pick it up, that'd be wonderful. though I wonder if a C binding for optable/rules engine makes more sense in the long term, similar to libpcre.
<particle> list of deltas would be great. other hackers could be encouraged to improve PGE then, with the pugs implementation as a reference, thanks.
<audreyt> np :)
<particle> i agree about C as the long-term solution, too.
<chromatic> Anything else?
<leo> a short Q to chip
<leo> just a general stmt WRT the mentioned design docs? 
<chromatic> Chip said privately he might be in a tunnel, but he'll try to respond within a couple of minutes.
<leo> ok
<Nicholas> I wanted to ask Leo if the substr pingpong example at the start of his design proposal on strings had got sent to the list at all
<Nicholas> I've found the thread on "[perl #37940] substr and memory issues" but I can't actually see how it maps to Leo's clearer code
<leo> I mentioned it when it came up with shootout benchmarks
<leo> it took some time to ananlyze the details
<Nicholas> that doesn't surprise me. It's the way of these things :-(
<leo> so the answer is no - the detailed example isn't public yet
<Nicholas> aha. because the analysis was interesting and I wanted to ask a question about it
<leo> yes?
<Nicholas> in the loop, doesn't it at most have 4 copies of the string, because when $S0 or $S1 get reassigned to the second (and subsequent) times round?
<Nicholas> hence intermediate string buffers should be reclaimable by the GC?
<leo> yes 
<leo> but it doesn't
<Nicholas> OK, now I'm confused
<leo> memory consumption ever increases
<chip> back
<leo> I didn't yet get that far to track the very reason
<Nicholas> that's why I'm confused. how come none of the intermediate temporary strings are available for GC
<chip> I think the problem is that the COW bit never gets turned off, even after enough copies have been taken
<Nicholas> hangon, so if a string gets marked as COW it never ever ends up being reclaimed?
<leo> I think there are always to refs to the string and nothing gets reclaimed at all
<chip> it never ends up without the COW bit until it's unreachable.  
<chip> leo may be right as well
<chip> s/unreachable/destroyed/ in !-2
<leo> Nicholas: no first COW bit is turned off, but if there is another ref COW is turned on again
<Nicholas> ah OK. I can't quite see how there are still refs to the strings given that there are only 4 (named) string variables in play
<Nicholas> I can accept that there are, but I can't see where they are coming from
<leo> well - these are the refs
<leo> the main problem I think is: a COWed string is aalways copied, or better the whole memor of it is copied, even if it refers just to one byte 
<chip> but that doesn't explain infinite memory growth
<leo> a = b[999999] # both are strings
<leo> a is one byte # for ascii
<leo> if a is alive 1 meg is copied
<leo> the grow comes from the GC trying to increase mem pools for more demand
<Nicholas> I don't know enough about that part of the GC to comment further, but that growth seems reasonable behaviour for the GC
<leo> yes but in that case it kills it finally 
<chip> but ... is it infinite growth in theory, if you kep tthe test program going you'd eventually plateau, no?
<Nicholas> copying 1 meg for a 1 byte substring sounds like some sort of naïveté that could be fix (as in, undo the COW if it's looking like the ratio of the substring is tiny). Oh. Hangon. The copy happens if you change b, because b has no idea how much a is pointing to?
<Nicholas> (happens also if you change b)
<leo> the copy happens if you change either part of the COW string
<chip> Nicholas: the ratio is also an idea I had.  But I'd first want to be sure the COW bit actually does get turned off at the right time
<leo> src/resources.c:327
<Nicholas> leo: yes, but what I meant was that when changing a, a should be able to see that it's 1 byte of 1 million and go "that's daft, I'll stop being COW now", but changing b, b has no idea that a is that small, only that "someone else is sharing my buffer" so b has no choice but to copy
<leo> yep
<leo> that means that substr for that case should never create COW copies
* chip adds "daft" to his design vocabulary
<leo> it's too late when COW bit is already on
<chip> leo: yes, it's more of an issue of my understanding the whole mechanism as is before recommending a change
<chip> ... well, that seemed to kill the conversation
<leo> na - just started dinnering
<Nicholas> I think it's because I'm still stuck on quite how the substr example really eats memory. and don't have the copy of parrot or the knowledge to track it down and understand it
<chip> when to turn on COW depends on when it gets turned off, at least in part; thus my question.  if COW isn't turned off correctly, that would imply the need for a larger change -- refcounting, perhaps, or even elimination of COW as a general mechanism (not that I'd like that)
<chip> Nicholas: quite.  it's dangerous to make changes without understanding the bug
<particle> is this String-specific? or might it occur with PMCs as well?
<chip> PMCs don't have automated COW so I think they're safe from this
<leo> currently STRING only
<particle> good to know, thx.
<particle> i haven't seen a test case. can i help?
<Nicholas> that's why I wondered if it would be better to go to the list
<Nicholas> (for starters with the test case)
<leo> well, I can post all the desing docs
<chip> no, not docs for what should be
<chip> this is about debugging what is
<chip> test case, other notes, gdb/trace suggestions, that sort of thing
<chip> s/debugging/analyzing/
<chip> the infinite growth is the part that needs to be either (1) determined to be non-infinite or (2) explained
<leo> ok I'll put together a testcase 
<chip> kthnx
<Nicholas> thanks too. If it's something subtlely very wrong, I'd like to learn how it hides, so that I don't make the same mistake myself
<Nicholas> That was a rather long conversation as a result of my questions. Oops.
<Nicholas> Fortunately that was my only question.
<leo> *g*
% mdiep is now known as mdiep_
<audreyt> :)
<allison> particle: re "Parrot Day", I found I had a hard time working on Parrot an hour or two a day, because I would end up spending most of the time just getting started. So, I switched over to working on Parrot (TGE/Punie/etc) one full day a week instead. I'm much more productive that way.
<particle> i see, thanks. good for you, and good for us :)
<Nicholas> I was trying to ramp up to ponie fortnights at Fotango (for much the same reason) but it didn't work out.
<allison> yeah, every week is better, then I can look back and be encouraged by all the progress in the past few weeks :)
<Nicholas> I guess it depends on the amount of time it takes to switch to the task. The internals are messy, and the head-bangingly-good problems take a few days to get up to speed on
<leo> Nicholas: btw some time ago, we talked about hash bucket allocation order - I've reversed that today
<Nicholas> ah right. thanks, I thought that I'd mailed perl6-internals in the end that I'd realised that a better solution to the problem was to abandon using that hash code for that particular task in ponie for now
<Nicholas> and instead make the existing hacked-around-tracking-thing talk to the mark part of parrot's GC
<leo> doesn't matter - it makes a nice 'ordered hash' base now ;-)
<Nicholas> because the existing hacked-around-tracking-thing had the right sort of add/delete while iterating special properties already
% mdiep has joined #parrotsketch
% mdiep_ has left mdiep_!~mdiep@c-24-11-80-190.hsd1.mi.comcast.net
% chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net
% mdiep_ has joined #parrotsketch
<particle> well then, since our moderator has left, i assume this meeting is over. catch ya next week, all.
% particle has left #parrotsketch
<Nicholas> my thoughts too
<audreyt> ciao :)
<allison> thanks all, and talk to you next week!
<audreyt> *wave*
<Coke> ~~
% mdiep has left mdiep!~matt@bursley-216-65.reshall.umich.edu
% mdiep_ is now known as mdiep
% mdiep is now known as mdiep_
% mdiep_ is now known as mdiep
<Nicholas> Allison: glad to read that you are better
<allison> thanks
<Nicholas> on the bright side, the specific cause can't happen again :-)
<allison> aye, all wisdom has been removed now :)
<leo> see you
<audreyt> I guess it'll bring about more creativity instead :)
<audreyt> leo: oh btw, have you updated String.pod etc too?
<leo> all a bit more or less, yes
<Nicholas> hopefuly not on the part of the other teeth to innovate new ways of making mischeif
<audreyt> leo: anything drastically different?
<audreyt> (I ask because I'm going to implement Strings.pod in Pugs.)
<audreyt> (and I overwrote the old copies :))
<chip> do you refer to the one in ~lt/dev-doc ?
<audreyt> aye
<chip> That remains unapproved FYI
<audreyt> I've already got the interfaces.pod part done, and promoting ResizableFooArray to String is an easy step
<audreyt> *nod* but implementing the original vtables was quite difficult, so I opted to do something easier :)
<audreyt> (this is for Pugs's internal VM, not for parrot targetting)
<chip> I know you're comfortable with churn or you'd have gotten out of the Perl 6 business long ago
<chip> Just as long as there's truth in advertising
<audreyt> churn?
<audreyt> hm, "be agitated" according to wordnet
<Nicholas> I originally met it in terms of customer turn over at mobile phone companies
<Nicholas> "churn" was customers moving around
<Nicholas> in http://www.answers.com/churn&r=67 it's the definition of "Technology"
<Nicholas> but it's change, with the negative connotation attached to change as in "change is inevitable, progress is not"
<chip> that's pretty close
<leo> audreyt: String.pod is afaik almost unmodified
<audreyt> leo: k
% allison has left allison!~allison@ppp-71-139-16-206.dsl.snfc21.pacbell.net
% audreyt has left #parrotsketch
% obra has joined #parrotsketch
<obra> to those still here, please accept my profound apologies
<obra> I was giving a class today and fucked up. I failed to appoint someone to act in my stead
<Coke> We did fine, don't worry about it. =-)
<leo> np
<Nicholas> fret not. We did reports by forwards alphabetical order
<Nicholas> so I assume next week it's reverse
<obra> heh
<obra> noted
% Coke has left Coke!~wcoleda@host-216-153-142-9.alb.choiceone.net
% Coke has joined #parrotsketch
% Coke has left Coke!~wcoleda@cpe-24-194-223-228.nycap.res.rr.com
% Coke has joined #parrotsketch
% Coke has left Coke!~wcoleda@cpe-24-194-223-228.nycap.res.rr.com
% allison has joined #parrotsketch
% Coke has joined #parrotsketch
% allison has left allison!~allison@adsl-69-232-223-133.dsl.pltn13.pacbell.net
% Coke has left Coke!~wcoleda@cpe-24-194-223-228.nycap.res.rr.com
% Coke has joined #parrotsketch
% Coke has left Coke!~wcoleda@cpe-24-194-223-228.nycap.res.rr.com
% Coke has joined #parrotsketch
% mdiep has left mdiep!~matt@bursley-216-65.reshall.umich.edu
% mdiep_ has joined #parrotsketch
% Coke has left Coke!~wcoleda@cpe-24-194-223-228.nycap.res.rr.com
% mdiep_ has left mdiep_!~matt@bursley-216-65.reshall.umich.edu
% mdiep_ has joined #parrotsketch