On Fri, 8 Dec 2006 16:24:32 +0000
Stuart J Urquhart <[EMAIL PROTECTED]> wrote:
> I'd also like to mention a little side-effect i noticed when using my
> modified palcat. Palettes aren't appended in the order that one would
> expect from the command-line.
Right, i didn't noticed that bcs i didn't tried with more than 3 pictures.
I fixed it, we don't want couter intuitive behaviour when the fix is
so simple :)
> >
> >> The patch is attached to this message, which also corrects a typo in
> >> scc_param.c I have tested the modifications, and they seem to work
> >> fine.
> >
> > I applied it with some modifications. However you should avoid mixing
> > unreleated changes in a patch. For a small patch like this it doesn't
> > matter much, but it still mean some extra work as i need to take the
> > changes apart to commit the separetly. I try to avoid mixing changes
> > bcs it make reading/understanding the diff much harder, in particular
> > when you read them later on when looking for something in the svn log.
> > In case you wonder i see 4 changes in that patch: Adding Pre-append,
> > scc_param fix, error message fix and the extra scc_img_free.
>
> Interesting approach, though i always feel that a good diff frontend
> will more than likely point out the specific changes in each file
> related to the revision.
Sure at best you get a separate hunk, at worst it is intermixed in the
same hunk and that's where it become really annoying. imho a good diff
should be as simple as possible to understand, adding things not related
to the main purpose of the diff just distract the reader.
> But then again one could see it as a balancing act: too many small
> patches make it difficult to see the bigger picture. Too many large
> patches make it difficult to see the tiny details in the picture.
Sure, but the size of the diff is not really important. What matter is
what it is supposed to do.
> >
> > I removed the scc_img_free. Some ppl like to be very strict with that,
> > but as the OS will just kill the heap when the program exit, i find
> > it better to keep the code simpler.
>
> I always find it helpful to free stuff i am finished with, even if it
> will be freed when the application terminates. This is very useful
> later on down the line when using memory profilers and tools such as
> Valgrind to track down memory leak issues - i don't have to sift
> through tons of false matches to get to the real problem.
I do that too on program that are supposed to run for some time.
But for such one-shot programs i prefer the code simplicity.
> I'm a bit puzzled as to why you commited the error message fix
> separately, though then again stranger things have happened. :)
Adding a new feature and fixing error messages are 2 different things,
so 2 different commit. Believe me in the long run when you have to
dig through the history having properly separated commits make things
a lot easier.
Albeu
_______________________________________________
ScummC-general mailing list
[email protected]
https://mail.gna.org/listinfo/scummc-general
