LUA?

[Joubarbe]

Is there any plan to implement LUA in PB? I'm looking for a scripting language that can be hooked to PB for game purposes, and it seems the best option to me. I know there is an existing library somewhere, but having it in the standard library would be more consistent (ie. better implementation).

[the.weavster]

I agree that a scripting language would be a great addition but I've advocated MicroPython seeing as Python is the #1 programming language these days.

[Joubarbe]

Well, yes, even better! Any scripting language would be great

[idle]

I'd prefer a PBJit compiler, none of that interpreted stuff needed.

[skywalk]

Quit your whining. All you need is a MOV command!

[idle]

Quit your whining. All you need is a MOV command!

Lol that would be some work to debug.

[Quin]

I'd prefer a PBJit compiler, none of that interpreted stuff needed.

+1000. Only possible downside is I might have a heart attack due to this feature being added before I ever got to use it

[miso]

Quit your whining. All you need is a MOV command!

Thank You! That made me smile in the morning.

[jack]

I agree that a scripting language would be a great addition but I've advocated MicroPython seeing as Python is the #1 programming language these days.

does anyone have experience embedding MicroPython ?

with msys2 installed I was able to build the MicroPython interpreter using the following steps
I created a folder named "mupython"
launch mingw64.exe
cd mupyton
git clone https://github.com/micropython/micropython
cd mupyton/micropython/ports/windows
make submodules
make

micropython.exe is in mupyton\micropython\ports\windows\build-standard
but what I am really interested in is using MicroPython in PB

[PBJim]

I'd prefer a PBJit compiler, none of that interpreted stuff needed.

I'm certainly of the view that a JIT compiler could be extremely powerful, but would that mean the compiler's execution within an existing compiled PB executable would require the 'end user' of the object code to have a PB licence installed?

[jack]

ok, to make a static libmicropython is as simple as make lib
then if I copy the static lib into a temp folder and
ar x libmicropython.a
gcc -static -shared -o libmicropython.dll *.o -lbcrypt
I get libmicropython.dll
you may download the static lib and dll from https://u.pcloud.link/publink/show?code ... 17kYll0fuy

[benubi]

I experimented for many years with Lua and PB and would say NO.

First of all it can easily be made into an open-source (User) Library handling the frequent problems and version changes. PB team should focus on the main body of the language, the simple and basic libraries + Ogre which is already a ton of work. Also as others pointed out other languages are frequently favored over Lua - for example Python.

Lua lacks "batteries" that are implemented in Python for example; all Lua "batteries" (libraries) like network are 3rd party, have often compatibility broken problems on big lua version changes, and may not be platform independent + redundant or blocking (compared to PB network library).

Lua is a little picky on it's implementation style. It's either 100% embedded or 100% extension. Meaning either it's 100% static lib compiled and ALL dll's/.so's that are loaded as plugins/extensions MUST also be static library linked or there will be problems; or 100% extension aka using the dll/so with ALL additional plugins/extensions also 100% compiled with dll extension mode.

This sounds easy but here is the catch: for Windows the developer recommends to use the extension (dll) version, but for Linux the recommendation is to use the static lua lib. This is not as easy as it sounds, creating a working static Lua lib is surprisingly hard (for me, on Windows, using it in PureBasic)

Long story short: better make an (open source!) User lib that handles versions, static/dynamic switch.

Things can get complicated when different Lua version have to work together (interpreter, compiled-source and execution may be each of different version and/or static/dynamic)

I am currently writing some "replacement" for Lua tables. It's just a "blackboard" inspired, Lua inspired key-value storage with optional destructor callbacks etc. It will perform faster for many internal things but for now of course there's no interpreter, byte-code execution or "eval" command yet. I'd like to write something like a GOAP planner and perhaps even something like STRIPS/PDDL interpreter, and for that to make sense one needs a useful "blackboard" and Lua is too unstable (because of the aformentionned problems) or has lesser "low level support" e.g. you can't access a table via it's pointer, always have to go via the stack and eval to access data.

Where it would make perhaps sense to implement Lua: in the 3D library, even though it may overload it then. Reason: CEGUI support for Lua, and mapping & handling 3D library objects like meshes etc with Lua would be a lot of fun, except when you don't need it then it's only bloating the DLL even more.

[jack]

...
This sounds easy but here is the catch: for Windows the developer recommends to use the extension (dll) version, but for Linux the recommendation is to use the static lua lib. This is not as easy as it sounds, creating a working static Lua lib is surprisingly hard (for me, on Windows, using it in PureBasic)

if you have msys2 installed you basically just run make, or you could just compile all the c files using gcc and then ar rcs liblua.a *.o
if you have MSVC installed you could run the following from the console, changing the paths as needed

"D:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat" amd64
cd "lua-5.4.7\src"
cl /MD /O2 /c /GS- /DLUA_BUILD_AS_DLL *.c
ren lua.obj lua.o
ren luac.obj luac.o
link /DLL /IMPLIB:lua-5.4.7.lib /OUT:lua-5.4.7.dll *.obj
link /OUT:lua.exe lua.o lua-5.4.7.lib
lib /OUT:lua-5.4.7-static.lib *.obj
link /OUT:luac.exe luac.o lua-5.4.7-static.lib

[idle]

I'd prefer a PBJit compiler, none of that interpreted stuff needed.

I'm certainly of the view that a JIT compiler could be extremely powerful, but would that mean the compiler's execution within an existing compiled PB executable would require the 'end user' of the object code to have a PB licence installed?

I wouldn't think so if it only created a dll and it was statically linked into the program.
A number of years ago I made an experimental pb jit compiler with llvm in pb so its doable it was very limited but as an exercise it worked.

[PBJim]

I wouldn't think so if it only created a dll and it was statically linked into the program.
A number of years ago I made an experimental pb jit compiler with llvm in pb so its doable it was very limited but as an exercise it worked.

I'm just trying to visualise how that would operate. Would that require the PB compiler, and say, GCC or appropriate, installing on the executing machine — i.e. the machine with the runtime compiled PB executable?

And just as a wild idea, is the following sort of thing conceivable, or intended along these lines?

Code: Select all

mycode.s = "OpenConsole()" + #CRLF$
mycode.s + "PrintN(" + chr(34) + "Hello world" + chr(34)) + #CRLF$
mycode.s + "Delay(1000)" + #CRLF$

Jit(mycode.s, etc. etc.)

Therefore, I've created a PB executable and the executable itself is responsible for building the code dynamically. Then having constructed the code, it can call JIT.