lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Date: Thu, 3 Sep 2009 00:16:45 +0200
From: Petite Abeille <petite.abeille@gmail.com>

On Sep 3, 2009, at 12:06 AM, Andre de Leiradella wrote:

I really miss the times when Lua was just an embeddable script language. I could just compile all Lua libraries I wanted, make a host application or change lua.c to open the additional libraries, link everything and be happy.

No reason to miss anything, jut ignore the "Architecture Astronauts" and be merry :))

Haha, yeah, I think you're right.

Date: Wed, 2 Sep 2009 23:51:03 +0100
From: Duncan Cross <duncan.cross@gmail.com>
>
Leiradella<aleirade@sct.microlink.com.br> wrote:
(...) Or I'm completely missing an
obvious way to require modules that are compiled into the application
without hacks... In which case everyone is free to punch, ignore or
enlighten me.

You should be able to make modules compiled into the application
available to "require" by adding them into the "package.preload" table
(the key is the module name as passed to require, and the value is the
luaopen_... function).

Thanks, I'll try it though I still miss the libraries the way they were before. I don't like the whole package idea. LUA_PATH sounds so weird in a language which can be run on systems without any file system! Though I know it's not part of neither the language nor the VM.

And even after reading your message, I still don't know how to statically compile LuaSocket (for example) into an application, with all its Lua files also included in the application in order to avoid dependencies outside the executable.

Date: Wed, 2 Sep 2009 22:44:36 -0300
From: Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br>

I really miss the times when Lua was just an embeddable script language. I could just compile all Lua libraries I wanted, make a host application or change lua.c to open the additional libraries, link everything and be happy.

You can do just that today: just edit linit.c to suit your needs.

Sure, but as I said above how to deal with complex packages like LuaSocket?

Date: Thu, 03 Sep 2009 16:51:28 +0900
From: Miles Bader <miles@gnu.org>

Andre de Leiradella <aleirade@sct.microlink.com.br> writes:
I really miss the times when Lua was just an embeddable script
language. I could just compile all Lua libraries I wanted, make a host
application or change lua.c to open the additional libraries, link
everything and be happy.

hmm, I must be a bit confused, 'cause lua still seems like that today...

Or the confusion is mine :-)

Date: Thu, 3 Sep 2009 11:43:11 +0100
From: "John Hind" <john.hind@zen.co.uk>

Or like this:

snip...

Thanks, I'll try that also.

Date: Thu, 3 Sep 2009 08:02:56 -0300
From: Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br>

It's sad to see Lua move away from its niche.

Just for the record, Lua is not moving away from its goals.
In particular, being easy to embed remains a major goal.
We're not pushing Lua in a different direction.

Sure, but the libraries we need to use with it appear to be.

A language without libraries is of little usage. One has to be able to open files, write to the console, or do more complex things like popping a wxWidgets window. People in the community share libraries and bindings that do this stuff so it doesn't make sense to write them from scratch. But to use them I must use packages (or so I thought, I'll try the suggestions later) so I think the packages are pulling Lua from its niche.

Date: Thu, 3 Sep 2009 14:22:36 +0200
From: Jerome Vuarand <jerome.vuarand@gmail.com>

2009/9/3 John Hind <john.hind@zen.co.uk>:
snip...


You can also write some helper functions:

snip...

Thanks, but how do I handle packages that include Lua files?

Date: Thu, 3 Sep 2009 14:29:23 +0100
From: "John Hind" <john.hind@zen.co.uk>

But why bother putting it in the preload table if you then immediately load it
using C code? The idea of the preload table is so you can have C libraries compiled into
the runtime but which only get loaded into the Lua environment if called for by
the script. If you load it right off, you should load it like any of the standard
libraries i.e. by just executing its loader function.

Take a look at http.lua from LuaSocket:

-----------------------------------------------------------------------------
-- Declare module and import dependencies
-------------------------------------------------------------------------------
local socket = require("socket")
local url = require("socket.url")
local ltn12 = require("ltn12")
local mime = require("mime")
local string = require("string")
local base = _G
local table = require("table")
module("socket.http")

...

I simply don't know how to "internalize" LuaSocket into an executable. It doesn't seem that executing its loader function is enough.

Please don't get me wrong, LuaSocket is a great library, it's just that I don't seem to find a way to make it into my application the way I want it to.

Date: Thu, 3 Sep 2009 16:01:00 +0200
From: Jerome Vuarand <jerome.vuarand@gmail.com>

2009/9/3 John Hind <john.hind@zen.co.uk>:
But why bother putting it in the preload table if you then immediately load it
using C code? The idea of the preload table is so you can have C libraries compiled into
the runtime but which only get loaded into the Lua environment if called for by
the script. If you load it right off, you should load it like any of the standard
libraries i.e. by just executing its loader function.

Loaders of the standard libraries are designed to be just executed.
Modules that are designed to be loaded through require may rely on the
extra features of require to work properly (ie. setting
package.loaded[modname] to the return value of the loader).

So it involves some voodoo to get it done!

Thanks everyone, I have somethings to try now though I'm still full of doubts.

Cheers,

Andre