gmane.comp.lang.lua.general

z/OS port - segmentation faults

David Crayford — 2012-05-18T11:24:17

Hello,

I've just ported lua to an IBM mainframe, z/OS system. All was cool 
until I optimized and now I am getting segmentation faults. I'm 
wondering if this is a build problem or a nasty bug.

Find below the stack trace. The problem is due to strlen() failing due 
to a bad address which is 0x7fff0100. Unfortunately when I compile with 
debug it goes away.

   Traceback:
     DSA   Entry       E  Offset  Statement   Load Mod             Program Unit                   Service  Status
     1     CEEHDSP     +00004220              CEEPLPKA             CEEHDSP                        HLE7780  Call
     2     luaO_chunkid+00000058  255         lua                                                          Exception
     3     luaG_runerror
                       +000000F0  548         lua                                                          Call
     4     luaV_execute+00001238  776         lua                                                          Call
     5     luaD_call   +000000D8  393         lua

Re: London Lua user group

steve donovan — 2012-05-18T09:55:08

I'm usually 8 hours away (as the 747 flies) but I'll be in the UK in
September, and I'm looking forward to meeting people who actually use
Lua.  It does get a little lonely, this end of the world, surronded by
Pythonistas.

steve d.

Re: London Lua user group

Peter Pimley — 2012-05-18T09:46:46


Likewise.  I'm in Brighton but it's only an hour or two away.

Peter

Re: London Lua user group

Alex Bradbury — 2012-05-18T09:33:52

This is an incredibly exciting development! Thank you so much for
organising it. I'm situated in Cambridge, and will certainly be
attending all the events I can.

Alex

Re: Interesting C++ way to allocate user data (placement new)

2012-05-18T07:54:12

absolutely smart。I like it
On 2012/5/16 18:46, Francesco Abbate wrote:

London Lua user group

Justin Cormack — 2012-05-18T07:28:39

*I wrote to this list last summer about the possibility of setting up a Lua
user group in London (UK), and there seemed to be some interest. So finally
it is happening.

The idea is to have monthly meetups, where we will have a mix of longer and
shorter talks about anything and everything to do with Lua. I want to have
a mix of all sorts of uses, from games to web to embedded systems to
scripting to anything else people are doing with Lua. I think there are
quite a few people in London and nearby using Lua but there is so far
nowhere for them to meet.

The planned dates are 5th July, 2nd Aug, 6th Sept, 4th Oct, 1st Nov, 6th
Dec, and events will be held at Skills Matter
(http://www.skillsmatter.com)<about:blank>in Clerkenwell. They will
video the events so that they are available
online for anyone unable to attend.

If you want to give a talk (of any length or on any aspect of Lua) please
get in touch. If you want to sponsor the event get in touch too; we would
like to be able to get speakers from further afi

Help using Lua Lake or "I can't believe it's so simple"

Ezequiel Garcia — 2012-05-17T21:36:35

Hi,

I'm doing some experiments towards replacing my small makefile by an
even smaller lakefile ;)
Being very dissatisfied by autotools, cmake and friends, I think lake
is a great tool.

However, I believe the newcomer would benefit from a better, cleaner,
(perhaps even shorter) documentation.
The current documentation is very complete, and tries to explain the
rationale behind lake, which is a good thing.
But I think some of us, may just want a concise explanation of "how to
use this tool", rather than "how it's made".

On this same newcomer line, I found the examples rather insufficient:
most of them consist of just one source file.
Later, I discovered how smart lake is, and it's the same with one or
many files. But at first, it looked awkard.

I guess, perhaps this is just my own surprise saying: "I can't believe
it's *that* simple, I must be wrong"

Another thing, after lake compiled my project it produced a bunch of
objects and dependencies stuff.
As I am a little obsessive, I don't like to have .d and

Re: lua man page on Mac show leopard (10.6.8)

Luiz Henrique de Figueiredo — 2012-05-17T16:19:22

The installation should have installed /usr/local/share/man/man1/lua.1.
Try man -d lua to see what files man is trying.

lua man page on Mac show leopard (10.6.8)

teugon — 2012-05-17T15:06:36

hi all,

I've download and installed the lastest lua source but when I'm doing a
$ man lua.
I've got a "no manual entry for lua", where can I find doc on the
interpreter or how can I install those man pages?

Regards,
    Teugon.

Re: Integer keys in registry

Luiz Henrique de Figueiredo — 2012-05-17T11:46:30

No, not by the reference mechanism, but Lua 5.2 uses two integer keys in
the registry:

/* predefined values in the registry */
#define LUA_RIDX_MAINTHREAD1
#define LUA_RIDX_GLOBALS2

RE: Integer keys in registry

Alexandre Rion — 2012-05-17T11:40:14

So, if I don't use explicitly luaL_ref with the registry, no integer key will be reserved by the reference mechanism?

Thanks for your response

Alexandre

----------------------------------------

Re: Integer keys in registry

Kevin Martin — 2012-05-17T08:53:33

On 17 May 2012, at 09:46, Alexandre Rion wrote:


The registry is just a table with index LUA_REGISTRYINDEX, so to store a reference in the registry table use

luaL_ref(l, LUA_REGISTRYINDEX)

This allows you to also use luaL_ref with any other table as well.

Thanks,
Kev

Integer keys in registry

Alexandre Rion — 2012-05-17T08:46:05

Hello,

In the 5.2 documentation, in the section about the registry (4.5), it is written:

"The integer keys in the registry are used by the reference mechanism, implemented by the auxiliary library, and by some predefined values. Therefore, integer keys should not be used for other purposes."

But when I'm looking to the luaL_ref/luaL_unref source code, I don't find any access to the registry. Where does it come from?

Thank you!

Alexandre

Re: Interesting C++ way to allocate user data (placement new)

Leo Razoumov — 2012-05-16T23:00:53

To spare some typing one can define a corresponding macro:

// untested, targeting GCC
#define NEW(L, Type, args...)   (new(L, #Type "Metatable")Type(args))

Foo *foo = NEW(L, Foo, constructor arguments);

--Leo--

Re: Interesting C++ way to allocate user data (placement new)

Dimiter 'malkia' Stanev — 2012-05-16T22:04:25

There are also problems when using dll library that has been linked with 
static crt, or a different version of the CRT.

It happens quite a lot with plugins for example.

On 5/16/2012 11:57 AM, Francesco Abbate wrote:

ANN: goluago peek preview 2

Mateusz Czaplinski — 2012-05-16T20:20:27

(posted to: lua-l< at >lists.lua.org, golang-nuts< at >googlegroups.com)

Library goluago aims to become a port of Lua 5.1 interpreter to Go
Language Toolchain
(first 8c/6c/5c, ultimately maybe pure Go).

The library is at early stage of development (not feature complete/not ready
for production use), but some important goals were already completed
successfully:

STATUS
------

### What works - new in preview 2:

  * [MILESTONE] parsing & compiling Lua scripts to bytecode (via
luaL_loadbuffer())
  * [Lua] standard libraries: basic library (print(), ipairs(),
assert(), loadstring(), etc.)
  * [Lua] passes parts of the Lua testsuite (tested on fragment of "calls.lua")
  * [API] basic strings API (lua_pushlstring(), lua_tolstring())
  * [API] exposing Go funcs into Lua (lua_pushgofunction(), lua_dump())
  * [tools] Lua script for embedding Lua testsuite parts in Go unit
tests (wrap-test.lua)
  * [API, Lua] string <-> number conversions

### What works since preview 1:

  * [API] creating/destroying new Lua state (luaL_ne

Re: Interesting C++ way to allocate user data (placement new)

Patrick Rapin — 2012-05-16T20:15:25

You are right. But there is a simple workaround for this problem.
As Pablo Pissanetzky already mentioned, you also need a matching
delete operator to deal with exceptions.
That can me written as (untested) :

void operator delete( void* ptr, lua_State * L, const char* metaname )
{
 lua_pushnil(L);
 lua_setmetatable(L, -2);
}

This delete overload will only be called if an exception occurs inside
the constructor.
Providing that the constructor does not itself deal with the Lua
state, the userdata is still on the top of the stack when the function
is called, and it is easy to invalidate the metatable *before* the
__gc metamethod could be called.

Re: Feeding data into a lua state: in chunks?

Bruce Wheaton — 2012-05-16T20:11:01

So far that seems to work perfectly, thanks. It's interesting that, since I accumulate strings outside the lua state, I can still run functions from other sources while the user is entering lines. Weird, but neat.

Thanks,

Bruce

On May 16, 2012, at 9:27 AM, Bruce Wheaton wrote:

Re: Interesting C++ way to allocate user data (placement new)

Francesco Abbate — 2012-05-16T18:57:38

2012/5/16 Gé Weijers <ge< at >weijers.org>:

I've banned C++ exceptions from gsl shell, the application I'm
currently developing. The reason is that they pose a serious
integration problem, I'm using a C++ library that is itself not
exception safe. In addition I think that C++ exceptions and Lua
setjmp/longjmp are pretty much incompatibles. To be honest the
setjmp/longjmp is also unfriendly to normal C++ stack unwinding but
exceptions just complicate the scenario even more.

If you add, in addition exceptions that can be thrown from
constructors and destructors you may end up with a big headache :-)

No exceptions and your life is simpler. This is the KISS principle I guess :-)

Francesco

Inconsistency in formal argument names

Vinnie Falco — 2012-05-16T17:34:30

documentation have changed. "narg" is an argument index in
luaL_check() varieties, while narg is the number of arguments in
lua_resume(). "nargs" is the number of arguments in lua_pcall(). It
would seem a review and adjustment to the consistency of these names
could be helpful.

Thanks

Re: Interesting C++ way to allocate user data (placement new)

Gé Weijers — 2012-05-16T16:47:24

I usually delay setting the metatable until the object is in a defined
state, which is hard to do with this idiom. If the constructor of the
object throws a C++ exception and you catch it the "__gc" routine  the
metatable refers to may call the destructor, which is a bad idea because
the constructor failed.