Post Reply 
DB48X: HP48-like RPL implementation for DM42
Yesterday, 10:42 PM
Post: #498
RE: DB48X: HP48-like RPL implementation for DM42
(12-03-2024 07:13 PM)Orome Wrote:  
(12-03-2024 05:56 PM)Orome Wrote:  Yeah I've got that and it works, but is there a way to make it the default location for both:
  1. "SOME.FILE" RCL and VAL "SOME.FILE" STO, and
  2. SETUP > (3) State >
For A it seems that there's no way for those commands to operate on anything other than the local data directory, so to exchange between macOS and iOS some moving or copying would be needed.

For B, as near as I can tell:
  1. on macOS, I can just load and save (including SAVE) state directly to iCloud (or anywhere really); but
  2. on iOS, it is not possible to load ("Operation not permitted") from iCloud (access to iCloud is apparently forbidden)
so on iOS it would be necessary to copy or between iCloud and the local state directory.

Is that right, or am I missing something?

There is currently no way to change the default location for saving / restoring, mostly because the DM42/DM32 have very small disks with only one possible location. On iOS, the recent places can serve as a quick way to get to some other location.

Unfortunately, iOS has two very specific notions that do not play well with traditional filesystem semantics: application sandboxing and iCloud. Application sandboxing restricts the files that your application can touch. iCloud means some documents show up in the filesystem but are not actually there, they are proxies for something that needs to be downloaded before being used.

The semantics for these features are complicated. Most developers hide behind a higher-level layer, like "documents", that manage this somewhat transparently. Even so, this entire subsystem has been bogus since it was introduced (from memory circa 10.7) to replace the old "save / save as" (now instead of "save as", you have "duplicate"). For example, for many major releases, opening two documents in Preview or any application using the new semantics, and then saving one of them with the name of the other would lock up the application. In short, the system is difficult enough to master that even Apple developers took several major iterations of OSX to get it half right.

Now, don't get me wrong, the system is also very powerful, with support for multiple version, transparent synchronization of documents across machines, and so on. So it goes way beyond the traditional Unix or MS-DOS filesystem.

But for an application like DB50x on iOS, which only needs to save and load files by name, this makes things complicated enough that, at least for the moment, it mysteriously fails in ways that I have yet to understand.

Among the problems that I am aware of:

1) I have not found a way to use the same directory across variants of the application. This is probably only a concern to me, but iOS treats DB48x and DB50x as two entirely distinct applications, even if they share the same file types. According to the documentation, one application should be able to read the documents from the other, but so far, it does not work.

2) The data directories sometimes disappear until you reboot your device. This notably happens when you upgrade (or, in my case, when I install a new version, but not every time).

3) iCloud directories created by one version of the application may become inaccessible by the next version of the same application (this is the "operation not permitted" you saw). What is really weird about this one is that if I start an iPhone simulator from scratch and connect it to my iCloud account, then I can access the directory, but not if I reuse a simulator where the previous version had been installed.

So in short, at the moment, iCloud support is very theoretical. When it works, it works well and you can sync your state files across multiple devices (even an iPhone and iPad in my case), but it sometimes goes boom for reasons that I don't understand yet. Sometimes, just restarting the iPhone fixes the problem, but it seems absolutely insane that you would have to do that.

I'm doing something wrong in the code, but I don't know what yet.

DB48X,HP,me
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
DB48X v0.4.8 is out - c3d - 10-22-2023, 11:31 PM
Release v0.5.0: Statistics and flags - c3d - 11-20-2023, 08:57 AM
v0.6.5: Minor bug fixes - c3d - 02-11-2024, 11:23 PM
Release 0.7.1 "Whip" - Bug fixes - c3d - 03-04-2024, 12:46 AM
DB48X v0.7.4 release is out - c3d - 04-14-2024, 03:05 PM
DB48X v0.7.6: Solving menu - c3d - 05-13-2024, 12:04 AM
DB48X v0.7.7: Units in solver - c3d - 06-02-2024, 11:36 PM
v0.7.10 - Interactive stack - c3d - 07-14-2024, 11:31 PM
DB48X v0.7.13 is out - c3d - 08-05-2024, 07:31 AM
DB48X v0.7.15 - c3d - 08-25-2024, 08:45 PM
DB48X v0.7.16 - c3d - 09-02-2024, 01:36 AM
DOSUBS command - grbrum - 09-04-2024, 03:37 PM
v0.7.18 - APPLY, SUBST, WHERE - c3d - 09-15-2024, 11:58 PM
Program Editing Question - spiff72 - 09-16-2024, 03:27 PM
press 2 simultaneous buttons? - grbrum - 09-30-2024, 09:01 PM
CST Custom Menu - grbrum - 10-04-2024, 05:00 AM
v0.8.2: Assignments, Custom menu - c3d - 10-21-2024, 05:49 AM
CST - grbrum - 11-05-2024, 08:07 PM
Stuttgart video - c3d - 11-07-2024, 08:22 PM
Long Name Menus - usability - grbrum - 11-08-2024, 07:47 PM
Release v0.8.5: Keyboard fixes - c3d - 11-12-2024, 01:05 AM
CONVERT bug - grbrum - 11-12-2024, 07:44 PM
Christmas wishlist is open - c3d - 12-02-2024, 07:09 PM
DB48X/50X CATALOG 'behaviour' - n1msr - 12-03-2024, 10:24 AM
RE: DB48X: HP48-like RPL implementation for DM42 - c3d - Yesterday 10:42 PM
DB48x v0.8.8 - Power usage reduction - c3d - 12-08-2024, 11:40 PM



User(s) browsing this thread: gentzel, 5 Guest(s)