Richard Russell wrote:It can't behave "100% compatibly" because you still need to allocate more than 4 bytes of memory to hold your 'integer' variable. That's going to break some assumptions, for example that the memory address of B% is always four greater than the memory address of A% (you may argue that programs should not rely on that, but some do).

How, on a non-Beeb platform, do you even discover the address of an integer variable? The only way I can think of is via shenanigans using CALL, but those have to break compatability on a 64-bit architecture anyway.

In the specific case of allocating memory with DIM and then accessing it using indirection, why is anybody doing that in 2018 anyway?

Manipulating parts of a binary file format via OSGBPB? Marshalling arguments in and out of system calls? So far as I'm aware there's still no record/structure support in BBC BASIC.

This is supported, and has been for a long time, in BB4W (Windows), BBCSDL (Windows, Linux, Mac OS, Raspberry Pi, Android, iOS) and BASICPlus (RISC OS). Not in any variant of 6502 BASIC that I am aware of however, if you are still living in the stone age.

So far as I'm aware there's still no record/structure support in BBC BASIC.

I think your 'awareness' needs some revising then! Structures have been in 'my' BASICs for at least 15 years.

OK. If contiguity of the fixed-position integers really really matters, plan B is to lay them out such that all the 32-bit low words are packed together first, followed by all the 32-bit high words packed together.

Not in any variant of 6502 BASIC that I am aware of however, if you are still living in the stone age.

Personally, having used BASIC on the Beeb and gradually drifted to C on the Archimedes, for the past twenty years I've been using C++ and Python under Windows and Linux (with the occasional deviation into other OSes and bare metal). Stardot is an Acorn forum, and Acorn died 17 years ago, so I think it's to be expected that anyone here is indeed living in, as you put it, the stone age!

This also means it's more reasonable for me to focus on backwards compatability with 35-year-old language versions than it would be in most contexts.

So far as I'm aware there's still no record/structure support in BBC BASIC.

I think your 'awareness' needs some revising then! Structures have been in 'my' BASICs for at least 15 years.

OK. I missed that, because it's hidden in DIM and I looked for it by skimming the list of keywords. At first glance, there's no way to coerce an area of memory into being treated as a structure, though? So you couldn't use structures to pick apart data read from files or returned by foreign language API calls?

crj wrote:At first glance, there's no way to coerce an area of memory into being treated as a structure, though?

You can, otherwise structures would be considerably less useful, but it does mean using an indirection operator. To make it slightly nicer, there's a PROC_setptr in the supplied library 'dlglib.bbc' which you can use as follows:

Sorry, minor diversion to loop back to the Apple issue: did you consider just using TestFlight for distribution? The disadvantage is that it's a similar review process as for the App Store proper (albeit with relaxed stability and completeness requirements, speaking empirically), but the advantage is that you can then invite up to 10,000 testers just by adding their Apple-associated email accounts. No need manually to collect or to curate UDIDs, and a much higher limit.

The policy re: BASIC interpreters was relaxed in 2010 so I'm not sure approval would be as much of a hurdle as you fear, subject to capriciousness.

You seem already to support UIFileSharingEnabled; you should also consider LSSupportsOpeningDocumentsInPlace. The two together will make you launchable from the Files app much like a regular desktop experience, with the advantage for those of us that are fully in the Apple ecosystem that Files is backed by iCloud. So the filesystem you're launching from and writing to is remote and accessible from both iOS and macOS. At maximum laziness, I can just keep my BASIC documents on the desktop of my Mac, and also work on them on my iPhone, with automatic syncing. No tether required.

ThomasHarte wrote:did you consider just using TestFlight for distribution? The disadvantage is that it's a similar review process as for the App Store proper

The limit of 100 devices of each type for 'ad hoc' distribution is likely to be far greater than the demand (it certainly is at the moment) and the administrative overhead is minimal. I've also seen contradictory information on how long the different release types remain active, at least one site implying that ad hoc releases last longer than testflight releases before they expire. Do you know for sure?

The policy re: BASIC interpreters was relaxed in 2010

My understanding was that the requirement that output from a downloaded BASIC program occupy no more than 80% of the screen area was still current (I presume on the basis that Apple want it to be obvious that what the user is seeing is the output from the BASIC program rather than from the app itself). If so there's no way that BBC BASIC can meet it: fundamentally you cannot tell if what's on the screen is the output from a BASIC program or not.

You seem already to support UIFileSharingEnabled; you should also consider LSSupportsOpeningDocumentsInPlace

Will that work even when the 'document' (i.e. in this case a BASIC program) is in a binary tokenised format that is not displayable by a conventional text editor?

ThomasHarte wrote:You seem already to support UIFileSharingEnabled; you should also consider LSSupportsOpeningDocumentsInPlace.

I tried that today. The effect is indeed useful, but sadly it breaks the Custom URL Scheme (which BBC BASIC uses to allow a home-screen shortcut to run a specific BASIC program). This is too useful a feature to lose, so I've had to disable LSSupportsOpeningDocumentsInPlace again. It's not obvious why those features are incompatible, conceivably it could even be an iOS bug.

Richard Russell wrote:The limit of 100 devices of each type for 'ad hoc' distribution is likely to be far greater than the demand (it certainly is at the moment) and the administrative overhead is minimal.

Right, I've probably been overly-influenced by my experience of doing this for beta releases in larger companies; walking every potentially interested non-technical person through the process necessary to obtain their UDID can be painful and is usually time consuming.

Richard Russell wrote:I've also seen contradictory information on how long the different release types remain active, at least one site implying that ad hoc releases last longer than testflight releases before they expire. Do you know for sure?

If memory serves — though I'm not presently an iOS developer, and these things change all the time — TestFlight releases last for a fixed 60 days, whereas ad hoc builds last until the expiration of your current certificate, which is indeed usually further away.

Richard Russell wrote:My understanding was that the requirement that output from a downloaded BASIC program occupy no more than 80% of the screen area was still current (I presume on the basis that Apple want it to be obvious that what the user is seeing is the output from the BASIC program rather than from the app itself). If so there's no way that BBC BASIC can meet it: fundamentally you cannot tell if what's on the screen is the output from a BASIC program or not.

I wasn't aware of a formalised policy, so I think you're better-informed than I am here. Other than trying to keep a general awareness when I was a developer, my only substantial interaction with that was when launching a ZX Spectrum emulator in early 2010. At the time we were required to obstruct user access to BASIC, which is probably why the C64 emulator release from a few months later stuck in the memory.

Richard Russell wrote:

ThomasHarte wrote:You seem already to support UIFileSharingEnabled; you should also consider LSSupportsOpeningDocumentsInPlace.

I tried that today. The effect is indeed useful, but sadly it breaks the Custom URL Scheme (which BBC BASIC uses to allow a home-screen shortcut to run a specific BASIC program). This is too useful a feature to lose, so I've had to disable LSSupportsOpeningDocumentsInPlace again. It's not obvious why those features are incompatible, conceivably it could even be an iOS bug.

ThomasHarte wrote:If memory serves — though I'm not presently an iOS developer, and these things change all the time — TestFlight releases last for a fixed 60 days, whereas ad hoc builds last until the expiration of your current certificate, which is indeed usually further away

That's my understanding too, and since the certificate lasts for a whole year (most of which is still in the future) it's a very good reason to use the Ad-Hoc method rather than TestFlight! Issuing a new release annually to keep it working is a lot easier than having to do it every 60 days!