Vision for 2.0: Production Users | Priority for 1.8: Testing Sprint | Priority for this week: close RT tickets | 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 24 November 2009.
06:28 particle1 joined 12:14 bluescreen joined 12:25 bluescreen joined 12:28 bluescreen joined
japhb DONE: 16:38
* Lots more metadata updates, fperrad++, dukeleto++, vadrer++
* Now at least 23 projects have Plumage metadata
* Convert Glue.pir code to native NQP-rx features as they become available
* Util.nqp reduce() implementation that doesn't entirely suck to use
* Improve output of projects command
WIP:
* Continued major refactoring. About 80% done now. 16:39
* Details of remaining refactoring unclear, need more code to clarify path forward.
MAD PROPZ:
* fperrad++ # Metadata updates, Win32 testing, assisting conversions to setup / plumage
* dukeleto++ # Metadata updates
* tene++ # try/CATCH
* cotto++ # Parrot build GUID/UUID suggestion
NEXT UP:
* Time to start adding more features again, before returning to refactoring.
* Figure out how to add per-build unique ID to parrot config
BLOCKERS:
* Hash literals in NQP-rx. pmichaud++ has said he will entertain patches, but I have not had enough time to do so myself. I would be most appreciative if someone jumped in and made this happen!
EOR
16:40 ascent joined
Tene I'm apparently alive again. This past week I've been working on ng and getting caught up on updating languages to use nqp-rx. 17:55
* Migrated steme to nqp-rx
* Implemented proof-of-concept macros in steme with nqp-rx. Looking forward to implementing that in rakudo.
* Added gather/take and loop to ng, along with some other minor fixes.
* Added exception handling to nqp-rx.
IN THE FUTURE:
* Migrating other languages to nqp-rx.
* More work on ng.
* Investigate vtable override speedups, credit to chromatic.
* Maybe more work on Web.pm? HLL stuff? Dunno... make requests.
BLOCKING:
* I want to add lazy gather/take to ng, but blocking on iterators interface redesign from pmichaud.
KTHXBAI 17:56
Oh, maybe a Select PMC! I just remembered about the IO stuff I wanted to work on.
18:01 Coke joined
Coke partcl-nqp (done): 18:01
- now able to run six of partcl's tests; re-adding bits as quickly as possible.
- want to write some perl6? this version of partcl is written almost entirely in the new NQP. Between the test suite, the original PIR
.
dukeleto Report 18:05
* I wrote a TAP Harness in PIR called Tapir: github.com/leto/tapir
* I nominate bubaflub++ for commit access. He has been translating tests like a madman.
* I will be around in #parrot later.
.EOR
18:08 bubaflub joined, barney joined
Coke Also: groups.google.com/group/partcl-dev/...abbefd898a 18:12
18:18 pmichaud joined
pmichaud What I did (since 2009-11-03): 18:21
* Worked more on NQP, added new version of NQP into parrot repo
* Started an nqp-based version of partcl
* Continued working on Rakudo 'ng' branch
* Various performance profiling items
** See my latest message to parrot-dev at
lists.parrot.org/pipermail/parrot-d...03431.html
What I'm doing this week:
* Continuing to work on Rakudo-ng, iterators and lazy lists
* More nqp-rx updates, error message improvements and better
syntax checking, regexes
* More profiling to find speed improvements
What I'm blocking on:
* Time
* Broken ISP connection
EOR
q1q
barney q1q 18:27
Util No report from last week. Tuits renewed this evening; will pick back up on outstanding tickets. 18:28
cotto_work Done: 18:29
* ported pprof2cg to nqp
* It's really slow. (26.5x on my dev laptop)
* pmichaud seems to think that the ugly pir that nqp has to generate to work around the lack of an lvalue model doesn't cause a major slowdown
# Will do:
* try to figure out how to make Callgrind-compatible output testable and not painfully slow
* if nqp can't be made fast, pushing the Callgrind output code into the runcore may start to look like a good idea
* either way, profiling is in order
# Blockers:
* life
EOR?
dukeleto 'ello 18:36
cotto_work hello 18:37
18:37 chromatic joined
chromatic Sorry; called away briefly. 18:37
dukeleto is back in time!
chromatic Hello, all. 18:38
dukeleto waves
barney hi
bubaflub hello
Util hello
chromatic Let's review weekly priorities. 18:39
We have a new release in two weeks, right?
dukeleto yes!
what needs to be in 1.9.0 ?
chromatic Most of the code changes we want in 2.0.0. 18:40
dukeleto chromatic: that is a tall order. do we need a gc sprint? 18:41
chromatic We should discuss that.
Clearly we have a performance gap.
dukeleto bubaflub: where is your report? 18:42
chromatic The wiki page we made a couple of weeks ago has PIRC on it as well. 18:43
Does anyone think we can make PIRC an optional component by January?
Coke no 18:44
chromatic Should we focus on performance for the next few weeks?
I can think of a couple of possibilities.
dukeleto chromatic: make it optional, maybe. will it pass all the tests? no. 18:45
chromatic: i like performance
chromatic: we can really do some amazing performance tweaks in 1.5 months. we need to make NQP and Rakudo faster
and HLL's in general 18:46
chromatic Other suggestions?
bubaflub sorry, here's the report:
Done: 18:47
* Couple tests to PIR
* CLA in the mail
To Do:
* Even more tests to PIR!
dukeleto more like a couple hundred tests translated to PIR
chromatic: testing and performance are worthly goals for 2.0 that we can accomplish. other goals have the chance of falling short because they are not as incremental 18:48
bubaflub i've got a few patches for tests in t/compilers/*/* but haven't submitted to tickets yet
chromatic My concern is that I haven't had time to do profiling and optimization, and I haven't seen anyone else poke at them.
Of course, if everyone else is as busy as I am.... 18:49
dukeleto chromatic: i can do benchmarking, but I don't have a place to run kcachegrind yet. os x and kcachegrind hate each other.
Coke dukeleto: ay. 18:50
chromatic Any objection to setting specific performance goals for the upcoming weeks then?
cotto_work +1 18:52
dukeleto chromatic: let's set some specific goals
chromatic The VTABLE override task is specific.
Beyond that, we need to figure out how to land the Context/CallSig merge bacek started.
dukeleto chromatic: what is the name of the branch? 18:53
chromatic: i think gc performance should also be worked on. i will do gc benchmarks
chromatic It's unlikely we'll fix GC performance without writing a new GC, and I have my doubts anyone will support that going on by default in 2.0. 18:55
pmichaud ...a swappable GC would be worthwhile, though.
that might be doable by 2.0 18:56
particle i'm for that
Coke I thought we already had that.
chromatic It *should* be swappable already.
Coke (see also: infinite memory allocator)
chromatic We need docs from whiteknight to figure out how to replace part or all of it.
pmichaud if we already have one, then there's no downside to starting work on gc issues pre-2.0
particle a new, non-default gc is a worthy goal
dukeleto yeah, i thought our gc was pluggable with a command-line option? didn't jtayloriv work on that?
Coke particle: "that is better than our current one." =-)
pmichaud s/no downside/little downside/
particle coke: even if it's not, we need to prove the api is solid 18:57
dukeleto do we have a commandline flag to turn the GC off? 18:58
that would be useful for our RTEMS port
chromatic -G 18:59
dukeleto chromatic++
dukeleto is attempting to compile kcachegrind on os x, again 19:00
bubaflub good hunting dukeleto
chromatic Any other comments on performance goals?
Coke chromatic: +1 from me. 19:01
chromatic Let's move on to questions then.
pmichaud?
19:02 mikehh joined
bubaflub q1q 19:02
dukeleto does anybody have ops, and/or can someone change the topic? 19:05
pmichaud my question was simply to point out my latest message to parrot-dev about gc cost and to see if we can get energy focused on it :)
seems lik that's being addressed, so eoq from me
chromatic barney, your question? 19:06
barney I wondered whether GDBM Hash should be removed, but I see it's a dynpmc already
chromatic bubaflub, your question?
bubaflub i just sent my CLA in the mail, and was wondering if i could get a commit bit
chromatic Any objections? 19:07
dukeleto bubaflub++ # give this man a bit
particle after your cla is received, and you get two +1 votes from committers, you can get a commit bit 19:08
cotto_work +1
barney bubaflub++
mikehh +1
Util +1
bubaflub no secret initiation?
dukeleto bubaflub: i have the tar and feathers waiting
cotto_work You'll know when it happens.
particle it's no secret to the rest of us :)
bubaflub hahahaha
barney the secret is that there is no secret 19:09
bubaflub that's like schrodinger's secret
Util Schrodinger's secret might actually be a secret. Or it might not; it is hard to tell without looking. 19:11
bubaflub and with that that's eoq for me
chromatic Other questions?
dukeleto q1q
chromatic go ahead, dukeleto. 19:13
dukeleto What do people want and need from a PIR TAP harness? I am looking towards it being the default for HLL's in the mk_lang_shell script.
it being Tapir
barney I'd like a 'language_output_is() 19:14
for TAP generation
dukeleto barney: what would that do?
Util dukeleto: a better TODO interface than is currently in test_more.pir.
dukeleto Util: i wrote a TAP consumer, not TAP producer 19:15
mikehh +1
barney run a piece of HLL code and compare with the expected output
Util Doh!
dukeleto barney: that is a TAP producer, not a TAP consumer
Tapir is a TAP Parser and Harness. A consumer of TAP.
it is really fast. Much faster than Test::Harness for small test files (~100 tests). As in roughly 1/3 the running time 19:16
Tapir could replace t/harness in Parrot and every HLL
and shave an enormous amount of time from our test suite runs
Test::Harness is just amazingly inefficient and really slows things down 19:17
which would allow development to move more quickly and have lots of other wonderful benefits
mikehh does it provide the same or better functionality than t/harness? 19:18
dukeleto mikehh: it will. currently it does not know about SKIPs or exit codes, but that is a few hours work. also, it does not know about TEST_JOBS, yet 19:20
mikehh: but the speedup could be so great that running tapir tests in one process is faster than TEST_JOBS=4 with Test::Harness
mikehh: Tapir has been written to be very testable from the ground up. It tests itself.
mikehh: are there features that you want that Test::Harness does not provide? 19:22
mikehh: oh yes, submitting to smolder is an issue, but it can be solved. All of these issues are in the TODO file in the Tapir repo 19:23
i will probably just port TAP::Harness::Archive to PIR
chromatic Other questions?
Let's call this a week then. 19:25
dukeleto ENODISHES
Util $_ == 'week'
s/==/eq/
dukeleto if someone is feeling really awesome, please change the channel topic to something useful 19:26
chromatic Which channel topic? 19:27
19:28 davidfetter joined
Tene dukeleto: this channel doesn't have +t set, so anybody can change the topic, including you! 19:30
19:31 bubaflub left 19:33 davidfetter left
moderator Vision for 2.0: Production Users | Priority for 1.9: Performance and Testing 19:45
20:26 PacoLinux left 20:32 tewk joined 20:41 bubaflub joined, mikehh joined, bubaflub left, bluescreen joined 20:51 mikehh joined 20:57 mikehh joined 21:19 mikehh joined 21:24 mikehh joined 21:25 chromatic left 21:30 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!