Re: /usr/bin/env and the Lua bytecode format

["Jay Carlson" <nop@...>]

"Erik Hougaard" <erik@hougaard.com> writes:

> > Aw, it's not a big deal.  On SPARC Solaris, using gcc in the
bloaty -fpic
> > mode, it adds all of 112 bytes to the text segment.  Just a mod to
> > ldo.c:parse_file().  IMO this is the right place for # special-casing:
in
> > file handling, not in the definition of chunk.
>
> This is a great solution if you are using lua as standalone, but in
embedded
> use this is just plain overhead. The only right place to add this, if you
> want to preserve lua's primary target (embedding), is to make the
> modification in LUA.C Please read the readme in src\lua (note that this is
> not even part of the primary source directory).
>
> "This is lua, a sample Lua interpreter.
> It can be used as a batch interpreter and also interactively."
>
> Look at the word 'sample'. If you want your standalone Lua to do something
> platform specific please make the corrects in the right spot.
>
> One of the qualities of Lua that got me (and my company) to use Lua as a
> embedded langauge was the portability (ANSI-C) of the library. Now you
want
> to make changes in the general library to support a unix scripting
function
> ?

I think you should *run* (not walk) over to your pristine Lua 4.0 source
tree and apply this patch to llex.c:

--- llex.c.orig Thu Aug  2 17:05:47 2001
+++ llex.c Thu Aug  2 17:05:20 2001
@@ -106,11 +106,6 @@
   LS->lastline = 1;
   LS->source = source;
   next(LS);  /* read first char */
-  if (LS->current == '#') {
-    do {  /* skip first line */
-      next(LS);
-    } while (LS->current != '\n' && LS->current != EOZ);
-  }
 }

That's the current ANSI C implementation of the support for this
Unix-centric scripting function.  And it affects the lexing of every Lua
chunk, not just files.  You're already using it if you still have the
parser.  Oh, and by removing this, you'll regain ~100 bytes of sparc code.

Your numbers will vary; for non-pic gcc on x86, cut all the mentioned sizes
in half.

Of course you can remove this code at no cost to Unix users if dofile() is
patched as in my previous message.  Sadly, the text size of my patch grew in
the second version, so the net increase in size is still around ~100 bytes.
Well, ~50 on x86.

BTW, the code size byte count is mostly tongue-in-cheek, but I do care about
code size.  However, I think text size reduction is better served by a full
bloat hunt rather than quibbling about small features to fix up language
syntax.

> p.s. Example: Why should my robot need a #! / thing in its binary files -
> everything is compiled since there is no room in the flash for the parser.
> The robot does not even run a OS it just some parts of lua compiled
directly
> to a hardware platform (Motorola Coldfire)

Your robot doesn't need any #! thing in its binary files.  With my proposed
patch, Lua merely tolerates #! at the beginning of binary files, in the same
way it currently tolerates #! at the beginning of Lua source code.

Do you have true files?  There's stuff in liblua you can rip out if you
don't have files, like the function I was patching....

Jay