Menu
▾
▴
Re: [TilEm-devel] libti*, titools...
|
From: Lionel D. <lio...@ya...> - 2011-05-29 07:29:15
|
Hi Benjamin,
> > > 1. Newer calculators (TI-83 and later) which support silent
> > > variable requests and directory listings.
> > > [snip]
> > > This seems straightforward except that we want all link
> > > operations to be asynchronous; we can't block the GUI while a
> > > transfer is in progress.
> > Yup, TIEmu and TiLem face the same problem.
> > The libusb 1.0 backend doesn't support asynchronous operation yet,
> > though it is likely to do so, sooner rather than later.
>
> I think you're talking about external linking (connecting the
> emulator to a real calculator via a USB cable)?
Correct.
> We haven't done that in TilEm2 yet, though it's something I'd like
> to add at some point.
Ah, OK.
> The current libusb0 driver does allow asynchronous operation on
> Linux and Windows, doesn't it?
Yes, it does. And the libusb 1.0 backend has now been committed, even if
it needs further fixing not detected by my tests with all USB devices.
> For internal linking (using ticalcs2 functions with a custom
> CableHandle to send/receive files)
Would it help TiLem if we added a brand-new TiLem cable to libticables ?
> the idea is to call ticalcs2 functions in a separate thread so that
> they don't interfere with the GUI. This is currently implemented
> for sending files, not (yet) for receiving them.
OK, good :)
> > > 2. Older calculators (TI-82 and TI-85) which only provide
> > > "calc-to-calc" transfers.
> > > [snip]
> > > Also note that, for these calculators in particular, it would be
> > > very useful to allow receiving memory backups. libticalcs2
> > > doesn't allow for automatically detecting a backup versus a
> > > variable transfer, but maybe we can kludge something together.
> > That would work... but wouldn't a new occurrence of insufficient
> > functionality in libti* be a good occasion to create the fifth
> > library (from stuff in tilp, gfm, titools) I already mentioned ?
> > I'm fully aware that it's some work, but it will reduce the need
> > for kludges in clients, and all clients potentially benefit.
>
> Absolutely, but I'm not sure what the API ought to look like. The
> issue with the current API is that you have to decide beforehand
> whether you want to call ticalcs_calc_recv_var_ns or
> ticalcs_calc_recv_backup. What we'd want would be to receive the
> variable header and decide what to do based on that.
A function that receives and returns a variable header, then ?
Could you post a feature request for this ? :)
> Actually, I believe that in calc-to-calc transfers, the sending
> calculator will happily wait for as long as necessary after
> sending the variable header and before receiving a CTS or SKP
> message (this is when the receiving calculator displays the menu
> asking whether the user wants to overwrite, skip, or rename the
> variable).
Makes sense.
> If we're saving files individually rather than as a group, it might
> make sense to take this opportunity to prompt the user for a
> filename.
If the calculator doesn't time out after only several seconds, yes,
sounds like it could work.
> > > In your reply to Thibault's reply to your mail:
> > > That's right. (Actually, the 82 and newer versions of the 85
> > > do support silent variable retrieval, although it isn't
> > > implemented in ticalcs2; neither model supports directory
> > > listings, so this isn't very useful.)
> > Nevertheless, would it make sense to implement silent variable
> > retrieval for the 82 ? It wouldn't be useful to TILP, but
> > command-line tools may use it.
> Sure, I guess it might be useful for somebody. I haven't tested
> it, but it looks like the protocol works the same way as for the
> TI-83 and 86.
I'll take care of posting this feature request.
> > I looked into the source of titools (0.1) to see how you handled
> > reception from non-silent calculators; then, I browsed the common.c
> > and glob.c files, which I had never done seriously before.
> > I spotted several things that we probably want to push to existing
> > libraries (or to the fifth library) in some form. For example:
> >
> > /* Convert UTF-16 to TI (ticonv_charset_utf16_to_ti() is not
> > implemented for most calcs) */
> > static char * utf16_to_ti(CalcModel model, const guint16 *str)
> > {
> > int i, j, k, n;
> > char *s;
> > unsigned long c;
> > const unsigned long *cs;
> >
> > if (!str || !*str)
> > return g_strdup("");
> >
> > n = ticonv_utf16_strlen(str);
> > s = g_new(char, n + 1);
> > s[0] = 0;
> > ticonv_charset_utf16_to_ti_s(model, str, s);
> > if (s[0])
> > return s;
> >
> > switch (model) {
> > case CALC_TI73: cs = ti73_charset; break;
> > case CALC_TI82: cs = ti82_charset; break;
> > case CALC_TI83: cs = ti83_charset; break;
> > case CALC_TI83P:
> > case CALC_TI84P: cs = ti83p_charset; break;
> > case CALC_TI85: cs = ti85_charset; break;
> > case CALC_TI86: cs = ti86_charset; break;
> > case CALC_TI89:
> > case CALC_TI92:
> > case CALC_TI92P:
> > case CALC_V200: cs = ti9x_charset; break;
> > default:
> > return ticonv_utf16_to_utf8(str);
> > }
> >
> > for (i = j = 0; i < n; i++) {
> > c = str[i];
> > if ((c & 0xfc00) == 0xd800)
> > c = (c << 16) | str[++i];
> >
> > if (c < 256 && cs[c] == c)
> > s[j] = c;
> > else {
> > s[j] = '?';
> > for (k = 0; k < 256; k++) {
> > if (cs[k] == c) {
> > s[j] = k;
> > break;
> > }
> > }
> > }
> > j++;
> > }
> >
> > s[j] = 0;
> > return s;
> > }
> >
> >
> > or
> >
> > /* Check if variable name should be tokenized.
> > ticonv_varname_tokenize() should probably be more
> > selective... */
> > static int is_tokenized_vartype(CalcModel model, int type)
> > {
> > switch (model) {
> > case CALC_TI73:
> > if (type == 0x05 || type == 0x06 || type == 0x19 || type == 0x1A
> > || type >= 0x20)
> > return 0;
> > else
> > return 1;
> >
> > case CALC_TI82:
> > case CALC_TI83:
> > case CALC_TI83P:
> > case CALC_TI84P:
> > if (type == 0x05 || type == 0x06 || type == 0x14 || type == 0x15
> > || type == 0x16 || type == 0x17 || type >= 0x20)
> > return 0;
> > else
> > return 1;
> >
> > default:
> > return 0;
> > }
> > }
> >
> >
> > The end of the former function could be pushed to libticonv as a new
> > function that the unimplemented ticonv_utf16_to_* call into, and
> > maybe also ticonv_utf16_to_ti9x could be cleaned up ?
> > Changes in the area of the latter function may help fixing the TILP
> > bug
> > https://sourceforge.net/tracker/?func=detail&aid=3018546&group_id=18378&atid=118378.
> >
> >
> > More generally, could you provide us a small list of inadequacies
> > in the libticonv/libtifiles/libticables/libticalcs APIs and
> > implementation (by e-mail, bugs on the TILP tracker, etc.), so that
> > we can try to improve them (probably not in TILP II 1.15
> > timeframe, TILP II 1.14 being already more than one year old, but
> > soon after) ? :)
> Sure, I have a bad habit of trying to work around other programs' bugs
> instead of fixing them. :)
:)
This makes your program able to cope with older unfixed versions of the
other programs, but doesn't fix the other programs :)
> I can't think of any other such issues at the moment, but I'll let
> you know.
Thanks.
For pushing chunks of your GPLv3+ code from titools to the GPLv2+
libti*, I'll need your permission to relicense them under the GPLv2+,
though ;)
Nobody needs permission for pushing GPLv2+ code to GPLv3 code, since the
former is explicitly made compatible by the "either version 2 of the
License, or (at your option) any later version", but the other way round
is different.
I have released TILP II 1.15, GFM 1.05 and associated libraries, the
files should appear on ticalc.org soon. No libti* API changes affect
TiLem, unless the long-deprecated ticalcs_calc_dump_rom function is
still referenced.
I'll upload the files to the SF infrastructure, and update the TILP site
on ticalc.org.
Thanks and bye,
Lionel.
|