% Nicholas has joined #parrotsketch
<Nicholas> thanks tweety, I already know that it's logged
<obra> I'm going to have to vanish for a few minutes at some point to deal with a housing inspector
<Nicholas> OK
<obra> If I'm not here by 5 past, ask chromatic to start without me?
<chip> we're at T-15 right?
<chip> oh, and Good Day
<chip> I have a meatspace meating that'll take me the first few minutes.  I expect I'll arrive at T+10
<obra> hi. yes. see you in 5
<obra> or whatever your local offset ends upo being ;)
% leo_ has joined #parrotsketch
% chromatic has joined #parrotsketch
% autrijus has joined #parrotsketch
<autrijus> greetings from during larry's state of onion.
<obra> hello leo, autrijus, chromatic 
<obra> I bet we're short an allison today.
<autrijus> allison is sitting on the left of me but with laptop closed
<obra> right. I figured as much.
<autrijus> the damian deadlang talk will be on shortly
<autrijus> at which time you'll lose me perhaps...
<obra> nod
<autrijus> (6% on battery)
<obra> ok. let's get going , then
<obra> autrijus: you first.
<obra> Waht's new?
<obra> (I have a report from mdiep in the can)
<autrijus> pairs demagicalized
<autrijus> parrot officiallydoesn't need to worry about magical pairs
<autrijus> the new PGE internal change segfaults here
<autrijus> for PGE::Hs
<autrijus> not yet debugged fully
<autrijus> helps welcome
<autrijus> otherwise, still slide hacking and pair poetry hacking, so nothing much else
<obra> Blocking on anything?
<obra> chip has a question for you before you lose battery.
<autrijus> go ahead chip
<autrijus> not blocking on anything.
<chip> autrijus: how demagicalized are these pairs?  Are all naemd parameters now syntactically identifiable?
<autrijus> chip: there is the remaining question of *$pair
<autrijus> where it needs runtime binding
<autrijus> which is still not very settled
<autrijus> otherwise it's purely static.
<chip> autrijus: let me rephrase
% pmichaud has joined #parrotsketch
<autrijus> greetings pmichaud
<chip> autrijus: the places where the named params come from in the param list are statically identifiable, if not the specific param names involved?
<autrijus> chip: yes.
<chip> PRAISE "BOB"
<pmichaud> hello, autrijus (and everyone else)!
<autrijus> hey pmichaud from this 2% battery
<chip> ok my q answered tx
<autrijus> np hth hand chip
<obra> ok. who's next? chip?
<chip> OK
<autrijus> no battery... over and out, bbl &
<chip> cya
<chip> lexical document in works
<chip> I'm blocking on possible misunderstanding of the word 'lexical' though.
<chip> Tcl code examples confound.  (no relation)
<chip> Sketch will be ready tomorrow though.
<obra> Excellent.
<obra> What can be done to clean up the misunderstanding of 'lexical'?
<chip> Approved Leo's plan, with small change, for var reg
<chip> Well, I thought it included some requirement of static scope.  I don't know any language lawyers here at $dayjob.
<chip> let me rephrase.  don't want to monopolize meeting though.
<chip> I thought a lexical had to be in principle knowable at compile time.  Tcl vars are not such.
<chip> To support Tcl vars as I understand them requires the dynamic lexical scratchpad in the original design, but that's rejected as too slow for p5/p6/python.
<chip> Anyway, that's the open issue.  Once that's clear the requirements will fall out.
<obra> ok.
<obra> anything else new and exciting, fearless leader?
<chip> Just one thing you might want to know ... I intend PIR to translate the lexical names to numbers, if that has to happen, so it shouldn't be necessary for compilers to track e.g. '$a' is pad element 4
<pmichaud> chip:  yay!
<chip> I figured you'd like that :-)  Leo thinks the lexicals should always map to registers.  I'm not entirely sure but it seems like a good plan
<chip> It also means maximal efficiency in using lexicals in same scope
<pmichaud> I agree, I like that plan
<chip> OK then
<obra> ok
<chip> that's all
<obra> Patrick, what else do you like? ;)
<pmichaud> more hours in the day would be nice, but I'm happy with what I've got now :)
* chip seconds that
<pmichaud> this week I re-did the calling internals for PGE
<pmichaud> PGE rules now act even more like subs -- they're all callable directly from PIR or as a subrule
<pmichaud> I also redid the internal representation of Match objects, so that they no longer need some funny indirection to handle the differences between arrays of captured Matches versus a single captured Match
<pmichaud> I have a version of Text::Balanced::bracketed that I'm about to ci to the repository -- it's callable as either a subrule or as a PIR function
<pmichaud> (I just need to steal test cases from p5's Test::Balanced t/ directory for that)
<pmichaud> I'm still working on the shift/reduce parser, it needed the internal changes mentioned above to work well
<pmichaud> the first thing that the shift/reduce parser will be used on is parsing of rule expressions, should be much faster than the existing recdescent version
<pmichaud> it will also provide a very nice case study or real-world example for the kinds of tree transformations we'll want to do in the compiler
<pmichaud> thazzit for me
<obra> You blocking on anything?
<chip> pmichaud: did you go with :multi for the rules?
<pmichaud> oh, and I'm likely to have lookahead  (<before ...> ) implemented by next week
<pmichaud> chip: no, I didn't
<chip> pmichaud: .isa or .can on first param then?
<pmichaud> chip:  yes,  .isa .  A rule sub looks at its first parameter, if it isa match object already then it clones it, if it's anything else then it stringifies it and creates a new match object from that.
<chip> pmichaud: cool
<pmichaud> (where the newly created match object will contain the result of the match)
<obra> Anything you need to make progress, besides brains and large sacks of cash?
<pmichaud> there are also optional parameters whereby a rulesub can specify the anchoring desired (anchor at current position or scan from current position), and to explicitly specify the class of the returned match object
<obra> Oh. is it time to do another pass through the PGE milestones and cross off things that are done?
<pmichaud> obra:  it's probably time to do another pass, yes -- I'll put that on my todo list right now
<obra> ok :)
<obra> anything else, or shall I pick on nick?
<pmichaud> nothing else, and to answer your question -- afaik I'm not blocked on anything at the moment
<obra> Excellent to hear.
<obra> Nick!
<obra> What's new?
<Nicholas> Back at work after 2 weeks off. (Fun fun fun, was getting up before 8am wall clock time every day of my so called "holiday" until this Friday)
<Nicholas> The work work is blocking on systems again, so the most logical thing to do is work on ponie until they're back
<Nicholas> I built it today and it failed tests. Pesky bitrot, I thought.
<Nicholas> It turns out that the bugs are at least partly due to the last bust of changes I made, to use the address registration PMC. Because I'm now using that to hold reference counts, when the core perl code manages to drop the reference count to 0, it means that SV (is a PMC) is not registered. Upshot is (of course) that it can be garbage collected. And perl 5 relies on things not quite going away, and not going away immediately that their reference cou
<Nicholas> In particular it happens that there is code down in sv_clear that makes a new temporary reference when destroying an object, and that was triggering the GC of a particular piece of memory higher up the stack. Yes, stack tracing is off, quite deliberately, because I want to find all the reference counting issues to make sure that destruction *is* timely under reference counting, before attempting the switch to true mark and sweep with a stack walke
<Nicholas> I've not solved it yet, but on the way home I think that the best solution is simply to bodge it and keep the reference count up by 1 from the true value, up to the point in perl5_cargocult.pmc where it currently does the ownership swap fr
<Nicholas> om "reference counted" to "nearly dead":
<Nicholas>                 if (!PL_in_clean_all) {
<Nicholas>                     FREE_SV_DEBUG_FILE(p);
<Nicholas>                     Parrot_PMC_push_pmc(INTERP, PL_sv_pining, SELF);
<Nicholas>                     Parrot_PMC_delete_pmckey(INTERP, PL_Refcounts, SELF);
<Nicholas>                 }
<Nicholas> (PL_sv_pining, the nearly dead being cleared at FREETMPS time)
<Nicholas> End of report
<Nicholas> [that was a cut&paste job]
<Nicholas> you're all stunned. :-)
<Nicholas> or pining for the fjords
<pmichaud> no, I'm thinking of quotes from "Young Frankenstein" and "Monty Python and the Holy Grail"
<pmichaud> "I'm not dead yet!"
<chip> Nicholas++ # Perl_sv_pining
<chip> Seriously it's a Good Thing not to lie to the GC system, and since Perl 5 tries, you have to adapt
<Nicholas> I fear that there's going to a be a lot more discovery of lies, and reference-count-free-pointers
<Nicholas> IIRC the optree references GVs
<Nicholas> there's the EGV slot in a GV
<Nicholas> and those are the two I can remember off the top of my head
<obra> Nicholas++ #stunning us into silence
<chip> heh
<obra> nick: blocking on anything {else}?
<Nicholas> well, pesky day job (the other stuff) still gets in the way of not-so-pesky-dayjob (ponie)
<obra> *nod*
<Nicholas> also, I'm hoping that the events API (or whatever was needed) as discussed some meetings ago, gets sufficiently written that parrot can be changed so as not to be hardcoded to grab (IIRC) SIGHUP
<Nicholas> because I'd like to heal the fork in the perl regression tests before I integrate the next version of 5.9
<Nicholas> also, I'd like a newer 5.9 release to integrate. but that's offtopic for this channel
<chip> Nicholas: I can fix that, I think, without having to rearchitect anything finally
<Nicholas> ah cool. it would be good to do so
<obra> ok. chromatic?
<Nicholas> also, I'm not sure where things got to on chromatic's autogeneration stuff for extend.c
<leo_> Nicholas: just patch parrot and disable it for now
<chromatic> I just sent p6i a proposed patch for that.
<Nicholas> but then Warnock ate it? :-(
<chromatic> I *think* it does everything the current system does now, except for preserving documentation, but I'm not sure.
<chromatic> Six minutes ago.
<Nicholas> I've not needed any more vtable calls exposed *yet*, but I the need to have one usually hits suddently
<Nicholas> OK. I think I am done now
<Nicholas> althigh I have a question for later
<chromatic> That's my report too.
<obra> chromatic: I bet you're working on the book, too.
<chromatic> You bet correctly.
<obra> Ok.
<obra> and from matt:
<obra> 11:48 <mdiep> I don't know that I'll be able to make the meeting today. but Tcl 
<obra>               is blocking on one issue: the unimplemented functions in 
<obra>               charset/unicode.src. we'd like someone to volunteer to work on 
<obra>               that, but if no one does, coke said he'll take a whack at it.
<obra> urk. poort paste job.
<pmichaud> looks fine here :-)  Which unimplemented functions?
<pmichaud> (all of them?)
<leo_> grep for UNIMP, and I've submitted some TODOs recently on p6i
<leo_> the TODOs are rather self-contained 
<leo_> like cclass for unicode
<obra> Ok.
<obra> I know patrick has questions.
<pmichaud> well, just one
<obra> Then nick
<pmichaud> but unfortunately my question swapped out for a moment, so while I'm remembering it let nick go first :)
<Nicholas> OK. This is one for chip (ish)
<Nicholas> On the perl whirl mjd wanted to talk to me about how perl does lexicals for closures, and how lisp does it, and I think how perl could learn from lisp.
<Nicholas> We didn't get time
<Nicholas> mjd is hoping that we can find time at the London Perl Workshop
<Nicholas> however, it strikes me that (apart from not being the best person he should talk to about perl 5, so I'll try to summon Dave), that this chat might also be useful for Parrot
<Nicholas> given that you're thinking about them right now
<Nicholas> I've not mentioned this parrot stuff to mjd, so the first time he learns of it might be reading the logs of this
<Nicholas> Does this thought make sense?
<Nicholas> chip: would it be useful, mjd willing, or have you already got a good grasp of how lisp does it?
* leo_ could report a few lines, like ongoing var-reg changes and removing deprecated stuff, or fixing ugly number formatting bug with PerlNums (detected on ARM only, due to obviously different double format) - but that's all ;-)
<chip> back
<Nicholas> leo_: ARM has mixed endian doubles.
<leo_> some ARMS - seems so yep
<Nicholas> totally legal IEEE. Catches out anything that thinks it can cheat
<chip> Yes, I think whatever else may be bad about Lisp, they've got conceptual clarity
<Nicholas> yes, the old soft float is mixed endian. new standard will be consistent, IIRC
<chip> Nicholas: I'll ask mjd for pointers to the bits of Lisp lexicals he finds praiseworthy
<Nicholas> cool.
<Nicholas> that's my "question" done, I think. Thanks
<pmichaud> my question is what happens if load_bytecode is executed twice on the same file -- does it actually reload the file (and re-run any @LOAD subs)?
<Nicholas> patrick - there's nowhere to hide
<pmichaud> i.e., is this something that parrot will handle or that something higher up needs to handle?
<leo_> pmichaud: this is unspecced, but I think it should be handled in core
<pmichaud> that's what I would prefer to see :)
<leo_> a test case always helps 
<chip> I agree that a redundant load should be detected ... this gets back to the UUID idea
<chip> I figured it'd be a Good Thing for each pbc to have a UUID that uniquely identifies the pbc in the universe of pbcs.  Each recompilation generates a new one.
<chip> That way we can detect redundant loads even when it's a separate copy, or on an MS-DOS filesystem, etc.
<pmichaud> it's not at all vitally important for me at the moment, I just have a module now that depends on PGE.pbc being loaded, and it'd be nice if it could simply do load_bytecode and have Parrot do the right thing
<pmichaud> the uuid idea sounds really good
<pmichaud> I'll see about writing up a test case and marking it TODO
<chip> pmichaud: thanks
<leo_> as PBC headers are under reconstruction currently, please just add this idea to it
<obra> ok. anything else up before we all part ways?
<chip> one thing
<chip> er, no, cancel
<chip> I'm done
<leo_> I got one to Nicholas 
<chromatic> My patch could use some review, as it eventually helps to remove something that blocks Nicholas sometimes.
<obra> leo_: go for it
<leo_> the mixed endian bit layout of ARM doubles - do you have an URL 
<Nicholas> er, I can't think of one offhand
<Nicholas> but it's for ARM running little endian, the (soft) floating point format was defined with the two 32 bit words laid out big endian.
<chip> is ARM like MIPS, where endianness is controlled by a pin on the chip
<leo_> and there are of course some more permutations I presume - but that helps already
<Nicholas> IIRC the rest is laid out "logically" (or at least as you would expect) for a 32 bit chip running in little endian mode
<Nicholas> chip: I don't know. It's only ARM6 and later that are switchable, and I have no idea about the actual hardware
<chip> k
<Nicholas> IIRC ARM6 is 1994 or thereabouts
<obra> Unfortunately, I need to run. I'll catch you folks later.
<Nicholas> Have fun
<leo_> Nicholas: please have a look at chromatic's patch - you are the major user of extend 
<Nicholas> OK. Will do
<leo_> thanks
* leo_ is moving to #parrot - see you
% chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net
% leo_ has left #parrotsketch
% pmichaud has left pmichaud!~chatzilla@c-24-1-26-255.hsd1.tx.comcast.net
% Nicholas has left #parrotsketch
% leo_ has joined #parrotsketch
% leo_ has left #parrotsketch