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

[tperry2x]

Please try the sample standalone I've included in that link.
It's not as simple as supplying a new stack. The changes aren't in a new stack, but located in behaviour scripts, rev ide stacks, and a livecodescript stack. There's also a pre-patched app container for MacOS - all that has to live in specific places. When I know the standalone with a menu works on Sonoma, I'll base v1.08 of OXT Lite around these changes.

[richmond62]

Please try the sample standalone I've included in that link.

That is what I just did.

Where can I obtain the standalone builder with the 'Sonoma' option?

[richmond62]

Aaaaaaaaah:
-

SShot 2024-08-26 at 14.47.26.png (132.49 KiB) Viewed 3445 times

-
After fooling around in the security settings . . .

[tperry2x]

That is what I just did.

Just seen your screenshot. That's great.

Where can I obtain the standalone builder with the 'Sonoma' option?

I haven't uploaded those changes yet, as they are unfinished, but the changes are spread across these files:

changes.png (39.59 KiB) Viewed 3442 times

[tperry2x]

I now need to put in a warning about preloading any graphics first if you are using this sonoma patch.
Just trying to find the method Paul mentioned a while back...
edit: think I found it, so added link - "Prepare image"...

[richmond62]

Mind you, I cannot get OXT Lite 1.07 to be accepted by MacOS 15 at all.

It runs OXT Lite 1.06 because I installed that BEFORE moving from Sonoma to the Sequoia beta.

[tperry2x]

Mind you, I cannot get OXT Lite 1.07 to be accepted by MacOS 15 at all.

It runs OXT Lite 1.06 because I installed that BEFORE moving from Sonoma to the Sequoia beta.

I think the word 'Beta' is key there. I'd ask you all the inevitable normal questions about making sure apps are allowed from anywhere, and all that jazz - but MacOS just seems to do what it feels like.

[richmond62]

Thought I would try this in the Terminal:

Code: Select all

% sudo spctl --master-disable
Password:
Globally disabling the assessment system needs to be confirmed in System Settings.

This allows you to accept software from anywhere in the Security section of the system settings.

Still NOT allowing me to run OXT Lite 1.07, so trying a restart.

System NOT rebooting.

Rebooting with the 'R' depressed (not sure what told me to do that): booted.

No joy with OXT Lite 1.07.

Deleted and redownloading . . . bonkers or what?

Reinstalling . . .

OXT Lite loads and runs.

Sucks to Apple!

[tperry2x]

edit: think I found it, so added link - "Prepare image"...

Quoted myself here, but just reading up on 'Prepare image' as it's a new one on me:
------------------------------------------------
Prepare Image Preloads an image into memory.

Example usage:
prepare image "myImage"
prepare image file "/Disk/Folder/logo.jpg"

Description:
Use the prepare image command to speed up execution when showing image data.
Use the prepare image command to preload an image at some time before it is needed. Then access the image and display it as needed on your stack. Since the image is already cached into memory, it displays instantly.
------------------------------------------------

So, perhaps I can make an informative dialog that appears when the 'Sonoma test' button is pressed in the standalone options.

dialog.png (46.8 KiB) Viewed 3408 times

Edit: I'll probably change "utilise" to "use" to get around the English-UK and English-US localisation issue.

[mwieder]

Tom-

shouldn't that section read

Code: Select all

         case "MacOSX"
         case "MacOSX x86-32"
            // SN-2015-07-09: [[ StandaloneDeployment ]] Gypified Standalone-<edition>.app building does not
            //  allow to create broken applications, so that the executable file in it bears the edition.
            put the upper of char 1 of tEdition into char 1 of tEdition
            return tRuntimePath & "/Mac OS X/x86-32/Standalone.app/Contents/MacOS/Standalone-" & tEdition
            break
         case "MacOSX x86-64"
         case "MacOSX arm64"
            return tRuntimePath & "/Mac OS X/x86-64/Standalone.app/Contents/MacOS/Standalone-" & tEdition
            break

because otherwise you're just building the 32-bit version anyway?

[tperry2x]

Tom-

shouldn't that section read

Code: Select all

         case "MacOSX"
         case "MacOSX x86-32"
            // SN-2015-07-09: [[ StandaloneDeployment ]] Gypified Standalone-<edition>.app building does not
            //  allow to create broken applications, so that the executable file in it bears the edition.
            put the upper of char 1 of tEdition into char 1 of tEdition
            return tRuntimePath & "/Mac OS X/x86-32/Standalone.app/Contents/MacOS/Standalone-" & tEdition
            break
         case "MacOSX x86-64"
         case "MacOSX arm64"
            return tRuntimePath & "/Mac OS X/x86-64/Standalone.app/Contents/MacOS/Standalone-" & tEdition
            break

because otherwise you're just building the 32-bit version anyway?

I don't quite understand what you mean here.
In the post further up, you'll see that the case statement for the "MacOSX x86-64" is filled in and has it's own statement:

filled-in.png (19.3 KiB) Viewed 3405 times

I'm not sure why you'd want to remove that from your quoted example?

You also have a case statement for "MacOSX arm64" which I don't have. In your example, surely the x86-64 and the arm64 case statements incorrectly equate to the same thing, as you have no break between them?
I'm assuming you are working off some github version or repository for this? - my apologies if that's the case, as I'm not using github.

Anyway, in my testing, the case statement runs if a x64 build is chosen, so no - I can confirm it's not just building the 32-bit version regardless.
I've since expanded upon that anyway to also use the sonoma patch if that's selected too. I can build x32, x64 and x64 sonoma-patched standalones as required.

Edit: In the older versions of this - possibly before I started messing about with a 'sonoma patch' in the standalone builder, I think I know why only a 32-bit path was calculated in earlier versions - and why in earlier versions of this stack, there wasn't a x64 version mentioned. At one point, what was marked up as 32-bit was in fact a universal binary (a fat binary). Then lipo would actually split the universal version into 32 or 64 bit as needed, and only keep what the user required. Hence why only one path was calculated, from what I can tell.
(This actually makes perfect sense, as while lipo can split a fat binary down to a slim x32 or slim x64, it can't combine a slim x32 or x64 into a fat binary if the user has chosen a universal build intentionally. You need to start with a fat binary in all instances if that was the selection the user had chosen). - if that makes sense...
Either way, a slim x32 and a slim x64 build was possible using that method, it was just handled a bit differently. Essentially lipo is now getting fed a x64 bit target anyway, but stripping away any x32 bit code just in case.

[mwieder]

my apologies if that's the case, as I'm not using github

Right. I'm outa here then. Have fun.

[tperry2x]

Right. I'm outa here then. Have fun.

That wasn't a negative directed at you, just that I don't get on with github, that's all. Didn't mean to offend, so my apologies if I did somehow.

I've never got on with github, and despite trying and trying, it just doesn't gel with me. I find it's making extra work of tracking changes (a needlessly complex solution to a problem), - but I'm old-skool and track what I've changed - when and where - manually. I always have worked this way, before github even existed.

Normally that manual approach wouldn't work for anything collaborative, which I get - but since nobody has got the C++ engine fixed, all changes are in script in the IDE stacks anyway - and anyone can see those changes live in the IDE as long as they are on the most recent build.

Edit: funny really, when you consider that I probably am working from GitHub code inadvertently on this occasion, as Paul shared that code with me here, which is presumably from his repo (yes, it is, line 3054 as it turns out).

[tperry2x]

If everyone likes the look of that dialog, and the wording, then I'll roll that change into v1.08, with the word 'utilise' changed to 'use'.

[mwieder]

since nobody has got the C++ engine fixed,

Most of the changes I've made on my end have been fixes to the engine files, but some of those require IDE changes to be effective. If you're not going to do things the easy way then you can diff the files from my repo. But I've changed some 300 or so files in there so hopefully you've got some quick way of automating the diffs.

[tperry2x]

If you're not going to do things the easy way then you can diff the files from my repo.

Yes, I have an automated script to do that if need be, that's if github doesn't reach a timeout error "RPC failed; transfer closed with outstanding read data remaining". - which is far from 'easy'.

The 'easy way' is always a matter of opinion of course. What works for one person, doesn't work for everyone. And vice versa.

...But I've changed some 300 or so files in there so hopefully you've got some quick way of automating the diffs.

Again, yes I do have - outside of github using a recursive diff compare.

How do you get around not being able to edit .rev and .livecode stack files in github for example?

Also, not meaning to aggravate you further, but how would anyone know which 300+ files you'd changed and where? - can you just download an archive of ONLY the recent changes, from a given date?.... I already know that the answer to this is no, which is another reason I don't use it - it takes too long to go through finding what has changed recently, instead of downloading a zip file with changes.

What about if I want to see the version history in github? Do I have to go through the 'releases' page, of which more often than not, there isn't one.

What about if I want to undo a change?

If I add a file to a repository via a browser, the file can be no larger than 25 MB
(!)

It's up to you how you work, I'm not telling you NOT to use github, just that I don't get on with it that's all. No offence implied.

[OpenXTalkPaul]

I've since expanded upon that anyway to also use the sonoma patch if that's selected too. I can build x32, x64 and x64 sonoma-patched standalones as required.

Edit: In the older versions of this - possibly before I started messing about with a 'sonoma patch' in the standalone builder, I think I know why only a 32-bit path was calculated in earlier versions - and why in earlier versions of this stack, there wasn't a x64 version mentioned. At one point, what was marked up as 32-bit was in fact a universal binary (a fat binary). Then lipo would actually split the universal version into 32 or 64 bit as needed, and only keep what the user required. Hence why only one path was calculated, from what I can tell.
(This actually makes perfect sense, as while lipo can split a fat binary down to a slim x32 or slim x64, it can't combine a slim x32 or x64 into a fat binary if the user has chosen a universal build intentionally. You need to start with a fat binary in all instances if that was the selection the user had chosen). - if that makes sense...
Either way, a slim x32 and a slim x64 build was possible using that method, it was just handled a bit differently. Essentially lipo is now getting fed a x64 bit target anyway, but stripping away any x32 bit code just in case.

Thanks Tom! Once that is ready, I'll test out that 'prepare image' fix theory.

Correct, this is the way the 'FAT' binary building for macOS has worked in Standalone Builder, which included at one time PPC+x86-32 'Universal" binaries (supported in macOS X 10.4.11 though 10.6.8).

[mwieder]

Also, not meaning to aggravate you further, but how would anyone know which 300+ files you'd changed and where? - can you just download an archive of ONLY the recent changes, from a given date?.... I already know that the answer to this is no, which is another reason I don't use it - it takes too long to go through finding what has changed recently, instead of downloading a zip file with changes.

Dude... that's exactly what git / github is for. Only have to download / upload the deltas.
And gitk (built into git) gives you a visual glimpse into the changes historically.

[tperry2x]

Only have to download / upload the deltas.

Deltas? eh?
What the heck are 'Deltas'.
This is what I mean - why over complicate something that should be simple with extra jargon. We already have a word for that. It's called 'changes'.

Still no clearer:

still-no-clearer.png (179.91 KiB) Viewed 3372 times

And gitk (built into git) gives you a visual glimpse into the changes historically.

Sounds good, how do you access that?

I still can't even work out how to download a folder?

download-a-folder.png (95.81 KiB) Viewed 3358 times

The more I read about github, the more it induces a lasting headache and I actually feel sick. I'm probably trying to 'fight it' / try and make sense of it by rationalising it, but I just can't.

If nothing else, just find my ineptitude of using github funny - but please don't worry about it, and don't read anything else into it - I'm certainly not having a go at you for using it.

Dealing with up-to-date changes (as I like to call them) :

If you are uncertain that you are dealing with my most recent 'commit' (if that's correct? or is it a delta? Or is it a diff? Or a pack?... and what are branches?)
[my most up to date change, in english], then as long as you've checked for updates - then you are dealing with my most recent changes. Then, if you do change something, and it works - please share on here because it benefits everyone. That way we can have a poke about with the changes and tweak anything, as people might want to modify it before it goes live. This way, you don't need to be able to code anything to suggest a change, it might be just a visual design adjustment - which is yet another advantage over the github-code-only approach.

And of course, genuine users registering on here to suggest a change - and get involved, playing an active part in OXT's development is what this is all about.

That was another reason of me bringing back updates to the IDE, so that we are all in sync. Incidentally - if anyone else wanted to take up the reigns of this project, or make a new 'fork' of it, all they have to do is download the current version - and modify from there. A single file to download, so as far as I can tell, that's nice and easy.

[mwieder]

OK - let's try this again...

Deltas are diffs. Git calculates what's changed and sends just the changes. When you pull the latest changes from github what you get are just the changes, and git incorporates those changes to bring your local copy up to date. It's quick.

Once you're set up:
$> git push # sends just the diffs up to github
$> git pull # figures out what diffs you don't already have and brings them in

mwieder wrote: ↑Mon Aug 26, 2024 1:37 pm
And gitk (built into git) gives you a visual glimpse into the changes historically.
Sounds good, how do you access that?

$> gitk

Then, if you do change something, and it works - please share on here because it benefits everyone.

OK - here's a start: I see you've made changes to the revstandalonesettings stack. Here's mine - feel free to add your changes and post it back.