|
"Tuesday at 20:30 UTC" Set by moderator on 2 June 2010. |
|||
|
05:22
contingencyplan joined
05:32
contingencyplan joined
06:02
contingencyplan joined
10:36
contingencyplan joined
12:59
wdg_user_341 joined
|
|||
| kid51 | * What I Did: | 13:00 | |
| -- usual small code/test fixes | |||
| -- participated in Lorito discussion at YAPC yesterday | 13:01 | ||
| -- oddly enough, word "Lorito" only mentioned once during the meeting | |||
| -- summary of points put on whiteboard is here: thenceforward.net/parrot/yapc_bof_20100621.txt | |||
| * Will Do: | |||
| -- More work on cfunctiondocs branch. | 13:02 | ||
| EOR | |||
|
13:14
bluescreen joined
13:16
spinclad joined
13:20
bluescreen joined
15:37
tcurtis joined
15:51
NotFound joined
16:02
cotto_work joined
16:08
kid51 joined
16:20
bubaflub joined
|
|||
| NotFound | What I did: | 17:18 | |
| -parrot | |||
| * Added set_integer_native and push_integer vtables to ByteBuffer | |||
| * Fixed NCI bug with null STRING | |||
| * Changed PMCs isa_hash initialization to shorten generated code | |||
| and simplify usages. | |||
| * Added URI/Escape to runtime library. | |||
| * Some cage cleaning in PMCs | |||
| * Added a lot of PMC tests. | |||
| -winxed | |||
| * Fixed NCI sigantures in example Mysql | |||
| * Allow multiple declarations in const statement. | |||
| * Experimental tailcall optimization. | |||
| * Update example pirado to PBC changes and fix sub problems, bacek++ | |||
| * Minor fixes and refactors. | |||
| What I will do: | 17:19 | ||
| No plan. | |||
|
17:34
eternaleye joined
17:55
eternaleye joined
18:01
whiteknight joined
18:15
eternaleye joined
|
|||
| Coke | partcl-nqp | 18:24 | |
| - F2F hacking session with mdiep, who committed code! | |||
| (though I didn't =-) | |||
| parrot | |||
| - work on html_cleanup branch; goal is to greatly improve technical | |||
| aspects of generating docs.parrot.org; list of current gen'd docs | |||
| is now docs/index/*json; tools/docs/make_html_docs.pl parses this | |||
| and does everything but... actually generate HTML | |||
| - yapc | |||
| attend bofs & talks. | |||
| EOR | |||
| whiteknight | WHAT I DID: | 18:56 | |
| * (PLA) Improved BLAS bindings | |||
| * (PLA) Added elementary row operations and gauss-jordan example. Looked into next steps (LAPACK bindings?) | |||
| * (PLA) Adding functionality and tests. Create a new branch to track Parrot HEAD more or less ("official" work still targets previous stable release) | |||
| * (Parrot) merged ns_func_cleanup branch. Created patches for Rakudo and Partcl | |||
| * (Plumage) Got commit bit from japhb++. Looking into some of the build failures | |||
| * (Parrot) Following along with our intrepid GSoC students, answering questions on IRC. | |||
| * (Other) Following along with some other projects, especially Rakudo and PIRATE | |||
| WHAT I WILL DO: | |||
| * (PLA) Need to expand some BLAS-related functionality to all Matrix types | |||
| * (PLA) Want to put together some usage examples, especially with Winxed and Rakudo | |||
| * (Plumage) Hope to either fix, or help fix, Plumage and get it running again against current Parrot | |||
| * (Parrot) A handful of small cleanup tasks I want to look into, some optimizations I want to explore | |||
| WHAT I AM BLOCKING ON: | |||
| * Time | |||
|
19:21
ash_ joined
19:23
eternaleye joined
19:29
allison joined
|
|||
| cotto_work | #did: | 19:41 | |
| - met with khairul to discuss his gsoc project, things look good on his end | |||
| - there's some overlap with ongoing work in dynop_mapping, but it's not blocking anything for now | |||
| - hacked on PIRATE (bacek's nqp-rx PIR->pbc compiler) | |||
| - completely awesome | |||
| - also, really slow | |||
| - jumped in on the deprecation discussion, got some good feedback (see questions to be asked during #ps) | |||
| #will do: | |||
| - more PIRATEing (yarr!) | |||
| - set up a trac/git site *somewhere* for people to play with | |||
| - look into either lazy PMC initalization or moving making ParrotInterp use PackFile PMCs internally | |||
| #blockers: | |||
| - OSUOSL not doing much with a test git/trac site | |||
| - This does not bode well for when we actually upgrade. | 19:42 | ||
| #eor | |||
| q2q | |||
|
19:51
eternaleye joined
19:59
khairul joined
|
|||
| khairul | Did: | 20:06 | |
| - Handle exit/unhandled exceptions in a way to allow instruments to be finalized. | |||
| - Cleaned up hook tables on destroy. | |||
| - Updated the callback interface. | |||
| - Hooks for dynops | |||
| - Blog post at parrot.mangkok.com/?p=110 | |||
| Will Do: | |||
| - Finish up tests on runtime library (Probe, EventLibrary) | |||
| - Instrument the gc interface. | 20:07 | ||
| - Plan on instrumenting the PMC vtable interface. | |||
| EOR | |||
|
20:14
darbelo joined
|
|||
| tcurtis | What I did: | 20:24 | |
| * Wrote some POD for PAST::Pattern and subclasses. | |||
| - located in docs/pct/pattern/ in my branch. | |||
| * Added some tests. | |||
| * Rewrote PAST::Node.match and .subst methods | |||
| - Now I won't have to modify them everytime I add a new option to PAST::Pattern's relevant methods. | |||
| * Posted a detailed description of the optimization developed in my blog post from Sunday and PAST::Pattern. | |||
| - www.parrot.org/content/first-optimi...ern-detail | |||
| * Implemented PAST::Pattern::Any. | |||
| - Wrote tests for it. | |||
| * Started working on GTK bindings for Parrot this weekend(very very very very early stage). | |||
| - Segfaulting in my stub gtk_init call | |||
| - Is there any way to get at the arguments in argc/argv format)? | |||
| - Not going to work on it much during the summer, I expect. | |||
| * Attempted to modify PCT::Node and subclasses to use actual attributes to see how it affects performance. | |||
| - Not much progress, although I did notice some attributes and node types I missed due to them not having POD. | |||
| * Possibly other stuff I've forgotten | 20:25 | ||
| What I will do: | |||
| * Write docs for PAST::Pattern::Any. | |||
| * Improve existing PAST::Pattern docs. | |||
| * Add support for the attributes and node types PAST::Walker and PAST::Pattern lack. | |||
| * Work on some more optimizations. | |||
| - Interested in feedback on possible low-hanging fruit. | |||
| * Try to get someone else to start using PAST::Pattern. | |||
| - If successful, get feedback from them on it: | |||
| -- What it lacks | |||
| -- What isn't convenient enough | |||
| -- What isn't possible. | |||
| -- etc. | |||
| EOR | |||
| darbelo | DONE | 20:30 | |
| - Made some more ops NFG-aware. | |||
| - Dynamic code points now return Unicode character class information if queried. | |||
| - Iterators now mostly work. | |||
| - NFG literals now mostly work too. There's one TODO that I still haven't figured out. | |||
| TODO | |||
| - Write more tests, find useful testcases. | |||
| - Get started on making mixed-encoding operations DTRT. | |||
| EOR. | 20:31 | ||
|
20:33
plobsing_work joined,
Chandon joined
|
|||
| cotto_work | hello | 20:34 | |
| NotFound | Hola | ||
| allison | hi | ||
| tcurtis | Hi. | ||
|
20:35
mikehh joined
|
|||
| allison | I suspect chromatic is tied up at YAPC::NA | 20:36 | |
| shall we get started? | |||
| First, how was our progress on the weekly priorities this week? | |||
| cotto_work | bacek said that gc_massacre is blocked on the issue of how it should be tuned. | 20:37 | |
| mikehh | I think he said it needed tuning before it could be merged | 20:38 | |
| allison | ok, sounds like it's close, possibly this week | 20:39 | |
| work on deprecated items? | |||
| cotto_work | not too many deprecations but lots of discussion on the deprecation process itself | 20:40 | |
| allison | which is also important | ||
|
20:41
Coke joined
|
|||
| allison | how about tickets? | 20:41 | |
| Looks like we're hovering around 630, not bad | 20:42 | ||
| What should the weekly priorities be this week? | |||
| I vote to keep the same priorities this week. | 20:44 | ||
| mikehh | gc_massacre, but it needs more eyse, chromatic, allison | ||
| s/eyse/eyes/ | |||
| allison | I can take a look at it | ||
| allison makes note in her TODO list | 20:45 | ||
| Any questions? | |||
| cotto_work has 2 | |||
| allison | cotto: go ahead | 20:46 | |
| mikehh | q1q | ||
| cotto_work | Our deprecation process doesn't help anyone working on top of Parrot apart from keeping us from changing things too often. Drupal does a much better job of making their changes known: drupal.org/update/modules . | ||
| I propose that any deprecations, when implemented, require *at least* an accompanying wiki page describing the upgrade path and preferably a message to parrot-users. | |||
| As I mentioned on parrot-dev, I'll be glad to modify the docs, the wiki pages and make sure the policy is followed. | |||
| s/docs,/docs and/ | 20:47 | ||
| mikehh | +1 | ||
| NotFound | +20 | ||
| mikehh | agreed antway | ||
| allison | Yes, I think that's an excellent idea, especially as we approach 3.0. | ||
| mikehh | anyway | ||
| tcurtis | q1q | 20:48 | |
| cotto_work | Great. Writing deprecation policies is not quite as much fun as writing code, but it'll make our users much less crabby. | ||
| eoq1 | |||
| mikehh | I'll try and help | 20:49 | |
| cotto_work | mikehh: thanks | ||
| q2: We need to start some kind of signing for our releases. bacek suggested that we could maintain a GPG-signed file that contains hashes of all released tarballs. Any thoughts? | |||
| NotFound | The "make sure the policy is followed" includes chainsaws? | ||
| cotto_work | NotFound, no, but a revert wouldn't be out of the question. | 20:50 | |
| allison | cotto: that would require changing the file with each release. Is that a security advantage over a separate signed hash for each release tarball? | ||
| or, "Is there any security advantage..." | |||
| cotto_work | I don't know of any. | 20:51 | |
| I'll be happy if we get some kind of GPG signing in place. | |||
| allison | It is a good idea | 20:52 | |
| mikehh | some kind of separate md5/sha sum | ||
| allison | sounds like it's at the stage of surveying some possibilities, and summarizing the advantages and disadvantages | 20:53 | |
| i.e. We don't want to make it too difficult for packages to be built from our tarballs, or for users to interact with them | |||
| but also want an added level of security, verifying the source of the tarballs | 20:54 | ||
| do we have a volunteer to start a wiki page on the subject? | |||
| cotto_work | sure | 20:55 | |
| allison | excellent, thanks! | 20:56 | |
| cotto_work | eoq then | ||
| allison | tcurtis: you had a question? | ||
| tcurtis | Yes. | ||
|
20:57
bubaflub joined,
bubaflub left
|
|||
| allison | tcurtis: go ahead | 20:58 | |
| tcurtis | PAST::Pattern is now at the point where I can implement optimizations using it fairly simply. I'd like to know if anyone has any suggestions for possible low-hanging-fruit optimizations to work on? Which isn't technically a question, actually. | 20:59 | |
| allison | how much code analysis are you able to do so far? | 21:02 | |
| some of the traditional low-hanging fruit would be loop unrolling or dead code removal | |||
| how about constant folding and propagation? | 21:03 | ||
| NotFound | tailcall optimization | 21:04 | |
| allison | yes, that would be a good one | ||
| cotto_work | function inlining | ||
| tcurtis | Anything which involves looking for trees with attributes or children with certain properties is trivial. More complicated things can be done with a little more effort(anything is technically possible, but not necessarily convenient, since you can use a closure as a pattern). | ||
| allison | identifying .return at the end of a subroutine and replacing it with .tailcall | ||
| (i.e. .return that returns the result of a sub call just before it) | 21:05 | ||
| tcurtis: so, it's essentially an attribute grammar, with synthesized and inherited attributes? | 21:06 | ||
| NotFound | I've done that in winxed this week for the simpler cases, and parrot seems to be happy with it. | ||
| allison | I would leave operation fusion/fission for a later technique | 21:07 | |
| identifying invariant instructions inside loops could be a big win | |||
| tcurtis | allison: I'm not sure exactly what an attribute grammar is. | ||
| cotto_work | wikipedia has a long list of optimizations. I'm sure that finding some to implement won't be a blocker. | ||
| spinclad | (q1q) | 21:08 | |
| cotto_work | en.wikipedia.org/wiki/Category:Comp...imizations | ||
| allison | tcurtis: basically, it's searches for attributes over trees | ||
| to answer your question, I would start with the easiest optimizations to put in place | 21:09 | ||
| and build up to the more complex possibilities | |||
| you might use an existing simple demo language like squaak to demonstrate the possibilities | 21:10 | ||
| tcurtis | I think I'll likely work on tail-call elimination and expanding on what constant folding I've already done initially. I've been using NQP-rx as my test language so far. | ||
| allison | excellent (both good features to start with and good choice of language) | 21:11 | |
| other questions? | 21:13 | ||
| spinclad? | |||
| spinclad | (not so much a question as a comment coming from kid51's notes at thenceforward.net/parrot/yapc_bof_20100621.txt:) IMO lexicals/scope is another critical weakness that should be addressed as urgently as objects and metamodel, as great gains and synergy can come of it. | ||
| (i misdoubt that it's actively on the table at this parrotsketch) | 21:14 | ||
| (but i hope worth mentioning) | |||
| allison | excellent summary, thanks for the link | ||
| I have a comment/question. | 21:15 | ||
| spinclad | eoq | ||
| plobsing_work | q1q | ||
| allison | Actually, more making explicit something I've already been doing. | 21:16 | |
| cotto_work | mikehh had one too | ||
| allison | At this stage in the project, we see a lot more people with architectural knowledge than we had 4 years ago. | ||
| I've been encouraging people to take on more responsibility not only in the code, but in the overall design of parrot. | 21:17 | ||
|
21:17
ash_ joined
|
|||
| allison | to think through the overall system issues, and not just look at a problem locally | 21:17 | |
| over the next year you'll see more of a focus on handing parts of the design to experienced project members (like cotto with lorito) | 21:19 | ||
| and on the collaborative design process | |||
| Really, it's pretty much exactly what we're doing now, just being explicit about it. | 21:20 | ||
| Does this sound reasonable/workable? | |||
| spinclad | +1 | ||
| allison | chromatic and patrick are going to be talking about it with people at YAPC this week too. | ||
| mikehh | +1 | 21:21 | |
| tcurtis | +1, even from the viewpoint of someone who is not an experienced project member. | 21:22 | |
| cotto_work | Decentralization is great to a certain degree. I'm happy as long as we still have someone with architectural vision and control. | ||
| mikehh | that would make this meeting even more important | ||
| allison | eoc/q (with plenty of room for people to keep talking about it and come back with thoughts later) | ||
| mikehh: definitely | 21:23 | ||
| mikehh: you had a question? | |||
| mikehh | 2.6 is a major release, we need to consider merges/deprecations etc ASAP for it, I think Coke is the man there | ||
| spinclad | through these meetings we can cultivate shared vision and control | ||
| mikehh | also R" is comming up | 21:25 | |
| R* | |||
| allison | mikehh: deprecation notices for 2.6 is a good addition to the weekly priorities | 21:26 | |
| NotFound | Including experimental | ||
| allison | One of the plans for YAPC this week was to sit down with patrick and make sure we get a good list of R*'s needs | 21:27 | |
| those should definitely be high on the monthly release priorities | 21:28 | ||
| do we have anyone specifically focusing their parrot-time this month on preparing for R*? | 21:29 | ||
| spinclad | (Coke, [particle]?) | ||
| cotto_work | iirc Rakudo's happy with Parrot as far as R* is concerned. Of course sitting down with pmichaud won't hurt it. | 21:30 | |
| allison | I suspect most of them are at YAPC, since they're the Perl-focused folks | ||
|
21:30
whiteknight joined
|
|||
| allison | mikehh: does that pretty much cover your question? | 21:31 | |
| mikehh | Just wanted to bring that up - eoq | ||
| allison | thanks! | 21:32 | |
| plobsing: you had a question? | |||
| plobsing_work | I'd like some elaboration on the "freeze/thaw sucks" part of the bof summary | 21:33 | |
| allison | we'd have to get someone from the meeting | ||
| but generally, the features of freeze/thaw are limited | |||
| there are many PMCs we can't adequately freeze/thaw | 21:34 | ||
| NotFound | I've fixed one last week BTW | ||
| allison | it hasn't been much of a problem so far, because we haven't made extensive use of the feature | ||
| but, something we need to work on (not the highest priority, but been on the list for a while) | 21:35 | ||
|
21:35
bluescreen joined
|
|||
| allison | I suspect the YAPC folks will come back full of energy and ideas again this year, so we can ask for a more detailed summary | 21:36 | |
| spinclad | (haven't made use of freeze/thaw perhaps because couldn't? catch-22) | ||
| allison | spinclad: exactly | ||
| plobsing_work | If there are parts of the freeze/thaw subsystem itself that need work (as opposed to simply PMCs not implementing interfaces), I'd be glad to help fix them | 21:37 | |
| NotFound | There are freeze/thaw fully untested. | ||
| allison | excellent, thanks | ||
| NotFound | Just testing them allows to find bugs. | ||
| allison | plobsing: I suspect the next step will be a design review | ||
| (the next step after more extensive testing) | 21:38 | ||
| plobsing: so both testing and design could be areas where you help | 21:40 | ||
| did I miss any other questions, before we wrap up for the day? | |||
| alright, thanks everybody! talk to you next week | 21:41 | ||
|
21:42
NotFound left
21:51
darbelo left
|
|||