Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2009-09-08

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

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

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary