Re: check sum (Re: [Jsynthlib-devel] Okay... so why can't I edit a patch with this?)

[Joe E. <jo...@em...>]

Bill Zwicky wrote:

> Joe Emenaker wrote:
>
>> The only way, that I can see, that would cause it to break another 
>> synthdriver is if that synthdriver *accounted* for the bug with its 
>> own code. But two wrongs don't make a right. I bug in a checksum 
>> method is a mistake. Trying to solve the problem by tweaking *other* 
>> parts of the synthdriver (instead of the checksum method) is *also* a 
>> mistake.
>
> No no, you have it backwards:  What if the synths themselves are 
> buggy?  What if someone tweaks the common driver to work around bugs 
> in their synth, but that triggers bugs in someone else's synth?

Well, you make the rule that nobody is allowed to "tweak" any of the 
common checksum methods. You can "fix" bugs that you discover, but you 
don't go in and just add some stuff that gives you the results you need 
without identifying a flaw in the existing code. In other words, if 
you're using a common checksum method and you're getting a bad checksum, 
either:
1 - There's a bug in your synthdriver
2 - You're using the wrong checksum method, or
3 - There's a bug in the checksum method itself.

In those cases, respectively, you:
1 - Fix your synthdriver
2 - Figure out the correct checksum method to use, or
3 - Notify the list that you think the checksum method is broken. Do 
*not* tweak your driver to get around the bug because, if the bug is 
ever fixed, it could break your driver.

> But if there's common code, it should be pulled out to a common place.

Of course. I thought that was a given. For example, we could use... 
org.jsynthlib.util.CommonChecksums

>> Well, I think the XML driver will. It's going to need (or want) to be 
>> able to choose checksum methods with a text string.
>
> True, but the XML driver is a completely seperate problem.

Well, I think that the XML driver shouldn't have to be a special case. I 
think the XML driver should, from the perspective of the higher JSL 
code, act just like all of the others. I've already tossed around some 
ideas with Rib Rdb off-list for cleaning the XML-specific stuff out of 
devicesConfig. But that's probably a separate discussion.

>> I'm also trying to solve future code-bloat. I'm looking forward to 
>> the day when JSL has support for 1,000+ devices. 
>
> Those are seperate problems too.  We're using Java on Gigahertz class 
> machines; bloat is not a problem.  Trust me on this, bloat is *really* 
> not a problem.

We have only about 100 synthdrivers and it takes me close to 1 minute to 
do a CVS update.

>> Even if we are lucky and *every* developer in the entire future of 
>> JSL writes flawless checksum methods, then our best possible outcome 
>> is needlessly-bloated code and a lot of duplicated effort.
>
> 1000 duplicate checksummers is *not* a problem as far as code size is 
> concerned.  But what about maintenance?  Well, how do you modify code 
> that affects multiple synths that you don't own?  How do you maintain 
> this code without having all 1000 synths around you?
>
> This is why I keep pushing for isolated code.  I think it's important 
> that hacking on a driver not affect any other driver.

Well, I don't think anybody should be "hacking" on anything in JSL. If 
something doesn't work, you don't work around it. You find the problem 
and fix it. If other people encountered the problem earlier and just 
worked around it, I'd say that they made a mistake... and that that 
should be fixed, too.

But I don't think that this will be as much of a problem as you fear. 
First, checksum routines are pretty easy to get correct, and any errors 
that are made would be fairly likely to be discovered quickly (even 
quicker when mulitple drivers use that checksum method). Secondly, I'm 
not necessarily saying that we need to go back to all of the old drivers 
and change them so that they use common checksum methods. I'm thinking 
more of future drivers.

- Joe