Martin | 4 Sep 03:38
Picon

alien attacks SDL

I liked Michal Kolodziejczyk demonstration of using SDL library with
alien module so I have changed and extend it a little and here is my
creation attached.

One thing that bother me is that I can not find why game always end
with segmentation fault when I am closing it! What is strange it
segfault after last command in the game is executed. I strongly
suspect it has to do something with memory management but can not
figure out a cure. Any suggestion?

While working with alien there was several questions I could not
answer. When defining prototype how do I indicate unsigned integers
of all kind:
SDL.SDL_FillRect:types("int", "pointer", "pointer", "unsigned int")

Also while trying struct.unpack I missed a possibility to unpack
pointer as light userdata, I resolved this with buff:get(5, "pointer").

And lastly when I allocate a buffer with alien.buffer() how do I free
it?  I guess this can be reason why my program ends with segmentation
fault, because I allocate buffers on several places but never free any
of them. Or does garbage collector take care of them?

Martin
Attachment (plain_pong.tar.bz2): application/octet-stream, 20 KiB
Joshua Jensen | 4 Sep 04:42

Re: alien attacks SDL

----- Original Message -----
From: Martin
Date: 9/3/2008 7:41 PM
> One thing that bother me is that I can not find why game always end
> with segmentation fault when I am closing it! What is strange it
> segfault after last command in the game is executed. I strongly
> suspect it has to do something with memory management but can not
> figure out a cure. Any suggestion?
>   
I have a slightly modified version of Alien.  It runs your sample fine.  
Among other fixes, it has this in core.c:

static int alien_function_gc(lua_State *L) {
  alien_Function *af = alien_checkfunction(L, 1);
  if(af->name) free(af->name);
  if(af->params) {
    free(af->params);
    if(af->ffi_params) free(af->ffi_params);
  }
  return 0;
}

The rest of my fixes can be found at 
svn://svn.luaplus.org/LuaPlus/work51/Src/Modules/alien/src/core.c and 
struct.c.
> And lastly when I allocate a buffer with alien.buffer() how do I free
> it?  I guess this can be reason why my program ends with segmentation
> fault, because I allocate buffers on several places but never free any
> of them. Or does garbage collector take care of them?
>   
(Continue reading)

Fabio Mascarenhas | 4 Sep 05:55
Picon

Re: alien attacks SDL

Hi,

For some reason the tarball on LuaForge was different from the version
in the repo (this is not supposed to happen as I have a make target
that packages and uploads the repo, but alas...), so this small bug
got away. It's fine now, so another "luarocks install alien" and the
example will run without glitches (apart from Ubuntu calling the
blasted lib libSDL-1.2.so instead of libSDL.so.1.2).

Joshua, could you explain what you use the type "cfunction" for? Maybe
I can overload one of the current types (pointer or callback) to do
what it does, instead of adding yet another one... and what about the
changes to struct (the "I" format and the extra parameter to userdata
unpacking)?

About signed vs unsigned, I wanted to see how far I could go without
adding this extra cruft (apart from the inevitable case of char vs
byte). In your SDL_FIllRect example, for example, you can use this as
prototype to SDL_MapRGBA:

SDL.SDL_MapRGBA:types("int", "pointer", "char", "char", "char", "char")

and then declare the last type of FillRect as int. It will all work
out in the end. It will even work if you build it in Lua "by hand"
(using bitlib) and then pass as a regular (signed) int.

--
Fabio Mascarenhas

On Wed, Sep 3, 2008 at 11:42 PM, Joshua Jensen
(Continue reading)

Fabio Mascarenhas | 4 Sep 06:04
Picon

Re: alien attacks SDL

BTW, very nice work with the game! Pong never gets old. :-) Though a
proper SDL api would use alien.wrap and wrapper functions to add some
type safety. See aio.lua inside this tarball, for example:
http://alien.luaforge.net/aio-current.tar.gz

Automatic generation of safe wrappers is one of the things in my todo
list (it's doable with a smarter types method).

--
Fabio Mascarenhas

On Thu, Sep 4, 2008 at 12:55 AM, Fabio Mascarenhas <mascarenhas <at> acm.org> wrote:
> Hi,
>
> For some reason the tarball on LuaForge was different from the version
> in the repo (this is not supposed to happen as I have a make target
> that packages and uploads the repo, but alas...), so this small bug
> got away. It's fine now, so another "luarocks install alien" and the
> example will run without glitches (apart from Ubuntu calling the
> blasted lib libSDL-1.2.so instead of libSDL.so.1.2).
>
> Joshua, could you explain what you use the type "cfunction" for? Maybe
> I can overload one of the current types (pointer or callback) to do
> what it does, instead of adding yet another one... and what about the
> changes to struct (the "I" format and the extra parameter to userdata
> unpacking)?
>
> About signed vs unsigned, I wanted to see how far I could go without
> adding this extra cruft (apart from the inevitable case of char vs
> byte). In your SDL_FIllRect example, for example, you can use this as
(Continue reading)

Martin | 4 Sep 14:44
Picon

Re: alien attacks SDL

On Thu, Sep 04, 2008 at 01:04:11AM -0300, Fabio Mascarenhas wrote:
> 
> BTW, very nice work with the game! Pong never gets old. :-) Though a
> proper SDL api would use alien.wrap and wrapper functions to add some
> type safety. See aio.lua inside this tarball, for example:
> http://alien.luaforge.net/aio-current.tar.gz

I will check that out.

> Automatic generation of safe wrappers is one of the things in my todo
> list (it's doable with a smarter types method).

Or better yet, I will wait while you exhaust your todo list!
How lazy man can be? :)

BTW, I added two extra braces into core.c as Joshue indicated and
now I get segfault no more. I am a happy man now!

> > About signed vs unsigned, I wanted to see how far I could go without
> > adding this extra cruft (apart from the inevitable case of char vs
> > byte). In your SDL_FIllRect example, for example, you can use this as
> > prototype to SDL_MapRGBA:
> >
> > SDL.SDL_MapRGBA:types("int", "pointer", "char", "char", "char", "char")
> >
> > and then declare the last type of FillRect as int. It will all work
> > out in the end. It will even work if you build it in Lua "by hand"
> > (using bitlib) and then pass as a regular (signed) int.

And this is how I used it until I find out how to extract format
(Continue reading)

Joshua Jensen | 4 Sep 06:27

Re: alien attacks SDL

----- Original Message -----
From: Fabio Mascarenhas
Date: 9/3/2008 9:55 PM
> Joshua, could you explain what you use the type "cfunction" for? Maybe
> I can overload one of the current types (pointer or callback) to do
> what it does, instead of adding yet another one... and what about the
> changes to struct (the "I" format and the extra parameter to userdata
> unpacking)?
>   
I wanted to get around to cleaning the 'cfunction' up, and that's why I 
hadn't submitted a patch yet.  As I recall, the situation was thus: A C 
function required a C callback.  The C function was made available via 
Alien, and the C callback was made available via Alien.  However, I 
couldn't hand the Alien-provided C callback function off as a parameter 
to the C function.

I can provide the exact example tomorrow for both the callback and the 
reason (or possibly, non-reason) for the 'I' format parameter.

I'm also not happy about the positioning of the additional 'pos' 
argument for the struct.unpack.  It should, as the original struct calls 
work, exist before the buffer size.

(I also don't like passing the buffer size along... is there a reason it 
can't be obtained via lua_objlen()?)

Josh

Fabio Mascarenhas | 4 Sep 21:16
Picon

Re: alien attacks SDL

On Wed, Sep 3, 2008 at 11:27 PM, Joshua Jensen
<jjensen <at> workspacewhiz.com> wrote:
> ----- Original Message -----
> From: Fabio Mascarenhas
>
> (I also don't like passing the buffer size along... is there a reason it
> can't be obtained via lua_objlen()?)

Buffers can be light userdata, too (you can pass a pointer to
alien.buffer and it just sets the metatable), and the size you want to
unpack can be smaller than the size of the buffer, so there are cases
where the size has to be explicit. But you are right that unpack can
be a little smarter and not need the size if you want to unpack a full
userdata.

Alas, using struct.unpack is a temporary bandaid while I do not
implement an struct abstraction on top of the buffers (like array).
The support for figuring out offsets from a description of the struct
is already in core.c, in the form of alien.sizeof and alien.align, so
it can be implemented as a Lua addon (just like arrays).

> Josh
>

--
Fabio Mascarenhas

Joshua Jensen | 5 Sep 07:42

Re: alien attacks SDL

----- Original Message -----
From: Fabio Mascarenhas
Date: 9/4/2008 1:16 PM
> Alas, using struct.unpack is a temporary bandaid while I do not
> implement an struct abstraction on top of the buffers (like array).
> The support for figuring out offsets from a description of the struct
> is already in core.c, in the form of alien.sizeof and alien.align, so
> it can be implemented as a Lua addon (just like arrays).
>   
Although not complete enough for my needs, I liked the approach 
CInvoke's Lua module took for structure definition.  Ultimately, I think 
struct.unpack will still be needed for special cases, but your struct 
abstraction will work most of the time.  (It occurs to me now that 
CInvoke didn't handle structures with arrays like 'char name[256]'.)

Josh

Joshua Jensen | 5 Sep 04:35

Re: alien attacks SDL


> ----- Original Message -----
> From: Fabio Mascarenhas
> Date: 9/3/2008 9:55 PM
>> Joshua, could you explain what you use the type "cfunction" for? Maybe
>> I can overload one of the current types (pointer or callback) to do
>> what it does, instead of adding yet another one... and what about the
>> changes to struct (the "I" format and the extra parameter to userdata
>> unpacking)?
>>   
> I wanted to get around to cleaning the 'cfunction' up, and that's why 
> I hadn't submitted a patch yet.  As I recall, the situation was thus: 
> A C function required a C callback.  The C function was made available 
> via Alien, and the C callback was made available via Alien.  However, 
> I couldn't hand the Alien-provided C callback function off as a 
> parameter to the C function.
>
> I can provide the exact example tomorrow for both the callback and the 
> reason (or possibly, non-reason) for the 'I' format parameter.
The callback, as I described above, is the reason for the "cfunction" 
type.  Even though the callback is technically a pointer, the Alien 
function type doesn't cast out to the containing pointer.  If it did, 
the "cfunction" type would be unnecessary.

The 'I' format parameter was to go along along with the 'in' format 
parameter.  According to Roberto's struct documentation:

"in" a signed integer with n bytes (where n must be a power of 2). An 
absent n means the native size of an int.
"In" like "in" but unsigned.
(Continue reading)

Hans van der Meer | 4 Sep 15:34
Picon
Picon

Re: alien attacks SDL

Martin <wtxnh-lua@...> wrote:
> One thing that bother me is that I can not find why game always end  
> with segmentation fault when I am closing it! What is strange it  
> segfault after last command in the game is executed. I strongly  
> suspect it has to do something with memory management but can not  
> figure out a cure. Any suggestion?

I have to cope with a similar problem: a segmentation fault occurring  
in the aftermath of a program (see subject "module loading in C"). Did  
you load C-libraries of your own, possibly within C-code? In my case I  
now believe the origin of such a crash might be in the premature  
unloading of a C library. These are held in the LUA_REGISTRY as  
userdata under a key "LOADLIB: <path-of-library>" and apparently  
nowhere else. The __gc function in the accompanying metatable unloads  
the library. Your problem might be similar.

Hans van der Meer


Gmane