On 10/04/2018 15:58, Russell Haley wrote:
> On Mon, Apr 9, 2018 at 5:53 PM, Chris Johns <chr...@rtems.org
> <mailto:chr...@rtems.org>> wrote:
> On 10/04/2018 10:40, Gedare Bloom wrote:
> > On Mon, Apr 9, 2018 at 4:17 PM, Russell Haley <russ.ha...@gmail.com
> <mailto:russ.ha...@gmail.com>
> > <mailto:russ.ha...@gmail.com <mailto:russ.ha...@gmail.com>>> wrote:
> > I'd like to start with getting other Lua scripts running.
> My goal is
> > to load a library called penlight that's a few dozens of
> files. Is
> > there a utility for creating and loading resources? I'll
> also look
> > at compiling the files using the luac compiler, but that's
> outside
> > of rtems.
> >
> > No worries. There is evolving support (pretty mature by now) for
> dynamically
> > loading object code, if that is what you mean: the Runtime Loader
> (RTL). I
> > don't have any experience with it though. Chris Johns is the expert on
> that topic.
> >
>
> The support is based around the standard calls 'dlopen' etc. You can load
> ELF
> object files. You do need a symbol table in the kernel and a simple
> makefile
> recipe can be found in the testsuite which works on the sparc simulator:
>
> https://git.rtems.org/rtems/tree/testsuites/libtests/Makefile.am#n319
> <https://git.rtems.org/rtems/tree/testsuites/libtests/Makefile.am#n319>
>
> (search for TEST_dl01 in the Makefile.am if the line has moved)
>
> Note, the erc32 sim does not have access to a host's file system so you
> will
> need to package the object files into a tar file just as the test does.
>
> Hi Chris, good to hear from you. Yes, the non-filesystem is what I'm trying to
> deal with. Lua can run as C or as Lua scripts. The dlopen support is excellent
> and I'll look into that when I start loading C. There are many fine Lua
> wrappers
> for some of the best C tools. Since, I'm trying to load lua scripts, the tar
> package sounds like what I need to look at first.
I did wonder what you are loading.
> Lua scripts can be loaded as a 'string' buffer (char array), or from a file.
> Either of those methods can load a text file or a Lua VM binary. Using binary
> is
> apparently faster to load, but must be compiled for the same architecture. The
> run speed is the same.
Python is similar.
> A simple Lua script to load a second module would look like this:
>
> local my_lib = require('mylib.init')
> local new_val = my_lib.dosomething()
>
> The require() function loads the file from a filesystem based on the
> package.path string. On my windows box, it looks like this:
>
> .\?.lua;C:\Program Files (x86)\LuaRocks\lua\?.lua;C:\Program Files
> (x86)\LuaRocks\lua\?\init.lua;C:\Program Files
> (x86)\LuaRocks\?.lua;C:\Users\russh\scripts\?\init.lua;C:\Users\russh\scripts\?.lua;C:\Users\russh;C:\Program
> Files (x86)\WinLua\Lua\5.3\bin\?53.dll;
>
> So, the require('mylib.init') would get translated so the '.' becomes the path
> separator on the filesystem, and any '?' in the package.path is replaced with
> the package name, eventually landing on C:\Users\russh\scripts\mylib\init.lua.
> Let's see how that translates to RTEMS...
>
Please keep us updated with your progress.
Chris
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
