Two updates.
After talking to Lionel about libtifiles it looks much of the input filtering I thought I was going to have to implement is actually being implemented upstream so that will save me quite a bit of work and make my code much cleaner. The one down side to this is that I will have to require the svn version of libtifiles until TiLP 1.15 comes out or even after that.

The second thing I found out, thanks to benryves and Tari on IRC, is that Windows doesn't provide the getopt_long or even the POSIX getopt so I will have to move to a different option parser if I plan to support windows. My plan was to use glib's as it is already required by libti and TiLP so it is not the end of the world but I was still trying to avoid its use. I'm not 100% familiar with the library setup on windows so it will be a bit more work to get everything working the way I'd like.

One advantage of using glib's getopt functions is that it can handle the help and Version stuff for me so that is an added bonus.

Finally depending on how much luck I have moving to glib I hope to release version 0.1 beta 1 in the near future though I'm not sure if I want do the move to glib first or wait till a later release.

That's annoying about Windows; I wasn't aware that it didn't support Posix getopt, although maybe I should have realized based on the fact that it uses /forward /slash /switches instead of the -s --tandard --dashed -s --witches that everyone else uses. Does the glib offering differ significantly?

That's little to do with Windows and more to do with CP/M, which didn't have a hierarchical file system (so using / as a switch character wasn't an issue). CP/M begat DOS, and DOS begat Windows. (In any case, DOS and Windows supports forward slashes in paths just fine, and the character indicating a switch depends on the program - PowerShell uses -dashes, for example).

As discussed on IRC, Microsoft do offer a software package to add a Unix subsystem to Windows NT but it's not standard on non-enterprise editions of Windows. Cygwin is usually the best bet, or you could change the way you parse command-line arguments (as TheStorm seems to be doing) or use one of the many getopt implementations that pops up if you search the web.

As I said using glib's getopt has the added bonus of handling the help and Version options for me so in the end it makes much more sense to just use that as libti* requires it anyway. The only reason I hadn't used it thus far as getopt just worked and when I first attempted using glibs getopt I ran into errors.

I should hopefully have time to get glib's getopt working tonight or tomorrow and then I will be one step closer to a release.

After playing with mingw a bit I have everything working with glib and it appears the windows build works as expected. If you want to try out what will soon be version 0.1b1 Click Here.

The included .dll's are from Lionel's latest TiLP beta and but since they do not lie in the windows PATH by default I have included them for the sake of ease of use. You will also need a recent version of the GTK or glib runtimes in your path but if you have TiLP installed working then you already have that.

The feature set is still rather limited but it can do most of what I wanted the bare minimum to be. Use -h or --help for usage and to get an idea of what is possible at this point.

Excellent! Seems good to me so far in my limited experimentation. I hope you continue to make good progress.

So after working on the libusb-1.0 stuff for libticables2 I decided to put a bit of time towards this project. What I ended up doing is setting up GNU autotools so that when I am finally ready to make a release I am all set, while it does complicate things slightly it adds the ability to run make install which makes packaging much easier for package maintainers and Users who compile from source.

I've also started moving common functions to a single file, which is made easier by automake.

One thing that has bothered me is how verbose libtifiles is even when just initing it, I can quiet it but then I would need to write my own content displaying routines. While this is not hard adds quite a bit of code as well as loses the french translations included with libtifiles.

Good
Verbosity on stdout/stderr is not much of a problem when using TILP/GFM, but indeed, when using a CLI tool, it becomes more of a problem...
That can't easily be fixed without changing the API, though.

Doesn't it have verbosity controls? Most projects I've worked with at least have the option to turn verbosity on and off, and many allow verbosity levels from 0 to 3, or INFO through FATAL, or something along those lines.

Necropost time
I should certainly have spent more energy on the matter over the past years, but I didn't, and that wasn't a good thing. Oh well... better late than never ?

For years, an item related to libtifiles-based calc file manipulation has been part of the internal, not-so-secret todo / wish list for libti* / gfm/tilp, which I'm progressively, if slowly, moving to https://github.com/debrouxl/tilibs/issues . At the end of 2011, the todo list already contained a mention of tiutils, though that was for libtiopers. A writeup about some needed calc file manipulation functionality, containing a link to this topic, didn't enter the file until 2016.

And the trigger for reviving this topic & item is that my recent work on converting the TI-68k ROM dumpers to pure assembly, and making them buildable by generic m68k toolchains (yes, without GCC4TI), has left me wanting to use, during the libticalcs build process, a libtifiles-based tool for at least setting the checksum of the generated files - that's the only thing my current assembly header + footer and ldscript don't compute - or better, wrapping header+footer-less raw binary data output by as+ld into the computer-side representation of a calculator file suitable for transfer.
Even if for now (and probably for the longer term), in order to work around the lack of a checksum in the generated binary, I made checksum errors non-fatal.


So I'm more interested in making CLI tools for manipulating calc files part of the tilibs repository, though maybe that project should live separately, alongside the four other current projects (to be joined by libtiopers some day), rather than be shoehorned into libtifiles.

The first task is probably to gather and consolidate into a single place (Github issue) the ideas posted in the todo/wish list, the ideas and the TI-Utils code posted in this topic, and the existing features of the TI-68k Developer Utilities (part of GCC4TI), tipack and the titools... and then probably brainstorm some more

In the meantime, as part of my fuzzing activities outside the TI community, I saw the CLI (both interactive and non-interactive) design of e.g. gdbmtool and tdbtool - and I like it. Although I'm not keen on implementing interactive keyboard input at first, it would be great to be able to use a single, (more) highly scriptable binary, rather than multiple CLI tools.


In 2011, expanding the use of Glib made sense - the fact was that, and is still that, libti* depend on it. However, nowadays, that would be a step in the wrong direction. In order to make it easier to target JS and WebAssembly through Emscripten, I've started reducing the dependency on Glib in libti*.

I created the issue corresponding to the previous post two days ago, but I waited for a bit longer before double-posting here

https://github.com/debrouxl/tilibs/issues/31 gathers information from multiple sources, including this topic, and contains several new ideas.