On Tue, May 14, 2024 at 12:40:48PM +0100, Stuart Henderson wrote:
> On 2024/05/10 10:00, Thomas Frohwein wrote:
> > On Fri, May 10, 2024 at 09:44:42AM -0400, Thomas Frohwein wrote:
> > > On Fri, May 10, 2024 at 11:31:54AM +0100, Stuart Henderson wrote:
> > > > +cc op@, sorry I missed the maintainer line in ../Makefile.inc
> > > > [ original mail: https://marc.info/?l=openbsd-ports&m=171528886832093&w=2 ]
> > > >
> > > > On 2024/05/09 20:06, Thomas Frohwein wrote:
> > > > > On Thu, May 09, 2024 at 10:09:39PM +0100, Stuart Henderson wrote:
> > > > >
> > > > > [...]
> > > > >
> > > > > > How useful is love/0.10, does it still make sense to keep it?
> > > > >
> > > > > There are a couple of nice (commercial) games that run with love-0.10:
> > > > >
> > > > > $ ls -1 0.10
> > > > > blue-revolver
> > > > > britebot
> > > > > cityglitch
> > > > > marvellous-inc
> > > > > pocket-rumble
> > > > > soulstice
> > > > > spellrazor
> > > > >
> > > > > From my side not a reason to keep aging version of luajit alive and I
> > > > > would be ok with marking love/0.10 BROKEN to give a little time to see
> > > > > if it can be patched up to work with the luajit update...
> > > > >
> > > >
> > > > For the error I'm running into, it looks like it would be fixed by an
> > > > update to newer luasocket, though the commit which updates it in the
> > > > love2d tree is huge -
> > > > https://github.com/love2d/love/commit/8885fc621dd01c3b8dfd1abf063785103d9daf15.patch
> > > > - and doesn't directly apply to the version in 0.10.2 (and there's no
> > > > 0.10 branch in their git repo so tracking down other needed commits is
> > > > a bit awkward).
> > > >
> > > > How much would it suck to disable the jit for this version as is
> > > > already done for 0.8?
> > >
> > > I've built it with your diff and ran a few that I could: orthorobot
> > > from packages, as well as Britebot, Marvellous Inc., and Soulstice.
> > > All run fine. This is on a high-end CPU (Intel Xeon W-11955M), so the
> > > effect of not using the JIT may be more noticeable on lower end
> > > hardware. But this is still all very niche, so I think disabling the
> > > JIT is the right move. ok thfr@
> >
> > Just realized the games that I couldn't run (Blue Revolver, Britebot,
> > Spellrazor) still run with LuaJIT, so the diff breaks them. I still
> > think it's the right move for now to disable the JIT for love-0.10 at
> > this point.
> >
> > Here the errors when running without JIT in case this means more to
> > someone else:
> >
> > Spellrazor:
> > Error: Syntax error: main.lua:1: unexpected symbol near '#'
> > stack traceback:
> > (tail call): ?
> > [C]: ?
> > [C]: in function 'require'
> > [string "boot.lua"]:429: in function <[string "boot.lua"]:275>
> > [C]: in function 'xpcall'
> >
> > Blue Revolver (and similar with Cityglitch):
> > Error: lib/bitser.lua:24: module 'ffi' not found:
> > no field package.preload['ffi']
> > no 'ffi' in LOVE game directories.
> > no file 'ffi.so' in LOVE paths.
> > no file './ffi.lua'
> > no file '/usr/local/share/lua/5.1/ffi.lua'
> > no file '/usr/local/share/lua/5.1/ffi/init.lua'
> > no file '/usr/local/lib/lua/5.1/ffi.lua'
> > no file '/usr/local/lib/lua/5.1/ffi/init.lua'
> > no file './ffi.so'
> > no file '/usr/local/lib/lua/5.1/ffi.so'
> > no file '/usr/local/lib/lua/5.1/loadall.so'
>
> LuaJIT includes an FFI extension that isn't present in normal Lua.
> However there's an external version which is fairly similar to LuaJIT's
> which maybe worth trying: https://github.com/q66/cffi-lua
I tried this, but it looks like it can't replace luajit's ffi. First,
it's installed as cffi.so. If I add a symlink ffi.so, Blue Revolver
tries to load it, but errors:
Error: error loading module 'ffi' from file '/usr/local/lib/lua/5.1/ffi.so':
Unable to resolve symbol
stack traceback:
(tail call): ?
[C]: ?
[C]: in function 'require'
lib/bitser.lua:24: in main chunk
[C]: in function 'require'
game/replayplaylist.lua:2: in main chunk
[C]: in function 'require'
game/states/loading.lua:7: in main chunk
[C]: in function 'require'
main.lua:53: in main chunk
[C]: in function 'require'
[string "boot.lua"]:429: in function <[string "boot.lua"]:275>
[C]: in function 'xpcall'
I'm not sure what to make of this, if any ideas about debugging this or
if this shows clearly enough that it won't replace luajit's ffi...?
I'm attaching a tarball of cffi-lua port.
No comments:
Post a Comment