Iterating the eLua Globals table/mbed port

[John Hind]

I’ve at last got started with eLua using an mbed and building my own image from the latest trunk sources in a VirtualBox Ubuntu VM hosted on Windows 7. Surprisingly painless once I’d banged my head on a few pieces of Linux obscurantism for an hour or six!

 

Is it possible to iterate the Globals table fully from Lua? I tried the usual ‘for k in pairs(_G) do print(k) end’ and was momentarily dismayed not to see any of the standard libraries, let alone any additions. Then I tried iterating ‘math’ and then ‘coroutine’ the same way and found both were present and correct. After some poking around in the documentation I see what is happening: most of the global goodness is in a hidden rotable which (presumably) informs the __index metamethod in the _G table. Is there any way to iterate this hidden table? If not, could I suggest it would be a good idea to expose a reference to it in the _G table? Maybe keyed _R for readonly or _L for library?

 

The support for the mbed ‘semihosted’ filesystem is impressive, but poking around in the source code I was surprised to (eventually) find the code in the root ‘src’ directory with the generic eLua code. Surely this is highly specific to the mbed platform and ought to be in the platform/lpc17xx part of the tree, or even in a specific mbed sub-tree below that again?

 

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

[BogdanM]

Hi,

> I’ve at last got started with eLua using an mbed and building my own image
> from the latest trunk sources in a VirtualBox Ubuntu VM hosted on Windows 7.
> Surprisingly painless once I’d banged my head on a few pieces of Linux
> obscurantism for an hour or six!

You can also compile eLua from Windows:

http://www.eluaproject.net/en_building_win.html

> Is it possible to iterate the Globals table fully from Lua? I tried the
> usual ‘for k in pairs(_G) do print(k) end’ and was momentarily dismayed not
> to see any of the standard libraries, let alone any additions.

This is a bug, thanks for reporting it. Moreover, I distinctly
remember that this used to work. I'll investigate.

> The support for the mbed ‘semihosted’ filesystem is impressive, but poking
> around in the source code I was surprised to (eventually) find the code in
> the root ‘src’ directory with the generic eLua code. Surely this is highly
> specific to the mbed platform and ought to be in the platform/lpc17xx part
> of the tree, or even in a specific mbed sub-tree below that again?

Yes, definitely. Thanks, we'll move the source file where it belongs.

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

> This is a bug, thanks for reporting it. Moreover, I distinctly
> remember that this used to work. I'll investigate.

Sorry, my bad. This is actually supposed to happen at this
optimization level in order to save some more RAM. There is an
intermediate optimization level of LTR that eLua doesn't use, in that
mode you can see the full contents of _G. So yes, your idea of having
a separate _R table certainly makes sense. I'm also inclined to add a
__pairs metamethod, but your proposal keeps eLua closer to standard
Lua.

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

Hi,

A bit late :) but check this:

https://github.com/elua/elua/commit/3ee593f0ab7c45fae3ec1950a1c06240f89fb6f2

(not yet merged to trunk, still testing).

Thanks, John. Your message made me realize that something is conceptually wrong with the LTR patch and that it should be changed.

Best,

Bogdan

On Tue, Dec 7, 2010 at 8:46 PM, Bogdan Marinescu <[hidden email]> wrote:

> This is a bug, thanks for reporting it. Moreover, I distinctly
> remember that this used to work. I'll investigate.

Sorry, my bad. This is actually supposed to happen at this
optimization level in order to save some more RAM. There is an
intermediate optimization level of LTR that eLua doesn't use, in that
mode you can see the full contents of _G. So yes, your idea of having
a separate _R table certainly makes sense. I'm also inclined to add a
__pairs metamethod, but your proposal keeps eLua closer to standard
Lua.

Best,
Bogdan

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