Hammerspoon: [HUB] Breaking issues from 0.9.79

[eccentric-j]

Hi, Hammerspoon contributors and package authors. Just encountered an issue after upgrading to 0.9.79 agzam/spacehammer#68 fixed in agzam/spacehammer#70.

I was thinking we could tag this issue (or a different issue) to keep track of how many packages are facing issues to provide a high-level view of impact.

If there's a better way to do this, I'm all for it. What are your thoughts?

[bruggsy]

Not sure if this caused by update, but after updating this morning I get this error for my window switcher:
2020-09-21 09:44:56: 09:44:56 ERROR: LuaSkin: hs.hotkey callback: /Users/jbruggeman/.hammerspoon/init.lua:38: attempt to call a nil value (method 'moveOneScreenEast') stack traceback: <home_dir>/.hammerspoon/init.lua:38: in function </Users/jbruggeman/.hammerspoon/init.lua:34>

hotkey code:
hs.hotkey.bind(hyper, ']', function() local win = hs.window.focusedWindow() if (win) then win:moveOneScreenEast() end end)

edit: looks like this already has an issue, open https://github.com/Hammerspoon/hammerspoon/issues/2476

[jacobisaliveandwell]

Confirmation here.

[asmagill]

@cmsj, since you moved hs.windows away from the module and the userdata using the same table, shouldn't the three lines between 745 and 759 starting with window[...]=... be objectMT[...]=... instead?

See https://github.com/Hammerspoon/hammerspoon/blob/master/extensions/window/init.lua#L745-L759 (specifically 746, 750, and 758)

I'll try to make a pull later today, unless someone beats me to it, and test to make sure nothing else is missing, but a cursory glance at init.lua suggests that you got the rest of them.

[zmanji]

I believe #2487 is another kind of regression as well

[asmagill]

@eccentric-j re Lua 5.4 and luarocks, another approach is outlined at https://github.com/Hammerspoon/hammerspoon/wiki/LuarocksAndHammerspon and was triggered by issue #2473.

As to a good tracking/announcing mechanism for things that break (or might break)... we don't have a particularly good one ATM other than filing issues here. There has been a suggestion to try and setup up a blog or wiki page specifically to outline upcoming changes for pending new releases, but it's still in the "It might be a good idea if..." stage right now.

[jacobisaliveandwell]

@asmagill github pages is a free way to manage a presence, but those are usually tied to a build, which brings up the question - can this be reverted and a new version pushed out for the time being?

[latenitefilms]

Whilst the various issues are being worked on, I've added a "Known Issues" section to the Wiki:

https://github.com/Hammerspoon/hammerspoon/wiki/Known-Issues

[asmagill]

@jacobisaliveandwell for which issue(s)?

The window and window filter ones should be (hopefully) addressed soon.

Likewise for the configuration directory ones.

The lua version one is the continuation of a decision we made quite some time ago to keep up with the current Lua version instead of locked into an older one (LuaJIT is a prime example of this, and while it is very powerful and has its niche, will never support later versions of Lua by the admission of its maintainer). And we have a work-around, documented at https://github.com/Hammerspoon/hammerspoon/wiki/LuarocksAndHammerspon that should address the majority of cases.

If you still want to campaign for a reversion, on any grounds, you need to convince @cmsj, as he handles the actual release builds. And I'm guessing by the time he could arrange it, we'll have fixed most of the current breaking changes -- minus the Lua version one, of course; that will still require our workaround (or something similar) or for Homebrew and/or MacPorts to start offering Lua 5.4, which they will, it's just not clear when.

[latenitefilms]

@asmagill - In regards to the Lua version issue, could we just manually include the paths to the previous Lua version as a workaround, so Hammerspoon always supports the paths of one earlier Lua version?

[asmagill]

It's not just a question of paths; that could be manually set in your init.lua by manipulating package.path and package.cpath yourself. And if all luarocks were only lua code with no compiled components, I could maybe see doing that.

The issue is the the C-API that Lua provides for extensions to the language changes -- a module with binary components (be it from LuaRocks or from Hammerspoon or by compiling it yourself) compiled for Lua 5.3 can't be loaded by Lua 5.4 (and vice-versa). If the major number of the Lua interpreter changes (in this case from 3 to 4), modules are binary-incompatible.

This isn't an issue between minor version numbers (say 5.4.0 and 5.4.1, once it's available) -- they are binary compatible -- so it shouldn't come up too often.

[asmagill]

With #2488 landed, are the issues in this thread addressed or is there still something outstanding?

[jacobisaliveandwell]

@asmagill fair enough. makes sense. thanks for jumping on this so quickly!

[kgutwin]

I just raised #2508, a regression in hs.urlevent.httpCallback. It seems to be related to changes in hs.window.

[asmagill]

@tokuchan please check out https://github.com/Hammerspoon/hammerspoon/wiki/Luarocks-and-Hammerspoon and see if following the instructions there will allow you to reinstall fennel for lua 5.4 and the latest Hammerspoon release.

[erikcw]

I followed the procedure on the wiki, but compiliing lua-5.4.1 (and 5.4) results in the following error on my Mac.

➜  lua-5.4.1 make macosx
/Applications/Xcode.app/Contents/Developer/usr/bin/make all SYSCFLAGS="-DLUA_USE_MACOSX -DLUA_USE_READLINE" SYSLIBS="-lreadline"
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lapi.o lapi.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE  -Os -c lcode.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lctype.o lctype.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o ldebug.o ldebug.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o ldo.o ldo.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o ldump.o ldump.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lfunc.o lfunc.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lgc.o lgc.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE  -Os -c llex.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lmem.o lmem.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lobject.o lobject.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lopcodes.o lopcodes.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE  -Os -c lparser.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lstate.o lstate.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lstring.o lstring.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o ltable.o ltable.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o ltm.o ltm.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lundump.o lundump.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lvm.o lvm.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lzio.o lzio.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lauxlib.o lauxlib.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lbaselib.o lbaselib.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lcorolib.o lcorolib.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o ldblib.o ldblib.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o liolib.o liolib.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lmathlib.o lmathlib.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o loadlib.o loadlib.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o loslib.o loslib.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lstrlib.o lstrlib.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o ltablib.o ltablib.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lutf8lib.o lutf8lib.c
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o linit.o linit.c
ar rcu liblua.a lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o lcorolib.o ldblib.o liolib.o lmathlib.o loadlib.o loslib.o lstrlib.o ltablib.o lutf8lib.o linit.o
ar: `u' modifier ignored since `D' is the default (see `U')
ranlib liblua.a
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE    -c -o lua.o lua.c
gcc -std=gnu99 -o lua   lua.o liblua.a -lm -lreadline
ld: warning: ignoring file liblua.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
Undefined symbols for architecture x86_64:
  "_luaL_callmeta", referenced from:
      _msghandler in lua.o
  "_luaL_checkstack", referenced from:
      _pmain in lua.o
      _doREPL in lua.o
  "_luaL_checkversion_", referenced from:
      _pmain in lua.o
  "_luaL_error", referenced from:
      _pmain in lua.o
      _lstop in lua.o
  "_luaL_len", referenced from:
      _pmain in lua.o
  "_luaL_loadbufferx", referenced from:
      _doREPL in lua.o
      _dostring in lua.o
  "_luaL_loadfilex", referenced from:
      _pmain in lua.o
  "_luaL_newstate", referenced from:
      _main in lua.o
  "_luaL_openlibs", referenced from:
      _pmain in lua.o
  "_luaL_traceback", referenced from:
      _msghandler in lua.o
  "_lua_close", referenced from:
      _main in lua.o
  "_lua_concat", referenced from:
      _doREPL in lua.o
  "_lua_createtable", referenced from:
      _pmain in lua.o
  "_lua_gc", referenced from:
      _pmain in lua.o
  "_lua_getglobal", referenced from:
      _pmain in lua.o
      _doREPL in lua.o
      _pushline in lua.o
  "_lua_gettop", referenced from:
      _pmain in lua.o
      _doREPL in lua.o
      _dostring in lua.o
  "_lua_pcallk", referenced from:
      _main in lua.o
      _pmain in lua.o
      _doREPL in lua.o
      _dostring in lua.o
  "_lua_pushboolean", referenced from:
      _pmain in lua.o
  "_lua_pushcclosure", referenced from:
      _main in lua.o
      _pmain in lua.o
      _doREPL in lua.o
      _dostring in lua.o
  "_lua_pushfstring", referenced from:
      _doREPL in lua.o
      _msghandler in lua.o
      _pushline in lua.o
  "_lua_pushinteger", referenced from:
      _main in lua.o
  "_lua_pushlightuserdata", referenced from:
      _main in lua.o
  "_lua_pushlstring", referenced from:
      _pushline in lua.o
  "_lua_pushstring", referenced from:
      _pmain in lua.o
      _doREPL in lua.o
  "_lua_rawgeti", referenced from:
      _pmain in lua.o
  "_lua_rawseti", referenced from:
      _pmain in lua.o
  "_lua_rotate", referenced from:
      _pmain in lua.o
      _doREPL in lua.o
      _dostring in lua.o
  "_lua_setfield", referenced from:
      _pmain in lua.o
  "_lua_setglobal", referenced from:
      _pmain in lua.o
  "_lua_sethook", referenced from:
      _laction in lua.o
      _lstop in lua.o
  "_lua_settop", referenced from:
      _main in lua.o
      _pmain in lua.o
      _doREPL in lua.o
      _dostring in lua.o
      _pushline in lua.o
  "_lua_toboolean", referenced from:
      _main in lua.o
  "_lua_tointegerx", referenced from:
      _pmain in lua.o
  "_lua_tolstring", referenced from:
      _main in lua.o
      _pmain in lua.o
      _doREPL in lua.o
      _dostring in lua.o
      _msghandler in lua.o
      _pushline in lua.o
  "_lua_touserdata", referenced from:
      _pmain in lua.o
  "_lua_type", referenced from:
      _msghandler in lua.o
  "_lua_typename", referenced from:
      _msghandler in lua.o
  "_lua_warning", referenced from:
      _pmain in lua.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[2]: *** [lua] Error 1
make[1]: *** [macosx] Error 2
make: *** [macosx] Error 2

[asmagill]

Following the same instructions in the wiki article, the build output is identical to yours up to the line which reads ar: 'u' modifier ignored since 'D' is the default (see 'U') -- I don't see that, and instead see:

~
ranlib liblua.a
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE -c -o lua.o lua.c
gcc -std=gnu99 -o lua lua.o liblua.a -lm -lreadline
gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_MACOSX -DLUA_USE_READLINE -c -o luac.o luac.c
gcc -std=gnu99 -o luac luac.o liblua.a -lm -lreadline
~

With no linking errors...

First thought is about your build environment... do you maybe have build tools from Homebrew or MacPorts or a cross compiler for ARM (or other architecture) installed?

When I check the obvious culprits on my system I see the following paths:

~sh
$ which gcc
/usr/bin/gcc
$ which ar
/usr/bin/ar
$ which ranlib
/usr/bin/ranlib
$ which ld
/usr/bin/ld
$
~

[erikcw]

PATH=/usr/bin:/bin:/usr/sbin:/sbin make macosx did the trick. Looks like homebrew had installed some build tools in my path.

Thanks!