I have been struggling a lot to get this to work.
Can someone provide an example with any LUA api of 2 scripts that pass a message back and forth.
I have tried Oil, lua-ipc and zeromq.
But I face several missing libraries issues.
The ultimate goal is to pass a vector of numbers from one Lua process to another Lua process (with a different version of Lua) without going through disk.
Here is a similar example in python of IPC in a single file. Something similar in lua would be extremely helpful.
I really need an example as my knowledge in pipes or UDP/TCP is not strong.
The equivalent would be to use luasocket. These examples come very close to the python example given. Here socket:receive() is used for the framing.
https://github.com/diegonehab/luasocket/blob/master/samples/listener.lua
https://github.com/diegonehab/luasocket/blob/master/samples/talker.lua
Related
I have some existing server code written in C++, Node.js and Python that I would like to port to WASM. This code makes heavy use of UDP/TCP sockets. Ideally with little to no modification of the code.
I know this type of question has been asked a number of times, and the answer is to convert them to websockets and use a bridge. However, this adds another moving part that I'd like to avoid if at all possible.
The code runs as a service on desktop, not in the browser. I know that there's a WASI proposal for sockets that is implemented by WasmEdge.
I'm quite new to WASM and still a little hazy on how it all fits together. Any advice on how to solve this would be greatly appreciated.
Thanks in advance!
I've tried two approaches and am unsure how best to proceed:
#1 Use WasmEdge - but I don't quite understand how to compile to WASM in a way that will take advantage of WasmEdge's socket support. For example, using emscripten will always convert the sockets to websocket.
#2 Create a Node.js wrapper that handles the sockets directly and passes the contents of the buffers back and forth with the embedded WASM module. This isn't ideal as I'd have to modify the source code or at the least create a shim of some kind to replace networking.
I can easily launch two or more separate Lua programs (running on LuaJIT2) on the same machine. But is there any way how these programs can communicate?
The best solution I can come up with is that each program can write a text file that orher program can read. But this is ree-aalllyyy slow solution (even if text files are saved on virtual RAM disks).
I know that thera are zeromq and other things that may help with this... The problem is that instructions are just too long and complicated / confusing (for me at least).
Any recommendations? Especially some working code example would be appreciated, no matter how simple. Even how to pass value of one variable from one LuaJIT2 process to another.
(I'm using Windows XP SP3, if that matters...)
Essentially, they keyword you should be looking for is "IPC" (Inter-Process Communication).
Some of the options you might want to explore:
Shared files
Shared memory
Network Sockets
Pipes (on POSIX systems)
Middleware utilizing one of the above
I can't really say that one of them is the best. The choice would depend on the other factors (needed speed, latency, what do you want to communicate), that you didn't provide. I just hope I pointed you in the right direction.
Also, if ZeroMQ is too complicated, i highly recommend you more reading, rather than looking for even simpler code examples. Lua is "do-it-yourself" language.
If you aren't really stick to Lua, take a look at PyRo (Python Remote Objects). Or you might want to implement something like this yourself.
I'm looking at moving a program that currently embeds a Python interpreter to use Lua. With Python it's fairly easy to use modulefinder, compileall, and zipfile to make a nice tidy zip containing all the external libraries used.
Does Lua have the ability to bundle up its libraries like that, or is there some better best practice for distributing programs that embed Lua?
As is typical with Lua, there's no one standard and a lot of people roll their own.
There's an effort to standardize on a package-management system called Lua Rocks, but I'm not sure how much momentum is behind it or how mature it is. (In 2008 it was not quite ready for prime time, but things may have changed.)
I myself am very low tech: if I want to distribute something, I just turn my Lua sources into C files and link them in with the binary. Finding and converting all the modules could be a bit tedious for me, but quite the easiest thing for my users—they don't even need to know that Lua is involved. I've posted a copy of my lua2c script at Pastebin. I have the option of compiling but I generally don't compile because the results are not portable and because the Lua compiler is so fast anyway.
It would be nice to have something more automated. I think it would probably take several days to write and debug a good tool.
People on the Lua mailing list will surely know more.
If it is pure Lua, you might also consider using squish
It's a tool that packs all Lua source files into a single file, with options to gzip/minify it.
I've skimmed Programming in Lua, I've looked at the Lua Reference.
However, they both tells me this function does this, but not how.
When reading SICP, I got this feeling of: "ah, here's the computational model underlying scheme"; I'm trying to get the same sense concerning Lua -- i.e. a concise description of it's vm, a "how" rather than a "what".
Does anyone know of a good document (besides the C source) describing this?
You might want to read the No-Frills Intro to Lua 5(.1) VM Instructions (pick a link, click on the Docs tab, choose English -> Go).
I don't remember exactly where I've seen it, but I remember reading that Lua's authors specifically discourage end-users from getting into too much detail on the VM; I think they want it to be as much of an implementation detail as possible.
Besides already mentioned A No-Frills Introduction to Lua 5.1 VM Instructions, you may be interested in this excellent post by Mike Pall on how to read Lua source.
Also see related Lua-Users Wiki page.
See http://www.lua.org/source/5.1/lopcodes.h.html . The list starts at OP_MOVE.
The computational model underlying Lua is pretty much the same as the computational model underlying Scheme, except that the central data structure is not the cons cell; it's the mutable hash table. (At least until you get into metaprogramming with metatables.) Otherwise all the familiar stuff is there: nested first-class functions with mutable local variables (let-bound variables in Scheme), and so on.
It's not clear to me that you'd get much from a study of the VM. I did some hacking on the VM a while back and it's a lot like any other register-oriented VM, although maybe a bit cleaner. Only a handful of instructions are Lua-specific.
If you're curious about the metatables, the semantics is described clearly, if somewhat verbosely, in Section 2.8 of the reference manual for Lua 5.1. If you look at the VM code in src/lvm.c you'll see almost exactly that logic implemented in C (e.g., the internal Arith function). The VM instructions are specialized for the common cases, but it's all terribly straightforward; nothing clever is involved.
For years I've been wanting a more formal specification of Lua's computational model, but my tastes run more toward formal semantics...
I've found The Implementation of Lua 5.1 very useful for understanding what Lua is actually doing.
It explains the hashing techniques, garbage collection and some other bits and pieces.
Another great paper is The Implmentation of Lua 5.0, which describes design and motivations of various key systems in the VM. I found that reading it was a great way to parse and understand what I was seeing in the C code.
I am surprised you refer to the C source for the VM as this is protected by lua.org and the tecgraf/puc rio in Brazil specially as the language is used for real business and commercial applications in a number of countries. The paper about The Implementation of lua contains details about the VM in the most detail it is permitted to include but the structure of the VM is proprietary. It is worth noting that versions 5.0 and 5' were commissioned by IBM in Europe for use on customer mainframes and their register-based version have a VM which accepts the IBM defined format of intermediate instructions.
I am trying to build out a useful 3d game engine out of the Ogre3d rendering engine for mocking up some of the ideas i have come up with and have come to a bit of a crossroads. There are a number of scripting languages that are available and i was wondering if there were one or two that were vetted and had a proper following.
LUA and Squirrel seem to be the more vetted, but im open to any and all.
Optimally it would be best if there were a compiled form for the language for distribution and ease of loading.
One interesting option is stackless-python. This was used in the Eve-Online game.
The syntax is a matter of taste, Lua is like Javascript but with curly braces replaced with Pascal-like keywords. It has the nice syntactic feature that semicolons are never required but whitespace is still not significant, so you can even remove all line breaks and have it still work. As someone who started with C I'd say Python is the one with esoteric syntax compared to all the other languages.
LuaJIT is also around 10 times as fast as Python and the Lua interpreter is much much smaller (150kb or around 15k lines of C which you can actually read through and understand). You can let the user script your game without having to embed a massive language. On the other hand if you rip the parser part out of Lua it becomes even smaller.
The Python/C API manual is longer than the whole Lua manual (including the Lua/C API).
Another reason for Lua is the built-in support for coroutines (co-operative multitasking within the one OS thread). It allows one to have like 1000's of seemingly individual scripts running very fast alongside each other. Like one script per monster/weapon or so.
( Why do people write Lua in upper case so much on SO? It's "Lua" (see here). )
One more vote for Lua. Small, fast, easy to integrate, what's important for modern consoles - you can easily control its memory operations.
I'd go with Lua since writing bindings is extremely easy, the license is very friendly (MIT) and existing libraries also tend to be under said license. Scheme is also nice and easy to bind which is why it was chosen for the Gimp image editor for example. But Lua is simply great. World of Warcraft uses it, as a very high profile example. LuaJIT gives you native-compiled performance. It's less than an order of magnitude from pure C.
I wouldn't recommend LUA, it has a peculiar syntax so takes some time to get used to. Depending on who will be doing the scripting, this may not be a problem, but I would try to use something fairly accessible.
I would probably choose python. It normally compiles to bytecode, so you would need to embed the interpreter. However, if you must you can use PyPy to for example translate the code to C, and then compile it.
Embedding the interpreter is no issue. I am more interested in features and performance at this point in time. LUA and Squirrel are both interpreted, which is nice because one of the games i am building out is to include modifiable code, which has an editor in game.
I would love to hear about python, as i have seen its use within the battlefield series i believe.
python is also nice because it has actual OGRE bindings, just in case you need to modify something lower-level on the fly. I don't know of any equivalent bindings for Lua.
Since it's a C++ library, I would suggest either JavaScript or Squirrel, the latter being my personal favorite of the two for being even closer to C++, in particular to how it handles tables/structs and classes. It would be the easiest to get used to for a C++ coder because of all the similarities.
However, if you go with JavaScript and find an HTML5 version of Ogre3D, you should be able to port your game code directly into the web version with minimal (if any) changes necessary.
Both of these are a good choice, and both have their pros and cons, but both would definitely be the easiest to learn since you're likely already working in C++. If you're working with Java, the same may hold true, and if it's Game Maker, you wouldn't need either one unless you're trying to make an executable that people wouldn't need Game Maker itself to run, in which case, good luck finding an extension to run either of these.