Lua 5.1 (alpha) now available

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Lua 5.1 (alpha) now available

Luiz Henrique de Figueiredo
Lua 5.1 (alpha) is now available for testing at
        http://www.lua.org/work/lua-5.1-alpha.tar.gz

The tarball includes an updated reference manual. Please take a look.
As usual, please send us your comments or post them here.

If everything goes well, we should release Lua 5.1 final by the end of
the year.

Enjoy.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (alpha) now available

Daniel Silverstone
On Fri, 2005-09-02 at 14:17 -0300, Luiz Henrique de Figueiredo wrote:
> Lua 5.1 (alpha) is now available for testing at
>         http://www.lua.org/work/lua-5.1-alpha.tar.gz

I'd just like to say 'thanks' to the Lua team for all their hard work
with Lua 5.1

Now I have to go and integrate the diffs into my branches. No rest for
the wicked.

And luiz: Next time I'm in Rio, I buy the food and beer. Okay?

D.

-- 
Daniel Silverstone                         http://www.digital-scurf.org/
PGP mail accepted and encouraged.            Key Id: 2BC8 4016 2068 7895



Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (alpha) now available

Adrian Perez-2
In reply to this post by Luiz Henrique de Figueiredo

El 02/09/2005, a las 19:17, Luiz Henrique de Figueiredo escribió:

Lua 5.1 (alpha) is now available for testing at
        http://www.lua.org/work/lua-5.1-alpha.tar.gz
[...]
If everything goes well, we should release Lua 5.1 final by the end of the year.

It would be a great Christmas gift for all the community, thanks to everyone that contributed (in special for the authors :P).

--
Adrián Pérez
GPUL/CLUG member » http://gpul.org
"Experience is what you get when you don't get what you want."


Attachment: PGP.sig
Description: Mensaje firmado digitalmente

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (alpha) now available

William Trenker
In reply to this post by Luiz Henrique de Figueiredo
On 9/2/05, Luiz Henrique de Figueiredo <[hidden email]> wrote:
>
> Lua 5.1 (alpha) is now available for testing

Fabulous!

How do we know where to best contribute towards stabilization?  Is
there a bug list so we know which items to work on or to test?

Thanks,
Bill


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (alpha) now available

Luiz Henrique de Figueiredo
> How do we know where to best contribute towards stabilization?  Is
> there a bug list so we know which items to work on or to test?

We try not to release tarballs containing known bugs. Lua 5.1 (alpha)
does not contain any known bugs. But that does not mean there are no
bugs. You may contribute by testing it! Thanks!
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (alpha) now available

William Trenker
On 9/2/05, Luiz Henrique de Figueiredo <[hidden email]> wrote:
>
> We try not to release tarballs containing known bugs. Lua 5.1
> (alpha) does not contain any known bugs.

So then does 5.1(alpha) contain all of the new features described in
your recent slides (novelties.pdf)?  Does the release of this alpha
imply a no-exceptions feature freeze?

I'm asking because I'm new to the Lua release cycle.  Would you mind
briefly highlighting your release cycle policy for the benefit of all
of us who are new to this list?

Thanks,
Bill


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (alpha) now available

Luiz Henrique de Figueiredo
> I'm asking because I'm new to the Lua release cycle.  Would you mind
> briefly highlighting your release cycle policy for the benefit of all
> of us who are new to this list?

Sure, sorry about that. Here it is:

When we start working on a new version we periodically release `work'
versions, which are merely snapshots of the current development. Work
versions contain no documentation because the version under development
is still a moving target. When this target stops moving, it's time for
an alpha version and this carries documentation. There may be bugs in
the code, in the installation, in the docs. But an alpha version looks
like the final version. No external changes are planned, unless bugs are
found. Internal changes may still be made. When we're satisfied that
there are no bugs and we're satisfied with the internals, then it's time
for a beta version, which will shortly become the final version, if no
problems are found.

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (alpha) now available

William Trenker
Documentation:

Where do I find the table of contents for the reference manual?

Thanks,
Bill


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (alpha) now available

Luiz Henrique de Figueiredo
> Where do I find the table of contents for the reference manual?

Sorry, not available at the moment. --lhf

Reply | Threaded
Open this post in threaded view
|

Lua 5.1 (alpha): Documentation "bug" and suggestions

steffenj
5.4 String Manipulation

look for: string.gsub

after the gsub examples follow string.len, string.lower, etc and after some
more functions the gsub Patterns are explained which actually belong to
string.gsub

--------------------------------------------------------------------------

And some general tips on making the manual more (immediately) usable: 

I would like to see all the functions updated to also show the return
values. You always have to pick them out of the description text that
follows (if there is any hint, for example, getfenv doesn't explicitly
mention that it returns a table).

It would be more convenient if it were more like this:

copy, numSubst = string.gsub (s, pat, repl [, n])
success, [msg/arg1, arg2, ...] = pcall (f, arg1, arg2, ...)

--------------------------------------------------------------------------

Also, i personally feel that it is often confusing not to know what type of
value we're dealing with here. I wonder if this never occured to anyone
before because almost all scripts i look at don't follow any variable naming
convention at all. A variable "index" could be an integer, a string, or even
a table. This isn't clear without looking at the context, and that makes
reading (especially complex) scripts harder than it need be.

I've come up with a simple scheme for naming my variables which i've sticked
to for like 50.000 lines of Lua code:

nNumber = 123
	iInteger = 123 or rReal = 1.23 to differentiate where needed
sString = "a string"
bBoolean = true
tTable = {}
uUserdata = <someuserdata>
fFunction = function f() end
cCoroutine = co
hThread = <thread>
xUnknown (for values whose type is determined at runtime, eg a table index
can be both a string and an integer when walking through table elements)

An additional prefix "g" to mark global variables (visible even across
files). So that would make: gnGlobalNumber etc.
I have made some more rules for my "Lua styleguide" but these are the most
essential ones.

Personally, i feel that would make the documentation more readable if there
were some widely accepted naming convention for all types of Lua values. It
definetely makes scripts more readable. This has been known for decades, or
am i wrong? ;)

Giving variables reasonable names (and prefixed) seems to be neglected far
too often in the Lua community, if i may say so. I often find it hard to
read scripts as i have to keep in mind one extra information about each
variable: it's type. If i can't remember, I'll have to go back and scan
through the relevant parts again, eg looking up the type of value a function
returns. And then back again to where i was. ... Where was I? <sigh>

Sure, it's quicker to write everything in lowercase letters and stick to
variable names with at max 6 chars. Sure, it's hard to stick or even get
used to naming conventions when many Lua scripts are at most 200 lines. Yes,
i *felt* that, too. But it would still make it easier to understand the
scripts, even for the scripter (my personal experience tells me so). 

I've gotten myself this far that it actually *hurts* me to quote anyone's
code and *not* fix it up with my variable prefixes but leave it as is, with
their "subst" and "index" and "roles" and "connServ" and "myFunc" and "arg"
and "wresist" and "check" and "sock" and "whatnot". ;)

So, i don't want to hurt myself anymore: "sSubstitute" and "iIndex" and
"tRoles" and "cConnectServer" and "fMyFunc" and "xArg" and "nWindResistance"
and "bChecked" and "uSocket" and "bWhatNot". ;)

I must add: i'm also a writer, so the spelled out names come more natural to
me in both writing and reading than any clever abbreviation to save a
character here and there. I fear more to break my tongue while reading (if
only in my mind) names like "dbg" or "fnc" or "src" (spell it out, please,
DO IT ONCE!) than typing 2 or 3 extra letters on my keyboard. And it's
actually good training to learn to type faster while making less typo's.

I only use abbreviations in names that are used hundreds or a thousand
times, like a "con" table containing often used "console window" functions.

Ok, so i got carried away .... please don't hurt me, please don't! *G*


steffenj


Reply | Threaded
Open this post in threaded view
|

AW: Lua 5.1 (alpha) - no more table.foreach(i) ?

steffenj
In reply to this post by Luiz Henrique de Figueiredo
i don't see them in the docs in the table section, have they been removed in
favor or (i)pairs ?


ps: disregard the string.gsub "Patterns" glitch i mentioned, i overlooked
that the Patterns now have a place on their own.


steffenj


Reply | Threaded
Open this post in threaded view
|

Re: AW: Lua 5.1 (alpha) - no more table.foreach(i) ?

Petite Abeille

On Sep 02, 2005, at 22:34, steffenj wrote:

i don't see them in the docs in the table section, have they been removed in
favor or (i)pairs ?

Talking of which, what is the present consensus on how to enumerate over vararg?

Considering:

local function test( ... )
        print( "print", #{ ... }, ... )

        for anIndex, aValue in ipairs( { ... } ) do
                print( "test", anIndex, aValue )
        end

        table.foreachi( { ... }, print )
end

test( "a", "b", nil, "c" )

print   4       a       b       nil     c
test    1       a
test    2       b
1       a
2       b
3       nil
4       c

The print() function recognizes the nil parameter. The length operator returns 4. foreachi() enumerates all the values. ipairs() stops at the first nil.

What gives?

Cheers

--
PA, Onnay Equitursay
http://alt.textdrive.com/


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (alpha): Documentation "bug" and suggestions

Klaus Ripke
In reply to this post by steffenj
On Fri, Sep 02, 2005 at 10:29:22PM +0200, steffenj wrote:
...
> copy, numSubst = string.gsub (s, pat, repl [, n])
meaning sTheNewString, nUmSubst?

...
> I've come up with a simple scheme for naming my variables which i've sticked
> to for like 50.000 lines of Lua code:
> nNumber = 123
> 	iInteger = 123 or rReal = 1.23 to differentiate where needed
a dude named Charles Simonyi came up with a similar scheme
some time ago which is known as "Hungarian Notation".
Searching for this will lead you to endless fruitless
discussions ...

No doubt stock Lua is not going to trade gsub for snGlobalSubstitute,
but since it is good practice to localize (sic) imports, you may
	require "hungarian" -- adds long names to all available libs
or introduce german notation using
	local snGlobaleErsetzung = string.gsub -- jawoll ;P

> Personally, i feel that would make the documentation more readable if there
> were some widely accepted naming convention for all types of Lua values. It
> definetely makes scripts more readable. This has been known for decades, or
> am i wrong? ;)
there is room for all fashions.
You should not hesitate to xlat the docs to hungarian.


salud

Reply | Threaded
Open this post in threaded view
|

RE: Lua 5.1 (alpha): Documentation "bug" and suggestions

Vijay Aswadhati-2
> > I've come up with a simple scheme for naming my variables which i've
> sticked
> > to for like 50.000 lines of Lua code:
> > nNumber = 123
> > 	iInteger = 123 or rReal = 1.23 to differentiate where needed
> a dude named Charles Simonyi came up with a similar scheme
> some time ago which is known as "Hungarian Notation".
> Searching for this will lead you to endless fruitless
> discussions ...

Yes. And you will find me in the camp against Charles Simonyi. After years of
campaigning FOR hungarian notation it is refreshing to note that Microsoft has
abandoned in their .NET/C# codeline. You may still find some traces of it here
and there in code writen by those instituitionilized to that notation. 

My gripe against that notation is simple: what happens when you decide that a
byte (bByte) today becomes an integer (iInteger) or a double (rReal). Naming
variables hard coded to their type is baaaad. They should be named for their
purpose.




Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (alpha): Documentation "bug" and suggestions

Chris Pressey
On Fri, 2 Sep 2005 14:42:29 -0700
"Vijay Aswadhati" <[hidden email]> wrote:

> 
> > > I've come up with a simple scheme for naming my variables which
> > > i've
> > sticked
> > > to for like 50.000 lines of Lua code:
> > > nNumber = 123
> > > 	iInteger = 123 or rReal = 1.23 to differentiate where needed
> > a dude named Charles Simonyi came up with a similar scheme
> > some time ago which is known as "Hungarian Notation".
> > Searching for this will lead you to endless fruitless
> > discussions ...
> 
> Yes. And you will find me in the camp against Charles Simonyi. After
> years of campaigning FOR hungarian notation it is refreshing to note
> that Microsoft has abandoned in their .NET/C# codeline. You may still
> find some traces of it here and there in code writen by those
> instituitionilized to that notation. 
> 
> My gripe against that notation is simple: what happens when you decide
> that a byte (bByte) today becomes an integer (iInteger) or a double
> (rReal). Naming variables hard coded to their type is baaaad. They
> should be named for their purpose.

My understanding is that Simonyi's original proposal was, in fact, about
just that, naming variables for their purpose... regardless of what
Hungarian Notation has come to mean since then.  A fairly good article
about this is http://www.joelonsoftware.com/articles/Wrong.html :

"... Somebody, somewhere, read Simonyi's paper, where he used the word
"type," and thought he meant type, like class, like in a type system,
like the type checking that the compiler does. He did not. He explained
very carefully exactly what he meant by the word "type," but it didn't
help. The damage was done..."

-Chris

Reply | Threaded
Open this post in threaded view
|

AW: Lua 5.1 (alpha): Documentation

steffenj
In reply to this post by Klaus Ripke
>what happens when you decide that a byte (bByte) today becomes an integer
>(iInteger) or a double (rReal).

what "happens" is that i do a "replace" or "replace in files" ... ;)

and well, it doesn't happen very often when you think about what you're
trying to do before actually coding it
from my experience that happens maybe once in 10.000 lines of code

but don't get me wrong, i'm more than glad that MS abandoned hungarian
notation, it's a bloated beast IMHO ... a good idea that went waaaaay too
far... C#/.NET code is much more readable than MFC code

but let's forget about hungarian notation, what i suggested is merely the
least common denominator adapted to Lua types


>He explained very carefully exactly what he meant by the word "type," but
>it didn't help. The damage was done...

Yep. I say: "prefix values with a single lowercase character to signal their
type". And i get "hungarian notation" in my face. I was like "Woaaah - don't
go there, don't even THINK about it!". :)


>You should not hesitate to xlat the docs to hungarian.

Maybe i will, and add some...
Ever since i've come across lua, i was constantly dissatisfied with the
manual because it's more like a programmer's technical reference than a real
"manual" as i understand the term. The target audience may be mostly
programmers (really?) but with Lua's popularity even among non-programmers
it may be time for a manual that is more suitable to beginners or simply
"inexperienced" lua users. I suggest a split between "manual" and "language
reference" should at least be considered.

What i'm personally missing most in the manual are more extensive and/or
readable examples. Here and there a few more words to explain all the
details, and maybe add some more explanations of the basics. A couple tips &
tricks as well, like how you can trash the garbage collector with string
concatenations and other common traps found only deep inside the Wiki.
Things that you will run into sooner or later and make yourself wonder why
some code is suddenly broken or slow.

Roberto's book helps but it still reads more like the manual with extra
information spread throughout. The Wiki is nice to have but you're always
unsure wether the information is up to date and mostly it's hard to find
what you are looking for. And still hard to find it again at a later time.

The LuaForge pages (eg LuaInterface, LuaSQL and compat5.1) also leave you
with a feeling as if everyone assumes that you will look at the sources
anyway and find things out yourself. The bits that are available help you
get started but leave you suffering for details. Like a function reference
for LuaInterface. Even considering a technically experienced audience for
these tools, the documentation could still be improved quite a lot if it
were written with the user in mind.

Tell me, am i expecting too much from these manuals? I mean there's a lot of
people working hard on Lua and the related tools and i respect that. Even
more so that everything is for free, which is a blessing. And i know how
hard it is to write good technical information about something you know
inside out.


steffenj


Reply | Threaded
Open this post in threaded view
|

Re: AW: Lua 5.1 (alpha): Documentation

David Given
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

steffenj wrote:
[...]
> Yep. I say: "prefix values with a single lowercase character to signal their
> type". And i get "hungarian notation" in my face. I was like "Woaaah - don't
> go there, don't even THINK about it!". :)

A lot of MS developers still get late night flashbacks on the horrors of
Hungarian Notation. As you said, let's not go there.

That said, though, I have seen a variant of HN used very successfully on the
EPOC platform: it used prefixes to indicate the *kind* of each symbol. That
is: type (T), class (C), handle (R), enumeration (E), instance data (i) or
argument (a). (Locals were untagged.) They were programming in C++, which
makes a lot of this kind of thing necessary.

Most people find themselves distinguishing different kinds of identifiers;
Java and C++ both tend to have ClassNames, functionNames,
_private_instance_data, and ordinary_locals.

This information *is* technically part of the type and so is strictly
unnecessary, but doing this kind of thing can make your life much easier. For
example, the hoary old C++ problem of:

struct Class {
	int left;
	int right;

	Class(int left, int right)
	{
		// Um...
	}
};

Lua, of course, tends suffer from this because it doesn't have the rigourously
hierarchical scopes that C++ does. Object instance accesses are mostly
explicit ("self.left = left"), but some closure-based OO systems may benefit
from something similar...

- --
+- David Given --McQ-+ "If you're up against someone more intelligent
|  [hidden email]    | than you are, do something insane and let him think
| ([hidden email]) | himself to death." --- Pyanfar Chanur
+- www.cowlark.com --+

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDGOYjf9E0noFvlzgRAiM+AJ9zcF3b9V9KdrDpMsK5wnisz7VMlwCg1pKn
iBukeudK+oWYC4UZYx66eNU=
=y+Yy
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

RE: Lua 5.1 (alpha): Documentation "bug" and suggestions

Vijay Aswadhati-2
In reply to this post by Chris Pressey
On Friday, September 02, 2005 3:29 PM, Chris Pressey wrote:

> 
> My understanding is that Simonyi's original proposal was, in fact, about
> just that, naming variables for their purpose... regardless of what
> Hungarian Notation has come to mean since then.  A fairly good article
> about this is http://www.joelonsoftware.com/articles/Wrong.html :

Very enlightning article. Thank you. I would recommend the above article to the
list heartily. I pity myself for a decade of ignorance. No damage was done
however since I tend to use descriptive names for my variables. Still Joel's
idea about collocation factor is worth some thought.

Vijay Aswadhati





Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (alpha) now available

George-13
In reply to this post by Luiz Henrique de Figueiredo
Thanks a lot guys!

Only one thing I still miss a lot is "string.split(string,seps)" returning a table directly.

George

Luiz Henrique de Figueiredo wrote:
Lua 5.1 (alpha) is now available for testing at
        http://www.lua.org/work/lua-5.1-alpha.tar.gz

The tarball includes an updated reference manual. Please take a look.
As usual, please send us your comments or post them here.

If everything goes well, we should release Lua 5.1 final by the end of
the year.

Enjoy.
--lhf



Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (alpha) now available

D Burgess-4
In reply to this post by Luiz Henrique de Figueiredo
Beats me. How  does the following from luaconf.h work? 

union luai_Cast { double l_d; long l_l; };
#define lua_number2int(i,d) \
  { volatile union luai_Cast u; u.l_d = (d) + 6755399441055744.0; (i) = u.l_l; }


David Burgess


123