Vision for 2.0: Production Users | Priority for 1.6: Merge Branches | Priority for this week: stability after branch merges, increase test coverage on Linux x86 (no %, calibrating workload) | 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 25 August 2009.
00:52 japhb joined 04:22 davidfetter joined 04:48 mikehh joined 09:12 allison joined 09:13 allison left 12:30 mmpf joined 12:31 TimToady joined 12:42 spinclad joined 13:16 mikehh_ joined 13:23 mikehh joined 14:00 PacoLinux joined 14:40 jhorwitz joined 15:04 samlh joined 16:02 cotto joined 16:21 darbelo joined, allison joined
allison - Between family visit and Foo Camp conference, I had very little Parrot time this week. 16:21
- Talked with pmichaud and Ryan Niebur about Debian Rakudo releases.
- Parrot Foundation elections went smoothly. This year's directors are particle, Coke, chromatic, jhorwitz, pmichaud, and me.
- Next thing we need to do with ParF is accept new members (new committers and non-committers).
- UK visa finally arrives this morning, am on a standby flight to London in the afternoon. Will try to make it to #parrotsketch from the airport, but posting my report early, just in case. 16:22
EOR
16:32 pmichaud joined
jhorwitz refactored mod_parrot configuration to work with installed parrot/rakudo 16:37
(hopefully) fixed configuration bug reported by Tene++
currently fixing ModPerl6::Registry to work with some subtle IO changes in Rakudo 16:38
EOR
16:49 whiteknight joined
whiteknight What I did: 16:49
* Deleted the old gsoc_pdd09 branch. Saved some things locally from it and may try to continue work on this eventually
* Talked with chromatic about ideas for ways to improve that general design.
* Deleted the io_cleanup branch in defeat.
* Saved some diffs from the io_cleanup branch, will try to break it into smaller tasks and continue them later
* Cleaned up a few other old branches too.
* Tried to help bacek in the context_pmc3 branch, but didn't manage to be too helpful.
* Added an evil hack for bacek to get around a PCC-related issue. Desperately waiting for pcc_arg_unify to help with this
* Did start looking into a fix for his JIT-related test failures, no solution so far.
* Put a note to the list about deprecating JIT. Looking for much more feedback about that 16:50
* Took a look at a patch from jrtayloriv to cleanup the Continuation PMC. Created the kill_parrot_cont branch to explore that.
What I will do:
* Help to shephard along the context_pmc3 and kill_parrot_cont branches, maybe try to get them both mergable.
* Misc cleanup, a lot of merges and commits lately have left the code in need of some TLC.
* Mostly busy in $real_life, so can't do much.
What I am blocking on:
* Not enough time.
EOR
16:51 jonathan joined 16:53 treed joined 16:59 chromatic joined
jonathan Rakudo 17:01
* Fixed a few bugs
* Started to research and think about the signature re-design and re-implementation
* Got some good input from TimToady++ on some areas of the spec
* The grant that I hope will fund me to complete the design and do the implementation of this should be up for public comment soon; aiming to do the bulk of it in October and November, when my schedule is pretty clear, and get it finished up early to mid December. Think that's fairly realistic.
Blizkost
* Started this new project to embed Perl 5 and expose it through the HLLCompiler interface
* Already four commiters including me: cognominal++, fperrad++ and leto++
* My first cut just handled basic string eval, but only took a morning to hack up
* eval('print "hello from p5"', :lang<perl5>) in Rakudo Just Worked after that :-)
* Build was sucky; others have taken care of fixing it up on Linux and OS X
* Next step is to be able to use the return value from the eval
Other
* I'm going to wander around Asia for the next four weeks, so probably won't make #ps
* Will take in YAPC::Asia as part of it, and maybe something with Perl folks in Korea too
* However, trip is mostly for relaxing, exploring, and getting myself re-charged for the months of work ahead towards Rakudo *. 17:02
.end
chromatic Answering questions, exploring things.
Will remove _synchronize member from PMC struct soon.
Will help cotto with profiling runcore merge.
Looking at further optimizations, including Lorito.
cotto # What I did: 17:23
* first stab at getting high-resolution cross-platform timing information
- a windows wrapper around GetProcessTimes() failed to be useful
- currently there's a less accurate (but functional) version using QueryPerformanceCounter
- some nice work from darbelo++ should give us the optimal CLOCK_* value on various unicies
- branch will be ready for testing later today (instructions in POD in tools/dev/pprof2cg.pl)
- will merge after chromatic has a chance to make the code less bad
# What I hope to do and how many tuits I expect to have:
* get profiling ready for testing (later today)
* merge the runcore branch back into trunk
* start a new branch for integrating annotations
# What could block my progress:
* ""
eor
17:39 Coke joined 17:49 Util joined
Coke My report: partcl.blogspot.com/2009/09/now-pas...tests.html 17:53
pmichaud What I did: 18:14
* Fixed some Parrot bugs and closed some PGE/PCT tickets
* Removed string-based class comparisons from Class.isa
* This results in a ~4.5% speed improvement for Rakudo spectests
* Improved Rakudo's Configure.pl to detect when attempting to build against non-devel Parrot, and/or when needed files are missing
* Moved several Rakudo builtin operators into setting
* Enabled overloading of builtin operators
* Answered lots of questions on IRC and other forums
* Participated in a local Rakudo hackathon
* Added rational (Rat) datatype to Rakudo
* Worked on Rakudo packaging for various OS distros
What I'm doing this week:
* More grant-related administrative things
* Finishing up a variety of operator-overloading tasks
* Cleaning up the handling of type coercions, vtables, etc. in Rakudo
* Adding contextual variables to NQP and Rakudo
* Working on many other PGE/NQP updates
What I'm blocking on:
* Insufficient tuits, although I have more tuits this week than I've had for a while now
EOR
mikehh What I did: 18:22
* testing trunk on amd64 and i386 and context_pmc3 branch on amd64
* testing rakudo, partcl, cardinal, decnum_dynpmcs on latest parrot build
* lua failed to build for me
* fix test failures when I could track them down or pass them on to NotFound++
What I will do:
* continue with testing and fixes
* looking at the Configure.pl set up of the test suite
.eor
Util # Done: 18:24
* Updated TT#504 (packfile pmcs milestone) to answer bacek's comment of "Task is finished from my point of view".
# Plan for next week:
* Add tickets and details on duplicating my results on round-trip failures and from-scratch construction of hello.pbc.
* All Packfile PMC issues.
# Blockers:
* Tuits still limited.
.end
japhb Short report: Tene did the eval-in-NQP work I asked for last week, but I have been unable even to check that it's working for me. @work_deadlines right now, but hope to find some cycles late in the week. WOR 18:25
er EOR 18:26
18:29 allison joined
chromatic Shall we begin? 18:30
mikehh go for it
duk3leto 'ello
Util Hi 18:31
allison hi
japhb o/
chromatic What were our priorities for last week? 18:32
Coke hi
allison stablize branches
Coke I'm assuming that's in the topic.
Util Priority for this week: stability after branch merges, increase test coverage on Linux x86 (no %, calibrating workload)
allison increase test coverage
chromatic How'd we do on stability?
whiteknight +1 18:33
Coke chromatic: pretty good, from partcl's standpoint.
duk3leto What I did:
* Wrote tools/dev/parrot_shell.pl
* Converted many tests to PIR
Plan:
* Convert more tests to PIR
whiteknight not perfect, but NotFound has been kicking some major butt
cotto hi
chromatic How about test coverage? (I fear not well...)
Util I think the idea was to try for a week, to see what a reasonable goal would be for future weeks. 18:34
chromatic Did anyone work on it? I didn't.
whiteknight did anybody write any tests? 18:35
me either
duk3leto whiteknight: i did add a few while converting some to PIR
mikehh context_pmc3 branch passes all but 1 codetest failure, rakudo PASSes with patch, partcl PASS
allison Util: aye
that gives us a baseline :) 18:36
no work = 0% increase in coverage
Util Coverage scan at tapir2.ro.vutbr.cz/cover/cover-results/ say: 40695=66.0%, 40848=65.8% 18:37
But that could be due to code added during branch merges
chromatic Perhaps we should pick a PMC and try to improve its coverage.
allison cotto: it was a good idea, maybe another approach? 18:38
like pick a particular source file?
mikehh I was looking at make cover and trying to devise some tests - not too far along 18:39
18:39 Tene joined
cotto allison, possible. It could also be an issue of tuits. 18:39
allison mikehh: sounds good
chromatic Let's review 1.6 milestones. 18:40
Util q1q
chromatic Export conventions, pmichaud?
pmichaud didn't have that on my list for this week but will add it.
it goes along with the NQP changes I'm working on, so it's not really additional
chromatic packfile PMCs, Util? 18:41
japhb pmichaud.q1q
Util I should have the detail tickets written up today. Volunteers welcome after that point :) No projection on completion if it is just me working on it.
(Trying for 1.6, anyway, tho) 18:42
chromatic profiling, cotto and me... I believe we can merge shortly.
There will likely be corner cases, but it should be stable.
cotto yes
japhb chromatic++ cotto++
jonathan chromatic++ cotto++ # *very* happy to hear about the profiling progress. 18:43
chromatic That includes pluggable runloops, but they're not dynamically loadable yet.
(I briefly consider making some of the exotic runcores pluggable, but not yet.)
Seed libraries? Was that japhb? 18:44
japhb chromatic, that was put on hold while I worked on the ecosystem ...
... which has been stalled this week
. 18:45
chromatic Objects PDD review? Who's on track for that?
whiteknight last I heard Allison had a claim staked 18:46
allison me
chromatic Status?
whiteknight ENOSTATUS 18:48
allison at the airline desk, come back in a minute
Coke q1q 18:49
chromatic Struct pruning... I made little progress except for a discussion of slimming PMC. I saw some discussion of slimming STRING. 18:50
Big wins there.
Util, you had a question.
Util Trac Ticket Report {19} (Newbie Tickets) fails. Who is the author? Need any help?
cotto That might be mine. ISTR creating something like that. 18:51
mikehh q1q
allison ok, done
duk3leto Util++ # having the newbie ticket link working is important for new contributors
whiteknight q3q 18:52
chromatic allison, Object PDD review?
cotto Util, go for it.
Util cotto: will do. More on #parrot
allison status on objects, started review
creating list of any remaining work 18:53
chromatic Coke, question?
allison (the task is to check what we might have missed in the earlier imple.)
.end 18:54
Coke chromatic: NotFound has done a great job getting partcl running again, avoiding about 30 segfaults ...
... still have several segfaults remaining, but these are repeatable; I'm opening tickets for them all today; it would be most helpful if we could get them resolved before the next release. 18:55
.
chromatic mikehh, question?
mikehh I am getting a lot of codetest/distro_tests failures with svn properties from git svn users 18:56
any way to sort this out?
chromatic We talked about autoprops set on the server with a commit hook. 18:57
allison are they not able to set svn props?
japhb fights the urge to troll an old argument
allison they coul 18:58
chromatic The old argument "Why are these properties useful again?"
japhb allison, that's correct, git-svn does not handle svn props. So git-svn users need to have a normal svn checkout, and remember to run the codetests in there after committing new files.
*have a normal svn checkout *also* 18:59
allison (cellphone keyboard)
that doesn't sound so terrible
japhb allison, no, but very easy to forget. :-/ 19:00
mikehh well the svn:keywords appear in the header
of the file that is
allison chromatic: server-side hooks are a good idea, but how do we know for sure when to apply them? 19:01
chromatic We *always* apply them.
japhb mikehh, I mean, easy for a git-svn user to forget to give the svn props a hug, after doing a big commit people tend to think they are done and go grab a beer.
chromatic They're basically the *same* on *every* file in the repository.
allison c: not all props apply to all files
chromatic I can think of two files out of our 6500+ which have different properties. 19:02
mikehh svn:mime_type for tests
allison txt vs binary, etc
Coke we wouldn't need the mime type if we had sane server defaults.
japhb allison, but if there is a computer-understandable rule that works 95% of the time, we should have the computer apply it, and let humans override it.
duk3leto allison: there is no git svn propset
allison japhb: git users wouldn't be able to interact withit 19:03
but can correct later 19:04
duk3leto japhb: git svn propget works, just not setting
japhb duk3leto, nodnod
chromatic Let's move this discussion over to #parrot.
allison any volunteers
chromatic Volunteers for server-side hooks? 19:05
allison (can't join #parrot from here, but log my thumbs up for exploring adding server-side hooks) 19:06
Util I wrote code months ago to analyse our SVN properties, but just used it for manual corrections. Have not done serverside hooks, but willing to try.
chromatic whiteknight, you had some questions.
whiteknight Three of them
Q1: What's the big difference between RetContination and Continuation? Would they be suitable to merge? 19:07
chromatic We know that we can recycle a RetContinuation immediately.
whiteknight but that's not necessarily a savings
chromatic Why wouldn't it be?
We know we don't have to mark anything reachable from it, for example. 19:08
whiteknight recycling manually or recycling automatically in GC will call the same routines and take the same amount of time
chromatic Not true.
allison RC also flattens the cont chain, but that's not necessary
chromatic If you can recycle a GCable without marking and sweeping to find it, you've avoided marking and sweeping to find it. 19:09
whiteknight If there's a significant difference, its a moot point, but I would like to see the two merged
pmichaud why is it not necessary to to flatten the cont chain (ooc)?
allison on the flip side is there any advantge to merging them? can't see much
whiteknight chromatic: if it's dead, you don't mark it, only sweep it
pmichaud if a RetContinuation doesn't do it, what does?
whiteknight allison: decreased code volume and increased maintainability
small nit, obviously not worth pursuing. EOQ 19:10
Q2: I'd like to nominate jrtayloriv to become a committer
allison pmichaud: not sure what you mean, i'm talking about a hacky optimization
chromatic Seems like a low priority compared to other things.
jrtayloriv gets +1 from me
pmichaud allison: I probably need to rethink my question then :) 19:11
+1
whiteknight he's been sending in some nice patches
mikehh he's done done some quite amazing work
chromatic Any concerns? 19:12
whiteknight he does need to do a CLA
jonathan pmichaud: RetContinuations get promoted to full Continuations if there's a need. 19:13
pmichaud jonathan: yes, I know that
allison a mentor?
whiteknight I volunteer
pmichaud jonathan: I'm more after what the semantic difference is between the two
allison sounds good
Coke jrtayloriv++
duk3leto +1 for jrtayloriv++
whiteknight okay, I'll get him to send in a CLA and go from there. EOQ 19:14
Q3: I mentioned this on the list, I want to deprecate the current JIT system for 2.0
and immediately start intense planning for a replacement
japhb +1
jonathan pmichaud: RetContinuation is only valid for a single invocation.
chromatic +1
allison too late for 2.0
Coke s/for/in 19:15
whiteknight ah yes, deprecate in 2.0
delete it immediately after 2.0
allison I'm okay with it, if we have a strategy for the replacement
jonathan What does it publicly expose that needs the deprecation cycle, out of curiosity?
chromatic --runcore=jit 19:16
Coke allison: even if we don't, is the current jit core at all useful?
(and if so, is it maintainable?)
whiteknight It also currently provides NCI frame building
mikehh the replacement should take over that
chromatic We should keep the NCI frame building.
allison if it's just escapism, then no
japhb chromatic, if --runcore=jit lies and just does --runcore=fast, is that sufficient "support"?
whiteknight chromatic: we should replace it. We can make a better and more portable frame builder
Coke japhb: works for me. =-)
jonathan japhb: That was kinda what I was hinting at too. :-) 19:17
allison i want a prototype for the new one
jonathan Is there anything we actually can't like about etc.
mikehh clang etc ?
allison at least a proof of concept
jonathan I agree with allison however that we should have something more concrete to go forward with.
Rather than "we rip this out at X date independent of if we know how we're moving forward". 19:18
Coke we need a plan to go forward; I disagree that we need it before removing the existing JIT.
japhb jonathan, I read whiteknight's suggestion as "We plan to deprecate at 2.0, but we start planning intensely NOW."
whiteknight I want to immediately start planning a replacement
not just a deprecation, a swap
chromatic Yes, but WHO CAN MAINTAIN THE EXISTING ONE?
whiteknight nobody, that's wo
chromatic Exactly.
jonathan (start planning now)++ 19:19
Coke so, whiteknight - get us a plan so we can argue about your plan instead of our lack of one. =-)
whiteknight we have been demonstrably inable to fix even small bugs with it
pmichaud ("just because we say that something is deprecated in 2.0 doesn't mean we have to remove it prior to 2.6")
mikehh afaik it only works (;-}) on i386 ( and not all platforms)
allison we can deprecate and remove before the replacement is finished 19:20
chromatic We're talking about code that doesn't work reliably, has known nasty bugs we're pretty sure we can't fix, isn't a core component because of cross-platform and bug issues, and even when it works provides little benefits.
japhb mikehh, it doesn't even truly work there. Just enough that people think it's working.
whiteknight chromatic: well said!
mikehh I did :-}
allison but, hand-waving "we'll replace it someday" isn't enough
japhb suggests dragging it out behind the shed, taking "Bessie" the rifle along .... 19:21
chromatic What's the alternative, keeping broken code around? I'm not sentimental.
duk3leto japhb++
Coke allison: would you rather keep the existing JIT if we had no replacement?
whiteknight allison: hard to estimate, but we should pencil in having a "good" replacement by 2.6 at the latest
mikehh +1 19:22
japhb allison, I really don't think people are wanting to wave hands. I think we're just wanting agreement to move forward into the research and planning stage
allison Coke: if we have no clue what to replace it with, yes
chromatic I'm sorry, but that's nuts.
whiteknight ...and all agree that the current JIT provides no benefits and serves only as an anchor to ongoing development
pmichaud
.oO( Why is "we'll do it someday" sufficient for some features but not others? )
mikehh there has been aa lot of new work in Java
japhb pmichaud++ 19:23
whiteknight A good context threading runcore will provide more performance benefit then our current JIT ever will
mikehh and of course .Net (Mono anyone)
allison c: 5 months is plenty of time
look.
Coke in any case, even though we disagree about the old JIT, we all seem to agree that we can do better. so let's avoid having to disagree about the old bit until we have to.
chromatic What's wrong with japhb's proposal? It's completely backwards compatible, and it makes --runcore=jit work on *more* platforms than it works on now. 19:24
Coke perhaps we can avoid that argument altogether.
allison deleting it says the fundamntal design is wrong
whiteknight we need to keep in mind that we do not "have JIT" now anyway. I've never had working JIT on my development system
particle chromatic: yes, by redefining "work"
chromatic It doesn't work and the fundamental design *is* wrong.
pmichaud I'll say it then: "The fundamental implementation is wrong"
whiteknight allison: the fundamental design of our current system IS wrong
allison that may be true
chromatic I've fixed bugs in the JIT on multiple platforms. It *is* true. 19:25
pmichaud it doesn't work. we can't maintain it. we can't port it to other platforms. that sounds like "wrong" to me.
particle it's not jit anyway, it's ahead-of-time
allison but then we must have an idea what is better
pmichaud allison: why?
.oO( lorito, also )
whiteknight chromatic: numbers that I have seen show fastcore is much faster then jit core
LLVM and libJit would be better
a pluggable API that supports both would be best
we can start writing that API now 19:26
chromatic whiteknight, JIT core works on 32-bit x86 Linux for speeding up Fibonacci benchmarks, but if we wanted to develop a compiler to run Fibonacci fast, we'd work on GHC.
allison pmichaud: if there's nothing better, then it can't be so bad
pmichaud yes it can
if it's blocking progress, that's worse than not having it
jonathan If it hinders development of other subsystems, it's bad.
whiteknight pmichaud: +1
And it DOES hinder these things
pmichaud you're assuming that keeping the existing jit is zero-cost. It's not zero-cost.
chromatic If it's an active lie in our marketing (Look, we have a JIT like all modern compilers!) it's bad.
allison whiteknight: are you willing to put together an options list for next week? 19:27
chromatic Why do we need an options list?
japhb And I have to constantly explain to people who bugreport OpenGL that they are running with JIT on i386 and thus are broken, and to recompile with JIT off, and voila, it works.
whiteknight allison: I'll have a treatise on the wiki by this evening
jonathan While I was at first reluctant to go with "pull it out without having a replacement plan" in case the replacement plan was "work from what we current have and refactor", I'm distinctly getting the impression that there's no way we can build off what is there now.
allison awesome
japhb whiteknight++ # JFDI
jonathan (From people who've looked at it and tried.) 19:28
pmichaud jonathan: recall the discussion from PDS last november on this topic -- I think we were agreed that we can't do much with the existing JIT.
whiteknight I'll write up the report. We can discuss it more then. EOQ
mikehh it certainly does NOT make sense in a lot of places for me
chromatic Let's move further discussion to #parrot. 19:29
Goals for this week?
Shall we work on 1) improving test coverage of a PMC
allison nice and specific
whiteknight which PMCs are short on tests? 19:30
chromatic Can I suggest the Namespace and Array PMCs?
mikehh has anyone got a specific one in mind?
whiteknight I like those two
mikehh why not both?
chromatic Let's do both. 19:31
allison namespace++
chromatic I'll also pick another struct to look at and prune.
Other focuses for the week, besides Coke's segfaults?
Coke Coke's memory PANICs? 19:32
chromatic YOU ASK TOO MUCH
Coke heh.
If I had to pick, segfaults are worse. =-) 19:33
chromatic Any last words?
moderator 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. 19:33
duk3leto chromatic: convert more tests to PIR 19:33
Coke NotFound++ for all his work on the segfaults. (again)
whiteknight NotFound++
chromatic Okay, let's call it a week everyone.
pmichaud japhb: you had a question for me?
japhb pmichaud, yes ...
I was wondering if you had more detail on what NQP work was planned for this week? 19:34
--> #parrot if you like, but since this is a planning meeting ...
.
pmichaud japhb: much of it is a bit exploratory -- seeing where I want to refactor things 19:35
japhb ah, ok
pmichaud adding attributes to class defs is included in that exploration
japhb cheers
That's the one I was looking for. ;-)
pmichaud so I can't say that it'll be done this week (or even soon), I will say that I'm looking at it and will do it if it's not too troublesome
japhb thank you
pmichaud it's on my list as a "this would be really good to have" for some of my other items as well
jonathan I could kinda use them too (in a month or so). 19:36
pmichaud right
anyway, it's highly likely they'll be addressed sooner rather than later
japhb Great. EOQ from my end 19:37
19:38 allison left 19:39 Util left 19:40 jonathan left 19:48 Coke left 20:19 darbelo left 21:45 jrtayloriv joined 21:46 jrtayloriv left 22:18 Whiteknight joined 22:21 treed 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!