Re: Lua and custom memory allocators

Thanks Mike and Ivo. Vista allocator does seem acceptable. Running without 
the debugger attached as Ivo suggested reduced the first test to 26 seconds 
(from 3m20s) which is quite acceptable (fastmm is only a bit over twice the 
speed).

Learn something new everyday I guess. I wasn't aware that running with the 
debugger attached on a full release build would be any different to running 
it outside of an ide.

- Alex

----- Original Message ----- 
From: "Ivo Beltchev" <ivo <at> roadrunner.com>
To: "Lua list" <lua <at> bazar2.conectiva.com.br>
Sent: Thursday, May 01, 2008 12:11 AM
Subject: Re: Lua and custom memory allocators

Try running the application without the debugger attached (Ctrl+F5 instead 
of F5). I noticed that if the debugger is present the OS uses a slower 
version of the heap. The difference is noticeable on XP, but is significant 
on Vista. If you run without a debugger and then attach, all is well.

Ivo 

[ANN] Luaxx 0.3

Hi,

I would like to announce the availability of Luaxx version 0.3.  It can 
be downloaded from http://matt-land.com/luaxx.

Luaxx is a thin wrapper around the Lua C API.  The wrapper adds some
convenience functions and integrates well with modern C++.  It is 
basically my conceptual port of lua to c++.  It does not yet wrap the 
full lua API, but it's a good start.  Please check it out and give me 
feedback.

Thanks.
--

-- 
Matthew Nicholson
matt-land.com

Re: [ANN] Luaxx 0.3

On May 1, 2008, at 1:19 AM, Matthew Nicholson wrote:
> Luaxx is a thin wrapper around the Lua C API.  The wrapper adds some
> convenience functions and integrates well with modern C++.  It is  
> basically my conceptual port of lua to c++.  It does not yet wrap  
> the full lua API, but it's a good start.  Please check it out and  
> give me feedback.
Looks pretty good so far... as for the exception throwing, you might  
want to offer a method that will avoid the throw since the user may  
know how to handle the error immediately without invoking the overhead  
of exception handling.

Also.. assuming errors are string objects is probably not the best  
plan-of-action.  It's quite possible for other objects are thrown as  
the error.

One of these days I'll give the API a try and see if there's any  
gotchas that I didn't see while glancing.

lua_getglobal / lua_pcall - can't find my function

Hi,

I have some lua functions I want to call from a C++ application. I use
lua_dofile to load the file. If I use lua_dostring to call a function it
works fine. However, when I use lua_getglobal/lua_pcall instead, my function
doesn't end up on the stack and pcall fails with a call to nil. 

Here's an example of what I'm talking about:

// get the foo module ready to go
lua_dofile(state, "foo.lua");
luaL_dostring(state, "foo.dosomething()");   // works fine

But:

lua_getglobal(state, "foo.dosomething");
lua_pcall(state, 0, 0, 0);    
// returns -1, err message indicates a call to nil

my foo.lua looks like:

module("foo", package.seeall)

function foo()
   print("Did something")
end

Is there something I'm missing?

Thanks,

Re: lua_getglobal / lua_pcall - can't find my function

hi

On Thu, May 01, 2008 at 09:28:35AM -0400, Aaron Saarela wrote:
...
> // get the foo module ready to go
> lua_dofile(state, "foo.lua");
> luaL_dostring(state, "foo.dosomething()");   // works fine
this accesses _G["foo]["dosomething"]

> But:
> 
> lua_getglobal(state, "foo.dosomething");
this tries to access _G["foo.dosomething"] which is not set

use a lua_getglobal(state, "foo") followed by a
lua_getfield for "dosomething"

> lua_pcall(state, 0, 0, 0);    
> // returns -1, err message indicates a call to nil
> 
> 
> my foo.lua looks like:
> 
> module("foo", package.seeall)
> 
> function foo()
or maybe function dosomething() ?

>    print("Did something")
> end

RE: lua_getglobal / lua_pcall - can't find my function

Aaron Saarela wrote:
> lua_getglobal(state, "foo.dosomething");
> lua_pcall(state, 0, 0, 0);
> // returns -1, err message indicates a call to nil

There is no global called "foo.dosomething" (as you can verify by
printing _G["foo.dosomething"]). You have to first get the global table
"foo", and then only get its member "dosomething". For example:

lua_getglobal(L, "foo");
if (lua_type(L, -1)!=LUA_TTABLE)
  return luaL_error(L, "foo module is not loaded");
lua_getfield(L, -1, "dosomething");
if (lua_type(L, -1)!=LUA_TFUNCTION)
  return luaL_error(L, "foo module has no dosomething method");
lua_replace(L, -2); // This removes the foo table from the stack
lua_pcall(L, 0, 0, 0); // should return 0

You should always check that a gettable (and its variants getfield,
getglobal, rawget, rawgeti) is pushing something on the stack before
using it.

Re: [ANN] Luaxx 0.3

Thomas Harning wrote:
> On May 1, 2008, at 1:19 AM, Matthew Nicholson wrote:
>> Luaxx is a thin wrapper around the Lua C API.  The wrapper adds some
>> convenience functions and integrates well with modern C++.  It is 
>> basically my conceptual port of lua to c++.  It does not yet wrap the 
>> full lua API, but it's a good start.  Please check it out and give me 
>> feedback.
> Looks pretty good so far... as for the exception throwing, you might 
> want to offer a method that will avoid the throw since the user may know 
> how to handle the error immediately without invoking the overhead of 
> exception handling.

You can use state::as and state::is to avoid exceptions, although the 
state::to functions always throw exceptions (state::as uses lua_is..() 
and lua_to..() internally).

When coding, there are some cases when you will expect a certain type 
and if lua_to...() fails you have to check for that.  For simple cases, 
you end up writing a lot of extra error checking code vs using 
exceptions.  There are also other cases where you expect any number of 
types, so you end up checking the type anyway.

Personally I prefer not to have to check if my call to lua_to... was 
successful, that way I can do things like this (and if there was a 
problem, and exception is thrown).

L.to(int_var, -1).to(str_var, -2).to(double_var, -3);

I would imagine calls to lua_to..() failing are not going to be frequent 
in speed critical code, but this is not necessarily a valid assumption 

Re: [ANN] Dado 1.0

Tomas Guisasola Gorham wrote:
> Dado is a package that offers some facilities implemented over LuaSQL 
> connection objects. Its main goals are:
> 
>     * better error messages,
>     * iterators to access the result set and
>     * more homogeneity in some commonly used database operations.
> 
> Dado is free software and uses the same license as Lua 5.1.
> 
> It can be downloaded from its LuaForge page:
> http://dado.luaforge.net/
> 
> Thanks,
> Tomás Guisasola

Handy tool.  However, I am finding a small difficulty.  I cannot run 2 
select statements in a row, but every other works.  I can run 
collectgarbage("collect") between them, and it works.  I suspect it has 
to do with "cur" being still open.  Is there a workaround, or am I just 
missing something fundamental?

Mike

Re: [ANN] Dado 1.0

On May 1, 2008, at 6:54 PM, Mike Schmitz wrote:

> Handy tool.  However, I am finding a small difficulty.  I cannot run  
> 2 select statements in a row, but every other works.  I can run  
> collectgarbage("collect") between them, and it works.  I suspect it  
> has to do with "cur" being still open.  Is there a workaround, or am  
> I just missing something fundamental?

Not sure about Dado itself, but in LuaSQL you will need to close the  
first connection cursor before issuing the second select statement.

http://www.keplerproject.org/luasql/manual.html#cursor_object

--
PA.
http://alt.textdrive.com/nanoki/

Question about Lua 5.1.3 and realloc() on life.lua