Known Bugs

[tperry2x]

Tested in Arch Linux, Ubuntu Mate, Zorin OS, and Fedora today (mostly VMs - except the Fedora distro, which is on a legacy piece of hardware).

(And of course, MX Linux - which is my "daily driver")

I can report that they all managed to play back the video as per my tests above. Fedora was very laggy at first, but sped up when the inspector was closed. So the inspector probably wants looking at next, regarding how it's applying the various properties on a "Player" object.

I'm probably going to mark this as 'fixed' on the bug status page, with the proviso that the dependency procedure should be followed.

edit: I find it funny that my post about the video and the fix has had over 250 views! (only 56 registered users) - but nobody offering to test it. Oh well, never mind.

[tperry2x]

Having been staring at the engine code most of the weekend (yes, I know - seems sad, but it's been raining again... typical uk weather, so...):
I'd been looking at malloc errors in the engine, and found one that affects all platforms to a varying degree.

The short version of this is repeated use of the switch case function leads to escalating memory use, until a certain point where the engine will spontaneously exit (MacOS - and take down the entire IDE) or (Linux - where menu drawing suddenly slows to a crawl as the memory heap reports having no available memory). (note to self: use munmap() to unmap the memory once I've identified what is causing this).

Windows does not seem to be affected, as looking at memory maps - the memory does escalate momentarily, but it is released, so never becomes a problem. (Verified behaviour using RAMMap)

It's difficult to see exactly what the root cause of this escalation of memory is on MacOS and Linux, but the symptoms to reproduce it involve working extensively with the switch case method for hours on end (macos). Or, on Linux - sometimes the bug can come into effect upon the launch of an instance of the IDE. This is what makes it hard to fix, as the bug behaves differently between platforms. It could even be a shared library causing it. (platform specific).

As such, the older method of if else statements may be better if you are working on switch case for hours on end without quitting the IDE. Alternatively, if you are (thinking of Richmond's Sheba stack when I write this), best to save the stack and relaunch the IDE every couple of hours of continued use.

[richmond62]

I am absolutely sure that a whole slew of people are 'out there' transcribing the complete Kebra Nagast using my Sheba stack as we face this problem.

What is more to the point (think about the far larger SWITCH statements in my Devawriter Pro thing) is whether this happens in a standalone.

[tperry2x]

What is more to the point (think about the far larger SWITCH statements in my Devawriter Pro thing) is whether this happens in a standalone.

That I don't know - I've not tried regenerating the standalones, or monitoring them for memory leaks, but that is a very good point.

Edit: I'm getting off topic here, so moved the next couple of posts here.

[tperry2x]

Poking around in the IDE, I found something that WILL become a problem, but isn't yet.
IF we ever get past MacOS 19 - when it goes to 20 (and if the IDE still runs)... (there's a lot of "if's" there)... but it'll be here sooner or later.

Anyway, when running on macOS 20+, if you were to 'get the platform', it'll come back as "MacOS Classic"
One to bear in mind for future!

platform-future-error.png (25.29 KiB) Viewed 2275 times

This will also mean in theory, that all Mac standalones ever created, will also identify the platform as "MacOS Classic" - so if anyone has used:

Code: Select all

if the platform is "MacOS X" then...

in a standalone, that won't work... and that (in theory) might break a few things.

But it's a bit niche, nonetheless.

[richmond62]

If Apple keep churning out versions at the rate they do that'll be in 2029, when many people using Mac computers won't know what 'Classic' means in that context.

Having found that can you not edit it to check for 1 or 2, as by the time we get to MacOS 30 I'm "planning" to be dead, senile, or planting cabbages with my nose in a sun-kissed monastery for antiquated nut-cases.

[tperry2x]

Having found that can you not edit it to check for 1 or 2...

You can, it's in the revcommonlibrary - and it's definitely editable.
I was in there poking around anyway, to fix revCopyFile on Windows and hunting for things that might be slowing the IDE down.

Edit: Richmond has confirmed it's not as pressing as I feared:
I just realised - that'll be a problem sooner rather than I thought!
This platform function uses systemversion. As in, the unfixed systemversion - the one that gets reported incorrectly by the engine.
With MacOS 11 actually reporting as 16 by the engine currently, that would in theory mean that MacOS 15 reports as MacOS 20 in the IDE if you run "put the systemversion".
If that's the case, can you try "put the platform" under MacOS sequoia for me Richmond? - I want to see if it comes back with "MacOS Classic"

I also found there's this undocumented(?) function:

Code: Select all

put macVersionLessThan("9.2.2", "11.3.1")

9.2.2 being the maximum version of "classic macOS", and 11.3.1 in my example being whatever systemversion MacOS is returning. Someone has obviously thought about how to reliably deal with the macOS systemversion differencing, but not implemented it.

Anyway, please can you check what "put the platform" returns under MacOS 15 Sequoia.

A suggested fix could be:

fix-for-this.png (72.4 KiB) Viewed 2238 times

[richmond62]

Yes, of course.

Currently hanging around in a queue to have my summer tyres taken off and the winter ones fitted . . .

You never know your luck, I might get to the machine running MacOS Wellingtonia within the next 2-3 hours.

[richmond62]

SShot 2024-11-15 at 15.15.49.png (71.69 KiB) Viewed 2225 times

-

SShot 2024-11-15 at 15.17.18.png (73.15 KiB) Viewed 2225 times

-

[richmond62]

Ooooooo: the Dictionary does not seem to be working:
-

SShot 2024-11-15 at 15.20.32.png (57.85 KiB) Viewed 2223 times

[tperry2x]

Can you try

Code: Select all

put the platform

Will go through the dictionary thing in a sec, just want to do one thing at a time.

[richmond62]

Can you try

I did exactly that AND posted a screen shot just now.

Oh, AND:
-

SShot 2024-11-15 at 15.24.00.png (79.99 KiB) Viewed 2221 times

[tperry2x]

Can you try

I did exactly that AND posted a screen shot just now.

Oh, AND:
-
SShot 2024-11-15 at 15.24.00.png

Cool. 15.2 is what you should be seeing of course.
Sorry, our posts crossed over. I replied too early.

for the dictionary thing, still loading here:

Screenshot 2024-11-15 at 13.27.28.png (172.77 KiB) Viewed 2219 times

So, can you navigate to:

path.png (12.65 KiB) Viewed 2219 times

Can you open any of those text files in a text editor?

If you can't, then it'll be a permissions thing, and I'll need to start setting the permission of these on the Mac just like I do on Windows and Linux currently.

For the meantime, go back a few folder levels, get-info on the "exports" folder. Make yourself have read & write access and apply to "all enclosed items..."

Screenshot 2024-11-15 at 13.32.33.png (81.98 KiB) Viewed 2216 times

[tperry2x]

Good news with the incorrect systemversion, that it's counting MacOS 15 Sequoia as 10.16 at least, not 16 - because if it were doing that, as I say - we'd be up to 20 now and be reporting the platform as "MacOS classic".
It buys us some more time at the very least.

I'll build a check into the dictionary stack, so it deals with permissions. That'll be a relatively simple thing to add, so thank you for finding that. (If it's indeed what that is).

[richmond62]

Yes: that 'systemVersion function.txt' can be opened with TextEdit on MacOS 15.2 beta 3 without a problem.

[richmond62]

No obvious probs round these parts either:
-

SShot 2024-11-15 at 16.14.51.png (165.92 KiB) Viewed 2201 times

[tperry2x]

If nothing is populating in the dictionary window, that implies that OXT can't read the contents of that folder (the exports folder I mention above) - yes, as per that screenshot you just posted - for whatever reason.
If you click on the padlock, change it to "read only" for example, then apply to all enclosed items. Then change it back to "read and write" (if you want) - see if it can load then?

or you can open a terminal, type "sudo chmod -R 755 " (with a space at the end) - then drag that folder in and press return.

(as I say, I'll build this check in, if that works).

[richmond62]

Did that,and, NO: Dictionary "says no!"

This is NOT happening at home with the MacOS 12 Monterey machine.

[tperry2x]

Hmmm. That is curious.
(and annoying if I'm honest)
I wonder if it's some kind of OS sandbox thing?

Well, you'll be glad to know that I will hopefully have a mac that will run Sequoia soon, so at least I'll be able to test and diagnose these issues a little better. (Rather than developing on Catalina and scrounging the use of a Monterey mac from someone else!).

So, things should only improve in that regard. (more cement, less sand)

I don't think I'll try betas though, I'll stick to non-beta OS releases.

[richmond62]

I don't think I'll try betas though, I'll stick to non-beta OS releases.

Whatever rubbish Apple may spew out, I would treat ALL MacOS releases as part of an ongoing rolling-release where nothing is ever finished.