% vsoni has joined #parrotsketch
% particle_ is now known as particle
% coke has joined #parrotsketch
% coke is now known as Coke
% mdiep has joined #parrotsketch
% der_leo has joined #parrotsketch
% der_leo is now known as leo_
<tewk> I'm not going to make parrot sketch.
<tewk> Quick status
<tewk> Starting to implement blocks and function calls in Cardinal
<obra> (Hi, I'll replya)
<obra> replay, even
<tewk> Working on a patch to add '_dump' to PGE::CodeString
<tewk> Added preliminiary Javascript and Python PGE grammars to svn.  vsoni and particle are planning on helping out with the JS compile once The Great TGE Refactor is completed.
<tewk> No major blocking points.
<obra> Having fun?
<tewk> Would like to explore object system implementation on top of parrot with others on the list.  Especially Meta-object protocols and interop.
<tewk> obra: Having a lot of fun.  I love compiler
% woggle has joined #parrotsketch
<obra>  Excellent
<tewk> Gotta run
<obra> Later
% allison has joined #parrotsketch
<obra> Hey allison.
<allison> hi
<obra> Parrot sketch roll call?
<mdiep> here
<leo_> hi all
<woggle> Hi.
<chip> here, but must run for 5-10min, sorry.  brb asap
<mdiep> patrick said he couldn't make it today
<Coke> here.
<obra> Tewk had to report early and vanish. I'll start with him. Then I'll pick on...coke, then mdiep, then woggle, then leo, then chip and finally allison
<obra> and then whomever I failed to list ;)
<obra> 13:51 <tewk> I'm not going to make parrot sketch.
<obra> 13:51 <tewk> Quick status
<obra> 13:51 <tewk> Starting to implement blocks and function calls in Cardinal
<obra> 13:52 <tewk> Working on a patch to add '_dump' to PGE::CodeString
<obra> 13:54 <tewk> Added preliminiary Javascript and Python PGE grammars to svn.  vsoni and
<obra>           particle are planning on helping out with the JS compile once The Great TGE
<obra>           Refactor is completed.
<obra> 13:55 <tewk> No major blocking points.
<obra> 13:56 <tewk> Would like to explore object system implementation on top of parrot with others
<obra>           on the list.  Especially Meta-object protocols and interop.
<obra> 13:56 <tewk> obra: Having a lot of fun.  I love compiler
<obra> 1
<obra> That's it. except for a truncated "s" ;)
<obra> questions for Tewk should go to mail. 
<obra> Coke. How's it going?
<Coke> - I switched to svk.
<Coke> - more progress with the testing suite. most of our internal tests are now
<Coke>   pure tcl
<Coke> - tcl code of a certain size has very bad performance, think it's 
<Coke>   related to the register allocator: trying to work around things in tcl   for now.
<Coke> - using pure tcl for the tcl tests, we're at about 1.7% of the tcl 
<Coke>   test suite. Down from our previous high of... what, 10% of the
<Coke>   converted tests, but there are a lot of tests passing not counted here
<Coke>   due to the issues with "large" tcl files, and some random bugs that 
<Coke>   abort processing mid-test. Expect this number to go up each week... 
<Coke>   for a while, anyway. For now, due mainly to improvements in the test suite
<Coke>   that let things that already work show as working. =-)
<Coke> - current annoyance: splice isn't universally usable. Need to open a ticket.
<Coke>   (this would basically give us [lreplace])
<Coke> return
<obra>  Blocking?
<Coke> no, no blocking. list_splice is annoying, could use some help with the allocator, but all in all, rolling forward.
<obra> Cool
<obra> mdiep?
<mdiep>  - Moved across the country
<mdiep>  - Partially fixed Tcl's "can't set self from this type" error
<mdiep>  - A handful of command fixes
<mdiep>  - Started to look at PGE's OpTable implementation a little
<mdiep>  - Occasionally experiencing a GC error that's still hiding in there
<mdiep> having fun... mostly. the GC error and some other parrot issues have been annoying though
<mdiep> ^D
<obra> woggle: you around?
<woggle> Yep.
<obra> What's exciting in your world?
<woggle> * Found and fixed some bugs/memory leaks in STM.
<woggle> * Made dynoplibs work with threads (for some senses of work)
<woggle> * Relatively unproductively looked at STM performance issues. (Profilers say that most of the time is spent in DOD in my benchmarks.)
<woggle> Currently, I'd like to try to get more STM test cases under the assumption there are bugs.
<obra> Is there a way to rope other folks into that?
<woggle> Don't know, really.
<obra> Are tehre things that newbies could help with? (Note that I don't actually have a box of useful newbies handy)
<woggle> I can't think of anything in particular. I hae most of the simplish tests done. And I'm most worried about whether I'm using more memory than I should be at the moment.
<obra> *nod*
<obra> ok.
<woggle> Uh, EOR.
<obra> leo_: you ready?
<leo_> * tested current state of exit_handlers aka END {} blocks
<leo_> * fixed freeze/thaw bug related to multiple hashes in one structure
<leo_> * tested Parrot on:  - x86_64 (static/dynamic)  - x86_64 -m32 (static/dynamic) and w/ JIT - solaris10 gcc4 and sun cc - darwin ppc 7.9.0 
<leo_> * currently investigating Bob's excellent analysis and POC of runloops + Continuations
<leo_> ETOOLESSTIMEFORMOREPARROTHACKING
<leo_> ^D
<obra> chip: you back?
<chip> yes!
<obra> Great!
<obra> What's up?!
<chip>  * prepared for 0.4.6
<chip>     > won't be able to merge stm, as the release is already late
<chip>     > immediately after release, hoping to merge woggle's current work
<chip>  * resolved all the core dump tickets
<chip>     > one was a real bug, which attempted a malloc(0)
<chip>     > the rest were TODOs (or hopelessly obsolete JAPHs)
<chip>  * very happy to see language progress, esp. in Tcl (mdiep++) and cardinal (tewk++)
<chip> plus I've done a lot of RT playing.
<chip> ^Z
<chip> um,
<chip> actualy, I also restored arrays to all the namespace/global opcodes and got rid of the methods (again),  allison++ for letting me rescind that
<chip> also, I fixed the handling of keys as parameters to opcodes, so now opcodes can tell the difference between   foo P0, ['a']  and  foo P0['a']
<chip> ^Z for real
<obra> allison: you're up
<allison> I released a partial version of PDD17. Little feedback, I think I picked an entirely non-controversial PDD to kick things off. :)
<allison> I'm discovering that working on nothing but design is demotivational. For the moment I've got the startup natural language project as a practical parrot project, but once I wrap that up I'll need to find another.
<allison> EOR
<allison> (I'm listening in on another conference call at the same time.)
<obra> (More punie hacking?)
<obra> particle: you ready?
<chip> ("working on nothing but design is demotivational" ... now she tells me.  :-))
<allison> obra: yeah, but patrick asked me to hold off on punie until he finishes some of the TGE refactors
<particle> this has been a light week for parrot work: 
<particle> ~ helped tewk with javascript parser grammar 
<particle> ~ some cleanup in prep for the release 
<particle> ~ thinking about testing tools for the compiler toolsuite 
<particle> ~ small perl6 parser mods 
<particle> ~ learning more about p6p6 and p6p5 efforts 
<particle> ~i had an interesting conversation in #perl6 about designing tests for use by multiple language implementations.
<particle> specifically, what todo() information would look like, and where it should go;
<particle> it's a tough problem, because there's a lot of pain, and it has to be shared somehow.
<particle> i think that as far as shared (perl6, pge, etc.) tests go, we're testing the specification, and implementation details should not exist in the test (let's limit it to todo() info for now)
<particle> others think that keeping todo info directly with the test is critical. (i can't fully disagree)
<particle> but that's troublesome, since it's multiplied by n implementations, requiring (imo) unnecessary test suite changes.
<particle> my main concern wasn't addressed to my satisfaction, but i can live with the result.
<particle> which is (todo will live with tests)
<particle> related to that, larry made a small spec change for unspace parsing which allows C<<< ok( <<'CODE', <<'OUTPUT', \n 'really long description', \n :multiple<options> :like<this> ); >>> which will help keep test files neat
<particle> (in perl5, the newline would immediately start the first heredoc, which forces test headers like this to be on one really long line. yuck.)
% chromatic has joined #parrotsketch
<particle> hrmm, that didn't come out right
<obra>  send it in mail so more folks see it :)
<particle> the code should read with trailing backslashes
<particle> i'll post the list, yes.
<obra> Cool
<particle> .end
<obra> chromatic: you're just in time.
<obra> What's new?
<obra> How's real-world parrot?
<chromatic> Installation is kind of a pain.
<chromatic> I'm not sure if it's the installation target or path issues when using PBCs in the tree.
<chromatic> Allison and I will track it down and figure out what to do.
<chromatic> Otherwise, I found and reported a test failure.  I'm also adding cond support to Pheme; it's taking a bit.
<chromatic> That's it by the way.
<obra> Cool.
<obra> anyone I missed?
<obra> vsoni: are you around?
* mdiep has a couple questions when it's that time
<obra> who else has questions?
<obra> ok. mdiep go for it
<mdiep> the reason tcl doesn't use exception handlers for argument mismatches inside subs is that you can't use .param -- you have to use get_params
<mdiep> is that likely to change? anytime soon?
<leo_> it's probably just a small parser patch
<chip> hrm.
<chip> agreed with leo, this is probalby just a small change.
<mdiep> okay. I'll file a ticket then
<chip> would you mind a ".entry" directive to tell the compiler that the label in question may be called like a sub?
* chip would like to avoid allowing .param after just any label
<allison> we're wandering into the territory of wanting to be able to define subs within subs
<leo_> it's not a label - it's push_eh / .param / .param ...
<mdiep> second... is there any reason I can't use the morph vtable function inside assign_pmc to change a ResizablePMCArray into a String?
<mdiep> leo_ has it right
<chip> push_eh label .... label: .param .parm     <- what I thought
<leo_> that is we have to define .param_section with an optional push_eh before .param
<chip> oh!  that case
<chip> OK
<allison> mdiep, when you submit the ticket, include some code examples
<leo_> mdiep: as said several times, it's up tor your PMCs what to do with assign / morh
* chip defers to leo on the morph question
<leo_> morph even
<chip> (thought so :-))
<chip> it's up to you to define init/morph/assign as you like, and if you switch your vtable, presto
<mdiep> I forgot morph existed until just a few minutes ago. I wondered if there was a reason someone didn't explicitly tell me to use morph :-)
<leo_> you still have to write *your* morph code
<Coke> pretty sure tcl is already using morph for 3 of its types.
<chip> mdiep: in the future, -if- PMCs get variable-sized heads [which could happen], then both the source and dest types will have to cooperate to ensure, or else be known for sure, that they fit into the memory allocated.
<mdiep> morph is pretty much one call to pmc_reuse
<Coke> only reason it's not doing it for list is that the Perl* code I culted from didn't. =-)
<mdiep> (this suddenly all looks much easier)
<Coke> mdiep: but if you do it now, then when chip changes it, *he'll* have to fix it. =-)
<leo_> mdiep: that's just the internals, which might change as chip has said
<mdiep> Coke: exactly! :-)
<chip> Coke-- # you weren't supposed to tell him that!
<obra> ok. more questions?
* mdiep has to run now
<leo_> I got to to allison 
<leo_> one
<obra>    ok. go
<leo_> any thoughts re Continuations and inferior runloops:  Analysis and POC
<allison> let me pull up that message
<leo_> basically: are tendencies towards:    1.  Restrict continuations to move only "outward" or    2.  Eliminate inferior runloops. ?
<allison> I'm leaning toward eliminating inferior runloops
<chromatic> Is there a possibility of 3. Use Parrot calling conventions for all internal C calls.
<chromatic> ?
<chip> I like that too.  stackless yay
<allison> but, I think we need to spend more time on it
<particle> stackless++
<chip> yeah, I'd like to understand the implications before OKing it.  And I'd like to merge STM too :-)
<allison> yes
<leo_> stackless and calling conv changes is basically the option 2) AFAIK
<allison> yup
<allison> I'll respond to Bob's latest message
<leo_> ok - thanks
<obra>   anytone have anything else this week?
<leo_> chip: what's the timetable for release and STM merge?
<chip> today is release.
<leo_> woot
<allison> yay!
<chip> STM merge is, say, Wednesday; before next week anyway, woggle's time & attention permitting
<leo_> great
<obra> ok. unless someone pipes up in the next 30 second, I'll see y'all next week
<allison> thanks jesse, see ya'
<leo_> see ya and thanks jesse
<chip> ciao
% chromatic has left #parrotsketch
% allison has left #parrotsketch
% leo_ has left leo_!lt@feather.perl6.nl
% leo_ has joined #parrotsketch
% Coke has left #parrotsketch
% smash has left #parrotsketch