% Nicholas has left #parrotsketch
% mdiep has joined #parrotsketch
% chromatic has joined #parrotsketch
<chip> here, then gone, then here again
<obra>  nice and descriptive ;)
% pmichaud has joined #parrotsketch
<chip> here again!
<chip> howy
<obra> Excellent.
<chip> howdy even
% Coke has joined #parrotsketch
<obra> we'll give the rest of everyone a couple more minutes to appear
<particle> hi all
<obra> folks should start to compose reports if they haven't yet ;)
* pmichaud <-- composed
<obra> chip: do you know if allison is around today?
<obra>   er. "chromatic"
<obra> damn nick completion
<chromatic> No idea.
<leo_> hi @all
<obra> Ok.
<obra> Let's get rolling
* chip tumbles across the mat
<Coke> ... alone or in pairs?
<obra> I think I'll start in order people piped up. 
<obra> So, today, chip, particle, pmichaud, chromatic, leo_ , coke, mdiep, tewk if he's here, allison.
<chip> Last week:
<chip>   * real life had high priority, but is now relaxed again (nothing tragic)
<chip>   * approved STM merge (woggle++ for good work)
<chip>   * engaged in good-natured bickering about code formatting
<chip>   * investigated C99
<chip>      - we can't use the language features yet (MSVC is the main spoiler)
<chip>      - the header/macro/library features are mostly redundant with Configure
<chip> Coming week:
<chip>   * write new pdd07 (code formatting)
<chip>   * make & keep Parrot compilable as C++, for integration with C++ systems
<chip>      - learning from the PERL_OBJECT feature of Perl 5
<chip>   * plus, the balance of last week's list:
<chip>      - resolve default packfile question (per chromatic)
<chip>      - review leo's PMC reorg proposal
<chip>      - Items from OSCON meeting w/Allison
<chip>      - Perhaps start on exceptions & dynamic scoping;
<chip>         these share a lot of concepts, and perhaps infrastructure
* chip is particularly disappointed in MSVC vs. C99
<chip> ^D
<obra> particle: you're up
<particle> ~ been modifying perl6 and pge to deal with synopsis changes
<particle> ~ thinking about test suite design: unique id's, pugs's smartlinks, etc
<particle> ~ there is some code and ideas to reuse, some to write
<particle> ~ i'll soon be starting a perldoc (pod, kwid) parser/emitter
<particle> ~ this will help link parrot & perl6 tests to the specs
<particle> .end
<pmichaud> * A week of improving tests (and, unfortunately, dealing with a local OS crash)
<pmichaud> * Worked with Coke++ to speed up PGE's p6 regex test suite
<pmichaud> * In the process, found four tests that were inadvertently being skipped,- fixed those
<pmichaud> * Added a 'dump_str' option to PGE/Dumper.pir for above
<pmichaud> * Worked with mdiep++ and Coke++ to create a pge-based grammar for parsing Tcl
<pmichaud> * Answered various other questions about PGE and parsing on #parrot
<pmichaud> * Continued work on PGE improvements and TGE refactor.  It's going slower than I had hoped, but I expect to have something public RSN.
<pmichaud> <commit>
<obra> chromatic: you're up
<chromatic> I checked in the library path patch.
<chromatic> If addressing Francois' concerns about Parrot::Embed fixes the build on Win32, I'll check it in.  (Jerry?)
<chromatic> I fixed a couple of skip tests and ranted about the state of others.
<chromatic> I hope to write more about the external API soon.
<chromatic> END
<obra> leo_: go for it
<leo_> * simple looking tickets like "[perl #40178] None Must Die" are possibly very untrivially to implement, as there are no specs for the *true* replacement
<leo_> * resolved it, nethertheless
<leo_> * did some tcl debugging ... and a debug trace fix
<leo_> * and some partcl coding (http://feather.perl6.nl/~lt/upvar.pir) - this are some experiments about lexical vars and [upvar]
<leo_> * various bug fixes and docu updates
<leo_> * started digging into STM guts, woggle promptly added 2 more docs (internals and howto)
<leo_> * strace'd --tracing parrot, which showed 2 fsync calls from unneeded fflush getting rid of these got 10x tracing speed
<leo_> Next week I'll hopefully be in Birmingham, Heathrow willing.
<leo_> ^D
<obra> Coke: your turn
<Coke> * partcl
<Coke>   - begin utilization of tcl's stdlib with [parray]
<Coke>   - add $tcl_library
<Coke>   - add $tcl_platform(byteOrder) and $tcl_platform(platform)
<Coke>   - #40143 - add $tcl_precision (mostly)
<Coke>   - add $tcl_interactive (when false)
<Coke>   - add dynamic ops for various tcl flow control macros
<Coke>   - add simplistic version of [regsub]
<Coke>   - add [lsort -real]
<Coke>   - add [open $file w]
<Coke>   - tcl test suite
<Coke>     + native passing %age falling. each fix in one spot seems
<Coke>       to cause segfaults or other errors elsewhere. :(
<Coke> * PGE
<Coke>   - working on converting t/compilers/pge/p6regex/01-regex.t to
<Coke>     PIR mostly done, need to integrate pmichaud' checkin earlier
<Coke>     for dump_str. Currently at 10s, down from 2m33s.  Should be
<Coke>     usable as a template to convert other pge tests. Incorporating
<Coke>     the idea of softlinks from
<Coke>     http://pugs.blogs.com/pugs/2006/08/integrating_the.html, thanks
<Coke>     to particle++
<Coke> * Cage
<Coke>   - annoy leo++ with various compiler warnings, and even fix some
<Coke>     myself.  originally looking for more c89 compliance.
<Coke>   - silence build errors by cc_flags.pl
<Coke>   - add docs for genfile() (part of Configure)
<Coke> * RT
<Coke>   - #40207, #40162 - patches courtesy amir dot aharoni at gmail dot com
<Coke>   - #38897 - makefiles ending in / are bad, mmkay?
% ambs has joined #parrotsketch
<Coke> </ul>
<obra> mdiep: how's things?
<mdiep>  - Made a couple changes to the default PMC to facilitate Tcl:
<mdiep>    - Add a morph implementation that morphs the PMC
<mdiep>    - Changed assign_pmc to morph to Undef if assigned an Undef
<mdiep>  - Fixed some Unicode issues
<mdiep>  - Got morphing working once and for all
<mdiep>  - Worked on PGE-ification of Tcl (almost done with first pass)
<mdiep> ^D
<obra> tewk: you around?
<obra> looks like not
<obra> and no allison
<obra> ok. Question time. I have one. who else?
<obra> (Did I miss anyone?)
* chip 
* leo_ 
<obra> Ok. So. What, that's not already being done, could help make parrot and perl6 on parrot happen faster, better, less painfully, more robustly, etc?
<obra> blue sky.
<chromatic> It would be nice to know what's working and what isn't.
<obra> for the moment, don't worry about budget or feasibility
<chip> Isn't there a tool for code duplication detection?
<Coke> yes.
<chip> And that Coverity tool that the kernel guys love
<chip> Running those against hte source would be Helpful
<pmichaud> I recognize that I'm probably the perl6/parrot bottleneck at the moment
<Coke> finding duplicate code is http://pmd.sourceforge.net/cpd.html
<particle> more awareness of smokes, and more platforms submitting them
<mdiep> better parsing for IMCC (meaning better errors, among other things)
<chromatic> More tests.
<chip> I would love to have a Purify license, or an Insure++ license if Purify is not available
<Coke> more followthrough on the promise of CAGE.
<particle> i think a smokebot on #parrot would help
<obra> pmichaud: assuming that, what could help un bottleneck you?
<pmichaud> for perl6/parrot there are just about 3 or 4 things that need to be designed/implemented at roughly the same time, and I'm having to slog through it
<pmichaud> I'm not finding easy small commit points
<leo_> pmichaud: short-term branch?
<particle> pm: i'm willing to help with design, if you pipe up about it :)
<obra> Could you enlist another designer to handle one of them or would that ruin your fun?
<pmichaud> obra: I think it'd ruin some of my fun :-)
<pmichaud> the pieces all tie together pretty intimately (pge, variables, namespaces, tge, and perl6)
<Coke> purify++ : an excellent idea.
<obra> Ok. Is there grunt-work research or dev spikes others could do for you?
<particle> perhaps a pge pdd draft would facilitate comments/suggestions?
<pmichaud> I haven't come up with anything.  But I think I should be able to break through the bottleneck this week
<pmichaud> ah, a pge pdd draft would be excellent
<pmichaud> if someone else could write it :-)
<particle> i'll think seriously about that.
<obra> chip: have you played with valgrind? I hear it's the new purify ;)
<chip> valgrind is good but AFAIK it lacks the deep evil
<obra> ok
<chip> Purify actually rewrites the object code so that every memory access can be checked, not depending on magic values or canaries
<pmichaud> If I don't have something substantial to delegate by next week, then I'll come to parrotsketch w/ideas
<chip> mind you, if I didn't have valgrind I'd be even more desperate
<obra> *nod*
<obra> ok. 
<obra> any other things people could use?
<chromatic> Improved TGE would help me.
<Coke> more speed.
<chip> yes, and the Parrot::Embed module could help
<particle> coverage tools
<Coke> (yes, yes, tcl is slow on it's one. *thbbbthp*)
<chip> I'd like a "make test" that uses embedded Parrot
<obra> Coke: It's the policy of TPF not to supply drugs stronger than caffeine to developers
<Coke> ... "its own" (wow)
<Coke> *snrk*
<chromatic> Knowing what features work and are in line with specs would help me beat the features that don't and aren't.
<particle> windows c developers
<leo_> faster proposal review ;)
<chip> particle++ # Windows shouldn't so poorly represented
<chip> leo_: it's a fair cop, but society's to blame
<chromatic> Wow, talk about blue sky.
<obra> Ok. anything else before we move on?
<Coke> about this caffiene. can we ship a case of something to chip?
% smash has joined #parrotsketch
<obra> ok. next chip, then leo.
<Coke> thank you. that is all.
<obra> chip: what's your question?
<chip> The removal of None is a good thing I'm still sure, but I wonder if there is anything left broken still as a result, and if so, is there anything I can do to help fix it?
<chip> ... I'll take that as a 'no'
<chip> good
<obra> ok
<obra> leo
<leo_> there's no problem with the None removal, but it revealed the lack of specs re STRING NULLs
<chip> oh boy yes
<pmichaud> At the moment the None remove works only because get_string_keyed on hash was coded to return ''
<leo_> or generally about the return value of (mainly) aggregate PMCs
<chip> for now it seems that a null string is mostly like a perl undef; it acts like a '' but you can test for it
<chip> this may be a good model
<leo_> pmichaud: yep - and that (maybe) workaround
<pmichaud> I'm planning to update PGE to eliminate reliance on that (but I still think that returning '' for get_string_keyed is a reasonable answer)
<pmichaud> iirc there are only five places that have to be fixed
<chip> pmichaud: or if null strings become perl5-undef-like, returning null would not hurt you either, I guess
<leo_> the better question actually is: what is a STRING*
<pmichaud> as long as   things like    $S1 = concat $S0, "foo"   works when $S0 is null, it's okay with me :-)
<chip> leo_: oh, don't go there, please.  we know you think STRING isa PMC someday :-)
<chip> I don't necessarily disagree btw
<chip> FSVO 'someday'
* particle finds string/pmc conversions frustrating, too
<leo_> fine ;)
<chromatic> That wouldn't necessarily hurt the external API's feelings either.
<chip> hm
<chip> really?  and the opcode proliferation really sucks
<chip> huh
<particle> concat_s_i doesn't exist. concat_p_i does.
% ambs has left ambs!~ambs@213.13.107.188
<chip> huh
<pmichaud> as long as there's a way for me to have a generic String object/role that encompasses all of the string representations, I'd be okay
<mdiep> fwiw, I think STRING currently corresponds to Perl 6's native string type
<leo_> particle: concat_p_i ???
<particle> $P0 .= $I0
<pmichaud> i.e.,  having separate   UnicodeString and ASCIIString classes doesn't quite work well
<particle> leo: for code emitters
<leo_> please paste a working example
<chip> mdiep: actually it doesn't, not really; Perl 6's native 'str' is supposed to be a lot stupider than a Parrot STRING
<chip> pmichaud: I'm totally with you on the "one class to bring them all and in the darkness encode them"
<chromatic> Having a separate string register is still somewhat useful though... or more pervasive MMD.
<pmichaud> Perl 6 doesn't have a native 'str' anymore, it's now 'buf'  :-)
<chip> pmichaud: oh.  that's ... good?  whatever.  :-)
<leo_> and that is what a Parrot S reg actually could be - an interface to str* libc functions
<pmichaud> chip: yeah, I can't quite keep up with it either
<chip> chromatic: opcode bifurcation is part of the solution, and MMD on a String class is the rest, I think, fo rthat problem
<pmichaud> there's another aspect to this, btw
<chip> leo_: byte buffer registers ... ?
<leo_> when we can do 'add Px, Py, Pz' with full MMD - why tf* we can't do that for strings?
<pmichaud> currently I can do   $S0 = 'foo'()   and know that I'll get the stringification of whatever comes back
<leo_> chip: cstrings
<particle> leo: do this to a string, instead...     print "[" 
<particle>     print $I0
<particle>     print "] => "
<pmichaud> I can't do that with $P0 = 'foo'()
<chip> pmichaud: that is convenient to be sure.  But the solution would depend on what you're doing.  If the next step is print or append or something, the stringification is implicit in the operation.   Otherwise, $P0 = 'foo'() can be followed with $P0 = $P0.'as_string'(), which may NOP
<chromatic> Or merge MMD with opcodes.
<chromatic> Wait, how blue is the sky right now?
<leo_> particle: concat is MMD, it nicely works with .Integer RHS PMCs
<chip> chromatic: there is another theory which states this has already occurred.
<chip> chromatic: (some 'opcodes' are already MMD sugar)
<chromatic> "some"
<obra> (should this discussion keep going here?)
<particle> leo: precisely. pmc's concat nicely, strings do not. this seems broken to me.
<obra> Failing a resounding yes, anyone got anything else questionwise?
<chip> obra: well, I think we've covered the idea space & the surface issues.  I vote 'move on'
<chip> but only gently
<particle> c: i owe you a look at your latest parrot::embed patch. will do.
<chromatic> Barring the problem Francois found with $ENV{PATH} (as in, there's a one-line File::Spec->path()) replacement, how does it work?
<particle> i'll have to let you know, i haven't applied yet
<obra> Ok. about to declare the meeting over
<leo_> chip: you have some initial comments re pddXX_pmc.pod already?
<obra> The tyranny has ENDED
<chip> leo_: I cannot tell a lie.  ...  look, a huge distracting thing!
* particle looks
<chip> chromatic: #parrot pls
<leo_> particle: it's not in svn
<particle> hey, it's really bright and blinking!
<particle> see you all next week!
<chip> cya
<leo_> see ya or not next week ;)
% chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net
% smash has left #parrotsketch
% Coke has left #parrotsketch
% pmichaud has left #parrotsketch
% mdiep has left mdiep!~matt@pool-71-115-179-176.gdrpmi.dsl-w.verizon.net
% mdiep has joined #parrotsketch
% mdiep has left mdiep!~matt@pool-71-115-179-176.gdrpmi.dsl-w.verizon.net
% mdiep has joined #parrotsketch
% mdiep has left mdiep!~matt@pool-71-115-179-176.gdrpmi.dsl-w.verizon.net