macOS Sequoia Preview

[OpenXTalkPaul]

So macOS Sequoia was announced and the good news is that Intel Macs are still supported.
My guess is 2026 will be the end for macIntel.

Here's a list of officially supported devices:
2019 iMac and later
2017 iMac Pro
2020 MacBook Air and later
2018 MacBook Pro and later
2019 Mac Pro and later
2018 Mac mini and later
2022 Mac Studio and later

I'm sure OpenCore Legacy Patcher will be updated and enable a bunch more older intel based computers to update.

Here's Apple's page that highlights the macOS features:
https://www.apple.com/macos/macos-sequoia-preview/

I won't install beta OS, so if someone else does then please let us know if OXT runs on it or crashes.

[richmond62]

I'ma foolish early adopter and WILL when the Beta 1 shows up here in the Balkans (probably Friday or Saturday).

As a guide to the Balkans: wedge heels are all the rage at the moment: I remember them when I was 12 and the 2 pimply teenage girls who served our tea were wearing them in 1974.

So, would that be 'Giant Redwood' or 'Giant Wedgewood'?

Oddly enough where I went to school in 1974 had within a 10 mile radius of it the greatest amount of Giant Redwoods anywhere on the planet . . . Yup: shitty Berkshire in England . . . go figure.

Currently in the school, but taking my Mac Mini home tonight so I can "up" grade it tomorrow, then annoy people by trying to get OXT Lite to "be a woodpecker" on the Wellingtonia . . .

https://en.wikipedia.org/wiki/Wellingtonia_Avenue

[richmond62]

I cannot quite work out what is wrong with me: I actually watched Craig Fluffy-Features PIMP MacOS 15 for about 45 minutes last night: the thing that was seriously disturbing was his 'Parkour' down a stairwell in the Apple Doughnut . . .

Wozzisname (Craig's hairstyle blocking my memory); err, oh. Tim Cook, looked positively both normal and ever so slightly maladjusted compared with 50+ Craig doing the "teenager on crack" impersonation that really gave me a serious attack of the dry boak: At 50+ you should behave like 50+, and not like some 17 year old creaming in your jeans.

What do I expect re my Intel Mac Mini 2018 and MacOS "Sasquatch"? Well: 2 things really:

1. More headaches with OXT Lite (thank "F" I have the crowd-funded 27" iMac chuntering along on MacOS 12: only snag: takes about 10 minutes to log in: seek comfort in coffee while waiting).

2. Nothing else.

3. Oh, Yerss: sexier calculator that would have been useful in 1984 when I was wroing with assembler language and got my brain tied in knots over hexadecimal machine-code: and what is my message to Tim, and Craig, Uncle Tom Cobbley, and all re that?

Why now, when we have got to the stage where we don't need it?

I wonder if anyone except Paris Hilton is fooled by that 'rabbit out of a hat'?

Why will I upgrade ("side-grade": discuss in no less than 50,000 words: on my desk by yesterday)? Because:

1. I am an aging fool.

2. It's there, and it's FREE . . . and anyone who wastes their time telling me that 'Free' upgrades from Apple is like catching a disease from a prostitute: don't bother: I know, and I'm already infected.

[richmond62]

My 2018 Intel Mac Mini is now running MacOS 15 beta 1 and I am very happy to report there are no obvious problems with OXT Lite 1.05.

[FourthWorld]

My 2018 Intel Mac Mini is now running MacOS 15 beta 1 and I am very happy to report there are no obvious problems with OXT Lite 1.05.

Does that imply the OXT menu crasher issue is resolved in the OS version?

[richmond62]

No it doesn't as I have not made a standalone with a menubar.

[OpenXTalkPaul]

No it doesn't as I have not made a standalone with a menubar.

I wonder if we try simply using the a copy of the IDE binary as the binary for Standalones (instead of the standard 'trimmed down' Standalone version of the Engine)? I mean in the IDE executable binary itself we obviously have an Engine that can runs on Sonoma (and Sequoia Preview) without crashing. Sure it would make for slightly larger standalones, but who cares about a few extra megabytes now days?

[tperry2x]

No it doesn't as I have not made a standalone with a menubar.

I wonder if we try simply using the a copy of the IDE binary as the binary for Standalones (instead of the standard 'trimmed down' Standalone version of the Engine)? I mean in the IDE executable binary itself we obviously have an Engine that can runs on Sonoma (and Sequoia Preview) without crashing. Sure it would make for slightly larger standalones, but who cares about a few extra megabytes now days?

That's a good idea.
Can someone try this menu stack (standalone), on MacOS Sonoma+ (and Sequoia preview) and see if it opens?
(link here)

menustack.png (200.82 KiB) Viewed 392 times

monterey-test.png (132.13 KiB) Viewed 382 times

[richmond62]

SShot 2024-06-21 at 12.40.26.png (80.99 KiB) Viewed 383 times

-

SShot 2024-06-21 at 12.40.03.png (16.26 KiB) Viewed 383 times

-
Groovy way to start my day.

[tperry2x]

Okay, thanks for confirming Richmond - I thought as much.
So, this has all the About, Quit, Help menus that Apple say have to exist for the menu to be compatible... and yet, what we have is what we have.

[tperry2x]

Here's what ChatGPT has to say on the debug report:

Based on the crash report you provided, the application "menustack" appears to crash due to a segmentation fault (SIGSEGV) on the main thread. Here are the key details that explain why the app might be crashing, particularly in relation to menus:
Key Details from the Crash Report:

Exception Type and Code:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
This indicates the application attempted to access memory at address 0x0000000000000000, which is invalid (a null pointer dereference).

Crashed Thread and Stack Trace:
Crashed Thread: 0 (Main thread)
The main thread is where the crash occurred, which is typically where UI operations are performed.
The stack trace shows a series of calls within the menustack application leading up to the crash.

objectivec

0 menustack 0x10e572f61 0x10e2f2000 + 2625377
1 menustack 0x10e572fdd 0x10e2f2000 + 2625501
2 menustack 0x10e572fdd 0x10e2f2000 + 2625501
3 menustack 0x10e560c54 0x10e2f2000 + 2550868
4 menustack 0x10e4a795f 0x10e2f2000 + 1792351
5 menustack 0x10e5795af 0x10e2f2000 + 2651567
6 CoreFoundation 0x7ff81a5ab84c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 137
7 CoreFoundation 0x7ff81a638db2 ___CFXRegistrationPost_block_invoke + 88
8 CoreFoundation 0x7ff81a638d01 _CFXRegistrationPost + 530
9 CoreFoundation 0x7ff81a57af2c _CFXNotificationPost + 765
10 Foundation 0x7ff81b5796eb -[NSNotificationCenter postNotificationName:object:userInfo:] + 82
11 AppKit 0x7ff81e02be9c -[NSWindow becomeKeyWindow] + 1174
12 AppKit 0x7ff81e02ac4a _NXShowKeyAndMain + 160
13 AppKit 0x7ff81e084264 -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 2705
14 AppKit 0x7ff81dffe145 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 409
15 AppKit 0x7ff81dffdd91 -[NSWindow(NSEventRouting) sendEvent:] + 339
16 AppKit 0x7ff81e89887a -[NSApplication(NSEventRouting) sendEvent:] + 1550

The stack trace indicates that the crash occurs while handling window and event-related operations, which includes mouse events (-[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:]).

Potential Issues with Menu Handling:
Given your suspicion about menus, the stack trace and context suggest that the crash might be related to menu interactions.
The crash occurs while NSWindow is becoming the key window, which often happens when a window is activated or brought to the foreground, possibly involving menu interactions.

Analysis:

Null Pointer Dereference: The app is trying to access memory at a null address (0x0000000000000000), which usually means there's an attempt to use an uninitialized or previously released object.
Event Handling: The crash in the main thread and the involvement of NSWindow and event routing functions (_handleMouseDownEvent, _reallySendEvent) suggest that the issue might be happening during user interaction with the UI, possibly related to menu handling.
Notification Center: There are calls to the notification center (__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__, postNotificationName:object:userInfo:), which indicates that some event or state change might be triggering a notification leading to the crash.

Conclusion:

The crash seems to be related to the handling of UI events, particularly those involving window focus and possibly menu interactions. The null pointer dereference at address 0x0000000000000000 suggests there might be an attempt to access an object that has not been properly initialized or has been released.
Recommendations:

Check for Null Pointers: Ensure that any objects accessed during the menu and window event handling are properly initialized and not null.
Review Menu Code: Pay special attention to the code related to menus and UI interactions that might be triggered when the window becomes key or handles mouse events.
Event Handling and Notifications: Investigate how events and notifications are managed, ensuring that all expected objects are in a valid state when these operations are performed.
Memory Management: Verify that objects are retained and released correctly to avoid accessing freed memory.

[richmond62]

what we have is what we have

Go straight to the top of the class for profound statements.

[richmond62]

Goofy Question Number 5,728 (and you can be sure I'm keeping count):
-

SShot 2024-06-21 at 13.00.36.png (265.79 KiB) Viewed 374 times

-
Err: in the stack where's the guff that sets up the menus?

[tperry2x]

Go straight to the top of the class for profound statements.

Yes, haha - It's like the saying "It is what it is" - well, yes - otherwise it'd be something else.
ChatGPT doesn't uncover anything wild or obvious, except the null pointer memory reference - which comes from the engine. Which I already suspect to be fixed in the 9.7.x engine (you know, the one I can only get to compile in Linux)

Err: in the stack where's the guff that sets up the menus?

It's built with the menu builder stack, but you can get to it via the Application browser (LCC and OXT set these up as a series of buttons).

menustack edit.png (244.34 KiB) Viewed 372 times

[richmond62]

OK, Yah . . .
-

SShot 2024-06-21 at 13.10.28.png (182.19 KiB) Viewed 368 times

-
Never built an xTalk menu in my life as trusted to in-stack menus forever.

Holy Cow, to think I was at University with Annabelle Heseltine . . . Fioch, fioch, fioch!

[tperry2x]

Holy Cow, to think I was at University with Annabelle Heseltine . . . Fioch, fioch, fioch!

Oh, I was wondering who that was.
Two things I steer clear of: Religion and politics.

[richmond62]

'That' is neither religion or politics; 'that' is an upper-class, vacant, toff: the English equivalent of Paris Hilton.

And 'that' was at Durham with me (1983-1986), and at Durham those types were called 'Rahs', and at my sister's Uni' (St. Andrews) were called 'Yahs' for extremely obvious reasons.

The Bulgarian version is called a kifla:
-

kifli.jpg (8.73 KiB) Viewed 358 times

-
As my late father, bless his memory, remarked on a visit to Bulgaria about 18 years ago, seeing some of those things in the park:

"Whore today, gone tomorrow!"

Gosh, I miss my Dad.

Sociology lessons you could do without. . .

[OpenXTalkPaul]

Potential Issues with Menu Handling:
Given your suspicion about menus, the stack trace and context suggest that the crash might be related to menu interactions.
The crash occurs while NSWindow is becoming the key window, which often happens when a window is activated or brought to the foreground, possibly involving menu interactions.

It reads like the OS is calling for something that isn't there, I wonder if something couldn't be done to satisfy whatever is missing from the NSWindow (or the apps NSMenu).

Ideally the problem would be fixed in the Engine, but XBuilder can do just about anything with NSObjects, including the top object NSApplication (that's how I implemented 'darkMode'), such a fix could be called 'on startup' in a standalone. I'm pretty sure that message happens before any stack windows are opened, which is why my home stack turns on darkMode just after the libraries init parts of 'on startup' handler so that IDE user never sees the switch-over to dark (that's a difference between OXT Lite and Heavy, btw.)

[tperry2x]

...IDE user never sees the switch-over to dark (that's a difference between OXT Lite and Heavy, btw.)

Are you sure? I thought I squashed that issue in 1.05?

[OpenXTalkPaul]

...IDE user never sees the switch-over to dark (that's a difference between OXT Lite and Heavy, btw.)

Are you sure? I thought I squashed that issue in 1.05?

[launches OXT Lite 1.05]
DOH! My bad, OXT Lite 1.05 does indeed squash that! Right on!