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.
05:11 particle joined 12:39 whiteknight joined 14:25 davidfetter joined 15:58 NotFound joined
Tene * I haven't really done anything recently. busy at home. 16:21
KTHXBAI
16:23 integral joined 16:37 darbelo joined
whiteknight WHAT I DID LAST WEEK 16:51
* Worked on pcc_reapply, helping to fix remaining tests
* All tests appear to pass now. Congrats to all people who helped (and there were many!)
* Looking for optimization potential. Watching as chromatic++ and bacek++ get started on that already 16:52
* Put together an initial patch to implement :call_sig. Only works on .param for now. Needs work, but good proof-of-concept.
* Watching lots of LLVM videos, cotto++ for finding them. Reading papers and stuff to prepare more for JIT
* Running lots of tests for the upcoming release.
* Moved Matrixy to Github.
* darbelo++ got it building against installed Parrot. I fixed a few issues stemming from the iterators refactor ("new 'Iterator'", etc)
* Separated out the CBLAS and CLAPACK library bindings into a new Parrot-Linear-Algebra project, also on Github.
* darbelo++, dukeleto++ and desertm4x++ for helping to plan a roadmap for that
* Reading into a lot of mathematics libraries, looking for good candidates to link against and support.
WHAT I WILL DO
* Planning for a new 2D Matrix PMC type, or family of types (depending on optimizations needed) in Parrot-Linear-Algebra. Suggestions/help welcome.
* May include single/double, real/complex, dense/sparse types (long-term goal). Be interested to hear what users want
* Getting Matrixy's test harness to work again (darbelo++ for looking at it already), and then making sure all tests pass (maybe with TODO)
* Help with pcc_reapply merger
* Finish implementing :call_sig properly and apply to trunk
* May need to use :call_sig in Matrixy to support the idiosyncratic argument passing scheme, will evaluate
* Work on frame builder and JIT
WHAT I AM BLOCKING ON
* Not enough time.
EOR
Tene That's impressively larger than my report. :) 17:03
darbelo Have done: * Updated Matrixy to work with an installed parrot. * Discussed parrot-linear-algebra ideas with Whiteknight. * Wrote a plumage .json file for Matrixy. First module with actual dependencies. * Cleaned up the decnum-dynpmcs build infrastructure a bit more. * All other plans failed with ENOTUITS.
Will attempt: * Start the cblas bindings for parrot-linear-algebra. * Get started on that damn DecQuad PMC already. * Kill DecInt, decNumber can't really handle big integers.
Blockers: * Tuit Insufficiency.
EOR.
17:10 mikehh joined
cotto_work What I did: 17:24
* added some postmature optimizations to the profiling runcore
- oofib.pir runs about 30% faster under the profiler
- Rakudo "< h i >.join.say" runs about 79% faster under the profiler
- memory usage is somewhat higher, so it's a trade-off
* improve pprof2cg
* whatever else is on the profiling todo list
What could block progress:
* rl
Is this the end of my report:
* Yes.
mikehh What I did in the last week: 17:35
* building and testing parrot in trunk and pcc_reapply branch - fixing codetest errors etc.
* fixed a couple of test failures and TODOs
* pcc_reapply ready for merging after the release? - All tests now seem to pass
What I intend to do in the next week:
* testing and fixing
* review skiped tests to see if any pass or can be TODOed
.eor
18:05 chromatic joined
japhb DONE IN PLUMAGE: 18:08
* Dependency handling, including remembering installed projects (not the final paradise, but Good Enough For Now)
* Automatically sudo if parrot_bin directory not writable by user
* New 'projects' (list known projects) and 'showdeps' (show resolution for all dependencies) commands
* Plumage metadata dir can now be overridden by conf file (for testing support)
* Several new functions in Glue.pir and Util.nqp
* Lots more docs for Glue.pir and Util.nqp
* More tasks broken out of my head into TASKS
MAD PROPZ:
* dukeleto++ # Testing, testing, testing; factor out Util.nqp from main program
* darbelo++ # Matrixy metadata (and making it buildable against installed Parrot)
NEXT UP:
* Importer for proto projects (already WIP)
* More refactoring into modules
* Maybe get a chance to blog the last couple weeks of work? Nah ....
BLOCKING ON:
* Day job + sick family. STILL.
EOR
18:10 pmichaud joined
pmichaud What I did: 18:10
* More work on nqp-rx.
* The parsers in nqp-rx are now self-hosting -- i.e., nqp-rx is able to
completely parse and compile its own language grammars
* In other words, it's now entirely independent of PGE.
* More of the p6 regular expression syntax is present, including many
items that were not available in PGE, including
** zero-width enumerated character assertions
** binding results to multiple targets 18:11
** subrule calls with multiple arguments <foo(arg1, arg2)>
* Since the regex engine is PAST based, we automatically get source
code annotations (source line numbers and offsets) and proper
lexical variable scoping
* Created an HLL::Grammar base grammar for deriving HLL grammars.
** Provides standard rules and actions for common HLL features
like quoted strings, integers, etc.
** Can be easily extended to allow HLL-specific constructs.
* Developed a new operator precedence parser based on the one in STD.pm
** Makes it very easy to add custom precedence levels, HLL-specific tokens
** Currently supports term:, infix:, prefix:, postfix:, circumfix:,
postcircumfix: operators with various associativities and precedence
levels
** New OPP is far more reusable and extensible than PGE's
* New NQP is being built based on HLL::Grammar
* Designed a number of PAST optimizations to improve constant handling
What I'm doing this week:
* Completing new NQP implementation, including bootstrap
* Starting a new Rakudo branch to switch to nqp-rx based grammar
* Adding more optimizations to PAST
* Implementing smarter/faster protoregexes
* Writing blog posts
* Helping with Rakudo release (Thursday)
* Working on Perl 6 book chapters 18:12
What I'm blocking on:
* Not much, yet
* May start blocking on Perl 6 specification issues soon (Parcels & Captures)
EOR.
japhb pmichaud++ # Fricking awesome
chromatic I worked on optimizations, specifically rewriting CallSignature to use fewer PMCs.
I have more optimizations.
That's about it.
pmichaud I hope to have a new NQP implementation late tomorrow-ish. 18:13
Might be sooner, depending on $family
japhb pmichaud, excellent. Will I need to change my Makefile (which assumes the existence of 'parrot_nqp'), or will you be swapping out the old NQP in place?
pmichaud it's a totally new nqp
you'll need to change your makefile 18:14
it's very likely that the new nqp won't be part of parrot by default
japhb OK, np.
um, less cool.
I can't depend on anything that's not in Parrot.
pmichaud there's probably room for some discussion there
the new nqp doesn't want to be restricted by parrot's distribution/deprecation policies 18:15
but there's nothing wrong with parrot selecting versions of nqp and bundling them into the release
japhb wait, let's save this for the main meeting ...
... and yes, that was my first idea.
18:17 moritz joined
moritz Not much of a report... learned that the Debian people have a summary bot which records lines, and can display it as summaries somehow - will look into making such a bot for #parrotsketch to better track results 18:19
18:19 allison joined
allison Last week: 18:20
- Worked on the PCC branch. Merged in chromatic's optimization of the CallSignature PMC. Spent a couple of days debugging cloned constants tables in threads.
Next week:
- (Today actually) Plan to merge the PCC branch into trunk after the 1.7 release.
18:22 Util joined
Util # Done 18:23
* Milestone TT#600 - not landed; reschedule for 1.7.
* Nothing else - tuit tunnel collapsed.
# Plan for next week:
* None. All tasks stalled for 1 week.
# Blockers:
* 0 tuits until next Tuesday night, then much available time.
.end
NotFound What I did: 18:28
* Just some testing, been busy and disconnected the last two weeks.
* Working on a language with javascript-alike syntax, nothing viewable yet.
What I will do:
* No plan.
EOR
18:29 dukeleto joined
dukeleto win32 testing in trunk, plz? 18:29
japhb Meeting time 18:30
q1t (topic)
whiteknight hello 18:31
chromatic Good news, everyone.
allison hi
darbelo hola
Tene What's the good news?
Util dukeleto: Win32 testing now
chromatic I'm sending you all to the WORK REALLY HARD FIXING TESTS planet this week.
whiteknight ditto
chromatic Let's review last week's goals. 18:32
dukeleto looks like win32 test have been failing for a while. sigh.
dukeleto stops interrupting
chromatic pcc_reapply status?
Tene done, except for merge
I should go merge it into trunk right now, while dukeleto is trying to cut the release? 18:33
chromatic I heard a collective eye roll.
cotto_work hi
chromatic Tests in trunk? I unskipped a few and made them pass, but was there much concentrated effort or only a few stabs?
Tene I didn't even look at trunk all week!
18:34 kj joined
Tene So, sounds like no concentrated effort. 18:34
chromatic Agreed.
The other priority I saw was a wiki page about immutable strings. whiteknight?
mikehh fixed a test or two, fulltest works in trunk and pcc_reapply 18:35
18:35 Coke joined
whiteknight chromatic: tuit shortage 18:35
focused on pcc_reapply instead
chromatic Alright.
Let's talk about this week then.
pcc_reapply lands. Priorities?
Coke << ENOREPORT >>
chromatic: partcl still has 3 or so segfaults that could use some love. 18:36
mikehh make sure rakudo etc work after the merge
from the parrot side that is
chromatic Language testing, then.
Tene rakudo doesn't work against pcc, last I checked. 18:37
pmichaud we expect rakudo to fail against pcc, fwiw
that's okay, it's likely a rakudo issue and not a parrot one.
darbelo partcl will probably break horribly too.
japhb "Help rakudo work against pcc"?
pmichaud +1
Tene cardinal works against pcc 18:38
Coke darbelo: I wouldn't expect it to.
pmichaud I'll need to make sure nqp-rx works against pcc (it should)
Coke (fail)
darbelo Coke: you never do, and it always does.
chromatic Any other priorities?
Tene what are the major tasks for the next release? 18:39
and what priority are they?
chromatic HLL interoperability.
Coke note: there are still two tickets for 1.7 in trac.
chromatic Testing sprint.
User mailing list. 18:40
Struct pruning will continue. I dragged my feet on part of it until the pcc_reapply merge.
Tene I plan to work on plumage more.
moritz do we need a user mailing list? parrot-dev doesn't seem to flooded with user questions right now
Tene I've said it before, but I'll try to diagnose and describe HLL interop issues.
Coke moritz: it's an easy thing to setup. 18:41
allison moritz: we put it off for that reason
mikehh I fixed a lot of documentation codetest failures in pcc_reapply, particularly src/call/args.c - it needs review
Tene moritz: because there's no parrot-users ml, of course.
"If you build it, they will spam"
;)
Coke Tene: can't be any worse that spam on parrot-dev
allison moritz: but 2.0 and after is when we expect to start getting more general users, so that's why we put it in
moritz Coke: that doesn't mean it's a good idea. Splitting up the community should only be done if necessary
chromatic Should we have it in place by 2.0?
allison chromatic: yes, I think so 18:42
Coke moritz: we are currently ``scaring'' away people who just want to use parrot, based on comments from friends.
pmichaud the problem with parrot-dev as it exists now is that if I'm a user, I don't see a place to ask my question.
allison sounds like this is the right time, then
pmichaud normally I would always start with a parrot-users list, and then split off parrot-dev when needed, instead of vice-versa.
Coke many of our docs are how to /contribute/, which is good for us, bad for our users.
allison (as in, when we start to see the need, and before it becomes a critical need)
pmichaud anyway, parrot-users +1 18:43
allison Coke: and yes, agreed, the list is only the start of a focus on users
moritz +0 from me then ;-) 18:44
chromatic Any objections to starting that list before 1.8?
Coke chromatic: no.
mikehh no
Coke pleae do.
chromatic Do we have a volunteer?
Coke I volunteer OSUOSL.
(I'll open a ticket with them.)
(claimed tt#608) 18:45
chromatic Okay.
It's three months until 2.0. What is our biggest priority for 2.0? 18:46
allison documentation
whiteknight JIT
pmichaud "production ready". That means performance and stability.
whiteknight performance=JIT
allison code cleanup
production ready also means approachable for production users
Tene and correctness 18:47
allison stability also implies testing
chromatic I suggest that we pick one of those each month for our weekly development priorities.
allison (so does correctness)
one each week? 18:48
Tene With our current policies, it's very important to identify and note any desired deprecations.
whiteknight those sound like things that can be done in parallel: documentation, testing, development
darbelo q1q
chromatic Hm. Let's pick one for this week then.
Testing?
whiteknight Testing
cotto_work +1 to whiteknight
(about parallel tasks) 18:49
japhb We may want to have a slightly longer trunk freeze in the weeks before 2.0, to really get as stable and clean as we can -- and doing so may ripple back in our timeframe estimates.
whiteknight not trunk freeze, but core development freeze
japhb whiteknight, yes, that's actually what I meant, sorry
whiteknight we'll want to be able to add new tests and new docs and new cleanups in that time
allison japhb: yes, that's the plan
japhb allison, excellent 18:50
allison not a freeze exactly, but no major feature development
cotto_work feature freeze
allison lots of testing fixes and documentation fixes in the last couple of weeks
and platform fixes
chromatic Can I suggest: extend our PCC testing this week as a priority?
allison excellent idea 18:51
darbelo +1
cotto_work chromatic: pre- or post-merge?
whiteknight +1
cotto_work +1 either way
mikehh either and both 18:52
chromatic Post-merge. At minimum, someone knowledgeable needs to review t/op/calling.t and a couple of other places, identify gaps, and document them on the wiki so we can concentrate on them.
That's a conversation lull. 18:54
Question time!
darbelo?
darbelo Is nqp-rx going to be merged into parrot or will it leave the nest?
japhb FWIW, that was the topic I wanted to discuss as well 18:55
pmichaud the new version of nqp will not be completely backwards compatible with existing nqp
it also no longer requires or uses pge
and it's likely to have a revised implementation of the HLLCompiler object (written in NQP instead of PIR)
darbelo That only argues for a deprecation notice and post-2.0 merge. 18:56
moritz pmichaud: will you import it into the parrot repo?
pmichaud moritz: I'm not planning to do so
allison our general move is toward external modules
moritz darbelo: it can co-exist with current tools
pmichaud Parrot is welcome to bundle NQP releases, but I'm thinking NQP will live outside of the Parrot repo
allison so, that's a deprecation notice that it's moving out
pmichaud well, the existing nqp and pge could be considered deprecated 18:57
moritz pmichaud: so what's the plan? install it via plumage?
allison it's sensible
moritz: yes
japhb The problem I have is that NQP (the old one) is effectively moribund. But I could really use the nqp-rx features, and I expect if I asked for new features beyond that, that's where they'd go.
pmichaud japhb: there are a couple of possibilities
japhb moritz, allison: that leaves me in a very sucky place. Plumage is now written in a dead language.
allison japhb: yes, the old NQP would be deprecated and removed after 2.0
pmichaud first, one could use NQP to create the .pir that gets bundled with parrot
similar to how nqp-rx itself bootstraps
allison (or, after the dependencies are resolved)
darbelo allison: It's a bootstrap nighmare. We're witing plumage in NQP. 18:58
pmichaud it's not a nightmare to bootstrap
seriously.
here's an approach
write plumage in NQP
allison darbelo: I didn't know that, but it is possible to work around
pmichaud compile plumage with NQP
bundled the compiled plumage with parrot
one doesn't need NQP to be present in order to run programs that were compiled with NQP
that's kind of the point. NQP is a compiler that doesn't have any runtime requirements beyond Parrot. 18:59
Which means NQP-compiled programs can be completely standalone.
allison like lex/yacc
pmichaud unlike, say Rakudo, where you have to have the runtime library present
yes, exactly like lex/yacc
japhb pmichaud, isn't there a runtime that I need to have around? Currently when I create a fakecutable, I still need to load_language 'nqp'
pmichaud japhb: nqp doesn't have a runtime
or any runtime that it currently has is limited to 'say' and 'print'
(and those will be going away, because NQP will allow direct access to Parrot opcodes) 19:00
japhb pmichaud, so then just copy the last bits of NQP runtime (mostly say, print, and eval) into Plumage's PIR code, yes?
pmichaud yes
or compile those into libraries that can be bundled with parrot
japhb OK. 19:01
pmichaud but NQP itself doesn't and never will have its own runtime baggage. That is its primary purpose.
it's a hll compiler for *Parrot* runtime.
all that said
darbelo pmichaud: Sorry, then. I was wrong about the NQP bootstrapability.
pmichaud Parrot will likely want to start bundling the Regex portion of NQP
whiteknight goes afk for a bit 19:02
japhb OK, so, the plan is: Plumage switches to nqp-rx. Plumage eats any runtime it was inheriting from elsewhere. Parrot starts shipping a Plumage precompiled to PIR. About right?
pmichaud that's not difficult though, because as mentioned above the Regex library can be created as PIR or .pbc and committed standalone
japhb: +1
allison japhb: I'd say "we ship a bundle that includes Parrot and Plumage" 19:03
japhb allison, what is the functional difference?
Tene japhb: deprecation policies?
allison japhb: very little, but yes, release cycles are part of it
japhb OK, fair enough. 19:04
darbelo So long as they land together I'm happy.
japhb darbelo, "land together"? Meaning, both installed when you install a parrot tarball?
darbelo yep.
japhb nodnod
pmichaud "bundle includes Parrot and Plumage" (and I'd recommend "includes NQP" also) 19:05
japhb OK, we can work out the details of how to bundle the two on #parrot.
pmichaud++ # that was going to be my next comment!
chromatic Other questions?
pmichaud NQP is really lightweight, but I expect it to be at the core of most HLLs
allison pmichaud: agreed
pmichaud in fact, I think I have to modify my earlier comment 19:06
japhb ... and thus we come around to the "basic batteries" concept, just not quite as I envisioned it the first time.
pmichaud NQP does now have a runtime -- that runtime consists of the regex engine, a base HLL grammar, and a base HLL::Compiler object.
japhb ... and I need the regex engine, definitely. 19:07
pmichaud one can create NQP programs that don't require the runtime, but obviously regexes and compilers will need those additional libraries
but those libraries aren't intimately tied to NQP, any more than other Parrot libraries are.
japhb We just still need to ship them in the bundle. 19:08
pmichaud agreed.
anyway, I don't see it as being terribly difficult. In many ways it's much easier.
Because NQP development can proceed separate from Parrot core
and Parrot simply decides which version of NQP to ship that meets its goals
(much like Rakudo decides which version of Parrot to use) 19:09
I'm done now. :)
Coke <chromatic>Anyone else have any more questions?</chromatic> 19:11
chromatic Let's call that a meeting then. 19:12
cotto_work It's a meeting.
allison thanks all!
Coke ~~
moritz it was a meeting.
19:12 Coke left, moritz left, PacoLinux left, Util left 19:13 darbelo left 19:14 NotFound left 20:11 kurahaupo joined 20:18 particle1 joined 20:49 chromatic left 21:04 kj left 21:30 Whiteknight joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!