Vision for 2.0: Production Users | Priority for 1.6: Merge Branches | Priority for this week: get PCC branch mergable, increase test coverage on CallSignature PMC | 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 6 October 2009.
02:39 mikehh joined 05:21 japhb joined 12:07 kid51 joined
kid51 kid51's report 12:20
* Created two branches to prepare for future work on new Jit capabilities.
** detect_llvm: Create config step auto::llvm and test it (trac.parrot.org/parrot/ticket/1075)
** auto_libjit: Bring plobsing's patch (trac.parrot.org/parrot/ticket/1105) into SVN
* Prepared to merge library_files branch into trunk (trac.parrot.org/parrot/ticket/1061); this will be completed later today. 12:21
* Prepared patch for doc error (trac.parrot.org/parrot/ticket/1104); would appreciate one more review before applying.
* Confirmed mikehh's report of failures in two test files when run through each of 3 alternate cores (trac.parrot.org/parrot/ticket/1102#comment:2). We should assign high priority to diagnosing and fixing these so that they don't become release blockers.
* Reviewed open TTs and posted some comments aimed at seeing if tickets are closable (TT 602 (allison), 894 (bacek), 941 (allison), 890 (satrac)
Blocking on:
* pcc_reapply branch: t/op/gc.t hangs indefinitely during 'make coretest' and 'make test' if configured without --buildframes=0 on Linux/i386. This prevents me from submitting Smolder reports that reflect a default configuration.
* tt509_install_files branch: I have for many weeks now requested review from someone on Win32 or non-symlinkable system (trac.parrot.org/parrot/ticket/509).
13:32 barney joined 14:19 schmalbe joined 16:24 cotto_work joined 16:32 kurahaupo joined 16:33 mikehh joined 16:54 einstein joined 17:22 pmichaud joined 17:27 Coke joined 17:29 moritz joined
moritz I don't really have a report - no parrot work (I focus on Rakudo and Perl 6 these days), just want to ask people to review tt #757. Thanks. 17:31
kurahaupo Not much to report. (Spent too much time arguing about how arrays should work and not enough doing.) Am working up a proposal for refactoring the whole collection of array PMC's in ways that should actually be useful to support threading, but I need more feedback before I'll commit to implementing it. See trac.parrot.org/parrot/wiki/ArrayTasklist 17:37
17:41 Util joined
Coke partcl: Still have unaddressed segfaults. :( Finalized source repo migration from googlecode+svn to github. 17:41
(Dukeleto++ did all the work here.)
Can now build/test/smoke again from pure git checkout.
Was using git-svn, really liked the git, hated the git-svn.
(Nothing else migrated yet, unsure yet if I will.)
Need a parrot plan for how to implement [uplevel] using the parrot call
chain.
japhb DONE IN PLUMAGE: 17:56
* Handle fetching over old working dir, including when changing repo types (as partcl did)
* Add rx() function for compiling regex strings, until nqp-rx is ready for use
* Likewise all_matches()
* Various small cleanups
* Fix gitoriousparser plugin for dalek-plugins
MAD PROPZ:
* darbelo++ # help with cleanups
* dukeleto++ # plumage source tree reorg
* dukeleto++ and Tene++ # plumage test harness and test suite
* dukeleto++ and Infinoid++ # gitoriousparser work enabling a parrot-plumage dalek feed
NEXT UP:
* Not much this week
BLOCKING ON:
* Day job + sick family, bleah.
EOR
Tene lots of work on pcc 18:00
not much else
EOR
Util # Done 18:03
* Fixed RT#69684 (Parallel build is broken in Rakudo)
* Investigated missing `use lib` pragma in Perl6 docs and implementations.
* Fixed 100+ Perl6 documentation errors (mostly typos) in 40+ files: specs, docs, examples, t/spec, and u4x.
= Insomnia--
* For TT#509 (install_files.pl did not care about symlinks), started investigating how symlinks work on msdos FS mounted on Darwin.
= Short answer, Darwin fakes the symlinks in ways that will break cross-platform builds.
# Plan for next week:
* Finish symlink research, update TT#509, and test its branch on Win32 as requested by kid51++.
* Un-stall my stalled work on TT#994, TT#389, and TT#600. 18:04
18:04 whiteknight joined
Util # Blockers: 18:04
* 7+-2.
.end
japhb Util, your blocker is your short term memory? 18:05
whiteknight WHAT I DID 18:06
* Still working on pcc_reapply, though had less time this week
* Running some of the remaing tests through GDB. No solid results yet.
* Reading papers, preparing for JIT still
WHAT I WILL DO
* redouble effort on pcc_reapply. Fix tests first, fix performance second, add features third
WHAT I AM BLOCKING ON:
* Tuit shortage
EOR
18:07 mikehh joined
Util japhb: Exactly! Too many work items that encourage frequent task changes. I'll cope, though :) 18:08
18:09 PacoLinux joined
pmichaud What I did: 18:18
* More work on regex refactors in perl6/nqp-rx repository
* Current status maintained at github.com/perl6/nqp-rx/blob/master/STATUS
* Fixed up nqp-rx build system so it acts more like a standalone project
* Some key features:
** Regex parser and compiler will be self-hosting in NQP
** Match objects are now created lazily, should be much more efficient
18:18 chromatic joined
pmichaud ** Many fewer GCable created during a match 18:18
** Backtracking is now much quicker -- we simply "throw state away" as opposed to attempting to undo each level of backtracking individually
** The engine has been much easier to build, modify, and maintain
** Very simplistic (and slow) protoregexes now, code for much smarter ones prototyped but not active yet
What I'm doing this week:
* More regex engine work
* Finish self-hosting the regex parser
* Other bootstrapping tasks
What I'm blocking on:
* Time and energy
EOR 18:19
chromatic Worked on:
* refactoring CallSignature to create fewer GCables
* minor fixes to pcc_reapply branch
* listing struct pruning targets on the wiki (right now)
Will work on:
* finishing CallSignature refactor
* will poke at frame builder in pcc_reapply
Blocking on: 18:20
* time
18:24 allison joined
mikehh What I did in the last week: 18:24
* building and testing parrot in trunk and pcc_reapply branch - fixing codetest errors etc.
* pcc_reapply - as make/make world now builds and make smoke now works submitted a lot of smolder tests
* on my last run down to 17 failing tests (3 of which are not run - fails and exits 3rd test of 6)
* and ran fulltest a few times - reported summaries
* Installed Ubuntu 9.10 beta (updated) - g++ 4.4 fails to build parrot (early failure - stricter than 4.3)
* gcc 4.4 is fine though
What I intend to do in the next week:
* testing and fixing
.eor
allison Last week: 18:25
- Worked with Tene on a refractor of return handling (for PIR and C calls) in the pcc branch. Restructured it to be more parallel with argument handling (looking forward to when they can be unified).
- Fixes to named parameter count checking to more closely match the behavior of trunk.
- Updated the 'result_info' op for new pcc argument passing.
Next week:
- Plan to continue work on the last few test failures.
EOR
whiteknight hello 18:31
Util hi
mikehh hi there
schmalbe hi
18:31 schmalbe left
chromatic Hello. Let's review last week's goals. 18:32
pcc_reapply?
18:32 schmalbe joined
mikehh smoke reports 17 failures for me 18:32
allison substantial progress
whiteknight very substantial 18:33
allison not finished yet
chromatic Any estimates on completion and merge dates?
whiteknight allison++ and Tene++ have been kicking ass, taking names
cotto_work lurks
allison Currently plan to merge right after 1.7
This may include todoing a couple of edge-case tests
whiteknight lots of eyes looking at test failures between now and then would be awesome 18:34
allison Would be nice to have CallSignature optimizations in at the same time
But soon after is okay too
chromatic I think CallSig can be ready by then.
Were there other development priorities last week?
allison increasing test coverage on CallSignature 18:35
chromatic dukeleto?
whiteknight ENODUKELETO 18:36
allison he did good work on it
chromatic I'm improving it as part of the refactor anyway.
allison still more extensive tests needed
good
chromatic Let's review milestones. 18:37
HLL interoperability. pmichaud?
pmichaud nothing to report -- been doing nqp-rx work.
chromatic Shall we bump that to 1.8?
pmichaud yes, please.
chromatic Magic Trac elves, transform! 18:38
No dukeleto, but I did see some discussion of debugger docs.
seed libraries, japhb?
japhb push
or bump, or whatever the correct term is 18:39
chromatic 1.8?
japhb 1.9 feels more likely to me.
chromatic Can do.
Bytecode testing, Util?
No Util. 18:40
I started a page on the wiki for struct pruning. It'll be an ongoing process. We can slim the interpreter struct by a bit so far; I think we should do that. 18:41
More eyes on that are welcome.
Let's talk about priorities for this week, including the hackathon and the 1.7 release. Suggestions?
whiteknight pcc, obviously 18:42
and lots of testing
I think trunk has been a bit neglected this month, need lots of tests in penance
chromatic It'd be nice to get rid of some TODOs and SKIPs. 18:43
I know some of the cores have some weird issues with line numbering reporting.
whiteknight can we get a complete list of tose?
cotto_work Should we make sure that the get/set_insp_keyed_x vtable functions of CallSignature get tests written?
mikehh In trunk we have some failing tests in 3 runcores f, g and S
dukeleto 'ello # sorry I am late 18:44
allison cotto: yes, those are important ones
cotto_work great. That's something nice and incremental.
chromatic I'm working on those tests now.
cotto_work just commit early and often 18:45
mikehh your patch fixed f but not g and S
cotto_work afk (but will backscroll)
chromatic dukeleto, what's the status of the debugger documentation? 18:46
whiteknight ENODUKELETOAGAIN 18:48
chromatic Okay.
Other suggestions for priorities this week?
Tene q1q 18:49
whiteknight array types are becoming a hot topic. Testing those would be good
or increasing tests of those
chromatic Okay, let's go to questions then. 18:51
Tene?
Tene someone mentioned recently that they'd like threading to have a higher priority than it currently does in the work for 2.0
Would anyone like to address that here?
EOQ
whiteknight I think threading is going to be a key feature for "business ready" 18:52
our implementation of it should be solid
dukeleto chromatic: it has improved a lot. i think the parrot debugger docs ticket is closeable and/or more specific tickets should be created
allison Tene: we do have one or several heavy-duty threads refactors that need to happen 18:53
Tene: but I'd hesitate to put that in before 2.0 18:54
Tene OK
dukeleto is slightly sick and not-all-there today. sorry for the delayed responses
whiteknight it's a stretch, but it's a feature business are going to want
kurahaupo Arrays would need a work-over before they're thread-safe
whiteknight without robust threading, it's not business-ready
japhb dukeleto, best of luck feeling better soon!
allison Tene: it's on the list for 3.0, but I expect we can get fixes in to 2.6
dukeleto chromatic: this file docs.parrot.org/parrot/latest/html/...r.pod.html has been updated in trunk with how to assign to registers in the debugger. I don't really know what else needs to go there 18:55
japhb: thanks!
chromatic Other questions? I have one, if no one else does. 18:57
Util is back. ENOCHARTERCABLE resolved.
chromatic Okay. My question: can we consider deprecating mutable strings in 2.0? 18:58
allison chromatic: a performance-related question?
dukeleto says: here is my late report
What I did:
* added tests for CallSignatures on pcc_reapply
* converted some tests to PIR
* hacked on Plumage, which now has a test harness in NQP
What I will do:
* help with pcc_reapply
* continute to convert tests to PIR 18:59
* add more tests to Plumage
Blocking on:
* Being sick. But fighting it :)
EOR
chromatic Performance and correctness.
whiteknight chromatic: I like the idea but it's going to be a huge refactor
chromatic My initial thought is that we remove the behavior of all C functions which modify strings in place. Instead they return a new string.
allison isn't that more pressure on the GC if every string operation has to create a new string? 19:00
chromatic Less, actually -- and where we want it.
19:00 jonathan joined
whiteknight might be less pressure because we don't have to compact 19:00
Tene allison: we currently clone strings all over the place "just in case"
whiteknight and don't need to move memory around
chromatic Right now, any operation that needs to return a string -- even in a read-only sense -- ought to create a new COW header to prevent anything from modifying it in place. 19:01
kurahaupo And it makes strings thread-safe into the bargain
allison it certainly has potential
what are the downsides?
whiteknight needs research
I'm sure we can come up with some comparative literature 19:02
chromatic Every time we pass a string as a parameter, we have to check it for constant-stringness and COW it, just in case arbitrary PIR code tries to modify it in place.
Even that doesn't catch all of the cases.
allison How about support for languages with mutable strings?
whiteknight making copies would be transparent to them, I suspect
chromatic They have to manage their storage appropriately.
allison so, we'd have a bunch of languages each making their own implementation of mutable strings? 19:03
chromatic No.
whiteknight mutability is a low-level storage question
kurahaupo A PMC holding a string is a mutable string to all intents and purposes
whiteknight so long as they access strings through registers and use API functions appropriately, there would be no difference
chromatic If they want action-at-a-distance mutability, they need to go through a single place that holds a string pointer. 19:04
allison And, access to STRINGs in C?
chromatic Same deal.
whiteknight s = Parrot_string_foo(s)
you just need to keep track of the return value 19:05
allison Any risk of an operation swapping out the string pointer beneath you?
chromatic Same risk there is now if you write buggy code. 19:06
jonathan One thing that mutable strings does seem to enable to happen fast is lots of concatenations onto the end of a string.
whiteknight let's set up a notes page on the wiki for info and references
kurahaupo (Basically only risk is GC in another thread)
allison whiteknight: sounds good
Util For those of us catching up: prior discussion from 2002 - markmail.org/message/3heavmqy3pmxm2jo , markmail.org/message/nv6ory3weou2xqlq
jonathan (I know because I was pretty impressed when doing the .Net => Parrot translator, and it could build the generated PIR string up really quite fast.)
chromatic jonathan, I think a StringBuffer approach can help that.
dukeleto q1q
chromatic Who's going to create the wiki page? 19:07
Coke q1q
jonathan chromatic: Yes, for sure.
kurahaupo jonathan: or using { join "", @array }
jonathan chromatic: In C#, I know to not just concatenate onto a string but create a StringBuilder class instead, because a string is immutable and one of those is mutable. But it requires a decision.
whiteknight chromatic: I'll throw some notes on there tonight
chromatic Thanks, wk.
whiteknight then, free-for-all
jonathan chromatic: Which isn't a problem, just worth noting. 19:08
chromatic Other comments before we move this discussion to the wiki?
jonathan kurahaupo: Yes, or that.
chromatic dukeleto, question?
dukeleto since pcc_reapply is waiting until after 1.7, what are our priorities for trunk in the next week? 19:09
chromatic Testing, fixing the line number failures, unTODOing and unSKIPping tests, pcc_reapply, and CallSignature testing. 19:10
whiteknight stability, testing, etc
dukeleto CallSig has almost 100% coverage, we should add another PMC to our "increase test coverage" goal 19:11
allison CPointer?
chromatic CallSig won't have coverage for long, and you can't rely on gcov -- it inherits a lot of behavior from Capture. 19:12
dukeleto chromatic: all the callsig tests are in pcc_reapply. what do you mean that it won't have coverage for long? Are you rewriting CallSig ? 19:13
chromatic Yes.
allison for one thing, to remove the inheritance from Capture 19:14
dukeleto chromatic: on the pcc_optimize_sig branch ?
chromatic Yes. 19:15
dukeleto chromatic: should tests be added to that branch as well? They will cause some minor conflicts when merging happens, but shouldn't be a big deal
chromatic I'm adding tests right now. I'll push some soon. 19:16
allison dukeleto: any tests should pass on both, so it's okay to keep the updated test file in sync between the two branches
chromatic Let's move that discussion to #parrot though.
allison yes
chromatic Coke, a question? 19:17
Coke Just ran a spec test on partcl after the move to github and am getting 19:18
about 700 more failures. While I track that down (hopefully something
lost in translation and not a parrot bug), it would be nice if
trac.parrot.org/parrot/ticket/965
could be looked at, even if to say "this will be broken differently after
1.7"
(this is one of the few remaining segfaults that partcl generates. (not all of them were resolved) 19:19
allison it certainly won't be broken the same way
is there any way to test it against the pcc_reapply branch?
Coke allison: does PGe work in teh branch? 19:20
if not, no.
allison Coke: yes
PGE passes all tests now
Coke really, we don't need corevm anymore?
ok. I can try it.
allison nope, can run a full make test
Coke will update the ticket.
ok. (this is why I wanted a ticket tracking our progress. =-) 19:21
EOQ.
chromatic Other questions?
allison probably a good idea for future branches (or just a top section of the wiki page)
Tene I am now able to run my scheme compiler against the pcc branch.
rakudo doesn't compile successfully yet, though. 19:22
but, exciting progress.
chromatic Any blockers to discuss? 19:23
Tene None for me.
chromatic Let's call it a week then. Thanks, everyone.
allison thanks c 19:24
19:24 Util left, PacoLinux left 19:25 moritz left, Coke left, chromatic left 19:28 jonathan left 20:58 Whiteknight joined 21:53 Whiteknight joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!