[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Porting Instructions
- From: "Daniel Collins" <daniel.collins@...>
- Date: Sat, 1 Jul 2006 00:35:19 +0930
> > I also simplified things by removing all the Lua standard
> libs that my
> > project doesn't require (IO, OS and String libs). Note that
> even when
> > these libs are left out, there are a lot of file and string uses in
> > the lua code that require changing.
> As far as we know, there are no file operations inside the
> Lua core. (It uses sprintf, which is defined in stdio.h, but
> this is not a real file operation.) In the other libraries,
> we try to keep file manipulation to a minimum (print in
> baselib, debug in debug, and loadfile/panic in auxlib.c;
> string.format makes heavy use of sprintf, but does not use
> files). String operations we do use without restrictions, as
> it is easy to implement them in C whenever necessary.
You are correct. I over generalised and did not mean to imply some
problem on the part of the lua code. Most of the functions I converted
to macros were for string functions. And you are also correct that
string operations are easy to implement in C when necessary. I
implemented several of them to make up for shortcomings of the embedded
platform I am using. This was another step in the porting process.
The final step in the porting process I didn't mention was changing the
lua number type to int, and then implementing a fixed point user data
type for those times when I needed it. The only quirk is that the fixed
point type has to be initialised with strings, since fractional numbers
are no longer legal with the integer lua_number. But constructs like:
pi = fixed.new("3.141")
are not so bad.