Re: [TilEm-devel] Receiving files and other linking matters

[Benjamin M. <flo...@us...>]

>> Sounds good.  One other point regarding the user interface: should we
>> display the "save" dialog before or after receiving variables?  In the
>> non-silent case, we have to finish receiving variables first, but in
>> the silent case, we could, in theory, display the save dialog first.
>>
>
> I've working a little bit on it. Now, getting vars is done before printing
> the dialog even for silent case.

OK.

> If the getting vars function do not work correctly, the receive dialog
> simply prints an empty list (so user must use refresh to get entries).

Hmm, failing without an error message isn't good...

> Another subtle point to consider is which file format to use.  When
>> transferring multiple variables, they can normally be stored in a
>> "flat" group file (.??g).  But if we are transferring applications in
>> addition to variables, or if we have more than 64k total, we need to
>> use a TIG file instead.  Some users might prefer to use a TIG file in
>> any case.
>>
>
> As you prefer.
>
> I've added a feature wich allow to list ti82 and ti85 vars.
> I think that's not really exactly how we had decided to do but it's
> basically working.
> Currently the user must prepare the calc himself to be in "send all" state.
> I think it could be done automatically (using a kind of
> prepare_for_link(emu) function) but for the moment I can't get it working
> automatically.

This makes some sense, but I don't really like the idea of blindly
pressing a sequence of keys - not knowing what state the calculator is
in to begin with - and hoping that somehow we'll end up in the right
place when we're done.  I know I did that in the test GUI, but only
because at the time, I needed a quick way of sending files from the
command line, after a cold reset - I didn't care to do anything
fancier or more robust.

> With this method, I get the var entries easily (even if the calc prints an
> "error link" message after 4 or 5 seconds).

Sounds like the EOT isn't being acknowledged for some reason?  I don't
remember how this is dealt with in ticalcs2.  I'll check it out.

> A this state, is it possible to only write the selected entry without
> reusing "ticalcs_calc_recv_var_ns" (and preparing link)?
> I would say : just extracting an entry from FileContent?

Yes, you can do that.  tifiles2 might have some convenience functions
for "grouping" and "ungrouping" FileContent structures, I don't
remember.  Either way, it's not hard to rearrange them by hand.

>> The VarEntry structure is also used within a FileContent, to store the
>> variable data.
>>
> Yes I have studied a little bit libtifiles and tilp today. A FileContent
> could even contains more than one entry (content->num_entries ,
> content->entries[0]).
>
> One thing I'm not sure : does a VarEntries contains all the data we need to
> transfert it on the computer?
> As said before, getting a FileContent containing all vars then extract only
> one VarEntry and use tifiles_content_write_regular to write the destination
> file could be a solution to do not ask the user to do some actions on the
> calc link menu.
> I'm don't know if I'm telling something stupid or not...

I suppose it could be made to work.  I'm still skeptical about the
idea of pressing a long sequence of keys automatically, but maybe by
peeking at the calculator state we could tell that it's actually at
the home screen to begin with?  Then, if we fast-forward through all
the link operations, it should be quick enough to transfer all of the
variables without a huge delay.  It's a nice idea UI-wise, I'm just
worried about the implementation.

>> However, it can't be used to store Flash apps or memory backups.  And
>> we could use VarEntries to store TI-81 programs, but that's
>> non-standard.  Maybe we could define our own generic file content
>> structure, and a set of GUI-independent functions for manipulating
>> them.
>>
>> (The logic for reading and writing all of the various file formats is
>> complicated enough that I think it would be worth keeping it separate
>> from the GUI.)
>
>
> As you want, tell me more about this possibility :)

I haven't thought it out completely, but here goes. :)  We should be
able to handle at least the following file formats:

- for the TI-81, PRG files
- for other models, normal program/variable files (e.g., .82P), group
files (.82G), and backup files (.82B)
- for the TI-73 and 83+ family, Flash apps (.8XK) and OSes (.8XU)
- TIG files

We could have a "TilemFileContent" structure, that could contain
either a FileContent, BackupContent, FlashContent, or TI81Program.
Also a "TilemVarHeader" structure that describes a single variable (or
application.)

A generic "read file" function would parse an input file and return a
linked list of TilemFileContents.  A "write file" function would write
such a list to a file.

A "send variable" function would take a TilemFileContent and send it
to the calculator.  A "get directory" function would produce a list of
TilemVarHeaders (from which you could extract the names, types, and
sizes of each variable.)  A "get variable" function would take a
TilemVarHeader and produce a TilemFileContent.  When called from the
GUI, these would all be asynchronous, but we'd also want synchronous
versions for command-line processing.

> Yes you're right code is duplicated and not optimized ;)
> And there's a lot of others problem in my code... As soon I have something
> working correctly, I will do a refactoring to add error handling etc...

Error handling - and more generally, returning results to the GUI
asynchronously - does make things quite a bit more complicated. :)

> Have you seen the new ti80 emulator by Randy Compton? That's great ;)

Yes, I've just heard about it, but I haven't had the opportunity to
try it.  Pretty cool; I gather that he reverse-engineered the entire
instruction set?!

Benjamin