do you use the pre-processor?

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

do you use the pre-processor?

Luiz Henrique de Figueiredo
Continuing our quest for simplifying Lua, we are considering trimming the
pre-processor.

More precisely, we'd keep $debug, $nodebug, $endinput, but would remove
$if, $else, $end. So, the pre-processor would be back to its old self of
simply a set of pragmas that have immediate effect.

Conditional parts add complexity to the lexer (and the language; see a recent
message about $ inside [[...]] strings), but the benefits are not obvious.
For instance, $if VAR has a misleading requirement that VAR needs to be defined
(or not) *before* the chunk starts.

So, would the removal of $if, $else, $end break lots of existing code?
--lhf

Reply | Threaded
Open this post in threaded view
|

RE: do you use the pre-processor?

Ashley Fryer-2
> -----Original Message-----
> Behalf Of Luiz Henrique de Figueiredo
> Sent: Wednesday, May 10, 2000 2:32 PM

>
> So, would the removal of $if, $else, $end break lots of existing code?
>

I sometimes use $if 0 to temporarily disable code while debugging, but I
don't use $if in shipping code.  It would be nice to retain the limited
ability to disable blocks of code... since no old code ( of mine :-) would
break, perhaps there's an alternate lexer-friendly syntax which could be
used instead?  For example, what about block comments /* */ ?

If there's no easy way, then I can live without it.

ashley


Reply | Threaded
Open this post in threaded view
|

Re: do you use the pre-processor?

Dave Gordon
In reply to this post by Luiz Henrique de Figueiredo
If you take out $if and $end then the only way to comment out a block
of code is to prepend "--" to each line.  I'd rather have safe multi-line
[[...]] strings, and if possible some sort of block comment delimiter.
(Or would another form of block comment have the same problems?)
 
Dave Gordon
--
Algorithmic Arts Inc., Tokyo, Japan
www:    http://www.algorithmic.com/

Reply | Threaded
Open this post in threaded view
|

Re: do you use the pre-processor?

John Batty
In reply to this post by Luiz Henrique de Figueiredo
I agree with Dave's point.

I mainly use the preprocessor to easily add/remove large blocks of code
(using "$if nil"), which is particularly useful when prototyping / 
experimenting / temporarily removing lines.

It would be a real pain to have to comment out each line individually.

If you could come up with an alternative way of doing this, I wouldn't
otherwise miss the preprocessing abilities...

john

-----Original Message-----
From: Dave Gordon <[hidden email]>
To: Multiple recipients of list <[hidden email]>
Date: 10 May 2000 23:18
Subject: Re: do you use the pre-processor?


>If you take out $if and $end then the only way to comment out a block
>of code is to prepend "--" to each line.  I'd rather have safe multi-line
>[[...]] strings, and if possible some sort of block comment delimiter.
>(Or would another form of block comment have the same problems?)
> 
>Dave Gordon
>--
>Algorithmic Arts Inc., Tokyo, Japan
>www:    http://www.algorithmic.com/
>
>

Reply | Threaded
Open this post in threaded view
|

Re: do you use the pre-processor?

Russell Y. Webb
In reply to this post by Dave Gordon
Large projects really need a way to include and exclude code at compile 
time.  A _much_ cleaner solution would be to have a compiler that can 
optimize on preprocessor defined boolean tokens which are constant and not 
part of the chunks namespace.  If the token is false then the compiler 
would optimize the chunk away.

Something like 

$define debugging true

function test(x)
  if debugging then
    if type(x) ~= 'table' then
       RuntimeError('x is not a table')
    end
  end
  print(x.name)
end

Having only one such token to set would cover 90% of the cases.

Russ

Reply | Threaded
Open this post in threaded view
|

Re: do you use the pre-processor?

Fred Bertsch
In reply to this post by John Batty
On Wed, 10 May 2000, John Batty wrote:

> I mainly use the preprocessor to easily add/remove large blocks of code
> (using "$if nil"), which is particularly useful when prototyping / 
> experimenting / temporarily removing lines.
> 
> It would be a real pain to have to comment out each line individually.
> 
> If you could come up with an alternative way of doing this, I wouldn't
> otherwise miss the preprocessing abilities...

How about starting it with "comment = [[" and ending with "]]".  That's
what I usually do...

F

Reply | Threaded
Open this post in threaded view
|

Re: do you use the pre-processor?

Norman Ramsey-2
In reply to this post by Luiz Henrique de Figueiredo
 > Continuing our quest for simplifying Lua, we are considering trimming the
 > pre-processor.
 > 
 > More precisely, we'd keep $debug, $nodebug, $endinput, but would remove
 > $if, $else, $end. So, the pre-processor would be back to its old self of
 > simply a set of pragmas that have immediate effect.

Hurrah!  Hurrah!


Norman

Reply | Threaded
Open this post in threaded view
|

Re: do you use the pre-processor?

Fred Bertsch
In reply to this post by Russell Y. Webb
On Wed, 10 May 2000 [hidden email] wrote:

> Something like 
> 
> $define debugging true
> 
> function test(x)
>   if debugging then
>     if type(x) ~= 'table' then
>        RuntimeError('x is not a table')
>     end
>   end
>   print(x.name)
> end

I would be happy with this.  I would be even happier if that were replaced
by:

function test(x)
  $assert( type(x) == 'table' )
  print(x.name)
end

You might control compiling or not-compiling the $assert function call
through the $debug macro.

F

Reply | Threaded
Open this post in threaded view
|

Re: do you use the pre-processor?

Russell Y. Webb
> function test(x)
>   $assert( type(x) == 'table' )
>   print(x.name)
> end
> 
> You might control compiling or not-compiling the $assert function call
> through the $debug macro.

That would work.  I guess you'd need to write a local function to call if 
there was more work to do, but more code space is OK while more execution 
time is not.

The runtime overhead of

function test(x)
  local debug_code = function(x) ... end
  $assert( debug_code(x) )
  print(x.name)
end

Reply | Threaded
Open this post in threaded view
|

Re: do you use the pre-processor?

Roberto Ierusalimschy
In reply to this post by Fred Bertsch
> How about starting it with "comment = [[" and ending with "]]".  That's
> what I usually do...

You can improve this by writing

  comment = [[
     ...
  --]]

That way you can switch your code in and out by just changing the first
line:

  -- comment = [[
       ...              <<<< active code now
  --]]


-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: do you use the pre-processor?

Dave Gordon
In reply to this post by Fred Bertsch
On Wed, May 10, 2000 at 07:38:36PM -0300, Fred Bertsch wrote:
| 
| How about starting it with "comment = [[" and ending with "]]".  That's
| what I usually do...

That's a good idea, but it doesn't work well in some cases.  At least 
I don't see a way to make it work in a situation I encounter often 
while debugging my renderer.  I use $if, $end to comment out sections 
of large data arrays (vertex and polygon lists to be precise) to try 
to locate regions of the data were a problem is occuring.  For that
purpose "comment = [[...]]" doesn't work because (I believe) there's 
no valid syntax that allows it to be put it in the middle of table
constructor consisting of a list of objects.  So unless there's 
another trick I'm missing I still think a block comment delimiter 
would be helpful.  That is in the absence of $if, $end of course.

Dave

-- 
Algorithmic Arts Inc., Tokyo, Japan
www:    http://www.algorithmic.com/

Reply | Threaded
Open this post in threaded view
|

Re: do you use the pre-processor?

Norman Ramsey-2
I have to say I'm surprised at all the calls for block-comment delimiters.
I've always found it easier to read comments that are terminated
by end of line.  And every editor I've used since 1981 has provided
an easy way of inserting a comment marker at the beginning of each line
of a large block of code (and removing them `en masse' later).
What editors are people using that don't support this operation?


Norman

Reply | Threaded
Open this post in threaded view
|

Re: do you use the pre-processor?

Erik Hougaard
In reply to this post by Luiz Henrique de Figueiredo
----- Original Message -----
From: "Luiz Henrique de Figueiredo" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Wednesday, May 10, 2000 11:31 PM
Subject: do you use the pre-processor?


> More precisely, we'd keep $debug, $nodebug, $endinput, but would remove
> $if, $else, $end. So, the pre-processor would be back to its old self of
> simply a set of pragmas that have immediate effect.

Sounds good to me!

Actually I would like to get rid of $debug and $nodebug also. Reason: Doing
debug has more to do with the environment than the source, so I would
prefeer to be able to set debug information in the environment. Also when
working with multiple sources it gets wierd to keep track of $debug in
strange places.

So just like many other environment - run/build in debug mode or release
mode without having to change the source

/Erik


Reply | Threaded
Open this post in threaded view
|

Re: do you use the pre-processor?

Russell Y. Webb
> Sounds good to me!

There's always the fact that you don't have to use all language features 
but when a feature is missing then it's harder.  There is a serious need 
for some way to turn on and off chunks of code (mainly for debugging, so 
one switch would mostly solve the problem) which are scattered through 
the source and across multiple files.  If $if is removed and nothing is 
added to replace it then we'll have lots of people (like me) writing 
preprocessors in lua to put something like it back.  The downside to that 
is that then less code is standard lua.  Perhaps a standard extendable 
preprocessor layer is the real solution.  Then as long as you can save 
the preprocessor state, change it, process your file, and restore the 
last state code become portable again. 

> Actually I would like to get rid of $debug and $nodebug also. Reason: Doing
> debug has more to do with the environment than the source, so I would
> prefeer to be able to set debug information in the environment. Also when
> working with multiple sources it gets wierd to keep track of $debug in
> strange places.

This is a good point.  Of course sometimes one global setting is too 
corse grained, for instance you might have a largish game scripted in Lua 
and need to debug certain parts of the code, but if you turn all the 
debuggin on then it isn't fast enough to really test.

Russ 

Reply | Threaded
Open this post in threaded view
|

Re: do you use the pre-processor?

Steve Dekorte-4
In reply to this post by Erik Hougaard
[hidden email] (Erik Hougaard) wrote:
> So just like many other environment - run/build in debug mode or release
> mode without having to change the source

If you mean take away the ability to control it from within lua, I don't 
agree. I'm working on a development environment *within* lua and I need
to be able to control which parts are in debug mode (including source
compiled at runtime using dostring()) from within lua. 

That said, I'd prefer a call like debug(1) instead of $debug.
This way it can be over-ridden.

Steve 

Reply | Threaded
Open this post in threaded view
|

precompiling

stev
In reply to this post by Norman Ramsey-2
Is there any way to access the precompiler from within lua?

I want to have my lua code precompile files before executing dofile()
so the next time the script is run it will run the precompiled version
if this source file hasn't changed.

Steve


Reply | Threaded
Open this post in threaded view
|

Re: precompiling

Luiz Henrique de Figueiredo
>Is there any way to access the precompiler from within lua?

Lua always precompiles chunks before running them.

>I want to have my lua code precompile files before executing dofile()
>so the next time the script is run it will run the precompiled version
>if this source file hasn't changed.

The easiest solution for this is to define a function around the whole chunk
and return it. Something like

	return function ()
		... (chunk code)
	end

Then do
	if CACHE[name]==nil or file "name" has changed then
		CACHE[name]=dofile(name)
	end
	CACHE[name]()

Of course, you could redefined "dofile" to do this, using %dofile to get the
original "dofile". You can also hide CACHE as an upvalue to the new "dofile".
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: precompiling

Edgar Toernig
Luiz Henrique de Figueiredo wrote:
> Stephen Dekorte wrote:
> >I want to have my lua code precompile files before executing dofile()
> >so the next time the script is run it will run the precompiled version
> >if this source file hasn't changed.
> 
> The easiest solution for this is to define a function around the whole chunk
> and return it. Something like
> [...]

I guess he meant something different.  More like

function dofile(name)
  local cname = name .. ".luac"
  if not exist(cname) or isolder(cname,name) then
    compile_and_dump(name,cname)
  end
  dofile(cname)
end

It's doable but I don't know if anybody has made it.

Ciao, ET.

Reply | Threaded
Open this post in threaded view
|

Re: precompiling

stev
In reply to this post by Luiz Henrique de Figueiredo

On Mon, 15 May 2000, Luiz Henrique de Figueiredo wrote:

> >Is there any way to access the precompiler from within lua?
> 
> Lua always precompiles chunks before running them.
> 
> >I want to have my lua code precompile files before executing dofile()
> >so the next time the script is run it will run the precompiled version
> >if this source file hasn't changed.
> 
> The easiest solution for this is to define a function around the whole chunk
> and return it. Something like
> 
> 	return function ()
> 		... (chunk code)
> 	end
> 
> Then do
> 	if CACHE[name]==nil or file "name" has changed then
> 		CACHE[name]=dofile(name)
> 	end
> 	CACHE[name]()

I guess I wasn't clear - I need to write out the precompiled chunk to
a file from within lua. 

In other words, with luac I can do this:

luac -o MyFile.luac -c MyFile.lua

and produce a MyFile.luac file that contains a precompiled version of
MyFile.lua. But could I do the same thing in lua without using a
system() call?

Steve

Reply | Threaded
Open this post in threaded view
|

Re: precompiling

Luiz Henrique de Figueiredo
In reply to this post by stev
>From: Stephen Dekorte <[hidden email]>
>I guess I wasn't clear - I need to write out the precompiled chunk to
>a file from within lua. 
>
>In other words, with luac I can do this:
>
>luac -o MyFile.luac -c MyFile.lua
>
>and produce a MyFile.luac file that contains a precompiled version of
>MyFile.lua. But could I do the same thing in lua without using a
>system() call?

Not officially.
But you may want to try the following function, adapted from luac.c.

int luac_dofile(FILE* D, char* filename)
{
 FILE* f= (filename==NULL) ? stdin : fopen(filename,"r");
 ZIO z;
 char source[255+2];
 if (f==NULL) return 2;
 luaL_filesource(source,filename,sizeof(source));
 luaZ_Fopen(&z,f,source);
 luaU_dumpchunk(luaY_parser(&z),D);
 if (f!=stdin) fclose(f);
 return 0;
}

I think if there's a parse error, then this code will exit the host program,
which is ok for luac but not in general.
For robust code, see lua_dofile in ldo.c.

Apart from this, the modules used by luac are written so that they can be used
by themselves -- they only need a C API such as the one above, which prepares
things and calls luaU_dumpchunk.
So, if I can come up with a clean solution for the error problem, I will add
such an API in the luac modules.

Similar code can be written for loading binary files; see luac.c.
--lhf

12