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

[richmond62]

Well, I am not unduly fussed by an extra 49 seconds as, at present at least, OXT Lite 1.07 takes 3 times longer than LC 963 to boot up on MacOS 12: although, as my personal synapses don't fire "that fast" it really doesn't fuss me.

[tperry2x]

Well, I am not unduly fussed by an extra 49 seconds as, at present at least, OXT Lite 1.07 takes 3 times longer than LC 963 to boot up on MacOS 12: although, as my personal synapses don't fire "that fast" it really doesn't fuss me.

That is excessive though. I mean, the IDE launches in 5 seconds flat on linux - on a modest i5 4th gen processor here.
On my MacBook Air, running Catalina, the IDE is slower to launch - but it's all up and running in approx 8 to 10 seconds (and that's a 2012 MacBook Air).
On my Windows 10 test PC, that's an HP with an i3 processor. Again, the IDE is up and running in under 10 seconds.

We are talking out of date hardware here, so I'm wondering why it's so slow for you.
Okay, on my main linux box - the IDE is open in 3 seconds, but that's got a more modern i7 20 core chipset.

I'd expect anyone on an Apple ARM chipset, using Rosetta 2 could probably open the IDE faster than even that.

[richmond62]

OK: that was the first boot up: now it is taking about 60 seconds.

On MacOS 15 it takes about 30 seconds.

Going to visit my Mother (back on 14th August) so Xubuntu 64-bit only for the duration.

[tperry2x]

So why is it so slow? Silly question, but are you running off an SSD or spinning HDD disk?
In 30 seconds, I could spin up a whole VM on any of these machines and probably have OXT Lite loaded.

[mwieder]

OK - I'm confused between OXT and OXT Lite now. Obviously the pull requests there are intended for OXT and may or may not apply to OXT Lite. OXT Lite does *not* take 49 seconds to load on my linux box - more like 5 seconds. Now I'll have to hunt down a copy of OXT and try that out. Some day.

[mwieder]

...and why the hell are we diverging here? Can't we cross-pollinate and have a single goal to aim for?

[overclockedmind]

I don't mean to interrupt or intercede, but the main idea is that:

1) Paul is adding additional functionality, and that's fine. That's OXT (DPE.)
2) Terry (tperry2x) is more focused on fixing bugs, and minimalism.
3) When either "camp" has an idea that should apply to both, they're free to "borrow" from each other, as both are OSS projects.
4) Anyone is free to correct me, if I have been inaccurate.

[tperry2x]

That's pretty much it. OXT Lite is about fixing those show stopping bugs that aren't in the engine, but are annoying. It's more like a test-bed for the DPE version - and I'll defer to Paul if he wants to include any of those, that's up to him.
As per the OpenXTalk main page:

[OXT Lite] is being considered as bit of a test bed for changes to the IDE, some possibly added to OXT DPE at a future time.

I'm not really adding loads of new features, new libraries and such - I'm more concerned with getting the IDE working as you'd expect it to. If that entails rewriting the dictionary (even if that's a large change) then so be it. In the name of functionality.

The DPE edition has a lot more capabilities, and bells-and-whistles than OXT Lite will have. We each have our own set of goals, but ultimately we both want things to work. (Is that a bit too zen?)

[tperry2x]

Added the ability for the text-version of the dictionary to read glossary terms. (no unsightly | characters)

scrn.png (57.5 KiB) Viewed 2274 times

Should take you to this build:

202408241822.png (13.59 KiB) Viewed 2274 times

[richmond62]

Erm, well, sort of:
-

Screenshot 2024-08-24 at 20.55.58.png (57.19 KiB) Viewed 2270 times

-
The engine (macOS 12) seems not to be 9.7

[tperry2x]

The engine (macOS 12) seems not to be 9.7

Yes, as mentioned - I can't compile the engine for MacOS or Windows. so MacOS and Windows users are 'stuck' on an older engine.

[richmond62]

Duly noted.

[OpenXTalkPaul]

The engine (macOS 12) seems not to be 9.7

Yes, as mentioned - I can't compile the engine for MacOS or Windows. so MacOS and Windows users are 'stuck' on an older engine.

Can we use the macOS12/13 patched binary for the IDE but have it as a deploy option (noting possible image corruption) for standalone building.

Also, is there still an issue with windowShape in standalones on macOS > 10.14 or 11? I have a stack that I actually uses it (my Virtual MIDI Bass Guitar stack), but the standalone didn't have the windowShape when I ran it on Sonoma the other day. I thought I fixed that, but I can't remember if I added that fix to this particular standalone or not. The workaround for that problem IIRC was that when running as a standalone on macOS > 10.14, you must re-apply the windowShape on preOpenStack before anything gets rendered on screen.

[richmond62]

I used windowShape for the first time in 2001 (admittedly thinking that it was a bit childish and a waste of tome), and the very few times I have used it (keeping tinies amused/focussed in progging classes) I have always done the windiwShapeThing in an openStack statement: so I don't see where there might be a bug.

[tperry2x]

Can we use the macOS12/13 patched binary for the IDE...

Yes, this is in place already. Weirdly, it plays nicely with Sonoma. The issue with menubars only seems to raise itself in standalones.

...but have it as a deploy option (noting possible image corruption) for standalone building.

I'd love to. The question is how.
I can get the option to appear in the standalone builder, by simply replacing the attached file (experimental, make a backup before you replace anything), but of course it doesn't do anything differently because I don't know how to link it up.
It's a bit of a mystery.

where.png (159.85 KiB) Viewed 2008 times

[OpenXTalkPaul]

Can we use the macOS12/13 patched binary for the IDE...

Yes, this is in place already. Weirdly, it plays nicely with Sonoma. The issue with menubars only seems to raise itself in standalones.

...but have it as a deploy option (noting possible image corruption) for standalone building.

I'd love to. The question is how.
I can get the option to appear in the standalone builder, by simply replacing the attached file (experimental, make a backup before you replace anything), but of course it doesn't do anything differently because I don't know how to link it up.
It's a bit of a mystery.

where.png

Oh it's in all in the revsblibrary.livecodescript I believe, that's where I added back in the 32bit right below the stubs leftover from where PowerPC Building script was:

In my current build script I have a handler that starts at line 3029:

Code: Select all

function revSBEnginePath pPlatform
   local tEdition
   put the editionType into tEdition
   // 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.
   if tEdition is not "community" then
      put "Commercial" into tEdition
   end if
   
   -- MW-2013-06-13: [[ CloneAndRun ]] If not installed, then fetch the engine locally.
   if revEnvironmentIsInstalled() then
      # MW-2009-06-24: For Mac OS X, engine source is two lines, first is PPC (if any), second
      #   is x86 (if any). Both implies universal build.
      -- MM-2014-03-21: [[ PPC Support Dropped ]] We now only support intel Mac builds. Assume all mac builds to be intel.
      local tRuntimePath
      put revEnvironmentRuntimePath() into tRuntimePath
      switch pPlatform
         case "MacOSX"
         case "MacOSX PowerPC-32"
         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-Community" -- & tEdition
            break
         case "MacOSX x86-64"
            // 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-64/Standalone.app/Contents/MacOS/Standalone-Community" --  & tEdition
            break
         case "Windows"
            return tRuntimePath & "/Windows/x86-32/Standalone"
            break
         case "Windows x86-64"
            return tRuntimePath & "/Windows/x86-64/Standalone"
            break
         case "Linux"
            return tRuntimePath & "/Linux/x86-32/Standalone"
            break
            -- MW-2013-11-06: [[ LinuxX64 ]] Compute the correct path for 64-bit linux.
         case "Linux x64"
            return tRuntimePath & "/Linux/x86-64/Standalone"
            break
            -- FG-2014-08-19: [[ RPi ]] Compute the correct path for ARMv6 Linux
         case "Linux armv6-hf"
            return tRuntimePath & "/Linux/armv6-hf/Standalone"
            break
         default
            return "error"
            break
      end switch
   else
      -- Make sure the platform is correct
      // SN-2015-05-15: [[ DeployAllPlatforms ]] Allow the deployment to happen
      //  for another platform, from the repository.
      local tBinariesPath
      
      if pPlatform contains "MacOSX" and the platform is not "macos" or \
            pPlatform contains "Linux" and the platform is not "linux" or \
            pPlatform is "Windows" and the platform is not "win32" then
         put revEnvironmentNonNativeBinariesPath(pPlatform) into tBinariesPath
      else
         put revEnvironmentBinariesPath() into tBinariesPath
      end if
      
      switch word 1 of pPlatform
         case "MacOSX"
            put the upper of char 1 of tEdition into char 1 of tEdition
            return tBinariesPath & "/Standalone-" & tEdition & ".app/Contents/MacOS/Standalone-" & tEdition
            break;
         case "Windows"
            return tBinariesPath & slash & "standalone-" & tEdition & ".exe"
            break
         case "Linux"
            return tBinariesPath & slash & "standalone-" & toLower(tEdition)
            break
         default
            return empty
            break
      end switch
   end if
end revSBEnginePath

There may have been some additional scripts added/changed, like in the Standalone Settings UI stack too, but this handler above sets up the file paths to the standalone binaries corresponding to the SB deploy options.

[tperry2x]

Oh it's in all in the revsblibrary.livecodescript I believe, that's where I added back in the 32bit right below the stubs leftover from where PowerPC Building script was

Okay, thanks. Looking at that, I can see only the following was changed:

preview.png (121.65 KiB) Viewed 1903 times

changes.pdf

(30 KiB) Downloaded 65 times

There may have been some additional scripts added/changed, like in the Standalone Settings UI stack too, but this handler above sets up the file paths to the standalone binaries corresponding to the SB deploy options.

What were the other changes, and in what files?

[tperry2x]

I notice the MacOS standalones have had their internal binary renamed, from:
".../Standalone.app/Contents/MacOS/Standalone-" & tEdition
to
".../Standalone.app/Contents/MacOS/Standalone-Community"

This is fine, and makes sense - as we don't have various editions of the IDE - we only have 'Community' now, but renaming this file has triggered these codesigning errors - which I didn't used to get:

err-01.png (83.87 KiB) Viewed 1899 times

err-02.png (83.93 KiB) Viewed 1899 times

After downloading the developer command line tools, the build does proceed to generate x32 and x64 bit MacOS standalones, as before.

err-03.png (89.06 KiB) Viewed 1899 times

I just wanted to point out that renaming the MacOS binary has that consequence.

Anyway, now onto building a toggle for Sonoma that works...

[tperry2x]

Righto, so now there's an additional option:

build-settings.png (88.77 KiB) Viewed 1892 times

Turning on the 'Sonoma' test build will build a x64-bit MacOS application with the patch applied (note the slight size difference)

builds.png (74.54 KiB) Viewed 1892 times

I'll just produce a MacOS version with a menu, and if someone could see if that runs on Sonoma please...

edit: file too big for this forum, so here's an alternative link.

Please can someone test this in Sonoma and see if it can render a File menu.

please-test.png (142.7 KiB) Viewed 1891 times

By the way, I fully expect this to put up all manner of codesigning / application damaged warnings etc. The normal scare-tactics stuff for MacOS.

[richmond62]

SShot 2024-08-26 at 14.38.58.png (50.95 KiB) Viewed 1868 times

-
Wonderful start.