Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2010-01-05

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

All times shown according to UTC.

Time Nick Message
02:32 japhb joined #parrotsketch
12:47 bluescreen joined #parrotsketch
12:50 bluescreen joined #parrotsketch
13:36 mikehh joined #parrotsketch
15:14 mikehh joined #parrotsketch
15:33 davidfetter joined #parrotsketch
16:53 Coke joined #parrotsketch
16:54 Coke parrot: branches/one_make -
16:54 Coke * Convert data_json, pirc, nqp, imcc, & json to be includes instead of recursive
16:54 Coke * Convert 2 scripts that were generated /at/ config time to just use
16:54 Coke Parrot::Config
16:54 Coke * Split up per directory Makefile.mak files into Rules.mak and Define.mak.
16:54 Coke * fix checkdepend.pl to optionally dump out the pre-processed makefile, and
16:54 Coke deal with include'd makefiles.
16:55 Coke * Cleanup up := usage in the static makefile fragments (AndyD++)
16:55 Coke parrot: tickets:
16:55 Coke Closed #1344 (applied patch)
16:56 plobsing joined #parrotsketch
16:56 darbelo joined #parrotsketch
16:59 mikehh What I did since my last report:
16:59 mikehh * building and testing parrot on amd64/i386, with gcc/g++, with and without --optimize
16:59 mikehh * some branch testing
16:59 mikehh * some fixes
16:59 mikehh * added some notes on CopyingGarbageCollection and CheneysCopyingCollector to the wiki
16:59 mikehh What I intend to do in the next week:
16:59 mikehh * testing and fixing
17:00 mikehh * investigate gc some more
17:00 mikehh .eor
17:01 PacoLinux joined #parrotsketch
17:19 plobsing What I Did:
17:19 plobsing - Figured out segfaults in t/pmc/eval (TT1142 again)
17:19 plobsing - Eliminated EXTRA_IS_PROP_HASH
17:19 plobsing What I Plan:
17:19 plobsing - Fix any failures in pmc_freeze_cleanup branch (are there any?)
17:19 plobsing - Merge branch (if not too close to 2.0)
17:19 plobsing EOR
17:21 darbelo Done:
17:21 darbelo Nothing useful.
17:21 darbelo Plan:
17:21 darbelo Help out in the pmc_freeze_cleanup branch.
17:21 darbelo Tackle bitwise dynops.
17:21 darbelo EOR
18:15 whiteknight joined #parrotsketch
18:17 allison joined #parrotsketch
18:20 chromatic joined #parrotsketch
18:21 Util Extra $WORK not yet completed. All Parrot work delayed a few more days. FAIL ticket closure.
18:21 Util q1q (I *am* attending the meeting today)
18:21 Util say 'Happy New Year!'
18:21 Util .end
18:21 allison - Still catching up from time away.
18:22 allison - Top priority is deprecations for 2.0.
18:22 allison EOR
18:22 whiteknight - Random testing and following along with email chains
18:22 whiteknight - checking out some branches
18:22 whiteknight - Far too busy for anything else
18:22 whiteknight EOR
18:30 masak joined #parrotsketch
18:33 chromatic Hello, everyone.
18:33 allison hi
18:33 Util Hello
18:33 darbelo Hola.
18:34 mikehh hi
18:34 chromatic We need to set a couple of priorities for this week, with the knowledge that 2.0 is a couple of weeks away.
18:35 chromatic Suggestions?
18:35 allison deprecation entries
18:36 Coke +1
18:36 allison testing on various platforms
18:36 Util +1 platforms
18:36 Coke there are 25 tickets currently opened for 2.0
18:37 allison also, check in with language devs for any 2.0 issues
18:39 chromatic Okay, I added those to the topic on #parrot.
18:40 allison q1q
18:40 Coke q1q
18:41 chromatic Any concerns about the last couple of weeks we need to discuss?
18:42 Coke it's been quiet, presumably due to holidays. no real concerns.
18:42 mikehh I take it that current branches are not going to be merged before 2.0
18:42 Coke one_make isn't.
18:42 allison aye, we usually do longer holds on branch merges before "supported" releases
18:43 whiteknight "usually" = "the last two times"
18:43 allison + "expected in the future"
18:43 chromatic The PMC freeze cleanup would be very nice to merge.
18:43 plobsing pmc_freeze_cleanup is in a mergeable state right now, AFACT.
18:44 Coke ... given that we've had only 2 supported releases, wk, I'm not sure what you're saying there. =-)
18:44 whiteknight Coke: I'm saying that we've only have two supported releases :)
18:44 mikehh a definate trend there
18:44 Coke if we can merge it /today/ and it's a low risk branch, I see no worries.
18:44 whiteknight +1 on merge today
18:44 Coke but anything past today is concerning. anything at all risky is concerning.
18:45 allison agreed with Coke
18:45 whiteknight we need to test the hell out of freeze/thaw if we're doing a merge today
18:45 plobsing +1 testing like madmen
18:45 Coke well, we can test in the branch, just as easily.
18:46 whiteknight I mean mostly adding a lot more tests. Test suite is slim on freeze/thaw tests
18:46 Coke chromatic: would you say it's a high-risk branch?
18:46 Coke low # of tests == high risk, for me.
18:47 chromatic make testr
18:47 mikehh I have run it through fulltest but we need more platforms tested
18:48 allison let's say two days of testing on the branch on multiple platforms
18:48 darbelo it also needs plenty of HLL testing.
18:48 allison if we hit all our supported platforms with no issues, then call it mergable
18:49 allison (platforms + languages)
18:49 allison if we find any issues, rather than scrambling to fix them, we just delay the merge until after 2.0
18:49 chromatic +1
18:50 mikehh +1
18:50 plobsing +1
18:51 Coke regenerated http://trac.parrot.org/parr​ot/wiki/BranchDescriptions - we have a lot of branches out there.
18:52 Coke (whoops. mis-gen'd.)
18:52 chromatic Any problems or speedbumps that came up in the last two weeks?
18:53 mikehh I make it 24 branches - of which only 3 or 4 are active
18:53 Coke (branches at http://feather.perl6.nl/~coke/output - I can't seem to update the wiki page.)
18:54 mikehh I should say showing recent activity
18:55 mikehh weirdo - see TT #1393
18:55 mikehh probably GC related
18:57 chromatic Let's move on to questions.
18:57 chromatic Util?
18:57 Util O'Reilly/Pragmatic has a new book by the ANTLR guy: "Language Implementation Patterns"
18:57 Util http://oreilly.com/catalog/9781934356456/
18:57 Util Is the book relevant to Parrot and/or Rakudo?
18:58 chromatic From the description, somewhat yes.
18:58 allison I suspect we add a few design patterns he's never thought of, but worth taking a look
18:59 Util Thanks. EOQ.
18:59 chromatic allison?
19:00 allison I received an email report of a compile failure of 1.9 on Ubuntu 8.04 (Hardy)
19:01 allison it's just inside our "OS released in the past 2 years" cutoff
19:02 allison my question was: does it make sense to support the Ubuntu Long-Term Support releases?
19:02 allison (as a general policy)
19:03 allison which would mean we would drop support for Hardy after Parrot 2.3
19:03 chromatic If we can find someone to support them.
19:03 allison I can manage tip and LTS
19:03 allison more than that would get too scattered
19:03 allison I guess it's tip, dev, and LTS, which is pushing it a bit
19:04 chromatic If the reporter is willing to try patches and work with someone, it's doable.
19:05 allison good enough feedback, EOQ
19:06 chromatic Coke?
19:06 Coke I need more feedback on TT#449; it's slated for 2.0, but it suggests moving 'say' to a dynop, among other things. I imagine that's big enough to require its own ticket.
19:07 Coke I also think it raises a question about ops vs. methods; if the recommended way to do something is through a method... can we just kill the opcode?
19:07 Coke (e.g.: open, fdopen, close, read, readline, getstd, setstd)
19:07 Tene I like that.
19:08 chromatic Moving say to a dynop means loading that dynops for a fair number of tests.
19:08 allison methods are slow, ops are fast, so there's still a strong motivation for keeping certain ops
19:08 Coke chromatic: or eliminating its usage, yes.
19:08 allison (especially common ops)
19:08 Coke allison: but the ops just call the method, no?
19:09 allison Coke: I don't remember, originally they called functions directly, but some were switched to methods to support variant filehandle types
19:09 Coke (and if not, why not? why have two methods of doing the same thing?) (and why not just concentrate on speeding up methods)
19:09 Coke s/methods/ways/:1st
19:09 allison if not, it's for speed
19:10 allison if so, it's for polymorphic substitutibility
19:10 Coke so we're recommending the slow way? =-)
19:10 allison I wouldn't say we're recommending methods
19:11 Coke you did in the ticket. =-)
19:11 allison just that methods are appropriate in some cases and ops in others
19:11 allison was that before we started pushing for speed?
19:12 allison (my apologies for the inconsistency/change over time)
19:13 Coke it says "primary", not "recommended", but yah.
19:13 Util An old but thorough posting on the subject: "WWIT: All those opcodes"
19:13 Util http://www.sidhe.org/~dan/​blog/archives/000404.html
19:13 allison thinking... this may be another Lorito question
19:13 Coke Util: That may, in fact, be too old. =-)
19:13 Coke ok. so for 2.0, the list there (except for say) is ok to move to dynops?
19:13 chromatic +1
19:13 Coke chromatic: to what?
19:14 allison yes, that post by Dan is the old philosophy
19:14 chromatic <Coke> ok. so for 2.0, the list there (except for say) is ok to move to dynops?
19:14 Coke chromatic: danke.
19:14 Coke if we want to move say, I'll let someone open another ticket. that's going to involve a lot of churn.
19:14 allison we've definitely moved away from the monolithic op set (an op for everything)
19:14 allison 'say' should certainly not move to dynop before 2.0
19:14 allison it's too soon
19:15 Util If the new philosophy is clearly articulated anywhere, could someone point me to it?
19:15 * darbelo q1q
19:16 Coke eoq.
19:16 chromatic darbelo?
19:17 darbelo We have a deprecation item stating that we'll remove the bitwise vtables and put in dynops to replace them.
19:17 darbelo Should we push to have the dynops in place by 2.0?
19:17 Coke (but keep the vtables for 2.0? that would be nice, yes.)
19:17 Coke then folks have something to switch to.
19:18 chromatic We also need migration documentation for that.
19:18 allison darbelo: if they make it in, good, but generally rapid development before a release is a bad idea
19:18 allison if someone is inspired, make sure you clearly mark them as "experimental"
19:18 allison then we're free to improve/change them right after 2.0 as needed
19:19 darbelo Ok. eoq.
19:19 chromatic Other questions?
19:19 Coke me.
19:20 Coke Any feedback on the one_make branch? I got some positive feedback ahead of time, just making sure there are no complaints so far.
19:21 Coke (with static .mak fragments, moving work from Configure to make...)
19:21 chromatic I'm all for it.
19:21 allison seems like generally a good direction, moving away from the Configure dependence
19:21 chromatic Unnecessary rebuilds annoy me.  It'll be nice to see them go.
19:22 darbelo Coke: I'll give it a test with BSD make later and let you know how it goes.
19:22 Coke darbelo: ah, spiffy.
19:22 Coke someone using 'nmake' would also be greatly appreciated.
19:23 darbelo you should ask someone to try sun's dmake too.
19:23 plobsing joined #parrotsketch
19:23 Coke pretty sure AndyD is doing that occasionally.
19:24 Coke chromatic: the compilers.dummy target is gone in branch, so that's a lot of it right there.
19:24 chromatic Fantastic!
19:25 Coke eoq.
19:25 chromatic Other questions?
19:28 chromatic Let's call it a week then.
19:28 chromatic Close tickets.
19:38 PacoLinux left #parrotsketch
19:56 chromatic left #parrotsketch
20:26 davidfetter left #parrotsketch
20:30 plobsing joined #parrotsketch
20:30 plobsing left #parrotsketch
21:06 bluescreen joined #parrotsketch
21:21 Coke left #parrotsketch
23:42 Whiteknight joined #parrotsketch

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