"Tuesday at 20:30 UTC"
Set by moderator on 8 July 2010.
00:44 japhb joined 12:18 kid51 joined
kid51 kid51's report: 12:19
[somewhat OT]: Am giving a brief talk on the Rakudo* launch at NYLUG Wednesday evening.
Feedback welcome: thenceforward.net/perl/talks/rakudostar/ ... 12:20
... particularly from those of you whom I've already asked for feedback ;-)
DONE: 12:21
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
kid51 identified test failures in gsoc_threads branch 12:22
EOR
13:20 macroron joined
Coke !! Doing 2.6.0 release tonight. 14:43
still working on "make html" do-over ; some progress. See: trac.parrot.org/parrot/wiki/CleanupMakeHtml
No feedback on
trac.parrot.org/parrot/wiki/Resolve...rimentals, so no
changes planned there. 14:44
EOR
LAST CHANCE to get any deprecation notices in.
14:54 tcurtis joined 16:36 cotto_work joined 17:45 dukeleto joined 17:46 NotFound joined
NotFound What I did: 18:04
-parrot
* Just testing
-winxed
* Miscellaneous fixes
* Initial support for constructors
* Some more optimizations of const expressions
* Predef two args atan
* New opengl example fly.winxed, useful as a demo
What I will do:
No plan
EOR
18:11 darbelo joined 18:20 eternaleye joined 18:23 macroron joined 18:36 bluescreen joined
dukeleto can't make it to the meeting today, but will backlog later. good luck on the release today! 18:36
18:51 darbelo joined 19:25 mikehh joined 19:30 bubaflub joined 19:31 khairul joined
mikehh What I did since my last report: 19:34
* building and testing parrot on amd64/i386, with gcc/g++
* various fixes
* branch testing and some fixes
* some work on html_cleanup branch
* testing rakudo, partcl-nqp, partcl, pir/PIRATE, winxed and plumage
What I intend to do in the next week:
* testing and fixing
* more preparation as release manager for 2.7.0
.eor
19:35 PacoLinux joined
khairul Did: 19:36
.instrumented methods
.support vtable overrides
.added test for Instrument::Event::GC
.minor code cleanup
Will Do:
.blog post
.more code cleanup
.more tests 19:37
EOR
19:39 Chandon joined 19:55 whiteknight joined 19:56 NotFound joined
Util # Done: 19:58
* Started review and catalog of download/getting-started pages.
* Worked on Rakudo Win32 problems.
# Plan to do:
* Finish download review (today, if possible)
* Finish Rakudo Win32 problems
# Blockers:
* $WORK
.end
cotto_work #did: 20:02
- met with khairul
- did some proofreading on the Squaak tutorial
- tcurtis++ for doing the hard work of resurrecting it in the first place
#will do:
- not sure
# What needed improvement between 2.4 and 2.6:
- unexpected impact of deprecations
# What should the priority be for 2.9:
- get Lorito maximally usable
#eor
20:07 allison joined
tcurtis What I did: 20:08
* GSoC midterm evaluation
* PAST::Transformer transforming PAST::Block.control and .loadinit attributes.
* Updated the Squaak tutorial
- It's now in trunk.
- cotto++ for proofreading.
* Started exploring a somewhat different approach to Lorito assembly from that of atrodo++
- github.com/ekiru/yalp-asm
* Blog post:
- parrot.org/content/uneventful-mid-t...timization
What I plan:
* Research LLVM's PassManager and various pass classes.
* Design and implement analogous system.
* More blog posting
chromatic questions:
What one thing could we have done better in the series of releases from 2.4
to 2.6?
* We could have handled the dynops deprecation better.
What should be our highest priority task for the series of releases
culminating in 2.9?
* Lorito or object system improvements(although I suppose it might make sense to wait for Lorito to do that).
EOR
whiteknight WHAT I DID: 20:10
* GSoC Midterm evaluations. Congratulations to all our passing students!
* Following along with Chandon's thread work
* Spending all my spare time working on Kakapo. The breakage is bigger and more pervasive than I anticipated
WHAT I WILL DO:
* Work on Kakapo
WHAT I AM BLOCKING ON:
* Time
20:11 chromatic joined
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)
cotto_work q1q 20:15
tcurtis q1q 20:26
chromatic Hello, everyone. 20:31
cotto_work Hi
whiteknight hello\\
Util Hello
darbelo Hola.
tcurtis Aloha.
allison hi 20:32
mikehh hello
Chandon Hi
chromatic Any last minute requests before the release? Coke? 20:33
Coke I'll probably be doing the release later tonight; 20:34
any deprecation notices, now is an excellent time to discuss them and get them added. 20:35
+/or experimental additions/substractions.
chromatic trac.parrot.org/parrot/wiki/ResolveExperimentals
Right, going there now.
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.
trac.parrot.org/parrot/wiki/CleanupMakeHtml is the status of the make html cleanup so far. 20:36
chromatic Anything else? 20:37
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.
chromatic Let's review the 2.4 - 2.6 family. 20:39
Dynops changes were painful.
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.
And they're still not fixed. 20:40
SFAIK.
darbelo They are mostly workarounded, in the code we can see.
chromatic Any other thoughts on what didn't work so well in the past three months? 20:41
darbelo kthakore's troubles with parrot moving from under his code. 20:43
Coke the TT#389 fix.
chromatic Deprecation is hard work, as usual.
Coke basically summed up by "parrot is a moving target".
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"?
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.
cotto_work I'll make it a priority to whip that into shape.
Coke 2) as soon as the alternative is in place, add it to the list of "how to migrate to new feature".
(or say: "sorry, this gone for good.") 20:46
allison release branches are a traditional way of handling a trunk that moves too quickly
Coke also encourage those of us who are not just core hackers to update that when we find issues (like the tt#389 fix)
chromatic I'm not sure release branches will help.
whiteknight -1 to release branches 20:47
allison the maintenance effort is higher, which would be difficult for us
Coke I'm not sure it'll help the end users who are just targeting the .3 releases, either.
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
as Coke mentioned, bundled changes are easier than multiple scattered changes
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.
allison so, we should stop development ;) 20:50
Coke whiteknight: well, i think that distro's are the main customer there. 20:51
anyone actually writing an HLL probably is just targeting the .1s
(or svn)
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
(despite our imperfect application)
chromatic Right.
Other issues we can address in the next quarter? 20:53
My other one is: performance improvements. We didn't merge the new GC. 20:54
darbelo ENOBACEK
Coke question: is it worth focusing on anything non-lorito?
chromatic Focusing how?
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
cotto_work (i.e. we don't have anyone who's done enough tuning to make it work merging and using by default)
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.
chromatic We seem to have had fewer commits (apart from GSoC students, who are awesome).
cotto_work afaict
darbelo allison: It was faster in plces, slower in places. IIRC. 20:56
Coke which may be a misguided concern.
chromatic Coke, I see this as general cleanup and bugfixing only help us port code to a Lorito world. 20:57
Cleaning up namespaces, for example, hurts no one.
darbelo allison: bacek seemed convinced that it could be made fater all around by tweaking the limits that trigger gc runs.
Eh, faster.
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.
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
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.
Coke (especially running HLLs on it.) 21:00
cotto_work has a brief (please) meeting. afk for a few minutes
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.
He has some lifetime benchmarks too.
That's a good place to start.
Let's move on to priorities for 2.9. 21:03
Everything I've read so far said Lorito.
Coke I will have to leave shortly. I'll be online later this evening to work on the release.
chromatic How?
whiteknight How what? 21:05
Coke I think we might need to table that until we have that POC working, no?
darbelo Coke: You've stated 'How': Make the POC work.
chromatic We have a working ops2c; could we get a working pmc2c? 21:06
Coke sure, we could rewrite pmc2c in NPQ.
chromatic We have a PIRATE getting close to working.
darbelo We have POST -> PBC within reach too.
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:07
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
chromatic How do we do that? 21:09
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
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.
What's the underlying code and what does it take to get something like ops2c targeting it?
mikehh A couple of people are playing around with POC stuff - we need some more ideas like cotto's trac.parrot.org/parrot/wiki/LoritoOps 21:13
allison with our recent emphasis on distributed design, I think it's important for the technical plan to be a group effort 21:14
what's the best way to make that happen?
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.
mikehh through the wiki maybe? 21:15
chromatic That seems like the most important process question to answer in the next quarter.
darbelo We can't do that until we know what the opcodes are.
allison we have the starting opcodes, and an initial implementation of them
chromatic darbelo, I've assumed that we can have an opcode which is basically "Call this C function".
Coke I recommend meetings (either take over parrotsketch or otherwise) of interested parties. either on irc/wiki/email./
mikehh we really won't know that until we do some more POC work
Coke if someone wants to drive, they can make a target on the wiki for people to talk about. 21:16
... c.v.f. cotto for lorito
chromatic Any other suggestions for the next quarter? 21:18
mikehh getting the GSOC stuff incorporated
chromatic Good one.
Are the students on track?
mikehh well tcurtis++ is certainly branching out 21:19
and some of the other stuff looks good
tcurtis I'm a few days behind due to Squaak, but I'll hopefully be back on schedule soon.
chromatic Should we suggest that students try to merge trunk changes when they reach a good merge point? 21:20
darbelo FSVO 'merge point' 21:21
mikehh that should depend on the mentor's to a certain extent - and suitable testing
chromatic "My tests all pass and I am confident in merging or at least begging my mentor for help." 21:22
Any other area of focus for Q3?
mikehh adding tests to improve coverage 21:23
chromatic Always a good one.
Let's move on to questions.
darbelo q1q 21:24
mikehh and again not closing tickets until suitable test are there
s/test/tests/
chromatic tcurtis?
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
NotFound +1 21:26
mikehh _1
darbelo +Inf
mikehh bah +1
allison +2
chromatic There's no two, Bender. It was only a bad dream.
Let's call that unanimity. darbelo?
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
chromatic Automate it from smoke reports?
Util Call for updates?
"unmaintained" - well, it should be updated one line at a time when someone fully tests on a platform. 21:29
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.
darbelo You are right, out-of-date is the wrong term. 21:31
'Un-updated' is the thought I was trying to voice.
mikehh need t5o keep it "up-to-date"
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.
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.
chromatic Likewise.
mikehh I think it should be more of parrot works (with some caveats maybe) on this platform 21:35
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 :)
chromatic Thanks.
cotto_work, question?
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?
chromatic At the lowest level (let's call it M0 for Microcode level 0), I can imagine not worrying about types. 21:38
It's all memory and offsets.
Chandon q1q 21:40
allison yes, one opcode with sane coercions is much better than weird specific types
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
as in, we currently have some parts of the system where we coerce a PMC to a low-level type, and then back again
which is silly 21:42
if opcodes don't care about types, then we only coerce when it's absolutely necessary
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
cotto_work e.g. xor $I0, $I1, $I2
allison not necessarily, e.g. why should addition always be integers or floats?
xor makes sense, as it's a boolean operation
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?
allison xor $I0, 5, $P2
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?
cotto_work chromatic: I had been thinking that there'd be only one level below PIR.
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?
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
chromatic I've been thinking that the POC ops are M0, our current ops are M1, and then you have PIR.
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.
tcurtis cotto_work: or do a multi-method.
cotto_work I'm saying that that coercion should happen explicitly rather than as part of add.
allison we do have types currently, that's how we know to dispatch to add_i_ic_ic versus add_p_p_p
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.
allison and the weird patterns where an op has some type combinations but not others
NotFound allison: AFAIK that's not dispatch, is PIR compiling. 21:49
cotto_work I agree with avoiding a combinatorial explosion.
I'm talking about the lowest level ops.
allison NotFound: it's true, it can live at that level, but currently it's a mixture of both
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.
NotFound If you plan to use just an address, you can't dispatch at the lower level with primitive types.
allison providing box/unbox operations at the lowest level could be enough 21:51
then limited type-specific operations
cotto_work I think we agree.
chromatic box/unbox seem too high level for M0
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
but, as long as it's trace-JITable, we're fine
chromatic: M0 must contain all behaviour for the higher levels
chromatic Backwards.
All higher level behavior must be expressible in M0. 21:53
allison aye, that's what I said (or meant to say)
chromatic If M0 doesn't know what a PMC is, so much the better.
allison if box/unbox can be expressed using other low-level ops, no problem
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.
allison and what series of low level ops compose the section in between? 21:55
calls to C functions aren't JITable
(unless the C function is actually a JIT template
chromatic Calls to C functions we haven't yet migrated to Lorito aren't JITtable yet. 21:56
The more M0 ops, the harder it is to JIT.
The more complex M0 ops, the harder they are to JIT.
allison yah, and also the M1+ ops need to be defined entirely in terms of M0 ops 21:57
(or compositions of lower level ops, which are ultimately compositions of M0 ops)
chromatic Exactly.
21:58 pmichaud joined
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
(but otherwise, we'll need them)
chromatic That's my guiding principle.
allison "Call this C function" doesn't count as composition
tcurtis Should M0 have support for method dispatch in any form? 21:59
allison tcurtis: it has "call"
which is method/vtable on a PMC
(the two being largely the same thing in Lorito)
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
tcurtis +1
allison there's some question about add being int or float 22:02
would have to default to float, if we really picked only one
cotto_work I picture there being add_i and add_n
chromatic add_i and add_n make sense to me.
tcurtis There should probably be math ops for both int and float, with explicit specification(at M0) level of which you want.
allison and since we require explicit coercions, there's no trouble picking which to use for PMC type calls 22:03
cotto_work great
one decision down, 127 more to go
;)
eoq as far as I'm concerned 22:04
chromatic Anything else?
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:05
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.
cotto_work revs his deprecation enforcement chainsaw
dukeleto q1q 22:07
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.
chromatic +1 to remove unworking things, +0.5 to giving a specific time frame for its replacement.
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?
chromatic Right.
Get that notice in before Coke comes back.
dukeleto, question? 22:10
Chandon Where do deprication notices go again?
darbelo DEPRECATED.pod with a supporting Trac ticket.
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?
allison unknown 22:11
AFAIK, there is no substantial use of threads anywhere currenly
dukeleto Are we providing sha1 sums for the release today?
NotFound Chandon: Have you checked coverage?
Chandon NotFound: Coverage?
NotFound Chandon: code coverage of the C functions in that file. 22:12
tapir2.ro.vutbr.cz/cover/cover-results/
chromatic Anything else? 22:14
mikehh dukeleto: need to ask Coke that when he gets back 22:16
cotto_work um... meeting dismissed 22:24
22:24 dukeleto left
Coke following up on Util's coment about getting people to update PLATFORMS. Did I not mention this in the email? 22:25
(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:30
22:45 darbelo left 23:27 pmichaud left 23:54 Coke left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!