% leo has joined #parrotsketch
<obra> 'afternnoon
<leo> hi all
<chip> hi folks
<chip> I'm on a train right now, and I'll be tunneling now and in about 15
<chip> so I should report first, and if it's OK I'll also solicit questions briefly
<obra> ok. go for it
<chip> Not many here ... OK
<obra> I'll make sure folks see the log
<chip> Lexical design seems to be holding up well, albeit with the need for some more details
<chip> Closure work remains, as Leo can't quite see what I'm trying to explain.  Which may or may not be because it's an Escher drawing.  :-,
<chip> Matt shows remarkable patience in not jumping up and down screaming "NAMESPACES!"
<chip> I think that soufle' is almost done, but as Brooks quoted: "If you are made to wait, it is so we may serve you better"
% mdiep has joined #parrotsketch
<obra> As if on cue.
<mdiep> hello :-)
<chip> Unlambda provides a non-Perl, non-Tcl lexical case, btw, and Leo has pointed out to me that the design *may* need adjustment for that.  But a language expert would be welcome... especially if he arrived bearing URLs
<obra> mdiep: from chip's report just now:
<obra> 13:04 <chip> Matt shows remarkable patience in not jumping up and down screaming "NAMESPACES!"
<obra> 13:05 <chip> I think that soufle' is almost done, but as Brooks quoted: "If you are made to wait, it is so we may
<obra>              serve you better"
<obra> 1
<mdiep> heh
<leo> unlambda is converted to pdd20 closures already
% chromatic has joined #parrotsketch
<chip> And finally, my spirits are raised as I see development activity from all others
<chip> }
% chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net
% allison has joined #parrotsketch
<chip> I'm tunnelling in about 10min, so with obra's permission I'll take Qs
<chip> leo: cool, I didn't quite get that
<obra> chip: go for it.
<obra> questions for chip?
<chip> OK, all...?
<leo> DynLexPad as standard, loadable dynamic Pad?
<chip> is that the Tcl style one?
<leo> yes
<chip> Yes, it should be standard.  It's a paradigm for lexicals that isn't Tcl-specific
<leo> good
<mdiep> would :lex then create a DynLexPad and .lex create the other LexPad PMC?
% chromatic has joined #parrotsketch
<chip> No
<leo> mdiep: err yes depending on .HLL setting
<chip> lexpad type is entirely HLL-driven.  :lex is only a hack *cough* special control to make sure that a pad gets created in the absence of .lex directives
<chip> On the other hand, DynLexPad can't implement declare_lex_preg, so .lex directives are effectively illegal in any HLL that uses DynLExPad
<leo> chip: would'nt the presence of find_lex/store?lex indicate the same as :lex?
<chip> leo: no, consider   my $a; sub foo { $a }    there's no reason for foo invocations to have pads, even though the find_lex "$a" is there in its body
<leo> ok
<leo> I think that DynLexPad could still consult and use LexInfo, if it's there, which could give a mixture of compiletime-known .lex and runtime lexicals
<chip> Current design would require any HLL that might need both cases (static & dynamic lexical lists) to invent its own Lex* PMCs that, perhaps, morph
<chip> Well ... that's an interesting idea actually.
<chip> The only objective problem with it is that performance of every lookup will essentially halve, as every lookup requires "is it static" followed by "is it dynamic"
<chip> Well, there's also the whole keeping-a-reference to the register file.
<leo> yep - that's true 
<chip> but some language might want it.  OK, consider this a definite "maybe".  I fthe feature can be made to cost nothing for those who don't mix types (or as close to nothing as makes no difference), I'm open to it
<chip> It'd be nice if we could show that the Tcl compiler (or some other) could actually use it
<chip> I think I'm about 1min from leaving
<leo> but as most of the lexicals are still compiletime in tcl, performance isn't a biggy probably
<mdiep> here's a question: if I have to ask for clarification regarding a portion of a pdd, should I feel free to update it and add detail?
<chip> Sorry for this timing ... I'll read the log.  I can't stop I don't know how it works...
<chip> Please clarify if you know the answer, maybe because I said so.  Don't clarify with guesses, is all
<chip> thanks
<mdiep> okay. I have in mind to add something explicit about how the LexPad PMC tracks lexicals via register numbers.
<leo> # afk (dinner) - but still reading
<obra> ok. I'll ask leo last ;)
<obra> anything else before I start asking for more reports?
<obra> right then
<obra> matt: what's new?
<mdiep> encoding/charset issues got worked out this week
<mdiep> PGE now escapes things for us
<mdiep> but then Tcl was broken on platforms without ICU
<mdiep> so coke went through and added some logic to only create unicode strings if they actually had values outside of the ascii range
<mdiep> (or perhaps it was if the string was unicode when it was passed to us)
<mdiep> Tcl is still trying to adapt to pdd20
<mdiep> I ran out of time last week, but from what I caught in scrollback, Parrot is requiring more methods from the LexPad PMC than are detailed in the pdd
<mdiep> so I think we'll be requiring some help from leo to get this implemented correctly
<mdiep> and, of course, I'm still waiting on chip for namespaces
<mdiep> ^D
<obra> blocking on anything but that?
<mdiep> an implementation of a TclLexPad PMC or an understanding of how to make it work
<mdiep> so no
% pmichaud has joined #parrotsketch
<obra> ok.
<obra> allison?
<allison> @@ -839,6 +839,14 @@
<allison>  If you want to set this to true, you should probably also set
<allison>  C<no_whining> or at least C<no_errata_section> to true.
<allison> +=item C<< $parser->preserve_whitespace( I<SOMEVALUE> ) >>
<allison> +
<allison> +If you set this attribute to a true value, the parser will try to
<allison> +preserve whitespace in the output.  This means that such formatting
<allison> +conventions as two spaces after periods will be preserved by the parser.
<allison> +This is primarily useful for output formats that treat whitespace as
<allison> +significant (such as text or *roff, but not HTML).
<allison> +
<allison>  =back
<allison> I'm working on using TGE in Punie.
<obra> (The parser really has a 'no_whining' flag?)
<obra> How's it going?
<allison> (pardon strange cut-n-paste problem, that would be a part of Pod::Simple documentation)
<allison> no
<allison> just wipe that out of the logs :)
<obra> Sadly can't do that ;) But no worries.
<obra> Anything else exciting going on?
<allison> Right, TGE in Punie: going slower than I'd like.
<allison> Oddly, the slow part isn't transforming the abstract syntax tree, but deciding what to transform them into. That is, what node types to use, both for the high-level tree and for the opcode tree.
<allison> So, I'm just going to implement it one way and see how it works out.
<allison> (Unsurprisingly, it'll start off very Pugs-like.)
<allison> EOR
<obra> Blocking?
<allison> Parrot libraries.
<obra> Howso?
<allison> I'm about to switch TGE over to PGE's strategy of simply including all the subclasses of TGE into the top level file and manually running their :load subroutines.
<chromatic> Include path problems?
<allison> Always struck me as ugly.
<pmichaud> note that manually loading :load isn't necessary any more
<allison> Yup.
<allison> does the :load run on an include? I thought it only ran on a load_bytecode.
<pmichaud> it doesn't run on an include, but it does run when the load_bytecode loads the file that did the include
<allison> okay, that's less ugly
<pmichaud> at any rate, PGE no longer manually runs the :load subroutines
<allison> still ugly
<allison> patrick, I'll have an offline conversation with you about library installation, you may have a simple answer
<pmichaud> allison: sounds great
<allison> really EOR now
<obra> ok.
<obra> Patrick! How's the PGE world?
<pmichaud> going nicely, although this past week has been more design and documentation than implementation
<pmichaud> here's the current status: since last week I've added lookbehind, changed PGE to use the new "escape" opcode for strings instead of calling the (slower) Data::Escape library (more)
<pmichaud> change PGE to be using compreg instead of find_global for locating its various compilers, so that PGE now has PGE::P6Rule, PGE::Glob, and since Thursday we have PGE::P5Regexp
<pmichaud> oh, there's also a "PGE::P6Grammar" compiler available, which will compile a string containing an entire grammar full of rules
<pmichaud> Synopsis 5 has been updated and made publicly available, just in time for us to change all of the internal syntax again :-)
<pmichaud> (just kidding)
<obra>   heh
<pmichaud> there's a STATUS file in compilers/pge that maintains the current state of completed items and items-left-to-be-done
<obra> how close are you to being able to rope in suckers to help with todos?
<pmichaud> well, particle on #parrot is starting to help with the TODOs, and many of the TODOs are at a stage where we can live without them being done
<pmichaud> in other words, they're features we want to have eventually, but aren't immediately necessary for writing a compiler or other tools
<pmichaud> of course, if they become necessary, then it's more likely for someone to take on the TODO
<pmichaud> and the place where I expect to be doing most roping is in perl 6 parsing
<pmichaud> and code generation
<obra> *nod*
<obra> how up to date is http://svn.perl.org/perl6/doc/trunk/plans/milestones.pod ?
<pmichaud> I'd have to look at it again, will do that this week
<pmichaud> there are some obvious new things there
<obra>  *nod*
<pmichaud> lots of things in that document can now be marked "done" :-)
<obra> Cool
<pmichaud> so, there are a number of perl 6 rule items that are being tweaked, but the rules portion of pge is in a fairly stable state where I can turn my attention to other things
<pmichaud> I'll next be adding a feature or two to the shift/reduce parser, and I hope to be parsing reasonable amounts of perl 6 code by this time next week
<pmichaud> it turns out I dont' have any holiday-related commitments this week, surprisingly :-)
<chromatic> It'd probably run faster if you had Parrot parsing the code, not Patrick.
<pmichaud> chromatic:  okay, s/hope to be/hope to have parrot/
<pmichaud> but at *this* point, it's still currently faster for me to parse perl 6 code than parrot.  When Parrot is able to parse perl 6 faster than autrijus then we'll be in good shape.  I don't know that we'll ever beat Larry.  :-)
<pmichaud> (scnr)
% mdiep has left mdiep!~matt@bursley-221-209.reshall.umich.edu
<pmichaud> anyway, that's my report
<obra> very cool. blocking?
<pmichaud> not really; leo and chip seem to be staying one step ahead of me on the things I'm thinking I'll need
<obra> Fantastic
<pmichaud> I agree, it's fantastic :-)
<obra> chromatic: what's the good word?
<chromatic> I don't need the fdreopen feature quite yet.
<chromatic> I've decided just to port Parrot::Test without worrying how to support the legacy tests right now.
<pmichaud> chromatic++
% mdiep_ has joined #parrotsketch
<chromatic> Unfortunately, I broke my development server the other day and don't expect to have a lot of time to work before the holiday.
<chromatic> But I have the design of Parrot::Test in my head and it seems pretty simple... I hope to have a preliminary Test::More after a few hours of working on it.  Everything is straightforward.
<obra> cool
<chromatic> Otherwise, we could run all the tests through Leo and Chip.
<obra> maybe we could get the pugs guys to help load-balance in the off hours.
<allison> oooh, let's build a Matrix....
<obra> allison: I hear that down that road lies pain, suffering and an earth ruled by machines.
<chromatic> No, just multidimensional array access.
<obra> Ok.
<obra> anything else? anyone I've missed?
<obra> Woot! We finished five minutes early.
<allison> digging around, my library problem turned out to be simpler than I thought, I just need to get TGE included in the make install for parrot and it'll dissapear.
<obra> Good thing nick and autrijus were off ;)
<leo> wait a bit
<allison> (but I can wait on that)
* leo reporting ;-)
<leo> (Unless you're evil, or Damian.
<leo> oops
<leo> - finished lexicals according to specs
<obra> oops. hi leo. sorry
<obra> hi
<obra> Right. what's new?
<leo> - converted unlambda interpreter to new style closures - works fine - nb: unl.pir used :outer in a sense that in pdd20 is: "(Unless you're evil, or Damian. ..."
<leo> - ongoing unicode improvements + string code cleanup
<leo> - implemented 'compose' (using NFC)
<leo> - and as some distraction improved sudoku solver algorithm
<leo> and finally:
<leo> I see a substantial speedup of Parrot dev according to ci'ed revs (~150/week)
<leo> EOR
<obra> blocking?
<leo> not yet ;-)
<leo> but need more pdds soon
<obra> ok
<obra> what's next on stack?
<leo> first the DynLexPad to please tcl and other folks
<leo> then we should probably attack named argument passing
<chip> (post-tunnel hi)
<leo> it's needed for all possible object creation
<leo> rehi
<pmichaud> leo: yes, named argument passing is very likely to be my next block
<leo> see one line above
% chromatic has left #parrotsketch
<chip> this is weird, the meeting just tailed off?
<pmichaud> seems so
<leo> chip: 20:03 < leo> then we should probably attack named argument passing
<chip> I saw
<obra> Chip: sorry. I didn't actually say "ok. thanks everybody" (I got called away)
% pmichaud has left #parrotsketch
% mdiep_ is now known as mdiep
% allison has left allison!~allison@sub17-30.member.dsl-only.net