libticalcs: Ability to delete folders

[the-blank-x]

I'm trying to write a FUSE filesystem (I know, a bit overkill) to manipulate files on the calculator, or at least a CLI utility, but it seems that I cannot delete directories.

It looks like there are two commands for deleting a file and a folder, while libticalcs only uses one. It seems like the ability to delete folders is already in the code, just unexposed.

I can (try to) implement this, but I don't know whether to expand ticalcs_calc_del_var to handle VarRequests with an empty name and non-empty folder, or to create an entirely new function (say, ticalcs_calc_del_fld). Also, the TI-86k supports folders, and I don't have one to test (nor do I know if you can actually remotely delete folders).

[debrouxl]

AFAICT, the ability to delete folders remotely is specific to the Nspire series, and unlike the folder creation operation, it can't be emulated on the TI-68k series, where remote file deletion was added only in the newest versions of the OS. I guess that this single protocol aspect is the main reason why I never wrapped it as a top-level operation, all the more I eventually exported a significant number of previously internal DBUS, DUSB and NSP functions for direct usage.

However, I see that the Nspire-specific folder deletion operation isn't exposed by the best available test_ticalcs_2 from the experimental2 branch, which is an indirect good catch :)

In the end, I suppose it could be made a top-level function, indeed named ticalcs_calc_del_fld(), with a new entry at the end of _CalcFnctPtrs and CalcFnctsIdx, a call within torture_ticalcs, a new operation in test_ticalcs_2, etc. That would generate significant conflicts with the WIP lab equipment support changes on the experimental2 branch; as such, this needs to be developed against the frequently rebased experimental2 branch, and I should probably be the one doing it.

In general, you can test TI-68k calculators, and communication with them, on TIEmu. Unlike the whole TI-Z80, TI-eZ80 and Nspire series, TI-68k OS upgrades downloaded from TI's site or elsewhere are enough to emulate them for all purposes but the OS upgrade transfer process, which is... seldom needed.

[debrouxl]

I've pushed an untested commit for doing what you need. Mostly a copy-paste-modify job, so we'll see whether I did silly mistakes. At least, I was able to spot a number of issues in the previous commit, and fold fixes into that one.

[the-blank-x]

It works, thanks! (also, there's a tiny bug here: https://github.com/debrouxl/tilibs/commit/4f3d85e31a1f9ff6a0c1b58e0b797f404ab5a63a#diff-f121fd10659d4a44afd4daf007c5623e307fe0eba98787ee016f15e90143328bR1144)

[debrouxl]

Heh. Fixed locally, thanks.

FYI, there's already a FUSE implementation of file operations on a Nspire: https://github.com/tangrs/fuse-nspire . It needs to be paired with Vogtinator's fork https://github.com/Vogtinator/libnspire , which contains a number of important bugfixes for the original libnspire's poor reliability, and support for the CX II's native NNSE protocol (though the CX II can fall back to classic NavNet, as was recently discovered - that's what libti do). Using the libti stack instead of libnspire has a number of upsides, though. The main one, although it might not be of direct interest to you if you only have Nspire calculators, is the unified API for communicating with 4 series of calculators going nearly 30 years back, instead of a single series going back half of that. Also, libti isn't limited to file operations: you could technically implement a virtual filesystem to gather screenshots, send keys, receive calculator information from your Nspire calculators, or perform a number of other operations not supported by the Nspire series. And I'm all for both honing one's skills, and contributing bugfixes and improvements to libti ;)

[the-blank-x]

Well there goes 2-3 days of my life. Thanks anyway

[adriweb]

You should still publish your code somewhere :)

[debrouxl]

Indeed, you clearly reached a point of usability for some file operations, and there are good reasons to use libti* instead of any calculator series-specific library :)

[the-blank-x]

True, I may or may not work on it anyway, or maybe when I'm bored and/or want an excuse to try using FUSE.

If anyone's interested, here's the source code (expects https://github.com/debrouxl/tilibs/tree/experimental2 to be in thirdparty/tilibs with disable-asan.diff.gz applied)

[debrouxl]

A partial C++ wrapper for libti*... interesting :)

[the-blank-x]

I prefer writing wrappers in C++ since it lets me a bit more lazy about memory management, though I usually write them myself (unless if there are official, in repo ones) because I don't wanna bring more dependencies than necesary.