Re: 5.2 ?

[Andrew Wilson]

"On Aug 7, 2012 5:11 PM, "Luiz Henrique de Figueiredo" <l...@tecgraf.puc-rio.br> wrote:
>
> > We are proud to announce the next release of Lua for Windows (LfW).
>
> Is there going to be a LfW with Lua 5.2?
>

Yes once LuaDist supports it (and the batteries package). Is there a good list of modules that have been updated to Lua 5.2? I am not sure how many of the binary modules have been updated yet.

I released this because it has been sitting for a while and I think it will be the last release till the package is built off the LuaDist platform. 
--
Regards,
Ryan"

No schedule at the moment, just more waiting for more libs & LuaDist....  AGRW

On Mon, Oct 1, 2012 at 9:43 AM, david collier <mys...@cix.co.uk> wrote:

Sorry if this question has been answered before :-)

I see the installer package was recently updated.

But I also see it's only Lua 5.1

Is there any intention of re-doing LFW with 5..2?

If so, and schedule?

TVM

David

[David Collier]

thanks for the heads-up

D

> *From:* "Andrew Wilson" <agrw...@gmail.com>
> *To:* <luafor...@googlegroups.com>
> *CC:* <mys...@cix.co.uk>
> *Date:* Mon, 1 Oct 2012 10:12:42 -0400

> --
> *Included Files:*
> am2file:001-HTML_Message.html


------------------------------
Please reply to
mys...@cix.co.uk
and if it's urgent
dav...@dexdyne.com
dexdynegdc on yahoo instant messenger

[steve donovan]

On Fri, Nov 30, 2012 at 1:09 PM, Vasileios Anagnostopoulos
<fithi...@gmail.com> wrote:
> I see an interesting use case for Lua 5.2, gsl-shell. It is only mingw and
> it has no other ability to use LFW packages in its scripts. It can be the
> matlab for LUA.

gsl-shell is a very cool project. However, it's LuaJIT based, not 5.2,
which makes sense since the weakness of Matlab (and other solutions
like numpy) is that they're really rather slow at plain loops; LuaJIT
can do a plain loop as fast as C. Francesco has in fact moved a fair
amount of code into Lua and gained a speed-up!

We'd need to get a portable build of GSL going, which for LuaDist
would involve a CMake solution. A quick search doesn't reveal any
obvious links.

Personally, I think LuaJIT 2 is the best upgrade path for LfW,
especially if we build it with 5.2 compatibility.

steve d.

[Hisham]

On 18 March 2013 12:51, steve donovan <steve.j...@gmail.com> wrote:
> On Fri, Nov 30, 2012 at 1:09 PM, Vasileios Anagnostopoulos

> Personally, I think LuaJIT 2 is the best upgrade path for LfW,
> especially if we build it with 5.2 compatibility.

Considering that LfW is a probably the first contact many users have
with the language, documentation is a little bit of a problem though.
LJ2 is somewhere between Lua 5.1 and Lua 5.2, so AFAIK there is no
Reference Manual for the dialect of Lua it implements (only the 5.1
manual plus the list of extensions from the LuaJIT website). That may
or may not be a problem for newcomers, I don't know -- but the thought
crossed my mind.

-- Hisham
http://hisham.hm/

[steve donovan]

On Mon, Mar 18, 2013 at 8:01 PM, Hisham <h...@hisham.hm> wrote:
> Considering that LfW is a probably the first contact many users have
> with the language, documentation is a little bit of a problem though.

In our experience, documentation is _always_ the problem ;) The Lua
manual is very well written, but isn't a good place to start
(Roberto's book is much better at that.)

I do see your point about going for LuaJIT. Mike P is strict about
Lua 5.1 compatibility, he is just not so tolerant about deprecated
features like illegal escape characters and that old 'arg' idiom for
varargs. Casual scripters can ignore the FFI stuff (although the FFI
is a fantastic opportunity for _module_ writers).

I feel we have to have some 'newness'. Pragmatically, 5.2 is not
ready to go yet since there's a backlog of modules to be ported.
Offering the fastest scripting language distribution in the world is a
nice bit of newness ;)

steve d.

[steve donovan]

On Mon, Mar 18, 2013 at 10:47 PM, Andrew Starks <andrew...@trms.com> wrote:
> The number of libraries that someone actually needs, in order to get going
> and call the batteries complete, is actually not that great and all of the
> critical ones are supporting 5.2.

That is actually a good point. Lua for Windows was deliberately a
'kitchen sink' distribution because we did not have a mechanism to
easily download new packages. I'm impressed with how luadist can (out
of the box) can make this work very well; it can also be used to
upgrade existing packages, so one can have a rolling release. One
idea would be to take the existing list of packages and ask the
question: does a new user need this _now_? For instance, we have both
IUP and wxLua; personally I'd say, go with wxLua and IUP/CD/IM can be
easily installed (especially if there's a meta-package to pull them
and their example packages in).

> If I'm new to Lua, I want to start on the latest version. My first reaction
> is going to be, "Where is the 5.2 version?" If someone tells me that LuaJIT
> is the Ambassador of Lua on Windows, I'm going to start wondering about what
> that means...

Fair point. Mike P does not help matters with him calling 5.2 the
'Vista of Lua releases'. Unfortunately ABI compatibilty means you
have to pick one or the other.

Also, new users may be accustomed to the rapid pace of change in other
languages; Lua is not changing fast. I would think that providing the
_fastest dynamic language implementation_ is more exciting than
offering a point release that has a few novelties like _ENV (I'm not a
fan, it's just a more elegant form of the same environment magic which
confuses newbies no end[1])

It boils down to good documentation - doesn't everything? There are
incredible levels of ignorance out there about Lua, e.g.

http://www.reddit.com/r/programming/comments/1aiwn7/lua_a_guide_for_redis_users/

steve d.

[1] Personally, I work with the sane subset, no _ENV, no module(). I
would like to use user-overridable # operator, but LuaJIT can be
configured to support that. (Although Mike P himself does not think a
distribution like Debian should ship a version with 5.2 comat enabled;
not sure if that advice is applicable here).

[Peter Drahoš]

On Tue, Mar 19, 2013 at 8:31 AM, steve donovan <steve.j...@gmail.com> wrote:

On Mon, Mar 18, 2013 at 10:47 PM, Andrew Starks <andrew...@trms.com> wrote:
> The number of libraries that someone actually needs, in order to get going
> and call the batteries complete, is actually not that great and all of the
> critical ones are supporting 5.2.

That is actually a good point. Lua for Windows was deliberately a
'kitchen sink' distribution because we did not have a mechanism to
easily download new packages.  I'm impressed with how luadist can (out
of the box) can make this work very well; it can also be used to
upgrade existing packages, so one can have a rolling release.  One
idea would be to take the existing list of packages and ask the
question: does a new user need this _now_?  For instance, we have both
IUP and wxLua; personally I'd say, go with wxLua and IUP/CD/IM can be
easily installed (especially if there's a meta-package to pull them
and their example packages in).

I also think IUP is not as good as wxLua at the moment especially  considering its state on OSX. wxLua does ok on all platforms but is bigger. As Michal Kottman already mentioned there is always lqt to fall back to that binds almost all of Qt meaning that we get access to everything, not just UI. The lqt binding is generated and therefore can be used from 5.1 and 5.2 easily. Qt can be bundled in binary form to avoid building it but I prefer wx because we can build it from source.

> If I'm new to Lua, I want to start on the latest version. My first reaction
> is going to be, "Where is the 5.2 version?" If someone tells me that LuaJIT
> is the Ambassador of Lua on Windows, I'm going to start wondering about what
> that means...

Fair point.  Mike P does not help matters with him calling 5.2 the
'Vista of Lua releases'.  Unfortunately ABI compatibilty means you
have to pick one or the other.

Or both. We can make the GUI aware that if the user wants 5.2 then he has to install into separate directory because they are incompatible. LuaDist does not really care and will happily install 5.2 if you want it to. 

Also, new users may be accustomed to the rapid pace of change in other
languages; Lua is not changing fast.  I would think that providing the
_fastest dynamic language implementation_ is more exciting than
offering a point release that has a few novelties like _ENV (I'm not a
fan, it's just a more elegant form of the same environment magic which
confuses newbies no end[1])

It boils down to good documentation - doesn't everything?  There are
incredible levels of ignorance out there about Lua, e.g.

I share this view. Most new users I talk to and students trying to pick up Lua do not have a guided introduction to the Lua ecosystem. Most install lua on their linux and start hacking, quickly they find no modules (some lucky ones find LuaRocks but have no clue on how to use it). They have no idea what LuaJIT is and ALL of them are stunned that Lua 5.2 simply does not have any modules yet. Documentation centered in a distribution which points to all the key places we have (PIL, lua-users ...) is essential.

pd

[steve donovan]

On Tue, Mar 19, 2013 at 10:53 AM, Peter Drahoš <dra...@gmail.com> wrote:
> I also think IUP is not as good as wxLua at the moment especially
> considering its state on OSX. wxLua does ok on all platforms but is bigger.

That seems the price of coverage; these cross-platform kits are
separate universes in many ways, providing their own file system and
networking libraries.

Not a disaster to fly without IUP, because the proposed GUI installer
would make installing it practically a 'click-and-drool' experience.

I don't think the _size_ of the zip matters that much these days, but
the result has to form some kind of coherent whole.

> I share this view. Most new users I talk to and students trying to pick up
> Lua do not have a guided introduction to the Lua ecosystem.

Some time back Alexander and I started a 'Lua Cookbook' to provide a
simple introduction and a set of good useful examples

https://github.com/lua-cookbook/lua-cookbook/tree/master/src/book/en_US

Now I'd like to take this further: work with the assumption that
libraries like luafilesystem, luasocket, lpeg, etc are 'part of the
language' and introduce their use as well. I do get the itch to write
introductions sometimes (I even wrote an introductory C++ book once,
even got translated into Italian ;)) and it seems like a worthwhile
goal - a structured readme for the distribution.

steve d.

[Andrew Starks]

> --
> 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

I think both and fixing documentation is the best option.

This question is probably "gettable" somewhere, but when you speak to
the lack of documentation, is there a punch list somewhere?

I'd like to work on that and that would help.

What are the top 3 documentation needs, described in such a way that I
could start work on them?

Also, work loosens a bit at the end of this week. I'll put some love
into the CI server ASAP.

-Andrew Starks

"As we get older, and stop making sense"
-David Byrne

[marbux]

On Tue, Mar 19, 2013 at 2:46 AM, steve donovan
<steve.j...@gmail.com> wrote:

> Not a disaster to fly without IUP, because the proposed GUI installer
> would make installing it practically a 'click-and-drool' experience.

Is wxLua compatible with Lua 5.2? Last time I checked --- not too long
ago --- there was no mention of Lua 5.2 compatibility on the wxLua web
site.

> Some time back Alexander and I started a 'Lua Cookbook' to provide a
> simple introduction and a set of good useful examples
>
> https://github.com/lua-cookbook/lua-cookbook/tree/master/src/book/en_US

Looks good but needs: [i] licensing info; and [ii] a web page for the
finished product in HTML, for linking purposes (not everyone has a
Markdown extension installed in their browser).

Best regards,

Paul

[marbux]

On Tue, Mar 19, 2013 at 3:39 AM, Andrew Starks <andrew...@trms.com> wrote:

> What are the top 3 documentation needs, described in such a way that I
> could start work on them?

I'll nominate:

1. Agreement on a Web-based workspace for storing content in development.

2. Agreement on scope of the project. (I.e., is the project LuaDist or
the future "Smart Lua").

3. A laundry list of topics to be addressed, for purposes of
discussion/prioritization.

On the laundry list, I'll nominate as the top 3:

3.1. Installation (for end users).

3.2. Embedding (for developers).

3.3. Getting Started (for end users).

Best regards,

Paul

[marbux]

On Tue, Mar 19, 2013 at 11:38 AM, marbux <mar...@gmail.com> wrote:

>> https://github.com/lua-cookbook/lua-cookbook/tree/master/src/book/en_US
>
> Looks good but needs: [i] licensing info; and [ii] a web page for the
> finished product in HTML, for linking purposes (not everyone has a
> Markdown extension installed in their browser).

I spoke to soon on the licensing. It's located higher in the tree than
the linked page. Sorry for that noise.

Paul

[Andrew Wilson]

minimal is good, remove IUP, 

allowing user selection of packages is whole idea, so only ship with reasonable functional packages,

support 5.1 & LuaJit, add 5.2 support later

target user is someone exploring Lua usage rather than embedded market so docs required

my 2 cents. 

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.

[Peter Drahoš]

On 19 Mar, 2013, at 19:58 , marbux <mar...@gmail.com> wrote:

> On Tue, Mar 19, 2013 at 3:39 AM, Andrew Starks <andrew...@trms.com> wrote:
>
>> What are the top 3 documentation needs, described in such a way that I
>> could start work on them?
>
> I'll nominate:
>
> 1. Agreement on a Web-based workspace for storing content in development.
>
> 2. Agreement on scope of the project. (I.e., is the project LuaDist or
> the future "Smart Lua").
>
> 3. A laundry list of topics to be addressed, for purposes of
> discussion/prioritization.

Solid list, I would add FAQ to the list which would include language specific issues and distribution specific ones. Eg. why does "require" fail. How to install XY. How can I debug etc.

> On the laundry list, I'll nominate as the top 3:
>
> 3.1. Installation (for end users).
>
> 3.2. Embedding (for developers).
>
> 3.3. Getting Started (for end users).

I will probably add an "LuaDist architecture" entry which the aim to provide an overview of LuaDist and its features. Its been longer on my list of 2DOs.

pd

[Andrew Starks]

On Tue, Mar 19, 2013 at 2: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,
> support 5.1 & LuaJit, add 5.2 support later
> target user is someone exploring Lua usage rather than embedded market so
> docs required
>
> my 2 cents.

At the risk of sounding ranty via repeating my position...

I do want to add that, given Programming in Lua 5.2 just came out,
it's reasonable to assume that this would be the book at someone's
side as they introduced themselves to the language, using their
WIndows 7 box and a freshly downloaded copy of L4W.

Nobody would ask, "Why'd you support 5.2?" 5.1 feels like we didn't
finish our homework.

Okay. I've said enough. If a 5.1 variant is what consensus ends up
being, I'll go along with it.

-Andrew

[Andrew Starks]

This is awesome and just what I needed. I'm busy at work, but I'll try
to get the CI server booted and on the public inter-webs before the
week is over. I'll also pick one of these topics and work on it, too.

If there is no objection, I'll take a stab at a CSS style for
documentation and go over LuaDoc / LDoc to see what (if any) markdown
extensions are already in use. I like multimarkdown (with some
extensions), if that isn't already being used.


-Andrew

[Andrew Wilson]

agreed 5.2 needs to be supported but hopefully by allowing users to say upgrade and then realize they don't have enough libs supported... 

[Peter Drahoš]

This is a valid concern and believe me I'm all for moving to 5.2 as soon as possible. Sure we could walk all the modules in batteries and patch those to work with 5.2. But I think it would be too soon to do so. First we need to get out the things that we can as fast as possible .. this means Lua 5.1 based batteries (and LuaJIT 2.1 support). Once the CI is in place we can work through the incompatible packages and quickly check which work and which need attention using the CI.

What we can do now is to release minimal core based around Lua 5.2 (lfs, socket, luadist, penlight etc).

pd

[Andrew Wilson]

right, agreed 100%, 5.2 comes later

[Paul K]

Hi Paul,

> Is wxLua compatible with Lua 5.2? Last time I checked --- not too long
> ago --- there was no mention of Lua 5.2 compatibility on the wxLua web
> site.

yes; svn head of wxlua supports Lua 5.2, but I haven't tested that. It
was a recent addition (few weeks), so the documentation hasn't been
updated yet.

Paul

[marbux]

On Tue, Mar 19, 2013 at 12:31 PM, Andrew Starks <andrew...@trms.com> wrote:

> If there is no objection, I'll take a stab at a CSS style for
> documentation and go over LuaDoc / LDoc to see what (if any) markdown
> extensions are already in use. I like multimarkdown (with some
> extensions), if that isn't already being used.

I'd suggest also taking a look at the LDoc CSS. LDoc's generated HTML
doesn't use frames, but uses DIVs positioned with CSS, which means
that the HTML is far more easily editable than framed HTML. (E.g., for
end user annotation purposes.) I've been trying to undo PUC-Rio's
framed documentation for IUP so I can annotate it and it's a
nightmare.

Best regards,

Paul

[Ryan Pusztai]

On Tue, Mar 19, 2013 at 3:39 PM, Peter Drahoš <dra...@gmail.com> wrote:

100% Agree with 5.1 first and then 5.2 later.

--

Regards,
Ryan

 

[marbux]

On Tue, Mar 19, 2013 at 12:39 PM, Peter Drahoš <dra...@gmail.com> wrote:

> What we can do now is to release minimal core based around Lua 5.2 (lfs, socket, luadist, penlight etc).

One thing that's been missing from Batteries so far as I can tell is a
module/library for processing Unicode strings. I'd like to see that
added for both Lua 5.1 and Lua 5.2.

The lua-users wiki points to slnunicode as the solution.
<http://luaforge.net/projects/sln/>. But I've found zero documentation
for it, having checked in sources and on the Selene project web site.

I've been using this one for some time , implemented in pure Lua,
without problems on embedded Lua 5.2.
<http://www.curse.com/addons/wow/utf8>. It's particularly nice because
it includes the upper case <> lower case mappings in a separate file
and has functions for converting strings to upper case and lower case.

There's another pure Lua implementation at
<https://github.com/alexander-yakushev/awesompd/blob/master/utf8.lua>.
I haven't tested it but from the code it looks far less versatile.

Best regards,

Paul

[marbux]

On Tue, Mar 19, 2013 at 12:59 PM, Paul K <paulc...@gmail.com> wrote:

> yes; svn head of wxlua supports Lua 5.2, but I haven't tested that. It
> was a recent addition (few weeks), so the documentation hasn't been
> updated yet.

Nice. Thanks for that information; we're evaluating GUI toolkits for
use with the NoteCase Pro outliner, which embeds Lua 5.2.

Best regards,

Paul

[steve donovan]

On Tue, Mar 19, 2013 at 8:38 PM, marbux <mar...@gmail.com> wrote:
> [ii] a web page for the
> finished product in HTML, for linking purposes (not everyone has a
> Markdown extension installed in their browser).

That can be easily organized, and it would be cool if someone with a
good sense of design would give us a nice stylesheet. The LDoc
stylesheets are just the old LuaDoc stylesheets - at least they're
div-based! (On the subject of distributing documentation _just_ as
HTML: it's like writing an app in assembly when Lua would do just as
well. Very last century!)

I'm not hung-up on any particular Markdown processor - personally like
using lua-discount in LDoc since it's so fast.

Reading these files I can now see the weaknesses; they are too concise
in important places and the proofreading is erratic. I'd really like
to do a 'Gentle Introduction' to the language _and_ its ecosystem.
So, after covering the language and its builtin facilities, we move
onto using luafilesystem and luasocket. And (why not?) an
introduction to wxLua, which is sorely needed because otherwise you
have to either be able to read the C++ docs or read the excellent
wxPython docs and do some mental translation. Basically, enough
annotated examples to get the learning process going.

I also want to revisit the Unofficial Lua FAQ http://www.luafaq.org/
(all suggestions welcome)

This seems to be a thing we can all participate in, with someone
nominated as editor-in-chief. From previous experience, it's useful
that the editor is not the major writer!

steve d.

[steve donovan]

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.

[steve donovan]

On Wed, Mar 20, 2013 at 9:27 AM, steve donovan
<steve.j...@gmail.com> wrote:
> - winapi (ok, I'm biased ;))

Understand that I have a horse in this race ;)

LuaDoc is no longer maintained, and in fact its maintainers are quite
happy for LDoc to be its successor.

I quote from Tomas Guisasola Gorham:
" I've checked with Fabio and Luís Eduardo and both of them agree
with me. Now, you can be the new maintainer of LuaDoc. Since LDoc is
almost completely compatible with LuaDoc 3.0 it'll be a smooth upgrade
:-) Feel free to call it LuaDoc 4.0 "

Apart from all the markdown, type annotations, etc goodness it also
can be used as a command-line help generator. Can do standard modules
because LDoc ships with the LuaDoc files created for Mitchell's
Textadept editor:

$ ldoc -m coroutine
----
module: coroutine creating and controlling coroutines.

* create(f) - Creates a new coroutine, with body `f`.
* resume(co, ...) - Starts or continues the execution of coroutine `co`.
* running() - Returns the running coroutine.
* status(co) - Returns the status of coroutine `co`.
* wrap(f) - Creates a new coroutine, with body `f`.
* yield(...) - Suspends the execution of the calling coroutine.

otherwise it looks for the module and extracts the docs from the comments:

$ ldoc -m copas
----
module: copas Copas - Coroutine Oriented Portable Asynchronous Services

Offers a dispatcher and socket operations based on coroutines.

Usage:
copas.addserver(server, handler, timeout)
copas.addthread(thread, ...) Create a new coroutine thread and run
it with args
copas.loop(timeout) - listens infinetely
....
$ ldoc -m copas.addserver

function addserver(server, handler, timeout)
Adds a server/handler pair to Copas dispatcher
parameters:
server
handler
timeout

(this feature was suggested by Norman Clarke)

Now, some of our target audience may not be totally comfortable with
the command-line, so we still have the question of how to integrate
with the editor.... but LDoc has a flexible back-end and could cache
generated pages (like man does)

But it's my horse, so I can't make this decision!

steve d.

[marbux]

On Wed, Mar 20, 2013 at 12:27 AM, steve donovan
<steve.j...@gmail.com> wrote:
>
> And luasql - seems there's a MySQL backend - what about sqlite3 as
> well? That's a much more learner-friendly option.

Haven't tried it, but there's LuaSQLite3.
<http://lua.sqlite.org/index.cgi/index>. Documentation (which at first
glance seems thorough) says it's for Lua 5.1. Or is that what you were
referring to as "sqlite3"?

Best regards,

Paul

[steve donovan]

On Wed, Mar 20, 2013 at 11:32 AM, marbux <mar...@gmail.com> wrote:
> Haven't tried it, but there's LuaSQLite3.
> <http://lua.sqlite.org/index.cgi/index>.

I like that package, yes, but I was thinking about the LuaSQL backend
to be consistent.

Windows users might also like the ODBC backend, which I can confirm
works very nicely. (However, that can be an available-but-not-present
package)

[Andrew Starks]

>
> From previous experience, it's useful
> that the editor is not the major writer!
>
> steve

Oh man, do I need an editor.

I completely agree with this. I love the idea of some more narrative
documentation. Something that gives a little "why" and tells a little
bit of a story.

But again, I need an editor for the things that I contribute. :)

[marbux]

On Wed, Mar 20, 2013 at 4:34 AM, Andrew Starks <andrew...@trms.com> wrote:
>>
>> From previous experience, it's useful
>> that the editor is not the major writer!
>>
>> steve
>

> I completely agree with this. I love the idea of some more narrative
> documentation. Something that gives a little "why" and tells a little
> bit of a story.

I think that optimally, there would be two editors other than the
major writers: one that understands the tech and the other who
doesn't. The first to check the technical aspects of the writing and
the latter to ensure that the text is understandable by those who
don't have a good technical grasp of the subject matter.

But the problem with "village idiot" editors is that they tend to
acquire knowledge as they edit, so eventually they stop being idiots.
:-)

Best regards,

Paul

[Andrew Starks]

On Mar 20, 2013, at 6:50, marbux <mar...@gmail.com> wrote:

>
> But the problem with "village idiot" editors is that they tend to
> acquire knowledge as they edit, so eventually they stop being idiots.
> :-)
>
> Best regards,
>
> Paul
>

> --

What's needed is some sort of brick...

- Andrew

[marbux]

On Wed, Mar 20, 2013 at 5:18 AM, Andrew Starks <andrew...@trms.com> wrote:
> On Mar 20, 2013, at 6:50, marbux <mar...@gmail.com> wrote:
>
>>
>> But the problem with "village idiot" editors is that they tend to
>> acquire knowledge as they edit, so eventually they stop being idiots.
>> :-)

> What's needed is some sort of brick...

:-)

[Ryan Pusztai]

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?

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.

--

Regards,

Ryan

[1] http://wxformbuilder.org

[Andrew Starks]

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.

--

Regards,

Ryan

[1] http://wxformbuilder.org

Ryan, 

What are your thoughts on including a small collection of DB packages that are all adapted to the same interface, but have their native ones available if needed? They seem pretty close, already. 

Without adapting them, I think one is the number for the initial kit, personally. I do love Postgres though. 

-Andrew

[Ryan Pusztai]

Hi Andrew,

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

... 

Ryan, 

What are your thoughts on including a small collection of DB packages that are all adapted to the same interface, but have their native ones available if needed? They seem pretty close, already. 

Without adapting them, I think one is the number for the initial kit, personally. I do love Postgres though. 

That is definitely an idea I could live with but...

All,

I worry about what the goal of Lua for [Linux|Windows] should be in this case. At it's core I believe that it is just a distribution or collection of modules and applications that is easy to install and deploy. We are starting to move down a path of creating new software for this distro. Is this something we should embrace and become maintainers of new tweaks and updates? With a re-written set of documentation that the module authors did not write. I am asking not telling so please feel free to tell me the thoughts you have. I am also worried about the manpower needed to support the LfW/LfL additions that we are all talking about. This topic is much more project management related, but I wanted to bring it up early and am truly enjoying the new found energy for the project. Thanks everyone!

[Paul K]

Hi Steve,

As others have commented, I'm for the minimal approach, so for all the
libraries you listed, if something fits the bill, I don't think we
need an overlap. I'm also for inclusion of winapi as I personally use
it as you know.

Few other comments on the list:

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

I think we *may* consider including metalua as it's useful by itself
and there are other libraries that depends on it (luainspect comes to
mind), but since it's Lua only, it should be only one command away;
both are already packaged with ZBS, so the absence is not critical to
me.

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

I tend to agree, but I think we may need to consider that lpeg has a
completely different syntax from "normal" regexps and and such has a
different learning curve. When I'm looking for a simple tool that does
the job, it would be nice to have the library available (otherwise
I'll look for other tools I have, like Perl). There is nothing bad
about that, but it would be great to cover 90% of use cases with the
package we are discussing.

opengl library may be considered for the list. wxlua/wxwidgets
provides opengl canvas and there are libraries like luagl that can
work with that canvas.

Speaking about wxlua; wxlua can be compiled with vastly different
configurations. The library I use for ZBS has minimal configuration:
it doesn't include xml, xrc, opengl, or even richtext components. It's
clear that whatever wxlua configuration we can provide needs to
include some of these (maybe all?).

Paul.

> --
> You received this message because you are subscribed to a topic in the Google Groups "luaforwindows" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/luaforwindows/txJ4aTAN1EY/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to luaforwindow...@googlegroups.com.

[Andrew Starks]

To Paul's point on regex:

It's a great one and I think it is endemic of the challenges of
introducing people to Lua: "Where the #$*& is the Perl library?"
(there is a joke in there...)

So, do you make regex standard to make them feel at home, or do you
force them to use the built-in, almost regex and add LPeg, which does
WAY MORE than regex can? (Add re and they might feel more
comfortable)?

I think that documentation helps here. A tutorial titled, "Where the
(+a?) is regex?" (or whatever the right way to do that is) It would
explain Lua's built in facilities and LPeg and then walk through a
series of common problems, showing how you would do them in all three.

It seems that making the regex library available separately is better,
if only to guide people towards the Lua way, without being too
bothersome about it.

-Andrew

-- "A programmer had a problem, so he used a regex. Now he has two problems."

[Andrew Starks]

On Wed, Mar 20, 2013 at 10:59 AM, Ryan Pusztai <rpus...@gmail.com> wrote:
> I worry about what the goal of Lua for [Linux|Windows] should be in this
> case. At it's core I believe that it is just a distribution or collection of
> modules and applications that is easy to install and deploy. We are starting
> to move down a path of creating new software for this distro. Is this
> something we should embrace and become maintainers of new tweaks and
> updates? With a re-written set of documentation that the module authors did
> not write. I am asking not telling so please feel free to tell me the
> thoughts you have. I am also worried about the manpower needed to support
> the LfW/LfL additions that we are all talking about. This topic is much more
> project management related, but I wanted to bring it up early and am truly
> enjoying the new found energy for the project. Thanks everyone!
>

Ryan,

This is well said and an excellent point. Hmmm... I guess I started
from the "let's turn everyone's make file into CMake" reality and have
been assuming that for everything. There *should be* limits on that
sort of thing, as you're suggesting.

I guess the challenge is that Lua's culture is very open to different
ways, as is Lua. How do you make a nice, coherent and *accessible*
ecco system that feels like it clicks together and either A) do it
with the libraries that are here or B) augment key elements of the
libraries that are here in a maintainable way.

I guess I'm very much in the B camp, so long as we can start in the A
camp and migrate in small steps. Also, I don't want this to be an
"other", like AOL was to the Internet in the 90's.

Like all almost all open source, you get lots of really brilliant work
backed up by crappy documentation, left for dead projects, spotty
testing... When people are doing something for free and for fun, they
generally don't like to do the hard work. They like to invent new ways
to, for example, connect to a freakin' database or write classes! :)

So, perhaps that might be somewhat of a guide: Where we're doing the
hard work that should have been done but wasn't, go ahead. Where we're
*changing* something, stop and evaluate the goal and the side
effects....

I don't know. I'm just typing over here... Where are my ADHD meds?


-Andrew

[marbux]

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

> I worry about what the goal of Lua for [Linux|Windows] should be in this
> case. At it's core I believe that it is just a distribution or collection of
> modules and applications that is easy to install and deploy. We are starting
> to move down a path of creating new software for this distro. Is this
> something we should embrace and become maintainers of new tweaks and
> updates? With a re-written set of documentation that the module authors did
> not write. I am asking not telling so please feel free to tell me the
> thoughts you have. I am also worried about the manpower needed to support
> the LfW/LfL additions that we are all talking about.

You likely missed parts of the grander vision that thus far is
scattered across four different Lua-related mailing lists that I
subscribe to, this list, lua-l, and the lists for LuaDist and LuaRocks
. There may be more. :-)

I'll attempt a summary but ask that others provide corrections or fill
the major holes.

There is a move underway, dubbed "SmartLua" by some, to inject some
user-friendliness into the existing Lua chaos involving location,
maintenance, distribution, installation and removal of modules and
libraries. Sufficient consensus has been arrived at amongst those
willing to devote time and energy to the project to identify at least
the following key aspects:

-- LuaDist is embeddable but LuaRocks isn't there yet. LuaDist is also
multi-platform and standardizes building sources with Cmake across all
supported platforms in a compiler-independent manner.

-- LuaDist does not need to have git and Cmake installed on the client
side for distribution/installation of binaries.

-- Participating developers will use git to store their releases along
with rockspecs and LuaDist dist.info manifests, from which LuaDist
will be able to pull binaries, or pull sources and build binaries.
Hisham and Peter are discussing movement to a single manifest format
for both apps.

-- One company (forgot which) is committed to providing 'puters for
the VMs need for the build farm to produce binaries.

-- Installing LuaDist will be the starting point for end users and it
will acquire the ability to handle dependencies.

-- Steve is writing a wxWidgets GUI app for the user interface with LuaDist.

-- LuaDist will be able to install Lua Rocks. (I don't remember if it
already does.)

-- Because of the above changes and LFW integration with LuaDist, LFW
will no longer need to ship all of its binaries with a single
installer; users will be able to install modules at will. At the same
time, because it is the only major all-binary distribution of Lua
*and* batteries, it's the logical beginning focal point for
implementing all of the above. Work to spread the effort to other
platforms comes later.

-- Which brings us back to the present discussion of what binaries
will ship with LFW and which will need to be installed via LuaDist and
Steve's GUI. It will still be Lua for Windows with Batteries but some
batteries will not be included with the installer; they will need to
be installed separately. Hence the effort to identify which batteries
will ship with the installer.

I hope I have captured the essence of the grand collective vision and
have not made too many mistakes. Perhaps the above might provide a
beginning point to massage into a more polished project description
that people could link to in emails?

Best regards,

Paul

[Andrew Starks]

Holy crap was this needed! I learned a great deal from this, actually.
Thanks Paul! My reading comprehension skills may be lacking, but I
think adding something like:

-- To create a branded web site, which associates with and promotes
Lua, while not confusing the project with the core Lua team. This site
would serve as the "front door" to not only the project, but to a
collection of documentation and teaching materials, which are aimed to
help people understand Lua, generally, but also from the context of
LuaDist, the Repository and L4W. (VIsiting the names of at least the
Repository is part of "branding."

-Andrew

[Peter Drahoš]

On Wed, Mar 20, 2013 at 6:49 PM, marbux <mar...@gmail.com> wrote:

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

> I worry about what the goal of Lua for [Linux|Windows] should be in this
> case. At it's core I believe that it is just a distribution or collection of
> modules and applications that is easy to install and deploy. We are starting
> to move down a path of creating new software for this distro. Is this
> something we should embrace and become maintainers of new tweaks and
> updates? With a re-written set of documentation that the module authors did
> not write. I am asking not telling so please feel free to tell me the
> thoughts you have. I am also worried about the manpower needed to support
> the LfW/LfL additions that we are all talking about.

You likely missed parts of the grander vision that thus far is
scattered across four different Lua-related mailing lists that I
subscribe to, this list, lua-l, and the lists for LuaDist and LuaRocks
. There may be more. :-)

Welcome to the Lua ecosystem. Still the discussions were rather productive but may have been hard to follow for some people. In the future we should probably streamline the communication channels .. perhaps finally expand the idea of a separate lua-users list that is separate from the lua-l list and focuses on the Lua ecosystem instead.

I'll attempt a summary but ask that others provide corrections or fill
the major holes.

Thank you! 

There is a move underway, dubbed "SmartLua" by some, to inject some
user-friendliness into the existing Lua chaos involving location,
maintenance, distribution, installation and removal of modules and
libraries. Sufficient consensus has been arrived at amongst those
willing to devote time and energy to the project to identify at least
the following key aspects:

-- LuaDist is embeddable but LuaRocks isn't there yet. LuaDist is also
multi-platform and standardizes building sources with Cmake across all
supported platforms in a compiler-independent manner.

Correct. Also note that LuaRocks can install LuaDist packages with some modification. However LuaDist can only use rocks that rely on the "builtin" functionality .. other rocks are dead end.

 

-- LuaDist does not need to have git and Cmake installed on the client
side for distribution/installation of binaries.

Correct.

 

-- Participating developers will use git to store their releases along
with rockspecs and LuaDist dist.info manifests, from which LuaDist
will be able to pull binaries, or pull sources and build binaries.
Hisham and Peter are discussing movement to a single manifest format
for both apps.

This is very preliminary. This boils down to the difference in philosophy. LuaRocks is hands off, it works for me approach. LuaDist goes the hard way and maintains everything. 

-- One company (forgot which) is committed to providing 'puters for
the VMs need for the build farm to produce binaries.

Indeed, Andrew Starks prommissed to donate a mac mini server suitable to run LuaDist/LuaRocks CI processes in VMs. These could also be used to generate binaries and module manifest. Manifests have been agreed to provide the needed matadata about the stare of modules instantly without having to gather the information gtom git (which is slow).

 

-- Installing LuaDist will be the starting point for end users and it
will acquire the ability to handle dependencies.

Correct. It already does dependency handling automatically. It just needs to behave correctly in binary mode where the module ABI may change. Not an issue for lua 5.1 modules only. Solution for this issue is on the way.

 

-- Steve is writing a wxWidgets GUI app for the user interface with LuaDist.

Correct. Additionally he identified some ZeroBraneStudio debuging issues in the process. 

-- LuaDist will be able to install Lua Rocks. (I don't remember if it
already does.)

It already does, however the integration still needs some work.

 

 -- Because of the above changes and LFW integration with LuaDist, LFW
will no longer need to ship all of its binaries with a single
installer; users will be able to install modules at will. At the same
time, because it is the only major all-binary distribution of Lua
*and* batteries, it's the logical beginning focal point for
implementing all of the above. Work to spread the effort to other
platforms comes later.

Correct.

-- Which brings us back to the present discussion of what binaries
will ship with LFW and which will need to be installed via LuaDist and
Steve's GUI. It will still be Lua for Windows with Batteries but some
batteries will not be included with the installer; they will need to
be installed separately. Hence the effort to identify which batteries
will ship with the installer.

Correct. The current discussion will determine the "core" modules. All other modules (many more then in the current batteries) will be available for download through the GUI. Additionally the intellua project may suggest (or automatically install) modules that are not present. Eg. when the app is run through ZeroBraneStudio we can re-define require to check the availability of the module. If it is not available then the proposed wxGui can pop up and ask the user to install it.

 

I hope I have captured the essence of the grand collective vision and
have not made too many mistakes. Perhaps the above might provide a
beginning point to massage into a more polished project description
that people could link to in emails?

Excellent summary. I think we should keep a document somewhere that aggregates links to the related issues and projects.

pd

[Ryan Pusztai]

Thanks for your great explanation, but I still think my point is valid. I like what Andrew Stark said "Where we're doing the hard work that should have been done but wasn't, go ahead. Where we're *changing* something, stop and evaluate the goal and the side effects....".

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 "meaninful"  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 loose a bunch of time and functionality that I already have today.

I am just proposing that we have the "major daily use" modules be contained in the install and for the 10% other "stuff" it gets installed by LuaDist.

Maybe we can all look at the current list [1] and pick the modules we use every day. Thoughts? 

I think we should move further conversations to a new topic with a better title.

P.S. We should talk about file type support. I am using xml and json like a mad fool please don't remove support out of the box for them. :)

[marbux]

On Wed, Mar 20, 2013 at 11:28 AM, Peter Drahoš <dra...@gmail.com> wrote:

> I think we should keep a document somewhere that
> aggregates links to the related issues and projects.

I'm willing to start such a document but am a bit leery of a single
document approach. One doc becomes two becomes three, etc., and pretty
soon you've got an disorganized mess. Plus I foresee that the grand
vision has a lot of potential to become a project in itself with
subprojects and related projects, its own mailing list, issue tracker,
etc.

Would it make sense to set up a project somewhere that has all the
bells and whistles if needed? E.g., Sourceforge, etc. Other than basic
project setup, we could begin with a single wiki page and tap other
provided tools as needed. And if we never get past using the wiki, the
cost is the same.

By way of illustration, I went through a period of my life when I set
up another instance of Tikiwiki whenever anything even smelled like it
might turn into a project because the modules were all bundled
together and integrated. In the beginning, wiki-only but enabling
another module as needed usually took only a few minutes.

I'm not advocating Tikiwiki here, but there are a lot of advantages to
beginning in a software environment that has available at least most
of what might conceivably be needed later.

Best regards,

Paul

[Thijs Schreijer]

Github project? Using markdown files easy to update/integrate pull requests etc. similar to how SemVer[1] uses it

Thijs

[1] https://github.com/mojombo/semver

[Ryan Pusztai]

On Thu, Mar 21, 2013 at 11:57 AM, marbux <mar...@gmail.com> wrote:

On Wed, Mar 20, 2013 at 11:28 AM, Peter Drahoš <dra...@gmail.com> wrote:

> I think we should keep a document somewhere that
> aggregates links to the related issues and projects.

I'm willing to start such a document but am a bit leery of a single
document approach. One doc becomes two becomes three, etc., and pretty
soon you've got an disorganized mess. Plus I foresee that the grand
vision has a lot of potential to become a project in itself with
subprojects and related projects, its own mailing list, issue tracker,
etc.

Would it make sense to set up a project somewhere that has all the
bells and whistles if needed? E.g., Sourceforge, etc. Other than basic
project setup, we could begin with a single wiki page and tap other
provided tools as needed. And if we never get past using the wiki, the
cost is the same.

The Lua for Windows project is hosted on Google Code and it has a wiki.

Also I pretty much am in love with Git, so GitHub? 

--

Regards,
Ryan

[steve donovan]

On Thu, Mar 21, 2013 at 7:52 PM, Ryan Pusztai <rpus...@gmail.com> wrote:
> Also I pretty much am in love with Git, so GitHub?

Well, I'm a fan as well - I'm just enjoying having a real issue
tracker and all that pull request machinery that makes it so easy for
people to contribute to my projects. And gh-pages gives me somewhere
to host files statically.

Plus, Git works fine on Windows. As a bonus, I get a very pleasant
bash shell without all that Cygwin nonsense.

Recently started playing with their wiki pages and they're very
straightforward to use, just Markdown.

steve d.

[marbux]

Github works for me.

Best regards,

Paul

[Peter Drahoš]

Vote for GitHub also.

pd

[Andrew Wilson]

+1 GitHub

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

Vote for GitHub also.

pd

--
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.

[MC]

I don't think I've ever seen the two editors idea mentioned anywhere before, and I've been around the block a few times.  It's a fantastic one, in my opinion.  My problem with documentation for almost everything involving programming is that it always seems that the only people who even looked at the documentation as it was being created were involved in building the stuff from the ground up, which is probably because they were.  I think I hit numerous dead ends on every "how to" I ever encountered associated with Lua, and I've programmed extensively in Assember, Algol, C, you-name-it over the years.  I just don't remember all that stuff anymore, and I don't want to have to learn it all again.  That's why I'm so excited to to see so much action here now.  I don't have time (and as the COO of a software dev company, it's not my job anymore) to re-learn the excruciatingly technical stuff I've forgotten just so I can go knock something out quickly because I don't want to bother someone else with it, or because I just enjoy doing it once in a while.  So I'm a "village idiot" in the Lua camp by necessity, if you will.  I think this project, done with the goals and approaches I'm seeing here, really has the potential to make a Lua a lot more widely known and used.

Mark

[steve donovan]

On Sat, Mar 23, 2013 at 4:02 PM, MC <macha...@gmail.com> wrote:
> I don't think I've ever seen the two editors idea mentioned anywhere before,
> and I've been around the block a few times. It's a fantastic one, in my
> opinion.

When I wrote a book with Que, I was completely outnumbered by editors
;) The system worked well.

> ... it always seems that the only people who even looked at

> the documentation as it was being created were involved in building the
> stuff from the ground up

Yeah, and that's in the case where documentation was actually some
kind of priority! Some reckon that just having a few @param
annotations and they are sorted (the JavaDoc curse).

Others honestly think that a few unit tests will magically explain everything.

If I was asked to staff a library project, I'd choose a real smart
propeller-head for the library internals, algorithms, etc, a person
that likes communication to design the API, and an even more social
person who is not a domain expert to do the documentation.

> you will. I think this project, done with the goals and approaches I'm
> seeing here, really has the potential to make a Lua a lot more widely known
> and used.

That's totally the idea. How do you feel about being one of the editors? ;)

steve d.

[Peter Drahoš]

If we get less people asking why we index from 1 and that global by default is the source of all evil then is all worth the effort. And dont get me started on the recent nil discussion on the lua-l dist. Lua is just plainly misunderstood language, that needs to change. No better way to do that than through examples and education.

pd

 

[MC]

On Saturday, March 23, 2013 10:42:53 AM UTC-4, SteveD wrote:

When I wrote a book with Que, I was completely outnumbered by editors
;) The system worked well.

I can see the humor (and the usefulness) in that - we all tend to get caught up in stuff we're spending a lot of time on, so much so that all the little stuff gets thrashed to death, while the big stuff has a way of slipping past us while our heads are down...

 

If I was asked to staff a library project, I'd choose a real smart
propeller-head for the library internals, algorithms, etc, a person
that likes communication to design the API, and an even more social
person who is not a domain expert to do the documentation.

I have the folks who answer the support lines for our software do both the QA testing and the documentation.  Net results:

It takes more support staff. 

You have to pay them more, but you don't have the turnover rate. 

They know the product because they QA'ed it. 

They're pretty social (if they like the support role and are willing to stay in it), so they tend to write more user-friendly documentation than average (if a bit verbose, but that's kinda my style anyway, in case you couldn't tell).

They also know that the better job they do with the documentation, the more time they have to play online games, because the phones don't ring as much.  :)
 

> you will.  I think this project, done with the goals and approaches I'm
> seeing here, really has the potential to make a Lua a lot more widely known
> and used.

That's totally the idea. How do you feel about being one of the editors? ;)

I'm probably imminently qualified to be a "village idiot" one, by my own admission, so yes, I'd be remiss to not volunteer, if called upon to serve.  :)

Mark

[MC]

On Monday, March 18, 2013 2:45:58 PM UTC-4, Paul K wrote:

The biggest (noticeable) difference for newcomers that comes to my mind is a different behavior during debugging.

 

Lua 5.1 only triggers debug.hook on a particular line if the control left that line and then returned to it. But LuaJIT calls debug.hook as many times as you have expressions/statements there.

 

So if you have "print(1) print(2) print(3)", Lua 5.1 will "step" only once, but LuaJIT will do it three times. One may argue that the latter is the more correct way to handle this, but I've seen people being confused by the cursor still staying on the same line during debugging.

 

FWIW, ZBS can use LuaJIT if one replaces lua51.dll with the LuaJIT one: http://studio.zerobrane.com/doc-luajit-debugging.html

 

Paul.

I'm going to have to try ZBS.  I know this is a bit of a contradiction to my "village idiot" status, but my editor of preference has been Vim for a very long time now, though I spend more time than I'd like in Visual Studio (but always with the excellent ViEmu add-on in place so I can still use my hard-wired keystrokes - I even use FireFox with Vimperator for my browser, for the same reason).  So, no, I'm not normal, but that's why I haven't tried it - the first time I saw mention of it, I checked to see if it had Vim bindings and couldn't find that it did, so I didn't look any further.  I will say, as an aside, though, that I've found that a programmer who defaults to a debugger, when a simple, well-placed, print statement (or log file entry) will do, wastes a lot of time.

Mark

[Mark Chalkley]

On Sat, Mar 23, 2013 at 11:07 AM, Peter Drahoš <dra...@gmail.com> wrote:

If we get less people asking why we index from 1 and that global by default is the source of all evil then is all worth the effort. And dont get me started on the recent nil discussion on the lua-l dist. Lua is just plainly misunderstood language, that needs to change. No better way to do that than through examples and education.

pd

Amen x 4, once for each sentence.

Mark

[Andrew Starks]

I'd be in the camp that heavily promoting Lua-capable IDEs is always a
great idea.

Including it in batteries is going to mean quite a bit of cruft for a
big segment of people. Specifically: Those who say, "I use (Perl,
Ruby, JS) and I like (TextMate, Emacs, Sublime), I'll give this Lua
thing a shot..."

They'd be much more likely to download the syntax highlighter for
their editor, before they're going to fumble through learning a new
one.

.02 from someone who hasn't gotten around to trying a real debugger...

-Andrew

[Paul K]

Hi Mark,

> I'm going to have to try ZBS. I know this is a bit of a contradiction to my

...

> will say, as an aside, though, that I've found that a programmer who
> defaults to a debugger, when a simple, well-placed, print statement (or log
> file entry) will do, wastes a lot of time.

I'm the same way. I'm using prints extensively when debugging the
debugger itself or parts of ZBS, but I also debug ZBS in ZBS (just
need to turn singleinstance check off), which is helpful in some
cases.

Some of the games engines that ZBS works with "eat" print statements
(they go to some local log you need to find or to a device log) and
the debugger provides a way to redirect those "print"s to the IDE, so
you can actually debug using "print" if you want. It's only setup by
default for some engines (not the default Lua one), but it's there if
someone needs it.

Give it a try and let me know if it works for you...

Paul.

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "luaforwindows" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/luaforwindows/txJ4aTAN1EY/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to

[steve donovan]

On Sat, Mar 23, 2013 at 5:45 PM, Andrew Starks <andrew...@trms.com> wrote:
> Including it in batteries is going to mean quite a bit of cruft for a
> big segment of people. Specifically: Those who say, "I use (Perl,
> Ruby, JS) and I like (TextMate, Emacs, Sublime), I'll give this Lua
> thing a shot..."

Lua _editor_ support is pretty good: http://lua-users.org/wiki/LuaEditorSupport

As a kindness, can include plugins for the old dinosaurs like vi and emacs.

ZBS isn't very big; what's big is wxLua, and that's a fully paying customer ;)

It is probably a cognitive-style thing, but some people are
_enormously_ more productive with a debugger. I find it makes me
actually _read_ code. Although, print() is so often our friend.

[Andrew Starks]

On Sat, Mar 23, 2013 at 10:59 AM, steve donovan
<steve.j...@gmail.com> wrote:
> On Sat, Mar 23, 2013 at 5:45 PM, Andrew Starks <andrew...@trms.com> wrote:
>> Including it in batteries is going to mean quite a bit of cruft for a
>> big segment of people. Specifically: Those who say, "I use (Perl,
>> Ruby, JS) and I like (TextMate, Emacs, Sublime), I'll give this Lua
>> thing a shot..."
>
> Lua _editor_ support is pretty good: http://lua-users.org/wiki/LuaEditorSupport
>
> As a kindness, can include plugins for the old dinosaurs like vi and emacs.
>
> ZBS isn't very big; what's big is wxLua, and that's a fully paying customer ;)

...and including it is a nice example of Lua using wxlua. I think
having it in seems like a decent decision, especially if its pointed
out that those that might use something else can poke around it, as an
example.

-Andrew

[steve donovan]

On Sat, Mar 23, 2013 at 6:01 PM, Andrew Starks <andrew...@trms.com> wrote:
> ...and including it is a nice example of Lua using wxlua. I think
> having it in seems like a decent decision, especially if its pointed
> out that those that might use something else can poke around it, as an
> example.

Absolutely, great example of a project eating its own dogfood. There
are actually a number of pure-or-mostly-Lua editors, including the
great retro TextAdept with a 2000 line C core. I remain a ScITE fan,
which is Lua-scriptable but maintaining the debugger extension was a
pain and involved mucking around with too much C++. Reuben Thomas,
the maintainer of GNU Zile (the stripped-down vs of Emacs) has a
branch completely rewritten in Lua.