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.
11:01 alexn_org joined 11:31 particle1 joined 12:05 bluescreen joined 13:46 PacoLinux joined 14:01 sorear joined 14:54 PacoLinux joined 16:49 wagle joined 17:32 NotFound joined 18:06 cotto_work joined 18:32 darbelo joined 18:37 bubaflub joined
darbelo DONE: 18:38
* Minor io-string cleanup and decoupling.
* Tested the release.
* Removed gdbm and digest dynpcs.
TODO:
* More io/str cleanups
18:38 dukeleto joined
darbelo .EOR 18:38
18:45 kurahaupo joined
Coke parrot: 18:56
* fixed up the ftp links to advertise "supported" instead of "stable", but had to keep old stable dir around for historical reasons, though.
* cleaned up PDD sections a bit.
partcl-nqp:
* initial support for tcl arrays.
* bring over [format], [vwait] from partcl
* run a lot of the test suite, TODOing those tests that are NYI in -nqp.
rakudo:
* fixed a single spec test.
* very minor ticket wrangling.
.
kurahaupo Is #ps still on at 1830utc?
(26 minutes ago) 18:57
Coke No. 18:58
moderator "Tuesday at 20:30 UTC" 18:58
dukeleto What I did: 19:16
* Added some POD to Tapir that is in core
* Realized that Tapir was in core (need to figure out from fperrad when it forked from the github repo)
* Wrote this blog post about PL/Parrot: leto.net/perl/2010/04/plparrot-flies.html
* My talk about Blizkost got accepted to YAPC::NA 2010 yapc2010.com/yn2010/talk/2670 19:17
What I will do:
* Stuff relating to GSoC
* Hack on PL/Parrot
* Work on Blizkost + PL/Parrot presentations
Blocking on:
.EOR
* PL/Parrot needs some security features from Parrot. I will ask more detailed questions on parrot-dev
NotFound What I did: 19:24
-parrot
* Minor fixes
* Testing
-winxed
* New predef function cry
* Environment var WINXED_PATH to locate stage's pbc
* Minor fixes
What I will do:
No plan
EOR
cotto_work #eor 19:42
allison What I did: 20:08
- Built test packages for Debian and Ubuntu in preparation for 2.3 release.
- Applied the fix for TT #389.
- Worked on the task list for GC refactors.
What I will do:
- Build (final) 2.3 packages for Debian and Ubuntu.
- Continue planning GC refactors.
EOR
20:14 chromatic joined
chromatic I worked on the immutable strings branch. It's ready to merge, pending a discussion from Rakudo as to when they want to deal with it. 20:14
I worked on line numbering and have a branch ready to merge there. That should fix up a lot of problems.
I looked at some optimizations. 20:15
I don't know how much time I'll have this week, and I'll try to be back in 15 minutes, but feel free to start without me.
Util # Done: 20:22
* Provided partial analysis for TT#1557 (pbc_disassemble fails on large PBCs)
* Found unrelated SigSegV with `pbc_disassemble` and namespaces/methods (Will ticket tomorrow)
* Opened TT#1570 #1570 (Out-of-date binaries/packages on Parrot.org) as requested in last #ps.
# Plan to do:
* None, or `pbc_disassemble` if time opens up.
# Blockers:
* $WORK
.end
japhb DONE: 20:24
20:24 eternaleye joined
japhb * Draft of first grant proposal to allison; review from same 20:24
TODO: 20:25
* Final version of first grant proposal to allison/board
* Fix ash's OpenGL warnings (decided not to do before 2.3 to avoid risk)
EOR
allison Hi all, who's here? 20:32
cotto_work hi
Util Hello
japhb o/
NotFound Hola
allison Let's get started. 20:33
How did we do on our weekly priorities this week?
Lots of testing for 2.3 20:34
from chromatic's report, it looks like we've got a fix for line number annotations
was there some documentation cleanup work? 20:35
(that may have been too general for a weekly priority)
good progress all around
What should our priorities be for this week? 20:36
Coke minor pdd cleanups, no content updates from me.
(on doc cleanup)
post-release, I recommend applying as many deprecations as possible. (already under full swing.)
s/under/in/
allison apply deprecations 20:37
particle i agree with coke, and add branch merging.
allison and also merge branches?
cotto_work That sounds like it'll happen whether it's a priority or not.
japhb q1q
allison yah, in this case, the weekly priority is about recognizing where the work focus should be for the week
chromatic Deprecations please.
Coke I just took the RetCon one, should be able to make that hit in the next day or so. 20:38
allison set the Priority topic on #parrot 20:39
chromatic Will the next Rakudo release target 2.3 or are they tracking trunk for the next couple of days?
allison I don't know. No moritz or jonathan today. 20:40
japhb pmichaud was about yesterday, looks like he's in #perl6 right now
dukeleto hola 20:41
japhb I just asked for pmichaud or jnthn to wander over
20:41 pmichaud joined
pmichaud here. 20:41
chromatic I have a Rakudo branch to make it work with immutable strings but I don't want to merge that branch for Rakudo until after the next release.
particle all rakudo releases track parrot releases
s/track/target/
allison for pmichaud: [21:39]\t<chromatic>\tWill the next Rakudo release target 2.3 or are they tracking trunk for the next couple of days? 20:42
pmichaud we target 2.3
allison makes sense
chromatic If we merge immutable_strings into Parrot now, will it affect the Rakudo release?
pmichaud I haven't heard anything to the contrary, and standard policy is that rakudo releases target parrot releases (unless we can't)
particle it shouldn't, unless parrot releases 2.3.1
chromatic We can cherry pick to make a 2.3.1 if necessary. 20:43
particle well, then, merge away.
pmichaud confirming on #perl6 now
allison particle: if we did, it would be bug fixes only, not full trunk
japhb Has the mandlebrot rakudo test been done against Parrot 2.3 yet? Earlier I noticed it had very bad memory behavior ...
chromatic No, I haven't looked at it yet. 20:44
pmichaud consensus on #perl6 is that we're following normal process this month -- i.e., rakudo #28 release will target Parrot 2.3.0 release 20:45
so merge away
chromatic Thanks.
allison Roadmap review next. 20:46
With the process changes discussed on the mailing list, the "Roadmap" tab in Trac is no longer the Design roadmap.
pmichaud (btw, "merge away" was meant for Parrot to merge in immutable strings, not to apply the changes to Rakudo yet :)
allison It's just the collection of tasks we hope to get done in a particular release.
pmichaud (changes to Rakudo take place after the Rakudo release)
20:47 PacoLinux joined
allison (which seems to be how we mostly use it anyway) 20:47
I don't see any roadmap tasks tagged for 2.4 anyway
the list there is mainly deprecations
same for 2.5 20:48
2.6 has a few, so will quickly run through and see if some should be removed
- Implement Async I/O 20:49
Is that a priority for 2.6?
chromatic Rakudo needs *better* IO, but I'm not sure that it needs async IO right now.
japhb Personally, I see that as a nice to have, not a priority (the async part, I mean -- I agree with chromatic)
cotto_work sounds like it'd go well with the Parrot hybrid threads gsoc proposal 20:50
allison let's drop it from the roadmap, keep it as a ticket (or on an I/O tasklist)
tewk A select PMC would be a nice compromise until full async io lands.
japhb tewk: +1
allison cotto: probably after GSoC
tewk: that's a good idea
chromatic Can someone put Select on a wishlist page on the wiki? 20:51
allison need to add the page
- next cross-compile configuration 20:52
this is important for building for, say, Android
is it a priority for 2.6?
particle i don't have an android device yet, so not for me
how about working on security, for pl/parrot? 20:53
japhb Won't this be part of the RTEMS gsoc, if they are approved?
allison japhb: yes
20:53 kurahaupo joined
dukeleto security++ 20:53
japhb: what will be part of RTEMS gsoc? 20:54
allison particle: security is important
japhb dukeleto, I meant the cross-compile; is there a PL/Parrot gsoc as well?
allison I'll list the other tasks currently on 2.6 and we can pick what our next "supported release priority" should be
pirc, bytecode generation from post, JIT, portable runtime, sweep-free gc 20:55
all good tasks, but none are grabbing me as "this is the big thing we should work on for 2.6"
the one we said in the virtual dev summit was GC 20:56
chromatic GC is it for me.
Coke pirc doesn't even compile at the moment. are we sure we want it to be the replacement for imcc?
japhb What is portable runtime again?
(And I vote GC as #1 priority)
allison japhb: like APR (apache)
japhb ah
allison Okay, on the roadmap wiki page, I'll list GC as the development priority for 2.6 20:57
that wraps up roadmap review
chromatic, do you want to run questions?
(and q1q from me) 20:58
chromatic Sure, let me backlog and find questioners.
japhb (my question went away earlier)
dukeleto japhb: no, PL/Parrot is not part of GSoC
japhb dukeleto, ah, OK
chromatic If japhb has no question, then it's allison time.
allison I'm working on the GC tasklist, basically "what do we need to do next?" I'm collecting a list of the pain points in the current GC. What are yours? 20:59
chromatic compact_pool is silly. Exceedingly silly.
allison speed and concurrency are the two big ones I've found so far
chromatic It's also bad for cache thrashing. 21:00
allison can you expand on silly?
chromatic Sure: it copies all compactable pools even if they're completely full or almost full.
allison (it probably needs to be taken out behind the shed and shot, but I'm also looking for what to replace it with)
chromatic That's busy work.
A big problem with the current GC is that it never can free allocated pools if the working set shrinks dramatically. 21:01
There are reasons you might not want to do that... but it's a flaw, because sometimes you do.
cotto_work afk
Coke (tasklist) start with all the tickets that are on the GC component?
allison Coke: yeah, I'm also doing ticket review 21:02
I'm looking for big-picture
tewk chromatic, to solve that you need a precise compacting collector.
allison as in "if I were doing research on completely replacing the GC (which I'm not really, not quite, anyway) what would I be looking for
chromatic Whatever we do, we have to be able to identify and collect short-lived garbage much more cheaply. 21:04
We can avoid that pain to some extent by reducing the amount of garbage we create (and that's been my strategy), but if we want to make function calls less expensive, we have to do this.
mikehh should we be using different pools?
to what extent do we know if it is going to be short-lived? 21:05
chromatic Without escape analysis, we don't know precisely.
We can suspect: most continuations don't survive past their return. We can probably play games with morphing and upgrading when we capture a continuation. 21:06
allison CallContexts are also pretty much always short-lived 21:07
mikehh I have been looking at aspects of copying collection - only used items are copied
chromatic But that gets into the madness of compact_pool. 21:08
mikehh yeah
bacek o/
allison okay, this is a useful brainstorm
I've taken notes
and feel free to email me more ideas 21:09
(even if it's no more than "hey, I had a crazy thought..."
bacek (compact_pool) I have a branch for improving compact_pool. Unfortunately it's slower then trunk...
allison bacek: branch name?
bacek compact_pool_revamp 21:10
allison thanks, will take a look
end of question, back to chromatic
chromatic Other questions?
Comments? Concerns? 21:11
Okay, let's wrap it up them. Merge time.
21:34 kurahaupo1 joined 21:38 chromatic left 21:45 NotFound left 22:52 Whiteknight joined 23:48 eternaleye 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!