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