[Scummvm-devel] Re: [Scummvm-cvs-logs] CVS: scummvm/scumm scummvm.cpp,1.99,1.100 scumm.h,1.84,1.85

[Max Horn]

At 1:26 Uhr -0600 18.12.2002, J.Brown (Ender) wrote:
>  > >Both issues are there to make things easier (until the new debugger at
>>  >least has the basic functionality of the old). Also I did not want
>>  >concurrency in this situation, for three reasons:
>>
>>  And I answer with three questions...
>>
>>  >   1) The debugger is far less critical than the GUI
>>  yeah, so why leave the old source code in CVS???
>
>Read above and the log.
>
>>  >   2) The current debugger is almost useless anyway, so concurrency is
>>  >pointless.
>>  yeah, so why leave the old source code in CVS???
>
>Read above and the log.
>
>>  >   3) It promotes active development of a far more useful replacement.
>>  >NewGUI is also a far more useful replacement, but OldGUI was at least
>>  >functionally useful. The old debugger isn't.
>>  Yeah so why leave the old source code in CVS?
>
>Read above and the log.
>
>To pseudo-quote:
>  "The old code is still in the CVS because that way people can easily
>copy/paste functionality from it into the new debugger, and switch the
>filenames in module.mk if they urgently actually NEED the old debuggers
>functionality".
>
>Then, to answer why I left it in CVS, not atticed, read above:
>  "Both issues are there to make things easier (until the new debugger at
>least has the basic functionality of the old"
>
>Then to answer why I do not run it concurrently, see the three reasons
>above:
>  "Also I did not want concurrency in this situation, for three reasons:"
>
>...
>
>It's not difficult to understand, is it? :P

Yes it is difficult to understand because you are contradicuting 
yourself. On the one hand you claim the old debugger is useless, so 
concurency is not needed. On the other hand you say people may 
urgently need the debugger. Hu?

On the one hand you say concurency is not necessary hence you thought 
it not necessary to give a different name to the new debugger. Yet 
you actually keep it concurrent by keeping all the old files around. 
(and note that even if you remove the file from CVS it is still 
around just hidden).

Sorry, but I don't agree with your "logic", in fact in my eyes it's 
seriously falwed.

>Maybe for YOU it makes sense to go digging through Attic'ed files to look
>for code to switch rooms from a debugger, or to find out how the variable
>watch system worked - however most people who might want to submit a patch
>for the debugger are not likely to do this. Think outside YOUR world and
>consider we should make things easier for new developers. :)

Err, sorry but that's a bit arrogant. I did make a proposal, and you 
think yours is better. Well I disagree <shrug>. I still think that 
what we have now is neither fish nor fowl. On the one hand you want 
concurency, to make it easy to use the old debugger, on the other 
hand you doN't want concurency to make ithard to use the old 
debugger. IMHO that is not logical. Yes I know what you claim to be 
your reasons, no need to reiterate them - I just don't agree with you 
for them being reasons. It would be trivial to have proper 
concurency, and this would have avoided a serious bug. It would also 
make it easy to debug stuff now. And the claim that this will slow 
down development of the new debugger I cannot accept either: the main 
person who is going to work on it should be you anyway, and you 
should be able to control yourself enough to work on it even if you 
have "temptation" of the old debugger around. There are not so many 
people using the old debugger anyway, mainly people actively working 
on ScummVM. And if one of them feel like it to work on the debugger, 
they will do so, and if they don't feel like it, they won't. Trying 
to "force" anybody to do the "inconvenient" work of implementing a 
new debugger by making it "somewhat inconcenient" to use the old 
debugger, is nonsense.
And if you now say "oh but a new developer shows up, the first thing 
he'll want to work on is a debugger", I won't even bother to comment 
that and just laugh :-)



Max
-- 
-----------------------------------------------
Max Horn
Software Developer