David Burgess | 1 Jun 2005 01:34
Picon

Re: PATCH: Lua 5.0.2 popen/pclose fix (was Re: segfault in io.close and a plea for pipes)

I think I have addressed my popen() problem for win32.
After some iteration, I have a popen() function whose only
requirement is that it is openlib()ed. The rest of the IO
library just works with it (work6). Plus

   - The GUI program restriction of the MS RTL _popen() is removed
   - pclose() is not required, the handle is mapped to a FILE* so it
     closes with fclose() just like any other fp.
   - tested for handle leaks
   - additional mode characters, namely;
       2 - maps stderr to stdout
       s - uses the windows shell (COMSPEC)
       h - hides any child process windows
       n - uses a NULL handle for unspecified child handles.
           Without this option the parent handle is inherited by the child.
           process.
           If the parent stdin, stdout, stderr are not initialized correctly
           (as in the case of a GUI parent) the popen() may fail unless this
           option is provided.

The C module also comes with an exec() function that spawns using
IO completion ports and provides Lua call backs to perform std io for the
child process. 

I can send you this code if you want it.

My presumption is that popen() is generally not an issue for Unix systems
and that some kind soul will provide the perfect popen() implementation
for work6.

(Continue reading)

Mike Pall | 1 Jun 2005 02:18
Picon

PATCH: 51w6 inheritable liolib + posix.popen (was PATCH: Lua 5.0.2 popen/pclose fix)

Hi,

L. H. de Figueiredo wrote:
> > Unfortunately this requires a large amount of code duplication
> > from liolib.c. The methods are not inheritable because of the
> > strict metatable checks (and you really need to override close()).
> 
> liolib could probably be made generic. There has been some talk about this
> on the list, but no code, AFAIK.

Well, since you asked ... :-)

Attached is a 10 line (!) patch against lauxlib.c from
Lua 5.1-work6 to allow for method inheritance on userdata
metatables. See below for a detailed explanation.

Since the above change makes inheriting from liolib.c very easy,
I wrote the posix.popen functionality, too. See the second
attachment.

I made it into a standalone module for easier testing. But
of course it's intended to be merged into lhf's POSIX module
(yes, I donate the code).

posix.popen(command [,mode]) creates a userdata object with the
"FILE*.PIPE" handle metatable. It overrides the "close" method
and the "__gc" and "__tostring" metamethods. All other methods
are inherited from the "FILE*" handle metatable provided by
liolib.c.

(Continue reading)

Jarno van Rooyen | 1 Jun 2005 09:58
Picon

RE: 'name conflict for module' with Compat-5.1

> > I'll try to explain my setup:
> >
> > I want tables (containing namespaces) as follows:
> >
> > 	Tests
> > 	Tests.Component1 -- Contains all the tests for Component1
> 
> May I suggest a different setup?
> 
> What about
> 
> /Tests
>   /Component1
>     Feature1.lua
> 
> and then use only
> 
> require "Tests.Component1.Feature1"
> 
> whenever you need to test feature1 from component1. The file could be only
> 
> module "Tests.Component1"
> ... some more code to implement tests for feature 1.
> 
> Notice that you can have more than one FeatureN file using the same module
> namespace (although local functions won't be visible among the different
> files).
> 
This could work. How would I provide my users with the ability to load all
the tests for component1? How would they load the tests for all the
(Continue reading)

Andy Jones | 1 Jun 2005 12:25
Picon
Gravatar

Re: [Off-topic] Anonymous messages

It seems to me that if someone posts a genuine Lua question to the
list, it deserves a genuine answer, whether or not you can make out
the person's name.

And if someone posts a flame, or an advert, then that should be
treated in a way commensurate with the content - regardless of the
email address.

Just my 10c worth  (and I'm wondering what name will come up on the post!)

Andy.

Andre Carregal | 1 Jun 2005 17:51
Picon

LuaForge Down

Hi,

After a serious no-break failure on IMPA, LuaForge had to be turned off. We
expect it to be back in a few hours and will announce its status in the list
as soon as possible.

Everything is OK with the servers and the data but we are sorry for the
inconvenience.

André Carregal

Brian Murphy | 1 Jun 2005 19:08
Picon

Re: building a single lua binary with luasocket

Diego Nehab wrote:

> Hi,
>
>> luaopen_lsocket is a C function which needs a wrapper to be called from
>> lua, as far as I am aware...
>
>
> Luaopen_lsocket shouldn't be called directly from Lua. It should be
> called by require, when require"lsocket" is invoked by socket.lua, which
> in turn is executed when require"socket" is called by the user.
>
> In a traditional instalation, require"lsocket" will search for
> lsocket.dll and use loadlib to get luaopen_lsocket. Placing it in
> package.preload["lsocket"] simply avoids the search. Everything else
> works the same.
>
>> This is not "just" placing luaopen_lsocket in 
>> package.preload["lsocket"].
>> I feel that my method is more transparent in that no changes have to be
>> made in lua code for it to work (after my patch is applied) and if 
>> someone
>> does a require"lsocket" with the current socket then a load of 
>> "socket" will
>> fail, i.e. any order of loading modules works and loading the C 
>> module first
>> requires no special handling.
>
>
> Why isn't this "just" placing it in package.preload? You don't need to
(Continue reading)

Andre Carregal | 1 Jun 2005 20:10
Picon

LuaForge Back

Hi,

LuaForge is back online but without the no-break protection, therefore we
will be more exposed to power failures until the hardware is replaced.

André Carregal

Aaron Brown | 1 Jun 2005 22:38

Re: Lua reference manual in Vim

Luis Carvalho wrote:

> Just a quick announcement to those among us who are Vim
> users: I uploaded a Vim help file version of the Lua 5.0
> reference manual to vim.org:
> 
> http://www.vim.org/scripts/script.php?script_id=1291

I'm using this now, and it's nice.  Thank you.

--

-- 
Aaron

Markus Fritsche | 2 Jun 2005 00:01
Picon

Re: Debugging Lua

Asko Kauppi wrote:

> http://www.luaplus.org/tiki-index.php?page=LuaPlus+Home+Page

It's a bit underdocumented, isn't it? How do I connect the remote
debugger to what?

Kind regards, Markus

Asko Kauppi | 2 Jun 2005 00:15
Gravatar

Re: Debugging Lua


You should probably ask the author:  :)

http://www.luaplus.org/tiki-user_information.php? 
view_user=jjensen&PHPSESSID=8e0a1761f66e228a5f3e14e4984849b7

Markus Fritsche kirjoitti 2.6.2005 kello 1.01:

> Asko Kauppi wrote:
>
>
>> http://www.luaplus.org/tiki-index.php?page=LuaPlus+Home+Page
>>
>
> It's a bit underdocumented, isn't it? How do I connect the remote
> debugger to what?
>
> Kind regards, Markus
>


Gmane