Re: Extending Lua-RPC: questions about handling index and call events

[Geoff Leyland <geoff_leyland@...>]

On 5/06/2009, at 2:39 AM, James Snyder wrote:
> > > math.cos(handle.some_remote_value)
>
> Hmm..  So, executing the line above gives you the following bytecode:
> main <test.lua:0,0> (6 instructions, 24 bytes at 0x1dd5530)
> 0+ params, 2 slots, 0 upvalues, 0 locals, 4 constants, 0 functions
> 	1	[1]	GETGLOBAL	0 -1	; math
> 	2	[1]	GETTABLE 	0 0 -2	; "cos"
> 	3	[1]	GETGLOBAL	1 -3	; handle
> 	4	[1]	GETTABLE 	1 1 -4	; "some_remote_value"
> 	5	[1]	CALL     	0 2 1
> 	6	[1]	RETURN   	0 1
>
> This is tougher than the other metatable stuff because after getting  
> the cos function onto the stack, locally, I'm putting a  
> some_remote_value userdata for it to operate on locally.   
> Unfortunately, it's not a lua number however, it's a userdata.   
> Looking at how this is implemented in lua, I don't see how I can  
> hook this in such a way that I can have that userdata behave like a  
> number.

Sorry, I got that one wrong - I can see how  
handle.math.cos(handle.some_remote_value) could be done in one round  
trip to the server, but I agree that  
math.cos(handle.some_remote_value) is not going to work and I can't  
see a way around math.cos(rpc.get(handle.some_remote_value)).  You'd  
need some kind of c++ cast operator - maybe you could campaign for a  
__tonumber metamethod in Lua 5.2?

> This, I suppose, is the crux of this issue: how do I know whether to  
> push userdata onto the local stack, or to serialize the remote value  
> and put that actual value on the stack instead?
>
> handle.math.cos(handle.some_remote_value) wouldn't be as much of a  
> problem, since I could push over the index events to get  
> some_remote_value onto the remote stack for the remote cos.
>
> I guess one way to deal with this would be to handle things this way  
> for remote indexes:
>
> if type is number, string, boolean, or nil:
> 	serialize it and put it on the local stack,
> otherwise:
> 	provide lazy evaluation helper
>
> There are probably a bunch of disadvantages I'm not thinking of  
> here, but I think, for sure, I have to point the index to some sort  
> of proxying function that actually gets the remote value, otherwise  
> I'll end up with a local cached value on the local table (which  
> would be undesirable if the value changed on the remote side and I  
> wanted to poll it).

Does this mean you'd have to go and ask the server at each __index?   
But then, "for k, v in pairs(handle.some_remote_table) do..." wouldn't  
work either.  (Campaign for __pairs in Lua 5.2?)

> > > Interesting, is Rima available somewhere?  I might be interested  
> > > in taking a look just to see if I might learn a bit from the  
> > > implementation.

http://www.incremental.co.nz/download/rima-0.01.tar.gz

Just ignore all the solver stuff and have a look at the symbolic math  
stuff.  rima/ref.lua is probably where the interesting stuff happens.   
Rima does not do this nicely yet - it's more that I aim to have it  
looking like what you're talking about one day.

> I could see some advantage to doing something like what you describe  
> above where you might have a client talking to multiple lua  
> instances to either poll them for state information, or to do work  
> on them.  If you wrap things with some sort of map function and use  
> it to work on large chunks of data over a series of connections  
> registered on a table or something.
>
> I'm mainly working on this for use with eLua (hence the serial link  
> protocol being supported (which is giving me some headaches) ), so  
> that I can have a link to an embedded device and do development and  
> testing while having the benefit of being able to get large  
> quantities of data back to a desktop machine.  There might be  
> benefit to being able to use this sort of thing to poll a bunch of  
> embedded devices in succession over a network or wireless link.

Distributing workloads seems like an obvious use?