Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2010-07-20

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

All times shown according to UTC.

Time Nick Message
00:44 japhb joined #parrotsketch
12:18 kid51 joined #parrotsketch
12:19 kid51 kid51's report:
12:19 kid51 [somewhat OT]:  Am giving a brief talk on the Rakudo* launch at NYLUG Wednesday evening.
12:20 kid51 Feedback welcome:  http://thenceforward.net/perl/talks/rakudostar/ ...
12:20 kid51 ... particularly from those of you whom I've already asked for feedback ;-)
12:21 kid51 DONE:
12:21 kid51 ran 'make fulltest' and got PASS on both Linux/i386 and Darwin/PPC (revisions as reported in previous days in #parrot)
12:22 bluescreen joined #parrotsketch
12:22 kid51 identified test failures in gsoc_threads branch
12:22 kid51 EOR
13:20 macroron joined #parrotsketch
14:43 Coke !! Doing 2.6.0 release tonight.
14:43 Coke still working on "make html" do-over ; some progress. See: http://trac.parrot.org/parrot/wiki/CleanupMakeHtml
14:43 Coke No feedback on
14:43 Coke http://trac.parrot.org/parro​t/wiki/ResolveExperimentals, so no
14:44 Coke changes planned there.
14:44 Coke EOR
14:44 Coke LAST CHANCE to get any deprecation notices in.
14:54 tcurtis joined #parrotsketch
16:36 cotto_work joined #parrotsketch
17:45 dukeleto joined #parrotsketch
17:46 NotFound joined #parrotsketch
18:04 NotFound What I did:
18:04 NotFound -parrot
18:04 NotFound * Just testing
18:04 NotFound -winxed
18:04 NotFound * Miscellaneous fixes
18:04 NotFound * Initial support for constructors
18:04 NotFound * Some more optimizations of const expressions
18:04 NotFound * Predef two args atan
18:04 NotFound * New opengl example fly.winxed, useful as a demo
18:04 NotFound What I will do:
18:04 NotFound No plan
18:04 NotFound EOR
18:11 darbelo joined #parrotsketch
18:20 eternaleye joined #parrotsketch
18:23 macroron joined #parrotsketch
18:36 bluescreen joined #parrotsketch
18:36 * dukeleto can't make it to the meeting today, but will backlog later. good luck on the release today!
18:51 darbelo joined #parrotsketch
19:25 mikehh joined #parrotsketch
19:30 bubaflub joined #parrotsketch
19:31 khairul joined #parrotsketch
19:34 mikehh What I did since my last report:
19:34 mikehh * building and testing parrot on amd64/i386, with gcc/g++
19:34 mikehh * various fixes
19:34 mikehh * branch testing and some fixes
19:34 mikehh * some work on html_cleanup branch
19:34 mikehh * testing rakudo, partcl-nqp, partcl, pir/PIRATE, winxed and plumage
19:34 mikehh What I intend to do in the next week:
19:34 mikehh * testing and fixing
19:34 mikehh * more preparation as release manager for 2.7.0
19:34 mikehh .eor
19:35 PacoLinux joined #parrotsketch
19:36 khairul Did:
19:36 khairul .instrumented methods
19:36 khairul .support vtable overrides
19:36 khairul .added test for Instrument::Event::GC
19:36 khairul .minor code cleanup
19:36 khairul Will Do:
19:36 khairul .blog post
19:36 khairul .more code cleanup
19:37 khairul .more tests
19:37 khairul EOR
19:39 Chandon joined #parrotsketch
19:55 whiteknight joined #parrotsketch
19:56 NotFound joined #parrotsketch
19:58 Util # Done:
19:58 Util * Started review and catalog of download/getting-started pages.
19:58 Util * Worked on Rakudo Win32 problems.
19:58 Util # Plan to do:
19:58 Util * Finish download review (today, if possible)
19:58 Util * Finish Rakudo Win32 problems
19:58 Util # Blockers:
19:58 Util * $WORK
19:58 Util .end
20:02 cotto_work #did:
20:02 cotto_work - met with khairul
20:02 cotto_work - did some proofreading on the Squaak tutorial
20:02 cotto_work - tcurtis++ for doing the hard work of resurrecting it in the first place
20:02 cotto_work #will do:
20:02 cotto_work - not sure
20:02 cotto_work # What needed improvement between 2.4 and 2.6:
20:02 cotto_work - unexpected impact of deprecations
20:02 cotto_work # What should the priority be for 2.9:
20:02 cotto_work - get Lorito maximally usable
20:02 cotto_work #eor
20:07 allison joined #parrotsketch
20:08 tcurtis What I did:
20:08 tcurtis * GSoC midterm evaluation
20:08 tcurtis * PAST::Transformer transforming PAST::Block.control and .loadinit attributes.
20:08 tcurtis * Updated the Squaak tutorial
20:08 tcurtis - It's now in trunk.
20:08 tcurtis - cotto++ for proofreading.
20:08 tcurtis * Started exploring a somewhat different approach to Lorito assembly from that of atrodo++
20:08 tcurtis - http://github.com/ekiru/yalp-asm
20:08 tcurtis * Blog post:
20:08 tcurtis - http://parrot.org/content/uneventful-mid-t​erm-week-and-future-pasttree-optimization
20:08 tcurtis What I plan:
20:08 tcurtis * Research LLVM's PassManager and various pass classes.
20:08 tcurtis * Design and implement analogous system.
20:08 tcurtis * More blog posting
20:08 tcurtis chromatic questions:
20:08 tcurtis What one thing could we have done better in the series of releases from 2.4
20:08 tcurtis to 2.6?
20:08 tcurtis * We could have handled the dynops deprecation better.
20:08 tcurtis What should be our highest priority task for the series of releases
20:08 tcurtis culminating in 2.9?
20:08 tcurtis * Lorito or object system improvements(although I suppose it might make sense to wait for Lorito to do that).
20:08 tcurtis EOR
20:10 whiteknight WHAT I DID:
20:10 whiteknight * GSoC Midterm evaluations. Congratulations to all our passing students!
20:10 whiteknight * Following along with Chandon's thread work
20:10 whiteknight * Spending all my spare time working on Kakapo. The breakage is bigger and more pervasive than I anticipated
20:10 whiteknight WHAT I WILL DO:
20:10 whiteknight * Work on Kakapo
20:10 whiteknight WHAT I AM BLOCKING ON:
20:10 whiteknight * Time
20:11 chromatic joined #parrotsketch
20:11 chromatic I answered some questions.
20:11 whiteknight (I haven't been active enough in the past three months to really answer chromatic's questions)
20:15 cotto_work q1q
20:26 tcurtis q1q
20:31 chromatic Hello, everyone.
20:31 cotto_work Hi
20:31 whiteknight hello\
20:31 Util Hello
20:31 darbelo Hola.
20:31 tcurtis Aloha.
20:32 allison hi
20:32 mikehh hello
20:32 Chandon Hi
20:33 chromatic Any last minute requests before the release?  Coke?
20:34 Coke I'll probably be doing the release later tonight;
20:35 Coke any deprecation notices, now is an excellent time to discuss them and get them added.
20:35 Coke +/or experimental additions/substractions.
20:35 chromatic http://trac.parrot.org/parro​t/wiki/ResolveExperimentals
20:35 chromatic Right, going there now.
20:35 Coke I'm also still working on cleaning up make html, but that's not going to block the release, since there isn't really a lot of new docs to convert.
20:36 Coke http://trac.parrot.org/parrot/wiki/CleanupMakeHtml is the status of the make html cleanup so far.
20:37 chromatic Anything else?
20:38 tcurtis If anyone wants to look at the updated Squaak tutorial before the release, that would be nice. I won't be around to fix anything after #ps, though.
20:38 NotFound Sorry, was busy. Hola.
20:39 chromatic Let's review the 2.4 - 2.6 family.
20:39 chromatic Dynops changes were painful.
20:39 Coke ah, yes. there's some new docs. Please give those some attention, and I'll make sure they make it onto the website if they aren't already.
20:40 Coke And they're still not fixed.
20:40 Coke SFAIK.
20:40 darbelo They are mostly workarounded, in the code we can see.
20:41 chromatic Any other thoughts on what didn't work so well in the past three months?
20:43 darbelo kthakore's troubles with parrot moving from under his code.
20:43 Coke the TT#389 fix.
20:43 chromatic Deprecation is hard work, as usual.
20:43 Coke basically summed up by "parrot is a moving target".
20:44 Coke I had a hard time catching up after the 2.3 release, because everything hit at once. but I still prefer that (right after supported release) to the alternative.
20:44 chromatic How do we address that?  The wiki page of "Here's how to deal with __specific__ deprecation"?
20:45 darbelo cotto's 'migration map' plan is probably enough to keep the target's new location findable. Hopefully.
20:45 Coke 1) make sure that before we rip something out, the alternative is in place.
20:45 cotto_work I'll make it a priority to whip that into shape.
20:45 Coke 2) as soon as the alternative is in place, add it to the list of "how to migrate to new feature".
20:46 Coke (or say: "sorry, this gone for good.")
20:46 allison release branches are a traditional way of handling a trunk that moves too quickly
20:46 Coke also encourage those of us who are not just core hackers to update that when we find issues (like the tt#389 fix)
20:46 chromatic I'm not sure release branches will help.
20:47 whiteknight -1 to release branches
20:47 allison the maintenance effort is higher, which would be difficult for us
20:47 Coke I'm not sure it'll help the end users who are just targeting the .3 releases, either.
20:48 darbelo Our bigger problem seems to be "Too much changed since the last release." I'm not sure rease branches can help there.
20:48 allison though on git, I don't expect "trunk" to be so meaningful anyway, so this may all wash out when we switch
20:48 allison as Coke mentioned, bundled changes are easier than multiple scattered changes
20:49 whiteknight Coke: almost nobody targets the .3 releases
20:49 chromatic I don't think it's the difference between change and no change, but it's the amount of changes.
20:50 allison so, we should stop development ;)
20:51 Coke whiteknight: well, i think that distro's are the main customer there.
20:51 Coke anyone actually writing an HLL probably is just targeting the .1s
20:51 Coke (or svn)
20:52 Coke at least in the short term. I think the other option is "no deprecation policy", but that would kill me. at least now the huge changes are clustered.
20:52 Coke (despite our imperfect application)
20:52 chromatic Right.
20:53 chromatic Other issues we can address in the next quarter?
20:54 chromatic My other one is: performance improvements.  We didn't merge the new GC.
20:54 darbelo ENOBACEK
20:54 Coke question: is it worth focusing on anything non-lorito?
20:54 chromatic Focusing how?
20:55 cotto_work The limiting factor for the gc branch has been tuning for the past month.
20:55 allison tuning in the sense that it's currently slower than trunk
20:55 cotto_work (i.e. we don't have anyone who's done enough tuning to make it work merging and using by default)
20:55 Coke chromatic: spending tuits on? I just want to make sure we don't put a ton of energy someplace where it will need to be rewritten.
20:55 chromatic We seem to have had fewer commits (apart from GSoC students, who are awesome).
20:55 cotto_work afaict
20:56 darbelo allison: It was faster in plces, slower in places. IIRC.
20:56 Coke which may be a misguided concern.
20:57 chromatic Coke, I see this as general cleanup and bugfixing only help us port code to a Lorito world.
20:57 chromatic Cleaning up namespaces, for example, hurts no one.
20:57 darbelo allison: bacek seemed convinced that it could be made fater all around by tweaking the limits that trigger gc runs.
20:57 darbelo Eh, faster.
20:58 darbelo It was also, less memory hungry all over.
20:58 chromatic When I get time, I'll work on tuning and profiling... but it'd be nice to spread out some of that work so it doesn't depend on a couple of people.
20:58 allison darbelo: aye, but it does put a slightly different slant on "tuning", i.e. that's why we held off rather than merging and tuning later
20:59 tcurtis chromatic: what does tuning it involve?
20:59 chromatic Running benchmarks, finding what's slow, digging through KCachegrind, and making as many benchmarks faster for as many loads as possible.
21:00 Coke (especially running HLLs on it.)
21:00 * cotto_work has a brief (please) meeting.  afk for a few minutes
21:01 darbelo Last time I touched the gc I used rakudo's start up time as a benchmark.
21:01 chromatic bacek wrote a few benchmarks which allocate a lot of garbage STRINGs and PMCs.
21:01 chromatic He has some lifetime benchmarks too.
21:01 chromatic That's a good place to start.
21:03 chromatic Let's move on to priorities for 2.9.
21:03 chromatic Everything I've read so far said Lorito.
21:03 Coke I will have to leave shortly. I'll be online later this evening to work on the release.
21:03 chromatic How?
21:05 whiteknight How what?
21:05 Coke I think we might need to table that until we have that POC working, no?
21:05 darbelo Coke: You've stated 'How': Make the POC work.
21:06 chromatic We have a working ops2c; could we get a working pmc2c?
21:06 Coke sure, we could rewrite pmc2c in NPQ.
21:06 chromatic We have a PIRATE getting close to working.
21:06 darbelo We have POST -> PBC within reach too.
21:07 Coke so far, I just see all these as unrelated nice to haves, not a coherent lorito. but I've never been clear on what lorito will actually look like.
21:08 chromatic Step 0: define what Lorito will look like?
21:08 allison to make lorito the 2.9/3.0 goal we'll need to break the overall idea down into concrete steps
21:09 chromatic How do we do that?
21:11 Coke well, it sounds like there are already project-sized chunks. Be nice if those were mapped into an overall technical plan.
21:11 allison that's part of defining what it looks like
21:12 Coke in the meantime, hopefully time spent on the already-defined chunks is well spent. (sounds like it)
21:12 chromatic I think we have to come at it from two angles.
21:12 chromatic What's the underlying code and what does it take to get something like ops2c targeting it?
21:13 mikehh A couple of people are playing around with POC stuff - we need some more ideas like cotto's http://trac.parrot.org/parrot/wiki/LoritoOps
21:14 allison with our recent emphasis on distributed design, I think it's important for the technical plan to be a group effort
21:14 allison what's the best way to make that happen?
21:14 darbelo I see one problem, a big part of our opcode set is just thin wrappers around libparrot exported functions. If we intend to lower our opcode set we need to rewrite that functionality in the new opcodes.
21:15 mikehh through the wiki maybe?
21:15 chromatic That seems like the most important process question to answer in the next quarter.
21:15 darbelo We can't do that until we know what the opcodes are.
21:15 allison we have the starting opcodes, and an initial implementation of them
21:15 chromatic darbelo, I've assumed that we can have an opcode which is basically "Call this C function".
21:15 Coke I recommend meetings (either take over parrotsketch or otherwise) of interested parties. either on irc/wiki/email./
21:15 mikehh we really won't know that until we do some more POC work
21:16 Coke if someone wants to drive, they can make a target on the wiki for people to talk about.
21:16 Coke ... c.v.f. cotto for lorito
21:18 chromatic Any other suggestions for the next quarter?
21:18 mikehh getting the GSOC stuff incorporated
21:18 chromatic Good one.
21:18 chromatic Are the students on track?
21:19 mikehh well tcurtis++ is certainly branching out
21:19 mikehh and some of the other stuff looks good
21:19 tcurtis I'm a few days behind due to Squaak, but I'll hopefully be back on schedule soon.
21:20 chromatic Should we suggest that students try to merge trunk changes when they reach a good merge point?
21:21 darbelo FSVO 'merge point'
21:21 mikehh that should depend on the mentor's to a certain extent - and suitable testing
21:22 chromatic "My tests all pass and I am confident in merging or at least begging my mentor for help."
21:22 chromatic Any other area of focus for Q3?
21:23 mikehh adding tests to improve coverage
21:23 chromatic Always a good one.
21:23 chromatic Let's move on to questions.
21:24 darbelo q1q
21:24 mikehh and again not closing tickets until suitable test are there
21:24 mikehh s/test/tests/
21:24 chromatic tcurtis?
21:25 tcurtis I'd like to become the "MAINTAINER" of examples/languages/squaak and officially take on the responsibility of making sure that both the compiler and tutorial stay up-to-date with any future changes to Parrot/NQP-rx. Is this acceptable?
21:25 chromatic +1
21:26 NotFound +1
21:26 mikehh _1
21:26 darbelo +Inf
21:26 mikehh bah +1
21:26 allison +2
21:26 chromatic There's no two, Bender.  It was only a bad dream.
21:26 chromatic Let's call that unanimity.  darbelo?
21:28 darbelo Our PLATFORMS file is fairly unmaintained, and out of date.  What can we do to improve it's state?
21:28 cotto_work back
21:28 chromatic Automate it from smoke reports?
21:28 Util Call for updates?
21:29 Util "unmaintained" - well, it should be updated one line at a time when someone fully tests on a platform.
21:30 darbelo There's no line with 2010 in the 'Supported platforms' section.
21:30 Util "out-of-date" - it is a historical record of where we used to run, and a poke-in-the-ribs to make sure it runs there now.
21:31 darbelo You are right, out-of-date is the wrong term.
21:31 darbelo 'Un-updated' is the thought I was trying to voice.
21:31 mikehh need t5o keep it "up-to-date"
21:32 Util I see several platforms there that I could verify and update the timestamp. Perhaps the release managers .pod should mention "get everyone to update PLATFORMS during release prep"?
21:32 chromatic I think it may, but it should -- if there's value in that file.
21:34 whiteknight I question whether that file, as is, has value
21:34 darbelo Maybe I want something different, but I'd like to know, by looking at this file if I can trust parrot to run ok in my platform.
21:34 chromatic Likewise.
21:35 mikehh I think it should be more of parrot works (with some caveats maybe) on this platform
21:36 chromatic Do we have a volunteer to take this discussion to the list?
21:36 darbelo I asked the question in the first place. Guess I'll have to step up :)
21:36 chromatic Thanks.
21:36 chromatic cotto_work, question?
21:37 mikehh I'll help as required
21:37 cotto_work Lorito design question:  When dealing with register types, do we want to have fewer ops that do internal type checking (i.e. a single opcode can take i_p_p, n_i_n, etc) or do we want ops with explicit types that rely on the compiler taking care of any necessary coercion?
21:38 chromatic At the lowest level (let's call it M0 for Microcode level 0), I can imagine not worrying about types.
21:38 chromatic It's all memory and offsets.
21:40 Chandon q1q
21:40 allison yes, one opcode with sane coercions is much better than weird specific types
21:41 cotto_work doesn't that mean the op will be doing work that's unnecessary most of the time?
21:41 allison it will also avoid unnecessary work
21:41 allison as in, we currently have some parts of the system where we coerce a PMC to a low-level type, and then back again
21:42 allison which is silly
21:42 allison if opcodes don't care about types, then we only coerce when it's absolutely necessary
21:43 cotto_work My assumption is that the common case will be that we'll want an op to work with arguments of the same primitive type.  Is this a valid assumption?
21:43 * dukeleto waves hello
21:43 cotto_work e.g. xor $I0, $I1, $I2
21:43 allison not necessarily, e.g. why should addition always be integers or floats?
21:43 allison xor makes sense, as it's a boolean operation
21:44 allison but, it may be extracting the boolean value from any number of different kinds of values
21:44 chromatic What's the M# of the op in this question?
21:44 allison xor $I0, 5, $P2
21:45 allison chromatic: shouldn't matter if all the ops are boxing/unboxing at the core
21:45 NotFound How can you tell just by the address is something is an integer, a number, oe whatever?
21:45 cotto_work chromatic: I had been thinking that there'd be only one level below PIR.
21:45 tcurtis allison: Why not require explicit coercions at the lowest level? If not, does this mean that every opcode execution will have to be dispatched at runtime based on the operand types?
21:46 cotto_work tcurtis said what I was trying to articulate
21:46 allison tcurtis: coercions are expensive, so you want to avoid them if at all possible
21:46 chromatic I've been thinking that the POC ops are M0, our current ops are M1, and then you have PIR.
21:47 NotFound Based on the types of what? An address has no type.
21:47 cotto_work If you want to add an object and a float, you have to coerce.
21:47 tcurtis cotto_work: or do a multi-method.
21:47 cotto_work I'm saying that that coercion should happen explicitly rather than as part of add.
21:47 allison we do have types currently, that's how we know to dispatch to add_i_ic_ic versus add_p_p_p
21:48 allison the main thing I want to avoid is the exponential explosion of ops for various types
21:48 darbelo We could have a default "Any" signature for ops that coerces as necessary, and then add more specific versions for the cases we want to make fast.
21:48 allison and the weird patterns where an op has some type combinations but not others
21:49 NotFound allison: AFAIK that's not dispatch, is PIR compiling.
21:49 cotto_work I agree with avoiding a combinatorial explosion.
21:49 cotto_work I'm talking about the lowest level ops.
21:49 allison NotFound: it's true, it can live at that level, but currently it's a mixture of both
21:50 tcurtis allison: can't that be dealt with by requiring explicit coercion when calling an op with something it doesn't support, though? For higher-level code, the compiler can insert necessary conversions automatically, but if you're writing "M0" directly, you have to do it yourself.
21:50 cotto_work we only have add_i_i_i and add_n_n_n.  If we want to add an int and a float, we coerce one.
21:50 NotFound If you plan to use just an address, you can't dispatch at the lower level with primitive types.
21:51 allison providing box/unbox operations at the lowest level could be enough
21:51 allison then limited type-specific operations
21:51 cotto_work I think we agree.
21:51 chromatic box/unbox seem too high level for M0
21:52 chromatic and, please, no runtime dispatch at M0
21:52 allison it can be expensive to coerce all PMCs to low-level types for basic operations
21:52 allison but, as long as it's trace-JITable, we're fine
21:52 allison chromatic: M0 must contain all behaviour for the higher levels
21:52 chromatic Backwards.
21:53 chromatic All higher level behavior must be expressible in M0.
21:53 allison aye, that's what I said (or meant to say)
21:53 chromatic If M0 doesn't know what a PMC is, so much the better.
21:53 allison if box/unbox can be expressed using other low-level ops, no problem
21:54 allison coercions between other types are needed too
21:54 chromatic That's basically the series of ops: call C function with this chunk of memory, return this chunk of memory.
21:55 allison and what series of low level ops compose the section in between?
21:55 allison calls to C functions aren't JITable
21:55 allison (unless the C function is actually a JIT template
21:56 chromatic Calls to C functions we haven't yet migrated to Lorito aren't JITtable yet.
21:56 chromatic The more M0 ops, the harder it is to JIT.
21:56 chromatic The more complex M0 ops, the harder they are to JIT.
21:57 allison yah, and also the M1+ ops need to be defined entirely in terms of M0 ops
21:57 allison (or compositions of lower level ops, which are ultimately compositions of M0 ops)
21:57 chromatic Exactly.
21:58 pmichaud joined #parrotsketch
21:58 chromatic box can be a M1+ op (provided that "Call this C function" is an M0) op.
21:58 allison so, if we can define box/unbox in terms of existing M0 or higher ops, then don't need to be in M0
21:58 allison (but otherwise, we'll need them)
21:58 chromatic That's my guiding principle.
21:58 allison "Call this C function" doesn't count as composition
21:59 tcurtis Should M0 have support for method dispatch in any form?
21:59 allison tcurtis: it has "call"
21:59 allison which is method/vtable on a PMC
21:59 allison (the two being largely the same thing in Lorito)
22:01 cotto_work so back to the question, is it agreed that we want M0 ops to deal with a single type apart from the coercion ops?
22:01 allison cotto: to the extent possible, yes
22:01 tcurtis +1
22:02 allison there's some question about add being int or float
22:02 allison would have to default to float, if we really picked only one
22:02 cotto_work I picture there being add_i and add_n
22:02 chromatic add_i and add_n make sense to me.
22:02 tcurtis There should probably be math ops for both int and float, with explicit specification(at M0) level of which you want.
22:03 allison and since we require explicit coercions, there's no trouble picking which to use for PMC type calls
22:03 cotto_work great
22:03 cotto_work one decision down, 127 more to go
22:03 cotto_work ;)
22:04 cotto_work eoq as far as I'm concerned
22:04 chromatic Anything else?
22:05 Chandon With the 2.6 release happening, would it make any sense to speculatively depreciate threading stuff that is changing in my branch in case it makes sense to merge before October?
22:06 chromatic What's your confidence
22:06 cotto_work Deprecating it now means that it can be removed any time after 2.6 is cut, provided the proper deprecation policies are met.
22:06 * cotto_work revs his deprecation enforcement chainsaw
22:07 dukeleto q1q
22:08 Chandon Threading seems to be largely broken anyway, and the concurrency stuff that I've broken and want to tweak isn't covered by any tests, so probably depricating it wouldn't hurt anything.
22:08 NotFound Is that stuff currently working and used? There is no point in safeguarding non working stuff.
22:08 chromatic +1 to remove unworking things, +0.5 to giving a specific time frame for its replacement.
22:09 allison +1 to deprecate and rip out the old
22:09 Chandon There's no reason things can't be undepricated later if they get fixed as is and I'm a mirage, right?
22:09 chromatic Right.
22:09 chromatic Get that notice in before Coke comes back.
22:10 chromatic dukeleto, question?
22:10 Chandon Where do deprication notices go again?
22:10 darbelo DEPRECATED.pod with a supporting Trac ticket.
22:10 Chandon And is there anything in scheduler.c and the related PMCs other than exceptions that people actually use but haven't written tests for?
22:11 allison unknown
22:11 allison AFAIK, there is no substantial use of threads anywhere currenly
22:11 dukeleto Are we providing sha1 sums for the release today?
22:11 NotFound Chandon: Have you checked coverage?
22:11 Chandon NotFound: Coverage?
22:12 NotFound Chandon: code coverage of the C functions in that file.
22:12 NotFound http://tapir2.ro.vutbr.cz/cover/cover-results/
22:14 chromatic Anything else?
22:16 mikehh dukeleto: need to ask Coke that when he gets back
22:24 cotto_work um... meeting dismissed
22:24 dukeleto left #parrotsketch
22:25 Coke following up on Util's coment about getting people to update PLATFORMS. Did I not mention this in the email?
22:30 Coke (SHA1 sums). If folks want stuff done for the release, it needs to go /in the release guide/ if it's not there, it's likely not getting done.
22:45 darbelo left #parrotsketch
23:27 pmichaud left #parrotsketch
23:54 Coke left #parrotsketch

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