Lua-RPC Coming

[jbsnyder]

Hi -

I just wanted to let folks know that I'm working on getting LuaRPC (http://q12.org/lua/index.html 
) up and running for eLua.  I've gotten it going with Lua 5.1.4 on the  
desktop, and it seems to be working to the degree that can initiate  
procedure calls with tables, numbers, etc.. as arguments, and get  
return values back over local socket connections.

The original code doesn't support shipping functions over the wire,  
but I think it should be possible to do this with lua_dump, so that  
one could modify functions on the remote "server" device (which in  
this case would be eLua).  I'll drop it into eLua when I get it  
working over serial, which I think, at least in principle, should be  
fairly easy.

If anyone is interested in looking at what I've done so far, you can  
find my modifications here:
http://github.com/jsnyder/luarpc/tree/master

The Lua API has gone through some interesting changes between 4.0.x  
and 5.1.x. I think I've mostly covered the bases as far as handling  
those differences, but the only testing I've done is with some  
examples provided by the original author.

Best.

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt
ph: [phone]


_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

Actually, I've just realized that one could do something similar to  
the following:
LOCAL:
fstring = string.dump(func)

remote.execfunc(fstring, inputval)

REMOTE:
function execfunc( fstring, input )
        func = loadstring(fstring)
        return func(input)
end

The are some limitations on the functions that can be used (only pure  
lua, no upvalues, etc..), but it seems to work :-)

This method then just makes use of the RPC mechanism for sending  
strings as input values for functions.

I don't think I'll be aiming to support sending anything other than  
chunks of Lua code over the wire, so I think this can be implemented  
with just a bit of syntactic sugar :-)

-jsnyder

On May 5, 2009, at 12:33 PM, James Snyder wrote:

> Hi -
>
> I just wanted to let folks know that I'm working on getting LuaRPC (http://q12.org/lua/index.html 
> ) up and running for eLua.  I've gotten it going with Lua 5.1.4 on  
> the desktop, and it seems to be working to the degree that can  
> initiate procedure calls with tables, numbers, etc.. as arguments,  
> and get return values back over local socket connections.
>
> The original code doesn't support shipping functions over the wire,  
> but I think it should be possible to do this with lua_dump, so that  
> one could modify functions on the remote "server" device (which in  
> this case would be eLua).  I'll drop it into eLua when I get it  
> working over serial, which I think, at least in principle, should be  
> fairly easy.
>
> If anyone is interested in looking at what I've done so far, you can  
> find my modifications here:
> http://github.com/jsnyder/luarpc/tree/master
>
> The Lua API has gone through some interesting changes between 4.0.x  
> and 5.1.x. I think I've mostly covered the bases as far as handling  
> those differences, but the only testing I've done is with some  
> examples provided by the original author.
>
> Best.
>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> [hidden email]
> http://fanplastic.org/key.txt
> ph: [phone]
>
> _______________________________________________
> Elua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt
ph: [phone]


_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

Hi -

I just wanted to let folks know that I'm working on getting LuaRPC (http://q12.org/lua/index.html) up and running for eLua.  I've gotten it going with Lua 5.1.4 on the desktop, and it seems to be working to the degree that can initiate procedure calls with tables, numbers, etc.. as arguments, and get return values back over local socket connections.

Excellent news!
 

The original code doesn't support shipping functions over the wire, but I think it should be possible to do this with lua_dump, so that one could modify functions on the remote "server" device (which in this case would be eLua).  I'll drop it into eLua when I get it working over serial, which I think, at least in principle, should be fairly easy.

Functions aren't hard, using lua_dump should do the trick just fine. The tricky part becomes apparent if the function uses any kind of globals. I think you can actually have a dumper that can send the full function environment, including its globals, by using the debug library to analyze it, but I wouldn't go there personally. Executing something like "pio.set(1)" remotely doesn't need any of that stuff, and it's what most people need anyway.
About serial/socket: you probably thought about this already, but just in case: remember to make your code as transport independent as possible. It would be nice to use the PC to call function from a robot running eLua via a radio connection at some point in the future :)
I'm also thinking about duplicating this for C functions; that is, having a very simple, restricted, yet functional RPC mechanism that would work directly for C functions. I did something like this with an AVR a while ago, and it worked quite nicely.
 

The Lua API has gone through some interesting changes between 4.0.x and 5.1.x. I think I've mostly covered the bases as far as handling those differences, but the only testing I've done is with some examples provided by the original author.

Hmmm. Anyone knows of a good test package for RPC systems? I don't.

Best,
Bogdan

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Tue, May 5, 2009 at 10:21 PM, James Snyder <[hidden email]> wrote:

Actually, I've just realized that one could do something similar to the following:
LOCAL:
fstring = string.dump(func)

remote.execfunc(fstring, inputval)

REMOTE:
function execfunc( fstring, input )
       func = loadstring(fstring)
       return func(input)
end

The are some limitations on the functions that can be used (only pure lua, no upvalues, etc..), but it seems to work :-)

This method then just makes use of the RPC mechanism for sending strings as input values for functions.

I don't think I'll be aiming to support sending anything other than chunks of Lua code over the wire, so I think this can be implemented with just a bit of syntactic sugar :-)

That sounds just abourt right. The main problem isn't sending the code I think, but rather serializing/deserializing the parameters/results, which I believe is also most of the work from Lua-RPC. I don't think we need to handle "tricky stuff" like recursive tables and such.

Other ideas that I find interesting:

- (almost) transparent remoting. By setting a metatable on _G, one can try to execute remotely calls that won't work locally. For example, if we do this on the PC:

start_remote()  -- this sets the metatable, also sets up the RPC transport if needed
print "Testme" -- local call, will work just fine
pio.set(1) -- the metatable will catch this call and try to execute it remotely instead of throwing an error immediately
end_remote()
pio.set(1) -- this time we'll get an error

This raises a number of interesting questions, like what happens if an assignment like "a = 1" happens inside a start_remote() block? Maybe this should also happen remotely, in which case a metatable with __newindex would also be fine. I wouldn't go this way though, it creates too much confusion. Or maybe the "print" in the above code example should also happen on the remote side? Lots of stuff to experiment with, in any case :)

- for RPC, you'd need a way to detect a failure on the transport and return this to the local caller; maybe by using the regular (nil, errormessage) Lua way.

- how exactly do you plan on implementing the transport part? Will it be a separate "thread" running on both the PC and the eLua board, or will it block both of them by doing RPC only? For example, while you do RPC, will you be able to use the shell on the eLua side? Cause you need some kind of listener for your RPC calls.

- can we do this both ways ? :) I mean, since we can call eLua from PC, it will only be fair to eLua to let it call the PC. The PC has nothing on eLua :)

Must return to some inhumanly boring work now, but I'll come back when I have new ideas.

Best,
Bogdan

-jsnyder

On May 5, 2009, at 12:33 PM, James Snyder wrote:

Hi -

I just wanted to let folks know that I'm working on getting LuaRPC (http://q12.org/lua/index.html) up and running for eLua.  I've gotten it going with Lua 5.1.4 on the desktop, and it seems to be working to the degree that can initiate procedure calls with tables, numbers, etc.. as arguments, and get return values back over local socket connections.

The original code doesn't support shipping functions over the wire, but I think it should be possible to do this with lua_dump, so that one could modify functions on the remote "server" device (which in this case would be eLua).  I'll drop it into eLua when I get it working over serial, which I think, at least in principle, should be fairly easy.

If anyone is interested in looking at what I've done so far, you can find my modifications here:
http://github.com/jsnyder/luarpc/tree/master

The Lua API has gone through some interesting changes between 4.0.x and 5.1.x. I think I've mostly covered the bases as far as handling those differences, but the only testing I've done is with some examples provided by the original author.

Best.

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt
ph: [phone]

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt
ph: [phone]

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[John Hind]

I am stuck in the “inhumanly boring” at the moment too – why will no one ever pay you to do anything interesting?

 

I still think there has to be something elegant to be done with serialising *closures* complete with their upvalues. So you send a closure from A to B and it has the values it needs from A as upvalues. That gets executed (parameterless) on B and can access and modify B’s environment. If a reply is needed, the A->B closure creates a new closure on B and dispatches it back to A for execution. The protocol could be that if calling a remote closure’s function returns a closure the run-time will return that closure to the sender.

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Bogdan Marinescu
Sent: 06 May 2009 09:20
To: eLua Users and Development List
Subject: Re: [eLua-dev] Lua-RPC Coming

 

That sounds just abourt right. The main problem isn't sending the code I think, but rather serializing/deserializing the parameters/results, which I believe is also most of the work from Lua-RPC. I don't think we need to handle "tricky stuff" like recursive tables and such.

Other ideas that I find interesting:[JH]  .....

 

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

On May 6, 2009, at 3:05 AM, Bogdan Marinescu wrote:

Hi -

I just wanted to let folks know that I'm working on getting LuaRPC (http://q12.org/lua/index.html) up and running for eLua.  I've gotten it going with Lua 5.1.4 on the desktop, and it seems to be working to the degree that can initiate procedure calls with tables, numbers, etc.. as arguments, and get return values back over local socket connections.

Excellent news!
 

The original code doesn't support shipping functions over the wire, but I think it should be possible to do this with lua_dump, so that one could modify functions on the remote "server" device (which in this case would be eLua).  I'll drop it into eLua when I get it working over serial, which I think, at least in principle, should be fairly easy.

Functions aren't hard, using lua_dump should do the trick just fine. The tricky part becomes apparent if the function uses any kind of globals. I think you can actually have a dumper that can send the full function environment, including its globals, by using the debug library to analyze it, but I wouldn't go there personally. Executing something like "pio.set(1)" remotely doesn't need any of that stuff, and it's what most people need anyway.
About serial/socket: you probably thought about this already, but just in case: remember to make your code as transport independent as possible. It would be nice to use the PC to call function from a robot running eLua via a radio connection at some point in the future :)

Yep, this is part of the idea, and is the next step I've started is separating out all the sockets stuff and adjusting the RPC code to use generic open/read/write/close functions that can be supplied by different transport layers.  I haven't decided exactly how I want to do it, but it would be nice to make it selectable when the RPC connection is initialized.  The existing code assumes the use of sockets, but it's got enough abstraction that making the interface generic shouldn't be too hard :-)

I'm open to suggestions on the model to use for the interface between the transport layer and the RPC layer.  Perhaps I'll take a look again at how the TCP/IP vs Serial terminal stuff is handled in eLua.

I'm also thinking about duplicating this for C functions; that is, having a very simple, restricted, yet functional RPC mechanism that would work directly for C functions. I did something like this with an AVR a while ago, and it worked quite nicely.

Interesting.  The existing module is built around two major things serializing lua data types and executing calls in a protected environment where errors can be custom-handled so that things get returned to the caller properly when things go south.

It should be possible to adapt things so that it'll work from the C layer as well, though, since the RPC layer just sends chunks of bytes, it might not be too hard to add a handling mechanism for that style of usage too.  I don't 

 

The Lua API has gone through some interesting changes between 4.0.x and 5.1.x. I think I've mostly covered the bases as far as handling those differences, but the only testing I've done is with some examples provided by the original author.

Hmmm. Anyone knows of a good test package for RPC systems? I don't.

Yeah, neither do I.  I think I may actually just do it by coming up with some unit tests for eLua and run them over RPC.  Obviously there are some differences and restrictions from running things locally, but if it works reasonably well for a range of behavior both locally and remotely, I would consider that acceptable.

There are some things that are more RPC specific, in terms of making sure it fails in the correct ways, but that could just be made optional for when being used in RPC mode.

I also like the idea of being able to run testing remotely with RPC since it means that there's a bit more flexibility for code to be used and for keeping track of results.  I don't like the idea of having an extra set of scripts for the romfs to do testing, that one has to decide whether or not to include, or having to send a large or multiple scripts over xmodem.

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

ph: [phone]

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

On May 6, 2009, at 3:19 AM, Bogdan Marinescu wrote:

On Tue, May 5, 2009 at 10:21 PM, James Snyder <[hidden email]> wrote:

Actually, I've just realized that one could do something similar to the following:
LOCAL:
fstring = string.dump(func)

remote.execfunc(fstring, inputval)

REMOTE:
function execfunc( fstring, input )
       func = loadstring(fstring)
       return func(input)
end

The are some limitations on the functions that can be used (only pure lua, no upvalues, etc..), but it seems to work :-)

This method then just makes use of the RPC mechanism for sending strings as input values for functions.

I don't think I'll be aiming to support sending anything other than chunks of Lua code over the wire, so I think this can be implemented with just a bit of syntactic sugar :-)

That sounds just abourt right. The main problem isn't sending the code I think, but rather serializing/deserializing the parameters/results, which I believe is also most of the work from Lua-RPC. I don't think we need to handle "tricky stuff" like recursive tables and such.

Other ideas that I find interesting:

- (almost) transparent remoting. By setting a metatable on _G, one can try to execute remotely calls that won't work locally. For example, if we do this on the PC:

start_remote()  -- this sets the metatable, also sets up the RPC transport if needed
print "Testme" -- local call, will work just fine
pio.set(1) -- the metatable will catch this call and try to execute it remotely instead of throwing an error immediately
end_remote()
pio.set(1) -- this time we'll get an error

This raises a number of interesting questions, like what happens if an assignment like "a = 1" happens inside a start_remote() block? Maybe this should also happen remotely, in which case a metatable with __newindex would also be fine. I wouldn't go this way though, it creates too much confusion. Or maybe the "print" in the above code example should also happen on the remote side? Lots of stuff to experiment with, in any case :)

Yeah, there are a lot of conceptual issues to consider there.  You could potentially make some of that bi-directional like if a remote call tries to find a but does not it can make a request back to the other end to get that variable.

I think the existing model needs to be adjusted to facilitate such back-and-forth behavor.

As far as the "RPC if no local exists" goes I think this would actually not be too hard to implement.  The way it works now is that you get a handle table when you open an rpc connection and doing an __index (used to be a gettable event) on entries in that table provides you with a helper (not sure why this double-layer is needed), and then you can call global functions through that helper.  I only have a __call metamethod on the helper so at the moment it only allows calling functions, but I should be able to adjust it to allow access to tables, numbers, etc..  I assume there's some global level call mechanism that could just be wrapped to check locally and then fall back to selected rpc handle if that fails.

- for RPC, you'd need a way to detect a failure on the transport and return this to the local caller; maybe by using the regular (nil, errormessage) Lua way.

It has exception handling for failures with the procedure calls themselves as well as the transport layer.  You can register a local error handler which gets an error message on, I think, both types of failure.  If you don't register one it comes back through a standard lua_error.

- how exactly do you plan on implementing the transport part? Will it be a separate "thread" running on both the PC and the eLua board, or will it block both of them by doing RPC only? For example, while you do RPC, will you be able to use the shell on the eLua side? Cause you need some kind of listener for your RPC calls.

There are two ways to handle this currently in LuaRPC. You can initialize a server with RPC_server, which is blocking and just waits on connections/calls.

Alternately you can do something like the following:

handle = RPC_listen (12345);

while 1 do

if RPC_peek (handle) then

RPC_dispatch (handle)

end

end

So you can open up the socket and only deal with calls when they've already come in.

As far as how to initialize things in eLua my thought was along the lines of having an option to have it, by default, come up in an RPC_server mode on a given transport and wait for RPC calls.  This would be off by default.  Something more compatible with the default mode would be to have a command that could be issued at the shell like "rpc" or something with an argument related to what transport/port to use, and that would fire up the listener on elua on that port.  My thought on that front, for an initial implementation, is to just take over the connection that the shell was open on, sort of like how xmodem does, and that will stay in control until no longer needed.

One nice thing about this latter approach is that it would be pretty easy to set up the desktop-side of the connection to start the rpc connection from the terminal if needed so one needn't do that manually.

Now as far as concurrency is concerned, you can do that within a script using the listen, peek, dispatch approach.  I suppose some sort of green threading could also be done with our yet-to-be-implemented Lua interrupts.

- can we do this both ways ? :) I mean, since we can call eLua from PC, it will only be fair to eLua to let it call the PC. The PC has nothing on eLua :)

I think this could go further than the bidirectionality mentioned above, but it will require that both sides have listeners going for incoming RPC requests.  I presume that if, right now, one starts a server on different ports on each side of a connection that requests can go both ways as long as things are run in non-blocking mode.  It would be interesting to see what work might be needed to do bi-directional calls over a single connection.

Must return to some inhumanly boring work now, but I'll come back when I have new ideas.

I have to do some of that too (mostly writing).

I also spent about 4 hours of yesterday, with students, explaining filtering, sampling while helping them debug their op-amp circuits, which I thought they had figured out the previous week :-)

I'll see what I get time for, but I think this should work pretty well with a bit of effort.

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

ph: [phone]

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

On May 6, 2009, at 5:47 AM, John Hind wrote:

I am stuck in the “inhumanly boring” at the moment too – why will no one ever pay you to do anything interesting?

 

I still think there has to be something elegant to be done with serialising *closures* complete with their upvalues. So you send a closure from A to B and it has the values it needs from A as upvalues. That gets executed (parameterless) on B and can access and modify B’s environment. If a reply is needed, the A->B closure creates a new closure on B and dispatches it back to A for execution. The protocol could be that if calling a remote closure’s function returns a closure the run-time will return that closure to the sender.

Yeah, this would be quite a neat feature.  I haven't inspected how lua_dump works to understand why upvalues get lost, but something that may be helpful is pluto:

http://luaforge.net/projects/pluto/

I haven't looked at the source, but it claims the following features:

* Can persist any Lua function

* Can persist threads 

* Works with any Lua chunkreader/chunkwriter 

* Support for "invariant" permanent objects, of all datatypes

* Can invoke metafunctions for custom persistence of tables and userdata

So, perhaps even if this is too heavy weight to use the whole thing some portions might be useful to help with serializing upvalues or other state information.

Ah, so many possibilities, so little time to evaluate them all...

-jsnyder

 

 

From: [hidden email] [[hidden email]] On Behalf Of Bogdan Marinescu
Sent: 06 May 2009 09:20
To: eLua Users and Development List
Subject: Re: [eLua-dev] Lua-RPC Coming

 

That sounds just abourt right. The main problem isn't sending the code I think, but rather serializing/deserializing the parameters/results, which I believe is also most of the work from Lua-RPC. I don't think we need to handle "tricky stuff" like recursive tables and such. 

Other ideas that I find interesting:[JH]  .....

 

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

ph: [phone]

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Wed, May 6, 2009 at 1:47 PM, John Hind <[hidden email]> wrote:

I am stuck in the “inhumanly boring” at the moment too – why will no one ever pay you to do anything interesting?

I'm starting to think this is some sort of conspiracy. But ssshhhhhh, they might hear us talking about it and get upset :)

I still think there has to be something elegant to be done with serialising *closures* complete with their upvalues. So you send a closure from A to B and it has the values it needs from A as upvalues. That gets executed (parameterless) on B and can access and modify B’s environment. If a reply is needed, the A->B closure creates a new closure on B and dispatches it back to A for execution. The protocol could be that if calling a remote closure’s function returns a closure the run-time will return that closure to the sender.

Elegant, for sure. But depending on how heavy weight the actual implementation of this proves to be in the end (and I really have no idea about this ATM), we'll consider if we want it or not. As usual, when torn between the beauty of having a full implementation that can do everything you throw at it, but which happens to be very heavy, and a not-so-complete implementation that is small and still covers most of the practical use scenarios, I'll automatically lean towards the practical side of the matter. This is how I'm built :) We can of course start with the smaller implementation, and build upon that if people want more.

Best,
Bogdan

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Bogdan Marinescu
Sent: 06 May 2009 09:20
To: eLua Users and Development List
Subject: Re: [eLua-dev] Lua-RPC Coming

 

That sounds just abourt right. The main problem isn't sending the code I think, but rather serializing/deserializing the parameters/results, which I believe is also most of the work from Lua-RPC. I don't think we need to handle "tricky stuff" like recursive tables and such.

Other ideas that I find interesting:[JH]  .....

 

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[John Hind]

I’m absolutely with you on that! For me, elegance is very much about being economical and extending the use of what is already there (which I guess is why I like Lua so much). When you start thinking about serialising values in Lua (either closure upvalues or ordinary tables) the complexity comes in if you try to cover all the cases (loops in tables, functions in tables, userdata etc.) – there is a place for that which has pretty much been covered by the existing “heavy-weight” serialisation libraries. I would limit serialisable upvalues to Number, String, Boolean and unlooped tables containing only these types plus nested tables with the same limits. The only function serialised would be the enclosured one.

 

Hopefully I can get on to doing some more work on this soon in PC Lua, but I’m disciplining myself not to buy any more hardware until I can get a single chip with 512k/64k or more and network support! I have too many “almost good enough” MPU development boards!

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Bogdan Marinescu
Sent: 09 May 2009 21:03
To: eLua Users and Development List
Subject: Re: [eLua-dev] Lua-RPC Coming

 

As usual, when torn between the beauty of having a full implementation that can do everything you throw at it, but which happens to be very heavy, and a not-so-complete implementation that is small and still covers most of the practical use scenarios, I'll automatically lean towards the practical side of the matter. This is how I'm built :)

 

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

Update and notes on LuaRPC:

I've now both gotten it working on 5.1.4 and have abstracted out the  
transport layer.  As it stands which "transport" one uses is a compile-
time option set by enabling or disabling some defines in config.h, but  
both serial (using pty to simulate real serial) and socket connections  
seem to be working at the moment for desktop use.  It's still somewhat  
rough around the edges, and I'd like to be able to support multiple  
transports from a single compilation, but I've not decided how I might  
want to do that yet (multiple modules?  function pointers that allow  
switching within a single module file?).

The existing module uses C-based exceptions to deal with transport-
layer errors (take a look at luarpc_rpc.h if you're interested).  I  
know we're not really using exceptions for most of the eLua modules,  
but I'm wondering whether I should leave that in place, or change that  
in order to be friendly to porting.  As it is set up, it doesn't have  
to derive from errno codes defined by system libraries (not sure  
whether Newlib provides an errno global), so if custom codes or  
strings are needed they can be set up.  I think, though, with the  
current flow, some exceptions will need to be thrown in order to  
enable connection resets when the client disappears, or if bad data is  
sent/received.

Additionally, argument handling for connection setup that varies  
between transports is included in the "transport" side of the code, so  
the API to the transport layer includes a few functions that want a  
lua_State.  This feels a bit undesirable to me since some of them push  
stuff onto the stack depending on what args are given to them, and  
that number has to be passed back up the chain of called functions,  
since none of the transport layer functions are called directly from  
Lua.

Also, beyond whatever was included in the original code, I've not done  
anything special security-wise to prevent clients from doing nasty  
things.  That said, if you were letting someone connect to a LuaRPC  
server, you were already letting them run arbitrary code on your  
server (unless you disable loadstring), so... :-)

I think I'll have an eLua serial backend going sometime in the near  
future, and I'll certainly mention that when it's ready to be abused.

Current work is still in the same place:
http://github.com/jsnyder/luarpc/tree/master

-jsnyder


On May 5, 2009, at 12:33 PM, James Snyder wrote:

> Hi -
>
> I just wanted to let folks know that I'm working on getting LuaRPC (http://q12.org/lua/index.html 
> ) up and running for eLua.  I've gotten it going with Lua 5.1.4 on  
> the desktop, and it seems to be working to the degree that can  
> initiate procedure calls with tables, numbers, etc.. as arguments,  
> and get return values back over local socket connections.
>
> The original code doesn't support shipping functions over the wire,  
> but I think it should be possible to do this with lua_dump, so that  
> one could modify functions on the remote "server" device (which in  
> this case would be eLua).  I'll drop it into eLua when I get it  
> working over serial, which I think, at least in principle, should be  
> fairly easy.
>
> If anyone is interested in looking at what I've done so far, you can  
> find my modifications here:
> http://github.com/jsnyder/luarpc/tree/master
>
> The Lua API has gone through some interesting changes between 4.0.x  
> and 5.1.x. I think I've mostly covered the bases as far as handling  
> those differences, but the only testing I've done is with some  
> examples provided by the original author.
>
> Best.
>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> [hidden email]
> http://fanplastic.org/key.txt
> ph: [phone]
>
> _______________________________________________
> Elua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt
ph: [phone]


_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

Can't wait to get my hands on that beauty! :)

Best,
Bogdan

On Thu, May 28, 2009 at 10:05 PM, James Snyder <[hidden email]> wrote:

Update and notes on LuaRPC:

I've now both gotten it working on 5.1.4 and have abstracted out the transport layer.  As it stands which "transport" one uses is a compile-time option set by enabling or disabling some defines in config.h, but both serial (using pty to simulate real serial) and socket connections seem to be working at the moment for desktop use.  It's still somewhat rough around the edges, and I'd like to be able to support multiple transports from a single compilation, but I've not decided how I might want to do that yet (multiple modules?  function pointers that allow switching within a single module file?).

The existing module uses C-based exceptions to deal with transport-layer errors (take a look at luarpc_rpc.h if you're interested).  I know we're not really using exceptions for most of the eLua modules, but I'm wondering whether I should leave that in place, or change that in order to be friendly to porting.  As it is set up, it doesn't have to derive from errno codes defined by system libraries (not sure whether Newlib provides an errno global), so if custom codes or strings are needed they can be set up.  I think, though, with the current flow, some exceptions will need to be thrown in order to enable connection resets when the client disappears, or if bad data is sent/received.

Additionally, argument handling for connection setup that varies between transports is included in the "transport" side of the code, so the API to the transport layer includes a few functions that want a lua_State.  This feels a bit undesirable to me since some of them push stuff onto the stack depending on what args are given to them, and that number has to be passed back up the chain of called functions, since none of the transport layer functions are called directly from Lua.

Also, beyond whatever was included in the original code, I've not done anything special security-wise to prevent clients from doing nasty things.  That said, if you were letting someone connect to a LuaRPC server, you were already letting them run arbitrary code on your server (unless you disable loadstring), so... :-)

I think I'll have an eLua serial backend going sometime in the near future, and I'll certainly mention that when it's ready to be abused.

Current work is still in the same place:
http://github.com/jsnyder/luarpc/tree/master

-jsnyder


On May 5, 2009, at 12:33 PM, James Snyder wrote:

Hi -

I just wanted to let folks know that I'm working on getting LuaRPC (http://q12.org/lua/index.html) up and running for eLua.  I've gotten it going with Lua 5.1.4 on the desktop, and it seems to be working to the degree that can initiate procedure calls with tables, numbers, etc.. as arguments, and get return values back over local socket connections.

The original code doesn't support shipping functions over the wire, but I think it should be possible to do this with lua_dump, so that one could modify functions on the remote "server" device (which in this case would be eLua).  I'll drop it into eLua when I get it working over serial, which I think, at least in principle, should be fairly easy.

If anyone is interested in looking at what I've done so far, you can find my modifications here:
http://github.com/jsnyder/luarpc/tree/master

The Lua API has gone through some interesting changes between 4.0.x and 5.1.x. I think I've mostly covered the bases as far as handling those differences, but the only testing I've done is with some examples provided by the original author.

Best.

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt
ph: [phone]

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt
ph: [phone]


_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev