rochus-keller
LuaJIT bytecode generation for use with OpenResty
Hello! Please upgrade LuaJIT dependency to version 2.1-20201027 from stable OpenResty 1.19.3.1 package (/bundle/LuaJIT-2.1-20201027/) and modify the bytecode generation for it.
This will make it possible to use Oberon (and smalltalk, etc) to develop modern web applications based on nginx+ngx_lua(jit).
LJ 2.1 compatibility is on the list for the longer term. The differences between 2.0 and 2.1 in the bytecode are not that big. But I don't have the overview how the countless variants of LJ 2.1 differ. And at the moment I'm quite busy with other priorities (my new Oberon variant, and the debugger is still far from working the way I want). It's also questionable how many people actually want to use Oberon in OpenResty, and whether the Qt dependency won't get in the way.
Thanks for the answer!
It's also questionable how many people actually want to use Oberon in OpenResty, and whether the Qt dependency won't get in the way.
No Qt dependency needed for use with OpenResty. The code will be written in the your Oberon IDE and exported LuaJIT bytecode will be used in ngx_lua bundled luajit.
All of my stuff depends on Qt core (compiler, runtime, ide, you name it); I use Qt core instead of Boost.
All of my stuff depends on Qt core
Yes, I understand. I mean — the OberonIDE is used to write code and compile a bytecode, which is exported (by "Export binary..." menu option) and executed in OpenResty as ljbc.
For example, I compiled an old version of the OpenResty (1.4.3.6), compatible with LuaJIT 2.0.5, slightly modified scripts/(obnlj|Out).lua and ran the assembled bytecode (ljbc file) in OpenResty.
You can see the result in the screenshot:
Looks great; and you're lucky that Out.String and Out.ln are fully implemented in Lua; but have a look at ObLjbcGen.cpp, obnlj.lua, ObLjLib.cpp and ObLjLibFfi.cpp; depending on which Oberon features you use one of the latter two is involved, and ObLjLib.cpp is also dependent on Qt; the forthcoming Obx* implementation depends on Qt as well; getting rid of the Qt dependency requires quite some work, and even then you still need a native shared library.