pLua Beta available

[Robert Kosek]

That works like a charm, thanks.

How would a register an "assignment" protocol to the object in addition to the indexer? Or, if the indexer has to go, then just the assignment protocol. So I can assign a table and then walk it to get the values. If you could help point me in the right direction there it would be much appreciated.

Oh, just a quick question. Is the UnhandledReader/UnhandledWriter support for array-like access only, or can it be used for assignment in a "ar = {}" command?

Edit:

Actually, now that I think about it more, I'm going to end up with a "recursive" associative array that will end up providing my templates. So maybe registration of the type is unnecessary. Instead I could, like you advised awhile back, use a surrogate function and pass the table plus an identifier string to a function.

So since I'm still unclear as to how, how would I declare/register a function to accept two parameters (first a string, then a table) and then in the function begin to walk the table into an associative array?

EG:

MyStuff = {
  "var1" = "whatever",
  "var2" = 42.42424242
}
AddTemplate('TMyStuff:2001', MyStuff);

I kinda understand how to use the function lua_next to walk the table, but not how to get the table's ID and then pass through the walk-loop. You don't need to write it all, I just need to understand Lua's stack concept--which is kinda painful.

[jdarling]

In order to handle the ar={} problem you would have to override the global indexer's. This can cause some real problems within the Lua environment, though many people do it, and I haven't played with the idea enough to actually suggest a good way of doing it. Remember the indexer is at the parent (meaning the ar.__index and ar.__newindex will handle ar.* and ar[*] calls).

As for registering a method that will accept a string and a table. There are two ways to do this in pLua; First is to use the normal Lua way of handling the passed in params.[pascal]function lua_AddTemplate(L : PLua_State) : Integer; cdecl;
var
fieldName,
TemplateName : AnsiString;
begin
result := 0;
// First check to make sure that ONLY 2 params got passed in
// it would be a good idea to check to see if we have the proper
// types coming in, but I'm not doing that
if lua_gettop(L) <> 2 then
exit;
// Now get the TemplateName
TemplateName := pLua_tostring(L, 1); // 1st param
lua_pushnil(L);
while (lua_next(L, 2) <> 0) do
begin
fieldName := plua_tostring(l,-2);// get the key
// the value is at -1, you can do something with it here
end;
lua_pop(L, 1); // remove our working table and the last nil pointer
end;[/pascal]

The second way would be to use pLua's built in variant handlers and read the passed in table as a variant array. You will need a temporary string list to hold the key names:[pascal]function lua_AddTemplate(L : PLua_State) : Integer; cdecl;
var
lua_values : Variant;
lua_keys : TStringList;
TemplateName : AnsiString;
begin
result := 0;
if lua_gettop(L) <> 2 then
exit;
lua_keys := TStringList.Create;
try
TemplateName := plua_tostring(L, 1);
lua_values := plua_TableToVariantArray(L, 2, lua_keys);
// Now you can itterate lua_values as an array and lua_keys contains
// the keys for each table element.
finally
lua_keys.Free;
end;
end;[/pascal]

As for registering your method, its the same in both cases. Either use your TLua instance's RegisterMethod or use pLua's built in RegisterMethod call to register it to the global environment.

I did all of the above freehand without and IDE so there may be a few typo's, but it should get the idea across.

[Robert Kosek]

Yeah, I get the idea.

After looking at pLua's implementation of TableToVariantArray and ToVariant, I see a potential problem: collision. If I used a series of subtables to describe parts of data that my application read, not even the keys would help because the keys would be reused. Now, if we concatenated the sub-tables key/name into the keys beneath it (including any of its sub-tables) we could completely avoid collision.

Just an idea, but one I think could become important.

I'll tinker around with trying to figure out how to handle the child tables, but no promises that I get anything put together. At least nothing stable/fast anyway. But I'll give it a whirl when I get some free time.

EDIT:

Yesterday evening I came up with a way to make a multi-depth associative array, based off the prior class, by including a child object reference. I haven't tried it yet, but as a rule it shouldn't be too hard. What I'll do is include a pointer stack for the last accessed items and then be able to restore a prior point. This way for parent/child searching all it takes is a few pushes and pops and you still have a reference to the base parent. I think I can base the function for table conversion off this same logic, though access would require:

  myarray[['grandparent','parent','child']];

As an array of string would be the indexer and not a normal string. (I'm quite sure index functions can't be varargs. :lol

[tuxscreen]

Hi Jeremy,

nice tool. As I'd like to use it in my delphi projects I tried it and had to fix
it in some places to get it to compile.

I would dive in and send you a patched version, but I think this might be already too late, because you might have already worked on it, so a diff against my version would not help.

I had to patch the following items:
PtrInt is not defined in delphi, FPC helpfile tells me that this type is deprecated and we should use PtrUInt or something completely different?
(BTW. I've still not dived deep enough into the LUA stuff to test this PtrInt routines )

Some files contain {$MODE..} compiler switches w/o the surrounding ifdefs for FPC.

event-handler assignments dont use the @-operator in delphi, I dont know fpc very well, but I there must be a way for both worlds.

I fixed also many warnings and hints the compiler throwed at me, but these where mostly unused variable stuff and if clauses which are always true...

I would like to participate in this "little" project and test against the latest delphi compilers, if you like.

Greetings
Marc