Re: [casetta] About compatibility between casio models

[Fabien ANDRE <fabien.andre.g@xxxxxxxxxx>]

Florian Birée a écrit :

Hello,

There is - in my opinion - an important issue we must think about in Casetta 0.4.
Casio calculators exists in different models, and different models doesn't manage exactly the same data (business is business).

By example, G35/65 can manage lists, but not G25, only G65 display orange and green pixels in pictures, some basic function are only available in certain models, etc.

There is three way to manage those differences.

The first is the one of Casetta 0.3 : doing nothing. Data is send to the  calculator. Maybe the calculator will refuse the header, but in most cases, data will be send, but will not be able to be used (think about programs with getkey for a G25).

The second is the one of Fx-Interface : one file is associated with a calculator. You'll be able to use only functions of this model. But this system has drawbacks: it's more difficult to share data with users of others models (if you make a  program in a G100 file in Fx-Interface, and you want to send the data to a G65, you cannot, because it'll try to use the transfer protocol of the G100).

In Fx-Interface, a file is like the memory of a calculator. But is it a good idea? By now, a Casetta file is already not like the memory: we store backups, screenshoots.

The third way to manage differences is the one I suggest for Casetta.
In Casetta, a file is just a container for all data. Some rules restrict some properties of data like names, etc. Theses rules should be the largest for all casio models (like names with 12 character because of the G100).

The verification of compatibility should be done only just before the transfer. A target model will be set in preferences (we can ask the model at the first startup, and of course a none setting could disable the verification).
All data will have a suit of test to check the compatibility of the data, and if something fail, a report will be displayed:
 * Some warning (which can be disabled), like 'Your picture use colors. It may not be fully displayed on your calculator'
 * Some errors, which can be fixed easly (like a name too long)
 * "Fatal" errors like a data type not supported

Interfaces could propose or make some fixes (new name, etc) before the transfer. We can also imagine the possibility to make tests for a given model from Gasetta menu.

We must think about how to implement this: the system must be able to various test, and to provide fixes when they fail (if some fixes are too heavy, we can make them as tools, like for change some basic function that doesn't exists in some models).
We must also reference all particularities for all casio models.

Because this system may need some changes in the data model (some restriction should be moved in the compatibility test suit), I think this compatibility system should be a part of Casetta 0.4. If we wait, we'll have more code to change.

What do you think about it?

Errr... What I think about that ? First and foremost I am impressed by this system :-D

Seriously, I think that the model you propose for casetta is the best... for users ! But it may be the worst for developers as it seems quite complicated to implement :-p

We must think about how to implement this: the system must be able to various test, and to provide fixes when they fail (if some fixes are too heavy, we can make them as tools, like for change some basic function that doesn't exists in some models).
We must also reference all particularities for all casio models.

About the implementation, I have the beginning of an idea. It would use the new object models of cas.py.
In this e-mail ( http://listengine.tuxfamily.org/lists.tuxfamily.org/casetta/2007/08/msg00002.html ), I said about the file devices_serial.py
" In send_data() function :
            raw_data_list = [data.raw_data[0:1028],
                             data.raw_data[1028:2056],
                             data.raw_data[2056:3084],
                             data.raw_data[3084:4112]]
        elif data.__class__ == datacls.Matrix or data.__class__ == datacls.List or data.__class__ == datacls.SimlEquationMatrix or data.__class__ == datacls.PolyEquationMatrix:
            raw_data_list = data.get_raw_data_list()
        else:
            raw_data_list = [data.raw_data]
I would like to replace this by : raw_data_list = data.get_raw_data_list(). This means each Transferable object in cas.py, should have a method who returns a list of data to be transferred even if this list contains only one element"

I think each get_raw_data_list method (which is called before any transfer) could call another method named is_valid which would take the model of calculator in argument and raise errors. For example for a program :

class TransferableProgram(datacls.Program):
    ....
    def is_valid(self, calculator_model):
       if calculator_model != "G100" and len(self.name):
          raise TooLongNameError
       if calculator_model == "G25":
          for line in self.get_text():
             raise

class TransferableList(datacls.List):
    ....
    def is_valid(self, calculator_model):
     if calculator_model == "G25":
       raise ListNotAvailable

An then casetta_cli and gasetta could provide fixes using try: except blocks. Or maybe we should directly include a method to do the various fixes inside the objects. This implementation has advantages : quite easy to implement, ability to make completely different tests for any data_type and drawbacks : the method is_valid may be enormous for some data_types such as programs, it is not really "clean" as the compatibility test suite is not located is a specific module, and we cannot distinguish fatal, major errors and warnings. For warnings maybe just a return -1, "Your picture uses colors, I may not be displayed correctly." is enough.

About backups, I think they should use the Fx-Interface model, they should be calculator dependent, although it may be possible to transfer a backup of a G35 to a G65. However, we will have huge problems !

About the particularities, you are right it is the first thing we should do. Listing the particularities may help us to find a good implementation.
As far as I know :
G100:
Does not have the => instruction (equivalent to if ... then)

G25:
Does not have the circle sketch instruction.

Where should we publish this information on the wiki ?

Because this system may need some changes in the data model (some restriction should be moved in the compatibility test suit), I think this compatibility system should be a part of Casetta 0.4. If we wait, we'll have more code to change.

This is a good argument ! Let's try to include this in Casetta 0.4 (As the development has just started and as we are free to mess up the compatibility with casetta_cli and gasetta). I think, to ease our work that the objective for casetta 0.4 should be to implement this compatibility layer and provide basic fixes but not too complicated ones.

Yours,
PS : I was correctly added to the group "casetta" on tuxfamily. Thank you !

--
Fabien ANDRE aka Xion345
Linux User #418689 -- fabien.andre.g@xxxxxxxxxx -- xion345@xxxxxxxxxxxxx
How should I know if it works? That's what beta testers are for. I only coded it. ( Attributed to Linus Torvalds, Not dated )