On Mac mini M1, 11.0.1
switcher = hs.window.switcher.new()
2020-11-22 21:43:18: -- Lazy extension loading enabled
2020-11-22 21:43:18: -- Loading ~/.hammerspoon/init.lua
2020-11-22 21:43:18: -- Loading extension: window
2020-11-22 21:43:18: -- Loading extensions: window.switcher
2020-11-22 21:43:18: 21:43:18 ERROR: LuaSkin: hs.canvas:clipToPath must be a boolean
2020-11-22 21:43:18: 21:43:18 ERROR: LuaSkin: hs.canvas:clipToPath must be a boolean
2020-11-22 21:43:18: 21:43:18 ERROR: LuaSkin: hs.canvas:clipToPath must be a boolean
2020-11-22 21:43:18: 21:43:18 ERROR: LuaSkin: hs.canvas:clipToPath must be a boolean
2020-11-22 21:43:18: *** ERROR: ...oon.app/Contents/Resources/extensions/hs/canvas/init.lua:525: bad argument #2 to 'canvasDefaultFor' (invalid argument type for clipToPath specified)
stack traceback:
[C]: in method 'canvasDefaultFor'
...oon.app/Contents/Resources/extensions/hs/canvas/init.lua:525: in metamethod 'newindex'
...ntents/Resources/extensions/hs/drawing/canvasWrapper.lua:29: in function 'hs.drawing.canvasWrapper._image'
(...tail calls...)
...app/Contents/Resources/extensions/hs/window/switcher.lua:380: in upvalue 'setUiPrefs'
...app/Contents/Resources/extensions/hs/window/switcher.lua:419: in function 'hs.window.switcher.new'
/Users/user/.hammerspoon/init.lua:1: in main chunk
[C]: in function 'xpcall'
...app/Contents/Resources/extensions/hs/_coresetup/init.lua:702: in function 'hs._coresetup.setup'
(...tail calls...)
Can't replicate on my end; what version of Hammerspoon are you running?
Version 0.9.82 (5614)
It's a clean install so the problem may not related to platform. Maybe I just forgot to meet some requirements.
After debugging the code I found after commenting this line the config can work with some error message:
2020-11-26 13:14:22: 13:14:22 ERROR: LuaSkin: hs.canvas:clipToPath must be a boolean
2020-11-26 13:14:22: 13:14:22 ERROR: LuaSkin: hs.canvas:absoluteSize must be a boolean
2020-11-26 13:14:22: 13:14:22 ERROR: LuaSkin: hs.canvas:absolutePosition must be a boolean
2020-11-26 13:14:23: 13:14:23 ERROR: LuaSkin: hs.canvas:imageAnimates must be a boolean
2020-11-26 13:14:23: 13:14:23 ERROR: LuaSkin: hs.canvas:imageAnimates must be a boolean
2020-11-26 13:14:23: 13:14:23 ERROR: LuaSkin: hs.canvas:imageAnimates must be a boolean
2020-11-26 13:14:23: 13:14:23 ERROR: LuaSkin: hs.canvas:imageAnimates must be a boolean
2020-11-26 13:14:23: 13:14:23 ERROR: LuaSkin: hs.canvas:clipToPath must be a boolean
2020-11-26 13:14:23: 13:14:23 ERROR: LuaSkin: hs.canvas:absoluteSize must be a boolean
2020-11-26 13:14:23: 13:14:23 ERROR: LuaSkin: hs.canvas:absolutePosition must be a boolean
...
All these error message are from the type checker in setDefaultFor and boolean value. So I guess maybe some implicit type conversion here causing the problem. Do you have any idea?
After seaching this may related to the problem?
So the problem was, that on 32bit, encode(BOOL) returns a 'c', but on 64 bit, it returns a 'B', while objCType on a numberWithBool: will give you a 'c' on both 64bit and 32bit.
Lua boolean is converting to numberWithBool and encode(BOOL) return 'B' on 64 bit, which preventing the check from passing.
@"clipToPath" : @{
@"class" : @[ [NSNumber class] ],
@"luaClass" : @"boolean",
@"objCType" : @(@encode(BOOL)),
@"nullable" : @(YES),
@"default" : @(NO),
@"optionalFor" : CLOSED,
},
...
if (subKeyMiniDefinition[@"objCType"]) {
if (strcmp([subKeyMiniDefinition[@"objCType"] UTF8String], [keyValue[subKeyName] objCType])) {
errorMessage = [NSString stringWithFormat:@"field %@ of %@ must be a %@", subKeyName, keyName, subKeyMiniDefinition[@"luaClass"]] ;
break ;
}
}
Hammerspoon has been 64bit for some time now, so it must be an M1 vs Intel thing... and if I recall correctly, there were some other places where we had to cast BOOL differently when @cmsj first tried to make a unified build, so that jibes...
Ok, I'll have to dig in a bit and see how to address this... I'm hoping to get an M1 myself to build with in the next week or so, but let me look at the code for canvas and LuaSkin over the Thanksgiving holiday and see if anything suggests itself that I can have you test sooner... we rely on the encoding of numbers in a few different places (LuaSkin being the biggest and most important) and if this is truly changing or differs between platforms, we've got some subtle bugs to go hunting for...
Sorry for the delay in getting back to this. For the short term, you can run Hammerspoon in Rosetta2 mode (in the Finder, select Hammerspoon and then select Get Info, then check "Open in Rosetta") and it should work (it has for my use cases).
I now have an M1 laptop myself, and have it running most of my configuration, but have the same issue you've outlined above with hs.canvas. I will be looking into this over the next couple of days, so hopefully running with Rosetta enabled is a short term requirement.
Ok, I can confirm that the issue is with @encode which gives different values for some types on the different architectures. I've found a work around that works for Canvas, but we use @encode in a number of other places I want to review tomorrow and see if they should be changed as well.
I will put up a pull request sometime tomorrow for testing.
Most helpful comment
Ok, I can confirm that the issue is with
@encodewhich gives different values for some types on the different architectures. I've found a work around that works for Canvas, but we use@encodein a number of other places I want to review tomorrow and see if they should be changed as well.I will put up a pull request sometime tomorrow for testing.