John Belmonte | 1 May 2000 04:43
Picon
Favicon

experience implementing a module system


Recently I had a go at implementing a module system in Lua.  I'll describe
how it works and mention the limitations with Lua I ran into.

My motivation was to make a better module system than what is presented in
the Lua faq.  The problem with that system is name clashes.  If you are
using a global table to represent a module called "string", for example, you
have to be careful that no code in your project uses the same global name
for another purpose.  Furthermore the module name must be hard-coded and
repeated throughout the module definition, which does not allow for easy
renaming.

As for the new design I created, I'll start with an example:

    --
    -- test.lua - this is a file using a module
    --
    dofile( "ModuleSys.lua" )
    local modz = import( "modx.lua" )  -- note how module can be "renamed"

    modz.func1()  -- in global space must use plain module name

    function test()
        %modz.func1()  -- when not in global space must use upvalue
    end

    --
    -- modx.lua - this is a file defining a module
    --
    dofile( "ModuleSys.lua" )
(Continue reading)

Jim Mathies | 1 May 2000 03:11
Favicon

Lua40 compiles


Clean compile with CodeWarrior 5.0 on a PPC.
Clean compile with Visual C++  6.0 on a PC.

Regards,
Jim

--
Jim Mathies (jim <at> mathies.com)
http://www.mathies.com/

Roberto Ierusalimschy | 1 May 2000 15:47
Picon
Picon

Re: Doc: explicit lua_open required

> ( I'm upgrading from 3.1 so disregard if this is old news )...
>
>It should be documented that the behavior of the standard library "open"
>functions has changed.  [...]

This is new news... With multi-states, we decided not to implicitly call
lua_open when lua_state is NULL. We will document it properly, and put an
apropriate error message in luaL_openlib.

-- Roberto

Picon

New Discussion Group About Little Languages

>From rkaplan <at> accsys-corp.com Mon May  1 20:08:29 EDT 2000

An online discussion group about Little Languages has been
started at http://www.egroups.com/group/littlelanguages. This group
is dedicated to the discussion of all aspects of little programming from
design, implementation, and use. The list is moderated by
Dr. Randy M. Kaplan, author of "Constructing Language Processors
for Little Languages." Please feel free to join this group if you are
interested in little languages.

--

Dr. Randy M. Kaplan
publisher, knowldgWORKS News
Subscribe at: knowldgWORKSNews-on <at> lists.webvalence.com
Visit: www.accsys-corp.com

Jim Mathies | 2 May 2000 00:30
Favicon

RE: COM Scripting with Lua

Here's one - I probably will never get too:

Use the IWebBrowser HTML interface and a COM
object,  hooked up to lua.  Then allow folks
to write scripts in lua which manipulates the 
html of the page.  You could embed it in a corner,
1 pixel by 1 pixel.  It could do so much more that
Javascript or VBScript.  Especially since you
get to redesign the DOM as you please.

I've had a project like this sitting for a while,
but have yet to get around to it.

Jim

-----Original Message-----
From: Antonio E. Scuri [mailto:scuri <at> tecgraf.puc-rio.br]
Sent: Friday, April 28, 2000 10:20 AM
To: Multiple recipients of list
Subject: Re:COM Scripting with Lua

>Yes I have create a version of Lua that uses Microsoft's Active
Scripting
>framework.
>I am quite happy to email you a copy of the source code if required.
>
>Paul Winwood.

   I am also interested. We developed a small program to handle the
Windows 
(Continue reading)

Jon Kleiser | 2 May 2000 16:31
Picon
Picon
Favicon
Gravatar

Lua 4.0 (alpha), strfind-bug?

With my PowerMac Lua 4.0 I have discovered something that seems like 
a bug in "strfind". (I don't have access to compiled Lua 4.0 for 
other platforms yet.)

I'm using strfind to search for a pattern (no magic) that occurs a 
few times in my source string. When the search starts after the last 
occurrence, strfind (sometimes) returns position numbers that are 
greater than the length of my source string! However, to be quite 
sure that this strange thing happens, it seems that I have to build 
up my source string step by step, as happens when I use my bytesToHex 
function (below). That's why I convert my source string from hex to 
binary and back to hex in the example below. Before you run it, make 
sure you iron out any newlines that the email transfer may have put 
into the three long lines (sorry) where the s string is given its 
initial value.

/Jon

-- A function that turns a string of bytes into a string of hex codes
function bytesToHex(bytes, byteGap)
   if not byteGap then
     byteGap = ""
   end
   local h = "" -- the string to return
   local nBytes = strlen(bytes)
   local i = 1
   while i <= nBytes do
     h = h..format("%02X"..byteGap, strbyte(bytes, i))
     i = i+1
   end
(Continue reading)

Roberto Ierusalimschy | 2 May 2000 20:27
Picon
Picon

Re: Lua 4.0 (alpha), strfind-bug?

> With my PowerMac Lua 4.0 I have discovered something that seems like 
> a bug in "strfind".

It is a bug, and a silly one :-(  In my machine, you can get the bug with
the following little chunk:

  a = "abc  "
  print(strlen(a), strfind(a, "\0", strlen(a)-2, 1))

To fix it, you have to change one single line in lstrlib.c:

  408c408
  <     const char *s2 = memfind(s+init, l1, p, l2);
  ---
  >     const char *s2 = memfind(s+init, l1-init, p, l2);

(In words, when you start the search with an offset, you must subtract the
offset from the total length of the subject.)

It will be fixed in next version.

-- Roberto

Edgar Toernig | 2 May 2000 21:48
Picon
Picon

Re: upvalues: doc suggestions and another opinion

Hi,

Luiz Henrique de Figueiredo wrote:
> 
> In a previous message, I wrote that the local variables in *all* enclosing
> functions can be used as upvalues. This is, of course, false! Only the
> locals in the immediately enclosing function can be used as upvalues.
> The reason is that locals that are located higher up may not exist when the
> function is created. I'm sorry for the noise.

It was my fault.  The example was wrong.  Roberto gave the right one.

Ciao, ET.

Edgar Toernig | 2 May 2000 22:35
Picon
Picon

Re: experience implementing a module system

Hi,

John Belmonte wrote:
> So what went wrong with this design?  The problem relates to upvalues, which
> are being used to emulate local namespaces for the modules.  Lua only allows
> upvalue access to the next outer scope.  This prevents the following:
> 
>     function m.func()
>         local test1 = function()
>             %m.hey = 10  --error
>         end
>     end

Right.  This _is_ annoying.

>  There is a workaround, but it can hardly be considered acceptable:
> 
>     function m.func()
>         local m2 = %m			[btw,  local m = %m  works, too]
>         local test2 = function()
>             %m2.hey = 10
>         end
>     end

I made a patch for lua 4.0a that allows upvalues to access locals in outer
scopes.  Semantically it does just what you did by hand, that is inserting
a "local foo=%foo" (but without actually creating the intermediate local).
Everything else stays the same.  You can find the patch at
http://user.exit.de/froese/lua/upvalue-4a-patch

(Continue reading)

Edgar Toernig | 3 May 2000 00:39
Picon
Picon

Re: [ANNOUNCE] Lua 4.0 (alpha) now available

Hi,

Luiz Henrique de Figueiredo wrote:
> 
> Lua 4.0 (alpha) is now available for downloading at

You did not get much response about the new version so I'll try to
give you some of my impressions ;)

First observations: it's really noticeable faster, the already clean
code got even cleaner, the re-entrant API is really nice, and the
new instruction format looks as made for a RISC CPU ;)

The points in detail:

- The Instruction type.  You defined it as unsigned long.  You realize,
that a long on 64-bit CPUs is normally 64 bit?  I guess, an unsigned int
would fit better.  I don't no any _relevant_ architecture where an int
is less than 32 bit (and then, these systems probably want a 16 bit
instruction format *g*).

- You wrote "+ reduced memory usage" and I was surprised to find that
tables take 17-25% more space.  I was very skeptic when I first saw
new hashing routines (I've an uneasy feeling when filling hashes up to
100% *g*).  I took some profiling and saw that especially luaH_set
is really faster (464->334 avg clk cycles).  I just hope, that the
additional memory for management is compensated by the high fill rate.

- Another thing with tables: there is still a problem with entries whose
values has been set to nil.  The reference of the key stays until the
(Continue reading)


Gmane