TILP: beta-testing...

u/Dream of Omnimaga May 01, 2016, 02:13:21 PM

I see. That could definitively become useful

u/Lionel Debroux October 09, 2016, 06:10:09 PM

A bunch of changes since the previous build:

reduced some internal code duplication and exported yet more functions to users (under no promise of backwards compatibility);
communication fixes for MacOS X with especially the Nspire, by Adriweb;
changes and code-based documentation related to requesting information from DUSB TI-Z80, TI-68k and TI-eZ80 calculators. A significant number of previously undocumented parameters, some of which are useful, came to light;
other bugfixes and improvements;
rebuilt against a newer version of the external libarchive library, namely version 3.2.1, containing a bunch of security fixes.

This build is noteworthy in that it is probably the last beta build before the long overdue release of TILP II 1.18
As such, and even if I know that very few people use TILP or its libraries, testing would be appreciated.

The only remaining item for the current development cycle is adding clock getting / setting support for the TI-eZ80 series, which was made possible by the DUSB PID documentation work from the past few weeks. Not a task for this week-end, though.

The usual links:

Windows installer download: http://tiplanet.org/beta/tilp2-setup.exe .
Source code: https://github.com/debrouxl/tilibs (experimental branch) + https://github.com/debrouxl/tilp_and_gfm (experimental branch).
Install script for anything non-Windows which is handled by TILP: https://ti-pla.net/tilpinst , https://github.com/debrouxl/tilp_and_gfm/blob/master/tilp/trunk/build/scripts/install_tilp.sh .

EDIT in 2021: updated the link to the *nix install script.

Last Edit: October 02, 2021, 07:08:23 AM by Lionel Debroux

u/Dream of Omnimaga October 10, 2016, 04:46:15 AM

Awesome Lionel. Something I am curious about is how the transfer speed compares to TI-Connect CE. TI-Connect was very slow, but TI-Connect CE improved things considerably, so I was curious about if TILP managed to push things even further. Also, can it do ROM dumps for the TI-82 Advanced and TI-84 Plus-T?

u/Lionel Debroux October 10, 2016, 06:09:30 PM

QuoteAlso, can it do ROM dumps for the TI-82 Advanced and TI-84 Plus-T?

Nope: this would require exploiting these calculators, but the method to do so is not public

Having libticalcs use exploits for holes in the calculator's software is not an issue in itself, as shown by Benjamin Moody's ROM dumper for the 85 and old 82 models, or even the Nspire OS 1.x dumper, which leverages direct directory traversal.

u/p2 October 11, 2016, 03:29:43 PM

I know this is not really about beta testing...
But it would be really great if there was an easier way to set up TiLp on different Linux distributions as it took me multiple hours to get it done the last time...

Btw will TiLp one day be availagle in the official download center (that GUI that makes it that much easier than manually doing it over terminal)?

u/Lionel Debroux October 11, 2016, 03:42:57 PM

QuoteBtw will TiLp one day be availagle in the official download center (that GUI that makes it that much easier than manually doing it over terminal)?

By now, TILP is packaged by at least Debian / Ubuntu / Mint / their many derivatives (alberthro), Arch (Jonimus et. al), Fedora (TC01) and OpenSUSE (Vogtinator). I might have forgotten one when writing this post. IOW, it is part of the official download center for the main end user distros

However, the fact is that the latest official release - which is packaged by distros, most of them do not package from the development sources - is nearly always hopelessly outdated. Even when there was a year +/- several months between releases, as occurred for TILP II 1.14-1.17, past the first few weeks after a release was cut, the version in the SCM (formerly SVN, nowadays Git) contained a bunch of new features and bugfixes made since the official release.
The changes in the upcoming TILP II 1.18 release train over the 1.17 release are by far larger than the changes between any two consecutive release trains in 1.13-1.17. Yes, I really should have made at least 2 releases since April 2013

Compiling from source, which is easy with the install_tilp.sh script (especially nowadays that I went out of my way to provide copy-pastable lists of build dependencies for multiple distro families), is what I tend to tell users of distro packages when they experience some unwanted behaviour, unless I know that this won't change anything (e.g. because I didn't modify that particular area since then). This is common behaviour for open-source / free software projects, not just for libti*/gfm/tilp.

Last Edit: October 11, 2016, 03:47:31 PM by Lionel Debroux

u/p2 October 11, 2016, 03:56:37 PM

For some reasons I couldn't find it on Mint when I wanted to install TiLp...
Had to do it manually using the terminal but at least someone sent me a script that did SOME of the work for me (but still had to manually get like a thousand dependecies) xD

u/Lionel Debroux October 11, 2016, 04:02:25 PM

QuoteHad to do it manually using the terminal but at least someone sent me a script

Yup, the script linked above.

Quotethat did SOME of the work for me

Attempting to detect the exact flavour and version of the Linux distro currently executing a script, and attempting to support the most relevant subset of distros is a significant pain and amount of work. Really

Quote(but still had to manually get like a thousand dependecies) xD

Yes, dozens of packages when counting the transitive dependencies. But at least, the script tells you which ones to download for the most popular distros

u/p2 October 11, 2016, 04:04:59 PM

yess it was a great help the script told me that

It was just like "oh god... not again... aaaahh" each time I got a new "YOU NEED THIS PACKAGE FIRST" message... xD

And as I experienced myself what a pain it is doing it for only one distro... I dont even want to imagine how much work it is creating a script that does all that automatically and for multiple distros >.< Big thanks for you guys putting so much work into that!!

u/Lionel Debroux October 11, 2016, 04:26:27 PM

QuoteI dont even want to imagine how much work it is creating a script that does all that automatically and for multiple distros

It's high indeed. The first step in the distro type + version detection automation was obtaining the relevant lists of packages, which I eventually did through Docker containers, so that I didn't have to install the whole distros in VMs. Attempting to auto-detect the distro would be the second step, but much work. I suppose I'd borrow from install scripts I saw over time, e.g. the install script for SDR stuff, but still.

Last Edit: October 11, 2016, 04:28:14 PM by Lionel Debroux

u/p2 October 11, 2016, 04:31:50 PM

I begin to understand...
People keep saying Linux sucks because it's so much work to install only a single program... (I did myself)
I finally begin to understand WHY many developers don't change something about it

u/Lionel Debroux October 11, 2016, 04:41:01 PM

QuotePeople keep saying Linux sucks because it's so much work to install only a single program... (I did myself)

And yet, it's so much easier to install a single program from the C/C++ source code in Linux or MacOS X than it is in Windows, that it isn't funny

Yes, seriously. Downloading build dependencies on Windows is so much of a pain that in fact, Microsoft recently created its own project to do exactly that, after users requested for many years that Microsoft provide something as good as the Linux package managers (apt and friends), or homebrew (third-party) for MacOS X. I forgot about the name of Microsoft's project.

QuoteI finally begin to understand WHY many developers don't change something about it

Amount of free time for many developers, yeah... I've never been paid to work on libti*/gfm/tilp, though it's a fact that I bought only a small subset of my calculator collection by myself, especially because I picked up 15 calculators from Romain Liévin a little while after becoming the maintainer, and that TI paid for most of my trip to their office in Paris in 2011.

u/p2 October 11, 2016, 04:55:50 PM

wait... you went to paris to visit some TI officials or something? O.o
THat sounds like an interesting story

Did they love you or did they hate you for creating TiLp...?

u/Lionel Debroux October 11, 2016, 06:14:59 PM

* yes, I went to TI's office in Paris once in 2011, and I met critor and Adriweb there (for the only time, so far) for a meeting with TI EdTech people, two of them being high-level executives. That was documented on TI-Planet at the time, IIRC, but probably in French only. On his side, Romain once went to TI EdTech's office in Dallas.
Amusingly, I had met Adriweb's father in a completely unrelated event, the year before.

* I didn't create TILP, Romain Liévin and Julien Blache did at the end of the 1990s, a decade before I became the maintainer

* TI is far from hating the work Romain, Julien, I and contributors (Benjamin Moody, Jonimus, etc.) did and still do on our free time

The TI EdTech stance is not to provide documentation about their "modern" (2004 and later) protocols and file formats, or even full documentation for their older protocols and file formats. So they're not trying to help the making of what we TI community dub "calculator linking software" (in HP parlance, it would be more like "connectivity kit") by providing information.
However, they're clearly not trying hard to hamper third-party efforts finding information by themselves (through reverse-engineering for interoperability purposes, which is perfectly legal in pretty much any country, all the more it's non-commercial as far as we're concerned) and providing programs for platforms both not supported (Linux, the BSDs) and supported (Windows, MacOS X) by TI EdTech, either.
They're even helping a bit, as a matter of fact: they gave calculators and cables to Romain in the past, which were invaluable to him for adding support for the 89T/84+ and Nspire USB protocols . They gave several calculators to me since 2011, the first one being the CX CAS, which enabled me to add Nspire CX / CM (CAS) color screenshot support in libticalcs several days later. They don't require NDAs, I never signed any form of NDA with TI (or anyone else, for that matter).

u/p2 October 11, 2016, 07:04:52 PM

wow I'm really surprised as I only got negative news about TI like making it impossible to downgrade the calcs and stuff like that.
How comes they on he one hand support people like you but on the other hand try to lock out some of our stuff?