On Mon, Sep 7, 2009 at 1:20 PM, David Given wrote:
> That said, there is a fairly small group of people like you who want Windows
> binaries, and this is precisely what Lua For Windows is for:
The other half of this equation is automating the source code builds
of hundreds of modules on many platforms so that distribution
maintainers (e.g. Lua for Windows) as well as end users can easily
build from source. Currently, Lua for Windows is assembled from
binaries contributed by individual authors, which is not desirable IMO
for reasons discussed herein. LuaRocks/LuaDist can solve the building
problem, though currently there are a handful of Lua for Windows
modules its not yet compiling.
On Tue, Sep 8, 2009 at 7:05 AM, David Manura<[hidden email]> wrote:
> LuaRocks/LuaDist can solve the building
> problem, though currently there are a handful of Lua for Windows
> modules its not yet compiling.
Yes, LuaRocks makes downloading and building a module as easy as
'luarocks install lpeg'. You do need the Microsoft compiler, but
that's a free download and then all you have to do is run the
'vcvars32.bat' to set up the paths, and away you go. I've written a
little local web front-end that really makes this a matter of click,
wait and go, which I'm currently packaging for LuaRocks.
OK, LuaRocks currently puts modules in eccentric places, although this
will change for LuaRocks 2 - which will probably become part of Lua
The current issue that David mentioned is a stumbling block, but this
is a technical matter (translation: I'm going to sit down and sort it
out, either by doing it myself or badgering rockspec maintainers).
This has to happen before LR can be considered as a useful add-on to
Lua for Windows.
In summary: compilation need not be difficult and can be an automated
task, even on Windows.
Gcc will do what you tell it to do. Some people ignore warnings from gcc,
but that's ill advised. The first error as you mention is always
informative, and the only one you should bother looking at. Here's what I
use to treat warnings as errors, and to stop after the first error.
For compile only - you probably need some include dirs and libs.
gcc -c -ggdb -Wall -Werror -Wfatal-errors
These are in a Makefile, or course, with all of its beauty! And don't
overlook the wonder of pkg-config.
On Tue, 8 Sep 2009, Jeff Pohlmeyer wrote:
> Date: Tue, 8 Sep 2009 01:27:08 -0500
> From: Jeff Pohlmeyer <[hidden email]>
> Reply-To: Lua list <[hidden email]>
> To: Lua list <[hidden email]>
> Subject: Re: The source file culture
> On Sep 8, 2009 Jacques Chester wrote:
>> On 08/09/2009, at 7:45 AM, Vaughan McAlley wrote:
>>> error messages that might as well be written in Sumerian cuneform,
>> At the risk of inciting a flamewar, this is really GCC's fault,
>> not Lua's. ICC and Clang/LLVM, for example, give very helpful
>> error messages.
> Actually, the *first* error message printed by gcc is usually quite
> helpful, the problem is with the 6000 lines of useless garbage it
> vomits up after that :-)
> At least that's been my experience.
> - Jeff
Jacques Chester <[hidden email]> writes:
>> error messages that might as well be written in Sumerian cuneform,
> At the risk of inciting a flamewar, this is really GCC's fault,
> not Lua's. ICC and Clang/LLVM, for example, give very helpful
> error messages.
That seems a dubious claim... There are always particular cases where
any given compiler gives bad errors, but I've not noticed any general
difference in clarity between gcc's error messages and other compilers.
[and of course, if you're a windows user who's been inculcated into
fearing even the _concept_ of a compiler, the mere presence of any error
message at all is frightening...]
Joy, n. An emotion variously excited, but in its highest degree arising from
the contemplation of grief in another.
> In summary: compilation need not be difficult and can be an automated
> task, even on Windows.
This is the most important sentence of this thread ;)
I would like to mention the Novell's openSUSE Build Service:
https://build.opensuse.org/ With this service, you can make (or Novell will make for you) a binary
package for every supported linux distro and cpu. Up to now you could
only (easily) compile packages for your distro/cpu (using your own
computer), now you can do it for others. So even in the "source culture"
this is a useful solution.
The difference between linux and windows is that it is really easy for
linux users to (re)compile a package, because all needed tools are
"built-in". In Windows world, for years you could only get binary files
(with all its problems), and you had to pay for a compiler if you wanted
to compile a program (so as an ordinary user you never wanted to compile
So I would say it is a Microsoft (and also Apple) culture which prevents
you from easily compiling any available source code. Ask Microsoft for a
service similar to Build Service, and you will get binary packages for
any of your Windows version. Or use LuaRocks (I am dreaming of similar
"Build Service" for LuaRocks, for different OS/CPUs ;)
2009/9/8 Michal Kolodziejczyk <[hidden email]>:
> So I would say it is a Microsoft (and also Apple) culture which prevents
> you from easily compiling any available source code.
Well, Unix culture is code-based, and when balancing the needs of
developers and users, tends to make life easier for developers.
The average Windows/Mac user is scared of command-line tools, and I
include many intelligent engineers and scientists in this category; it
isn't a sign of lack of intelligence; they just have different
piorities. Cygwin is not a solution to a problem they recognize ;) So
I have sympathy for Lua programmers who find that C makes their head
Although, man, does Microsoft make compiling more difficult than it
need be! The decision to have a compiler-specific runtime and
deprecate good old mscvrt.dll makes for life of headaches. (Mingw can
actually build against the new runtimes, but not always.)
Anyway, at least the MS tools are now free, for the nominal cost of a
few hundred megabytes of download.
For the end user/scripter, errors are a bug. Something like LuaRocks
can handle the Lua dependencies well, but there are packages which
have 'special' needs. For example, lgdm can be built for Windows, but
you have to go out and hunt for the GDM port first. So the real
challenge is to make something like LuaRocks understand how to get and
install those external dependencies. This is really non-trivial, if
you think of all the varieties of platforms, rpm,deb,darwin-ports,
etc. Imagine a module specification which specified all the many
possible ways to grab things, and you can see that the module author
(or maintainer) has to be an unusually dedicated person!
On the subject of 'binaries considered harmful': you need trusted
sources, and some check like MD5 (which LuaRocks does support). We are
not talking about picking up DLLs from some random shareware site!
On Tue, Sep 8, 2009 at 10:23 AM, steve donovan<[hidden email]> wrote:
> deprecate good old mscvrt.dll makes for life of headaches. (Mingw can
> actually build against the new runtimes, but not always.)
For reference, this is how you can build lfs with mingw for Lua for Windows:
David Smead wrote:
> For compile only - you probably need some include dirs and libs.
> gcc -c -ggdb -Wall -Werror -Wfatal-errors
-Werror is dead handy for development, but may I make a plea to remember
to turn it *off* for distribution?
The problem is that while the C standard mandates when compilers produce
errors, it does not mandate when they produce warnings. So, different
compilers produce different warnings. This means that with this option,
working, non-broken code that compiles fine on compiler X will fail to
compile on compiler Y, because Y is producing a warning in a place where
X did not.
The gcc maintainers leave -Werror turned on, with the entirely unfunny
consequence that building gcc 4.Y on gcc 4.X where certain combinations
of X and Y will frequently fail to work out of the box:
steve donovan <[hidden email]> wrote:
From: steve donovan <[hidden email]>
Date: Tue, 8 Sep 2009 10:23:20 +0200
Subj: Re: The source file culture
> 2009/9/8 Michal Kolodziejczyk <[hidden email]>:
> > So I would say it is a Microsoft (and also Apple) culture which prevents
> > you from easily compiling any available source code.
> Well, Unix culture is code-based, and when balancing the needs of
> developers and users, tends to make life easier for developers.
> The average Windows/Mac user is scared of command-line tools, and I
> include many intelligent engineers and scientists in this category; it
> isn't a sign of lack of intelligence; they just have different
> piorities. Cygwin is not a solution to a problem they recognize ;) So
> I have sympathy for Lua programmers who find that C makes their head
> Although, man, does Microsoft make compiling more difficult than it
> need be!
I agree that compiling under Win32 is not as straightforward as it could
be. Part of that has historical reasons and part has to do with the fact
that hindsight is always easier on the eyes than foresight. A good part
of it is sheer MS stupidity though.
> The decision to have a compiler-specific runtime and
> deprecate good old mscvrt.dll makes for life of headaches.
It is possible, even with the newer MS compilers (2005, 2008), to link
against MSVCRT.DLL. This is even supported in the sense that MS provides
a set of tools to do so and does it for (some of) its products as well.
[Apologies for not replying to this message by reply to a list email;
I had delivery turned off at the time.]
George Petsagourakis wrote:
> My comment stems from the fact that there are quite a lot of people
> who are using Windows, and really there is nothing we can do
> other than open the code with a text editor and look at it unless we
> are into C programming.
It has nothing to do with Windows, it applies to any Lua user who is
"not into C programming". Equally, the same applies to anyone perusing
a Lua script who is not into Lua programming.
> Taking this as a fact implies that in order to script Lua,
As already pointed out, this is untrue. What is true is that the
standard Lua system does not provide much in the way of libraries.
However, I often find myself installing extra libraries for Perl
programming as I do for Lua. The difference is that CPAN provides a
simple uniform system, which hides the C compilation &c. that is
> you need to be able to program in C which blows away
> all the simple to use syntax concept of Lua, that is the main selling
> point to non programmers.
Lua programming is, by definition, not for non-programmers! Lua is of
interest to non-programmers for data description, configuration, and,
potentially, as a way in to programming. Again, there are ways to make
it easier, and many distributions, like Lua for Windows, do exactly
> I do realize that Lua isn't about getting it out and that it is meant to be
> embedded in another host program but it has gotten beyond that
> scope, for quite some years now, especially since the release of
> the Kepler project.
And the Kepler project provides the solution too: luarocks (sorry, I
referred to "gems" in a previous post, which is of course the Ruby
> I feel the need to express that the community
> should be ready, for example, when the Apache includes Lua
> support with their next release.
For what is the community not "ready"?
Really, your entire argument is a mish-mash of exaggeration ("you
can't program in Lua without C"), nonsense ("you can't use Lua on
Windows if you're a non-programmer"), personal bias ("I want Windows
binaries!") and untruth ("Lua doesn't have a module system"). It's
perfectly true that Lua's distribution is not as advanced as its
competitors'. This suggests two logical courses of action for you:
decide to help, or decide to use a more mature language platform.
While I'm sure you're not a troll, this kind of lazy un-thought-out
writing is little better than trolling.
On 07/09/2009 19:51, Chris Camacho wrote:
> I'd love to be able to understand the reverse, why do people insist on
> downloading binaries?
> There could be any manner of virus or back door in binary, at least if its
> source code I can audit it myself, better yet I can fix it too.
Because it is easier, faster and less prone to break (baring DLL hell issues)?
Windows doesn't come with a compiler by default. And make utilities can bring different
results (or break) depending if you use Cygwin, MingW, Visual Studio, TCC, Wacom or
Borland compiler, etc.
Most people will be afraid to use a compiler anyway. And will be totally unable to audit
code... Beside, most of the time, supposing you know well the used programming language
and the pitfalls it might offer, it is just too long to inspect source code: I want to use
Eclipse or Thunderbird immediately, not scrutinize its source in search of some back
Beside, Windows culture is mostly binary based: commercial products just doesn't come with
source (in general) and there are lot of useful freewares which are not open.
-- (near) Paris -- France
-- http://Phi.Lho.free.fr -- -- -- -- -- -- -- -- -- -- -- -- -- --
2009/9/8 George Petsagourakis <[hidden email]>:
> Reuben Thomas <rrt <at> sc3d.org> writes:
>> While I'm sure you're not a troll, this kind of lazy un-thought-out
>> writing is little better than trolling.
I'm not sure how the above leads to the following.
> I'll show up in the list at some other point in time,
> since at the present I am being perceived as a troll
> and this is really not my intention.
> I am trying to indicate a possible reality
> issue that people on Windows (installed on something around the 90%
> of machines world-wide) are facing as far as Lua's usability is
This is an issue of which everyone was already well aware, and which
no contributor to this thread has disputed.
> don't turn it to flaming, I have already mentioned that
> it was not in my intentions.
No-one's flaming. I was trying to explain in what ways your original
post was confused and unhelpful, and to lay out the real problems we
face, to which I should add the perceptions that lead to posts like
Indeed, perhaps the most valuable lesson one can learn from it is that
marketing counts, and that the Lua community, if it wants Lua to
become more popular (and that is not a given) may need to work on the
language's image as much as anything else. Alternatively, one can take
the view that it's no big deal, and that image always tends to lag
reality in any case (something that seems to be true even of the most
widely-used and well-known languages and systems).
> Taking up Lua _is_ by far easier than taking up C. Full stop.
Of course (again, I didn't say anything to the contrary).
Reuben Thomas wrote:
> Indeed, perhaps the most valuable lesson one can learn from it is that
> marketing counts, and that the Lua community, if it wants Lua to
> become more popular (and that is not a given) may need to work on the
> language's image as much as anything else. Alternatively, one can take
> the view that it's no big deal, and that image always tends to lag
> reality in any case (something that seems to be true even of the most
> widely-used and well-known languages and systems).
I remember one rather interesting conversation here a while back;
someone was asking about using Lua for some purpose... enterprise data
processing, I think. I was rather struck by the difference in attitude
between the people here and the kind of community you get in, say, Ruby
Q. Why should I use [Language] for X?
Python community: It's great that you're considering Python, because
it's the best language for the job! Python is really good at doing A, B
and C, and if you were to change your architecture you could do D, E and
F as well!
Lua community: I don't know. Why *should* you use Lua?
I think most people here see Lua as a component, intended to be
customised and bolted into another product, rather than being used on
its own. I write Lua scripts for doing quick hacks --- but they nearly
always get a customised interpreter if they ever turn into anything more
than a quick hack.
Here's some rather interesting statistics from the Debian Popularity
35% of (participating) users have liblua5.1 installed (the shared
library). 1% have lua5.1 installed (the command line interpreter). If
you compare to ruby, 34% have ruby1.8 installed while 27% have
libruby1.8 --- most ruby users use the interpreter. And if you check
Python, most versions don't even *have* a separate library package!
(Also, check out that growth curve for liblua5.1...)
I think what I'm trying to say is that Lua users are weird and don't
necessarily fall into the same demographic as with other scripting
languages. I could be wrong, though --- I know *I'm* weird...
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "They laughed at Newton. They laughed at Einstein. Of course, they
│ also laughed at Bozo the Clown." --- Carl Sagan
2009/9/8 David Given <[hidden email]>:
> Lua community: I don't know. Why *should* you use Lua?
The Lua maintainers, at least, are both reticent and cautious,
compared to other language maintainers.
> I think most people here see Lua as a component, intended to be customised
> and bolted into another product, rather than being used on its own. I write
> Lua scripts for doing quick hacks --- but they nearly always get a
> customised interpreter if they ever turn into anything more than a quick
I agree: I used to use Lua for general-purpose scripting, but found
that its lack of libraries, whether built-in or available in language
or OS distributions, was too much of a headache. I use it now
precisely where its small size and lack of dependencies make it easy
On Tue, Sep 8, 2009 at 3:35 PM, David Given<[hidden email]> wrote:
> I remember one rather interesting conversation here a while back; someone
> was asking about using Lua for some purpose... enterprise data processing, I
> think. I was rather struck by the difference in attitude between the people
> here and the kind of community you get in, say, Ruby or Python:
Well, I think we've experienced two users with very different laments,
Andre de Leiradella talking about the good old days when you could
'just' knock some C together with Lua and have an app, and George
talking about the difficulties of doing Lua without having to do C.
Both were not very coherent complaints, but that is the nature of a
lament, and attacking incoherence does not advance the cause.
OK, so what is the cause? Most of us are embedded Lua people, and
have forgotten our frustrations with command-line tools, forgiven C,
and often content to use 30-year old technology (e.g emacs/vi, make).
>From that perspective, not wanting to go that path seems like a sign
of not being serious. Then there are people who are attracted to a
fast, sane little programming language and want to use it in wider
applications, maybe even as an application library. I'm in both
camps, I like Lua because it reduces the amount of C++ I need write;
the headaches I get with C++ are not related to my skill level, just a
recognition that most C++ is probably premature optimization in the
There are initiatives to make Lua a better all-purpose scripting
language, and mostly these don't worry the embedders, unless like
Andre they think it is complicating that simple idylic C + Lua life.
So maybe when a scripter complains, then the embedders should remember
their own frustrations, just a little?
Otherwise, we do come across as elitist and snotty, and that does us
no favours in the long term.
> 2009/9/8 George Petsagourakis <[hidden email]>:
>> Reuben Thomas <rrt <at> sc3d.org> writes:
>> don't turn it to flaming, I have already mentioned that
>> it was not in my intentions.
> No-one's flaming. I was trying to explain in what ways your original
> post was confused and unhelpful, and to lay out the real problems we
> face, to which I should add the perceptions that lead to posts like
Can we shut this part of the thread down for now? It's not really
going anywhere useful now.
If anyone wants to discuss further, let's start afresh with a new
thread and a clean slate.
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia