Vision for 2.0: Production Users | Priority for 1.6: Merge Branches | Priority for this week: get PCC branch mergable, increase test coverage on CallSignature PMC | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
Set by moderator on 6 October 2009.
06:19 cotto joined 06:43 cotto joined 14:08 particle joined 15:34 mikehh joined 15:49 darbelo joined 16:04 Coke joined
Coke ONE: 16:18
- parrot - slow progress on RT queue. - documented manual update process for docs.parrot.org
- stir up some PLATFORM updates
- partcl
- eliminate toInteger multi, use get_integer VTABLE instead.
- minor fixups to mathop.test
- partcl.blogspot.com/2009/10/partcl-...tests.html
- track changes post PCC merge.
BLOCKERS (a.k.a. segfaults)
- Segfaults: TT #1131, #1136
- Misc: TT #996, #910, #721
- Can't build partcl against an uninstalled parrot
COMING:
- move from TGE/PGE to nqp-rx (pmichaud++) as a guinea pig
s/^ONE/DONE/ && eor.
16:54 mikehh joined
Tene ohright, PS today 16:54
The girlfriend has been visiting for the past week; consequently, I haven't touched Parrot since. Maybe I need to reexamine my priorities. 16:55
Oh, wait, no... I fixed lolcode a bit. It still doesn't install, but at least it builds and passes tests. 16:56
16:58 whiteknight joined 17:02 mikehh joined 17:06 Util joined
japhb DONE: 17:07
* Mostly it was my turn to be sick this week. :-(
* Improve validation of metadata
* Refactoring and function documentation
* Much improved Makefile (with automatic Makefile rebuilding)
WIP:
* import_proto.p6 (Import proto-managed projects into Plumage metadata)
* Analyzing discussion surrounding major CPAN META spec upgrade (which is in design phase)
MAD PROPZ: 17:08
* darbelo++ # Plumage's NQP configure brought to other projects
* Austin++ # Makefile education
NEXT UP:
* Be less sick
BLOCKERS:
* import_proto.p6 blocking on proto's installed-modules branch
EOR
darbelo THE PAST: 17:15
* Matrixy infrastructure work.
* Parrot-linear-algebra infrastructure work.
* Added support for Configure.nqp to plumage projects.
* Removed src/gc/res_lea.c and the las traces of the 'malloc' gc.
* Folded 'make install-dev' into 'make install'. Badly. thanks to pmichaud++ for fixing that. 17:16
THE FUTURE:
* Exams. Lots of 'em.
* Maybe some light parrot hacking.
BLOCKERS:
* Exams. Lots of 'em. Will probably consume all available tuits.
EOR.
q2q 17:17
17:46 particle joined 17:51 mikehh joined 18:00 pmichaud_ joined
pmichaud_ What I did: 18:01
* Practically nothing at all for the Rakudo "Thousand Oaks" release (PerlJam++)
* More work on nqp-rx.
* Enable multiple bindings in subrule captures <abc=def=subrule>
* Improved quote handling and escapes in quotations, including customizable escapes.
* Added word-splitting form of quotes.
* Added debug tracing and table dumping capabilities to the regex engine.
* Updated protoregexes to understand token prefixes, including transitive token prefixes.
* Added <?MARKER> and <?MARKED> builtins to make it easy to keep track of end-of-statement, whitespace, etc.
* Added most statement constructs and operators to nqp-rx.
* Added lexical subs, with various parameter forms. Also now allows default expressions.
* Had a long discussion about 'fetch' and 'vivify' opcodes on #parrot, looking forward to being able to use those opcodes.
What I'm doing this week:
* Adding contextual variables to nqp-rx
* Adding regexes and grammars to nqp
* Completing new NQP implementation, including bootstrap
* Starting a new Rakudo branch to switch to nqp-rx based grammar
* Implementing a demonstration language (e.g. abc or squaak) using nqp-rx, including a basic tutorial
What I'm blocking on:
* Available time.
EOR
Q1Q 18:02
mikehh What I did in the last week: 18:06
* building and testing parrot - fixing codetest errors etc.
* started fixing a couple of tests
* started looking to see if rakudo/tools/autounfudge.pl can be adapted to parrot
* - the main problem being that there seem to be no standard way tests are skipped in parrot
* - I found at least three different ways
* looking at g++ 4.4.1 build failures
* - seems to be related to different strchr definitions in string.h
What I intend to do in the next week:
* testing and fixing
* continue working on checking skipped tests
.eor
18:11 whiteknight joined 18:12 NotFound joined 18:15 chromatic joined 18:16 jonathan joined
chromatic I: fixed a few bugs, made several optimizations (with bacek). 18:19
I: am working on experimental fetch opcodes for pmichaud.
I: will work on STRINGNULL, the opcodes, some optimizations, and perhaps some struct removal. 18:20
I: might fix bugs in the extension calls, if someone else writes tests for them.
I: am blocking on fixing bugs in line numbering, waiting for japhb to extract some tests.
japhb oh d'oh!
allison Last week: 18:24
- Merged the PCC branch into trunk after the 1.7 release.
- Added a single extend/embed function Parrot_ext_call for calling Parrot subs and methods. Added deprecation notices for the old API functions it replaces.
- Did some work on removing old calling conventions code, more to be done there.
- Released a new version of Pod::Simple (we should think about removing the ancient version we ship with Parrot).
- Started playing with CPython's parser.
Next week:
- Removing up old calling conventions code.
- Pynie
- Scan ticket queue for those needing design decisions
- Open to requests
EOR
Util # Done
* Attended Southeast User Group Leader Summit, brought to Atlanta by Microsoft and O'Reilly Media. Time well spent.
* Edited [S32/*], correcting 38 problems.
* Wrote beginning of Subs chapter for #perl6book. 18:25
* Moved TT#600 (Bytecode testing framework) and TT#606 (Prune C data structures) from 1.7 milestones to 1.8.
* Read clang.llvm.org/diagnostics.html , and drooled over the thought of Perl 6 providing that level of diags.
# Plan for next week:
* Probably finish the chapter, then un-stall the tasks from the last 3 weeks.
# Blockers:
* Intermittent connectivity.
.end
jonathan Rakudo/Parrot
* Been working on getting Rakudo compiling under trunk again, using the calling conventions updates
* Just about ready to merge that now
* Patched a couple of things in Parrot along the way (actually, mostly did bad patches, which caused other people to do better ones in their place - thanks!)
* We take a relatively minor runtime performance hit on the benchmarks in tools/benchmark.pl (10%-15%)
* However, I didn't really do the changes (e.g. using :call_sig) to take advantage of the PCC changes properly yet, so I am hopeful I can win that back, or most of it
* Parsing/compilation seems way, way slower now though, which does hurt a good bit on the spectest run times
* Set up KCacheGrind and played with the new Parrot profiler for the first time. Impressed - it's going to tell us Useful Stuff
Conferences
* Spoke at Italian Perl Workshop - got a decent response
Blockers
* None really, and I've no travel plans for the next month
Worries 18:26
* Content and CallSignature merge worries me a bit; I'm willing to shut up if I know somebody else will do the patches to make Rakudo run and pass all of its tests on top of it though.
.end
whiteknight WHAT I DID LAST WEEK
(parrot) Talked with chromatic about some GC changes. Looking at my notes. Have high hopes for a new algorithm.
(parrot) Some modest improvements to the fixed-size allocator
(parrot) Replaced calls to Parrot_PCCINVOKE (deprecated) with calls to Parrot_pcc_invoke_method_from_c_args.
(parrot) Added prototype for :call_sig with tests that demonstrate it's use. Very limited.
(parrot) Started work on a prototype load_bytecode op that would return an Eval PMC.
(matrixy) Some record keeping for Matrixy (docs mostly). Updating links to point to github
(pla) Created a new NumMatrix2D PMC type for parrot-linear-algebra. Bare-bones now, but a good framework to add BLAS bindings.
(pla) Parrot-linear-algebra now has proper build and install make targets. Some of this was stolen from Rakudo++.
(pla) dukeleto++, darbelo++ and desertm4x++ for their help in these projects
WHAT I WILL DO THIS WEEK:
(parrot) working more on the load_bytecode thing
(matrixy) Creating a new branch to convert Matrixy to use parrot-linear-algebra types instead of nested RPAs
(matrixy) Converting Matrixy's test harness to NQP instead of Perl5
(pla) Adding a test harness and starting a test suite for parrot-linear-algebra
(pla) Planning for a new PMCMatrix2D type that will be a 2D array of PMC pointers
WHAT I AM BLOCKING ON: 18:27
* nothing
EOR
NotFound What I did:
* Some bug fixing.
* Created a repository for Winxed, a javascript-alike language,
and worked on it.
What I will do:
* Work on Winxed.
* Take a look at some tickets and patches.
EOR
18:29 mikehh joined
chromatic He336. 18:31
Num lock.
whiteknight hello
mikehh howdy there
pmichaud_ Hello.
darbelo Hola
allison hi
Util hi
chromatic Let's review last week.
We landed a branch.
Rocks fall. Everyone dies.
NotFound hola
whiteknight not EVERYBODY died 18:32
chromatic How else did we do on our weekly goals?
whiteknight (Matrixy was completely unharmed)
allison remarkably painless
NotFound (Winxed fly away)
mikehh we've got fulltest working and jonathan has nearly got rakudo working 18:33
chromatic Is Coke here?
Coke hio
18:34 cotto_work2 joined, kurahaupo joined
chromatic I ask because my perception is that the deprecated extension functions to call PCC from C are broken and this caused Coke pain. 18:34
kurahaupo sorry, totally out of tuits this week. <EOR> 18:35
Coke chromatic: my pain was resolved by allison pretty quickly with a new function.
however, jonathan got bit by the same thing, and I think had a little more of a hard time.
the root cause there was that the parrot subs we were using weren't tested, and so broke during the pcc changes. 18:36
chromatic Any HLL designer who isn't on channel right now will have the same problem.
whiteknight Any HLL developing using the C api
Coke again, the root cause was untested parrot code. improving our code coverage will help ameliorate these types of things (and make the deprecation hoops worth jumping through.) 18:37
chromatic My suggestion: more tests for those functions.
whiteknight agreed
chromatic Even though they're deprecated functions, they have an easy replacement and migration. We can keep the tests even as we remove those functions in January.
Other goals for last week? 18:38
whiteknight On the extreme end, every function in extend.c should have a test, and we should have a test to prove that
Coke whiteknight: 'make cover'
(a good first start.) 18:39
darbelo chromatic: How about "get the libjit frame builder going again"?
kurahaupo has to leave for $DAYJOB
jonathan Yes - I migrated to the new C interface.
18:39 kurahaupo left
jonathan And that's been working fine, but agree, it made the transition more painful than it need have been. 18:39
chromatic Are there docs on migrating to the new interface?
whiteknight plobsing++ has been doing a really nice job on that new framebuilder
Coke chromatic: see the Deprecation wiki page. (and I don't think so.)
chromatic Is there a volunteer to write those docs and link to them in the API documentation in the source? 18:40
allison I've updated the existing API docs 18:41
are you looking for more of a migration guide?
chromatic Yes.
allison is a wiki page sufficient?
cotto_work2 q1q 18:42
Coke IMO, yes.
chromatic +1
allison (this is me volunteering, since I know the details best)
Coke (because after a while, no one needs to migrate. relentless progress.)
jonathan +1 - and mention it in the docs for the deprecated functions.
allison ok, will add to my list for the week
chromatic Other thoughts on trying to land the framebuilder branch this week? 18:43
whiteknight I've heard some concerns that supporting multiple JIT engines will be hard
so at the least we should get some eyes on the LLVM documentation to make sure we can support that too
other then that, no concerns
jonathan By the way, here is the diffstat for switching to the new calling conventions: 18:44
8 files changed, 164 insertions(+), 246 deletions(-)
japhb chromatic, if it lands this week, I *might* have enough cycles to try to push the OpenGL bindings a little farther. If it lands any later, I probably won't have time to do that for this release cycle
Util q1q
18:44 einstein joined
chromatic Any other recommendations for focus this week? We have two solid onces. 18:44
ones
whiteknight parrot-linear-algebra needs the framebuilder too, for all the new exotic LAPACK functions
mikehh I got started on checking skipped tests - then diverted by trying to get the equivalent of autounfudge.pl in parrot - still working on that 18:45
japhb whiteknight, and at some point, I'd like to coordinate on using your matrices as OpenGL buffers ....
whiteknight japhb: would love that 18:46
chromatic Let's move on to questions then.
darbelo?
japhb No rush, but that would definitely be a good test of NCI. :-)
mikehh q1q
darbelo pmc_i_ops has been waiting for review for roughly five months now. Can we get a ruling before it bitrots into unmergeability?
allison what is it? 18:47
is there a ticket or wiki page explaining the purpose of the branch?
Coke q1q
darbelo It was bacek's attempt to implement some VTABLE operations in term of the in-place ones 18:48
It's on the branch descriptions page.
pmichaud_ (repeating my q1q from my report earlier)
darbelo "Branch to reduce amount of code by reusing i_op from op" 18:49
chromatic I think the answer to the question is "Yes, that can get review." Should we move that to #parrot?
whiteknight yes
allison yes
darbelo chromatic: sure.
chromatic darbelo, next question? 18:50
einstein May I ask on this channel on my plan what i described in ticket #1020?
darbelo We have TT#75 and TT#77 (with a few other friends) What should we do there? 18:51
chromatic einstein, that's probably better in #parrot
einstein ok
darbelo Are we even supporting those interfaces anymore?
chromatic Parrot::Embed needs updating, that's for sure. 18:52
I will happily trade features for tests, or work with someone to fix the API there.
darbelo Okay. That's good enough for me. 18:53
chromatic Util, question?
Util The bottom 2/3rds of t/src/embed.t has been SKIPped for so long, its code has bit-rotted. The SKIP is just for unexported symbols. With PCC landing, wouldn't this be a good time for a PCC specialist to bring embed.t up-to-date? Or will Allison's migration guide be enough that a simple ticket right now would allow someone to fix the tests at a later date? 18:54
allison I'll take a look
Coke Util: open a ticket and assign it to allison.
allison will either fix, or put in a ticket telling how to fix 18:55
Util allison: thanks. I will be glad to write the ticket if it is needed. EOQ.
chromatic Excellent.
allison that works
chromatic cotto_work2, question?
NotFound Util: those tests can be killed, they are counterproducent. I leaved them skipped just in case someone wanted to take a look and update them.
cotto_work2 We don't currently have a way for C code to generate a PAST, e.g. for users who want to write a lexer/parser in C or C++ and just pass the PAST to the next stage of the compiler. Is this something we eventually want to support and where does it fit in the roadmap?
18:56 mikehh joined
pmichaud_ if/when we gain the capability to invoke methods from C, this becomes trivial. 18:57
allison cotto: as I understand it, PAST is moving along with nqp
Coke pmichaud_: pretty sure we can do that now.
NotFound cotto_work2: Why can't be generated? can't be done by creating some objects and calling some methods or subs?
pmichaud_ allison: so far PAST is remaining in parrot
allison pmichaud: (can move offline) doesn't the PAST->PIR transition depend on NQP? 18:58
NotFound pmichaud_: I think we already can invoke methods from c.
pmichaud_ allison: no.
at present PAST->PIR is still pure PIR. 18:59
there may come a time when we re-implement PAST in NQP, but that isn't happening immediately.
allison okay, then, cotto, the answer is that building PAST from C is the same as creating any PMCs
or, are you looking for a C API? 19:00
cotto_work2 So it should be possible now, as long as I don't mind building my own callsig?
allison as in, function calls?
cotto: you don't even need to build a call sig
just ordinary calls
pmichaud_ all that current compilers do is make method calls on PAST objects to build the PAST tree.
allison basically, pmc_new for the node and then set the attributes
cotto_work2 ok
pmichaud_ don't even need pmc_new 19:01
because PAST nodes have a 'new' method that does that (and attribute initialization as well)
jonathan No, just grab the proto-object and .new it.
pmichaud_ ...what jonathan++ said.
allison with get_class?
pmichaud_ look it up in the namespace
$P0 = get_hll_global ['PAST'], 'Op'
$P1 = $P0.'new'(...arguments...)
cotto_work2 ok. O 19:02
chromatic Coke, you had a question?
cotto_work2 I'll play with that and see how far I can get.
Coke chromatic: partcl still has at least 2 segfaults remaining.
the pcc merge let us avoid one (by forcing me to use a different parrot sub), but some are still there. See my report. be nice if we could be segfault free. =-) 19:03
eoq 19:04
chromatic pmichaud_, you had a question.
pmichaud_ (long question)
Currently the parrot executable supports -L and -I options for
adding directories to the library path (load_bytecode) and
.include path.
Unfortunately, -L and -I *append* the directories to the end of
the search list, which means that installed versions of a file
always take precedence over those in the paths specified by -L/-I. 19:05
Most implementations of -L/-I *prepend* directories to the search path.
(Perl 5, GCC, etc. all prepend paths.)
This means that it's very difficult to bootstrap/build/test local
copies of modules because the system-installed versions tend to get
in the way.
Is this a bug, can it be fixed, and does it need a deprecation cycle?
EOQ
allison it can be fixed
and, can skip the deprecation cycle (it's a bug making the feature less-than-usable) 19:06
whiteknight I'd say it's a good idea to change it
pmichaud_ okay 19:07
I will change if nobody beats me to it. Thanks.
whiteknight bonus points for a patch :)
pmichaud_ patch is trivial :)
chromatic mikehh, you had a question.
pmichaud_ I'll put a note in NEWS/ChangeLog identifying the change.
NotFound I implemented -I and -L and was not a bug, just a quick addition without much thinking ;) 19:08
mikehh allison mentioned updateing Pod::Simple - book uses Pod::Pseudopod but not in parrot - can we consider that aspect aswell
japhb NotFound, a bug in your implementation process, then. :-)
pmichaud_ NotFound: sometimes one person's bug becomes another person's "gotta have feature" :)
allison mikehh: not updating, actually removing 19:09
mikehh: (skipping the pieces that use it if it's not installed)
mikehh allison - whatever
NotFound If I remember well, I just copy what the pcre test was doing with pir code.
allison mikehh: yes, worth considering our Pod::PseudoPod policy as well 19:10
mikehh: this could all be made much simpler by a Plumage package
mikehh I had that thought
japhb Anyone is welcome to trade a gitorious ID and PaFo CLA for a Plumage commitbit. 19:11
Get 'em while they're hot!
whiteknight still has to fill out his parrot CLA! 19:12
NotFound BTW if someone want a commit bit on Winxed, just ask.
mikehh I think I got one somewhere :-}
chromatic Other questions?
allison users list?
19:12 cotto_work joined
allison (update on) 19:12
iirc, Coke was working on that 19:13
19:14 cotto_work2 left
allison okay, no update, carry on 19:15
chromatic Other questions? Blockers? Concerns? Subtle puns?
Note that puns must start with the letter 'P'. Icelandic thorn is also acceptable. 19:16
japhb *sound of people mousing to their local Character Map equivalent*
chromatic Too late! Have a good week, everyone. 19:17
japhb o/
allison thanks all!
19:17 allison left 19:18 pmichaud_ left, NotFound left, PacoLinux left, chromatic left 19:19 Util left 19:29 darbelo left 19:34 Coke left 19:41 jonathan left 19:49 davidfetter left 19:59 particle1 joined 20:07 kurahaupo joined 20:08 kurahaupo left 20:44 mikehh joined 21:11 kj joined 21:23 kj left 21:55 Whiteknight joined 22:50 Whiteknight joined 23:13 mikehh joined 23:55 davidfetter joined