Page 23 of 35

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

Posted: Sat Aug 03, 2024 7:36 pm
by 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.

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

Posted: Sat Aug 03, 2024 7:40 pm
by tperry2x
richmond62 wrote: Sat Aug 03, 2024 7:36 pm 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.

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

Posted: Sat Aug 03, 2024 7:49 pm
by 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.

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

Posted: Sat Aug 03, 2024 7:56 pm
by 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.

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

Posted: Sat Aug 03, 2024 8:09 pm
by 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.

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

Posted: Sat Aug 03, 2024 8:10 pm
by mwieder
...and why the hell are we diverging here? Can't we cross-pollinate and have a single goal to aim for?

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

Posted: Sat Aug 03, 2024 8:17 pm
by 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.

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

Posted: Sat Aug 03, 2024 8:22 pm
by 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?)

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

Posted: Sat Aug 24, 2024 5:53 pm
by tperry2x
Added the ability for the text-version of the dictionary to read glossary terms. (no unsightly | characters)
scrn.png
scrn.png (57.5 KiB) Viewed 2268 times
Should take you to this build:
202408241822.png
202408241822.png (13.59 KiB) Viewed 2268 times

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

Posted: Sat Aug 24, 2024 5:57 pm
by richmond62
Erm, well, sort of:
-
Screenshot 2024-08-24 at 20.55.58.png
Screenshot 2024-08-24 at 20.55.58.png (57.19 KiB) Viewed 2264 times
-
The engine (macOS 12) seems not to be 9.7

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

Posted: Sat Aug 24, 2024 5:59 pm
by tperry2x
richmond62 wrote: Sat Aug 24, 2024 5:57 pm 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.

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

Posted: Sat Aug 24, 2024 6:05 pm
by richmond62
Duly noted.

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

Posted: Sun Aug 25, 2024 12:33 pm
by OpenXTalkPaul
tperry2x wrote: Sat Aug 24, 2024 5:59 pm
richmond62 wrote: Sat Aug 24, 2024 5:57 pm 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.

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

Posted: Sun Aug 25, 2024 1:45 pm
by 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.

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

Posted: Sun Aug 25, 2024 6:17 pm
by tperry2x
OpenXTalkPaul wrote: Sun Aug 25, 2024 12:33 pm 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.
OpenXTalkPaul wrote: Sun Aug 25, 2024 12:33 pm ...but have it as a deploy option (noting possible image corruption) for standalone building.
I'd love to. The question is how. :D :?:
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
where.png (159.85 KiB) Viewed 2002 times

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

Posted: Sun Aug 25, 2024 8:22 pm
by OpenXTalkPaul
tperry2x wrote: Sun Aug 25, 2024 6:17 pm
OpenXTalkPaul wrote: Sun Aug 25, 2024 12:33 pm 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.
OpenXTalkPaul wrote: Sun Aug 25, 2024 12:33 pm ...but have it as a deploy option (noting possible image corruption) for standalone building.
I'd love to. The question is how. :D :?:
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.

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

Posted: Mon Aug 26, 2024 7:24 am
by tperry2x
OpenXTalkPaul wrote: Sun Aug 25, 2024 8:22 pm 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
preview.png (121.65 KiB) Viewed 1897 times
changes.pdf
(30 KiB) Downloaded 65 times
OpenXTalkPaul wrote: Sun Aug 25, 2024 8:22 pm 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?

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

Posted: Mon Aug 26, 2024 7:44 am
by 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
err-01.png (83.87 KiB) Viewed 1893 times
err-02.png
err-02.png (83.93 KiB) Viewed 1893 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
err-03.png (89.06 KiB) Viewed 1893 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...

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

Posted: Mon Aug 26, 2024 9:07 am
by tperry2x
Righto, so now there's an additional option:
build-settings.png
build-settings.png (88.77 KiB) Viewed 1886 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
builds.png (74.54 KiB) Viewed 1886 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
please-test.png (142.7 KiB) Viewed 1885 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.

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

Posted: Mon Aug 26, 2024 11:29 am
by richmond62
SShot 2024-08-26 at 14.38.58.png
SShot 2024-08-26 at 14.38.58.png (50.95 KiB) Viewed 1862 times
-
Wonderful start.