[GeanyLua] For version 5.4.3?

[jradxl]

Any change this plugin will be upgraded to Lua 5.4.3 any time soon?

[elextr]

Since Geanylua is orphaned (ie has no maintainer) I suspect it will be a case of someone needing to do it.

[xiota]

LuaJIT appears to be a drop-in replacement for Lua 5.1 that would require only build script or other minor changes. Based on Git activity, LuaJIT is actively maintained. Perhaps GeanyLua could switch to LuaJIT (issue #1228)?

[elextr]

As I noted above, the plugin is orphaned, so somebody needs to take it over and then make the change.

[xiota]

I am willing to look into what would be necessary to switch to LuaJIT, but if there would be opposition to such a change, it wouldn't be worth the effort.

In principle, switching to LuaJIT should be easier than switching to Lua 5.4+ because LuaJIT is intended to be a drop-in replacement for Lua 5.1. LuaJIT appears to be actively maintained, while Lua 5.1 has been deprecated for nearly two decades. At the moment, it's working, but there's a possibility that it will eventually be dropped by some distros or stop compiling because of some future gcc, glibc, or other update.

[elextr]

Well, there is no plugin maintainer to object ;-)

The simplest solution would be just to make it a new plugin ("Geanyluajit" maybe) until its stable and supports the platforms the existing one does. That also means a Geanylua is still available while the distros get their heads around the new dependency.
Then Geanylua can be simply deleted when it breaks.

I can't figure out if the bundles include Geanylua and if a bundled lua dll is included for Windows (@eht16) or OSX (@techee)?

[techee]

It's not included for macOS - I don't remember why, if it was just that I didn't try or know how to use the plugin, or if there was some actual problem. Right now the macOS binary uses the "hardened runtime" where JIT is disabled but one can easily add a certain flag and enable it so it shouldn't be a problem.

[techee]

Lua 5.4 is not a drop-in replacement for Lua 5.1, so it would require major rewrites.

Just out of curiosity, what are the changes that make it hard to migrate to the new version?

[xiota]

Just out of curiosity, what are the changes that make it hard to migrate to the new version?

I'm not familiar with Lua, but took a look a while ago. I saw accumulated API-breaking changes. Compatibility functions/macros did exist between adjacent releases, but those that were of interest had been deprecated and removed by 5.4. Both 5.1 and 5.4 APIs would have to be learned well enough to almost be able to rewrite the plugin from scratch. Further, a 5.5 release, with more API-breaking changes, could be just a couple years away. (5.4 was released about 2.5 years ago. Average time between 5.x releases is about 4.5 years. Longest is 6 years.)

From LuaJIT Installation:

LuaJIT is API-compatible with Lua 5.1. If you've already embedded Lua into your application, you probably don't need to do anything to switch to LuaJIT, except link with a different library...

So it seems there's potential, with minimal effort, to switch to a maintained library with reduced concern for future API-breaking changes.

LuaJIT is supported on Windows and macOS. Packages are available for Debian and Fedora.

[xiota]

I just tried rebuilding GeanyLua with LuaJIT. It's fairly simple:

• Edit geanylua/*.c to use luaL_Reg instead of luaL_reg:
  • The real name of the struct is luaL_Reg. luaL_reg is defined for compatibility.
  • LuaJIT does not include the define for luaL_reg.
• Update build/geanylua.m4 to:
  • Refer to luajit instead of lua5.1
  • Use versions between 2.0 and 3.0 instead of 5.1 and 5.2.

Would a single PR be acceptable, or would separate PRs be preferred?

[techee]

I'm just wondering - what problem does the migration to luajit try to solve? As far as I can say, Lua 5.1 is available as a package and offered by distributions. I've just checked luajit's open bugs and one of them is this one

LuaJIT/LuaJIT#559

where it doesn't support pointer authentication which is used on ARM-based Apple computers:

https://support.apple.com/guide/security/operating-system-integrity-sec8b776536b/web

If there is some compelling reason to move to luajit, it might be worth it and sacrifice the macOS version of the plugin (which doesn't exist yet anyway) but I haven't seen such a reason mentioned above.

[elextr]

geany/geany-osx#41 (comment) seems to suggest that the plugin will never work on Windows or Wayland either.

If "somebody" contributed it I bet it could just hook into the Geany keyevents and use GDK platform independently like Geany does.

[xiota]

There's no "problem" to "solve", per se.

• Changing luaL_reg to luaL_Reg would make for one less thing to fix when/if switching to a different Lua release, whether 5.4+ or LuaJIT.
• LuaJIT performs better, even with JIT turned off. Probably doesn't matter much for Geany.
• Switching to something else improves the chances of GeanyLua becoming maintained. Those with Lua 5.1 expertise have likely moved on to later 5.x releases or LuaJIT. Those without existing expertise are more likely to be willing to learn 5.4+ or LuaJIT.
• Since LuaJIT is a drop-in replacement for Lua 5.1, switching back and forth wouldn't be difficult. The build/*.m4 script might even be able to detect and support both.
• LuaJIT supports macOS, so it might be possible to make the currently non-existent (Intel) macOS version of the plugin exist. To workaround the ARM64e issue, Lua 5.1 could be used, if it works. If not, it's a wash and there is no "sacrifice" either way. Since LuaJIT is maintained, there's a reasonable chance the issue will be fixed sometime around when mainline Linux fully supports Apple M# processors.
• LuaJIT has some interesting features of its own, but that could break Lua 5.1 compatibility.
• Lua 5.1 is at risk of being dropped someday. Maybe not for another two decades, but the number of packages that use it is dwindling. In the distro I'm currently using, there are seven packages that depend on Lua 5.1, after excluding Lua 5.1 and modules. I recall that there were more in the past. At least one appears to have dropped Lua support entirely, rather than migrate. LuaJIT is almost as popular as Lua 5.4. There are nearly three dozen packages using LuaJIT, including gegl, mpv, obs, and vlc. There are over three dozen packages using Lua 5.4, while Lua 5.2 and 5.3 are unused.

[elextr]

IIUC the reason things like gegl moved to luajit was for speed, its a pixel manipulation library after all, they really don't care about whatever the new features of Lua 5.4 are since they just use Lua as an extension language, not an application language. And now there is an ecosystem of extensions in Lua 5.1 I doubt they want to upgrade to Lua 5.4 until Luajit supports it and then only if it is strictly Lua 5.1 backward compatible so existing Lua extensions work.

I would have thought Geanylua is in the same category, performance that minimises UI delays is important if Lua code runs between keystrokes, writing whole applications in Geanylua is not.

Given that Geanylua only appears to work on Linux X11 it is likely to become unusable from that before Lua 5.1 is removed, so I'm not sure if @xiota wants to invest the effort in porting to Luajit or Lua 5.4 before that is fixed.

Also @kugel- does Peasy support luajit?

[xiota]

Given that Geanylua only appears to work on Linux X11 it is likely to become unusable from that before Lua 5.1

Wayland is still feature incomplete. The number of distributions supporting X11 hasn't dwindled to a mere handful yet.

Are there any other X11 issues besides the key event hooks?

I'm not sure if xiota wants to invest the effort in porting to Luajit or Lua 5.4 before that is fixed.

I'm already using GeanyLua with LuaJIT. "Porting" was mostly changing the build script. My existing (simple) Lua scripts are working as expected with no change.

I keep revisiting GeanyLua because it's useful, but dislike using/working on it because it's on a deprecated for nearly two decades branch of Lua. LuaJIT seems to be the most expedient path.