"Tuesday at 20:30 UTC"
Set by moderator on 3 August 2010.
00:41 kid51 joined
kid51 kid51's report 00:42
DONE/IN PROGRESS
TT #1726: documentation for functions in .pmc files: 00:43
* 1. Merge tt1726_pmc_pod branch into trunk.
* 2. Added the POD framework for most of the 23 files identified as having functions which lacked documentation. Where possible, converted inline comments to POD.
* 3. Used 'svn annotate' to identify Parrot committers who had previously contributed to these .pmc files; sent them email requesting assistance. NotFound++ for replying to two of my requests. mikehh++ for adding docs even without my prodding him.
Other:
* 1. *Several* times had to run 'tools/dev/mk_packfile_pbc' to get t/native_pbc/*.t to pass on Darwin/PPC. (This is getting tiresome.)
* 2. Made sure tools/dev/pprof2cg.pl gets installed -- but not as an executable.
* 3. Ran 'make fulltest' to PASS on Linux/i386 and Darwin/PPC at r48536
TO DO
* TT #1725: clarify headerizer documentation: For the time being I will probably abandon my attempt to refactor this, write tests, i.e., give headerizer.pl the full Phalanx treatment. I will simply try to get the docs in better shape. Spare tuits have to go to learning Rakudo Star.
QUESTIONS/COMMENTS
* 1. There was discussion on #parrot as to the desirability of writing documentation *in POD format* for *static* functions in the .pmc files (TT #1726). It was argued that such functions should be documented merely by inline comments on the grounds that they are "implementation details."
** I disagree. If *all* our functions were documented in *all* our source code files, we could have the luxury of deciding which functions should go into POD and which can be relegated to inline comments. But we are so far away from that that I believe we should err on the side of getting all functions documented in POD format, which is the only format for which we have (somewhat) good tools to detect the presence of
documentation. The overwhelming majority of static functions in the TT #1726 files lacked comments as well as POD up until last week.
** Another case where the perfect is the enemy of the good. 00:44
EOR
01:08 pgollucci joined 01:59 whiteknight joined 11:55 kid51 joined 17:45 pgollucci joined 17:49 NotFound joined 18:04 pgollucc2 joined 18:14 atrodo joined
NotFound What I did: 18:17
-parrot
* A bit of cleaning and nano-optimization in hashes
* Miscellaneous code cleaning and POD improvements.
* Added tests for several uncovered cases
* Avoid mark when empty in Capture and in string and pmc arrays.
-winxed
* Implememt and use "using static", plobsing++
* Fix constructor calls and use more constructors in stage 1 compiler
What I will do:
No plan, short of available time
EOR
18:25 pgollucci joined 18:33 pgollucci joined 18:55 ash_ joined 18:56 pgollucc2 joined 19:01 pgollucci joined 19:15 tcurtis joined 19:21 pgollucci joined 19:22 whiteknight joined
whiteknight WHAT I DID: 19:22
* Final evaluation for Chandon's GSoC project. Reading over all his code and stuff
* Tracking down some errors in Kakapo. With help from Austin_Hastings++ it's working well enough to run the PLA unit tests
* Fixed several bugs in PLA, including a really nasty inferior-runloop one
* Started creating Rakudo bindings for PLA.
* Massive refactor of the PLA test suite, hoping to start adding many more tests soon
* Added implementation of GEMM for PLA complex matrix type, needs testing
* Got nominated, and did some nominating, for PaFo board elections
WHAT I WILL DO:
* PLA test suite is filled with broken and TODO'd tests, so going to rectify that 19:23
* Other tweaks and changes to PLA
* Start a new module (Math::LinearAlgebra?) for Rakudo using PLA
WHAT I AM BLOCKING ON:
* Nothing
19:28 PacoLinux joined 19:43 plobsing_work joined 19:46 mikehh joined
plobsing_work What I Did: 19:49
* merged dynop_mapping branch
* modify freeze/thaw/packfiles with an eye toward rakudo startup performance
* completed deepclone library (on github)
What I Plan:
* more freeze/thaw/packfile changes
* general optimizations (suggestions?)
* documentation
* gsoc-y stuff
EOR
19:51 chromatic joined 19:56 darbelo_ joined
darbelo_ DONE 19:59
- Hit something of a dead end on unshared_buffers.
- (The approach has merit, but I have to shave another yak first.)
- Put my GSoC pencil down.
- Filled out the final evaluation form.
- Made a tarball of this summer's work.
TODO
- Upload the code sample tarbal to Google.
- Dive into substr_eq_at, this is the yak I mentioned before.
- Eventually merge all three branches back to trunk.
EOR.
chromatic Done: some optimizations, some helping with optimizations. 20:00
Undone: GC massacre, MRO email to list.
Will do: review a threading patch, help merge branches.
tcurtis Did: 20:11
* Fixed some bugs in PAST::Transformer.
* Wrote some docs for Tree::Optimizer.
* Added TailCallElim::Explicit to simple-optimizations.
* Expanded ConstantFold::Simple.
* Downed pencil
* Worked on GSoC final evaluation.
Will do:
* Final GSoC blog post
* More docs.
* More bug fixes.
EOR.
20:12 smash joined
cotto_work #done: 20:13
- gave khairul tips on docs, finished his gsoc eval, made a tarball (in case Google wants one)
- finally figured out how to get the github trac plugin installed and working
#hope to:
- write something cool to show what khairul's been doing
- extend the github trac plugin to map svn revisions to git hashes
#eor
mikehh What I did since my last report: 20:14
* building and testing parrot on amd64/i386, with gcc/g++
* some fixes
* testing rakudo, partcl-nqp, partcl, pir/PIRATE, winxed and plumage
* worked on documentation, especially for .pmc files
* got things ready for the release today
should be ready to go after the meeting
What I intend to do in the next week:
* testing and fixing
* work on html_cleanup branch
.eor
20:23 Chandon joined
Util # Done: 20:23
* Researched compiling GMP on Win32 (for bigints, etc). Wiki writeup RSN.
# Plan to do:
* No time this week.
# Blockers
* My cup overfloweth
.end
20:26 Coke joined
Coke hacked on partcl-nqp, some RT maintenance for rakudo; will repeat next week. EOR. 20:27
Hello, everyone. 20:31
mikehh hi there
cotto_work hi
plobsing_work hi 20:32
NotFound Hola
tcurtis Hi. 20:33
Util Hello
Coke Anyone volunteering to run the meeting?
(I cannot today, and c is coming in late.) 20:34
20:35 dukeleto joined
mikehh there you go 20:35
dukeleto: yoiu have just been volunteered to run the meeting 20:36
dukeleto mikehh: oh boy
Did we meet our goals for the week?
did html_cleanup and the gc_* branches get merged? 20:37
Coke I did not. html_cleanup branch is still idling.
mikehh I was going to work on it but didn#t find time
Util Coke: is time the only blocker on html_cleanup? 20:38
Coke interest?
mikehh We need to set up the indexing
Coke my goal was to get it done before 2.6; since I missed that, it's a far far lower priority for me now. 20:39
if anyone else thinks it's worthwhile, happy to work with them on it. it's all perl5 ATM.
Util Just keeping an eye out in case expected 0 time expands to >0.
NotFound Coke: Maybe that is the reason for the lack of interest.
dukeleto what should our new goals for the week be?
personally, I vote that we need to get a smolder instance running again. I am not attached to smolder, but some way for people to submit test results is extremely important 20:40
mikehh merging branches after the release and any deprecations that can go
plobsing_work q2q 20:41
mikehh dukeleto: I was going to bring that up
Coke particle is on the smolder thign with OSUOSL, I think.
NotFound dukeleto: good goal, but hardly a general priority.
dukeleto NotFound: it is a meta-priority, it helps our gears turn smoothly 20:42
NotFound ok then
cotto_work There's not much most people can do about it, but +1 for those who can help.
mikehh I think it is very important from the testing point of view
particle the status from osuosl from late last week was "we're working on it, slowly, cause the guy working on it isn't here"
dukeleto particle: ok, good to hear you are on top of it
particle let me know if i need to apply more pressure
cotto_work Do they know about its memory leak issues?
NotFound Is a bad month to press people, let's wait until september 20:43
mikehh particle: I tried to email mpeters, but have not had a reply
dukeleto particle: i would say we should have it working at least 2 weeks before the next stable release, so that gives us about 6 weeks ?
particle dukeleto: can do
dukeleto are we into the questions section of #ps or did I miss something?
particle mikehh: thanks for trying, i don't know why no response.
i can follow up with mpeters, too 20:44
Coke dukeleto: it's your show. do what you like. =-)
dukeleto will have to leave for a dentist appointment soonish, and will have to hand-off. maybe chromatic will be here by then
plobsing_work: what is your 1st question?
mikehh did we decide on goals for the week?
dukeleto mikehh: touche. Let's decide some goals. 20:45
plobsing_work every time I update native pbc's it seems someone on darwin/ppc (usually kid51) has to do so as well. why?
dukeleto What is reasonable to accomplish in the next week?
NotFound +1 for the ones mikehh said
dukeleto plobsing_work: we will come back to that as soon as we decide some goals
I agree with mikehh, but I think we need our goals to be a bit more specific, so we know if we have actually accomplished them 20:46
mikehh I think there are a few things that were waiting for the release, branch wise 20:47
merge any branches that are ready (after testing of course) 20:48
darbelo GSoC is done and the release is out. Should we push for the GSoC branches to merge?
dukeleto darbelo: yes
darbelo (If ready, and not leaving the nest, of course.)
dukeleto I know that bubaflub's gsoc work is not done yet, but he seems eager to continue working on it after gsoc, which is promising 20:49
cotto_work khairul's code is leaving the nest, so it's a non-issue for him.
darbelo tcurtis has already moved his code out, IIRC.
cotto_work yup 20:50
darbelo And I have performance yaks to shave before merging is an option.
I don't know what the other statuses are. 20:51
dukeleto ok, so goals i here so far are merge gsoc branches that are ready, as well as others. Do we want more goals or is that enough?
chromatic How about closing n open tickets?
20:51 Paul_the_Greek joined
dukeleto chromatic: that sounds like a nice goal 20:51
chromatic: who gets to choose n ?
chromatic We do. 20:52
We have 663 active tickets.
dukeleto chromatic: what about each person at #ps right now closes at least 2 open tickets this week ?
darbelo Is one per active committer sane?
chromatic Close 13 tickets?
dukeleto darbelo: i think that is sane, and perhaps a bit less than we can do. Let's aim high. 20:53
Paul_the_Greek I'll join in when I return home. 20:54
darbelo That reminds me, we could force a commit bit upon Paul_the_Greek.
20:54 allison joined
darbelo I think he's sent a CLA. 20:54
dukeleto who wants to make closing 13 tickets a goal for this week?
cotto_work +1 if he wants one, though I don't think he does
Paul_the_Greek Yes, I have.
You can give it to me, but I'll use it gingerly for awhile. 20:55
chromatic If we're discussing CLAs, I like the work luben karavelov has been doing too.
cotto_work too
mikehh +1 to both
Paul_the_Greek Cotto knows of two patches I have attached to tickets. They will close those tickets.
NotFound +1
chromatic Ditto Nick Wellnhofer, though I don't know if he's on IRC.
darbelo chromatic: That's the gc patches, right?
chromatic GC and hash, yes. 20:56
Coke +1 to getting CLAs to both of them.
(pual & luben) I don't know nick.
particle Paul_the_Greek's cla has been received, approved, and logged
dukeleto +1 to more commit bits
cotto_work let's flip some bits
mikehh with a bit of mentoring, it works well 20:57
chromatic Nick wrote some patches to fix STRING iteration in January and February, and he's offered some GC patches lately.
dukeleto So shall we say that the goals for the week are to merge ready branches after the release and close at least 13 tickets ?
Coke I can flip the bits as soon as we have cla's and mentors.
Util +1 # goals 20:58
Coke so goal is to get down to 620 tickets?
Paul_the_Greek Fip my bit and assign me a mentor!
chromatic +1 to goals of closing 650 tickets and +1 to soliciting CLAs
particle someone please invite luben and nick to consider a commit bit and submit a cla
dukeleto Coke: no, because new ones could be added. Our goal is to close at least 13 tickets this week 20:59
particle joy
Paul_the_Greek I've been reading lots of tickets and some of them have basically pooped out. As if everyone decided that no change should be made. 21:00
There are also tickets in the New Patches set that are quite old. 21:01
Coke dukeleto: that number is harder to track.
dukeleto Paul_the_Greek: yes, that happens sometimes. We need to review those tickets, and close them if we decide they are invalid or no action should be taken
Coke Paul_the_Greek: if the patch no longer applies, we can probably reject it as outdated and invite a new one.
dukeleto Coke: there is an email for every closed ticket, it shouldn't be too hard
Paul_the_Greek An example: trac.parrot.org/parrot/ticket/850 21:02
dukeleto has to leave, i leave you all in the capable hands of chromatic++ 21:06
21:07 Paul_the_Greek joined
chromatic Do we have agreement on our goals then? 21:07
Paul_the_Greek Good goals.
darbelo Sounds like it.
Coke closes 2 tickets. 21:08
chromatic Agreement on inviting three new committers?
mikehh +1
allison +1
darbelo +1
NotFound +1
Coke +1
Util +1
Coke (well, +3)
chromatic Any other questions? 21:09
darbelo plobsing's didn't get an answer.
mikehh just gonna say that
plobsing_work Am I doing something wrong when I regenerate the native PBCs? kid51 always has to remake them on darwin/ppc. 21:10
mikehh I think the native code files were created on different platforms
darbelo plobsing_work: Are you on 32 or 64-bit intel?
NotFound plobsing_work: the wrong thing is the need to regenerate them. 21:11
mikehh we don't have functions to create them cross-platform wise
plobsing_work I always remake on 32-bit intel. I thought all the tests were all targetted at that platform's PBCs
NotFound See my last comment on TT #1712 21:12
mikehh we never decided on a testing policy there, ref the skipped tests
chromatic Does anyone believe we'll fix the cross-platform nature of PBC in the near future? Before 2.9?
NotFound Yes, we skip the test and then add other tests with the same problem.
darbelo In theory all platforms should be able to read packfiles for all others. Most of the code is there, but we're missing 'cross-reading' functions for some of the combinations. 21:13
NotFound darbelo: but we have the practical problem of regernerating the pbc for the tests. 21:14
21:15 whiteknight joined
NotFound That's not theory, is hurting us every month. 21:15
chromatic What do the tests gain us?
NotFound The packfile tests are needed, is the way they work what is wrong. 21:16
mikehh we should be able to recreate any given defined format, without having to generate it on the native platform
plobsing_work IIUC, they check that all platforms can read intel 32-bit packfiles
NotFound They should test the packfile pmc, not the pbc format. 21:17
That's the work of the native_pbc tests, wich are skipped.
darbelo I thought we were talking about those.
mikehh we should be able to read any format and transform it to another 21:18
NotFound darbelo: they are skipped, so they don't hurt.
atrodo is there a reason that the packfiles arn't just in little or big endian across the board? am I missing something obvious?
NotFound The practical problem now is the packfile PMCs tests.
21:18 tcurtis joined
NotFound atrodo: the problem is just to reuse the native_pbc files for that tests. 21:19
plobsing_work atrodo: not having to convert packfiles generated by your own machine is thought to be a win
chromatic We're not to the point at which we can mmap yet though.
whiteknight what will it take us to get to that point? 21:21
darbelo A person who can stand to hack on the packfile code for extended periods of time? 21:22
plobsing_work likely just someone caring enough to make it work
chromatic What should we do now with regard to the tests?
darbelo Stop checking in generated packfiles to the repo. 21:23
NotFound What tests? packfile PMCs or native _pbc?
plobsing_work +1
darbelo (for packfile PMCs) 21:24
mikehh we should not have to check in binary files
darbelo We should take whatever process creates them now and use it to create them when the test runs.
Coke I know rurban has strong feelings on these tests. whoever claims this todo item should at least review his post to the mailing list about it from just before 1.0
NotFound We just need to generate some pbc for the packfile PMCs tests 21:25
mikehh if we need them they should be generated
NotFound Coke: he's missing the point. The native_pbc tests are already skipped.
chromatic +1 to removing generated binary files
mikehh are those test the only reason we have the binary files? 21:26
NotFound mikehh: yes, the only reason to have it is its use in test that are skipped, and to misuse in unrelated tests. 21:27
mikehh kill 'em 21:28
Coke NotFound: his point was that they should not have been skipped at all, iirc.
darbelo We can start with the 'stop misusing' part. Then revisit for the kill.
chromatic I understood rurban's complaint to be "Stop breaking PBC compatibility."
NotFound Coke: but that point is not for that ticket, here it only adds confusion,
Coke <whatever/>
I have no stake in this particular mess, but only wish to point out someone who does. 21:29
chromatic Does anyone believe we can (or should) enforce PBC compatibility across supported releases? 21:30
NotFound I like rurban goal, but looks like we don't have enough access to all platforms required.
darbelo "It can be solved, but not without more resources than we have now."
plobsing_work it would be nice to have, but PBC is so far from ideal and ties in to so many other things, it would freeze us up.
Coke chromatic: yes. we /should/ be drawing a line in the sand and freezing our PBC format at some point. 21:31
chromatic Is that point now?
Coke it is crazy to have to recompile pir to pbc all the time. At least IME coming from the JVM. 21:32
darbelo No way. At best we could write a pbc 'migrator'.
Coke chromatic: I'm only answering the 'should' at this point. =-)
NotFound I don't think so. Frozen PMCs in the pbc means compatibility can compromise all PMCs.
chromatic Okay, let's skip that part for now.
sorear chromatic: PBC compatibility means imcc can be dropped in favor of PIRATE, if that's a goal
chromatic Does changing the tests to generate PBCs before testing them solve our problem now?
darbelo Yes. One of them, anyway. 21:33
chromatic Objections to doing so?
Who's going to make it happen? 21:34
Coke are we sure we're testing the right thing then? 21:35
NotFound We are testing the packfile PMCs
21:36 pmichaud joined
NotFound chromatic: I can go for it, but not sure if will have enough time this week. 21:36
chromatic Other questions?
If not, I have one. 21:37
mikehh NotFound: it has been hanging around for a year at least, go for it
chromatic Given the beneficial desire to document all C functions but the meh of adding public POD to static functions, any thoughts on changing the "Does this have documentation?" test to accept mere C comments for static functions instead of full POD? 21:38
cotto_work +1
Paul_the_Greek +1
plobsing_work +1 21:39
darbelo +1
cotto_work (unless it means more boilerplate comments to pass the test instead of documenting the functions)
Util I thought someone (kid51?) had made huge progress in cleaning up the backlog of un-PODed C functions
chromatic Any objections?
mikehh if you can come up with a reliable test that does that, at least with the pod headers we can determine that there is documentation there
or would just any comment in the function do? I do't realy think so 21:40
don't
chromatic My concern with requiring POD is that these are functions not for public consumption and thus should not be in public documentation.
NotFound A way to extract and put elsewhere all public api functions, methods and vtables will be better, IMO. 21:41
Paul_the_Greek Which prevents users from relying on some internal feature.
mikehh who are we documenting for, I think we document for devs as much as users
NotFound Its PODs, I mean.
tcurtis Is there any way to make it so that we have POD for both (because POD seems to be easier to check for), but the non-public functions are marked so that they don't show up in public docs?
plobsing_work I think one multi-line descriptive comment above static functions is appropriate
chromatic Figuring out how to hide POD seems like more work to me, but if someone can figure it out that's fine too.
Paul_the_Greek As a new developer, I don't see why I'd want static functions documented externally.
tcurtis Although, if so, that should probably wait until html_cleanup gets merged, perhaps. 21:42
chromatic Do we have some sort of conclusion as to what we should do?
mikehh I agree, but from the developer point of view, we definately *need* documentation
Paul_the_Greek Require a comment preceding a static function, but not a POD. Hide static PODs. 21:43
chromatic I can take a look at fixing the test if we agree on doing so.
mikehh as long as we have a way of requiring comments for every static function 21:44
Paul_the_Greek Any requirements for data structures?
chromatic We haven't reached that yet.
mikehh we should probably go for that too
Paul_the_Greek At least as important, I think. 21:45
cotto_work no requirements, but more comment patches are welcome
(yet)
tcurtis +1 to plobsing/Paul_the_Greek's suggestions, at least for now.
chromatic Other questions? 21:46
Paul_the_Greek A memory management question?
plobsing_work what is the difference between parrot's baked-in config and config.fpmc?
darbelo There shouldn't be one. 21:47
That is, config.fpmc is what we bake into parrot.
plobsing_work so why do we have runtime/parrot/library/config.pir?
NotFound plobsing_work: you mean the one in the Interpreter PMC?
chromatic There's a lot of useless stuff in config.fpmc.
plobsing_work NotFound: yes, that one.
NotFound plobsing_work: that is loaded from the other during intialization. 21:48
mikehh IIRC some of that stuff was set up to be sent to smolder
darbelo I think it's for people talking to libparrot directly and not through a parrot executable.
whiteknight config.fpmc could easily be broken up into multiple separate caches of data. Information about build/configure is useful for extensions but not so much for a running Parrot 21:49
NotFound But to get the path to load it you need to have it loaded. We should elaborate a btter way. 21:50
chromatic If this is getting into design discussions, perhaps it's better back in #parrot
NotFound A RFC ticket is better, IMO.
Paul_the_Greek Memory management question? 21:51
chromatic Probably better in #parrot. 21:52
Paul_the_Greek Okay.
chromatic Any last questions?
Calling it a week then. Thank you, everyone. 21:53
21:53 Paul_the_Greek left 22:19 plobsing_work left 22:41 Chandon left 22:57 kid51 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!