IMCC v1 call for bug list and feature freeze
Melvin Smith
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
Leopold Toetsch
> 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
Melvin Smith
>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
Melvin Smith
>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
>
>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
Jonathan Worthington
> 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
Melvin Smith
Give me time to dig back through my p6i email and collect some of it.
Some I remember, but some I don't.
-Melvin
Dan Sugalski
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
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Melvin Smith
>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
Dan Sugalski
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)
Melvin Smith
>At 11:05 AM +0100 1/15/04, Leopold Toetsch wrote:
>>Melvin Smith wrote:
>>
>>>Feel free to checkout branch imcc1final to test with.
>>
>>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
Leopold Toetsch
> 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
Arvindh Rajesh Tamilmani
>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.
Leopold Toetsch
> do
> $ cvs update -A classes/timer.pmc
> to remove the "sticky tag" and try committing again.
Ah, yes thanks, that worked.
> HTH,
> arvindh.
leo
Arvindh Rajesh Tamilmani
>> $ cvs update -A classes/timer.pmc
>> to remove the "sticky tag" and try committing again.
>
>Ah, yes thanks, that worked.
If you wish to get a particular revision/branch of a file,
but don't want the sticky tag to be set, you may use this command:
$ cvs update -r <tag> -p file >file
This way, "Working revision" and "Sticky Tag" will remain unchanged.
arvindh