Feature freeze
The next release 0.4.4 will be prepared this weekend. The usual terms apply: - no more feature changes to Parrot core - docu updates, trivial bug fixes, ..., welcome - as well as updates to PLATFORMS, smoke reports, test results Thanks, leo
Feature freeze
The next release will be rolled out this weekend. The usual terms apply: * no feature changes to Parrot core incl. build * bug and docu fixes welcome leo
Feature freeze
You knew it already, but just to make sure ... - No new feature checkins - Object patches are fine - Tests, bug fixes, docu updates, and such are more then welcome Release date is still considered to be Feb, 29th. *If* objects need some more days to settle, release will be on Feb, 30th (that is the date, when objects are usable ;) WRT release name: Piers has proposed The Leaping Kakapo (whatever that is:) We could also name it The Leaping Aoudad. leo
RE: Feature freeze
Leopold Toetsch wrote: WRT release name: Piers has proposed The Leaping Kakapo (whatever that is:) We could also name it The Leaping Aoudad. A Kakapo is a flightless night parrot: http://www.kakapo.net/en/. So leaping Kakapo does make a kind of sense. kaka is the Maori word for parrot. Po must be Maori for night. The mountain kaka is carnivorous. It has been known to attack and kill lambs and pigs. Kakapo is also a combination of kaka and pooh. -Which are words loaded with other meanings... In American English (at least), kaka is childish slang for shit as is poo. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: Feature freeze
Garrett Goebel [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: WRT release name: Piers has proposed The Leaping Kakapo (whatever that is:) We could also name it The Leaping Aoudad. A Kakapo is a flightless night parrot: http://www.kakapo.net/en/. So leaping Kakapo does make a kind of sense. Thanks for the explanation. So 0.1.0 got a name ... leo
CVS troubles (was: IMCC v1 call for bug list and feature freeze)
Melvin Smith [EMAIL PROTECTED] wrote: cvs checkout -r imcc1final parrot I don't know, if this is related, but I get now errors on commit: cvs server: sticky tag `HEAD' for file `classes/timer.pmc' is not a branch I did commit some patches an hour before which worked fine. Now I suddenly get a bunch of these messages. What does it mean? $ cvs status -v classes/timer.pmc === File: timer.pmc Status: Locally Modified Working revision:1.10 Repository revision: 1.10/cvs/public/parrot/classes/timer.pmc,v Sticky Tag: HEAD (revision: 1.10) Sticky Date: (none) Sticky Options: (none) Existing Tags: imcc1final (branch: 1.10.2) RELEASE_0_0_13 (revision: 1.7) file_move_031023(revision: 1.7) RELEASE_0_0_11 (revision: 1.7) help(revision: 1.6) leo
RE: CVS troubles (was: IMCC v1 call for bug list and feature freeze)
cvs server: sticky tag `HEAD' for file `classes/timer.pmc' is not a branch do $ cvs update -A classes/timer.pmc to remove the sticky tag and try committing again. The sticky tag gets set when cvs checkout/update is done with the -r option. leo HTH, arvindh. This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com
IMCC v1 call for bug list and feature freeze
I'm freezing imcc as version 1 except for bug fixes. I'm working on fixing the PCC code emitter before freezing it. Besides the bugs concerning non-scalability of the register allocator, I'm interested in any bug reports (for IMCC only) that may have been Warnocked until now. I'd like to get imcc1 working as correct as possible and frozen within a couple of weeks, then I'll start on the really major rework for imcc2 (including all the deprecation that is going to make everyone mad at me.) ;) Feel free to checkout branch imcc1final to test with. The command should be: cvs checkout -r imcc1final parrot -Melvin
Re: IMCC v1 call for bug list and feature freeze
Melvin Smith wrote: Feel free to checkout branch imcc1final to test with. The command should be: cvs checkout -r imcc1final parrot Could you be a bit more verbose about that. I've now checked out the branch imcc1final, which switched the whole tree to use that sticky tag. Into which branch should changes to non-imcc files go? And of course I don't understand, why you splitted the tree now, while bug-fixes for imcc1 aren't in. -Melvin leo
Re: IMCC v1 call for bug list and feature freeze
At 11:05 AM 1/15/2004 +0100, Leopold Toetsch wrote: Melvin Smith wrote: Feel free to checkout branch imcc1final to test with. The command should be: cvs checkout -r imcc1final parrot Could you be a bit more verbose about that. I've now checked out the branch I would not checkout the branch into the current working directory, although it shouldn't hurt. All you have to do is switch your working branch back to the main parrot trunk. So far, my changes are only local to imcc/. Also you don't have to check it out; you could do a diff between the main and the branch and review the patch. imcc1final, which switched the whole tree to use that sticky tag. Into which branch should changes to non-imcc files go? And of course I don't understand, Changes to non-imcc files should go into the main tree as usual. I'm just using the branch to move forward on imcc at my own pace and make the changes public while doing it. As I understand branches, this is exactly what they are for. It would probably help to get a document with cvs hints, specifically about branches. why you splitted the tree now, while bug-fixes for imcc1 aren't in. You must have missed my commit. I committed a revision with the branch that fixes a couple of issues with prototyped subs, specifically a couple of local test cases that I was using that were failing. -Melvin
Re: IMCC v1 call for bug list and feature freeze
At 10:28 AM 1/15/2004 +, you wrote: On Thu, Jan 15, 2004 at 02:21:56AM -0500, Melvin Smith wrote: I'd like to get imcc1 working as correct as possible and frozen within a couple of weeks, then I'll start on the really major rework for imcc2 (including all the deprecation that is going to make everyone If the next parrot release is (going to be) planned for mid Feb then it might be good to freeze v1 sooner to give more time for the impact of the rework to be absorbed. Or perhaps make v2 available sooner as imcc2 and then rename them both (imcc-imcc1, imcc2-imcc) once imcc2 is stable. Tim [who may be talking nonsense]. Hope you don't mind me cc-ing this back to the list. This is exactly what I was planning to do. I expect for a while people won't want to target v2 so there will be a stable standby until such time that it matures and we deem to migrate Parrot tests to it (there will be a few minor breakages of syntax). -Melvin
Re: IMCC v1 call for bug list and feature freeze
From: Melvin Smith [EMAIL PROTECTED] I'd like to get imcc1 working as correct as possible and frozen within a couple of weeks, then I'll start on the really major rework for imcc2 (including all the deprecation that is going to make everyone mad at me.) ;) Any chance of a list of what is being deprecated and what the major changes/new additions will be? Thanks, Jonathan
Re: IMCC v1 call for bug list and feature freeze
At 04:17 PM 1/15/2004 +, Jonathan Worthington wrote: From: Melvin Smith [EMAIL PROTECTED] I'd like to get imcc1 working as correct as possible and frozen within a couple of weeks, then I'll start on the really major rework for imcc2 (including all the deprecation that is going to make everyone mad at me.) ;) Any chance of a list of what is being deprecated and what the major changes/new additions will be? Give me time to dig back through my p6i email and collect some of it. Some I remember, but some I don't. -Melvin
Re: IMCC v1 call for bug list and feature freeze
At 11:05 AM +0100 1/15/04, Leopold Toetsch wrote: Melvin Smith wrote: Feel free to checkout branch imcc1final to test with. The command should be: cvs checkout -r imcc1final parrot Could you be a bit more verbose about that. I've now checked out the branch imcc1final, which switched the whole tree to use that sticky tag. Into which branch should changes to non-imcc files go? And of course I don't understand, why you splitted the tree now, while bug-fixes for imcc1 aren't in. I'm glad he has split things off--IMCC desperately needs gutting and replacing (the code was never meant to be production code (which I knew when I said bring it in :) and there's *far* too many big uncommented sections filled with single-character variable names), but I'd rather not break things as they currently stand. A branch is exactly what's called for in this circumstance, so there's remote version control and backup, and folks who're interested can see what's going on. I think one of the things I'd like to do for the next release, in addition to user docs, is to get the code cleaned and commented. There are huge swaths of gibberish in there, and I'd rather that get fixed sooner than later. (While I don't like macros, #define'd constants are OK...) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: IMCC v1 call for bug list and feature freeze
At 10:27 AM 1/15/2004 -0500, Melvin Smith wrote: At 11:05 AM 1/15/2004 +0100, Leopold Toetsch wrote: Melvin Smith wrote: Feel free to checkout branch imcc1final to test with. The command should be: cvs checkout -r imcc1final parrot Could you be a bit more verbose about that. I've now checked out the branch I would not checkout the branch into the current working directory, although it shouldn't hurt. All you have to do is switch your working Actually, eep no. What I said was wrong, sorry. It is _not_ a good idea to check out a branch into a working directory unless you already know the changes are compatible, because the changes aren't ready to actually be merged, and might just cause tons of conflicts (not the case here, though as they are minor). Unless I merge really quickly back to the trunk, I'll have a bit of work to do when I get ready to merge. Hopefully the changes will all be in imcc/* and there won't be any conflicts. -Melvin
Re: IMCC v1 call for bug list and feature freeze
At 1:17 PM -0500 1/15/04, Melvin Smith wrote: At 10:27 AM 1/15/2004 -0500, Melvin Smith wrote: At 11:05 AM 1/15/2004 +0100, Leopold Toetsch wrote: Melvin Smith wrote: Feel free to checkout branch imcc1final to test with. The command should be: cvs checkout -r imcc1final parrot Could you be a bit more verbose about that. I've now checked out the branch I would not checkout the branch into the current working directory, although it shouldn't hurt. All you have to do is switch your working Actually, eep no. What I said was wrong, sorry. It is _not_ a good idea to check out a branch into a working directory unless you already know the changes are compatible, because the changes aren't ready to actually be merged, and might just cause tons of conflicts (not the case here, though as they are minor). Unless I merge really quickly back to the trunk, I'll have a bit of work to do when I get ready to merge. Hopefully the changes will all be in imcc/* and there won't be any conflicts. This would be a good time to nail down the IMCC calling interface, then, so back merges can just toss the entirety of the imcc/ directory and have everything still just work. Those changes should go in both the v1 and v2 branches, assuming that there need to be any. (Might not need any, which is fine) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: IMCC v1 call for bug list and feature freeze
At 01:08 PM 1/15/2004 -0500, Dan Sugalski wrote: At 11:05 AM +0100 1/15/04, Leopold Toetsch wrote: Melvin Smith wrote: Feel free to checkout branch imcc1final to test with. Could you be a bit more verbose about that. I've now checked out the branch imcc1final, which switched the whole tree to use that sticky tag. Into which branch should changes to non-imcc files go? And of course I don't understand, why you splitted the tree now, while bug-fixes for imcc1 aren't in. I'm glad he has split things off--IMCC desperately needs gutting and replacing (the code was never meant to be production code (which I knew when I said bring it in :) and there's *far* too many big uncommented sections filled with single-character variable names), but I'd rather not break things as they currently stand. A branch is exactly what's called for in this circumstance, so there's remote version control and backup, and folks who're interested can see what's going on. And as I said, this branch is not the major rework branch. Maybe I wasn't clear. imcc1final is for collection of all the final bug fixes _for_ imcc1 (that we know of) before we move on to major rework (imcc2). The major rework will be _after_ I merge imcc1final back to the tree. Then you can freeze it at will when you do the parrot 0.1 freeze. So, no cause for alarm. :) -Melvin
[ANNOUNCE] feature freeze
As originally proposed by Melvin Smith, we gonna have a Halloween release. Its not so much Nothing fancy, just something fun. :) - A lot of things did happen since the last release. Not really milestones, though - nevertheless the rather big list of improvements[1] justifies a release. * Feature freeze is from now Oct, 29th 8.00 GMT until * Code freeze starts at Oct, 31th 8.00 GMT During feature freeze, only core patches WRT building, testing, warnings, bug fixes and the like should go in (languages/* aren't affected). leo [1] - The Big Move: Parrot source and build files rearranged into sub dirs - Build imcc as parrot - Objects more finished - Delegate vtable methods to byte code - Binary multi-method dispatching - Isa and does methods for PMCs - Call byte code from C - Start of extension interface - Experimental struct handling - Catch access to NULL PMCs - Experimental network socket interface code and opcodes - IO fixes and improvements - Dynamic opcode libraries - Fix-assigned opcode numbers - Argument flattening for function calls - More native call interface (NCI) signatures - Ncurses, postgres, and pcre interface libraries - Forth language is vastly improved - BSD and Win32 build improvements - Many new tests and fixes Additions and comments welcome,
FEATURE FREEZE Sunday 14-Sep-2003
Had to stick that year on in case this message gets unearthed. Ok, the little voices in my head have told me that it's time for that release we were talking about. So, you have until Sunday to cram in any functionality you want in the next release. After Sunday, it will be cleanups, bugfixes, and completing existing functionality only for a little while. The version number has not yet been decided -- 0.0.11, 0.1.0, or maybe 4.3 for the hell of it. The code name is, of course, open for discussion. Although I reserve the right to call it the hairy tulip release if I want. (in private) (with the shades drawn)
THERE IS NO FEATURE FREEZE
I think I've finally straightened my mail configuration out enough for this to go somewhere. There is no feature freeze. That was just an old message that was dug up accidentally from the past. I denied it several times as soon as I saw it, which wasn't very soon because I recently had a death in my family and have been completely out of touch for a month or so. Also as a result of that, I am far away from my usual setup and my home machine crashed. So I have been operating under a nonfunctional mail setup for a while without realizing it. Sorry for the confusion.
Re: Parrot 0.0.10 feature freeze
Steve Fink wrote: As for the code name -- I'm personally leaning towards the Juice suggestion. Given that Juice is already the name of an existing (but apparently defunct) virtual machine, you might want to consider another choice. The home page appears dead: http://www.ics.uci.edu/~juice/ but you can find it in the wayback machine: http://web.archive.org/web/*/http://www.ics.uci.edu/~juice/ A brief citation can also be found at: http://cliki.tunes.org/Juice I wasn't paying attention when the original list got submitted, so sorry if these are redundant: Bereft (more Monty Python) Choir Invisible (ditto) Nailed to the Perch (is there an echo in here?) Boutique (ok, it stopped being funny already) Norwegian Blue (all right, I'll stop...) Mister Polly (oops, I did it again.) Lovely Plumage Voom! Just Resting Notlob (ok, that's pretty much the end of the sketch...) Chimera (rejected name of Parrot) Pylon (see above) Perth (urm... see above the above) The Real Macaw (also the name of a bar) The Vaults of Madagascar (more from the O'Reilly book) Fractious Culture (O'Reilly - and would make a good band name, too) Gnope (again, O'Reilly) The Snake That Broke the Camel's Back (slashdot) Jarrot (yes, same book) Your Ad Here! (my favorite!) Pretty Bird (d'oh) -- David Cuny
Re: Parrot 0.0.10 feature freeze
Steve Fink wrote: As for the code name -- I'm personally leaning towards the Juice suggestion. I'm not sure why, but it just sounds kinda cool. And it does fit well with the -Oj flag. Parrot -- now with extra juice! Or something. Opinions? Too much honor ;) What about one of these: http://www.wordsmith.org/anagram/anagram.cgi?anagram=parrot+teninclude=exclude=d=n=m=source=adva=nl=nlanguage=englishwhere= Starting with Anagram for parrot ten A PENT TORR A TERN PORT A TERN TROP A RENT PORT A RENT TROP A PERT TORN A TERR PONT PARTNER TO ... PAR ROTTEN ... TAT RE PORN TAT ERR PON oops, leo
Parrot 0.0.10 feature freeze
This is a day late, but as previously announced, Parrot is now feature-frozen. I'll cut a release next Saturday, March 15, unless things look good enough to go before then. Feature freeze means bugfixes and new tests are still ok. The only currently in-progress feature that I'm aware of is the conversion of open to PIO, and unless it's more disruptive than it sounds, I'd say it lands into the bugfix category. :-) As for the code name -- I'm personally leaning towards the Juice suggestion. I'm not sure why, but it just sounds kinda cool. And it does fit well with the -Oj flag. Parrot -- now with extra juice! Or something. Opinions?
Re: Feature Freeze
On Thu, Sep 20, 2001 at 09:00:20AM +0100, Simon Cozens wrote: So, if you're running on one of the core platforms, please check out a *clean* CVS copy, try and build and post the output of make test. FWIW, here's the current state of Tru64: Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/integer.t4 1024264 15.38% 1 3 21 23 t/op/number.t21 537623 21 91.30% 1-19 21 23 t/op/trans.t 18 460818 18 100.00% 1-18 4 subtests skipped. Failed 3/5 test scripts, 40.00% okay. 43/74 subtests failed, 41.89% okay. -- Actually Perl *can* be a Bondage Discipline language but it's unique among such languages in that it lets you use safe words. -- Piers Cawley
Re: Feature Freeze
[EMAIL PROTECTED] (Simon Cozens) writes: [...] So, if you're running on one of the core platforms, please check out a *clean* CVS copy, try and build and post the output of make test. On FreeBSD 4.x all passes (or skips) except the first t/op/integer test. (as other people have mentioned). -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: Feature Freeze
On Thu, Sep 20, 2001 at 09:00:20AM +0100, Simon Cozens wrote: So, if you're running on one of the core platforms, please check out a *clean* CVS copy, try and build and post the output of make test. FWIW, here's the current state of Linux/Sparc (ivsize=8, nvsize=8, ptrsize=4) Failed 4/5 test scripts, 20.00% okay. 20/74 subtests failed, 72.97% okay. Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/basic.t 1 256 21 50.00% 1 t/op/integer.t 11 281626 11 42.31% 1-7 21-24 t/op/number.t 7 1792237 30.43% 7 9 11 13 15 17 23 t/op/string.t 1 256 51 20.00% 2 4 subtests skipped. make: *** [test] Error 29 -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Feature Freeze
On Thu 20 Sep 2001 15:49, Simon Cozens [EMAIL PROTECTED] wrote: On Thu, Sep 20, 2001 at 09:00:20AM +0100, Simon Cozens wrote: So, if you're running on one of the core platforms, please check out a *clean* CVS copy, try and build and post the output of make test. FWIW, here's the current state of Tru64: Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/integer.t4 1024264 15.38% 1 3 21 23 t/op/number.t21 537623 21 91.30% 1-19 21 23 t/op/trans.t 18 460818 18 100.00% 1-18 4 subtests skipped. Failed 3/5 test scripts, 40.00% okay. 43/74 subtests failed, 41.89% okay. I did let it run for some time to get a more complete picture :) Here's the results from the Dutch HP-UX 11.00 jury running bleadperl for Parrot snap 20 Sep 2001 09:00 Configuration: -Dusedevel -Uuseperlio === ../perl t/harness t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler t/op/integerok t/op/number.Confused test output: test 2 answered after test 6 Test output counter mismatch [test 7] Confused test output: test 2 answered after test 7 Test output counter mismatch [test 8] Confused test output: test 2 answered after test 8 Test output counter mismatch [test 9] Confused test output: test 2 answered after test 9 Test output counter mismatch [test 10] Confused test output: test 2 answered after test 10 Test output counter mismatch [test 11] Confused test output: test 2 answered after test 11 Test output counter mismatch [test 12] Confused test output: test 2 answered after test 12 Test output counter mismatch [test 13] Confused test output: test 2 answered after test 13 Test output counter mismatch [test 14] Confused test output: test 2 answered after test 14 Test output counter mismatch [test 15] Confused test output: test 2 answered after test 15 Test output counter mismatch [test 16] Confused test output: test 2 answered after test 16 Test output counter mismatch [test 17] Confused test output: test 2 answered after test 17 Test output counter mismatch [test 18] Confused test output: test 2 answered after test 18 Test output counter mismatch [test 19] dubious Test returned status 21 (wstat 5376, 0x1500) DIED. FAILED tests 1-19, 21, 23 Failed 21/23 tests, 8.70% okay (-2 skipped tests: 0 okay, 0.00%) t/op/string.ok, 1/5 skipped: I'm unable to write it! t/op/trans..dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 13, 18 Failed 2/18 tests, 88.89% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/number.t 21 537623 142 617.39% 1-19 21 23 t/op/trans.t 2 512182 11.11% 13 18 4 subtests skipped. For all next configurations I manually removed the line noise ... Configuration: -Dusedevel -Uuseperlio === t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler t/op/integerok t/op/number. DIED. FAILED tests 1-19, 21, 23 t/op/string.ok, 1/5 skipped: I'm unable to write it! t/op/trans.. DIED. FAILED tests 13, 18 Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/number.t 21 537623 142 617.39% 1-19 21 23 t/op/trans.t 2 512182 11.11% 13 18 4 subtests skipped. Configuration: -DDEBUGGING -Dusedevel -Uuseperlio === t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler t/op/integerok t/op/number. DIED. FAILED tests 1-19, 21, 23 t/op/string.ok, 1/5 skipped: I'm unable to write it! t/op/trans.. DIED. FAILED tests 13, 18 Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/number.t 21 537623 142 617.39% 1-19 21 23 t/op/trans.t 2 512182 11.11% 13 18 4 subtests skipped. Configuration: -DDEBUGGING -Dusedevel -Uuseperlio === t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler t/op/integerok t/op/number. DIED. FAILED tests 1-19, 21, 23 t/op/string.ok, 1/5 skipped: I'm unable to write it! t/op/trans.. DIED. FAILED tests 13, 18 Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/number.t 21 537623 142 617.39% 1-19 21 23 t/op/trans.t 2 512182 11.11% 13 18 4 subtests skipped. Configuration: -Dusedevel -Duseperlio
