Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2009-10-13

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

All times shown according to UTC.

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

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