Re: [casetta] Ideas for version 0.4 of casetta /GPLv3

[Florian Birée <florian@xxxxxxxxxx>]

Hello,

Because you've started the thread I should have started, I begin by the
draft of the todo list of casetta 0.4 (with your propositions - see my
comments in answer of them):

# casetta
- needed items
* Full support of graph 65 (included the support of all g65 data, their
support in the transfer tool, and in all file formats)
- less important items
* Picture Extractor from backups (using the Fabien ANDRE's code?)
* List/Matrix extractor from backup
* Better img_to_basic function
* Add the support of all Fa-124 formats (for the compatibility with
graph 85/fx-9860G)
- optional items
* Try to make a picture to drawstat function. It may be difficult.
(About drawstat: http://www.casioland.net/forum/viewtopic.php?t=662
(french) and http://www.casiocalc.org/?showtopic=2078 (english))
* Depending of the advancement of the xfer9860 project, write a wrapper
for xfer9860 in a casetta transfer tool. This also depend of if I (or
any casetta developer/contributor) can get a graph 85
(See the discussion with xfer9860 developer:
https://sourceforge.net/forum/forum.php?thread_id=1753286&forum_id=682488 )

# casetta_cli
- needed items
* New arguments parser using the optparse python module
- optional items
* Add the support of the xfer9860 wrapper for command line arguments

# gasetta
- needed items
* New arguments parser using the optparse python module
* Create a list/matrix/etc editor
- optional items
* Improve the picture editor (drag'n drop to draw, etc)
* Make a 'drawstat editor' to make easily drawstat pictures (if the
picture to drawstat function is impossible to create)
* If the wrapper for xfer9860 work, make a special interface for it
(need to display the content of the calculator memory, etc)

I think also to implement a compatibility system, to check if the data
to be transferred is compatible with your casio calculator. I'll start a
new thread about this subject (but not this night).

Fabien ANDRE a écrit :
> Hello,
> 
> About casetta website, I would like to mention that the link to the web
> svn repository is broken :
> The link on this page (http://casetta.tuxfamily.org/download) points to
> :
> http://svnweb.tuxfamily.org/listing.php?repname=casetta+%28casetta%29&path=%2F&sc=0
> The good link seems to be :
> http://svnweb.tuxfamily.org/listing.php?repname=casetta/casetta&path=%2F&sc=0
> (Tuxfamily svn repository was reorganized ?)

I'll fix it.

> I have some ideas/proposals for casetta 0.4 (I insist on this point,
> they are just ideas :-) :

All ideas are welcome!

> - Reorganize the transfer tool (devices_serial.py), casio link
> management module (cas.py) and the data manager (data.py)...

> _*Cas.py*_
> /What I propose to do :
> /Create classes in cas.py, which derives from classes of data.py and add
> methods to these classes which have the same usefulness as the current
> functions.
> 
> For example, for programs we could have (in cas.py) : See cas-exple.py
> in attachements.
(The attachment has disappear...)
> 
> Of course, same thing have to be done for all classes of data.py. Using
> this new """architecture""", when implementing a new raw format, you
> just need to modify one class... Maybe, it would be good to also create
> a generic TransferableData class.

I've create devices_serial.py and cas.py by converting the perl code
from cafix into pyhton. The organization is more or less the same
(cas.py contain the code used for the transfer and for the cas file
format, devices_serial contain the transfer stuff).

You object model seems to be very better. I'm OK to try this
re-organization, maybe in a branch of the repository. It'll be the first
big work on the 0.4 version.

> The only function which cannot be transformed into a method is :
> det_data_format. But I don't like the way it works. Why does it return a
> string : header_type rather than directly an object (Which is created
> after in receive data of devices_serial.py ?)) See cas-exple.py in
> Attachements

Do you want to speak about cas.get_header_format?
As you wrote, this function cannot be integrated in the object model,
but it can return object, and more: it can do test provided by
transferable-data classes. With this, the cas.get_header_format just has
to get the list of transferable-data classes, and for each test if the
header match.
It's the better and more object-oriented way I see to do this.

> _*Devices_serial.py
> *_Keep cool ! For this file I don't want to change everything like the
> previous :-D
> I would like to change some part of the file :
> 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

No problem. Good suggestion.

> 
> In receive_data() function :
>                 ## List/Matrix management specific block
>                 if ( data_type == 'list' or data_type == 'matrix' or
> data_type == 'simlequation-matrix' or data_type == 'polyequation-matrix'
> ) and (index-13)%14==0 and index <= data_len-14:
>                     # Checksum test
>                     calc_crc=self.get_byte()
>                     filereceived.write(calc_crc)
>                     if abs(255 - (crc % 256)) + 1 == ord(calc_crc):
>                         self.send_byte('\x06')
>                         crc=0
>                         resp=self.get_byte()
>                         filereceived.write(resp)
>                         if resp != '\x3a':
>                             raise errors.BadAnswerFromCalc(resp)
>                     else:
>                         raise errors.ChecksumError()
> 
>                 ## Screencapture management specific block
>                 if data_type == 'screencapture' and sub_type == 'color' \
>                         and (index == 1024 or index == 2048):
>                     resp2 = self.get_byte()
>                     self.send_byte('\x06')
>                     resp2 = self.get_byte()
>                     crc = 0
> 
>                 ## Picture management specific block
>                 if data_type == 'picture' and (index + 1) % 1028 == 0 \
>                         and index != 0 and index + 1 < data_len:
>                     # IMAGE / color screencapture
>                     newcrc = ord(self.get_byte())
>                     crc = abs(255 - (crc % 256)) + 1
>                     if not newcrc == crc :
>                         raise errors.ChecksumError()
>                     crc = 0
>                     self.send_byte('\x06')
>                     resp2 = self.get_byte()
>                     if not resp2 == '\x3a':
>                         raise errors.BadAnswerFromCalc(resp2)
>                 #if data_type == 1 and bytesproc + 1 == 62684:
>                 #    print 'byte 62684 of a backup : send 0x06'
>                 #    send_byte('\x06')
>                 raw_data += byte
> I think each Transferable object should have a method return the indexes
> where the transmission needs to be stopped but I am not sure of how to
> do that.
> "Talk is cheap. Show me the code"

Or maybe with something like:
if mydata.is_transfered(index):
    # checksum stuff

We must check what an is_transfered function can need as argument.

> 
> _*Data.py
> *_The worst is before you. I don't want to change anything in this file.
> ;-) Just add some things ! Maybe we should create a generic FileObject
> management class which could manage File List, Variable Files, Y=Data
> Files and son.

Yes, it's probably the better option. I haven't take the time to really
read your code about new data.py objects (I'm moving to a new flat, and
that take time :-) ), but it seems to be good.

> My other proposals (I am pretty sure you will agree with them) for
> casetta 0.4 are :
> - Full support ? For Graph65

No problem, it'll be the main goal of the 0.4 version.

> - Picture Extractor from backups (I have one, which uses the white sheet
> to detect a picture in a backup because color bytes and son are not
> stored in backups). It is not so bad..

If we are sure to not extract non-picture data, no problem. It's easy to
implement it with regular expression.

> - List/Matrix extractors from backup

No problem (have you begin to see where they are stored in the
calculator memory?)

> - Better img_to_basic function

No problem if you have some idea to improve it. I'll not work on this
functionality until a full support of all casio models in casetta :-)

And... what's your opinion about GPLv3? Asher256 and I are ok to switch
in GPLv3 only, your are the last author of casetta code, your choice
will be the choice for the project!

Cheers,
-- 
Thesa ~ Florian Birée
e-mail : florian@xxxxxxxxxx
Messagerie Instantanée Jabber/XMPP/Google Talk : florian.biree@xxxxxxxxx
Site web : http://florian.biree.name/
Carnet web : http://filyb.info/

begin:vcard
fn;quoted-printable:Florian Bir=C3=A9e
n;quoted-printable:Bir=C3=A9e;Florian
org;quoted-printable:Universit=C3=A9 Toulouse III : Paul Sabatier;Licence MIA
adr:;;118, route de Narbonne;Toulouse Cedex 9;;31062;France
email;internet:florian@xxxxxxxxxx
title;quoted-printable:=C3=89tudiant
x-mozilla-html:FALSE
url:http://florian.biree.name/
version:2.1
end:vcard

Attachment: signature.asc
Description: OpenPGP digital signature