This is the collective yearly thread for macOS betas. Please use this to discuss instead of opening new issues.
I will try to keep this updated just like every year.
2021-06-07 Developer Beta 1 (21A5248p)
Dock.app is available at [Dock.app.zip](https://github.com/koekeishiya/yabai/files/6617787/Dock.app.zip).
Issue
Note
build from source fails
Click to expand build log
```
❯ make
rm -rf ./bin
xcrun clang ./src/osax/loader.m -shared -O2 -mmacosx-version-min=10.13 -o ./src/osax/loader -framework Foundation
xcrun clang ./src/osax/payload.m -shared -fPIC -O2 -mmacosx-version-min=10.13 -o ./src/osax/payload -framework Foundation -framework Carbon
./src/osax/payload.m:37:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSGetConnectionPSN(int cid, ProcessSerialNumber *psn);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:37:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSGetConnectionPSN(int cid, ProcessSerialNumber *psn);
^
*
./src/osax/payload.m:38:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSSetWindowAlpha(int cid, uint32_t wid, float alpha);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:38:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSSetWindowAlpha(int cid, uint32_t wid, float alpha);
^
*
./src/osax/payload.m:39:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSSetWindowListAlpha(int cid, const uint32_t *window_list, int window_count, float alpha, float duration);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:39:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSSetWindowListAlpha(int cid, const uint32_t *window_list, int window_count, float alpha, float duration);
^
*
./src/osax/payload.m:40:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSSetWindowLevel(int cid, uint32_t wid, int level);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:40:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSSetWindowLevel(int cid, uint32_t wid, int level);
^
*
./src/osax/payload.m:42:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSReassociateWindowsSpacesByGeometry(int cid, CFArrayRef window_list);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:42:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSReassociateWindowsSpacesByGeometry(int cid, CFArrayRef window_list);
^
*
./src/osax/payload.m:43:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSGetWindowOwner(int cid, uint32_t wid, int *window_cid);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:43:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSGetWindowOwner(int cid, uint32_t wid, int *window_cid);
^
*
./src/osax/payload.m:44:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSInvalidateWindowShadow(int cid, CGWindowID wid);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:44:51: error: unknown type name 'CGWindowID'
extern CGError CGSInvalidateWindowShadow(int cid, CGWindowID wid);
^
./src/osax/payload.m:44:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSInvalidateWindowShadow(int cid, CGWindowID wid);
^
*
./src/osax/payload.m:45:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSSetWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:45:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSSetWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize);
^
*
./src/osax/payload.m:46:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSClearWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:46:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSClearWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize);
^
*
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make: *** [src/osax/sa_loader.c] Error 1
```
After some thought I will be updating to 12.0.1 and add support for that probably tonight. I'll probably mark these comments as resolved, or delete them afterwards, to reduce noise.
Edit: Updated with support for 12.0.1. Updated comment above.
@evprkr I don't know and I definitely could be wrong, but my intuition screams that your problem (which seems to uniquely effect you) is the result of doing a app != '^(a|b|c)$' manage=off rule.
I honestly wouldn't expect it to go well, and I think it alone can explain your problem.
What I think is happening is like this:
Something on your computer generates (invisible) windows intermittently. (Or you just open a window that you expect yabai to ignore)
The main event loop of yabai dutifully starts to adjust the layout to fit the new window in
The rule processor finishes processing the window added event and determines it is supposed to be a floating window, so it removes it from the layout
The other windows adjust for the removal of that window in the layout (before it was necessarily ever drawn)
I would seriously consider trying an alternative approach to your filtering. Like, for example, using a float or stack layout space default and setting manage=on rules for the apps you do want to layout.
I'm not sure that will work either, but I'm just ... not surprised that the thing you are trying now doesn't. I'd honestly never expect it to (and therefore would never have thought to try it)
@evprkr I don't know and I definitely could be wrong, but my intuition screams that your problem (which seems to uniquely effect you) is the result of doing a app != '^(a|b|c)$' manage=off rule.
I honestly wouldn't expect it to go well, and I think it alone can explain your problem.
What I think is happening is like this:
Something on your computer generates (invisible) windows intermittently. (Or you just open a window that you expect yabai to ignore)
The main event loop of yabai dutifully starts to adjust the layout to fit the new window in
The rule processor finishes processing the window added event and determines it is supposed to be a floating window, so it removes it from the layout
The other windows adjust for the removal of that window in the layout (before it was necessarily ever drawn)
I would seriously consider trying an alternative approach to your filtering. Like, for example, using a float or stack layout space default and setting manage=on rules for the apps you do want to layout.
I'm not sure that will work either, but I'm just ... not surprised that the thing you are trying now doesn't. I'd honestly never expect it to (and therefore would never have thought to try it)
I have seen other people talking about it, but I haven't seen their configs so I'm not sure if they're using the same sort of thing as I am, but you may be right regardless. What would be the best way to go about employing a "tile ONLY App1, App2, App3..." rule?
@evprkr I don't know and I definitely could be wrong, but my intuition screams that your problem (which seems to uniquely effect you) is the result of doing a app != '^(a|b|c)$' manage=off rule.
I honestly wouldn't expect it to go well, and I think it alone can explain your problem.
What I think is happening is like this:
Something on your computer generates (invisible) windows intermittently. (Or you just open a window that you expect yabai to ignore)
The main event loop of yabai dutifully starts to adjust the layout to fit the new window in
The rule processor finishes processing the window added event and determines it is supposed to be a floating window, so it removes it from the layout
The other windows adjust for the removal of that window in the layout (before it was necessarily ever drawn)
I would seriously consider trying an alternative approach to your filtering. Like, for example, using a float or stack layout space default and setting manage=on rules for the apps you do want to layout.
I'm not sure that will work either, but I'm just ... not surprised that the thing you are trying now doesn't. I'd honestly never expect it to (and therefore would never have thought to try it)
I'm also experience these random reshuffling issue and I use the following config
Tomorrow I will test if commenting out the rules will help with the issue
Updated with support for 12.0.1. I have merged the-future branch into master for now. I have updated the instructions in my previous comment, but the wiki instructions here (disable sip) and here (install from master) should apply.
@evprkr Are you comfortable attempting to build from source? I think a crash report/backtrace with debug symbols might help trying to figure out what exactly is causing a crash for you.
Edit: First try the master version and see if it reproduces there.
@evprkr Are you comfortable attempting to build from source? I think a crash report/backtrace with debug symbols might help trying to figure out what exactly is causing a crash for you.
Edit: First try the master version and see if it reproduces there.
I will try the master version (with my same configs) and report back. If it's not resolved, I'm willing to try building from source, I managed to do it with @donaldguy's fork.
@koekeishiya Alright, so I just had it happen again. I had installed from HEAD, I'm not entirely sure that's what you meant, but from what I could tell, the last commit to release 3.3.10 was a couple of months ago, so I'm not really sure where to get the latest commit to master.
Or did you mean I'd have to build that from source?
I just tried and got this error. @koekeishiya I'm on M1 macOS 12.0.1
❯ brew install yabai --HEAD
==> Cloning https://github.com/koekeishiya/yabai.git
Updating /Users/A.Y/Library/Caches/Homebrew/yabai--git
==> Checking out branch master
Already on 'master'
Your branch is up to date with 'origin/master'.
HEAD is now at 6bcf544 bump version
==> Installing yabai from koekeishiya/formulae
==> make install
Last 15 lines from /Users/A.Y/Library/Logs/Homebrew/yabai/01.make:
rm -f ./src/osax/mach_loader
mkdir -p ./bin
clang src/manifest.m src/osax/loader_bin.c src/osax/payload_bin.c src/osax/mach_loader_bin.c -std=c99 -Wall -DNDEBUG -O2 -fvisibility=hidden -mmacosx-version-min=10.13 -fno-objc-arc -arch x86_64 -arch arm64 -F/System/Library/PrivateFrameworks -framework Carbon -framework Cocoa -framework CoreServices -framework SkyLight -framework ScriptingBridge -o bin/yabai
Undefined symbols for architecture x86_64:
"_regcompA", referenced from:
_handle_message in manifest-7ee4a3.o
"_regexecA", referenced from:
_event_signal_flush in manifest-7ee4a3.o
_window_manager_apply_rule_to_window in manifest-7ee4a3.o
"_regfreeA", referenced from:
_event_signal_destroy in manifest-7ee4a3.o
_rule_destroy in manifest-7ee4a3.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [bin/yabai] Error 1
I have tested that the master branch builds fine for me on macOS Big Sur 11.6.1 (Intel) and macOS Monterey 12.0.1 (Apple Silicon). Both builds work when I send them to my other device, both ways. Make sure your Xcode is up to date. Also what is the output of xcode-select -p
With yabai from --HEAD, SIP totally disable, codesigned I still get this warning and I cannot install payload:
❯ yabai -v
yabai-v4.0.0
❯ sudo yabai --load-sa
could not set thread state: (os/kern) protection failure
yabai: scripting-addition failed to inject payload into Dock.app!
❯ csrutil status
System Integrity Protection status: disabled.
Edit: I am using Xcode v13.1 (13A1030d) on both devices (not command line tools) and Apple clang version 13.0.0 (clang-1300.0.29.3).
I have the exact same version of these two things. xcode-select -p gives me /Applications/Xcode.app/Contents/Developer
I tried the prebuilt file you shared (thank you so much). It works well so far. But still wondering why brew doesn't work... and now I cannot do the brew service thing to automate it.
Same issue here. M1 Macbook Pro, Xcode 13.1. I have re-enabled SIP and cleared nvram boot arguments to defaults so that I can go all the way through the process again twice now, but still receive
could not set thread state: (os/kern) protection failure
yabai: scripting-addition failed to inject payload into Dock.app!
when loading the scripting addon.
# yabai -v
yabai-v4.0.0
# csrutil status
System Integrity Protection status: unknown (Custom Configuration).
Configuration:
Apple Internal: disabled
Kext Signing: enabled
Filesystem Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: enabled
NVRAM Protections: disabled
BaseSystem Verification: enabled
Boot-arg Restrictions: disabled
Kernel Integrity Protections: disabled
Authenticated Root Requirement: enabled
This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
@evprkr I don't know and I definitely could be wrong, but my intuition screams that your problem (which seems to uniquely effect you) is the result of doing a app != '^(a|b|c)$' manage=off rule.
I honestly wouldn't expect it to go well, and I think it alone can explain your problem.
What I think is happening is like this:
Something on your computer generates (invisible) windows intermittently. (Or you just open a window that you expect yabai to ignore)
The main event loop of yabai dutifully starts to adjust the layout to fit the new window in
The rule processor finishes processing the window added event and determines it is supposed to be a floating window, so it removes it from the layout
The other windows adjust for the removal of that window in the layout (before it was necessarily ever drawn)
I would seriously consider trying an alternative approach to your filtering. Like, for example, using a float or stack layout space default and setting manage=on rules for the apps you do want to layout.
I'm not sure that will work either, but I'm just ... not surprised that the thing you are trying now doesn't. I'd honestly never expect it to (and therefore would never have thought to try it)
I'm also experience these random reshuffling issue and I use the following config
Tomorrow I will test if commenting out the rules will help with the issue
I tested it with the newest master version and with my rules enabled and that solved it for me!!
Thank you very much @koekeishiya !!
I get the following error on the System recovery Terminal:
nvram boot-args=-arm64e_preview_abi
Error setting variable - 'boot-args': (iokit/common) not permitted.
You are correct; I see the same behaviour. I have updated the wiki so that it mentions that this command must be run as root after exiting recovery mode and rebooting. Previously it was possible to run the nvram command in recovery mode after SIP had been disabled (possibly can be done in recovery after a reboot between the initial command to disable SIP, but then it might as well be done from a normal user session using sudo).
@bentosquares
Did you reboot after changing the boot-args? I am unable to reproduce a failure in thread_set_state on my end, with seemingly the same config:
@DennisFeldbusch
That's great, hopefully it remains stable for the most part.
Thank you so much for the work to get this running for Monterey. It's a shame that window borders don't work anymore, but I'm happy to have my window tiling back!
However, yabai -m space --focus commands still don't seem to work for me, even though they exit with 0 as does sudo yabai --load-sa. Logs don't show anything.
You can look for logs in Console.app. Select your device on the left, and filter for "Dock" at the right, as shown in the below screenshot. Make sure no previous injection of the scripting-addition has been attempted; run pkill Dock first if it has. Clear the log window first for less noise, then run sudo yabai --load-sa and assuming it returns no error, you should see something like the following:
Well the issue is that for some reason your scripting-addition is not being built as a universal binary. I don't really know why that is. The current master builds a universal binary on both my Intel MacBook running 11.6.1, and my Apple Silicon MacBook running 12.0.1. Note that I am not using brew while testing, so maybe that could somehow cause a difference in compilation, even though it uses the same makefile?? I'm not sure how to debug that issue further.
I wonder what exactly is causing the command run from the makefile to differ from the one actually at the master branch. Do you have some custom clang version installed that takes precedence over the XCode / command line tools version? This seems likely to me as it appears that a standard header that should be included, is in fact not.
Ok, I think I got this. I've installed with brew install yabai --HEAD and them downloaded the prebuilt binary I posted in: #923 (comment) .
Then I did this (a kinda hack):
❯ cd Desktop/archive/bin/
mv yabai /opt/homebrew/Cellar/yabai/HEAD-6bcf544/bin/yabai
override r-xr-xr-x storopoli/admin for /opt/homebrew/Cellar/yabai/HEAD-6bcf544/bin/yabai? (y/n [n]) y
Ok, I think I got this. I've installed with brew install yabai --HEAD and them downloaded the prebuilt binary I posted in: #923 (comment) .
Then I did this (a kinda hack):
❯ cd Desktop/archive/bin/
mv yabai /opt/homebrew/Cellar/yabai/HEAD-6bcf544/bin/yabai
override r-xr-xr-x storopoli/admin for /opt/homebrew/Cellar/yabai/HEAD-6bcf544/bin/yabai? (y/n [n]) y
It seem to be working now.
For whatever reason, this worked. I tried brew install head and sudo make install and I'm pretty confident that I followed the instructions to the letter. After I saw this comment, i removed all old installations and did a
brew install koekeishiya/formulae/yabai --HEAD
followed by copying the before mentioned pre-built binary to the correct directory. Install sa and load sa worked like a charm and I can keep working again! Huge thanks to @koekeishiya and @storopoli
Did you reboot after changing the boot-args? I am unable to reproduce a failure in thread_set_state on my end, with seemingly the same config:
I had done, but I see you've tracked down the issue, my results mirror that of @storopoli. The hack of replacing the binary with the pre-compiled copy has also worked for me. Thanks to you both. Good luck in tracking down the issues with the Brew process! And thanks for such a great piece of software.
This is the collective yearly thread for macOS betas. Please use this to discuss instead of opening new issues.
I will try to keep this updated just like every year.
2021-06-07 Developer Beta 1 (21A5248p)
Dock.app is available at [Dock.app.zip](https://github.com/koekeishiya/yabai/files/6617787/Dock.app.zip).
Click to expand build log
``` ❯ make rm -rf ./bin xcrun clang ./src/osax/loader.m -shared -O2 -mmacosx-version-min=10.13 -o ./src/osax/loader -framework Foundation xcrun clang ./src/osax/payload.m -shared -fPIC -O2 -mmacosx-version-min=10.13 -o ./src/osax/payload -framework Foundation -framework Carbon ./src/osax/payload.m:37:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSGetConnectionPSN(int cid, ProcessSerialNumber *psn); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArrayThe snippet you posted works fine for me. Are you running 12.0.0, or 12.0.1? As mentioned only 12.0.0 is supported right now.
Right, I'm on 12.0.1, thanks for the quick response
After some thought I will be updating to 12.0.1 and add support for that probably tonight. I'll probably mark these comments as resolved, or delete them afterwards, to reduce noise.
Edit: Updated with support for 12.0.1. Updated comment above.
If 12.0.1 support is released, do you have any ETA of an official merge to master ?
Any idea if the reshuffling is resolved in the version you mentioned above?
Not tested yet, but I don't think so...
@evprkr I don't know and I definitely could be wrong, but my intuition screams that your problem (which seems to uniquely effect you) is the result of doing a
app != '^(a|b|c)$' manage=offrule.I honestly wouldn't expect it to go well, and I think it alone can explain your problem.
What I think is happening is like this:
I would seriously consider trying an alternative approach to your filtering. Like, for example, using a float or stack layout space default and setting manage=on rules for the apps you do want to layout.
I'm not sure that will work either, but I'm just ... not surprised that the thing you are trying now doesn't. I'd honestly never expect it to (and therefore would never have thought to try it)
I have seen other people talking about it, but I haven't seen their configs so I'm not sure if they're using the same sort of thing as I am, but you may be right regardless. What would be the best way to go about employing a "tile ONLY App1, App2, App3..." rule?
I also have this reshuffling issue. Explanation about filtering rules is fine, but doesn't explain why it wasn't a problem with previous Mac OS X.
I mean if it's in fact a race condition kind of issue, any number of things could change between versions:
And any combination of such things could effect the timing
EDIT: … speed of regex parsing, response time of individual syscalls, …
I'm also experience these random reshuffling issue and I use the following config
Tomorrow I will test if commenting out the rules will help with the issue
Updated with support for 12.0.1. I have merged
the-futurebranch into master for now. I have updated the instructions in my previous comment, but the wiki instructions here (disable sip) and here (install from master) should apply.@evprkr Are you comfortable attempting to build from source? I think a crash report/backtrace with debug symbols might help trying to figure out what exactly is causing a crash for you.
Edit: First try the master version and see if it reproduces there.
I will try the master version (with my same configs) and report back. If it's not resolved, I'm willing to try building from source, I managed to do it with @donaldguy's fork.
@koekeishiya Alright, so I just had it happen again. I had installed from HEAD, I'm not entirely sure that's what you meant, but from what I could tell, the last commit to release 3.3.10 was a couple of months ago, so I'm not really sure where to get the latest commit to master.
Or did you mean I'd have to build that from source?
I just tried and got this error. @koekeishiya I'm on M1 macOS 12.0.1
I have tested that the master branch builds fine for me on macOS Big Sur 11.6.1 (Intel) and macOS Monterey 12.0.1 (Apple Silicon). Both builds work when I send them to my other device, both ways. Make sure your Xcode is up to date. Also what is the output of
xcode-select -pHere is a pre-built version (with debug symbols) of commit (https://github.com/koekeishiya/yabai/commit/727b11200b6155fba116dbf583873c772af50bc6): yabai-v4.0.0.tar.gz
I have verified that it runs on both arm64 (12.0.1) and x86-64 (11.6.1).
Edit: I am using Xcode v13.1 (13A1030d) on both devices (not command line tools) and Apple clang version 13.0.0 (clang-1300.0.29.3).
With yabai from --HEAD, SIP totally disable, codesigned I still get this warning and I cannot install payload:
EDIT: I am on a MacOS M1:
@storopoli You probably have not yet changed the boot-args to allow for non-Apple-signed arm64e binaries. I have updated the wiki page here
I have the exact same version of these two things.
xcode-select -pgives me/Applications/Xcode.app/Contents/DeveloperI tried the prebuilt file you shared (thank you so much). It works well so far. But still wondering why brew doesn't work... and now I cannot do the
brew servicething to automate it.I get the following error on the System recovery Terminal:
And the output of
csrutil status:@storopoli I got the same error. Run
sudo nvram boot-args=-arm64e_preview_abiin a regular terminal and reboot solved my problem.Same issue here. M1 Macbook Pro, Xcode 13.1. I have re-enabled SIP and cleared nvram boot arguments to defaults so that I can go all the way through the process again twice now, but still receive
when loading the scripting addon.
I tested it with the newest master version and with my rules enabled and that solved it for me!! Thank you very much @koekeishiya !!
@storopoli
You are correct; I see the same behaviour. I have updated the wiki so that it mentions that this command must be run as root after exiting recovery mode and rebooting. Previously it was possible to run the nvram command in recovery mode after SIP had been disabled (possibly can be done in recovery after a reboot between the initial command to disable SIP, but then it might as well be done from a normal user session using sudo).
@bentosquares
Did you reboot after changing the boot-args? I am unable to reproduce a failure in
thread_set_stateon my end, with seemingly the same config:@DennisFeldbusch
That's great, hopefully it remains stable for the most part.
Thank you so much for the work to get this running for Monterey. It's a shame that window borders don't work anymore, but I'm happy to have my window tiling back!
However,
yabai -m space --focuscommands still don't seem to work for me, even though they exit with0as doessudo yabai --load-sa. Logs don't show anything.System details:
@koekeishiya I am still getting the same error after several reboots:
@robinsturmeit
You can look for logs in
Console.app. Select your device on the left, and filter for "Dock" at the right, as shown in the below screenshot. Make sure no previous injection of the scripting-addition has been attempted; runpkill Dockfirst if it has. Clear the log window first for less noise, then runsudo yabai --load-saand assuming it returns no error, you should see something like the following:@storopoli Can you post the output of the following:
This is what it should look like:
Here it is:
Well the issue is that for some reason your scripting-addition is not being built as a universal binary. I don't really know why that is. The current master builds a universal binary on both my Intel MacBook running 11.6.1, and my Apple Silicon MacBook running 12.0.1. Note that I am not using brew while testing, so maybe that could somehow cause a difference in compilation, even though it uses the same makefile?? I'm not sure how to debug that issue further.
I will try to build from master without brew
I cannot build from master:
I wonder what exactly is causing the command run from the makefile to differ from the one actually at the master branch. Do you have some custom clang version installed that takes precedence over the XCode / command line tools version? This seems likely to me as it appears that a standard header that should be included, is in fact not.
This is the line i expected to see:
Notice how it refuses to build a universal binary containing two images; the x86_64 part is just stripped from your version, which shouldn't happen.
Ok, I think I got this. I've installed with
brew install yabai --HEADand them downloaded the prebuilt binary I posted in: #923 (comment) .Then I did this (a kinda hack):
It seem to be working now.
Closing in favour of #1054.
For whatever reason, this worked. I tried brew install head and sudo make install and I'm pretty confident that I followed the instructions to the letter. After I saw this comment, i removed all old installations and did a
brew install koekeishiya/formulae/yabai --HEADfollowed by copying the before mentioned pre-built binary to the correct directory. Install sa and load sa worked like a charm and I can keep working again! Huge thanks to @koekeishiya and @storopoliI had done, but I see you've tracked down the issue, my results mirror that of @storopoli. The hack of replacing the binary with the pre-compiled copy has also worked for me. Thanks to you both. Good luck in tracking down the issues with the Brew process! And thanks for such a great piece of software.
I'm running Monterey on Intel, it's hard to follow what solutions in that thread are for Monterey and what issues are for M1.
Install the latest version released (v4.0.0) either through brew or grab it from the GitHub releases page.
@koekeishiya thanks! After upgrading 3.3 -> 4.0, it looks like that fixed the scripting additions notification spam.