Hmm, that's interesting, working it from the other way around. I was thinking of libticalc being the plugin to the main gCn client. I think I'd probably prefer it my way, since I also support the "$10 Bridge" and the Arduino-based bridge, but that's some good food for thought.

The only reason I say that is because that's what I have planned for glassLink. Instead of having two programs try to claim the calc and run separately, not knowing what the other programs are doing, a plugin architecture would handle any interference. Now, this is more applicable for GlassOS since it can have multiple parts want to send data to the calc at the same time. :-\

The exposed routines would be for using TI's protocol to send custom packets or use commands not currently exported in their own function. For sending raw data there is already libticables.

The main use case of this would be to allow people familiar with the built in linking routines to easily communicate with a PC application. IIRC the link assist hardware uses TI's byte level protocol so this would allow the use of that as well.

On a more or less related note: the libraries have pretty much "always" been thread-unsafe. There are global variables, and if one tries to trigger multiple operations simultaneously, double frees or uses after free occur pretty easily.


Jonimus is entirely right, what I termed "raw packets" are effectively "arbitrary packets in OS format" (e.g., for DUSB, 4 size bytes + 1 type byte + data). Thanks for making it clear and correcting me
Several days ago, on IRC, Kerm and I discussed about the new capability in libticalcs, and the fact that the gCn bridge isn't using TI's protocols (possibly not a bad choice ^^) was mentioned in the discussion.


Adding and exporting the "memory dump" DBUS command of recent TI-Z80 calculators (as well as the whole set of higher-level "cmd" functions) is on the TODO list for the next release.
Dozens of functions need to be fixed, so that they don't crash if they're passed NULL for e.g. the CalcHandle pointer. Maybe Coccinelle (spatch) will proves even more helpful than it was in r4441, where I renamed most of these functions relatively painlessly

Really glad TiLP is still an active project A few days ago I wasn't sure if I wanted to switch back to TI Connect to send some stuff I could send with TiLP, but I guess I need to try out the new version first. The new features sound great!

Even if it were inactive, TILP would not become unusable overnight

EDIT: I'm progressively committing the constituents of the patchset, after performing small changes which don't impact executables but impact the build system / documentation / etc.

I have refreshed the installer at http://lpg.ticalc.org/prj_tilp/beta/setup.exe .
All changes have been committed to SVN.
As usual, the install script is https://github.com/debrouxl/tilp_and_gfm/blob/master/tilp/trunk/build/scripts/install_tilp.sh .

Highlights since the previous beta build (several posts above):
* added initial, experimental TI-80 VSC support, by Randy Compton. This model is very rare nowadays, and the only linking command it supports is "get screenshot";
* support for Nspire OS extensions, currently limited to English-Chinese dictionaries;
* a new function for the Nspire remote control feature, which makes it possible to implement nRemote ( http://ourl.ca/16836 / http://tiplanet.org/forum/viewtopic.php?t=10246 ) through FLOSS code - even before nRemote is publicly available

Some spelling fixes and minor man page improvements, too.

Please go forth and test

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

Four months after the previous beta, and a year after the previous release, the development cycle is drawing to a close, thanks to Benjamin Moody's important contributions

I'm releasing an intermediate beta tonight. It should soon be followed by a release candidate containing today's patch from Benjamin, for clearing the last significant hurdle for releasing TILP II 1.17 (minizip -> libarchive transition in libtifiles), and a minor fix (TODO) for Debian packaging (not copying Windows stuff even when compiling on non-Windows for non-Windows).
In order to handle Benjamin's libarchive patch, I need to set up some extra things and spend time on testing it and reading the code - but it's Friday evening, not the best time for doing that

* refreshed the installer at http://tiplanet.org/beta/setup.exe . (unusual URL, the ticalc.org FTP is currently experiencing trouble)
* the patchset against SVN HEAD is http://tiplanet.org/beta/tilp_patchset_20121214.tar.bz2 .
* is usual, the install script is https://github.com/debrouxl/tilp_and_gfm/blob/master/tilp/trunk/build/scripts/install_tilp.sh .

Highlights since the previous beta build (several posts above):
* improved support for "raw mode" external linking, by Benjamin Moody, thanks to two new functions for getting and setting both lines simultaneously (if supported by the cable);
* 84+DUSB ROM dumper: dump the certificate page as well;
* libticables: add dynamic libusb-win32 loader, which paves the way for driver-less libticables-based emulator installers - IOW, installation of TilEm and TIEmu on school computers without admin privileges;
* bugfixes: for instance, desynchronized UI and code reported by Deep Thought. The other bugfixes / improvements are less visible to users (for instance, robustness fixes and tests - API functions shouldn't crash when they're passed NULL arguments).

Please go forth and test

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

The development is considered finished, though I still have to make sure that the source tarball does not contain Windows binaries, so that lintian does not complain

* refreshed the installer at http://tiplanet.org/beta/setup.exe . (unusual URL, the ticalc.org FTP is still experiencing trouble)
* the patchset against SVN HEAD is http://tiplanet.org/beta/tilp_patchset_20121231.tar.bz2 .
* as usual, the install script is https://github.com/debrouxl/tilp_and_gfm/blob/master/tilp/trunk/build/scripts/install_tilp.sh .

Highlights since the previous beta build, a couple weeks ago:
* integration of Benjamin Moody's patch mentioned above, for using an external libarchive instead of an embedded fork of minizip. No intended functionality change, but the change removes the main reason why Fedora would never accept libti*/gfm/tilp packages;
* reverted a change in the installed DLL name, reported wrong on Omnimaga;
* integration of another patch from Benjamin, fixing two detokenization issues;
* expansion and integration of older work of mine, for fixing even more compiler warnings, fixing defects flagged by the dynamic binary instrumentation produced by clang -fsanitize=undefined (very useful ) + defects in similar code chunks.

As they stand before this last patch, libti* running on e.g a Nspire (under Linux, of course) have no chance of being useful to communicate with another Nspire. They contain unaligned memory reads/writes, and left shifts of count > width of type; now, dirlist, CX/CM screenshots, calculator information, and suchlike operations with another Nspire could work.

Please go forth and test

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

I'll look into fixing these issues myself if I get a chance, but documenting them here:

The mingw build puts ~/.tilp.ini in the wrong location. It causes breakage if tilp is not run as admin. (I vote just removing the mingw specific IFDEF's as that should make it behave like the old VS builds.)

The console window should go away for release builds, its fine for these beta's and I would be fine for having it IFDEF with --debug builds or similar but it looks very unprofessional for releases.

Serial links, namely the dhahelper stuff, broke with the last build. And while it hasn't ever worked for me on a 64bit windows, it is much more broken than it was before, not even installing the proper things. The source code does contain a fallback for 64bit windows but who knows when the last time that code was touched and if it even builds anymore.

More precisely ?


I have tried this at some point, but I ended up either never committing it, or reverting it, as it totally broke the ability to redirect stdout/stderr to a file, and thereby deprived me of useful debugging information


You mean that it worked with the December 14th build, but it does not work with the December 31st build ?

Also what happened to using github/sf.net's git repo, I haven't seen much activity on either from you?

As for the tilp.ini try running as non-admin on a windows 7 or vista box and see it try to write to %ProgramFiles%/LPG rather than the correct %APPDATA% and the My TI Data folder ends up in there as well. This was not an issue with the VS builds of TILP.


The serial stuff has been broken for a while now, but I don't know exactly when it broke. It was closer to working in 1.16 iirc but perhaps I can try to get a build environment setup to try and narrow it down. Are there details of what your setup is somewhere so I can give it a go?

Commit activity has been irregular over this development cycle:
* no commits between TILP II 1.16 (mid-December 2011) and May 2012;
* no commits since early September 2012, with the integration of the current patchset over HEAD (the vast majority of which was made by Benjamin) having begun at the end of November (and some pieces were rewritten).

In October, I had worked on fixing defects "reported" by `clang -fcatch-undefined-behaviour`, but I waited for it to become more usable before double-checking the work and integrating it (last patch in the patchset). Benjamin pointed out that there are other suspicious bits that warrant some attention.


Faulty fallback ? I'll try to have a look.


My build environment setup is somewhat described in tilp/trunk/build/scripts/recompile_cross_tilp.sh. If the description is incomplete (i.e. it does not enable you to replicate it), I'll gladly improve it with your help

Well, just to keep things clear, which tree are you updating and should be followed by contributors and is the svn tree official dead as it should be?

More like a faulty override of perfectly good defines from what I recall since the mingw build support was initially intended for people installing under mingw/mysys's install dir rather than system wide. It made sense if running from mysys, but not directly from windows.

All of them, SVN first and the others later. However, the patches from the past month were not committed yet: I don't have much time at the moment, they needed more testing - and precisely, one of my changes was faulty
As long as patches are committed to the trees relatively quickly (meaning that I shall commit in the next few weeks, probably this week as the holidays are over), and the patches are provided publicly anyhow, avoiding commit-and-fix is not a cardinal sin.


Not at the time of this writing, though the current location of SVN tree will probably disappear, as JB wants it gone

To date, I still have found no way to manage multiple Git trees as conveniently as the current pseudo-fused SVN tree (separate SVN repositories, which I've always used as one because it just worked). For instance, while I'm using it for synchronizing the Git repositories from SVN, mr doesn't do the job for the commit production part.
Do you know of something to that effect ?

Keeping an efficient workflow and reducing the number of manual operations matters to me, especially now that my job place is further from my home, resulting in ~45' to 1h less free time each day of the week.
A higher number of commits, as a side effect of tooling limitations resulting in having to split a single logical commit (such as a synchronized version bump or a change that spans multiple libraries), does not matter to me.

Well, it sounds like the issue is that "your doing it wrong" so to speak. Commits should not span multiple libraries, though I would support a tilibs repo and a tilp repo if you want to simplify things that way. The use case of just installing some of the ti-libs but not all of them is rather slim, and practically non-existent anyway so keeping them split inside the package

The other option I know of is git submodules but from what I hear its rather a pain to work with. But really, syncronized version bumps should not be needed that often and changes that span multiple libraries should be split. Big commits are generally bad and the only really acceptable large commits in the "git" workflow are squashed commits for large dependent changes, but even then it was broken up for review before being squashed and push to mainline.

Just like projects should follow rero, release early release often, git wants commit early commit often. Rewritting commits is not impossible and having 5 versions of a patch should not be an issue. Any new features and heck just about any commit that isn't a simple one liner or reviewed external patch should be developed in another branch. Git makes branching and rebasing easy as can be, take advantage of this.

See Github.com Git-Workflow especially the Do's and Don't's section for a better explanation than I ever could do.

Indeed, having a single repository for all four libti* (backends), a single repository for gfm and tilp (frontends), and a lower-activity repository containing the rest (tfdocgen, linkguide) would break my heart quite a bit less
Hmm... why did we never think of that before (IIRC), exactly ? ^^
Maybe the creation will be a bit troublesome, but `git filter-branch --tree-filter` and suchlike commands should help.
Thanks for your input


I've never used them because the documentation indicates that they don't do what I'm dreaming of - but I've always read about git submodules as mild pain sources, indeed.


They're fairly infrequent indeed, but I still find it silly to have to split a single logical commit


... without breaking the strive for bisectability, and the strive for not committing new code without users. Without going back far in time, r4415:4416 (moving a workaround from one library to another), r4458 (TI-80 VSC "get screen" support) or r4460 (support for Nspire Chinese-English dictionaries) would have taken extra effort.
Having a lower number of repositories, as you suggested, would largely fix the problem, though


* it's true that I'm not using many remote branches for the FLOSS I'm supposed to maintain, though the "experimental" GCC4TI branch started that way.
* however, locally, I can tell you I'm using branching, rewriting and rebasing a lot
At work, we're using local and remote branches as well. The workflow goes approximately like this: committing experimental stuff (+ subsequent fixes / improvements) to remote branches, and rewriting said remote branches on an internal Git repository used for integration testing and synchronizing multiple computers, before committing cleaned up stuff to the project's SVN repository.

In a collaborative project, rewriting remote branches is a big no-no. Contributors hate it when others do it ^^

Lionel, another issue we need to fix before the next windows release is the default file location when built with mingw. When MSVC was the official release compiler this wasn't an issue but now it is built with mingw we shouldn't special case it and default to g_get_home_dir() like we do for other OS's. The relevant code is in tilp_paths.c at line 93. This one has annoyed me for a while and tifreak8x also recently ran into it so I took the time to track it down.

I also think we should remove the checks for the old config file in program files and just inform people that old configs will be ignored in the new version. This should solve the issue of someone running as admin once and writing the config in program files and if they try to do it again failing. It might annoy a few XP users and people on Vista/7 who have UAC disabled but for security and future compatibility it needs to be done.

We also need to look at making libusb-1.0 based libticables builds on windows possible because it currently appears that due to a change in the driver signing requirements may make libusb-win32's libusb0.sys not an option on Windows 8 machines. While 1.0 doesn't work with the filter driver the latest git does work with our current libusb0.sys standard driver as well as WinUSB which is installed by default or available via Windows Update on all machines running Vista or newer. (XP is a separate download but available at least)

As I've mentioned on IRC I have also gotten Proof Of Concept driverless Blacklink / $4link support on windows working but it is far to slow to be usable atm. It works, slowly, with my TI-86 at least, but the faster calcs such as the TI84+SE seem to give up faster than I can toggle the lines with my current code. I have some ideas to speed it up namely only switching the lines I need rather than switching all of them all the time. Espcially since via the Windows Comm API, namely EscapeCommFunction, can only switch one of the out lines at a time so its currently two outputs per write rather than one. Inlining my helper function would also perhaps help but I have a feeling the API call is the biggest slowdown. I already had to remove the delay in order to not have it timeout every time. Having a git tree to work off of would be grand we really need to get that setup, svn just doesn't really cut it for this sort of thing and the branching/merging is horrid.

Finally on the subject of moving to git. Since tilp is basically the main consumer of libti* moving to a single large git tree maybe wouldn't be the worst. Two, one for the libs and one for the GUI would also be a an option, either way a unified autoconfig setup would and should be integrated if we make that move. But we really need to remove configure and other autoconf generated files from the VCS tree. To facilitate easy testing something like mesa's autogen.sh would be an easy way to facilitate this.

Oh, I didn't know this thread existed! I've got a bug report for the Linux version, under Ubuntu 12.04 LTS:

I try downloading tilp2 from the Ubuntu Software Center, which installs correctly but fails to communicate with my 84 Plus Silver Edition DirectLink (it does recognize it, however). I seem to recall someone saying that it does not work with DirectLink: is this still true?

The one in the archives is outdated. There is a script somewhere (I found it on ominmaga) that can be used to install the latest version that works.
edit: http://lpg.ticalc.org/prj_tilp/download/install_tilp.sh