Ideas for implementing commercial support for Lua

classic Classic list List threaded Threaded
68 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Ideas for implementing commercial support for Lua

Ray Garcia
> From: Luiz Henrique de Figueiredo [[hidden email]]
> Sent: Tuesday, November 12, 2002 6:44 AM
> To: [hidden email]
> Subject: Re: survey
>
> What do you mean by "commercial support"? Other people have said something
> similar and we're trying to understand how this could be implemented.
>
> Thanks again.
> --lhf


Suggestions from Ray Garcia:

On the topic of commercial support: probably the best model to look at is
Linux, either Redhat, Suse, Mandrake or Turbo Linux.  These vendors sell
packaging and support for Linux while remaining totally open source.
Similiar example with support for MySQL or Postgres.  In the Java community
probably Jboss.org is an other model to look at.

One can either simply download open source software and struggle with
getting it running or they can pay a small fee and get a fully tested and
installable package.  If one needs to do something other than the basic
installation then they could buy into a support program that lets them get
questions answered in a timely manner.  In the cases where someone needs to
do something novel they have a source of developers they could potential
contract to customize the open source implementation.  I beleive that this
somewhat describes the maturing of the open source movement and gives a
balance between open flexibility and sustaining the cost of on-going
development.  When open source is left only to volunteer efforts of a few
people it presents a risk to any business who has the desire to adopt the
open source solution but does not want to find itself without support when
defects are found or new releases as technology advances.  Of course with
patience it is possible to solve many issues when adopting open source by
asking for help from volunteers, unfortunately most business can't afford to
depend on this and need something more definate.

This is somewhat dealing with market perception more than reality in the
case of Lua.  For example; if one was to perceive that Lua development and
future releases had a commercial incentive then it would be more likely that
the language would be supported in the future.  The perception now (I my
opinion) is that Lua is a powerful scripting language with academic appeal
and of interest to the technically gifted and curious.  I recognize that the
reality is that Lua is actively supported and that if one needed help I'm
sure one would be able to find a volunteer to answer questions.

While the approach the Lua community is taking today leaves opportunity for
a wide variety of uses for Lua it limits the adoption to those who wish to
make Lua part of an existing effort.  Lua has the benefit of being small,
simple and fast but lacks the builtin libraries that might make it generally
usefull to a broad range of uses.  Each person needs to start with a small
Lua core and integrate it with whatever they deem necessary.  This is
somewhat a philosophical position that I think the Lua community has taken
intentionally.  In contrast Python can be small as well but it has a large
set of standard libraries that one could use immediately.  If one needs a
small version of Python its easy enough to strip away what is not needed.
Therefore it all depends on where the Lua community assumes the use for Lua
will be.  Today the assumption seems to be that it is not general purpose
and omits the large standard library approach.  My suggestion is that Lua
should come with an optional large standard library.

I beleive that Lua may be very close to being a viable option for not just
Python but other emerging languages as well.  For example; I looked at
Yindo.com, which is based on Lua and is probably the most powerful script
technology for the internet around, I was able to execute the complex demos
in just a few minutes.  Each of these demos are just a few lines of code.
In contrast if one was to attempt the exact same demos using ActiveX, a Java
applet, or Flash the download time alone would be so long as to not make it
practical.  Looking at Curl.com you'll see another example of a failed
strategy, to run the demo's requires a 12meg download and installation
process.  IBM research has put out Sash Weblications which again requires
lots of downloads and setup and runs slowly.  A good example of what Yindo
and Lua could easily compete with is Rebol.com.  Rebol approach to the
internet is very lean and powerful with a language that is simple, flexible,
and lightweight.

Aside from the support question I raise above I beleive that if the Lua
community took on the effort of adopting a standard library that included
all of something like what Yindo attempted it would position the Lua effort
as a direct alternative to Python, Ruby and other scripting languages.

You may be asking, "well if he thinks that Yindo is the way to go then why
not just use it and leave Lua the way it is", this basically goes back to
the support and commercial issues.  The Yindo effort was three guys, all of
whom seem to have moved on to other projects and do not  maintaining Yindo
anymore.  One of the Yindo founders has even started to create yet another
scripting language.  Same for several of the Lua projects I have asked about
over the internet.  Nearly all of them were great ideas started by a single
person who only periodically supported the Lua project they started or have
completely stopped the effort.

I want to consider using Lua for a commercial project but for now I'll only
look at it as another very cool scripting language to program in for fun.





Reply | Threaded
Open this post in threaded view
|

How do I INSTALL AND HELLO WORLD...

REINALDO QUARESMA
...under VC6 ?

Hello,

This is Reinaldo and I am almost sure I made all procedures to get Lua working....but it doesn't.

Thanks
Reinaldo Quaresma



Reply | Threaded
Open this post in threaded view
|

Re: Ideas for implementing commercial support for Lua

Asko Kauppi-2
In reply to this post by Ray Garcia
I'm having a similar situation to yours, being delighted by Lua as a
language but facing a psychological barrier for using it in "real" projects.
What I've asked the Lua people to do is at least to get the book out and
into the Amazon. :) That gives some more 'prestige' or 'maturity' to the
language, at least in the eyes of the non-devotees.

My primary wish from a commercial support house would be to have a clean,
nice, preferably Win32/Linux/OS-X multiplatform IDE. Currently, all of the
IDEs I've seen are smallish and sort-of functioning. None of them have been
great.

Keeping thumbs up for your suggestion, and following it...

- Asko Kauppi
  Flextronics Finland

--
Flextronics Design Finland
Box 23, 39201 Kyröskoski, Finland
+358 205 345 251 phone
+358 205 345 332 fax
www.flextronics.com


> -----Original Message-----
> From:	Ray Garcia [SMTP:[hidden email]]
> Sent:	Wednesday, November 13, 2002 6:05 AM
> To:	Multiple recipients of list
> Subject:	Ideas for implementing commercial support for Lua
> 
> > From: Luiz Henrique de Figueiredo [[hidden email]]
> > Sent: Tuesday, November 12, 2002 6:44 AM
> > To: [hidden email]
> > Subject: Re: survey
> >
> > What do you mean by "commercial support"? Other people have said
> something
> > similar and we're trying to understand how this could be implemented.
> >
> > Thanks again.
> > --lhf
> 
> 
> Suggestions from Ray Garcia:
> 
> On the topic of commercial support: probably the best model to look at is
> Linux, either Redhat, Suse, Mandrake or Turbo Linux.  These vendors sell
> packaging and support for Linux while remaining totally open source.
> Similiar example with support for MySQL or Postgres.  In the Java
> community
> probably Jboss.org is an other model to look at.
> 
> One can either simply download open source software and struggle with
> getting it running or they can pay a small fee and get a fully tested and
> installable package.  If one needs to do something other than the basic
> installation then they could buy into a support program that lets them get
> questions answered in a timely manner.  In the cases where someone needs
> to
> do something novel they have a source of developers they could potential
> contract to customize the open source implementation.  I beleive that this
> somewhat describes the maturing of the open source movement and gives a
> balance between open flexibility and sustaining the cost of on-going
> development.  When open source is left only to volunteer efforts of a few
> people it presents a risk to any business who has the desire to adopt the
> open source solution but does not want to find itself without support when
> defects are found or new releases as technology advances.  Of course with
> patience it is possible to solve many issues when adopting open source by
> asking for help from volunteers, unfortunately most business can't afford
> to
> depend on this and need something more definate.
> 
> This is somewhat dealing with market perception more than reality in the
> case of Lua.  For example; if one was to perceive that Lua development and
> future releases had a commercial incentive then it would be more likely
> that
> the language would be supported in the future.  The perception now (I my
> opinion) is that Lua is a powerful scripting language with academic appeal
> and of interest to the technically gifted and curious.  I recognize that
> the
> reality is that Lua is actively supported and that if one needed help I'm
> sure one would be able to find a volunteer to answer questions.
> 
> While the approach the Lua community is taking today leaves opportunity
> for
> a wide variety of uses for Lua it limits the adoption to those who wish to
> make Lua part of an existing effort.  Lua has the benefit of being small,
> simple and fast but lacks the builtin libraries that might make it
> generally
> usefull to a broad range of uses.  Each person needs to start with a small
> Lua core and integrate it with whatever they deem necessary.  This is
> somewhat a philosophical position that I think the Lua community has taken
> intentionally.  In contrast Python can be small as well but it has a large
> set of standard libraries that one could use immediately.  If one needs a
> small version of Python its easy enough to strip away what is not needed.
> Therefore it all depends on where the Lua community assumes the use for
> Lua
> will be.  Today the assumption seems to be that it is not general purpose
> and omits the large standard library approach.  My suggestion is that Lua
> should come with an optional large standard library.
> 
> I beleive that Lua may be very close to being a viable option for not just
> Python but other emerging languages as well.  For example; I looked at
> Yindo.com, which is based on Lua and is probably the most powerful script
> technology for the internet around, I was able to execute the complex
> demos
> in just a few minutes.  Each of these demos are just a few lines of code.
> In contrast if one was to attempt the exact same demos using ActiveX, a
> Java
> applet, or Flash the download time alone would be so long as to not make
> it
> practical.  Looking at Curl.com you'll see another example of a failed
> strategy, to run the demo's requires a 12meg download and installation
> process.  IBM research has put out Sash Weblications which again requires
> lots of downloads and setup and runs slowly.  A good example of what Yindo
> and Lua could easily compete with is Rebol.com.  Rebol approach to the
> internet is very lean and powerful with a language that is simple,
> flexible,
> and lightweight.
> 
> Aside from the support question I raise above I beleive that if the Lua
> community took on the effort of adopting a standard library that included
> all of something like what Yindo attempted it would position the Lua
> effort
> as a direct alternative to Python, Ruby and other scripting languages.
> 
> You may be asking, "well if he thinks that Yindo is the way to go then why
> not just use it and leave Lua the way it is", this basically goes back to
> the support and commercial issues.  The Yindo effort was three guys, all
> of
> whom seem to have moved on to other projects and do not  maintaining Yindo
> anymore.  One of the Yindo founders has even started to create yet another
> scripting language.  Same for several of the Lua projects I have asked
> about
> over the internet.  Nearly all of them were great ideas started by a
> single
> person who only periodically supported the Lua project they started or
> have
> completely stopped the effort.
> 
> I want to consider using Lua for a commercial project but for now I'll
> only
> look at it as another very cool scripting language to program in for fun.
> 
> 
> 
###########################################
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.


Reply | Threaded
Open this post in threaded view
|

Re: How do I INSTALL AND HELLO WORLD...

Martin Spernau
In reply to this post by REINALDO QUARESMA
You might want to try one of the VC6 Project files linked to here: http://lua-users.org/wiki/LuaAddons
I started with this one:
http://jove.prohosting.com/~philho/softwares/PhiLhoSoft/Lua/index.html

HTH, Martin


REINALDO QUARESMA wrote:

...under VC6 ?

Hello,

This is Reinaldo and I am almost sure I made all procedures to get Lua working....but it doesn't.

Thanks
Reinaldo Quaresma






Reply | Threaded
Open this post in threaded view
|

RE: Ideas for implementing commercial support for Lua

Ray Garcia
In reply to this post by Asko Kauppi-2
Asko,

Good suggestion on the book idea.  I beleive one is already written.  I'm
may to offer to publish it for them.

I agree on the need for an good IDE, this would make a significant
difference in market perception.  I would suggest a basic IDE similiar to
what comes with Python but then also sell a more complete environment like
what Activestate does.  Activestate give away Python but then sells an IDE
called Komodo.

An similiar approach could be taken with Lua.  They could put out an open
source IDE based on Scintilla and maybe GTK.  This would be both an IDE and
an example of an application built in Lua.  The commercial product could be
built as a plug-in to the Eclipse framework which is freely available from
IBM.

Ray

> -----Original Message-----
> From: Asko Kauppi [[hidden email]]
> Sent: Wednesday, November 13, 2002 6:00 AM
> To: 'Ray Garcia'
> Cc: '[hidden email]'
> Subject: Re: Ideas for implementing commercial support for Lua
>
>
>
> I'm having a similar situation to yours, being delighted by Lua as a
> language but facing a psychological barrier for using it in
> "real" projects.
> What I've asked the Lua people to do is at least to get the book out and
> into the Amazon. :) That gives some more 'prestige' or 'maturity' to the
> language, at least in the eyes of the non-devotees.
>
> My primary wish from a commercial support house would be to have a clean,
> nice, preferably Win32/Linux/OS-X multiplatform IDE. Currently, all of the
> IDEs I've seen are smallish and sort-of functioning. None of them
> have been
> great.
>
> Keeping thumbs up for your suggestion, and following it...
>
> - Asko Kauppi
>   Flextronics Finland
>
> --
> Flextronics Design Finland
> Box 23, 39201 Kyröskoski, Finland
> +358 205 345 251 phone
> +358 205 345 332 fax
> www.flextronics.com
>
>
> > -----Original Message-----
> > From:	Ray Garcia [SMTP:[hidden email]]
> > Sent:	Wednesday, November 13, 2002 6:05 AM
> > To:	Multiple recipients of list
> > Subject:	Ideas for implementing commercial support for Lua
> >
> > > From: Luiz Henrique de Figueiredo [[hidden email]]
> > > Sent: Tuesday, November 12, 2002 6:44 AM
> > > To: [hidden email]
> > > Subject: Re: survey
> > >
> > > What do you mean by "commercial support"? Other people have said
> > something
> > > similar and we're trying to understand how this could be implemented.
> > >
> > > Thanks again.
> > > --lhf
> >
> >
> > Suggestions from Ray Garcia:
> >
> > On the topic of commercial support: probably the best model to
> look at is
> > Linux, either Redhat, Suse, Mandrake or Turbo Linux.  These vendors sell
> > packaging and support for Linux while remaining totally open source.
> > Similiar example with support for MySQL or Postgres.  In the Java
> > community
> > probably Jboss.org is an other model to look at.
> >
> > One can either simply download open source software and struggle with
> > getting it running or they can pay a small fee and get a fully
> tested and
> > installable package.  If one needs to do something other than the basic
> > installation then they could buy into a support program that
> lets them get
> > questions answered in a timely manner.  In the cases where someone needs
> > to
> > do something novel they have a source of developers they could potential
> > contract to customize the open source implementation.  I
> beleive that this
> > somewhat describes the maturing of the open source movement and gives a
> > balance between open flexibility and sustaining the cost of on-going
> > development.  When open source is left only to volunteer
> efforts of a few
> > people it presents a risk to any business who has the desire to
> adopt the
> > open source solution but does not want to find itself without
> support when
> > defects are found or new releases as technology advances.  Of
> course with
> > patience it is possible to solve many issues when adopting open
> source by
> > asking for help from volunteers, unfortunately most business
> can't afford
> > to
> > depend on this and need something more definate.
> >
> > This is somewhat dealing with market perception more than reality in the
> > case of Lua.  For example; if one was to perceive that Lua
> development and
> > future releases had a commercial incentive then it would be more likely
> > that
> > the language would be supported in the future.  The perception now (I my
> > opinion) is that Lua is a powerful scripting language with
> academic appeal
> > and of interest to the technically gifted and curious.  I recognize that
> > the
> > reality is that Lua is actively supported and that if one
> needed help I'm
> > sure one would be able to find a volunteer to answer questions.
> >
> > While the approach the Lua community is taking today leaves opportunity
> > for
> > a wide variety of uses for Lua it limits the adoption to those
> who wish to
> > make Lua part of an existing effort.  Lua has the benefit of
> being small,
> > simple and fast but lacks the builtin libraries that might make it
> > generally
> > usefull to a broad range of uses.  Each person needs to start
> with a small
> > Lua core and integrate it with whatever they deem necessary.  This is
> > somewhat a philosophical position that I think the Lua
> community has taken
> > intentionally.  In contrast Python can be small as well but it
> has a large
> > set of standard libraries that one could use immediately.  If
> one needs a
> > small version of Python its easy enough to strip away what is
> not needed.
> > Therefore it all depends on where the Lua community assumes the use for
> > Lua
> > will be.  Today the assumption seems to be that it is not
> general purpose
> > and omits the large standard library approach.  My suggestion
> is that Lua
> > should come with an optional large standard library.
> >
> > I beleive that Lua may be very close to being a viable option
> for not just
> > Python but other emerging languages as well.  For example; I looked at
> > Yindo.com, which is based on Lua and is probably the most
> powerful script
> > technology for the internet around, I was able to execute the complex
> > demos
> > in just a few minutes.  Each of these demos are just a few
> lines of code.
> > In contrast if one was to attempt the exact same demos using ActiveX, a
> > Java
> > applet, or Flash the download time alone would be so long as to not make
> > it
> > practical.  Looking at Curl.com you'll see another example of a failed
> > strategy, to run the demo's requires a 12meg download and installation
> > process.  IBM research has put out Sash Weblications which
> again requires
> > lots of downloads and setup and runs slowly.  A good example of
> what Yindo
> > and Lua could easily compete with is Rebol.com.  Rebol approach to the
> > internet is very lean and powerful with a language that is simple,
> > flexible,
> > and lightweight.
> >
> > Aside from the support question I raise above I beleive that if the Lua
> > community took on the effort of adopting a standard library
> that included
> > all of something like what Yindo attempted it would position the Lua
> > effort
> > as a direct alternative to Python, Ruby and other scripting languages.
> >
> > You may be asking, "well if he thinks that Yindo is the way to
> go then why
> > not just use it and leave Lua the way it is", this basically
> goes back to
> > the support and commercial issues.  The Yindo effort was three guys, all
> > of
> > whom seem to have moved on to other projects and do not
> maintaining Yindo
> > anymore.  One of the Yindo founders has even started to create
> yet another
> > scripting language.  Same for several of the Lua projects I have asked
> > about
> > over the internet.  Nearly all of them were great ideas started by a
> > single
> > person who only periodically supported the Lua project they started or
> > have
> > completely stopped the effort.
> >
> > I want to consider using Lua for a commercial project but for now I'll
> > only
> > look at it as another very cool scripting language to program
> in for fun.
> >
> >
> >
> ###########################################
> This message has been scanned by F-Secure Anti-Virus for
> Microsoft Exchange.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: RE: Ideas for implementing commercial support for Lua

Andy Stark
Just another humble opinion from someone who hasn't even used Lua for
anything serious yet:-

All the ideas expressed so far about getting some commercial input into
Lua seem to have one major flaw: they are all about making Lua resemble
the languages that are already established ("Lua could compete with
Rebol", "Lua should have a large standard library like Python does",
"needs a graphical GUI, IDE", etc).

I think Lua's very strength lies in the fact that it DOESN'T have these
features. The philosophy behind Lua is that it should be very easy to
embed and I think this requires it to be minimal but effective
nevertheless.

We have observed that, say, Python CAN be stripped down to a minimal
implementation which can be embedded. But embeddability is not exactly
Python's forte and is a relatively minor design issue in the language.
For example, I doubt that Python could boast that it is "written in
ANSI C, and compiles unmodified in all known platforms". You can't just
pick Python up and drop it into your app.

Lua, on the other hand IS specifically designed to be embeddable. I
think this is what the authors intended it to be all along and this
strength is what should be developed in the future. There is no point in
adding features that are common in other languages (at least we
shouldn't treat this as high priority) because we will simply end up
re-inventing Python or Perl or Rebol. As programmers, we are all
concerned about avoiding unnecessary code duplication, and this is code
duplication of the worst kind: open source projects competing for the
same niche!

It will take considerable creative effort to preserve Lua's fresh and
distinctive spirit because (I think) it is the first language whose
syntax and implementation are specifically designed for "extreme"
embeddability above all else. But if we put respectability above
embeddability, then we will end up with another Python. Don't get me
wrong, Python is great, but we don't need two of them!

&.
Reply | Threaded
Open this post in threaded view
|

Re: RE: Ideas for implementing commercial support for Lua

Fabio Reis Cecin
Andy Stark wrote:
> There is no point in
> adding features that are common in other languages (at least we
> shouldn't treat this as high priority)
I think it's all worth a try. In the end, it's just about marketing: if you make
things clear on your marketing efforts that the focus is at embedding and having
a lightweight, 100% ANSI-C core, there's no reason not to start developing
fancy add-ons around it.
And if you are really concerned abount mixing things up, then develop the add-on
at a separate project-website - get a sourceforge account for it, etc.

--
[]'s
Fábio R. Cecin
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RE: Ideas for implementing commercial support for Lua

Andy Stark
>if you make
>things clear on your marketing efforts that the focus is at embedding and having
>a lightweight, 100% ANSI-C core, there's no reason not to start developing
>fancy add-ons around it.
>And if you are really concerned abount mixing things up, then develop the add-on
>at a separate project-website - get a sourceforge account for it, etc.

This is exactly what I mean. The headline on the Lua website should be "here's a language designed for embeddability (and by the way, some of the things you can embed it in are a command line tool, an IDE, etc)" in contrast to "here's another language with an IDE, a GUI toolkit, a standard library, etc (oh and by the way, you can embed it if you like)" which is what you get with other languages. Put the emphasis on embedding and reinforce and promote the language in this area and you have a distinctive identity.

Deep down, programmers know that you can use almost any language for almost anything, but still tend to associate different languages with different types of task (Lisp is seen as an AI language, Perl is seen as a text processing language, etc). All this means is that the language has a slight bias toward the task it is associated with, but the difference it makes from a marketing point of view is enormous. The difficulty Lua faces is that its target task of extreme embeddability is relatively unexplored territory. I think that injecting a few novel ideas about embeddability into Lua will help people to see that it is not a trivial task and deserves special treatment.

&.
Reply | Threaded
Open this post in threaded view
|

Re: RE: Ideas for implementing commercial support for Lua

Luiz Henrique de Figueiredo
In reply to this post by Ray Garcia
>   Put the emphasis on embedding

That's the first sentence in Lua's description:

 Lua is a powerful light-weight programming language designed for
 extending applications.

Or do you mean "embedded" as in "embedded systems", that is, small machines,
such as network switches or robots or microwave ovens?

>   The difficulty Lua faces is that its target task of extreme
>   embeddability is relatively unexplored territory. I think that
>   injecting a few novel ideas about embeddability into Lua will help
>   people to see that it is not a trivial task and deserves special
>   treatment.

Could you be more specific on what those ideas might be? We're definitely
interested in seeing Lua used in small machines but we have little experience
with those.

Thanks.
--lhf

Reply | Threaded
Open this post in threaded view
|

randomseed

Bram Vaessen
There is no info about the randomseed function in the library. How do I
randomize the random function??
(like srand(time()) )

thanks


Reply | Threaded
Open this post in threaded view
|

Re: RE: Ideas for implementing commercial support for Lua

Philippe Lhoste
In reply to this post by Andy Stark
On 2002/11/14 12:35:04, "Andy Stark" <[hidden email]>
wrote: 

> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <html><head></head><body bgcolor="#FFFFFF">
> <div
> style="margin-left:10px;margin-right:10px;text-indent:0px;padding-left:
> 0px;padding-right:0px;margin-top:0px;"><font face="Geneva" size="+0"
> color="#000000" style="font-size:10pt;color:#000000;">Just another
> humble opinion from someone who hasn't even used Lua for<br>anything
> serious yet:-<br><br>All the ideas expressed so far about getting some
> commercial input into<br>Lua seem to have one major flaw: they are all
> about making Lua resemble<br>the languages that are already
> established (&quot;Lua could compete with<br>Rebol&quot;, &quot;Lua
> should have a large standard library like Python
> does&quot;,<br>&quot;needs a graphical GUI, IDE&quot;, etc).<br><br>I
> think Lua's very strength lies in the fact that it DOESN'T have
> these<br>features. The philosophy behind Lua is that it should be very
> easy to<br>embed and I think this requires it to be minimal but
> effective<br>nevertheless.<br><br>We have observed that, say, Python
> CAN be stripped down to a minimal<br>implementation which can be
> embedded. But embeddability is not exactly<br>Python's forte and is a
> relatively minor design issue in the language.<br>For example, I doubt
> that Python could boast that it is &quot;written in<br>ANSI&#160;C,
> and compiles unmodified in all known platforms&quot;. You can't
> just<br>pick Python up and drop it into your app.<br><br>Lua, on the
> other hand IS specifically designed to be embeddable. I<br>think this
> is what the authors intended it to be all along and this<br>strength
> is what should be developed in the future. There is no point
> in<br>adding features that are common in other languages (at least
> we<br>shouldn't treat this as high priority) because we will simply
> end up<br>re-inventing Python or Perl or Rebol. As programmers, we are
> all<br>concer ned about avoiding unnecessary code duplication, and
> this is code<br>duplication of the worst kind: open source projects
> competing for the<br>same niche!<br><br>It will take considerable
> creative effort to preserve Lua's fresh and<br>distinctive spirit
> because (I think) it is the first language whose<br>syntax and
> implementation are specifically designed for
> &quot;extreme&quot;<br>embeddability above all else. But if we put
> respectability above<br>embeddability, then we will end up with
> another Python. Don't get me<br>wrong, Python is great, but we don't
> need two of them!<br><br>&amp;.<br> </font></div></body></html>

Wow, hard to read!
This has been discuted already, between those using Lua as an extension 
language, and those using it as a scripting language.

I mainly use it as a scripting language, because it fits most of my needs 
and I like the syntax. And since my needs are small, I have (currently) no 
time to learn Python or improve my Perl.

But I also plan to use it as extension language (to SciTE, to other future 
applications...) so I am concerned by both aspects of the language.

Even in a world of gigahertz and gigabytes, I still care for small and 
fast applications, so I don't want Lua to become bloated.
You can perhaps strip down Python to a small core, but at least for 
Windows, unless using a independent, perhaps outdated distribution, you 
have to download a 8~9MB file and install it before stripping out... If 
all you want is to run a small script found elsewhere, it is overkill.

Yes, Lua must still be available as Ansi C source code and small binaries.
We should never have to strip down Lua to get small binary, but instead be 
able to download various extensions, perhaps as a whole package if needed.
If someday we devise a standard way to extend Lua as scripting language, 
using external modules, it would be a great improvement.

Such use is much more popular, and as such, it can introduce Lua to a 
wider range of people, which may be pleased to be able to embed it later, 
using an already familiar language.

Last note: Lua is a living language, and authors are open to suggestions 
to improvement, while still keeping in mind their initial goals. That's a 
very good thing, even if compatibility with previous versions is sometime 
broken. That's good, we don't want to carry obsolete functionality just 
for the sake of backward compatibility. As the main purpose of Lua is to 
be embedded/integrated, authors can choose to keep an old version or 
[re]design for the newest, greatest version.

The drawback is that if there are many modules/add-ons, they must all be 
updated to the latest version. That's already the case with some current 
libraries, and this probably won't dissapear with external modules. And I 
don't want this "problem" to slow down innovation. So we have to live with 
this.

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/



Reply | Threaded
Open this post in threaded view
|

Re: randomseed

Philippe Lhoste
In reply to this post by Bram Vaessen
On 2002/11/14 12:16:36, "Bram Vaessen" <[hidden email]> wrote:

> There is no info about the randomseed function in the library. How do I
> randomize the random function??
> (like srand(time()) )

to the simple random generator functions rand and srand, provided by ANSI 
C."

Now, we don't have a time() function...

Perhaps try:

dostring("timev = " .. date('%Y') .. date('%j') ..
  date('%H') .. date('%M') .. date('%S'))
randomseed(timev)

or other combinations of these values.

There may be a simpler method...

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/



Reply | Threaded
Open this post in threaded view
|

External modules was Re: Ideas for implementing commercial support for Lua

Björn De Meyer
In reply to this post by Philippe Lhoste
Philippe Lhoste wrote:
> 
> Yes, Lua must still be available as Ansi C source code and small binaries.
> We should never have to strip down Lua to get small binary, but instead be
> able to download various extensions, perhaps as a whole package if needed.
> If someday we devise a standard way to extend Lua as scripting language,
> using external modules, it would be a great improvement.

This is the key feature that Lua should aquire. An advanced
system by wich available C libraries can be easily integrated,
without recompiling. Hmmm... perhaps it could be posible to 
make a single  "libluaproxy" that uses Lua scripts as a description
language for the functions that are to be called, and works
as a go-in-between between Lua and regular C functions. 
It could work a bit like the "Declare function" statements 
in Visual Basic. 


-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: External modules was Re: Ideas for implementing commercial support for Lua

Thatcher Ulrich
On Nov 15, 2002 at 07:26 +0100, Bj?rn De Meyer wrote:
> Philippe Lhoste wrote:
> > 
> > Yes, Lua must still be available as Ansi C source code and small binaries.
> > We should never have to strip down Lua to get small binary, but instead be
> > able to download various extensions, perhaps as a whole package if needed.
> > If someday we devise a standard way to extend Lua as scripting language,
> > using external modules, it would be a great improvement.
> 
> This is the key feature that Lua should aquire. An advanced
> system by wich available C libraries can be easily integrated,
> without recompiling.

Hear hear!

Actually, several such systems exist; the problem is there's no
officially-blessed standard.  I think the most Lua-like approach to
this is Ignacio Casta.o's luselib (but I can never find the URL when I
look for it! ):

Anyway, we've gone over this before.  My summary: some users
(especially embedded developers) thought that including a DLL loader
in the Lua distribution would be the thin edge of the wedge towards a
bloated distro, and objected; others (including me) thought it would
help extend Lua without bloating; the result was that Lua authors
added the LUA_USERCONFIG and lua_userinit hooks to lua.c in 5.0-alpha.

MHO is that lua_userinit is nice, but I'd like to see luselib.c
somewhere in the distro as well (not enabled by default), so that at
least there is a baseline official implementation, and people can
distribute shared-library binaries with some confidence.

> Hmmm... perhaps it could be posible to 
> make a single  "libluaproxy" that uses Lua scripts as a description
> language for the functions that are to be called, and works
> as a go-in-between between Lua and regular C functions. 
> It could work a bit like the "Declare function" statements 
> in Visual Basic. 

That could be cool; I think though that the bare minimum (and
therefore most likely to be acceptable to the Lua community) is
something like luselib, which provides a very simple API to
specifically-designed C-language shared libraries.

-- 
Thatcher Ulrich
http://tulrich.com

Reply | Threaded
Open this post in threaded view
|

Re: External modules was Re: Ideas for implementing commercial support for Lua

Thatcher Ulrich
On Nov 15, 2002 at 02:14 -0500, Thatcher Ulrich wrote:

> MHO is that lua_userinit is nice, but I'd like to see luselib.c
> somewhere in the distro as well (not enabled by default), so that at
> least there is a baseline official implementation, and people can
> distribute shared-library binaries with some confidence.

On second thought, rather than argue about this, how about we set up a
section on the wiki at lua-users.org for binary modules?  I.e. make a
page with links to luselib-enabled versions of the lua.c interpreter,
and provide a place to upload binary modules.  I have a Lua SDL
binding ready to go, and I think it would be a nice alternative outlet
for the database bindings, socket libraries, and XML projects that
have been talked about on the list.  This way, we can gauge the level
of interest in such a feature before hassling the Lua authors with yet
another feature request.

-- 
Thatcher Ulrich
http://tulrich.com

Reply | Threaded
Open this post in threaded view
|

RE: External modules was Re: Ideas for implementing commercial support for Lua

Brownsword-2
In reply to this post by Thatcher Ulrich
I object to the "including a DLL loader" statement.  It carries a lot of meaning that you perhaps did not intend -- most platforms don't have "DLLs", and "loading" would not be appropriate either.  If you mean a system by which you can bind additional functionality into Lua at runtime without changing the Lua source code, then that could be quite useful (assuming it doesn't cause a performance hit).  If you mean a Win32 DLL load implementation then that has no place in Lua, except perhaps as a sample implementation of how to use the runtime binding facility.

One thing we are looking at, in particular, is how to add a couple of data types to Lua without having the overhead associated with metatables and Lua/C calls.  The operations on these types are very quick, on the order to 10-20 times faster than just making the call to C, and it would be much faster if these could be intrinsic operations in the VM.


-----Original Message-----
From: Thatcher Ulrich [[hidden email]]
Sent: Friday, November 15, 2002 11:15 AM
To: Multiple recipients of list
Subject: Re: External modules was Re: Ideas for implementing commercial
support for Lua


On Nov 15, 2002 at 07:26 +0100, Bj?rn De Meyer wrote:
> Philippe Lhoste wrote:
> > 
> > Yes, Lua must still be available as Ansi C source code and small binaries.
> > We should never have to strip down Lua to get small binary, but instead be
> > able to download various extensions, perhaps as a whole package if needed.
> > If someday we devise a standard way to extend Lua as scripting language,
> > using external modules, it would be a great improvement.
> 
> This is the key feature that Lua should aquire. An advanced
> system by wich available C libraries can be easily integrated,
> without recompiling.

Actually, several such systems exist; the problem is there's no
officially-blessed standard.  I think the most Lua-like approach to
this is Ignacio Casta.o's luselib (but I can never find the URL when I
look for it! ):

Anyway, we've gone over this before.  My summary: some users
(especially embedded developers) thought that including a DLL loader
in the Lua distribution would be the thin edge of the wedge towards a
bloated distro, and objected; others (including me) thought it would
help extend Lua without bloating; the result was that Lua authors
added the LUA_USERCONFIG and lua_userinit hooks to lua.c in 5.0-alpha.

... edited for brevity ...

Reply | Threaded
Open this post in threaded view
|

RE: External modules was Re: Ideas for implementing commercial support for Lua

Pyrogon Public
> I object to the "including a DLL loader" statement.  It 
> carries a lot of meaning that you perhaps did not intend -- 
> most platforms don't have "DLLs", and "loading" would not be 
> appropriate either.

I disagree.  Both implicit and explicit loading of shared libraries are
fairly common across a wide range of platforms.  Obviously, they can't
be implemented on ALL systems, but even DOS had this facility via
overlays and even loading Windows DLLs under DOS4GW.

Under Win32, you have the LoadLibrary()/GetProcAddress() calls; under
Unix there are dlopen()/dlsym()/dlclose(); under MacOS you could use the
Code Fragment Manager to dynamically load code resources; under OS X
there are NSBundles; under Carbon for MacOS/OS X there are CFBundles;
there are shared libraries; and many other operating systems support the
notion of dynamically loading code.

So as a concept, the ability to "load a piece of code and call it from
Lua" is generally applicable, but because this isn't ALWAYS the case, I
would think it should stay out of the core or at least be conditionally
compiled out.

Brian


Reply | Threaded
Open this post in threaded view
|

Re: External modules was Re: Ideas for implementing commercial support for Lua

Steve Dekorte-4

On Friday, November 15, 2002, at 12:13 PM, Pyrogon Public wrote:
I disagree.  Both implicit and explicit loading of shared libraries are
fairly common across a wide range of platforms.

Does this include game consoles, PDAs and cellphones?

Cheers,
Steve
OSX freeware and shareware: http://www.dekorte.com/downloads.html


Reply | Threaded
Open this post in threaded view
|

RE: External modules was Re: Ideas for implementing commercial support for Lua

Pyrogon Public
> Does this include game consoles, PDAs and cellphones?

My contention was not that dynamic libraries are ubiquitous, but that
they are more than just a Windows-specific hack.  Some PDAs support the
notion of dynamically loaded code, for example PocketPC/WinCE and
Sharp/Zaurus.  Most game consoles do not.

Brian


Reply | Threaded
Open this post in threaded view
|

Re: External modules was Re: Ideas for implementing commercial support for Lua

Luiz Henrique de Figueiredo
In reply to this post by Brownsword-2
>the result was that Lua authors
>added the LUA_USERCONFIG and lua_userinit hooks to lua.c in 5.0-alpha.

Much in the spirit of Lua :-)

Anyway, it may have gone unnoticed that it is pretty simple to compile 5.0-alpha
to get support for DLL loading. It's a simple matter of uncommenting a line in
config. The code for this resides in etc/, outside the core.
--lhf

1234