US mirror moved

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

US mirror moved

Luiz Henrique de Figueiredo
I've just found by chance that the US mirror of Lua's ftp site has been moved to
	ftp://ftp.freesoftware.com/pub/languages/lua/

The web site has been updated.

If you know of other mirrors, or want to setup one, please let me know.
Thanks.
--lhf

Reply | Threaded
Open this post in threaded view
|

The ~

Erik Hougaard
I'm thinking of redefining the ~ (tilde) to something that more
accessable on a european keyboard. In Denmark it AltGr-^+Space (Three
keys) to get the tilde cause it treated as a accent to be able to make
ãõñ etc.. 

What is the purpose for the choice of this character ??? .. Why not use
! just like C C++ etc.. 

My users keeps telling me that is a pain to type!

/Erik

Reply | Threaded
Open this post in threaded view
|

Re: The ~

Alex Sandro Queiroz e Silva
On Fri, 17 Mar 2000, Erik Hougaard wrote:

> What is the purpose for the choice of this character ??? .. Why not use
> ! just like C C++ etc.. 
> 
	
	Maybe because of some influence from Perl, or because it's damn
easy to type it here in Brazil. :) This might had lead to a choice closer
to the notation we see in those Mathematical Logic books.

  --Alex	[hidden email]		Lab. de Computacao Grafica/UFC
-------------------------------------------------------------------------------
"Minha força vem da solidão. Não tenho medo das chuvas tempestuosas nem das
 grandes ventanias soltas, pois eu também sou o escuro da noite."
	- Clarice Lispector 
-------------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: The ~

Luiz Henrique de Figueiredo
In reply to this post by Erik Hougaard
>From [hidden email]  Fri Mar 17 15:04:02 2000
>
>I'm thinking of redefining the ~ (tilde) to something that more
>accessable on a european keyboard.

You're free to do as you please, but just don't call the resulting language Lua.

>In Denmark it AltGr-^+Space (Three
>keys) to get the tilde cause it treated as a accent to be able to make
>ãõñ etc.. 

We would have the same problem here in Brazil: ã and õ are *very* common in
portuguese.
Isn't it a problem of the editor or something like this?
(I for one use vi with one set of macros for programming and a different
set of macros for writing portuguese text. But please let's not get into a
religious war about editors and such.)

>What is the purpose for the choice of this character ??? .. Why not use
>! just like C C++ etc.. 

I confess that one of the initial choices in the design of Lua was that it
should not be similar to C, because we were targeting end users, not experienced
programmers.
To us, ~ reads naturally as "not" and so ~= reads naturally as "not equal".
Perhaps because ~ is bitwise-not in C...

Anyway, it's not something that can be changed now. Sorry.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: The ~

Alan Watson-2
I agree, you can't change ~ to !, but you could make Lua
accept both. 

This is the first thing I do when I install a new version of
Lua. (And, no, I don't call the modified language Lua.)

Regards,

Alan
-- 
Dr Alan Watson
Instituto de Astronomía UNAM

Reply | Threaded
Open this post in threaded view
|

Re: The ~

Erik Hougaard
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo wrote:
> I confess that one of the initial choices in the design of Lua was that it
> should not be similar to C, because we were targeting end users, not experienced
> programmers.
> To us, ~ reads naturally as "not" and so ~= reads naturally as "not equal".
> Perhaps because ~ is bitwise-not in C...
> 
> Anyway, it's not something that can be changed now. Sorry.
> --lhf

Well after looking more into - I'm planning to just add '!' to work just
like '~' but not remove the '~' and thereby preserving Lua syntax!

/Erik

Reply | Threaded
Open this post in threaded view
|

RE: The ~

Ashley Fryer-2

> From: Erik Hougaard
> Sent: Friday, March 17, 2000 12:06 PM
>
> Well after looking more into - I'm planning to just add '!' to work just
> like '~' but not remove the '~' and thereby preserving Lua syntax!

This is a good idea.  I can't imagine any problem with extending the Lua
syntax in this way.  Is there any legacy code that would break by adding
this?

ashley


Reply | Threaded
Open this post in threaded view
|

Lua Future (Was: Re: The ~)

Erik Hougaard
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo wrote:
> You're free to do as you please, but just don't call the resulting language Lua.

Well I'm calling the language uCoreScript (Lua does not have the hitech
name that the marketing department demands ;-) - but I'm crediting you
guys for making Lua in the startup notes, I hope that thats OK. But the
whole "changing the language" issue is getting quite complicated when
added application functions and tag methods into the discussion - So
when is the language still Lua ? And Lua code also never true portable
due the specific functions added in every implementation. 

I know that preserving a embedded script language is quite difficult -
must implementations fits the classic movie description "Based on true
fiction" - meaning that every implementation of the embedded language is
unique but has a degree of equallity to the original language - some are
true to story, others are not.

Luiz Henrique de Figueiredo also wrote:
>Anyway, it's not something that can be changed now. Sorry.

I accept, agree and understand that the language Lua is fixed, but just
like other languages continues to evolve, so should Lua. So how does
LuaTNG (I have no idea that Next Generation is in Portugies) look like?
are there plans? I know some of the things I would like to see?

1. Binary Tree sorting on tables instead of hash. Or maybe some sort of
plugin system
1. Case statement
1. Language constants - That would compile to values.
1. BCD support for embedded platforms without floating point.

These are just examples I can pull from the top of my head. 
 
Plase do not take this the wrong way, I'm very pleased with Lua and my
company has a lot riding on it. But in these days of "Open Source"
projects - I will have to consider Lua as a "Closed Development - Open
Source" thing. I have very little knowledge of the next version - some
rumors about multi-state, something about better error messages - and a
release date "soon" ! .. Ofcause this might have something to do with me
being in Europe. 

How are the resources on Tecgraf allocated to Lua - is it part of a
class or is it something the teachers do in their spare time, is it
research ? I have no idea. If I came to Brazil for a month, would I be
able to "inhale" some Lua information, tips 'n tricks ? 

Should we organize some resources to contribute to the development Lua -
I'm sure that I'm speaking on behalf of many of us, that we would be
glad to contribute!

/Erik

Reply | Threaded
Open this post in threaded view
|

RE: The ~

Max McGuire-2
In reply to this post by Ashley Fryer-2

> From: Erik Hougaard
> Sent: Friday, March 17, 2000 12:06 PM
>
> Well after looking more into - I'm planning to just add '!' to work just
> like '~' but not remove the '~' and thereby preserving Lua syntax!

This is a good idea.  I can't imagine any problem with extending the Lua
syntax in this way.  Is there any legacy code that would break by adding
this?

ashley

This sounds like how languages like C++ evolve...

Max

Reply | Threaded
Open this post in threaded view
|

RE: The ~

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
>From [hidden email] Fri Mar 17 21:40:42 2000
>> >
>> > Well after looking more into - I'm planning to just add '!' to work just
>> > like '~' but not remove the '~' and thereby preserving Lua syntax!
>>
>This sounds like how languages like C++ evolve...

Hear, hear!

We, the Lua team, have periodic meetings in which we mostly discuss what to
*remove* from Lua (without breaking anything) rather than what to add!
--lhf

Reply | Threaded
Open this post in threaded view
|

RE: The ~

Dave Bollinger
Luiz Henrique de Figueiredo wrote:
 >> periodic meetings in which we mostly discuss what to *remove* from Lua 

   I remember hearing the rumor that a future version of Lua was planned to
have a macro capability.  This is good news, however...  I hope that it
doesn't introduce a bunch of new "punctuation" into the language (witness
Perl, or worse Forth).  I'm suspecting that you might be planning something
similar to the CGILua pre-parse macros, which although functional is not
the most elegant code structure to my eyes.  Others may disagree, but I
prefer words to symbols where reasonable (obviously operators, string
delimiters and the like are good places for symbols).  Then let the
language figure out whether that word is a function/macro/variable/keyword.
 Just hoping that Lua doesn't end up with something unsightly that then
becomes hard to change later.  But I _would_ like to see a powerful macro
facility in Lua.
   It may not be feasible but if it were legal to do something like:

  #define  !=  ~=

   then that would put a rest to this issue, wouldn't it?  Also, if the
macro syntax could handle for loops and case statements then that would put
and end to those issues as well.  Plus probably several other issues I'm
forgetting about, yes?

   Cheers,

   Dave

Reply | Threaded
Open this post in threaded view
|

Re: Lua Future (Was: Re: The ~)

Luiz Henrique de Figueiredo
In reply to this post by Erik Hougaard
>From [hidden email]  Fri Mar 17 21:38:00 2000
>
>Luiz Henrique de Figueiredo wrote:
>> You're free to do as you please, but just don't call the resulting language Lua.
>
>Well I'm calling the language uCoreScript (Lua does not have the hitech
>name that the marketing department demands ;-) - but I'm crediting you
>guys for making Lua in the startup notes, I hope that thats OK.

That's ok.
We'd still prefer that you called it Lua, of course, keeing the syntax intact,
but you're free to do as you wish, as long as you comply with our requests set
in the COPYRIGHT notice.

>But the
>whole "changing the language" issue is getting quite complicated when
>added application functions and tag methods into the discussion - So
>when is the language still Lua ?

Lua is still Lua as long as it can be compiled by our code and the semantics
remain intact. This means that adding application functions and tag methods
does not change the language, but changing ~= to != does, even if you keep ~=.

>I accept, agree and understand that the language Lua is fixed, but just
>like other languages continues to evolve, so should Lua. So how does
>LuaTNG (I have no idea that Next Generation is in Portugies) look like?
>are there plans?

The next version will have a re-entrant API, and this is a major change,
although great pains are being taken to avoid any incompatibilities.
This is the single most important aspect of the next version.
It will also contain many other smaller changes, from the point of view of
the Lua programmer, although much in the code is being changed.

>1. Binary Tree sorting on tables instead of hash. Or maybe some sort of
>plugin system

I don't understand. The language does not have hash -- it has tables, which
up to now have been implemented as hash tables, in several diferent ways,
without anyone being aware of it.

>1. Case statement

Probably not going to happen.

>1. Language constants - That would compile to values.

What do you mean here? a=1+2 being changed to a=3?

>1. BCD support for embedded platforms without floating point.

If your C compiler for an embedded platform supports BCD, then it should be
simple to use it instead of doubles. Keep tuned for a LTN about using ints
instead of doubles, coming soon :-)

>Plase do not take this the wrong way, I'm very pleased with Lua and my
>company has a lot riding on it.

I'm glad to hear this.

>But in these days of "Open Source"
>projects - I will have to consider Lua as a "Closed Development - Open
>Source" thing.

That's right: Lua is Open Source but it's not an "Open Source" project,
in the sense of several people contributing code. But then again you're free
to take an existing implementation and starting your own "Open Source" project
based on it. Actually, a different implementation of Lua would be great!

>I have very little knowledge of the next version - some
>rumors about multi-state, something about better error messages - and a
>release date "soon" ! .. Ofcause this might have something to do with me
>being in Europe. 

Sorry, I said "soon" several weeks ago but an alpha version should be out by
Easter. 

>How are the resources on Tecgraf allocated to Lua - is it part of a
>class or is it something the teachers do in their spare time, is it
>research ? I have no idea.

Lua is a project housed by TeCGraf, which is a major user of Lua, but is
essentially our own effort (we, the Lua Team: roberto, lhf, celes).
Of course, we listen to TeCGraf's needs (and yours and everybody else's),
but Lua is not run by a committee :-)

>If I came to Brazil for a month, would I be
>able to "inhale" some Lua information, tips 'n tricks ? 

Probably yes, if you talked with us.

>Should we organize some resources to contribute to the development Lua -
>I'm sure that I'm speaking on behalf of many of us, that we would be
>glad to contribute!

Thanks very much for the offer. I'm glad that Lua can inspire such enthusiam.
What we need most is a wide base of users, and people like you and others in
the list help a lot to spread the word on Lua. I'm amazed how many usenet
postings mention Lua, from people that sometimes are not even on the list.

We need lots of applications written in Lua,
We need these applications not only to show that Lua exists but also to
display how the metamechamisms and extensible semantics of Lua are really
powerful, as we intended them to be.

We need many more general purpose libraries. This is one of the main obstacles
to take Lua into the main stream (witness perl and python).

We also need development tools, such as an IDE, including a debugger.
The best compliment you could pay Lua would be to have such a project being
run outside of TeCGraf, with no direct participation of the Lua team.
We would still be very happy to answer any questions about Lua, of course.

Finally, we need much more documentation. The reference manual is the
authoritative definition of Lua, but it's dry, like any other manual.
Roberto is working on a book, but it won't be ready any time soon.
The FAW did not ever take off, and so I started LTNs, which I hope will be
a forum for providing detailed technical information on Lua. This includes
cases studies of how common tasks are solved in Lua. I hope to get LTNs from
all of you!

When I say "we need" above, I meant the Lua community, of which the people
in the list are part, not only the Lua team or TeCGraf.

I thank you again for your enthusiam. This is what keep us running.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua Future (Was: Re: The ~)

Claus H. Karstensen
-----Original Message-----
From: Luiz Henrique de Figueiredo <[hidden email]>
To: Multiple recipients of list <[hidden email]>
Date: 18. marts 2000 04:06
Subject: Re: Lua Future (Was: Re: The ~)



>We need lots of applications written in Lua,
>We need many more general purpose libraries.
>This is one of the main obstacles 
>to take Lua into the main stream.................. 
>
>We also need development tools, such as an IDE,
> including a debugger.........

For what it's worth, I'm fiddling with a Lua-gui system.
Currently using a binding to the FLTK widget set ( www.fltk.org ),
but trying to keep the underlying toolkit easily interchangable
with something else. 
FLTK fits Lua extremely well, however, being compact, simple, modular,
and cross-platform to a reasonable extent. A full Lua Wish-like
shell - with everything statically linked - compiles to well below 400kB.

The idea is to produce a full Lua IDE, including a Delphi-like RAD
tool - ideally written entirely in Lua. 
The whole thing should run on all (sort of) X-nix and WinDos platforms.

There will be a web-page for this in a couple of weeks - to  be announced. 
Participation welcome.

.....................

To the authors of Lua: Thanks for this breath of fresh air.
Lua is clean, cool, and clear. It's great FUN to work with.
(But where's the10 MB minimal source distribution?)



Claus H. Karstensen
[hidden email]





    




Reply | Threaded
Open this post in threaded view
|

Re: Lua Future (Was: Re: The ~)

Erik Hougaard
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo wrote:
> That's ok.
> We'd still prefer that you called it Lua, of course, keeing the syntax intact,
> but you're free to do as you wish, as long as you comply with our requests set
> in the COPYRIGHT notice.
I do belive that I'm very complient to your copyright notice. I'm not
hiding the fact that its "based on" Lua so my users could go hunting for
Lua code to use in uCore - But there is not forum for Lua source - only
C source libraries etc. can be found ? Is this anything you have
considered ?

> >1. Binary Tree sorting on tables instead of hash. Or maybe some sort of
> >plugin system
> I don't understand. The language does not have hash -- it has tables, which
> up to now have been implemented as hash tables, in several diferent ways,
> without anyone being aware of it.

This is correctly a implementation request and not language change .. I
though that it would be rather cool to have a "plug-in" sorting/indexing
system for the tables. So people how need raw speed could use a hash
based system, but people how need some kind of sorting could use some
sort of tree system!

> >1. Case statement
> Probably not going to happen.

I know this one is very high on many peoples list.. A case statement is
very must used in business applications (such as mine) and without it,
some of the code seems a bit combersome cause the of many elseif in a
row.
 
> >1. Language constants - That would compile to values.
> What do you mean here? a=1+2 being changed to a=3?

That would be nice :-) but it more in the ShowWindow(Mycontrol,SW_HIDE)
where SW_HIDE is a constant that would get compiled to value. Right now
if people are going to implement a GUI (thoose bastards always have tons
of constants) they are going to reside in the global variable room and
cause they are constants why not eliminate then. In C this is done in
the preprocessor.
 
> >1. BCD support for embedded platforms without floating point.
> If your C compiler for an embedded platform supports BCD, then it should be
> simple to use it instead of doubles. Keep tuned for a LTN about using ints
> instead of doubles, coming soon :-)

Well I have Lua running with only INTs on my Coldfire board (In the
heart of my robot - pictures will be supplied later), but most embedded
C compilers do not natively support BCD and with embedded platforms the
choice of compileres is not big - Usually there is just couble per
platform (And they are tied together with In Circuit
Debuggers/downloaders/emulators etc.).
 
> That's right: Lua is Open Source but it's not an "Open Source" project,
> in the sense of several people contributing code. But then again you're free
> to take an existing implementation and starting your own "Open Source" project
> based on it. Actually, a different implementation of Lua would be great!

Well that would make a interesting project, as soon as uCore is out the
door :-) But with more implementations languages thend to either freeze
or seperate into different languages - look how the ML scene is very
seperated one the different implementations ;-( 

> We also need development tools, such as an IDE, including a debugger.
> The best compliment you could pay Lua would be to have such a project being
> run outside of TeCGraf, with no direct participation of the Lua team.
> We would still be very happy to answer any questions about Lua, of course.

Well I have been talking with the other guys, and maybe we could make
some sort of release of uCore. uCore is basicly a IDE for Lua with
debugger, database, network and all the stuff. The funny part is that
the uCore IDE is written in uCore itself (thereby Lua). We use uCore to
write a ERP pakage called uCore Financials. Lets see what the lawlers
think. I any case I will properly ask for beta testers on the list a
little later.

/Erik

Reply | Threaded
Open this post in threaded view
|

Keep it small

Gavin Wraith-2
In reply to this post by Luiz Henrique de Figueiredo
On Sat 18 Mar, Luiz Henrique de Figueiredo wrote:

> We, the Lua team, have periodic meetings in which we mostly discuss what to
> *remove* from Lua (without breaking anything) rather than what to add!
> --lhf

Here, at last, some wisdom. There is so much good software that
could be even better with fewer features. There are popular
M*cr*s*ft products with user interfaces that make the cockpit
of a Jumbo Jet look like child's play. Please do not be seduced
into making Lua bigger for the sake of fashion.
-- 
Gavin Wraith ([hidden email]) or ([hidden email])
Home page: http://www.wraith.u-net.com/

Reply | Threaded
Open this post in threaded view
|

Lua source

Fred Bertsch
In reply to this post by Erik Hougaard
On Sat, 18 Mar 2000, Erik Hougaard wrote:

> I do belive that I'm very complient to your copyright notice. I'm not
> hiding the fact that its "based on" Lua so my users could go hunting for
> Lua code to use in uCore - But there is not forum for Lua source - only
> C source libraries etc. can be found ? Is this anything you have
> considered ?

If there is such a forum, I'll donate a linked list implementation.  (It's
included as an attachment.)  It's implemented entirely in Lua, and the
documentation is contained in comments at the beginning of the file.

I'm afraid that the source looks a bit strange.  I have to be a bit
paranoid about putting things in the global namespace in my
application.  I let users run scripts on my server, so I have to be fairly
picky about what they can access.

The chief advantage of this over standard Lua list-tables is that
insertion and deletion takes constant time with this.  Lists also behave
like objects and carry their operations with them.

F
$debug

--

--  LinkedList.lua

--

--  Written by Fred Bertsch, 1999.  

--    Feel free to use it however you want.

--

--  This is a simple linked list package for Lua.

--

--  No global variable other than CreateList is created.

--

--  It is implemented entirely in Lua.  No external C code is required.

--

--  It is always assumed that the lists and nodes given are correct.

--    Only minimal error checking is done.  If the global variable _debug

--    is set to 1 before loading this file, then additional error checking

--    is performed.  After loading the file, it is okay to unset _debug.

--    Do not directly manipulate the nodes or lists

--

--  The following standard Lua functions are used.  It is assumed that 

--    they exist when this code is loaded, but they may be removed from

--    the global space later:

--      newtag

--      settag

--      tag

--      settagmethod

--      rawsettable

--      error

--



--

--  CreateList():  This creates a linked list.  It takes one optional

--    argument--a standard table-type Lua list.  (eg: { 'a', 'b', 'c' })

--    This argument makes it easier to create constant lists.

--



--

--  list:

--    This is a table containing the info on the entire linked list.

--      Here are the contents:

--        First = first node

--        Last = last node

--      Note that while you can safely read the contents of the list,

--        you cannot and should not modify them except through the

--        list functions.

--    It contains the following functions:

--      list:Prepend( object ):  Puts a lua object at the beginning of 

--          the list.

--      list:Append( object ):  Appends a lua object to the end of the

--          list.

--      list:AppendList( list ):  Concatinates the two lists.  The objects

--          in the list are not copied, but the nodes are.  (ie: modifying

--          the order of the appended list will not affect this list, but

--          modifying the objects in the list will.)

--      list:Insert( node, object ):  This puts a new object in the list.  

--          The object is inserted before the given node.  If the given node 

--          is equal to nil, the object is inserted at the end of the list.  

--          The node that the object was placed in is returned.

--      list:RemoveRange( nodeStart, nodeEnd ):  This removes a range of 

--          nodes from a given list.  All nodes starting with the starting 

--          node and ending immediately before the ending node are removed.

--      list:Remove( nodeToRemove ):  This removes a single node from the 

--          given list.

--      list:Length():  This returns the length of the list.  Note that 

--          this takes O( n ) time, where n is the length of the list.

--



--

--  node:

--    This is a table containing info on one node of a linked list.

--      Here are the contents:

--        Previous = previous node (nil iff none)

--        Next = next node (nil iff none)

--        Contents = contents (a lua object)

--      Note that while you can safely read the contents of the node,

--        you cannot and should not modify them except through the

--        list functions.

--    nil is a valid node representing the null node.  (ie: end of the list,

--      before the beginning of the list, etc.)

--



--

--  Example code:

--

--    Here's a simple program that uses some of the features.  (Including

--      iterating over the lists.)

--

--    list = CreateList( { 'is', 'the', 'C' } )

--

--    list:Append( 'code?' )

--    list:Prepend( 'Where' )

--

--    loopNode = list.First

--    while( loopNode ~= nil ) do

--      print( tostring( loopNode.Contents ) )

--      loopNode = loopNode.Next

--    end

--





do

  --  This generates an error along with a stack dump when in debug mode.

  local lerror = function( text )

$if _debug

    print( tostring( text ) )

    local nontable = nil

    nontable[ 1 ] = nil  --  Designed to produce a stack output if in debug mode.

$else

    error( tostring( text ) )

$end

  end



  local TagInvalidSetTable = function( table, index, value )

    %lerror( "Illegal attempt to set table values." )

  end



  --  These are the tags used by lists and nodes.  No tag methods are attached to

  --    them in order to improve speed slightly.

  local tagList = newtag()

  settagmethod( tagList, "settable", TagInvalidSetTable )



  local tagNode = newtag()

  settagmethod( tagNode, "settable", TagInvalidSetTable )



  local SetTag = settag

  local Tag = tag

  local RawSetTable = rawsettable





  --  This is the proper way to create a new linked list structure.  It

  --    returns an empty list.

  function CreateList( ltable )

    local list = {}



    local tagList = %tagList

    local tagNode = %tagNode

    local SetTag = %SetTag

    local Tag = %Tag

    local RawSetTable = %RawSetTable

    local LError = %lerror



    --  This puts a new object at the beginning of the list.  The node the object

    --    was placed in is returned.

    local Prepend = function( self, obj )

$if _debug

      if( %Tag( self ) ~= %tagList ) then

        %LError( "Invalid list." )

      end

$end



      --  Create the node...

      local nodeNew = { Next = self.First, Contents = obj }

      %SetTag( nodeNew, %tagNode )



      --  Update the list endpoints...

      if( self.First ~= nil ) then

        %RawSetTable( self.First, "Previous", nodeNew )

      else

        %RawSetTable( self, "Last", nodeNew )

      end

      %RawSetTable( self, "First", nodeNew )



      return nodeNew

    end

    list.Prepend = Prepend





    --  This puts a new object at the end of the list.  The node the object was 

    --    placed in is returned.

    list.Append = function( self, obj )

$if _debug

      if( %Tag( self ) ~= %tagList ) then

        %LError( "Invalid list." )

      end

$end



      --  Create the node...

      local nodeNew = { Previous = self.Last, Contents = obj }

      %SetTag( nodeNew, %tagNode )



      --  Update the list...

      if( self.Last ~= nil ) then

        %RawSetTable( self.Last, "Next", nodeNew )

      else

        %RawSetTable( self, "First", nodeNew )

      end

      %RawSetTable( self, "Last", nodeNew )



      return nodeNew

    end





    --  This appends the contents of a list to another list.  The contents

    --    of the second list are copied.

    list.AppendList = function( self, listToAppend )

$if _debug

      if( %Tag( self ) ~= %tagList  or  %Tag( listToAppend ) ~= %tagList ) then

        %LError( "Invalid list." )

      end

$end



      local node = listToAppend.First

      while( node ~= nil ) do

        self:Append( node.Contents )

        node = node.Next

      end

    end





    --  This puts a new object in the list.  The object is inserted before the given 

    --    node.  If the given node is equal to nil, the object is inserted at the end

    --    of the list.  The node that the object was placed in is returned.

    list.Insert = function( self, node, obj )

$if _debug

      if( %Tag( self ) ~= %tagList ) then

        %LError( "Invalid list." )

      end

      if( %Tag( node ) ~= %tagNode ) then

        %LError( "Invalid node." )

      end

$end



      if( node ~= nil ) then

        local nodePrevious = node.Previous



        --  Create the node to insert...

        local nodeToInsert = { Previous = nodePrevious, Next = node, Contents = obj }

        %SetTag( nodeToInsert, %tagNode )



        --  Update the previous node...

        if( nodePrevious ~= nil ) then

          %RawSetTable( nodePrevious, "Next", nodeToInsert )

        else

          %RawSetTable( self, "First", nodeToInsert )

        end



        --  Update the next node...

        %RawSetTable( node, "Previous", nodeToInsert )

      else

        self:Append( obj )

      end

    end



  

    --  This removes a range of nodes from a given list.  All nodes starting with the

    --    starting node and ending immediately before the ending node are removed.

    list.RemoveRange = function( self, nodeStart, nodeEnd )

$if _debug

      if( %Tag( self ) ~= %tagList ) then

        %LError( "Invalid list." )

      end

      if( %Tag( nodeStart ) ~= %tagNode  or  %Tag( nodeEnd ) ~= %tagNode ) then

        %LError( "Invalid node." )

      end



      --  Confirm that the ending node is after the starting node...

      local node = nodeStart

      while( node ~= nil  and  node ~= nodeEnd ) do

        node = node.Next

      end

      if( node ~= nodeEnd ) then

        %LError( "Ending node did not come after starting node." )

      end

$end



      if( nodeStart ~= nil ) then 

        local nodePrevious = nodeStart.Previous



        --  Update list endpoints...

        if( self.First == nodeStart ) then

          %RawSetTable( self, "First", nodeEnd )

        end

        if( nodeEnd == nil ) then

          %RawSetTable( self, "Last", nodePrevious )

        end

 

        --  Update edges of removed section...

        if( nodePrevious ~= nil ) then

          %RawSetTable( nodePrevious, "Next", nodeEnd )

        end

        if( nodeEnd ~= nil ) then

          %RawSetTable( nodeEnd, "Previous", nodePrevious )

        end

      end 

    end





    --  This removes a single node from the given list.

    list.Remove = function( self, nodeToRemove )

$if _debug

      if( %Tag( self ) ~= %tagList ) then

        %LError( "Invalid list." )

      end

      if( %Tag( nodeToRemove ) ~= %tagNode ) then

        %LError( "Invalid node." )

      end

$end



      if( nodeToRemove ~= nil ) then

        local nodePrevious = nodeToRemove.Previous

        local nodeNext = nodeToRemove.Next



        --  Update endpoints in list...

        if( self.First == nodeToRemove ) then

          %RawSetTable( self, "First", nodeNext )

        end

        if( self.Last == nodeToRemove ) then

          %RawSetTable( self, "Last", nodePrevious )

        end



        --  Update nodes that aren't being removed...

        if( nodePrevious ~= nil ) then

          %RawSetTable( nodePrevious, "Next", nodeNext )

        end

        if( nodeNext ~= nil ) then

          %RawSetTable( nodeNext, "Previous", nodePrevious )

        end

      end

    end





    --  This returns the length of the list.  Note that this takes O( n ) time, where

    --    n is the length of the list.

    list.Length = function( self )

$if _debug

      if( %Tag( self ) ~= %tagList ) then

        %LError( "Invalid list." )

      end

$end



      local n = 0

      local node = self.First

      while( node ~= nil ) do

        n = n + 1

        node = node.Next

      end



      return n

    end



    SetTag( list, tagList )



    --  Insert elements from standard lua-type table if needed...

    if( ltable ~= nil ) then

      local index = 1

      while( ltable[ index ] ~= nil ) do

        list:Append( ltable[ index ] )

        index = index + 1

      end

    end



    return list

  end

end





Reply | Threaded
Open this post in threaded view
|

Re: The ~

Diego Nehab-3
In reply to this post by Erik Hougaard
Hi Erik,

What happens when you key '~' followed by a space, or followed by an '='
sign, or even followed by another '~'? Do you get an error? I understand ~a,
~n etc will be translated to 'ã' and 'ñ' etc, just as it does with most
Portuguese enabled systems. But there is usualy an easier way to generate a
standard symbol like '~'. It also happens with the " and ' keys, which when
followed by 'u', for instance, become 'ü' and 'ú'.

What platform are your users using? Maybe it's just a matter of adjusting
the keyboard configuration so that it produces the correct codes.

Kind regards,
Diego.

Reply | Threaded
Open this post in threaded view
|

Re: The ~

Max Gilead-2
Diego Nehab wrote:

> What happens when you key '~' followed by a space, or followed by an '='
> sign, or even followed by another '~'? Do you get an error? I understand ~a,
> ~n etc will be translated to 'ã' and 'ñ' etc, just as it does with most
> Portuguese enabled systems.

In Polish windows version it works similar. But here solution is simple: tap ~
two times and that's all. Maybe it works for you, too?

Max

--
Max Gilead ([hidden email]) http://3d.linart.krakow.pl/OfficinaArtificialis
-----------------------------------------------------------------------------





Reply | Threaded
Open this post in threaded view
|

Re: The ~

Diego Nehab-2
In reply to this post by Erik Hougaard
Hi,

> In Polish windows version it works similar. But here
> solution is simple: tap ~ two times and that's all. 
> Maybe it works for you, too?

It works for me. Actually, if you reread my message,
you will see it was one of my suggestions. I wonder if
it works for Erik and his clients, though.

The point is: there is probably some way to solve the
problem without changing the Lua language.

Kind regards,
Diego.

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Reply | Threaded
Open this post in threaded view
|

Re: Keep it small

Maciej Maczynski
In reply to this post by Gavin Wraith-2

> On Sat 18 Mar, Luiz Henrique de Figueiredo wrote:
>
> > We, the Lua team, have periodic meetings in which we mostly discuss what
to
> > *remove* from Lua (without breaking anything) rather than what to add!
> > --lhf
>
> Here, at last, some wisdom. There is so much good software that
> could be even better with fewer features. There are popular
> M*cr*s*ft products with user interfaces that make the cockpit
> of a Jumbo Jet look like child's play. Please do not be seduced
> into making Lua bigger for the sake of fashion.
> --

That's what I call wisdom!
Although I'm not Lua-wizard, I'm experienced C++ (and some other languages)
programmer and I agree 100%.
I like Lua because it is _small_, has clean syntax and its extension
capabilities are powerful.
Don't try to turn it into Swiss-army knife - or you'll end up with Perl...

Maciej


12