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 6 September 2009.
07:19 chromatic joined 12:17 whiteknight joined 13:57 jrtayloriv joined 14:16 jhorwitz joined 14:49 mikehh joined 15:41 NotFound joined 16:04 jrtayloriv joined
whiteknight WHAT I DID: 16:28
* Applied patch from darbelo++ to remove next_for_GC abuse in src/pmc_freeze.c
* Nagged him to send in a CLA (We needs us more committers)
* Converted most NameSpace PMC tests to PIR. Still have some that I haven't had time to convert
* Expanded NameSpace test coverage.
* We're running ~60% more NameSpace tests now in about half the execution time
* Fixed the Fixed-Size structure allocator.
* Combined with some optimizations from chromatic++, it gives us ~3%-5% benefit in some tests.
* Lots of code cleanups and small tweaks after all the branches that have landed this week
* Specifically, interplay between Sub, Continuation, and Context PMCs needed to be looked over for sanity and consistency
* Updated NEWS. I was looking through the log for cleanup and optimization ideas, so I just started recording big changes I saw
* Killed src/gc/alloc_register.c and include/parrot/register.h. Consolidated like things into src/call/context.c and include/parrot/context.h
* Following along with jrtayloriv++'s gc-refactor branch. It's going well, but definitely exposes problems in our command-line arg handling
WHAT I AM DOING:
* More cleanups and performance improvements in preparation for the branch. Can't wait to start profiling things!
* I saw some test weirdness/failures in the switch core, so need to track that down 16:29
* Try and improve test coverage and convert more tests to PIR
* Looking at argument handling in IMCC, with a specific eye to some refactors in that area
* Would like to move argument processing out of IMCC entirely, though that may be a long-term goal
* More planning for JIT improvements, GC improvements (with bacek++ and jrtayloriv++)
WHAT I AM BLOCKING ON:
* Not enough time.
cotto # What I did: 16:35
* fixed enough bugs to get a profile from tcl and Rakudo hello worlds
- the profiling runcore is very slow (1.9s vs 4:05 for tcl hello world)
- also, the output format is uncompressed and slightly better than base64-encoded xml in terms of efficiency
- bacek++ and Whiteknight++ took care of the merge on Sunday when svn was giving me errors
- now anyone can profile by adding -Rprofiling to the parrot invocation
- also documented pprof2cg and added code to the profiling runcore to say what to do with the pprof
* applied some patches from darbelo++ to reduce ->strstart abuse
# What I hope to do and how many tuits I expect to have:
* see question #1
# What could block my progress:
* I got a job and am moving, so RL won't leave too much time for Parrot.
eor
queue two questions
jrtayloriv What I did: 16:37
* Worked on some simple refactoring of GC code:
* Moved data/functions specific to a particular GC core out of preprocessor directives and into the GC_Subsystem structure I added.
* Worked towards adding ability to select GC core via command line switch instead of at compile time (pretty much there, but see blockers ...)
* Moved a lot of GMS code that was scattered around into the GMS header/source files, and removed a lot of it that wasn't being used.
* Renamed GC functions/structures to sensible values that reflect their purpose. (e.g. Small_Object_Pool is now Fixed_Size_Pool)
* Moved several things out of gc_api.h into gc_private.h (such as the Memory_Block struct, etc) 16:38
* Updated pdd09 and memory_internals.pod
* Lots of reading (GC algorithms, memory management, C standards, parrot-dev archives)
What I'm blocking on:
* Inability to parse command line args *before* initializing the interpreter.
(done)
Tene Recently: 16:39
* eval for NQP
* Flailed about with mysql, got segfaults, gave up
* Improved Parrot's SQLite3 library wrapper, successfully used it from Rakudo, working on a higher-level version in Perl 6: github.com/tene/perl6-sqlite
* Helped Rindolf get started with his own scheme-like language, Spark
Soon:
* More SQLite work with masak
* Evaluate the patches on TT757, to see if we can get threading working in HLLs
* More work on Spark or Steme, so we can have a more-useful scheme-like 16:40
* Dunno... suggestions/requests?
Blocking on:
* Akrasia
* Sleep
* RL Drama
KTHXBAI
jhorwitz since last time:
* fixed mod_parrot and mod_perl6 for latest parrot/rakudo (again)
* revamped registry script I/O tying so it works again
currently:
* working on reproducing compilation problems reported by Tene++
blocking on tuits, as usual
EOR
Tene Oh man, I totally remember that now.
* Complained loudly to jhorwitz, demanding that he fix my problems immediately. 16:41
jhorwitz :)
NotFound What I did (last two weaks): 16:54
* Fixing lots of things after merges.
* Fixing bugs that were hidden because of other bugs.
* Using a context with HLL set to 'parrot' and namespace to his root, this must fix TT #150
* Some improvements in test coverity of FixedPMCArray.
* Miscellallaneous cleanings.
What I will do:
* Try to fix more things.
EOR
mikehh What I did: 17:11
* building and testing parrot on Ubuntu 9.04 amd64 and i386
* with both gcc and g++ (g++ tends to pick up errors that gcc does not)
* on trunk and in branches before merge
* fixing codetest, distro_tests, and manifest_test errors
* testing rakudo, cardinal, partcl and devnum_dynpmcs on each build of parrot
What I am doing/intend to do:
* more of the same
* looking at llvm and clang
* looking at nqp_test to incorporate it into test directly (and smoke and fulltest)
What I am blocking on:
* getting my $%&^@ VM (kvm or VirtualBox) to work on a wireless connection
* time of course (and some $work interference)
.eor
17:28 chromatic joined
japhb * What I did: 17:28
+ use.perl.org/~geoffrey/journal/39598
+ gitorious.org/parrot-plumage/parrot-plumage
* What I plan to do:
+ Try to get the plumage executable able to install at least one thing
+ I'm thinking Blizkost
* Blocking on:
+ Object attribute declaration in NQP
* Nice to have:
+ dalek support for the parrot-plumage source repo
+ Platform PATH separator in Parrot config info
+ NQP:
- A nice error message for accidently using = instead of :=
- Fix PIR generation to include "load_language 'nqp'" during :load
* Kudos to:
+ Tene++, for an implementation of eval() in NQP that worked the first time.
EOR
17:28 Util joined
Tene Oh, and I also explained confusing things to japhb about bugs in parrot's HLL stuff. 17:31
japhb heh 17:33
17:54 darbelo joined
darbelo PAST: * Submitted the GSoC code samples to Google Code. 17:59
* Removed some more ->strstart (ab)uses * Submitted a CLA.
* Submitted a CLA. 18:00
* ripped out a big chunk of src/pmc_freeze.c
FUTURE:
* Looking into replacing decnum-dynpmcs Configure.pl with a Configure.pir
* Planing how to remove ->strstart altogether
BLOCKERS:
* Starting school again, migh cut into parrot-hacking time
EOR
chromatic I have been working on bugfixes and profiling and performance improvements. 18:04
I will review the profiling runcore. 18:05
I will also fix up the last bits of PMC_sync removal, to see if it's worth committing now.
18:08 pmichaud joined
duk3leto What I did: 18:08
* Wrote throws_ok() in test_more.pir, which allows us to check exceptions in PIR
* Converted FixedPMCArray tests to PIR
* Fixed bug where parrot core dumped if you tried to give a FixedPMCArray a negative size and added test 18:09
* Converted Float PMC test to PIR
* Found some nasty bugs when eval'ing code that does :vtable stuff TT#992, TT#993
* Worked on blizkost a bit
Intentions:
* Work on PDD14 ticket TT#236
Blockers:
* TT#236 is ambiguous, no clear way to know what needs to be done to close it
particle obama is sending a message to #parrotsketchers today, and i'm boycotting because i don't want him indoctrinating our committers. 18:12
18:12 Coke joined
jrtayloriv Digs around for his flag pin. 18:12
pmichaud What I did: 18:17
* Increased the robustness of some PCT compilation components
* Reviewed context_pmc3 branch changes
* Added operations to support dynamic lexicals (contextuals in Perl 6)
* Added contextual variables to Rakudo
* Supported others' patches to Rakudo, PCT, and Parrot
What I'm doing this week:
* Writing up more documentation for PCT, NQP, Rakudo Star planning
* Adding contextual variables to NQP
* Working on many other PGE/NQP updates
* Designing protoregexes for PGE
What I'm blocking on:
* Insufficient usable hours per solar day
EOR
Coke did: 18:21
partcl- tracking fixes made my notfound that improve spectest coverage.
avoid PGE bug that blocked several hundred tests.
will:
report on likely parrot slowdown candidates post 1.5.0 (spec test is 50%
slower in past week or so.)
continue pinging folks on segfaults blocking spec tests.
blocked on:
. 18:22
whoops, paste-o: blocked on: 18:24
tracking down parrot segfaults (and waiting for fixes)
tracking down parrot slowdowns
.
18:25 allison joined
allison - Week mostly absorbed by travel and an annoying flood of setup tasks once I got to the UK (nice to be here, though). 18:26
- Nearly done with the objects PDD review, so far the only gaps I've found are in Roles (mainly testing).
- Not much progress on the last ~500 failing pcc tests, but it's top on my list for this week.
- I'll miss #parrotsketch next week, as I'll be on a plane (no network access).
EOR
Util ## Done: 18:27
* Looked back in delight to find that bacek++ fixed Packfile PMCs (TT#504) just based on my detail-sparse comments.
* Opened and worked on TT#994 (Fix SVN properties for git-svn users). Server-side hooks contra-indicated. `git-svn` may already be fixed.
# Plan for next week:
* Make SVN properties do-the-right-thing for `git-svn` users (TT#994).
* Check Packfile PMCs for remaining problems (TT#504).
# Blockers:
* Tuits still in low supply.
.end
Coke Hello, everyone. 18:30
duk3leto hola
jrtayloriv Howdy.
mikehh 'allo, 'allo
Util Hello
NotFound hola
allison hi
jhorwitz hola
pmichaud hello
chromatic hello
cotto hi ho 18:31
chromatic Let's review last week's goals. How did the testing work?
duk3leto i uncovered and fixed some issues with FixedPMCArray and converted it to PIR and added some other tests 18:32
chromatic Did anyone work on NameSpace?
duk3leto we now check more edge cases because it is easy to write tests with throws_like()
chromatic: whiteknight++ converted a bunch of namespace tests to PIR and added tests for unicode/latin 1 namespace lookups. i converted some of the tests to throws_like() 18:33
chromatic That sounds like a successful experiment then.
whiteknight Added about 40 tests
(and they run faster!) 18:34
duk3leto chromatic: fixedpmcarray is close to 100% coverage, namespace still needs love
chromatic Shall we continue to work on NameSpace and choose another victim?
mikehh yes 18:35
whiteknight yes
NotFound yes
chromatic Nominations?
whiteknight ... 18:36
chromatic Continuation? If we're optimizing and changing things there....
whiteknight sounds good to me
pmichaud +1
chromatic How are we doing on milestones for the next release? 18:37
I know we had quite a few merges.
cotto That's putting it mildly
duk3leto bigint pmc's have very low test coverage
as well as exceptions and multisub's
whiteknight one at a time! 18:38
chromatic Do you think that focusing on one or two helped/
whiteknight we're not 100% on stability, but much better then we were
chromatic ?
cotto How about those two next week.
whiteknight chromatic: yes, helped significantly
chromatic Okay. duk3leto stash.
trac.parrot.org/parrot/report/14
export conventions, pmichaud? 18:39
Util I think that test coverage numbers are skewed on the PMCs, since some coverage is credited to the source .pmc, and other coverage to the generated .c file.
duk3leto Util: i was wondering about that
pmichaud still working on those. as noted above, documentation and pct improvements are my goals for the week, so "in progress" but possibly "at risk"
chromatic Does that count for all HLL interop?
pmichaud I don't understand "all HLL interop" 18:40
chromatic There are several HLL interop milestones on the list.
NotFound Util: I don't care about numbers, as long as it shows me the lines uncovered
pmichaud it should include most of them, yes.
chromatic Is there a way to help you?
pmichaud (looking at list)
it just takes a bit of time to read the relevant p6 specs and make sure that what we do in PCT corresponds in some manner 18:41
Tene++ has already been a big help, as has japhb++
cotto btw, I marked profiling completed since the relevant branch has been merged. 18:42
pmichaud I don't have a ready-made list of tasks to be delegated, no.
cotto (There's plenty more work to do, but it's usable today.)
chromatic Okay.
Packfile PMCs, Infinoid?
Anyone know? 18:43
whiteknight I think Infinoid has been busy all month
Util bacek++ thinks he has fixed the round-trip problem. I am writing the tests to verify that all is done. On target to close this week.
whiteknight bacek is some sort of magical coding robot
chromatic Excellent.
japhb every project needs one of those.
mikehh bacek++ wroks
chromatic seed libraries? japhb?
japhb still delayed on plumage, which is still mired in yak shaving. there is progress, but slower than I'd like 18:44
whiteknight the metaphors are delicious
japhb I'm focusing on the positive point of "there is progress".
mmm, tasty, tasty yak ...
chromatic Could we set a goal of making a list of likely libraries?
That's at least visible progress we can concentrate on. 18:45
japhb I had one ... but allison did not like it. (I think) we agreed that if I needed it for Plumage, it could be there, otherwise not.
allison japhb: we seemed to come to agreement towards the end 18:46
japhb: I think the only remaining disagreement was what should be "core"
japhb allison, right. Is my statement above correct?
allison japhb: (or if anything should be)
chromatic Objects PDD review, allison? You said you're close? 18:47
allison at least for the first year, it's better if Plumage isn't core
japhb sighs
allison that is, you're going to be developing pretty rapidly, right?
japhb God I hope so.
I see ... deprecation issues?
allison so, you don't really want to have to wait for 6 month deprecation cycles on the modules you depend on
aye
japhb yup, gotcha.
q1q 18:48
Util q1q
whiteknight q2q
japhb
.oO( Let's all ask at once! )
Coke q1k (kibbitz)
chromatic Allison, object PDD review? 18:49
allison half-done
only Roles need implementation work so far
(Role could be a good testing target for week after next)
should be fine for 1.6
chromatic Okay. We merged the profiling core, go us. 18:50
Struct review... I didn't get anything done. Boo me.
Question time!
cotto, you had two?
cotto indeed
The following is a list of tasks, ordered decreasingly by priority, that I want to work on now that profiling has landed. Is there anything missing from the list and how does the order look?
- tests of profiling output and conversion
- integration of source code annotations
- a Configure-based approach to finding the appropriate timing functions
- an optional efficient binary output format with optional compression, similar to NYTProf
chromatic Seems reasonable to me. 18:51
Coke test of output first, changing output later?
cotto The idea is that the runcore will be able to output both formats so I'll only need to test that they're equivalent. 18:52
chromatic Also testing output helps us find and fix bugs.
Next question?
cotto I'm not entirely sure if the idea is feasible, but I'm pretty sure it can work. 18:53
Any further comments are welcome at any time.
I'd like to nominate darbelo for a commit bit?
whiteknight +1
mikehh +1
NotFound +1
pmichaud +1
allison +1
chromatic +1 18:54
Who's shepherding him?
cotto I'd be glad to do that.
duk3leto +1 to darbelo, he is burying me in patches
chromatic Make it so. 18:55
japhb, question?
japhb save me for last, $life
chromatic Util, question?
Util (Pre-typed before cotto's question) 18:56
cotto said: "btw, I marked profiling completed since the relevant branch has been merged."
Where can I find how-to-use instructions for the new shiny? Or is it not usable yet?
whiteknight yes, documentation would be killer
cotto Util, tools/dev/pprof2cg.pl should have all the documentation you could ask for. If not, lmk and it will.
chromatic I need to write docs on how runcores work now too. Will do. 18:57
Util thanks. EOQ
chromatic whiteknight, first question?
whiteknight Can we kill the non-working and probably never-will-work generational_ms and incremental_ms GC cores? Effort to fix and modernize these is likely more then required for a complete rewrite.
Coke whiteknight: I thought we already had a ticket marking them deprecated and removable.
jrtayloriv +1 18:58
allison and yes
Coke (but perhaps all that was removed was the ability to config with them.)
whiteknight okay, EOQ
chromatic whiteknight, second question?
whiteknight In all seriousness, I would like to redirect --runcore=jit to use the fast or switch core instead
we joked about it last week, but I want to do it now
chromatic Trivial change to make it so.
allison my bad for not checking the wiki, but do you have a list of options?
whiteknight for reimplementing JIT, yes 18:59
trac.parrot.org/parrot/wiki/JITRewrite
cotto excellent work there, btw
whiteknight but in the interim, I want to disable the JIT, and make the --runcore=jit commandline option use a different core instead
so we won't lose the user interface, but we also aren't using th emoldy old code 19:00
japhb Well you know I'm +1
pmichaud +1
allison let me look over your list of options and see if we have something better there than what we currently have working 19:01
cotto +1
whiteknight in fact, we will actually *gain* from it, because suddenly --runcore=jit wil work on all platforms
allison (or not-working)
that's a pretty empty gain
whiteknight pretty empty, but not completely without merit
japhb ... and it will start to work on existing platforms?
chromatic ... and it stops the current barely-working-but-mostly-not-working JIT from blocking other progress? 19:02
particle whiteknight: the option, as i see it, is to replace =jit with =fast or =slow
whiteknight exactly. Keep the code unchanged, just how the commandline options map to them
particle if we default to =fast, =slow doesn't make sense
chromatic We now default to =fast for optimized Parrot builds.
particle right, as of today iirc 19:03
allison which works on the most platforms?
particle so =jit will do nothin anywhere
=fast works everywhere =slow does
whiteknight particle: under my proposal, =jit will work
it will just be identical to =fast
japhb particle, isn't =slow the default if Parrot is configured without --optimize? 19:04
chromatic Yes, japhb.
allison whiteknight: no, it won't work, let's be clear on that, it will only pretend to work
whiteknight allison: better then honestly not working
but yes, it is a band-aid over the larger problem
japhb allison, all of this is just to allow us to work around an "oops we forgot to deprecate this" error.
allison before we repeat last week...
japhb Which leads to my question ..., if anyone agrees to pause this one 19:05
allison I'm generally okay with the idea, but I want in plan in place for the replacement first
pmichaud how detailed a plan?
particle there's no reason that =jit must be aliased to =fast for 1.6 release
if we can, we will. 19:06
pmichaud particle: I think it's more a question of "how long must =jit not be aliased"
allison I'll look over whiteknight's comments and send a message to the mailing list in a couple of days
whiteknight okay. That's all we really need
well, not all, but most :)
japhb Q: Can we come up with a process for a deprecation exception? Right now, we're discussing a particular case, and trying to figure out details of how to route around our standards. But it seems to me we need to agree to a process for going "Ooops." and still making forward process on a project that is still, realistically, in a heavy development phase.
(chromatic: that was my queued question)
particle forking is one way 19:07
chromatic I recommend following the guidelines in our support policy, which explicitly list what we do and do not support.
allison japhb: well, this particular case just swapping out a different runcore for 'jit' satisfies the support policy 19:08
whiteknight forking would be reasonable if we have good community support for it. a renegade fork does nothing to help anybody
allison forking is a not a good idea
branching satisfies the same goal
japhb How did my question devolve to forking? (Honest question)
Coke 15:07 < particle> forking is one way
pmichaud can we have a "devel trunk" branch, then?
particle exceptions to the deprecation policy can be solved by forking
japhb Coke, I saw that. I just didn't understand the *direct* meaning 19:09
particle i'm not recommending it, just stating fact.
a fork means that a different deprecation policy can be followed
chromatic I don't believe we've discussed anything that's an exception to the deprecation policy yet.
allison pmichaud: that brings up major headaches in merging things back into "trunk trunk"
pmichaud allison: I agree it brings up headaches
japhb particle, I'd rather the mainline project have a process, that's all. Businesses have a process to go back and fix errors in accounting, I'm not entirely clear on why a parallel concept does not apply to us.
allison so far, I really haven't seen anything that deserves an exception
pmichaud but that seems to me to be the logical conclusion to "branching satisfies the same goal"
allison the hard part is just training developers to think about the deprecation policy as they're developing their branch 19:10
if you don't think about it until you're ready to merge, it might catch you out
but, a little forethought while developing takes care of it 19:11
japhb chromatic, technically you're correct. But we're now two weeks running (or more, if you count the bigger picture) discussing a situation in which most of the team says "we need to do this" and the architect says "but your solution only follows the deprecation policy in name, and not in spirit."
chromatic Has that been a problem? I haven't see it as a problem.
allison japhb: oh, my problem with the JIT isn't the deprecation policy
chromatic I meant allison, not japhb for that question.
whiteknight we also don't want to frame this as an "us vs her" discussion. It's not that 19:12
allison japhb: it's more of an overall project and design planning issue
japhb whiteknight, I'm sorry, I didn't mean it that way.
whiteknight no worries, I just want to make sure it doesn't descend in that direction
allison chromatic: nope, it hasn't been a problem. a few branches needed minor fixes before merging
chromatic: no big deal
japhb allison, OK, so if your objection is only with the planning, and honest effort is going into planning, and you don't believe we have a deprecation policy issue, why not act now to do phase one (change the command line option)? 19:13
chromatic That I actually do see as a problem.
allison japhb: to be specific, it's not the deprecation policy that says we need a new plan for the JIT before ripping out the old one
whiteknight Replacing the JIT system is a straight-forward tractable problem. Working around the decaying husk of our existing system is another issue entirely
development speed will increase overall without it 19:14
japhb allison, I thought your objection was with removing something but masking it for the users. In a sense, following the letter of the law, but not actually doing what the user wants anymore.
whiteknight arguably, what the user "wants" is a system that works
allison japhb: no, my issue is that once the old one's gone, the motivation for fixing it drops off radically
japhb whiteknight, I am in 100% agreement with you.
allison, oh. Then I don't believe that's the case. 19:15
Several of us really want a working JIT. The old one is just in the way.
pmichaud allison: I would rephrase your statement as "once the old one's gone, the motivation for having one drops off radically"
japhb We have to level the tenaments before we can put in the new hotel.
pmichaud because nobody plans to "fix" the existing one.
japhb OK, that didn't come out quite the way I meant it.
allison pmichaud: yes, that targets my concern more directly
pmichaud allison: and you're saying that having a jit is more important/pressing than our other concerns
(not saying it directly, but that's the conclusion) 19:16
chromatic Even if that JIT doesn't work and blocks other work.
japhb I meant, the old JIT is actively in the way. We all want a new JIT, we just have to get the old one out of the way *first*.
Because we can't even clean up the rubble until it's gone.
pmichaud does "we all want a new JIT" mean that someone will be actively working on it when the old one is gone?
allison I meant to review whiteknight's comments before this meeting but forgot
pmichaud if so, who?
whiteknight I will be
chromatic I will.
allison so, that's my bad
particle this is an old, ongoing item. can it move to #parrot or the ml? 19:17
allison but, I'm not going to make a major decision like this under heat of pressure
whiteknight don't worry about it, theyre in the wiki forever
allison so, 2 days
whiteknight that's perfectly fair
EOQ
particle heh, whiteknight said "wiki" and "fovever" in the same sentence
allison I will put a yay or nay message on the mailing list, promise
japhb $life again, afk
chromatic Coke, question? 19:18
Coke - Thanks for all the work (esp. by NotFound++) done chasing segfaults
exposed by partcl.
- Still have five segfaulting spec tests remaining. It would be most
awesome if we could get this down to 0 before 1.6.0
.
(pretyped. more...)
additionally, trying to track down speed issues I'm seeing in recent parrots. test suite is taking longer and longer (no change in tests being run), trying to find a single .test file that shows the slowdown. 19:19
(but I'll take segfault fixes over speedups)
(END)
chromatic Other questions? 19:20
mikehh we had a problen with merging trunk into a branch - has that been resolved?
pmichaud who is the parrot release manager this month?
particle i am 19:21
and rakudo release manager
pmichaud particle: you're doing both the parrot and rakudo re..... excellent!
need to start sending NEWS update announcements to mailing lists :) 19:22
whiteknight so when things go wrong, we have only one person to blame :)
particle yep, schwern.
duk3leto hahaha 19:23
chromatic Any thoughts on mikehh's question?
Coke could be related to the SSL cert.
pmichaud mikehh: I generally try to merge branches into copies of trunk
Coke someone on list suggested changing a server setting. don't think any action was taken on that.
jrtayloriv I found a bunch of stuff saying it might have to do with mod_dav_svn
Apparently it happens with DAV has to auth for each directory, rather than just once.
mikehh pmichaud: me too 19:24
chromatic Can someone talk to Lance or someone at OSU about that?
jrtayloriv s/with DAV/when DAV/
Coke I'll open a ticket.
mikehh who had admin permissions?
has 19:25
allison on the svn server? me, coke, particle, jhorwitz
Coke (and OSU. I was just going to punt to them.)
if one of the admins wants to take it directly, by all means. 19:26
allison that works
if they punt it back, we can take care of it
jrtayloriv allison, www.sharp-tools.net/archives/000928.html
chromatic Other questions?
cotto one 19:27
allison jrtayloriv: have we confirmed that this is still a problem now that the security certificate is working?
cotto Is the pluggable runcore milestone satisfied by the merge?
whiteknight allison: no, the only time it triggered was during large branch merges 19:28
so haven't had any other opportunity to run afoul of it
cotto (apologies if I just missed that part of the discussion)
jrtayloriv I was having connection issues yesterday when trying to sync up my copy of gc-refactor branch w/ trunk.
allison cotto: I would say so
whiteknight cotto++
Coke (ticket opened with OSUOSL)
cotto chromatic did that part of the work 19:29
chromatic They're just not dynamically loadable yet.
cotto I'll mark that one completed then. 19:31
eoq
jrtayloriv has to head out -- toodle doo! 19:32
japhb sounds like meeting over? 19:34
whiteknight anybody else have anything to say or ask? 19:36
mikehh back to testing
cotto sounds like it is. 19:38
chromatic until next week
19:38 chromatic left
mikehh cuall 19:39
duk3leto eom
Coke la
19:39 Coke left, darbelo left, Util left 19:45 PacoLinux left 19:49 NotFound left 20:08 pmichaud left 20:13 jrtayloriv left 21:07 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!