I might be breaking things..

protomank · Post by **protomank** » Sat Nov 07, 2009 12:58 am

I was talking a much broader problem: when not only the name changes, but functions gain new arguments or loose some; and programas are really broken because of this, needing more than a string replacement :)

Post by **Herben** » Sat Nov 07, 2009 7:10 am

Ok, so here's what I've done.. I added "GetSyscall", which simply calls GetSyscallHandler and returns the result. In addition, I've added the attribute "deprecated" to the prototype for "GetSyscall" in kernel.h. This will result in a warning when compiling code that uses GetSyscall, but it will compile just fine.

I, personally, don't believe that legacy functions should be retained indefinitely. While it may make sense to do so in a library that is used commercially or has a large user-base, I feel that it needlessly complicates things for little gain, in this case.

Anyway, that's all I've got to say on this subject. At some point GetSyscall will be removed from the SDK so you should use GetSyscallHandler for now on. The same is true for "RFU60" and "RFU61", which have been deprecated for a couple years now.

dlanor · Post by **dlanor** » Sat Nov 07, 2009 10:17 pm

Herben wrote:I, personally, don't believe that legacy functions should be retained indefinitely. While it may make sense to do so in a library that is used commercially or has a large user-base, I feel that it needlessly complicates things for little gain, in this case.

Though it was I who raised this backwards compatibility issue a few posts back, I really do agree with you on this, and especially when it comes to replacement of old and badly written stuff with new and far better implementations. (This does not refer directly to the GetSyscall change, which was only a name change, though well motivated by consistency with names of newly implemented functions.)

To hang on to all the old stuff just for backwards compatibility, would clutter up the libs, and might even hold back needed progress (if one insists on unchanged invocation methods for all old stuff).

So we must instead 'pay the price of progress' in the form of some additional work when we want to revive or adapt old code for modern usage. This is a price I'm willing to pay myself, at any rate.

However, it may be a good idea to put together a cumulative changelog of only those changes (past and present) which impose a different reference usage (such as name changes, or extended function arguments), to aid those who work with adapting old code.

Searching for such changes in existing changelogs and notes might be impractical, since those may 'drown' the relevant information in info about other changes (of pure functionality not affecting reference methods).

Best regards: dlanor

ragnarok2040 · Post by **ragnarok2040** » Mon Nov 09, 2009 6:10 pm

Wouldn't the svn commit log be just enough? You can get a specific log for the file or directory you want by specifying it on the 'svn log' command line, and even use grep to keyword search it.

After finding the revision with the change you're interested in, you can use `svn diff --summarize -c REV` to get the list of modified files for that revision or 'svn diff -c REV' to get a diff of the changes made by that revision. That would give you the relevant information regarding the updated code. Removed files can easily be found through the parent directory's log and the diff for the revision would contain that entire file.

I think subversion does all that remotely through svn.ps2dev.org, though, so it's slow. Using misfire's mercurial clone of ps2sdk would probably be better. Not only that, you have every change ever made to ps2sdk sitting right there locally, heh.