What packages shoudl be in the base install?

[Ryan Pusztai]

Hi Everyone,

I thought I would move the discussion of what packages should be removed or included in the new LfW base install. I think if we can look at the current package list [1] and let everyone know the list of modules you use most that might give us an idea for what should be included.

I will copy Steve D. proposal with a few peoples responses. Please don't feel left out if I missed something, just reply back with your comments. Thanks.

--

Regards,
Ryan

[1] http://luaforwindows.googlecode.com

On Wed, Mar 20, 2013 at 3:27 AM, steve donovan <steve.j...@gmail.com> wrote:

On Tue, Mar 19, 2013 at 9:23 PM, Andrew Wilson <agrw...@gmail.com> wrote:

> minimal is good, remove IUP,
> allowing user selection of packages is whole idea, so only ship with
> reasonable functional packages,

As for the 'optimally sized core' (not necessary 'minimal'):  I'm
looking at the package list for the Batteries. There are packages
which overlap in functionality (always bearing in mind that any
removed packages will be 'one click away' from being installed)

  - yes, IUP is cute, but wxLua is more commonly used and less eccentric
  - much as refugees from other languages like them, do we need
'standard' regexp packages when we have lpeg? E.g. lrexlib
  - luaex is an interesting package, which was originally meant as an
'executable proposal'. It replicates stuff which is available through
luafilesystem and other packages.
  - OIL is marginal, don't think casual scripters would need CORBA support
  - there are a number of packages which work with compressed archives
- do we need them all?
  - if we have luaexpat, do we need luaxml?
  - if we have Lanes, do we need luatask and rings?
  - metalua is a very cool project, but does it need to be part of the base?
  - do people use luadate?  (there's already a pl.Date class in Penlight)

On the other hand, on the Windows side I'd suggest these packages
   - winapi   (ok, I'm biased ;))
   - luacom  (not yet available as binary)

And  luasql - seems there's a MySQL backend - what about sqlite3 as
well?  That's a much more learner-friendly option.

steve d.

 On Wed, Mar 20, 2013 at 9:49 AM, Ryan Pusztai <rpus...@gmail.com> wrote:

On Wed, Mar 20, 2013 at 3:27 AM, steve donovan <steve.j...@gmail.com> wrote:

As for the 'optimally sized core' (not necessary 'minimal'):  I'm

looking at the package list for the Batteries. There are packages
which overlap in functionality (always bearing in mind that any
removed packages will be 'one click away' from being installed)

I agree with this sentiment completely. I want a 90-95 percent coverage of what most people will use from day to day. Having to install new packages every time I install LfW would get very tiring and I think the reason for the success of LfW is that it did include enough modules to allow users to write real applications using Lua.

  - yes, IUP is cute, but wxLua is more commonly used and less eccentric

Agreed. Remove from the base. (P.S. I see that wxFormBuilder [1] (WYSIWYG GUI editor) is getting wxLua support in a branch)

 

  - much as refugees from other languages like them, do we need
'standard' regexp packages when we have lpeg? E.g. lrexlib

No. Remove from the base. 

  - luaex is an interesting package, which was originally meant as an
'executable proposal'. It replicates stuff which is available through
luafilesystem and other packages.

Agreed. Remove from the base. But I am not sure how any Lua user would be able to set an environment variable.

 

  - OIL is marginal, don't think casual scripters would need CORBA support

Agreed. Remove from the base.

 

  - there are a number of packages which work with compressed archives
- do we need them all?

Is there overlap in archive file types? I use .zip and .gz and I think they are in different modules. So I think that if there is no overlap I would keep them all.

 

  - if we have luaexpat, do we need luaxml?

I tend to agree, but I have to say that LuaExpat is harder for me to use and I actually switched to using Penlights XML module where you hide it all. I know Penlight uses LuaExpat, so to me LuaExpat is the clear winner.

 

  - if we have Lanes, do we need luatask and rings?

This is less clear for me. I have tried Lanes and really would prefer to include ZeroMQ. But I thought rings was native Lua implimentation of "threading" and so I think there is a reason to have Lanes and rings/luatask.

  - metalua is a very cool project, but does it need to be part of the base?

Agreed. Remove from the base.

 

  - do people use luadate?  (there's already a pl.Date class in Penlight)

Agreed. Remove from the base.

 

On the other hand, on the Windows side I'd suggest these packages
   - winapi   (ok, I'm biased ;))

Sure, but that module is not as exciting as find the components in a module that is cross-platform, but I guess we could say that luaposix is the unix equivialnt of winapi for Windows. So I guess I talked myself into it :) Put it in there.

 

   - luacom  (not yet available as binary)

I could see this be put in there is there are tests. I have tried to use this twice and was not successful at all.

 

And  luasql - seems there's a MySQL backend - what about sqlite3 as
well?  That's a much more learner-friendly option.

Here is my biggest sticky point. I believe that database support in the main Batteries is critical and having a module like LuaSQL makes your application more maintainable. What I mean by this is I have many Lua applications written using LuaSQL and I was able to reuse most of the DB stuff and I am using SQLite3, MySQL and Postgress with minimal code changes. That is why I feel like it should be included. Now that being said, it doesn't seem to be very supported these days and at least on the SQLite3 side I had a bug reported with a pull request to fix the binding to allow PRAGMA use and I don't know if it will be released. So I took some time to look at the Lua and database world and found LuaDBI. I actually really like it and it has support, at least for, MySQL, SQLite3, and Postgress. It is in LuaRocks and debian packages it. I am proposing possibly switching to that database wrapper. Thoughts?

 On Wed, Mar 20, 2013 at 10:52 AM, Andrew Starks <andrew...@trms.com> wrote:

On Mar 20, 2013, at 8:49 AM, Ryan Pusztai <rpus...@gmail.com> wrote:

Snip: agreed with everything. 

Is there overlap in archive file types? I use .zip and .gz and I think they are in different modules. So I think that if there is no overlap I would keep them all.

 

  - if we have luaexpat, do we need luaxml?

I tend to agree, but I have to say that LuaExpat is harder for me to use and I actually switched to using Penlights XML module where you hide it all. I know Penlight uses LuaExpat, so to me LuaExpat is the clear winner.

I wrote a really functional XML parser in Lpeg. It didn't do do type verification, but did give comprehensible error messages, etc. There is another one out there that supports UTF8. 

I love the idea that Penlight + LPEG = most of the tools you need, except for external integration. I'd vote to look at Penlight development as a way to fill in the missing pieces (replace its CSV parser with an LPEG variant that can take callbacks, etc). 

That said, it doesn't get any more standard than expat. It's just I would lean towards a story that says, "look what you're doing for less than a 2meg download, and look how we make it super easy to bring more in!"

Expat is clean, but I guess I feel like I could build real software with Penlight and LPEG and I would still retain the feeling that I understand the entire language and everything I downloaded in my brain. 

 

  - if we have Lanes, do we need luatask and rings?

This is less clear for me. I have tried Lanes and really would prefer to include ZeroMQ. But I thought rings was native Lua implimentation of "threading" and so I think there is a reason to have Lanes and rings/luatask.

Here is where I take a left turn, as well...

 

This is an advanced topic with some very cool upsides. ZeroMQ has that awesome "Lua Feel." Also, it's one that benefits from someone doing the hard labor of making it work on Windows. 

I feel like a hero in 10 seconds, walking through their awesome tutorials. 

The question that I have is: can this be wired together with other parts (already included or more Lua code) to emulate something that approaches Node.js, even just a little? I don't think we should include a huge event library, but it would be awesome to be able to "point the way."

Generally, I'm always looking for ways to get Lua and ZMQ to be together. The are from the exact same school of thought. 

 

On the other hand, on the Windows side I'd suggest these packages
   - winapi   (ok, I'm biased ;))

Sure, but that module is not as exciting as find the components in a module that is cross-platform, but I guess we could say that luaposix is the unix equivialnt of winapi for Windows. So I guess I talked myself into it :) Put it in there.

 

   - luacom  (not yet available as binary)

I can see the merit in including this, if it can be aligned with some hyper-useful tutorials. 

I could see this be put in there is there are tests. I have tried to use this twice and was not successful at all.

 

And  luasql - seems there's a MySQL backend - what about sqlite3 as
well?  That's a much more learner-friendly option.

Here is my biggest sticky point. I believe that database support in the main Batteries is critical and having a module like LuaSQL makes your application more maintainable. What I mean by this is I have many Lua applications written using LuaSQL and I was able to reuse most of the DB stuff and I am using SQLite3, MySQL and Postgress with minimal code changes. That is why I feel like it should be included. Now that being said, it doesn't seem to be very supported these days and at least on the SQLite3 side I had a bug reported with a pull request to fix the binding to allow PRAGMA use and I don't know if it will be released. So I took some time to look at the Lua and database world and found LuaDBI. I actually really like it and it has support, at least for, MySQL, SQLite3, and Postgress. It is in LuaRocks and debian packages it. I am proposing possibly switching to that database wrapper. Thoughts?

Also I am not a fan of a different module interface for each DB. I know that it can make more of each database specific functionality usable, but as the base of what should come with Batteries/LfW or LfL I think it should be an opt-in thing to go specific.

I hope this makes sense. It was harder to start the new topic than I thought. 

--

Regards,

Ryan

[Andrew Starks]

I acknowledge my own bias might be interfering with my view on this,
so with that...

Given that a major feature of this system is to make it breathtakingly
simple to install additional modules, showing off what can be done
with very little seems like a great way to teach. That is, be a
completely working system but with very little code.

Also, when I'm writing software, everything that I add is both a
solution and a burdon. So, I always look to use tools that use what
I'm already loading...

If that isn't a big part of everyone's thinking, then my approach
won't be a good one and I really am happy to pick some other,
reasonable approach, such as "best over-all tool for a job that is
likely to be considered out-of-the-box possible."

Mine would go something like, " Provide a complete system with as much
Lua as possible, aiming for The Lua Way, and not for 100% feature
coverage with every module."

For example, JSON, XML and CSV can all be beautifully parsed by LPeg.
My vote would be to use it for these purposes and include the Lua
library (or extend Penlight) to provide that configured parser.

For database access, I'd vote for LuaSQL and leave the others on-demand.

To me, Penlight is such a useful playground that I end up going back
to over and over again, that I would call it "pretty essential." By
its inclusion, you can cut the number needed way down. Also, it's a
good starting point if we need to fill out or extend it.

I like the idea of a set of OS-specific libraries for each targeted
platform, only to show special capabilities with those
integrations.... LuaCOM, etc.

LFS, Xavante (and dependancies), LuaSocket, are all musts (imho)

wxLua

My one vote for indulgence goes to ZeroMQ, because it provides an
advanced playground, fits Lua's philosophy and it's cool. :)

My passion on this topic is limited, though. I'm mostly interested in
keeping the core "batteries" small, just to showcase what can be done
and to contrast it with your typical Ruby experience.

-Andrew

[Andrew Wilson]

Maybe we better list what should be included

Alien

CD

IM

EX

LPeg

Date

LuaDoc

LuaExpat

LuaFileSystem

LuaLogging

LuaProfiler

LuaSocket

LuaSQL

LuaUnit

stdlib

wxLua

lpack

VStruct

LuaBitOps

LuaXML

Penlight

LuaRocks

LuaJSON

+

ZeroBane

LuaDist

feel free to add what you feel must be included or removed...

Another option on install could be to do a minimal install or maximal install so that install binary can optionally support a heavier full batteries style install

AGRW

[marbux]

utf-8.lua <http://www.curse.com/addons/wow/utf8>.
strict.lua

[Thijs Schreijer]

> > Alien
> > CD
> > IM
> > EX
> > LPeg
> > Date
> > LuaDoc

Replace LuaDoc with Ldoc

> > LuaExpat
> > LuaFileSystem
> > LuaLogging
> > LuaProfiler
LuaProfiler is an advanced tool for coders, not a 'battery', so should not be included

[steve donovan]

On Wed, Mar 20, 2013 at 9:46 PM, Andrew Starks <andrew...@trms.com> wrote:
> with very little seems like a great way to teach. That is, be a
> completely working system but with very little code.

Although, Ryan has a point: we don't want something too small, and
modern people don't dare that much about download size. It's possible
to also publish a 'core' archive but then we have extra management
burden. Or, if we know that the machine has an internet connection,
to use luadist to fill in the rest. (However to be honest I am not
that happy with big packages which then proceed to download even
bigger packages, like the Android SDK) The main thing is that the zip
is curated as a 'whole' and provides at least links to all the
documentation.

Then you may publish a script and know that it will be usually covered
by the 90% rule. If you have dozens of machines, like Ryan, that
makes life much easier.

> Mine would go something like, " Provide a complete system with as much
> Lua as possible, aiming for The Lua Way, and not for 100% feature
> coverage with every module."

Exactly!

> For example, JSON, XML and CSV can all be beautifully parsed by LPeg.
> My vote would be to use it for these purposes and include the Lua
> library (or extend Penlight) to provide that configured parser.

There is a problem of demarcation here; I've always wanted Penlight to
have minimal dependencies (only essential to have lfs); the emphasis
is on 'pure Lua'. Also, it's a general purpose library so it doesn't
try to cover different 'universes' - a fine example of that would be
database support. I'd hesitate to support JSON because heaven knows
there's enough Lua modules to do that, and for some reason everybody
and their dog writes another one. XML is something of an exception -
I rationalized including XML support because luaexpat just does
parsing, and there was a clear need for a prettyprinter, etc that
would work with the LOM representation. Although strictly speaking
that was the whole point of my LuaexpatUtils module...

Another favourite area of replication is parsing command-line
arguments. Penlight continues in this tradition by offering two
distinct ways, a simple thirty-line one and Lapp, which is
specification-driven.

I totally agree that LPeg is a fantastic implementation technology. I
dd a CSV parser module in C and Josh Jensen showed a short lpeg script
which was slightly faster ;) This was humbling and highly
educational.

> I like the idea of a set of OS-specific libraries for each targeted
> platform, only to show special capabilities with those
> integrations.... LuaCOM, etc.

Especially for things which have no clear cross-platform equivalent, e.g. COM.

Ryan raises an interesting point about luaex; although it replicates
other functionality, it's the only cross-platform package that allows
you to set an environment variable. Both winapi and luaposix provide
this, but they're otherwise rather different. So perhaps luaex should
be in just for that one job? It's a pity IHMO that luaex did not
become 'canonical' because it really pushed the cross-platform thing.
It's failing was that it did not try to complement things like
LuaFileSystem, and basically reimplemented most of lfs. (Also, it put
stuff into os. Lua people get irritated with that)

Well, we are clever people, and are free to write our own modules, or
adapt code from existing modules. But looking after a distro is
enough trouble without having to work upstream as well!

> LFS, Xavante (and dependancies), LuaSocket, are all musts (imho)

Xavante is important technology, but I don't know if it's something
everyone needs, especially if it is directly available from the repo.
Ryan does a lot of work with Orbit so he can speak about this need.

> My one vote for indulgence goes to ZeroMQ, because it provides an
> advanced playground, fits Lua's philosophy and it's cool. :)

It did seem very powerful and interesting, well worth an evaluation.
(As for 'node.js-like functionality' there is luvit, but it isn't
suitable for inclusion, since it's basically a node.js implementation
using a custom LuaJIT - luvit programs in fact look just like node.js
programs. luvit doesn't even implement coroutine.*)

steve d.

[steve donovan]

On Thu, Mar 21, 2013 at 10:10 AM, Thijs Schreijer
<th...@thijsschreijer.nl> wrote:
>> > LuaProfiler
> LuaProfiler is an advanced tool for coders, not a 'battery', so should not be included

I tend to agree with you, ditto for luacov. The 'batteries' are
essentially an extended run-time, not a full developer kit.

Although by _that_ logic ZBstudio is a dev tool - but logic does not
always have to be followed to its end, particularly because ZBStudio
is not very big and mostly relies on wxLua which is an essential.

(It's a pity that this group is called 'luaforwindows' because we're
really discussing issues that apply to 'Lua for X'.)

steve d.

[steve donovan]

On Wed, Mar 20, 2013 at 8:40 PM, Ryan Pusztai <rpus...@gmail.com> wrote:
> I thought I would move the discussion of what packages should be removed or
> included in the new LfW base install.

This quote of Ryan is particularly important:

"My biggest fear is that we streamline the install down to the
smallest it can be, causing users to go and script LuaDist to install
all the "meaningful" packages needed to write common applications.
Now based on the list of modules that Steve D. suggested I can totally
tell that this is not the proposal, but I can say that I just don't
want to have to install more modules every time I install LfW on a PC.
I actually maintain quite a large amount of PCs that I have to deploy
this too and I would lose a bunch of time and functionality that I
already have today."

People are quite happy with 16Meg language distros - that's on the
small side actually. As long as they can open up the editor and the
docs, look at tutorials, and start playing/working.

So pruning modules is not to get rid of fat really, it's to reduce
consumer confusion ;) [1]

steve d.

[1] e.g. my first experience of a US supermarket - metres and metres
of different toothpaste brands.

[Thijs Schreijer]

> On Thu, Mar 21, 2013 at 10:10 AM, Thijs Schreijer
> <th...@thijsschreijer.nl> wrote:
> >> > LuaProfiler
> > LuaProfiler is an advanced tool for coders, not a 'battery', so should
> > not be included
>
> I tend to agree with you, ditto for luacov. The 'batteries' are
> essentially an extended run-time, not a full developer kit.
>
> Although by _that_ logic ZBstudio is a dev tool - but logic does not
> always have to be followed to its end, particularly because ZBStudio is
> not very big and mostly relies on wxLua which is an essential.
>

The trick is the word 'advanced' which LuaCov and LuaProfiler both are, whereas ZBS can be considered a 'basic' requirement for coding

[Andrew Starks]

I think it's best to nominate someone to pull the trigger on an
approach, cut the discussion off and call it done. I don't see a
passionate distance between the ideas floating around here and that
I'd be happy with a defined list.

I've been skipping past the point of calling it "Batteries". Batteries implies:

*Everything that you would expect from a complete Lua distribution, in
one downloadable packgage that just works.*

The word "expect" might be the most important part here. All of us are
pretty sure what people "need", but there is a significant segment
where we all depart on what that means. For me at least, "expect"
might be a clearer goal, but I wouldn't be qualified to participate in
what that would be. I didn't know what 3/4 of the modules that you
guys listed were! :)

I've been focused on a different goal, which isn't against this one,
it's only different. Something more like…

*The most accessible introduction to The Lua Way, from a platform that
gives you access to The Lua World.*

So, naturally, I'm nervous of confusion, wanting to avoid 2 or 3 ways
when one is all you need (everyone has expressed this as well). Doing
as much in core Lua is a goal as well.

Achieving an extremely small download, just to make a contrast to
other experiences is on my mind, because I'd like to make a point of
that in the web site's copy. The dream would be: An installation so
small, they think they accidentally downloaded the shortcut to the
distribution instead of the actual file.

Finally, there is the third option, which is a "Minimal Install" and a
"Full Install".

I'm surprisingly lukewarm on this. I'd download every package there
was, if that was an option, just as I do with MacTeX. Lua forces
people like me to think minimally and I like the idea that you start
them focused on something that is core.

If you offer both, then I'd just offer the full installation, because
you'll end up needing to maintain two, only for the people that are
already disciplined enough to start small and they're probably not the
ones that you need to reach.

So, as I see it, it's between emphasizing immediate utility and/or
parity with their expectations VS emphasizing the out-of-box teaching
elements.

If I've fairly stated the positions, I'd like to nominate Peter and
Steve to make the call, or to pick the group that will make the call,
so that we can put this bed.

Cool?

-Andrew

[Ryan Pusztai]

On Thu, Mar 21, 2013 at 4:44 AM, steve donovan <steve.j...@gmail.com> wrote:

...

> Mine would go something like, " Provide a complete system with as much
> Lua as possible, aiming for The Lua Way, and not for 100% feature
> coverage with every module."

Exactly!

100% agree.

> For example, JSON, XML and CSV can all be beautifully parsed by LPeg.
> My vote would be to use it for these purposes and include the Lua
> library (or extend Penlight) to provide that configured parser.

There is a problem of demarcation here; I've always wanted Penlight to
have minimal dependencies (only essential to have lfs); the emphasis
is on 'pure Lua'.  Also, it's a general purpose library so it doesn't
try to cover different 'universes' - a fine example of that would be
database support.  I'd hesitate to support JSON because heaven knows
there's enough Lua modules to do that, and for some reason everybody
and their dog writes another one.  XML is something of an exception -
I rationalized including XML support because luaexpat just does
parsing, and there was a clear need for a prettyprinter, etc that
would work with the LOM representation.  Although strictly speaking
that was the whole point of my LuaexpatUtils module...

Another favourite area of replication is parsing command-line
arguments. Penlight continues in this tradition by offering two
distinct ways, a simple thirty-line one and Lapp, which is
specification-driven.

I totally agree that LPeg is a fantastic implementation technology. I
dd a CSV parser module in C and Josh Jensen showed a short lpeg script
which was slightly faster ;)  This was humbling and highly
educational.

There are good modules to do this job, I think I would stick with them.

 

> I like the idea of a set of OS-specific libraries for each targeted
> platform, only to show special capabilities with those
> integrations.... LuaCOM, etc.

Especially for things which have no clear cross-platform equivalent, e.g. COM.

Ryan raises an interesting point about luaex; although it replicates
other functionality, it's the only cross-platform package that allows
you to set an environment variable.  Both winapi and luaposix provide
this, but they're otherwise rather different.  So perhaps luaex should
be in just for that one job?  It's a pity IHMO that luaex did not
become 'canonical' because it really pushed the cross-platform thing.
It's failing was that it did not try to complement things like
LuaFileSystem, and basically reimplemented most of lfs.  (Also, it put
stuff into os. Lua people get irritated with that)

Well, we are clever people, and are free to write our own modules, or
adapt code from existing modules.  But looking after a distro is
enough trouble without having to work upstream as well!

Agreed. Implementation is lacking, but the functionality is helpful. 

> LFS, Xavante (and dependancies), LuaSocket, are all musts (imho)

Xavante is important technology, but I don't know if it's something
everyone needs, especially if it is directly available from the repo.
Ryan does a lot of work with Orbit so he can speak about this need.

I agree. I would love to see Xavante included. I feel like web technology is an important market for Lua and the world.

 

> My one vote for indulgence goes to ZeroMQ, because it provides an
> advanced playground, fits Lua's philosophy and it's cool. :)

It did seem very powerful and interesting, well worth an evaluation.
(As for 'node.js-like functionality' there is luvit, but it isn't
suitable for inclusion, since it's basically a node.js implementation
using a custom LuaJIT - luvit programs in fact look just like node.js
programs. luvit doesn't even implement coroutine.*)

I think anything that can't be ran as a module should not be part of the base install. It just adds to the confusion.

--

Regards,

Ryan

[Ryan Pusztai]

On Thu, Mar 21, 2013 at 4:49 AM, steve donovan <steve.j...@gmail.com> wrote:

(It's a pity that this group is called 'luaforwindows' because we're

really discussing issues that apply to 'Lua for X'.)

I believe I can change the name of the group. There is an option to leave the email the same too. Or we can change them both.

--

Regards,

Ryan

[Andrew Wilson]

I agree with Mr Stark and Ryan on the Lua Way. 

Lua for Windows has traction and would be a shame to waist that. But things change.

I think goal is to provide "an easy to install, introductory developer environment , with enough batteries to do useful stuff".

How about a new name "Lua for Developers" ?  "Lua for Programmers", "Lua for All"? ???

AGRW

--
You received this message because you are subscribed to the Google Groups "luaforwindows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to luaforwindow...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andrew Wilson]

cool

[Ryan Pusztai]

--

Regards,
Ryan

On Wed, Mar 20, 2013 at 2:40 PM, Ryan Pusztai <rpus...@gmail.com> wrote:

Hi Everyone,

I thought I would move the discussion of what packages should be removed or included in the new LfW base install. I think if we can look at the current package list [1] and let everyone know the list of modules you use most that might give us an idea for what should be included.

Here is my list if I had to pick today.

LPeg

LDoc

LuaExpat

LuaFileSystem 

LuaLogging

LuaSocket

LuaSQL, if we can get the latest code from GitHub to be our base because the current release doesn't support SQLite3 PRAGMAS

LuaUnit

LeMock

MD5

LuaBitOps

wxLua

LuaJSON

SubLua

Penlight

Some concurrency module. My vote is for 0MQ

Optionals:

Xavante

Orbit

[Ryan Pusztai]

On Thu, Mar 21, 2013 at 1:07 PM, Andrew Starks <andrew...@trms.com> wrote:

I think it's best to nominate someone to pull the trigger on an
approach, cut the discussion off and call it done. I don't see a
passionate distance between the ideas floating around here and that
I'd be happy with a defined list. 

I think this exercise is worthwhile. The group of people currently talking about it is small enough to make it helpful.

 

I've been skipping past the point of calling it "Batteries". Batteries implies:

*Everything that you would expect from a complete Lua distribution, in
one downloadable packgage that just works.*

I agree with this. I could not have said that better. I think what made Lua for Windows successful was that people could just download and go. Both as a developer and as a "run-time".

I thinks if we have modules that help people but don't duplicate functionality, then Lua for XX is a success.

I agree. This is actually the reason I choose the current model of Lua for Windows. Full Install didn't seem to bring that many negatives and added so many benifits.

 

So, as I see it, it's between emphasizing immediate utility and/or
parity with their expectations VS emphasizing the out-of-box teaching
elements.

If I've fairly stated the positions, I'd like to nominate Peter and
Steve to make the call, or to pick the group that will make the call,
so that we can put this bed. 

Cool?

Not sure if Peter cares? He is just offering a system to build and deploy new modules. Peter D. do you care enough about this?

--

Regards,

Ryan

[Andrew Starks]

On Thu, Mar 21, 2013 at 12:55 PM, Ryan Pusztai <rpus...@gmail.com> wrote:
> Not sure if Peter cares? He is just offering a system to build and deploy
> new modules. Peter D. do you care enough about this?
> --
> Regards,
> Ryan

Ryan,

Here, my ignorance has gotten in the way. I didn't mean to make a
value statement about who I liked more or less. :) I'm utterly lost on
what projects are involved and who has a history with what. If you're
one of the principles of LfW, please forgive the slight. It wasn't
intended.

To all:

So, if I can, I will take back my nomination. Instead:

I'd favor the person with the most context on the "Batteries" package
making the call on the package list.

The reason is that we will all have fun politely discussing this for a
long time, but the bottom line is that there isn't a right answer and
someone here should say, "This is the first list. It may change."

The benefit is in knowing what to focus on, in terms of documentation.
The core distribution should have some kind of overall manual and
eventually, tutorials that cover using them as little sub-units.

-Andrew

[Andrew Starks]

FWIW: I like this list

Does it include some kind of UTF8 support? I think some lightweight
nod to that would be cool, if it's not already there.

Also, I'm waffling on 0MQ, but if concurrency isn't in there somewhere
already, then I'd vote fore it. Along with it, I'd include the
llthreads module, as well, which is pretty much a part of that
package, anyway.

-Andrew

[Ryan Pusztai]

Andrew,

On Thu, Mar 21, 2013 at 2:28 PM, Andrew Starks <andrew...@trms.com> wrote:

Ryan,

Here, my ignorance has gotten in the way. I didn't mean to make a
value statement about who I liked more or less. :) I'm utterly lost on
what projects are involved and who has a history with what. If you're
one of the principles of LfW, please forgive the slight. It wasn't
intended.

No offence taken, but thanks for the apology. :) 

To all:

So, if I can, I will take back my nomination. Instead:

I'd favor the person with the most context on the "Batteries" package
making the call on the package list.

The reason is that we will all have fun politely discussing this for a
long time, but the bottom line is that there isn't a right answer and
someone here should say, "This is the first list. It may change."

Good point. 

The benefit is in knowing what to focus on, in terms of documentation.
The core distribution should have some kind of overall manual and
eventually, tutorials that cover using them as little sub-units.

Agreed.

--

Regards,

Ryan

[Peter Drahoš]

On Thu, Mar 21, 2013 at 6:55 PM, Ryan Pusztai <rpus...@gmail.com> wrote:

..

Not sure if Peter cares? He is just offering a system to build and deploy new modules. Peter D. do you care enough about this?

Sure I do. LuaDist is almost 7 years old now and started as a project to bring Lua to all the platforms I work on and I am still at it. However I feel Steve D. should be the person who decides on the package selection and policies. Not only is he better qualified than me but also the author of penlight which should be the core module we use as an example to other developers on how to do things. I would also like to nominate you as the second person for this purpose.

However, I feel we can have multiple persons responsible for various parts of the projects. Eg. Steve D. would be responsible for module policies (what tools to use, how to structure them etc). Ryan for module evaluation and selection (what is in, what is out). I am willing to be the person responsible for the technical parts such as CI, tools and of course maintainer of the more complex builds that sometimes need to be done.

pd

[Ryan Pusztai]

On Thu, Mar 21, 2013 at 4:37 PM, Peter Drahoš <dra...@gmail.com> wrote:

On Thu, Mar 21, 2013 at 6:55 PM, Ryan Pusztai <rpus...@gmail.com> wrote:

..

Not sure if Peter cares? He is just offering a system to build and deploy new modules. Peter D. do you care enough about this?

Sure I do. LuaDist is almost 7 years old now and started as a project to bring Lua to all the platforms I work on and I am still at it.

Totally agree. I meant no offense, please forgive me. The work you have done it amazing. I just wondered if you wanted to be the person who selected the modules. From your current project (LuaDist), it accepts all modules :)

However I feel Steve D. should be the person who decides on the package selection and policies. Not only is he better qualified than me but also the author of penlight which should be the core module we use as an example to other developers on how to do things. I would also like to nominate you as the second person for this purpose.

Agreed Steve D. is a huge player in the Lua universe in my book.

 

However, I feel we can have multiple persons responsible for various parts of the projects. Eg. Steve D. would be responsible for module policies (what tools to use, how to structure them etc). Ryan for module evaluation and selection (what is in, what is out). I am willing to be the person responsible for the technical parts such as CI, tools and of course maintainer of the more complex builds that sometimes need to be done.

This is a great way to break down the roles. I think there is a bunch of work and it is best to separate it into manageable and meaningful part.

--

Regards,
Ryan

[Peter Drahoš]

On Thu, Mar 21, 2013 at 10:07 PM, Ryan Pusztai <rpus...@gmail.com> wrote:

On Thu, Mar 21, 2013 at 4:37 PM, Peter Drahoš <dra...@gmail.com> wrote:

On Thu, Mar 21, 2013 at 6:55 PM, Ryan Pusztai <rpus...@gmail.com> wrote:

..

Not sure if Peter cares? He is just offering a system to build and deploy new modules. Peter D. do you care enough about this?

Sure I do. LuaDist is almost 7 years old now and started as a project to bring Lua to all the platforms I work on and I am still at it.

Totally agree. I meant no offense, please forgive me. The work you have done it amazing. I just wondered if you wanted to be the person who selected the modules. From your current project (LuaDist), it accepts all modules :)

No apologies needed. I did not intentionally participate in the discussion because my module priorities are skewed and I would not bring anything to the table.

However I feel Steve D. should be the person who decides on the package selection and policies. Not only is he better qualified than me but also the author of penlight which should be the core module we use as an example to other developers on how to do things. I would also like to nominate you as the second person for this purpose.

Agreed Steve D. is a huge player in the Lua universe in my book.

 

However, I feel we can have multiple persons responsible for various parts of the projects. Eg. Steve D. would be responsible for module policies (what tools to use, how to structure them etc). Ryan for module evaluation and selection (what is in, what is out). I am willing to be the person responsible for the technical parts such as CI, tools and of course maintainer of the more complex builds that sometimes need to be done.

This is a great way to break down the roles. I think there is a bunch of work and it is best to separate it into manageable and meaningful part.

Ok. I think we reached a consensus. Its up to Steve D. and Ryan P. to decide on how to end this thread. I'm sure the roles will crystalize more once the project is going.

pd

[marbux]

On Thu, Mar 21, 2013 at 10:07 AM, Andrew Starks <andrew...@trms.com> wrote:
> I think it's best to nominate someone to pull the trigger on an
> approach, cut the discussion off and call it done. I don't see a
> passionate distance between the ideas floating around here and that

I agree and approve of your nominees.

Achieving an extremely small download, just to make a contrast to
> other experiences is on my mind, because I'd like to make a point of
> that in the web site's copy. The dream would be: An installation so
> small, they think they accidentally downloaded the shortcut to the
> distribution instead of the actual file.

An extremely small download, e.g., just Lua/standard libraries plus
Lua Dist properly configured for binaries only, would do far more than
just make a contrast. A huge proportion of this planet is still
extremely band-width-limited for those who cannot afford a satellite
connection, including much of the rural U.S. Even worse in large
swaths of, e.g., Africa. Consider the use case of rural recipients of
the One Laptop Per Child project's XO laptops who have only local P2P
wireless connectivity to work with betwixt times when someone has time
to make the trip to an internet connection and return. Check the map:
<http://one.laptop.org/map>.

Best regards,

Paul

[Peter Drahoš]

That is really not a problem with the current LuaDist and git access through lua-git. I did a proof of concept for the lua-l list [1]. It is a minimal LuaDist downloader that will happily download any binary modules you want, no dependencies. All it does is download batteries but you can install just modules you want editing the batch file [2] or using the bin/luadist CLI directly.

The downloader is around 700kb zipped. I could still make it smaller.

pd

[1] https://github.com/drahosp/LuaDist-installer

[2] https://github.com/drahosp/LuaDist-installer/blob/master/install.bat#L8 

[marbux]

On Thu, Mar 21, 2013 at 2:32 PM, Peter Drahoš <dra...@gmail.com> wrote:

> That is really not a problem with the current LuaDist and git access through
> lua-git. I did a proof of concept for the lua-l list [1]. It is a minimal
> LuaDist downloader that will happily download any binary modules you want,
> no dependencies. All it does is download batteries but you can install just
> modules you want editing the batch file [2] or using the bin/luadist CLI
> directly.
>
> The downloader is around 700kb zipped. I could still make it smaller.

700 KB is do-able even with a dial-up modem. Very impressive, Peter.
On making it smaller, would the absolute minimum be LuaDist, zlib, and
Lua binaries, plus a batch file for installation?

Best regards,

Paul

[Peter Drahoš]

I'm on 496KB after using UPX .. and that is unpacked. However we do not really need any downloader at all just a Git client which may be even smaller. The binaries are stored in the Git repositories (in a detached branch) and can be downloaded. The trick is to know what URLs and what tags to pull, for that the manifest can be used to generate a sequence of git commands which would basically do the same thing as the installer.

If the Git repositories are on GitHub then a simple browser download can be used and the downloaded archives need only to be extracted into a single directory. Eg. Zip of Lua 5.2 Binary [1], just unpack and use.

pd

[1] https://github.com/LuaDist/lua/archive/5.2.1-Windows-x86.zip

[Peter Drahoš]

I have been trying some things out since the last post and managed to make a single executable LuaDist.exe[1] using trial version of MoleBox[2] that contains UPX packed binary of LuaDist and its dependencies. 

The whole process is dead easy and can be used to pack LuaDist wx based applications. Maybe we could even make an installer using this approach. However I failed to find similar open source software that could be used instead of MoleBox. This approach also has the advantage of packing data alongside the application which was an issue with LuaBuild made by Steve D. 

pd

NOTE: On OSX LuaDist apps can be bundle as Application Bundles without any 3rd party software.

[1] https://github.com/drahosp/LuaDist-installer/tree/molebox

[2] http://www.molebox.com/

[marbux]

On Fri, Mar 22, 2013 at 8:25 AM, Peter Drahoš <dra...@gmail.com> wrote:

> I have been trying some things out since the last post and managed to make a
> single executable LuaDist.exe[1] using trial version of MoleBox[2] that
> contains UPX packed binary of LuaDist and its dependencies.
>
> The whole process is dead easy and can be used to pack LuaDist wx based
> applications. Maybe we could even make an installer using this approach.
> However I failed to find similar open source software that could be used
> instead of MoleBox. This approach also has the advantage of packing data
> alongside the application which was an issue with LuaBuild made by Steve D.
>
> pd
>
> NOTE: On OSX LuaDist apps can be bundle as Application Bundles without any
> 3rd party software.
>
> [1] https://github.com/drahosp/LuaDist-installer/tree/molebox
> [2] http://www.molebox.com/

Hi, Peter,

I can't get it to install on Win7. AVG insists that its a security
threat, then when I ignore that, I get a Windows message that it can't
access the specified device, path or file. When I try to view the
file's properties, nothing happens. So maybe a corrupt file?

Best regards,

Paul

[Peter Drahoš]

Well the antivirus behavior is typical for UPX packed executable. I tested it only on my Windows8 VM so this may be the typical "works for me" case as I do not know the implications of using MoleBox. I will investigate further and once the CI server is ready I will have a place to test the approach some more.

pd 

[marbux]

On Fri, Mar 22, 2013 at 10:43 AM, Peter Drahoš <dra...@gmail.com> wrote:
>
> Well the antivirus behavior is typical for UPX packed executable. I tested
> it only on my Windows8 VM so this may be the typical "works for me" case as
> I do not know the implications of using MoleBox. I will investigate further
> and once the CI server is ready I will have a place to test the approach
> some more.

Thanks, Peter. BTW, I truly admire the work you are doing.

Best regards,

Paul

[steve donovan]

On Fri, Mar 22, 2013 at 5:25 PM, Peter Drahoš <dra...@gmail.com> wrote:
> However I failed to find similar open source software that could be used
> instead of MoleBox. This approach also has the advantage of packing data
> alongside the application which was an issue with LuaBuild made by Steve D.

Yes, it's a limitation of srlua - the 'payload' is just a single Lua
file, which can of course be an archive representing a whole Lua
program using Jay's soar. I'm sure the basic tactic of srlua could be
extended to append a set of data files, rather as they're encoded in a
tar archive. Or just a straight uncompressed tar extractor on the
payload. io.open etc can be monkey-patched to look for things in the
archive.

As for self-extracting compressed executables, is it that much needed?
I believe compressed HTTP streams [1] can do the job more
transparently, although there are Problems. Paul M (marbux) points
out that there's a need to have a lightweight download for the
data-poor, but then I'd say that one larger download is more suitable,
precisely because Internet access is intermittent.

(Another generalization of srlua I want to work on is one that packs a
shared library, not an executable. This is useful for embedders, who
may (for example) want a Lua 5.2 DLL with embedded LuaFileSystem and
LuaSocket. That fits with luabuild's mission, and probably isn't so
appropriate for a general distribution.)

steve d.

[1] http://en.wikipedia.org/wiki/HTTP_compression

[Peter Drahoš]

LuaBuild has its purpose and I'm sure I can replicate it with LuaDist after some modification. In the meantime I have found Cameyo to be a great single executable packer that works with LuaDist directly and can even launch multiple executables inside of it. Free and easy to use, solves the issue of single executable distribution on Windows. My only issue with is is that it launches new terminal when the executable is used from the CLI.

pd

[1] http://www.cameyo.com/ 

[marbux]

Steve Donovan said:

> Paul M (marbux) points
> out that there's a need to have a lightweight download for the
> data-poor, but then I'd say that one larger download is more suitable,
> precisely because Internet access is intermittent.

Depends on whether the limitation is intermittent internet access or a
very slow connection. With a slow connection, a lightweight download
with the ability to pull down modules only as needed would be much
preferred. There are lots of folk in rural Oregon who are still stuck
with 56kb dial-up modems.

I'm sorry, I chose the wrong example to illustrate the issue I'd like
to see addressed.

Best regards,

Paul

[Thijs Schreijer]

> -----Original Message-----
> From: luafor...@googlegroups.com
> [mailto:luafor...@googlegroups.com] On Behalf Of marbux
> Sent: maandag 25 maart 2013 6:28
> To: luafor...@googlegroups.com
> Subject: Re: What packages shoudl be in the base install?
>
> Steve Donovan said:
>
> > Paul M (marbux) points
> > out that there's a need to have a lightweight download for the
> > data-poor, but then I'd say that one larger download is more suitable,
> > precisely because Internet access is intermittent.
>
> Depends on whether the limitation is intermittent internet access or a
> very slow connection. With a slow connection, a lightweight download with
> the ability to pull down modules only as needed would be much preferred.
> There are lots of folk in rural Oregon who are still stuck with 56kb dial-
> up modems.
>

I don't think the size should be part of the 'specs'. Don't get me wrong, I feel along with the folks in Oregon (or even as close to home as rural Germany, same thing there). But Lua code has been small all the way, some dependencies will not be small but alas. Even in Oregon 80/90% of users will run Windows, and a single windowsupdate is probably bigger than the entire Lua ecosystem envisioned here.
So yes it's good to be keen on the size, but from a priority perspective it should be somewhere at the bottom of the list, and then I'm convinced it will still be fine.

Thijs

[marbux]

On Mon, Mar 25, 2013 at 1:15 AM, Thijs Schreijer
<th...@thijsschreijer.nl> wrote:

> I don't think the size should be part of the 'specs'. Don't get me wrong, I feel along with the folks in Oregon (or even as close to home as rural Germany, same thing there). But Lua code has been small all the way, some dependencies will not be small but alas. Even in Oregon 80/90% of users will run Windows, and a single windowsupdate is probably bigger than the entire Lua ecosystem envisioned here.
> So yes it's good to be keen on the size, but from a priority perspective it should be somewhere at the bottom of the list, and then I'm convinced it will still be fine.

I'm not pushing for a downsizing of the basic package. I just think
there needs to be an alternative to downloading the entire L4W
package.

Perhaps that's better handled by Peter as a separate LuaDist install.
FWIW, size is also a big factor with developers who embed Lua. I know
that the first question I will get whenever I ask our lead developer
to integrate another module with embedded Lua, his very first question
is, "how much will it add to the package size?" I'm planning to ask
him to add LuaDist when it's ready for Lua 5.2. But I know it would be
a waste of time for both of us to ask him to add LuaDist *and*
batteries.

Not trying to be argumentative. But there are use cases for a small
installer that downloads and installs modules only when requested.

Best regards,

Paul

[steve donovan]

On Mon, Mar 25, 2013 at 10:34 AM, marbux <mar...@gmail.com> wrote:
> installer that downloads and installs modules only when requested.

I.e. LuaDist ;)

Seriously, a person with organizational skills and not much else could
take the batteries zip and trim it down to the minimum core - or just
use LuaDist to build it up, bit by bit. Peter reckons it's easy to
get something under a meg, without compression.

Having lots of available zips might be a maintainance problem, however.

Thijs points out that the modern desktop world is already cruel to
people with dialup, with Windows (or Linux) being anxious about being
up-to-date.

(As for smaller devices, it's perfectly possible to have a workable
little Lua distro for Android, based on AndroLua/LuaJava. But that is
another kettle of fish, as the English say. The code editing
possibilities get reduced, to say the least! There are some
interesting educational initiatives involving very widespread
deployment of tablets, e.g. in India)

steve d.

[Thijs Schreijer]

> -----Original Message-----
> From: luafor...@googlegroups.com
> [mailto:luafor...@googlegroups.com] On Behalf Of steve donovan
> Sent: maandag 25 maart 2013 9:44
> To: luafor...@googlegroups.com
> Subject: Re: What packages shoudl be in the base install?
>

I can agree with everything above, but in retrospect the core of my message was: focus! If you want it be to all things to all people the effort will fail.
In relation to my earlier message listing things that the project is and what it isn't, I think we could add that;
- it is intended to be an incremental installation (allowing easy adding/removing of packages)
- it is not intended to be a bare-minimum size installation, but it might be possible to customize it in that way

Having said that; could it be organized as some "orphaned" rockspecs? "orphaned" meaning that it would be a rockspec not related to a specific module, but only containing a list of dependencies, grouped under a single name. Eg. "kepler", "kepler_minimum", "kepler_full" (assuming kepler as the project name)

Thijs

[Peter Drahoš]

Sure, thats exactly what "batteries" package in LuaDist is. Just collection of dependencies, very similar to a rockspec[1]. All dependencies are maintained separately so creating multiple meta-packages is not an issue. The hard work lies in maintenance of the packages that need to be installed, their documentation, tests and library dependencies.

pd 

[1] https://github.com/LuaDist/batteries/blob/master/dist.info

[David Manura]

On Wed, Mar 20, 2013 at 2:40 PM, Ryan Pusztai <rpus...@gmail.com> wrote:

>>> - luacom  (not yet available as binary)
>>I can see the merit in including this, if it can be aligned with some hyper-useful tutorials. 

>>>I could see this be put in there is there are tests. I have tried to use this twice and was not successful at all.

On Wed, Mar 20, 2013 at 3:46 PM, Andrew Starks <andrew...@trms.com> wrote:

> I like the idea of a set of OS-specific libraries for each targeted platform,
> only to show special capabilities with those integrations.... LuaCOM, etc.

On Thu, Mar 21, 2013 at 4:44 AM, steve donovan <steve.j...@gmail.com> wrote:

> Especially for things which have no clear cross-platform equivalent, e.g. COM.

Whether and where it's included would depend on the selection criteria used, but here's a couple data points...  I'm not sure if LfW is using the latest source release, but it is maintained, regularly used in production/stable, and the only COM module available for Lua.  A lot of Windows and Office is accessible via COM.  The main difficulty with this module is that a lot of the COM examples one finds on the web are written in VB and need to be translated to Lua (e.g. including differences between ":" v.s. "." and other things).  The following example invokes the Windows text-to-speech engine (+1 for fun factor):

local luacom = require "luacom"

local sapi = luacom.CreateObject("sapi.spvoice")

sapi:speak("Hello from Lua.")

sapi:speak("<emph>Hello from Lua</emph>")

sapi:speak("<pitch middle='10'>Hello from Lua.</pitch>")

sapi:speak("<pitch middle='-10'>Hello from Lua.</pitch>")

sapi:speak("<rate absspeed='-10'>Hello from Lua.</rate>")

sapi:speak("<rate absspeed='10'>Hello from "..("Lua "):rep(10)..".</rate>")

Out-of-the-box bridges to yet other object models can bring in large ecosystems.  LfW already includes Alien, although LuaJIT FFI has been replacing that.  jnlua is potentially useful for scripting Java objects from a stock lua.exe, but I've only used it a little and so can't say much about it other than to provide the following test of scripting Swing GUI components:

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

local javavm = require "javavm"

javavm.create("-Djava.class.path=jnlua-0.9.4.jar")

local JFrame = java.require"javax.swing.JFrame"
local JButton = java.require"javax.swing.JButton"
local ActionListener = java.require"java.awt.event.ActionListener"
f = JFrame:new()
f:setSize(100,100)
local content = f:getContentPane()
local button = JButton:new("test")

local listen = ActionListener:new({ actionPerformed = function() end})

button:addActionListener(listen)
content:add(button)
f:setVisible(true)

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

[steve donovan]

On Fri, Mar 29, 2013 at 8:41 PM, David Manura <dm....@math2.org> wrote:

>Whether and where it's included would depend on the selection criteria used, but here's a couple data points...  I'm not sure if LfW is using the latest source release, but it is

> maintained,regularly used in production/stable, and the only COM module available for Lua.  A lot of Windows and Office is accessible via COM.

That's exactly what I feel - it's a small module that opens up a lot of Windows functionality.  MS has a tendency to jump onto new technologies, but there's always COM at the bottom, and it's the easiest way to access native scripting capabilities through Windows Scripting Host.
 

>  jnlua is potentially useful for scripting Java objects from a stock lua.exe,

That is interesting, because LuaJava did not allow embedding in a regular Lua executable in this way.  Lua Java interop is a lot of fun (and cross-platform) and Swing actually becomes almost pleasant with Lua.  In other words, it's a lightweight GUI toolkit alternative - lightweight in the sense that it would add less than 100Kb to the distro, but like all managed solutions, it's a bit slow before it's had its morning coffee.

I still have a soft spot for LuaInterface, but the bootstrapping bit needed to get it to work with stock Lua exe is hairy and I don't know if it can be done with mingw.  (I did update the branch that used native Lua for the MonoLuaInterface project)

steve d.

[David Manura]

On Thu, Mar 21, 2013 at 1:48 PM, Ryan Pusztai <rpus...@gmail.com> wrote:

Here is my list if I had to pick today.

...MD5...

I would indeed recommend basic digest capability in the things considered more or less core (however you define that) because the need commonly occurs in multiple different contexts.  It's even in lua-git [1].  This normally entails MD5 and/or SHA1, although MD5 is more frowned upon these days though not irrelevant.

But when I last looked [4], I wasn't so satisfied with these modules [2].  There's C implementations and Lua implementations (and perhaps ones that invoke the Linux command line utilities), some do only SHA1 and/or MD5 and/or other digests, some involve a large dependency (e.g. openssl or Apache APR) while others provide their own implementations, some do encryption/decryption too, some output hex and/or binary digests, and some don't support incremental calculation for very large strings [3].  There's nothing wrong with that, but there is a needless difference in interface and style between these modules that makes these not "interchangeable parts" (e.g. swapping a Lua implementation for a C one, swapping MD5 for SHA1, or adding it in a pipeline chained with other "filters" like base64 [4] with some consistent filter API).  Possible improvements to md5 in Kepler/LfW are in an open ticket [4].  So, this isn't just a question of what to preinstall but is also about the more interesting questions of interface standardization for digests API's.

[1] https://github.com/mkottman/lua-git/blob/master/src/sha.c

[2] http://lua-users.org/wiki/CryptographyStuff

[3] http://lua-users.org/lists/lua-l/2010-04/msg00613.html

[4] https://github.com/keplerproject/md5/pull/1 

[Thijs Schreijer]

> -----Original Message-----
> From: luafor...@googlegroups.com
> [mailto:luafor...@googlegroups.com] On Behalf Of David Manura
> Sent: zaterdag 30 maart 2013 2:25
> To: luafor...@googlegroups.com
> Subject: Re: What packages shoudl be in the base install?
>

Though very true, it comes back to the issue of 'collecting' only modules or 'updating/standardizing/maintaining' as well. If there are volunteers to pick this up to collect some of this stuff standardize and repackage, fine. But I really think it shouldn't be part of this effort, it should be separate.

Thijs