Vision for 2.0: Production Users | Priority for 1.6: Merge Branches | Priority for this week: Fix partcl segfaults & PANICs, increase test coverage on Namespace and Array PMCs, prune a struct | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
Set by moderator on 4 October 2009.
00:33 cotto joined 02:52 cottoo joined 02:54 cotto joined 07:09 kurahaupo joined 09:09 mikehh joined 09:20 particle joined 09:55 particle joined 11:41 kid51 joined 13:08 particle joined 13:54 PacoLinux joined 14:30 PacoLinux joined 16:08 davidfetter joined 16:50 cotto_work joined 17:05 whiteknight joined
pmichaud What I did: 17:13
* Mainly worked on regex refactors
* Started work in branches/pct-rx in parrot svn, but have since decided to move all of the work to nqp-rx repository on github
* End result will be a new implementation of NQP that is also able to compile Perl 6 regular expressions (including protoregexes and longest-token-matching semantics).
* Have a working implementation of protoregexes, now just need to tie all of the new pieces together 17:14
* Have a draft implementation of a new extensible operator precedence parser, with NQP source equivalent
What I'm doing this week:
* More regex engine work
* Fixing up the build system of the nqp-rx project
* Trying to figure out how to get all of the components bootstrapped
What I'm blocking on:
* Time
EOR
17:18 NotFound joined 17:19 Util joined
cotto_work no report this week 17:24
whiteknight WHAT I DID: 17:30
* Helped organize and advertise the weekend's hackathon. Was a big success! 17:31
* Worked on PCC system, fixing tests mostly.
* Wrote up some documentation about how argument processing happens
* Updated some *Tasklist pages on the wiki
* Answered questions on IRC
WHAT I PLAN TO DO:
* PCC: strike while the iron is hot. Would LOVE to get it merged before 1.7.0
* Trunk seems to have some problems, especially with --optimize. Need to dig into that
* Miscellaneous JIT preparations
* Documentation
WHAT I AM BLOCKING ON:
* Not enough time
EOR
japhb DONE: 17:35
* use.perl.org/~geoffrey/journal/39697
* use.perl.org/~geoffrey/journal/39713
* Plumage now able to install Rakudo
WILL DO:
EOR
Hmmm, that's odd, my report is missing lines in irclog.perlgeek.de/parrotsketch/today ... 17:37
17:40 jonathan joined
japhb Oh interesting, I think I got throttled but my local client showed them as sent 17:45
sending report again in pieces ....
DONE:
* use.perl.org/~geoffrey/journal/39697
* use.perl.org/~geoffrey/journal/39713
* Plumage now able to install Rakudo
WILL DO:
* Hack, hack, hack
POTENTIAL BLOCKERS:
* Need to find a place to host metadata repo. Suggestions?
EOR
OK, that looks better 17:46
mikehh What I did in the last week: 17:49
* only managed 11 builds/fulltests on trunk only one of which was on i386 - the rest on amd64
* (there weren't that many commits to trunk)
* most of my time was spent building/testing on pcc_reapply branch
* make/make world does not build - used make corevm (with normal config parameters on amd64)
* make codetest/make manifest_tests did run and managed to fix (eventually) all failures there
* make headerizer did not work in the branch
* spent nearly all my waking time on Friday/Saturday/Sunday on the branch - Monday was a complete write-off
* make smolder_coretest got only 39 failures at r41710/#28557 but this increased to 59 again at r51727/#28571
* and was the same today r51733/#28614 - kid51 had a lot more problems on i386
* meant to install Ubuntu 9.10 beta - never got around to it
What I intend to do in the next week:
# continue testing in trunk and branches
# install Ubuntu 9.10 betas and test parrot on it
.eor
Tene * Work on PCC. Going to make another try to finish fill_params tonight. 17:51
That's probably all for this week.
Unless someone assigns me a specific task. 17:52
KTHXBAI
pmichaud I should also report that I'm extremely pleased to see all the progress on the PCC refactors. 17:57
jonathan * Back from my vacation in far east Asia...probably my last serious vacation before Rakudo *. 18:02
* Spoke at YAPC::Asia and for Seoul.pm too - plenty of interest from both :-) 18:03
* Got my grant for working on signature refactors approved
* "Eased" into it today by doing some refactors that make actions.pm cleaner and will let me change the way we build signatures more easily
* Expecting to make loads of progress on signature changes this week
* Also need to do some blogging - Blizkost also made progress on my Rakudo day before I went away as well as while-I-was-away hacking. One big bug to fix, then I think it may start to be quite useful, at least on Win32 (will need help on other platforms).
* Am liable to block somewhat on the PCC branch, so *very* happy it's a many person effort now - thanks everyone!
.end
NotFound 2009-oct-06 18:04
What I did:
* Add deprecation notice for TT #918.
* Some bug haunting on pcc_reapply.
What I will do:
* No plan.
EOR
18:07 kurahaupo joined 18:09 allison joined
allison - Created a new branch for the PCC refactor, merging the existing changes with a fresh branch of trunk. Fixed up merge problems to ready the branch for group effort. 18:10
- The hackathon this weekend was very productive. Spent as much time as possible on IRC, answering questions so others could work on the branch too.
- Changed generated VTABLE stubs in Object to use the new PCC.
- Broke arg/param/return/result handling in to a separate file for sanity.
- Worked out a new arg/param handling algorithm with Whiteknight on IRC to be more maintainable, implemented it, fixed several bugs/found missing features in the process.
EOR
Util # Done 18:15
* Poked at broken std_hilite/STD_syntax_highlight
= inspired by moritz++ : perlgeek.de/blog-en/perl-6/parse-tree.html
= working kludge achieved, but no peer review requested yet, so no patch yet.
* Removed bogus properties from files and root dir in Parrot repo. (r41736,r41737)
* TT#600 (bytecode testing framework) - Stalled
= have not replied to comment from dukeleto++ , nor led discussion yet.
* TT#994 (git-svn auto-props) - Testing in branches/autoprops
* TT#389 (keeping subs with :method out of the namespace) - Caught up with Allison's thinking.
# Plan for next week:
* Continue work on TT#994 (to completion) and TT#389 (time allowing), and prod #parrot for discussion of TT#600.
# Blockers:
* None.
.end
kurahaupo Converted ResizableIntegerArray ļ»ætests to PIR, discovered & fixed some missing test coverage in the process <EOR>
18:21 Coke joined, barney joined, darbelo joined
darbelo THE PAST: 18:22
(parrot)
* Obliterated the old and unused GC_IS_MALLOC code.
* Ripped out the old pmc2c tests
* Removed strstart uses in the debugger with the help of dukeleto++
* Some more strstart removal is pending on win32 testing. (nopaste.snit.ch/18236)
(partcl)
* Updated copyright and licensing information to PaFo and Artistic 2.0
* Error: partcl install failed with ENOTUITS
(plumage)
* Generated partcl metadata file. Runs 'make test'
THE FUTURE:
(parrot)
* Take a shot at fixing the frame builder on the pcc_reapply branch.
(partcl)
* keep working on the 'install' target. 18:23
THE IMPEDIMENTS:
* Tuit shortage.
.EOR
dukeleto Past: My write up about Perl and Parrot in GSOC2009 got published on the Google Open Source Blog: google-opensource.blogspot.com/ 18:27
Coke (All partcl)
Done: - switching over to github. (dukeleto++) - worked on switching to use parrot's call chain. Looks like we can't yet
- running spec test occasionally.
Coming up: - finalize switchover to github (dukeleto++)
.
- ping pmichaud on pct cutover. - combine 3 makefiles into a single one, improve deps (See code.google.com/p/partcl/issues/detail?id=111)
Blocking on: - tuits
dukeleto Future: Continue to convert tests to PIR and benchmark released versions of parrot against trunk with euler_bench
Blocking On: Too many cool things to hack on 18:28
japhb Coke: q1q 18:30
allison looks like no chromatic this wek 18:31
Let's start with the roadmap review. 18:32
trac.parrot.org/parrot/report/14
hll export?
whiteknight I had expressed interest but have done no work on it 18:33
allison okay, interested parties absorbed by other priority (pcc branch)
documentation for parrot_debugger?
18:33 chromatic joined
allison iirc, that was dukeleto 18:34
I'm taking that as no progress this week
seed libraries? 18:35
looks like japhb has been making good progress
japhb allison, yeah, Plumage is going well
allison at least, he mentioned hosting for the metadata
excellent
what do you need hosted?
mysql + web interface? 18:36
japhb I need a place that's outside my firewall to have a mod_perl + mysql instance, where I can install arbitrary modules
allison (i.e. html and json)
japhb yeah
NotFound Mysql is now able to be installed from plumage in unix-like platforms
allison mod_perl?
japhb It's not time critical, I'm mentioning it now to keep it out of my critical path later
allison you're using mod_perl for serving the web pages and data? 18:37
japhb allison, I suppose CGI or FastCGI is possible,
allison japhb: mod_parrot eventually? :)
whiteknight any reason it can't be mod_parrot :)
japhb I'm just a mod_perl guy, so it's my default way to host something like this.
allison, heck yeah. And in fact,
I'd be happy to do that if it was ready by the time I was.
allison okay
japhb (And the performance wasn't abysmal)
allison I'm thinking this should be hostable on parrot.org 18:38
will check with our admins
japhb allison, cool.
thank you.
allison bytecode testing framework? 18:39
japhb smiles at the thought of writing mod_parrot code.
Util TT#600 (bytecode testing framework) - only progress is a vote from dukeleto++ for running both .pir and .pbc versions of the testing as the default. I need to carry it into #parrot; among other issues, running both will more than double our current `make test` time.
I will make time tomorrow for the discussion, at the latest.
allison Util: aye, it's something that should be an option for fulltest, but not part of the default tests
sounds good 18:40
prune c data structures?
chromatic I have notes. I haven't put them on the wiki or implemented them yet.
I'm a bit leery of making large trunk changes pending a PCC merge.
allison chromatic: yes, that's sensible
chromatic, would you like to take over for the weekly priority review 18:41
(so far we've done roadmap review)
chromatic Is the roadmap review over?
allison yes, that's the last item
whiteknight yes
chromatic Last week's priority: the hackathon. 18:42
Thoughts?
allison a huge success
whiteknight huge
pmichaud agreed
let's do it again. now. :)
whiteknight and we're coming out of it with a lot of momentum and a much higher bus number on that system
allison it had a big impact on motivation and collaboration
darbelo We should have one every week.
chromatic Is every week too often? 18:43
whiteknight every week might be pushing it, if we don't have clear goals
allison yes, probably
whiteknight busywork is no good
allison it's definitely a push
whiteknight I say about once per month, assuming we have good candidate tasks to work on
allison with a corresponding dip in productivity right after
whiteknight maybe more, maybe less
allison one a month is probably about right
darbelo one or two a month is a bit more realistic. 18:44
allison depending on the tasks at hand
chromatic How about the size of the hackathon tasks?
allison and, towards the early side of the month for development merges
this one was a good size
a branch that's nearly finished
we dropped it from 900 failing tests to 58-ish 18:45
whiteknight the "saturday" for the hackathon started friday evening and ended sunday evening
so that might have been too big a task
(but very necessary)
chromatic Other thoughts?
allison whiteknight: even if we'd only cut the failing tests in half it would have been a good hackathon
whiteknight yes, and we knocked "half" out of the water! 18:46
allison I'd like to revive the announcements of "testing sprints" before releases 18:47
whiteknight agreed
chromatic Testing sprint?
allison sort of related to hackathons, but not quite the same
particle previously known as "bug day"
particle arrives, late 18:48
whiteknight development sprints towards the beginning of each cycle, and testing sprints towards the end
mikehh we still need to to get the full build to work in pcc_reapply - and I would like to test the other cores
allison that reminds me: q1q
whiteknight yes, lots of work still on pcc_reapply, and then I'm sure the merge will be eventful
allison (chromatic: japhb had a q1q at the start)
whiteknight plus HLL testing
chromatic Shall we tentatively plan a testing weekend on the 17th and 18th? 18:49
darbelo +1
mikehh +1
allison +1
chromatic Okay. Let's go to questions.
japhb? 18:50
japhb It sounds like partcl will be switching repos this week, correct Coke?
particle q1q
japhb If so, can you send me the new repo info, or a patch against the metadata in Plumage, please? 18:51
dukeleto japhb: i am working on partcl->github, so I can help with that
japhb That was it, but we seem to have lost Coke.
dukeleto 'ello, by the way
chromatic allison?
japhb dukeleto, ah, cool, thank you.
darbelo japhb: I can do that when the move's done.
japhb excellent
Util q1q
allison my question is about src/frame_builder.c 18:52
it's the last remaining bit of the old JIT
as I understand, kept for speed gains on x86?
NotFound allison: IMO his own advantage is that it doesn't need a reconfigure when you need a new signature. 18:53
allison it was bunged up a good bit when the old JIT was removed, so a bit shaky
NotFound s/own/only
allison and, it completely doesn't survive the PCC transition
NotFound Let's kill it!
allison so, the question is, is it worth delaying the PCC branch merge to get it working again? 18:54
chromatic It's the only useful part of the old JIT and it does get used.
allison or, can we disable it temporarily, and get it working again later?
whiteknight but alternatives are already popping up
we have a libJIT-based framebuilder on github for starters
mikehh it was causing major problems with i386 in the branch
whiteknight an LLVM-based one would be a good kickoff to the rest of our JIT work
chromatic There are three different questions here. (more) 18:55
mikehh kid51 had to disable it to get tests to pass
chromatic 1) Should it block the branch merge?
allison mikehh: at the moment the code doesn't work with the new PCC, guaranteed
chromatic 2) Is it useful as-is?
3) What are likely replacements?
mikehh it doesn't bother me on amd64 though :-}
whiteknight ditto :)
allison mikehh: as far as I understand, it's always disabled on amd64 18:56
NotFound To avoid problems with testers we just need to make --buildframes=0 the default.
allison mikehh: that is, it only ever works on i386
mikehh didn't do the old jit
whiteknight If we have a firm plan to have a replacement in trunk by 1.8, can we remove it now? 18:57
chromatic Let's take the questions one by one.
Should it block the branch merge?
particle i think as long as we have a replacement by 2.0 we can remove it
and the branch merge should not block.
whiteknight no. Branch has been too far delayed as-is
allison to one, I'd say no, it shouldn't block the merge
whiteknight and HLLs are hurting for it as is
chromatic Objections?
particle we must have a replacement soon. 18:58
chromatic <crickets />
#2 -- is it useful as-is?
mikehh no
particle and as a side, it's sad to see the last bit of gsoc code removed from parrot. again.
whiteknight barely, only on x86 I think
chromatic It improves startup time on x86 32-bit by ~15%.
It reduces libparrot.so size measurably.
particle *as an aside 18:59
chromatic On the con side, it doesn't handle all signatures appropriately.
NotFound It fails to run opengl examples
particle that might be opengl's fault
chromatic I think that's NCI in general.
japhb NotFound, thanks for not making me be the one to point that out again.
whiteknight I would say it's benefit is overall neutral
and only on x86
chromatic ... which is the majority of our platforms right now.
particle it's benefit is unknown without asking our users 19:00
whiteknight not among developers
allison is its limited usefulness on x86 blocking progress on other platforms?
particle our users are hll devs. ask them.
whiteknight allison: nobody is working on a frame builder for any other system. Don't know why
allison sounds like it's largely neutral, then
whiteknight I would suspect more interest in developing a "proper" portable one
chromatic Summary then: it's somewhat useful as is, but not compellingly so. 19:01
Third question: are there likely alternatives in the near future?
whiteknight yes
allison If we get it working with the new PCC, it's probably worth keeping it until something better comes along.
particle can they be completed along with our other goals?
whiteknight there's a drop-in libJIT solution on github now, and an LLVM-based one could be added in a month
mikehh is it worth the effort needed to get it working on one platform ?
Coke I'm back, sorry. 19:02
particle whiteknight, why on earth would we want to make parrot rely on both libjit and llvm?
allison mikehh: depends on the amount of effort, and the readiness of alternatives.
whiteknight particle: either/or
allison particle: they would both be optional
whiteknight configure finds what we have, and uses anything it finds
chromatic Did I hear someone mention hand-coded assembly?
whiteknight TiMBuS and I are idly working on something like that 19:03
particle so, a llvm gc and libjit frame builder is possible?
whiteknight particle: no idea about the GC, but an LLVM-based frame builder is, yes
allison particle: yes, it doesn't matter how you compile the code down to machine code
whiteknight and a compelling first stepping stone in our larger JIT rewrite
allison particle: it's machine code in the end
particle eh, whatever. just ask the users about removing functionality we currently provide. they don't seem to be here.
particle <--- user advocate today 19:04
chromatic It's mostly not user visible.
allison only as speed
which is important for 2.0
particle and recompiling
chromatic There's one spot where it's visible.
whiteknight in the same way the old JIT system was "mostly not user visible"
chromatic If they try to use an NCI signature we haven't compiled in, it's possible the frame builder can make the appropriate thunk.
particle hey, i need a new sig. i have to recompile parrot. oh, wait, i have a debian package.
mikehh speed like in premature optimisation... 19:05
NotFound Is visible for people that have problems with selinux config blocking the frame creation.
Coke I'm sorry,did someone leave the snark on?
whiteknight ah yes, I forgot about selinux 19:06
chromatic We've answered the important first question though.
kurahaupo Doesn't JVM have same problem on SElinux?
chromatic We've agreed that it shouldn't block merging the PCC branch.
allison chromatic: the answers to 2 and 3 are a process 19:07
particle agreed.
whiteknight we can have a replacement by next release, which coincidentally would be a great topic for a hackathon
chromatic Any other comments for now?
particle, you had a question. 19:08
particle we've had multiple releases since 1.0, our target for 'stable platform for hll developers'. how have we failed to meet hll devs needs, and how can we address that? we can use the knowledge gained from a discussion on this topic to address the 2.0 'business-ready' target.
chromatic HLL developers? Coke? 19:09
whiteknight <pmichaud>Parrot hasn't really been stable for HLL developers since 1.0 though</pmichaud>
Coke 1.0 was really not stable enough at all.
particle we need a forum where these issues can be discussed candidly, with hll devs.
Coke I am still forced to update every week or so, not tied to releases.
particle can someone set up an internet chat, here or on #parrot, soliciting hll devs for input and discussion? 19:10
whiteknight like a #parrot-hll?
chromatic or #parrotowthedeephurting
allison #parrotlang
whiteknight or a "chatathon"?
particle they're all fine names. 19:11
Coke given that you have two hll folks on the board, you could potentially solicit feedabck there pretty easily.
jonathan To pick a specific example of one disappointing thing, while I'm very happy to see so many people working hard on PCC stuff now, it's a disappointment that it's taken so long to get to this point. Especially given it was flagged up at PDS.
dukeleto BTW: I did make incremental progress on the parrot debugger docs, just wasn't here when it was mentioned.
allison particle: did you have a particular time in mind?
whiteknight particle: are you asking about a dedicated chat place, or dedicated chat time?
allison particle: or more of an ongoing thing?
dukeleto q1q
particle allison: whatever works for them. once, for now. but we need to make this a regular thing
chromatic jonathan, I think that's a process failure more than anything else.
particle there are critical (imo) issues to address, and scheduled meetings is one of them 19:12
chromatic We've been modifying our processes to improve and avoid such things.
particle we need someone to act as a user advocate
allison would the language devs here like to meet for 20 minutes right after #parrotsketch?
Coke particle: what's driving this?
particle the devs are noisy, but the users are quiet 19:13
allison particle: the users are the devs
Coke so, are pmichaud and I not users, from that standpoint?
whiteknight Yeah? Coke is as noisy as they come!
:)
allison particle: though, I have to say, it would be useful for me to talk from the perspective of Pynie development
particle no, patrick is an infrequent core contributor to parrot
allison that is, it's more about topic focus than about who participates
particle his focus is rakudo.
allison: correct
allison #parrotsketch is for core development 19:14
kurahaupo I have question/comment about ResizableXxxxArrays and their lack of initialization guarantees. Seems to me that that makes them "not fit for purpose" for any purpose I can think of which isn't fulfilled by a FixedXxxxArray. If you have the language devs together, should bring it up then?
allison kurahaupo: that's a coredev question
but, best on the mailing list 19:15
or #parrot
Coke kurahaupo: I find the Fixed ones completely unfit for purpose. so your MMV. =-)
allison to wrap up this question, is there general interest in a regular meeting for language devs?
Coke No. 19:16
kurahaupo A one-off meeting?
allison Coke: you're satisfied with #parrotsketch/#parrot/parrot-dev to meet language dev needs?
particle i'm happy to talk to hll dev teams separately
they can always talk to each other on #parrot or otherwise
mikehh are you going to be the user advocate?
whiteknight one-on-one meetings with individual dev teams might be nice 19:17
Coke allison: if I have a need, I know where to go, yes.
particle i seem to be the only one making noise, mikehh, so yes :)
allison Coke: makse sense
Coke particle: and why are you making noise?
whiteknight Coke: users are something we should be concerned with more then we are
particle coke: for one, rakudo devs are disappointed in parrot's lack of delivering pcc
and many more are disappointed in the lack of parrot api stability 19:18
what have we done to address that? nothing.
allison the stability we promised is "you can update only every 6 months"
whiteknight to be fair, rakudo have pushed for changes in the past that broke stability
allison I'm doing that with Pynie, and it works well
particle pynie is a slow moving target 19:19
allison partly, yes, but more I keep it very intentionally decoupled from Parrot development
dukeleto +1 to the idea of having a channel specifically for HLL devs
particle what happened to cardinal development? it's trailed off. why? does anybody know?
these are questions we want to have answered. 19:20
whiteknight I haven't seen Treed around in a while
jonathan allison: Rakudo isn't coupling more tightly just for the fun of it, you know.
particle right, out of steam, out of time, or out of patience?
chromatic Let's summarize before this becomes a free for all.
particle thanks, c.
whiteknight chromatic: agreed
chromatic particle, will you talk to HLL devs and get some data for us to discuss?
mikehh treed has started a new $job, hasn't been around that much
allison jonathan: I know, it's because the Rakudo developers are adding Parrot features they need, which is good for both
particle c: i will.
chromatic jonathan, Coke, allison, tene, whomever, will you help particle? 19:21
jonathan Sure.
chromatic Great, thank you.
Util, you had a question.
whiteknight particle: create a place, such as on the wiki, where this info can be put
Util In his report, pmichaud said that the new (branched) NQP will support protoregexes and LTM.
Is that the last major obstacle to STD.pm working on Rakudo? If not, what else are blockers?
Tene chromatic: help particle with what exactly
chromatic, particle: I'll do whatever you ask me to do.
particle make me a sandwich 19:22
whiteknight sudo make me a sandwich
chromatic Those are the two big ones I know of, Util. jonathan and pmichaud will know better.
Tene particle: it was mostly just treed working on cardinal while he wa sunemployed/job hunting. He has a job now, and is busy with life.
barney same here, with Pipp 19:23
jonathan Util: It will go a long way towards that.
allison Tene: I think that was "help particle summarize hll developer's needs"
jonathan Util: However, there's a few other bits (embedded closures, context variables in regexes, etc)
particle ok, that's great news. i only mentioned it because we don't, as a group, know the answers. more regular contact with our users will give us better info.
jonathan That are also important.
particle pcc is important, too 19:24
pmichaud sorry, I was afk for a bit
whiteknight lots of important things
pmichaud 19:18 <allison> the stability we promised is "you can update only every 6 months"
Util I am trying to keep an eye out for things that can be worked on in parallel to protore&LTM, since Rakudo+STD will be such a big step forward.
pmichaud both Coke and I have commented that this form of stability is basically useless for HLL devs
Tene q1q
pmichaud I'll take it to #parrot 19:25
Util Thanks. EOQ.
chromatic Tene?
Coke pmichaud: +1 - it's not /harmful/ to me, per se, but it doesn't help.
allison pmichaud: we were running a bit off topic there, and decided we needed longer discussion elsewhere,
pmichaud allison: yes, I just caught up with scrollback
allison #parrot is good or whatever
pmichaud sorry for the untimely interjection
Tene Last weekend's hackathon was a big success. I've heard a few people express interest in doing it again. Do we want to schedule another hacking event, possibly with a different focus? pirc? any suggestions? 19:26
allison pmichaud: it's good confirmation that particle is right and we do need to talk more
dukeleto chromatic: i had a question queued as well
Tene EOQ
chromatic pirc is a good candidate. We roughly agreed to do this the weekend after next to focus on testing before the release.
Tene a testing hackathon would be great.
allison Whiteknight suggested jits, which might be a good one after pirc
Tene we could make a wiki page with hackathon targets. 19:27
particle what about a frame builder?
whiteknight so long as JIT happens before 2.0 I am fine
particle: frame builder is part of JIT
particle yes, it is.
chromatic Does someone volunteer to make that page? We can put further discussion there.
allison if we do a testing one the weekend before the release, and a development one soon after that should work well
particle i think that's more important than pirc atm
mikehh whiteknight: do you think we will have something workable by then? 19:28
whiteknight I'll create the page
mikehh: by when?
pmichaud I'm fine with another focus as long as the pcc development doesn't lose pace again
mikehh 2.0
chromatic dukeleto, you had a question?
allison pmichaud: this would be a hackathon after 1.7, so not distracting from finishing off pcc 19:29
pmichaud okay
good, and thanks.
mikehh imcc is really causing a lot of problems - I think pirc need to be emphasised
dukeleto chromatic: yes
is pcc_reapply going into 1.7 ? 19:30
particle we have a roadmap to help us select code sprint topics
Tene dukeleto: several people really want it to happen.
allison dukeleto: can't say for sure yet, but we'll try
chromatic If it's mergeable in the next week, definitely.
After that... depends on how mergeable it is.
allison yes, no merges in the week before the release
mikehh I'll keep testing as soon as there are any commits 19:31
chromatic Other questions?
dukeleto allison: since I am release manager, i would like to know where to focus my energies. i would like to get it in 1.7, if possible 19:32
i must run, i will catch up on the backlog in a few minutes
allison the first focus is on return handling
that's the last big gap in functionality
chromatic Final thought: weekly focus. 19:33
Anything besides PCC?
particle pcc and pcc.
mikehh let's get pcc out of the way asap
particle how about coverage on some of those files?
is there a heavily used pmc there?
chromatic CallSignature. 19:34
allison particle: CallSignature PMC
particle amen.
allison which has a single test
(can I be instantiated)
plenty to test there
mikehh I will try for some more 19:35
chromatic Anything else before we adjourn?
Until next week then. Thank you all. 19:36
cotto_work If CallSignature is extensively used in that branch, we should make sure we're not testing code that's already well-exercised.
mikehh cheers
cotto_work vim
ww
moderator Vision for 2.0: Production Users | Priority for 1.6: Merge Branches | Priority for this week: get PCC branch mergable, increase test coverage on CallSignature PMC | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead. 19:36
PacoLinux left 19:37 Util left 19:38 chromatic left 19:40 darbelo left 19:41 NotFound left 20:57 davidfetter left 20:58 Whiteknight joined 21:09 Coke left 21:42 Whiteknight joined 22:57 jonathan left 23:08 cotto 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!