headers
Juris Kalnins | 1 Sep 14:30
Picon

userdata environment

Maual says: << Environments associated with userdata have no meaning for  
Lua. It is only a convenience feature for programmers to associate a table  
to a userdata. >>

Would it be possible to have Udata->env of type GCObject *?
It seems quite a waste to allocate table just to attach, say, one string  
to a userdata.
Permalink | Reply | 10 comments |
headers
Jerome Vuarand | 1 Sep 16:20
Picon
Gravatar

Re: userdata environment

2009/9/1 Juris Kalnins <juris <at> mt.lv>:
> Maual says: << Environments associated with userdata have no meaning for
> Lua. It is only a convenience feature for programmers to associate a table
> to a userdata. >>
>
> Would it be possible to have Udata->env of type GCObject *?
> It seems quite a waste to allocate table just to attach, say, one string to
> a userdata.

When I first used userdata environment I assumed it was the case and
was quite disappointed to discover it's not.

However you have other methods to associate metadata to a userdata.
For example you can use a weak table in the registry, with the
userdata as a weak key and the string as value.
Permalink | Reply | 7 comments |
headers
Rob Kendrick | 1 Sep 22:37
Picon

Feature request for 5.2; make exit codes from popen()ed programs obtainable

Hi,

Currently in Lua, it appears as if it is impossible to obtain the exit
code of a program that you have opened with io.popen(); the close
method on the returned object only returns true.

Are there reasons for it not return this?  If not, can I request it be
considered for 5.2?

B.
Permalink | Reply | 4 comments |
headers
Patrick Donnelly | 2 Sep 03:16

Re: Feature request for 5.2; make exit codes from popen()ed programs obtainable

On Tue, Sep 1, 2009 at 4:37 PM, Rob Kendrick<lua-l <at> nun.org.uk> wrote:
> Hi,
>
> Currently in Lua, it appears as if it is impossible to obtain the exit
> code of a program that you have opened with io.popen(); the close
> method on the returned object only returns true.
>
> Are there reasons for it not return this?  If not, can I request it be
> considered for 5.2?

This has been discussed [1]. There were some hacks proposed for
obtaining the status code in that thread. It would be nice if popen
returned the status code. I feel it should be a second argument,
however, because popen may fail early with "nil, <failure string>".

--

-- 
-Patrick Donnelly

"Let all men know thee, but no man know thee thoroughly: Men freely
ford that see the shallows."

- Benjamin Franklin
Permalink | Reply | 1 comment |
headers
Patrick Donnelly | 2 Sep 03:17

Re: Feature request for 5.2; make exit codes from popen()ed programs obtainable

On Tue, Sep 1, 2009 at 9:16 PM, Patrick Donnelly<batrick <at> batbytes.com> wrote:
> This has been discussed [1]. There were some hacks proposed for
> obtaining the status code in that thread. It would be nice if popen
> returned the status code. I feel it should be a second argument,
> however, because popen may fail early with "nil, <failure string>".

Knew I forgot something...

[1] http://lua-users.org/lists/lua-l/2009-06/msg00124.html

--

-- 
-Patrick Donnelly

"Let all men know thee, but no man know thee thoroughly: Men freely
ford that see the shallows."

- Benjamin Franklin
Permalink | Reply | 0 comments |
headers
RJP Computing | 2 Sep 04:06
Picon
Gravatar

Re: Feature request for 5.2; make exit codes from popen()ed programs obtainable

On Tue, Sep 1, 2009 at 4:37 PM, Rob Kendrick<lua-l <at> nun.org.uk> wrote:
> Hi,
>
> Currently in Lua, it appears as if it is impossible to obtain the exit
> code of a program that you have opened with io.popen(); the close
> method on the returned object only returns true.
>
> Are there reasons for it not return this?  If not, can I request it be
> considered for 5.2?

I would love this. Please, oh please add this. I have worked with the
hacks and they are not great.
--

-- 
Regards,
Ryan
Permalink | Reply | 1 comment |
headers
steve donovan | 2 Sep 09:42
Picon

Re: Feature request for 5.2; make exit codes from popen()ed programs obtainable

On Wed, Sep 2, 2009 at 4:06 AM, RJP Computing<rjpcomputing <at> gmail.com> wrote:
> I would love this. Please, oh please add this. I have worked with the
> hacks and they are not great.

It seems very doable, since _popen/_pclose in Windows console apps
works in a fairly standard way.  Adding an explicit pclose method
would be easy, although getting sensible errors (i.e. if called on a
file object not returned by popen) might take some work.

For Windows GUI apps, then one has to use something like lua-ex since
the C runtime version only works for the console subsystem. But this
is not Lua's problem ;)

http://msdn.microsoft.com/en-us/library/96ayss4b(VS.80).aspx

steve d.
Permalink | Reply | 0 comments |
headers
steve donovan | 2 Sep 10:22
Picon

Wishlists and Modules (was [ANN] libmc)

> Anyway, remember - it *is* a wishlist. :-)

While we are exchanging wishlists, here's one of mine ;)

Although code may be free (in both senses of the English word) it can
still be expensive in terms of time needed to understand it.  In an
ideal world there would be as little friction as possible in the
process, i.e. that when using a new module, the accidental complexity
should be as little as possible. (May well be essential complexity,
sometimes things _are_ rocket science.)

A The ideal module:
  0 well named (using namespaces)
  1 well focused
  2 well contained
  3 explicit dependencies
  4 documented in some standard way
  5 adequate test coverage
  6 useful examples

A0 may seem obvious but namespaces are increasingly a must.  CPAN is
looking after 16486 modules (!) and the only way that they can coexist
is by disciplined use of namespaces (e.g [0]).  A project needs a cool
name, but a module needs a useful name.

A2 means that a module behaves itself and doesn't mess with the global
table, except to introduce its own table.  A module can of course be
'injected' into the global table, but only on explicit request.

B And the ideal package manager:
(Continue reading)

Permalink | Reply | 2 comments |
headers
yxtor | 2 Sep 11:30
Picon

Re: Lua/SWIG: output parameters of custom types as references?


Hello. I am a new user here at Nabble.

I wonder if anybody has an answer to Sebs question? Its really hard finding
documentation
about this.

/Robert

Sebastian Wolff wrote:
> 
> Dear Lua community,
> 
> I hope someone already encountered the following problem and may assist 
> finding a solution.
> 
> I have an own object class type MyClass and want to wrap a C++ library 
> using SWIG 1.3.39 to be used by Lua. Using this library I often have to 
> wrap methods of the form
> 
> void foo1(const MyClass & a, MyClass & b)
> {
>     b.assign_and_action(a);
> }
> void foo2(const MyClass & a, MyClass & b)
> {
>     b.modify(a);
> }
> void foo2b(const int &a, int &b)
> {
(Continue reading)

Permalink | Reply | 0 comments |
headers
steve donovan | 2 Sep 19:01
Picon

Re: Feature request for 5.2; make exit codes from popen()ed programs obtainable

On Wed, Sep 2, 2009 at 6:46 PM, <delbu9c1 <at> erau.edu> wrote:
> I'm not sure I see a benefit to it being a second return. Nil is false and all numbers are true so existing
functionality should remain in tact.

I don't think we need fool with io.popen(), just define a pclose()
method on file streams that returns the error code.  You may easily
get output from a 'failed' process, and you won't know the status code
anyway until the stream is finished.

steve d.
Permalink | Reply | 0 comments |

Gmane