lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Hi Liam,

On Fri, Jan 7, 2011 at 1:15 PM, liam mail <> wrote:

> Jose profiling, looking at the generated assembly just the
> same techniques you would use on any other code; yet with the addition of
> only touching the Lua API when you must. I do use a simple speed comparison
> test[1] and there are more detailed results available[2]. Daniel Wallin did
> say that Luabind has a comparison test for other libraries yet IIRC due to
> dependancies he is unable to make it available.

Of course I know how to profile, but, as I said I'm still willing to
sacrifice speed for
legibility of the wrapped code, I just can't bare having to write
macros to do all the work.

> I have attempted to look at SLB a few times and some things put me off from
> even comparing it with OOLua, mostly the use of a dreaded singleton which I
> am not sure how it effects unrelated Lua states and see it will only close
> onexit.

I suppose you mean the SLB::Manager which used to be a Singleton, well that's no
true anymore, you can now instantiate any number of Manager, and
control which classes
are registered in which managers, thy act as a containers of the
registered classes.

>Then there is the unit tests which I like to consider as the
> documentation, if you do not mind I would like to suggest you rename the
> tests. For example as a none user of the library what actually is
> unit_00X.cpp (replace X with a number) testing, which script does it load?
> Maybe look at using a C++ or Lua testing framework,
> personally I like to see setup, operation, assert, teardown. OOLua did in
> the past did load external scripts and run tests yet it
> separated the code too much so instead it use strings for the Lua code to
> try and help ease the reading of the test units, although
> saying that I sometimes generate the Lua code which makes reading slightly
> harder.

You got the name wrong, and its use. The tests are script driven, from
the scripts
directory in tests/scripts. Each scripts loads one unit to test
(that's the reason to name
unit_00X.cpp) and performs several tests. Maybe is not as structured
as a given unit test framework, but that doesn't mean I'm doing it

Anyway, I will take into consideration rename the unit_blha, to avoid
people thinking it's something wrong.

> Beo I could not disagree more. These "samples" should be the unit tests
> which get run all the time and are always correct. Do the SLB examples get
> run by Jose? I have no idea and they could be wrong which is much worse than
> having no examples, personally I do not think the Luabind samples or it's
> unit tests are anything to shout about.

The examples are run, and the tests passed, under linux (with
valgrind), mac os X, and windows, that's for sure.


  Jose L. Hidalgo Valiño (PpluX)
  ---- ----