Vision for 2.0: Production Users | Don't forget to post closed tickets in your report. | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead. | irclog: irc.pugscode.org/
Set by moderator on 2 February 2010.
02:09 cotto joined 03:01 cotto joined 04:15 contingencyplan joined 04:26 cotto joined 05:47 cotto joined 05:48 eternaleye joined 08:29 mikehh joined 08:48 ascent joined 09:49 cotto joined 11:03 cotto joined 11:36 cotto joined 12:07 bluescreen joined 12:08 cotto joined 12:31 bluescreen joined, mikehh joined, particle joined, Coke joined, TimToady joined, Tene joined 13:07 cotto joined 13:22 PerlJam joined 13:53 perlpilot joined 15:05 cotto joined 15:14 bluescreen joined 15:18 cottoo joined 16:29 cotto joined 17:54 whiteknight joined
whiteknight WHAT I DID 17:55
* Applied patch from tcurtis++
* Received, and responded to, several emails from prospective GSoC students. If half of these submit applications, it could be our best year ever. Lots of interest in Immutable Strings specificaly, we may need to do some collision avoidance.
* Got a list of tickets blocking Austin and Kakapo, sorted in priority order. Closed some, tried to delegate some, commented on others.
* More tinkering on the Matrixy refactor, had a plan but am having doubts about it now.
* Created a new project, parrot-bidwidth-types, to play with some PMCs for fixed-width data types (integer32, float64, etc)
WHAT I WILL DO
* More cheerleading for GSoC.
TICKETS I CLOSED
#1533, #1133, #1497, #1473
Coke partcl-nqp - implement several [string] subcommands. - somehow convinced Austin++ to get a commit bit and do a ton of work. - added [lset] 18:04
- fixed TODO tests. - eliminate some Q:PIR
parrot -
- closed several TTs
rakudo -
- Talked to jnthn about priorities for Rakudo * - Very interested in getting good line #s on reported errors; jnthn will do some testing, but it would be good for us to make sure that line numbers in errors have
good coverage.
planned -
- keep migrating more work from partcl to partcl-nqp - this is actually
a good task if people want to play with NQP - take existing PIR and
transform it. 18:05
- work with darbelo to kill the dynpmc makefile (though this may actually
make sense to wait until after 2.3, as that will remove many of our
dynpmcs.
.
mikehh What I did since my last report: 18:09
* building and testing parrot on amd64/i386, with gcc/g++, with and without --optimize
* fixing codetest failures - particularly assert args
* no branch testing this week (too involved with trunk)
* couple of fixes to get g++ to build
* at the moment all tests up to fulltest pass (r45318) Ubuntu 9.10 amd64/i386 gcc/g++
What I intend to do in the next week:
* testing and fixing
* investigate codetest problems with nqp (which I did not get around to this week)
* documentation
.eor
cotto_work #did: 18:10
* "merged" test for the profiling runcore in t/profiling/profiling.t
- wasted about 90 minutes with two failed syncs before manually taking a diff and applying it to trunk
- profiling runcore tests are now run by default with library tests
- I'm not sure if that's the best place for the .t file, feel free to move if needed.
- Rough edges exist, but it works and it's easy to add more tests (including nqp-based tests).
* told khairul I can mentor his gsoc project, groups.google.com/group/parrot-dev/...138c1dbb4f
#will do:
* find profiling bugs, write test cases, fix, repeat
* look for holes or improvements in khairul's proposal
* back to opsc work?
#blockers:
#closed TTs:
#eor
19:12 darbelo joined, Tene joined, Coke joined, particle joined, whiteknight joined 19:21 chromatic joined 19:28 allison joined 19:36 dukeleto joined 19:37 bubaflub joined 19:41 bacek joined 19:43 moritz joined
bacek Done: 19:44
- Almost nothing.
- Fix Parrot_str_write_COW to allocate less memory (pointed out by chromatic++)
- Attempted to fix TT#1172 - reverted.
- Fix build with GC INF
Todo:
- New experimental Generational GC. 19:48
Blockers:
- RL.
EOR
chromatic Fixed a bunch of memory leaks.
moritz chromatic++ bacek++
chromatic Made several performance tweaks; Rakudo now starts at least 8% faster and should run at least 2.5% faster.
Wrote up plans for better constant STRING handling and VTABLE override checking; takers wanted on both. 19:49
Will continue to look at Rakudo-specific bugs.
19:50 NotFound joined
NotFound What I did: 19:52
- parrot
* Minor fixes, lloking at some tickets.
- winxed
* Some improvements in pirado.
* Hex integers in stage 0.
What I will do:
Not much, some holidays.
EOR
20:21 Util joined, allison joined 20:28 bubaflub joined 20:29 bacek_mobile joined
Util Nothing done, or planned for new week. Blocked by $WORK. 20:29
.end
allison Last week: 20:30
- Refactored the compact_pool function into a series of smaller static functions.
- Added documentation based on IRC discussions.
Next week:
- Scanning for further GC refactors.
- Focus on Rakudo needs.
EOR
chromatic Any other reports before we begin? 20:31
Okay, let's begin. 20:32
Last week in review: fortunately, bacek and I found and fixed the memory problem which hurt Rakudo.
20:33 bluescreen joined
chromatic How are we doing on HLL bugs, specifically MMD and methods in namespaces? 20:33
Util chromatic: Was that a true fix, or the workaround that you spoke of last #ps?
chromatic The memory problem was a true fix. 20:34
Other discussion of last week's priorities? Going once.... 20:37
Let's move on to this week's priorities.
Util TT #389 status?
chromatic Still blocked on brainpower, I'm afraid. 20:38
Util thx
chromatic I hope to have time to work on it this weekend.
Our next release is in three weeks, by way of a reminder. 20:40
allison Review the roadmap before or after questions? 20:41
chromatic Let's pick some weekly priorities, then do the roadmap.
Suggestions? 20:42
allison TT #389?
Coke rakudo's buildtime.
chromatic I'm not sure we can get anyone else to work on TT #389 who isn't.
Buildtime would be good. 20:43
Objections? Other thoughts? Line numbers? 20:44
Util +1 # Buildtime
darbelo q1q
chromatic Okay. Roadmap review, allison? 20:45
allison we need to take a step back and move the 2.2 roadmap items out
the quick question for each is 2.3 or later? 20:46
(and how much later)
chromatic Sounds fair.
allison Fix system-dependend code in src/gc/system.c
2.3? 20:47
later?
chromatic Later.
Coke do you have TT's for these?
allison or drop from roadmap?
TT #273
The report is: trac.parrot.org/parrot/query?milestone=2.2 20:48
ok, later 20:49
chromatic Low priority, but probably not much work.
allison it seems like a good task, but not roadmap importance
changed to no milestone associated 20:50
export conventions 20:51
TT #566
chromatic R* still needs them.
allison then move to 2.3
Coke needs a new owner, likely.
allison will set to no owner for now 20:52
Migrate non-essential PMCs to dynpmcs
have we done as much of that as we plan to do for the immediate future?
chromatic Low priority, low risk... after 2.3.
allison will put 2.6 20:53
same migration of dynops 20:54
also 2.6?
chromatic Yes, after 2.3.
allison done 20:55
:invocant flag?
low priority, needed at some point by R* last I checked 20:56
say, 2.5?
chromatic Sure. 20:57
allison hll interop work
Coke (if it's needed by R*, please add "perl6" to the language slot) 20:58
allison is anyone actively working on that?
Coke not to my knowledge.
allison so, 2.3 unlikely
chromatic Right.
allison what's the priority for R*?
I'd say low, since it's needed for interacting with other languages, not implementing one language 20:59
so, 2.6?
chromatic Sure.
Coke wfm
allison done 21:00
documentation for parrot_debugger?
Coke I don't think that's a high priority.
allison 3.0?
NotFound allison: I'd rename that to "Improve parrot_debugger" 21:01
Coke improve isn't really closable.
allison NotFound: that's a separate ticket
(one with specific fixes) 21:02
NotFound Then I think is documented enough for his current functionality.
allison so, close?
I know some work went into it
NotFound I vote to close it.
allison I'll take ownership to check that we have an adequate manpage for the distros 21:03
and move it to 2.3
then close after that's done
bytecode migration tool and testing framework 21:04
I vote 3.0 or later
21:05 bubaflub left
Util 3.0+ 21:05
allison other thoughts? 21:06
going, going...
moved to 3.0
Make all PMCs Subclassable
TT#789
chromatic As in "Get rid of PMCProxy"?
allison that's not mentioned in the ticket at the moment 21:07
it's more of "get subclassing working any which way"
chromatic That one bites Rakudo more and more often.
allison it's specifically addressing attributes of C-PMCs that aren't I/N/S/P types 21:08
(had some discussions on IRC this week about it, so forgive the repeat):
Coke That has also hurt partcl in the past. (though it won't impact partcl-nqp)
allison PMCProxy is a temporary solution to the fact that C-PMCs don't have metaobjects for their Class 21:09
so, don't allow introspection
the can go away as soon as that changes
(Lorito or sooner)
anyone want to volunteer to write the "Deprecate PMCProxy" ticket? 21:10
21:11 chromatic left
Coke I don't understand what it woudl be replaced with. 21:11
21:11 chromatic joined
Coke (so, not I =-) 21:11
allison chromatic/Coke: on biting Rakudo/partcl, do you mean PMCProxy or non-register attributes?
chromatic Neither one in specific, merely the difficulty of subclassing.
I think the problem is crossing the PMCProxy boundary. 21:12
Coke allison: in general, the fact that Objects Ain't PMCs (or vice versea). There are things that you can (could?) only do in one case but not the other.
dukeleto is going to paste a late report
allison dukeleto: go ahead 21:13
or not
chromatic/Coke: okay, then we'll keep this ticket at an earlier milestone, say 3.4? and free it from any particular implementation 21:14
chromatic Earlier is better, if we can swing it. 21:15
dukeleto What I did: * Got PL/Parrot to pass ints and strings to PIR subroutines * Helping out students with their Parrot-related GSoC proposals * Added Parrot_PMC_push_* and Parrot_PMC_pop_* to PDD11 * Created TT# 1532 for Dynloadable runcores: trac.parrot.org/parrot/ticket/1532
What I will do: * Hack more on PL/Parrot * GSoC stuff
EOR
allison 2.4
(I meant to dype)
type
Deprecate pushaction, pushmark, popmark 21:17
chromatic 2.4 is good.
allison changed subclassable PMCs ticket to 2. 21:18
2.4
are pushaction, etc being used? do we need a replacement?
chromatic I think we deprecated them a long time ago. 21:19
allison there's no entry in DEPRECATED.pod
chromatic Time to add one! 21:21
allison adding an entry in DEPRECATED.pod, for deprecation in 2.3 and removal for 2.4
Configure probes for LLVM 21:22
blech, we really let the roadmap items pile up in 2.2 21:23
should we do the rest next week?
Util +1
Coke +1
mikehh we need to give some thought to prioritizing - so yes 21:24
allison a suggested second priority for the week: review 2.2 and 2.3 roadmap items
mikehh +1 21:25
chromatic +1
allison okay, closing up roadmap review, back to chromatic
chromatic Question time.
darbelo? 21:26
Coke q1q
chromatic No darbelo, Coke? 21:28
mikehh darbelo is not here
Coke Just wondering if we can get some guidance on a few tickets. #1118, and... digging.
eh. one a week is ok. 21:29
I vote we reject the proposal. too much complexity, not enough gain.
dukeleto q1q 21:31
Coke don't need to vote here. If you feel strongly, add a comment on the ticket.
allison Coke: I vote reject
Coke ... my timing, as always, is excellent. =-)
allison will comment in ticket
Util Advantage to deferring until IMCC replacement is in production? 21:32
Coke danke. 1 down, 655 to go.
Util: for me, it's not an imcc vs. pirc thing, it's a PIR thing.
(also, pirc is not going to be ready anytime soon.)
eoq & q1q. 21:33
chromatic dukeleto, question?
dukeleto I see that some PDD's have a postamble that has a maintainer, PDD version number, last-modified-by and other stuff,
which mostly seems out-of-date. Do we still want these?
Also, I would like to volunteer as a maintainer of the draft of PDD11.
Coke dukeleto: no.
(i would vote for removing the ancient author info from most of our docs.)
dukeleto Coke: so i get rid of all those fields?
this question was prompted by me updating PDD11 and seeing lots of crufty stuff 21:34
chromatic Deleting cruft is always good.
Coke last modified date might be helpful for folks reading on docs.parrot.org
dukeleto i am +1 to getting rid of most of the fields, except maybe Maintainer, which i think could still be useful
Coke who did the update is less helpful for the casual reader. 21:35
dukeleto Coke: i hear that, but it often is not updated
Coke dukeleto: then rip it out. Maintainer isn't going to be updated either. =-)
dukeleto Coke: i mean the metadata is not updated, while the doc is
Coke (perhaps we can update our pod2html process to put in a last modified date.)
allison author information goes in CREDITS, not in individual files
Coke allison: +1 21:36
dukeleto Coke: yes, I hear that. but it is nice to have a go-to person for a PDD, especially if it is still in draft
so are "PDD maintainers" a concept that we no longer need?
Util dukeleto: svn log for that info, or Trac
allison see the coding standards around line 850
dukeleto Util: sounds fine to me 21:37
allison dukeleto: aye, the team maintains the PDDs
dukeleto allison: sounds good. i will remove the crufty data in any PDD's that i touch
i will create a TT for removing the metadata from all PDD's 21:38
allison dukeleto: I removed it from the ones I launched out of draft 21:39
chromatic Coke, question?
dukeleto should the History section be left in PDDs?
allison: ah, good. so only the drafts still have it. i can probably take care of those
Coke chromatic: I have to run, so i'll just chime in quick: any deprecations we want need to get ,
dukeleto docs/pdds/pdd00_pdd.pod talks about the Maintainer and Version sections. should i remove that stuff? 21:40
Coke into this release notice for 2.3; I would rather be aggresive in what we list because we can always NOT remove it.
dukeleto Coke: +1 to having longer release notes rather than shorter
allison dukeleto: the Version is just the SVN revision number, which is fine
Coke it will be a good idea to check the remaining dynops & dynpmcs & libraries for things that are of questionable use.
gotta run. 21:41
allison dukeleto: ditch the History
dukeleto allison: ok
allison Coke: longer release notes are a good idea
Coke: and I'll move the dynpmc/dynop tickets back to 2.3 to remind us to enter deprecation items 21:42
chromatic Other questions? 21:47
mikehh we possibly need to look at nqp based tests 21:50
chromatic For libraries?
mikehh we had a problem in branches but now we have one failing codetest thinking it should be pir - t/profiling/profiling.t 21:51
thinks it should have a pir coda
when it is acvtually nqp based 21:52
actually
cotto_work I took a stab at fixing that but didn't get deep enough before I got distracted.
mikehh I was going to look into this last week but now it is coming up in trunk 21:53
cotto_work any reason this needs to be in #ps? 21:54
mikehh no - just thought I would mention it
cotto_work off to #parrot wit it then 21:55
mikehh as a possible problem that needs resolving
chromatic Anything else for #ps 21:59
?
Let's call it a week then. 22:00
Util $_ = 'week'
22:54 NotFound left 23:24 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!