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.
00:58 ascent joined 02:50 mariano joined 09:04 sorear joined 13:59 plobsing joined
plobsing likely won't make #ps 14:00
What I Did:
* stringnull support everywhere (including packfiles)
* make config.fpmc a HoS (saves space, faster to thaw => startup should benefit)
* nci deprecations (mainly UnManagedStruct)
What I Plan: 14:01
* more nci deprecations (focusing on dlfunc)
* convert libjit framebuilder to use hooks added for dynamic frame builder
* use as a prototype for framebuilder add-on libraries
* start an alternate frame builder
* try to do it in PIR (should be doable using callback interface)
* candidates: cc (pitched as posix by sorear++), tcc
EOR
15:30 ascent joined, tewk joined, mikehh joined, eternaleye joined, PerlJam joined, integral joined, Util joined 15:50 tewk joined 17:48 cotto_work joined 19:31 jrtayloriv joined 19:36 tcurtis joined 19:38 darbelo joined 19:43 bubaflub joined
japhb DONE: 19:47
* Parrot Quarterly Meeting. Rock.
* Perl6-lang discussions
NEXT:
* Plumage grant proposal
* Plumage separable tasks -> dukeleto
EOR
darbelo DONE: 19:48
* Explored making STRINGs smaller. Ran into trouble with code not respecting encapsulation.
* Discovered some of the dirty tricks we play with strings and buffers.
* Started removing some of the worst offenders. Once I'm done with IO we should be good.
TODO: * Remove the last fake strings and other encapsulation breakages in IO.
* Try again to slim down strings.
EOR
19:56 cotto_work joined
Coke did: some work on partcl-nqp; unborked parrot lexical handling. EOR 19:57
mikehh What I did since my last report: 20:00
* building and testing parrot on amd64/i386, with gcc/g++
* some fixes
* added to trac wiki
What I intend to do in the next week:
* testing and fixing
* continue looking at integrating nqp into codetests
* documentation
.eor
20:02 NotFound joined
NotFound What I did: 20:07
* Almost nothing, lack of time.
What I will do:
No plan
Util # Done in the last two weeks (missed last #ps meeting): 20:11
* Provided analysis for TT#1541
* Attended Parrot Virtual Developer Summit
# Plan to do:
* No plan yet
# Blockers: 20:12
* $WORK
.end
20:12 chromatic joined
chromatic Worked on immutable strings; the branch is almost 5% faster than trunk. 20:13
No work on line numbers in PIR; blocked on a test framework.
Worked on a few optimizations; 2.3 is going to be the fastest Parrot in a long time.
Will continue to focus on immutable strings, constant string caching, and line numbers (the latter the highest priority).
Coke Q1Q: {Suggested focus this week: documentation improvements, since we shouldn't be mucking with code just before a big release anyway.}} 20:17
chromatic Will be a few minutes late; feel free to start without me. 20:22
20:25 allison joined
allison Last week: 20:27
- The virtual development summit was a success.
- Implemented the fix needed for TT #389, fixed the few failing tests (that were pulling a method from the namespace without marking it with :sentry), and added some new tests. Not committed yet because PGE still depends on methods being stored in the namespace. Working on that now.
- Fixed some problems with authentication on the /languages repository and trac instance.
Next week:
- Work on the task list for GC refactors. 20:28
- Work on porting roadmap tasks to the wiki.
EOR
s/sentry/nsentry/
cotto_work #did: 20:30
* reviewed and rated more gsoc proposals
* took a stab at testing the line numbers of all pir files in t using ProfTest code
* it turns out that parsing each line of the profile with a grammar is prohibitively slow (~2 min per pir test file)
* using subst might work reasonably, perl 5 or manual parsing is probably the best bet 20:31
* no tuits likely until this weekend
* if someone else wants to do this before then, the relevant code to get a profile is in runtime/parrot/library/ProfTest/PIRProfile.nqp
#will do:
* not break the release
#closed TTs:
#eor
HELO 20:33
NotFound Hola.
mikehh hi there
darbelo EHLO
japhb o/
chromatic Hi. I have to talk to a client; can someone else run things? 20:34
mikehh allison? 20:35
allison hello 20:36
Did anyone not report yet?
How did we do on our priorities last week? 20:37
those were line number annotations and GSoC applications
cotto_work line numbers ran into surprise slowness
allison as in, the fixes caused slowness in execution? 20:38
cotto_work didn't have tuits to speed up the profiling test code
no, the testing code is too slow to be usable on any significant subset of our pir tests 20:39
~2 min per pir test file
allison ah, slowness in the testing framework
that is surprising
further work on that this week? 20:40
cotto_work from me, this weekend looks plausible 20:41
allison great
We got a good round of GSoC applications
several are quite promising (including 2 mentioned in the virtual summit)
now just waiting to hear how many slots TPF got this year 20:42
cotto_work q1q
allison we'll do questions, and then roadmap 20:43
cotto?
cotto_work PVMW: we gonna have one or not? I want to buy my plane tickets for yapc.
allison there may be something Rakudo related, but not a Parrot workshop at YAPC 20:44
cotto_work eoq then
darbelo Coke prepasted 1q 20:45
allison (we didn't want to exclude non-Perlies)
darbelo: could you copy Coke's q in? my scrollback doesn't go that far
darbelo Q1Q: {Suggested focus this week: documentation improvements, since we shouldn't be mucking with code just before a big release anyway.}} 20:46
Not much of a q, now that I look at it.
allison That's an excellent idea.
Do we have volunteers to work on documentation this week? 20:47
(The new policy being to only set weekly priorities if we have at least 1-2 people working on the task.)
mikehh I already intended to 20:48
allison That's one
I'll help
mikehh but what specifically needs doing?
japhb I *may* be able to do some work on distutils doc this week. 50-50.
cotto_work mikehh: filling in stub documentation is great. 20:49
mikehh 'k
Util Is there a simple way to list the stubs?
japhb (distutils has a lot of stub docs that I found confusing while interfacing to it, so maybe this is a hint to put my hard-won knowledge back into the source. :-)
cotto_work if you get confused, ask in #parrot.
darbelo Util: not waht you are asking for, but now the headerizer warns about functions with no POD. 20:50
cotto_work Util: t/codingstd/c_function_docs.t gripes about boilerplate-only docs.
mikehh there is a list in the Wiki 20:51
Util thanks 20:52
allison Any further questions? 20:53
So, we'll pick up documentation as this weeks priority, and drop GSoC applications (since that's closed). 20:54
Do we want to keep line number annotations as a priority? 20:55
cotto_work gsoc review and scoring is still valuable
I'll be working on it either way if chromatic doesn't get impatient to do it himself.
NotFound I'll try to look at it, but don't expect to have much time available this week. 20:56
allison okay, I kept line number annotations 20:57
On the roadmap review, I'll skip the usual ticket run, since we're changing the process there after the virtual dev summit 20:58
mikehh make sure everything is ok for the release
allison mikehh: good idea, added
is there anyone here who wasn't at the virtual dev summit? 20:59
NotFound Me
cotto_work afk; will backscroll
allison and for those who were, are we comfortable with the process changes?
darbelo wfm 21:00
japhb yes
mikehh let's see how they work
allison particularly, a chance to speak before we dive in and convert a pile of tickets to wiki pages
NotFound I lacked the time to look, so no chance. 21:01
But no problem anyway.
allison NotFound: the big change is to a policy of only using Trac for bugs
NotFound Good
mikehh I think one of the problems has been in setting the ticket tags/reasons etc
allison NotFound: and using wiki pages for development tasks
Coke allison: I am not convinced that moving wishlist items to a wiki page is helpful. 21:02
allison mikehh: problem in the old strategy or in the new one?
Coke but I'm also not opposed to it. I agree we could manage our existing tracs better.
mikehh allison: old
allison Coke: we talked about that a fair bit 21:03
mikehh too many non-bugs not set as RFC or such
allison Coke: I can't guarantee it'll help wishlist items get more attention 21:04
Coke: I suspect it'll be about the same attention
Coke: but I do think it will help us see bugs more quickly
Coke: and help us stay on top of them
right now bugs tend to get lost in the development tasks, roadmap items, and wishlist items 21:05
basically, I'm not sure either, but it's worth trying 21:06
Coke: what do you think about maintenance
Coke: will wiki pages be more difficult to maintain? 21:07
Coke: more prone to staleness?
(I ask because you and kid51 do a lot of the ticket queue maintenance)
Coke yes, It's more of a pain to maintain and report on. 21:10
(if you want to see only bugs, I can whip up a trac report for that.)
(skip rfcs, roadmaps, wishlists, etc.)
Would that help? 21:11
(sorry, also $DAYJOBbing here.
21:11 allison joined
allison what was the last thing that got through before I timed out? 21:12
okay, got Coke's reply from the archive 21:13
It would help, but I'm not sure it's enough
A lot of the wishlist items are things we never intend to work on, or at least not for a long time 21:14
Though, a bigger problem is the lack of ability to group development tasks by... well, basically by branch 21:15
bacek ~~ 21:16
Coke I'll add a report this evening and advertise it on list.
allison Coke: that's helpful, thanks
Coke I can also update existing reports that shouldn't have wishlist items. 21:17
allison Coke: there is something valuable here, and it's more of a subtle perspective shift than an earth-shattering change
we have been using wiki pages more and more for development tasks 21:18
and tickets less and less
Coke I see no problem using task lists to flesh out existing tickets.
allison but then what do we need the ticket for? 21:19
Coke to track and report on progress?
allison we do that on the wiki page
(we already do that on the wiki page)
Coke who reads that?
the people working on the tasks.
allison aye 21:20
who reads the ticket?
same people
Coke it's scattershot, there are over a dozen task pages, all differently named.
allison right, so a big part of it is organizing the wiki pages
one page for "wishlist" , one page for "development tasks", likely grouped by "active", "inactive", etc 21:21
we need to do that anyway
Coke or we could, I don't know, use trac. =-) 21:22
allison we are using trac
Coke a wiki that happens to be in trac, sure.
allison a different part of trac
the nice thing about trac is, they're all integrated
Coke the reporting functionality is not linked in, no. 21:23
allison wiki syntax works in tickets, ticket and revision links work in wiki pages
aye, that was my major complaint too
but, what do the reports tell us?
about development tasks 21:24
Coke which makes it a waste of time for me.
allison it's important to track our bug stats
chromatic Tell me how to write and maintain this wiki page in bug reports, and I'll use bug reports to manage my tasks: trac.parrot.org/parrot/wiki/Perform...provements
allison but is it important to track stats on every development task and wishlist item?
Coke And what's going into a particular revision. I am not sure why you think we'll get better traction via wiki than via tickets.
allison actually, I think the work we do will be equivalent 21:25
not that more tasks will get done
Coke I mean the tracking.
allison but that the important bugs won't get lost
Coke "i'm working on these tasks", or "we should have this done for this release". 21:26
they're not lost now.
But we're not getting anywhere here. Do what you need to, that's fine.
allison ah! that's the important process change we started with first
Coke I had to leave 30m ago. ~~
allison are you okay with trying it out? 21:27
not going to ask you to do huge ticket conversions or anything
(I actually think converting old tickets is mostly a waste of time) 21:28
Coke conversions - i can guarantee that I won't be doing any more ticket conversions, ever. 21:29
(the RT to trac burned me out on that.)
allison It burned out all of us.
21:30 plobsing joined
japhb plobsing, we're an hour in ... 21:30
plobsing just glad I made it at all. reading log now. 21:31
allison Coke: thanks for the feedback, we'll spend some more time thinking through the details
Coke: (when one of the two people who do most of the maintenance work on a system aren't enthusiastic about a change, it's important) 21:32
Any more questions or comments before we wrap up for the day? 21:33
21:33 Whiteknight joined
Util q1q 21:33
allison Util: go ahead
Util is it known that many binaries/packages linked to on parrot.org/download are out-of-date? 21:34
Cygwin, MacPorts, and Debian, at least.
allison Util: hadn't looked at it lately
Debian you're absolutely right, that's the wrong link 21:35
that was the substitute while we were waiting for Debian to sync recent Parrot packages
none of the others look like they include version numbers
is it just that those distros are behind?
Util The MacPorts portfile is for 1.0, and has MD5 sum for it. 21:36
allison I also notice that we don't include distros like Fedora or SuSE
japhb With the Perl 5.12, I was looking at the perl.org download page. Very swank. WBNI we could do something similar. 21:37
(Not as flashy as say Firefox downloads, but I think it fits the target audience well.) 21:38
Util I have no suggestions yet for process improvement; just bringing the problem to light. Their may always be a lag on platforms that the release manager cannot update directly. Good PR if we can make it work, though.
allison japhb: yeah, that's definitely possible
japhb: most of our instructions are "follow your packaging system's install procedure" 21:39
Util: so I want to say "could you submit a ticket for that?" 21:40
japhb Sure, but it's the Windows and Mac people that we need to care about in this case, because they don't have a unified packaging system (yet).
Util allison: will do
japhb And they're the ones most likely to go to a downloads page.
allison japhb: aye, but we don't do binary builds for Mac/Windows
japhb Someone was doing that in the past (Windows, IIRC) ... did that get dropped? 21:41
allison there's a sourceforge project
it's listed on that page
Util Win32 released 2.2 the same day as we did.
allison (updated to 2.2, I just checked)
Util Looks like Rakudo for Win32, too. 21:42
japhb Good. And it's not that parrot.org/download is *bad*, just that perl.org's version seems more ... inviting somehow. 21:43
allison okay, we'll work on that a bit, see if we can spruce it up
21:43 cotto_work joined
allison more q's? 21:43
mikehh have we had any thoughts on runcores? 21:44
cotto_work mikehh++
mikehh might be a good idea to get deprecations in with 2.4
sorry 2.3 21:45
cotto_work Most of them are never used and will add extra work to the ops_pct branch.
iwbn to get rid of some of them
allison That's a wrap, thanks everyone, talk to you next week.
cotto_work ?
21:46 allison joined
mikehh I think allison had to go 21:46
oh back
allison apologies, really strange network lag
cotto_work so, about trimming down our runcores... 21:47
allison I didn't see any answers from anyone for a couple of minutes
mikehh from the testy point of view - I think we need testb, testF and testr 21:48
testf
allison yes, runcore deprecations in 2.3 are a good idea
(reading from log)
cotto_work allison: which ones do you see as less than valuable? 21:50
mikehh as I see it the runcores were experimental and I don't know if anyone uses them these days
I think we need to keep the ability to add - especially jit if it arrives 21:51
allison I don't know that those count as runcores in the sense of something we compile separately 21:52
cotto_work we have slow, fast, switch, exec, gcdebug, debugger, cgoto, cgp and profiling
allison It's cgoto, cgp, and switch that have to be compiled into separate .o files 21:54
mikehh for example does any use cgoto, cgp, switch or exec
cgoto, cgp and switch are tested in fulltest, but otherwise? 21:55
21:55 allison joined
cotto_work reducing the amount of perl code required for preprocessing .ops files into C is my motivation here 21:55
allison yes, and also reducing the bulk of libparrot 21:56
how about a mailing list proposal of what to deprecate? 21:57
that'll give us a wider set of comments
We can always put in a deprecation notice, and not remove everything we deprecated, if it turns out it is needed. 21:58
cotto_work ok
allison do you want to post, or should I do it? 21:59
should be a quick one
so, not a big deal
cotto_work you can commit from where you are
I have to wait for cotto to take care of it. ;) 22:00
allison :)
okay, I'll spend a few minutes on it right after this 22:01
cotto_work thanks
allison Let's call that a day.
Util cgoto/cgp/switch always seemed to me to be about keeping options open about performance, back when we had not built enough of Parrot to tell if one of the runcores would be a clear winner for all platforms and all client languages.
Do we have a sense of a clear winner now?
nm. will take to mailing list
allison Util: we don't, and profiling would be a good idea before we drop the axe 22:02
Thanks all!
22:03 chromatic left, PacoLinux left 22:30 wagle_ joined 22:52 cotto_work left 23:02 plobsing left 23:06 tcurtis joined 23:34 mariano 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!