What I'm adding, and what I'm planning next...

[OpenXTalkPaul]

I was just poking around in old versions of LCC, as one might, and discovered that the old standalone builder in LCC 7.0 Linux-x64 supports building on Arm Linux.
So, I wonder if this can be bought up-to-date, and I wonder about incorporating that in OXT Lite.
It would be cool as we can then deploy for Raspberry PI's.

this-is-cool.png

As a side note, my god LCC 7.x is fast compared to LCC 9.x - the script editor absolutely knocks the spots off the one in LCC 9.x

That would be great if we could get an RPi arm and arm64 compiled engine based on v9 or at least v8. The last time someone built and released the Engine for RPi/Arm was v.7.x One user did report successfully compiling v8 for RPi/arm but they never released it to the public.

[richmond62]

OK, let's ask cheeky questions . . .

re ARM-Linux.

1. Would a version be taken up by Raspberry Pi users?

(might be informative to find about the LC uptake: the fact that development stopped on that version quite some time ago is . . .)

2. Do you envisage a 'horde' of ARM-Linux users wanting/needing OXT?

3. Are you only really interested in this as an intellectual exercise?

[richmond62]

Before the implementation of full Unicode compatibility in LiveCode 8.0
one had to work with SURROGATE PAIRS to access a lot of glyphs in higher Unicode slots:

"Surrogate pairs are character representations in source code that represent a single character that consists of a sequence of two Unicode values. In a coded pair, the first value is a high surrogate and the second is a low surrogate. A high surrogate is a character in the range U+D800 through U+DBFF."

As you can probably imagine this involved a lot more work in terms of finding those surrogate pairs and in terms of writing code.
-

SShot 2024-10-01 at 11.18.38.png (93.78 KiB) Viewed 1219 times

-
(Numbers must be entered in Decimal format).

Code: Select all

on mouseUp
   put fld "pNum"into peeNum
   if peeNum > 65535 then
   put trunc ((fld "pNum" - 65536)/1024 + 55296) into fld "pair1"
   put ((fld "pNum" - 65536) mod 1024 + 56320) into fld "pair2"
else
   answer "Unicode address is lower than 65536 so doesn't need surrogate pairs"
   put empty into fld "pNum"
   end if
end mouseUp

[richmond62]

At the same time the numToChar function was "shrunk" to work with the ASCII character set only, and numToCodePoint was introduced.

Unless you have a secret urge to write to your Mum in Sanskrit or Chinese this basically makes no difference.

[tperry2x]

re ARM-Linux.
1. Would a version be taken up by Raspberry Pi users?

That's the hope.

(might be informative to find about the LC uptake: the fact that development stopped on that version quite some time ago is . . .)

Well, probably doesn't make sense to them from a "business decision" - the same as dropping 32-bit support for MacOS which I reenabled. I don't care about "business decisions" as this ain't a business.

2. Do you envisage a 'horde' of ARM-Linux users wanting/needing OXT?

Again, would be nice. There have been lots of sales of Raspberry PIs, so potentially a huge market for OXT use.

oimg.png (58.78 KiB) Viewed 1210 times

3. Are you only really interested in this as an intellectual exercise?

I'm not sure I follow your meaning here. I'm interested in potentially getting more OXT and OXT Lite users on board if we had something that can develop for that platform. If you could build for it, then deploy your app to a Raspberry PI, it opens up a whole load of potential use cases - the whole 'smart things' / internet-of-things use case.

[richmond62]

If you could build for it, then deploy your app to a Raspberry PI, it opens up a whole load of potential use cases - the whole 'smart things' / internet-of-things use case.

Well, we seem to have 2 things here:

1. Running a version of OXT (Lite) on Raspberry Pi.

2. Building standalones for Raspberry Pi from OXT

(which would entail having that as a choice in the standalone builder settings on all platforms).

[richmond62]

There have been lots of sales of Raspberry PIs, so potentially a huge market

My first Q would be who is buying them: if the vast majority of buyers are schools 'fergettit' as the English and Scottish Education departments have fixated on programming enivronments/languages that are NOT 'us', and getting them to change their collective mind is about as easy as the proverbial camel through the eye of the needle.

[tperry2x]

1. Running a version of OXT (Lite) on Raspberry Pi.

That's a lot harder, and would require the entire rPI IDE and engine there to be updated. The source of that seems hard to find, to say the least.

2. Building standalones for Raspberry Pi from OXT

A lot easier (for 32-bit arm, and 64-bit arm would also run it), because I already have that standalone plucked from v7.0.0 of the LCC standalone builder. It's 'just' a matter of me re-enabling it in the same way I did with the MacOS X 32-bit builds (in theory). - Then you can build a 32-bit arm standalone on whatever platform OXT is running on.

[tperry2x]

My first Q would be who is buying them

There's an absolutely huge "Maker's" community - people who use single-board-computers for home automation, security cameras, personal projects, coding projects (outside of schools). Then there's behind the scenes in companies for manufacturing and automation processes. I've even seen them used in digital signage, and at trade exhibitions running all sorts of things from slideshows to robotic arms. Even various coffee shops & restaurants have used them as a point of sale ordering system, and displaying menus.

There's absolutely loads of uses for them.

[richmond62]

OK: I'm with you re potential users.

Now, the next 'poisonous' question [watch out, there's a self-appointed Devil's advocate about]:

If I am developing a 'something' for Raspberry Pi on my "juicy Lucy Mac" with 8 Gigs of RAM, a dirty-great-sexy processor and so on, how am I going to work out when my standalone I am about to hive off from my source stack is not going to be dead in the water when I attempt to run the thing on a Raspberry Pi thing?

Certainly I feel that, on selecting Raspberry Pi [as opposed to 'plain, vanilla' ARM-Linux 32-bit] there should be a series of fairly aggressive flags that say something like "No chance, Chum: this thing will exceed all the capabilities of yer Raspberry Flan, and will NOT run!" when the limitations ahve been exceeded.

[richmond62]

AND, like it or not (and I don't as I am personally not very keen on Communist China and its racist stuff with the Uighers and what it is doing in Hong Kong), you probably will have to find a way to 'shoehorn' the Unicode guff into any build for Raspberry Pi because we all know where the BIG market is, and WHO constitute about 50% of the world's population. Oh, and I have a soft spot for Taiwan.

[tperry2x]

2. Building standalones for Raspberry Pi from OXT
(which would entail having that as a choice in the standalone builder settings on all platforms).

You say that, but it's only possible to build an iOS standalone on the Mac version of LCC/OXT. (Because it hooks into needing xCode installed, so MacOS only). - it's not strictly possible to deploy to all platforms with all versions of the IDE in the same manner currently.

[richmond62]

to build an iOS standalone on the Mac version of LCC/OXT

Indeed: and extremely difficult at that.

Personally I would suggest that OXT DROPS the mobile builds possibility as they involve more work than they are worth: an expansion into more desktop systems MIGHT attract some positive attention: with, obviously, Raspberry Pi being top of the list.

[tperry2x]

If I am developing a 'something' for Raspberry Pi on my "juicy Lucy Mac" with 8 Gigs of RAM, a dirty-great-sexy processor and so on, how am I going to work out when my standalone I am about to hive off from my source stack is not going to be dead in the water when I attempt to run the thing on a Raspberry Pi thing?

Optimisation - keeping that in mind when writing any script, making it as lean and as fast as you can - that ensures that it can run on meagre hardware. Also, there's no telling what system any end-user will have, so optimising things down for the slowest use case imaginable is always good practice.

Certainly I feel that, on selecting Raspberry Pi [as opposed to 'plain, vanilla' ARM-Linux 32-bit] there should be a series of fairly aggressive flags that say something like "No chance, Chum: this thing will exceed all the capabilities of yer Raspberry Flan, and will NOT run!" when the limitations ahve been exceeded.

Well, true - I mean if you try and call up a 1200dpi file which is 12000px x 9050 pixels on a pi - it'll choke. It's about being realistic. The same as if you made a stack, then expect MacOS 10.9 users to run it with their 2 GBS of memory on their Intel Core 2 duos (early MBA, old iMacs, Mac Minis etc) - you could also put in a system check at card 1 of any stack to check what resources were available. There's lots of ways to do that kind of thing of course. You can query most info from various shell commands to ascertain if something is going to run acceptably or not.

[tperry2x]

would suggest that OXT DROPS the mobile builds possibility as they involve more work than they are worth...

They do require a lot of work to bring them up to speed. Currently I think we are iOS 14 as a maximum target. (No concept of iPadOS for example) - Android is much the same (Android 10 Q) whereas Android 15 is current, with Android 16 on the imminent horizon.

I don't know if they should be dropped - after all, being able to create an iOS app with the IDE is currently the only way to produce something with ARM code that will natively run on Arm Macs. More and more things are going mobile-only (or at least mobile-first), and to get rid of any options seems like a bit of an own-goal in my opinion.

Yes, Apple has a stranglehold on iOS app submission and won't permit iOS apps made with LCC/OXT into the app stores, but it can still be side-loaded. Also the same is possible with Android APKs too.

[tperry2x]

Speaking of which, spent some time today making a few little changes to the "revsaveasandroidstandalone.livecodescript" stack, and it now builds android apk standalones with a lot less grumbling:

android.png (34.87 KiB) Viewed 1154 times

oxt-setting.png (60.76 KiB) Viewed 1154 times

mac-android-build.jpg (542.8 KiB) Viewed 1028 times

[OpenXTalkPaul]

I have LC Comunnity built .Apks built for my old, old, old phone, targeting 4.3 ICS, run quite well side-loaded to my Android 10 Sony TV! It shouldn't be hard to update the build scripts to allow newer Android ADK.

Deploy standalone for RPi would need to force saving the stack to version 7 stack format, which would removed any placed widgets. If the stack works fine after being saved as v7 stack then it should work fine on an RPi (within reason, it is very modest hardware).

RPi are great for single purpose computing. As Tom mentioned RPi can easily be sued for digital signage, attached to any HDTV via HDMI and powered by the TV's USB port. Install Batocera Linux and turn anything with an HDMI port into a game console! Or LibreELEC and turn it into a streaming media box.
The v7 IDE runs on RPi, so that's better than nothing!

[tperry2x]

One step forward, two steps back.

I can get the Armv6-hf (Raspberry Pi) option to show up - that's kind of easy, because as soon as the standalone is added to the "Runtime" folder - then it shows up. Great, and you'd think we were on the way there...

nothing-is-ever-simple.png (59.79 KiB) Viewed 941 times

This is because the standalone builder (right at the end of the build process), after it's gathered everything, does the last bit of processing inside the engine.

stymied.png (22.42 KiB) Viewed 941 times

Code: Select all

_internal deploy linux pDeployInfo

So that's a pain. The function for that in the engine has obviously changed between v7 and v9 of the engine.

Option 1: copy the function of the v7 engine out, into the v9 one, calling it legacy_deploy
So it can run in it's own function. (which means an entire recompile).

Option 2: abstract it all away so it runs as a separate C++ legacy_deploy library

Option 3: Ask someone nicely to recompile & update the RPI Runtime (so that it functions with the LCC 9.x engine).
(where would I find the source for the RPI standalone build?)
As has been mentioned before, this was only a personal project of a LC staff member and quickly became unstable due to OS updates. (sounds familiar!)
The only trace I can find of it all now is:
LiveCodeCommunityInstaller-7_0_0-Linux.rpi
LiveCodeCommunityInstaller-7_0_1-Linux.rpi
LiveCodeCommunityInstaller-7_0_3-Linux.rpi
LiveCodeCommunityInstaller-7_0_4-Linux.rpi
There's no source to go with any of that, so the code that was used to create the Raspberry PI runtime isn't at all "open source" - unless someone can find an archived copy somewhere?

Option 4: Forget about the whole Raspberry PI build thing.
(Not the option I want).

edit: looking further into this, because of a header mismatch (if I'm reading it correctly), that's why it throws the error:

error-in-engine.png (76.79 KiB) Viewed 906 times

This probably means the whole rPi build target thing is a bit dead without someone willing to re-write the Arm runtime.
Such a shame, as I think it would have made a very worthwhile addition. I wonder which staff member at LC had this as their personal project. Does that staff member still work there? If not, are they reading this? (yeah, I know - I'm grasping at straws now!)

[mdm]

I wonder which staff member at LC had this as their personal project. Does that staff member still work there? If not, are they reading this? (yeah, I know - I'm grasping at straws now!)

In theory, Fraser Gordon would be your guy.
http://newsletters.livecode.com/decembe ... tter1.html
http://newsletters.livecode.com/septemb ... tter2.html
https://forums.livecode.com/viewtopic.php?t=26223

He now should be in Toronto or near there:
https://ca.linkedin.com/in/fraserjgordon

You may be aware that you are not alone in your cravings, some people present here had them too
https://forums.livecode.com/viewtopic.php?f=76&t=27912
(and some not present anymore sadly:)
https://forums.livecode.com/viewtopic.php?f=76&t=19248

Etc.

This topic is really blowing this already overexpanded thread out of any proportion. Someone has an axe?

[tperry2x]

I have LC Community built .apks built for my old, old, old phone, targeting 4.3 ICS, run quite well side-loaded to my Android 10 Sony TV! It shouldn't be hard to update the build scripts to allow newer Android SDK.

That would be nice - at the moment, the build scripts have to use v8 of the SDK as you know.

Perhaps someone can point this poor fellow (David) from here:
https://forums.livecode.com/viewtopic.php?f=122&t=39368

over to here.

And then, perhaps over to here.
:poached: