Name Suggestions

[Andrew Starks]

I threw these out to a couple of you guys, but since then my anxiety
about receiving slings and arrows has dropped. So, I'll share this
with everyone:

I hear consensus a web site that acts as a front door to a collection
of projects that are aimed at people looking for more than the C
source code. The projects would include:

LuaDist with the Repository
What is now Lua4Windows, but I believe should be the basis for a Mac
install, as well (if not also Linux).
LuaRocks (maybe not it's HOME, but LuaRocks should at least be a first
class citizen)

[One could imagine that the "batteries" project is the only download,
providing the power of LuaDist and LuaRocks as part of the payload.
So, if you go this route, you're gonna install some batteries, no
matter what. That's not a bad option...]

It would include crisp context on why Lua should exist, what The Lua
Way is, and ways to get started. It should admit that Lua's core is
embed-ability and that the content on the site is meant to help
everyone, that isn't the site's *primary* focus.

The site could have its own name, or it could be named after the distributable.

With that introduction, here are some things I've been working on:

For the distributable and web site (would work for both):

Lithium (Taken by a software company. Nuts.)

Lithium Air:

LithiumAir
__.LithiumAir
_Li Air (too close to Liar)
Lithium[Air] (probably my vote)

http://en.wikipedia.org/wiki/Lithium_air_battery
LithiumAir is an emerging technology that has extremely high energy
density. Seems somewhat cool...

Embracing the theme of batteries, the visual theme of the site could
follow it. For example, you start a
tutorial and as you page through it, the battery meter grows.

Other icons that play on meanings: "Recharge batteries", "adding
batteries","dead batteries", etc.

Some slogan treatments:

LithiumAir
The simplest way to get started with Lua.

__LithiumAir
Start awesome with Lua.

Lithium[Air]
Start some awesome with Lua.

------------------
Option 2:

For a web site only (does not work for product):

The 100 or Room 100 (.org taken by an awesome looking site)

The idea is that it's where you start. It's also a play on "The Loo",
which is rumored to have origins in the fact that the bathroom was
traditionally Room 100 and 100 looks like l00. I never miss a chance
for a potty joke.

Other variations:

Lua100, LuaLOO, Lua[100], The[100], etc.

I can't wait to hear other ideas.

[On keeping Lua4Windows: I'm in the camp that this idea should be
spread to every desktop and because of that, strongly favor a change.
If that turns out not to be the direction, I'd favor keeping it
Lua4Windows or shortening it to L4W]

-Andrew

[Andrew Wilson]

Simple to leverage Lua for naming ... since we need separate install kits for each OS anyway.

L4W - Lua for Windows 

L4M - Lua for Mac

L4L  - Lua for Linux

L4D - Lua for Distribution could be Web site name...

Not particularly inspirational or fun, but silly or funny docs could give more humorous feel.

TLW - The Lua Way 

TLD - The Lua Distribution

AGRW

-Andrew

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

I Like

Three Letter Distribution

TLD

:)

-Andrew

[Roland Yonaba]

For what it's worth, I like that. Very much.

Andrew Wilson <agrw...@gmail.com> a écrit :

[marbux]

The Lua Way (TLD) works for me too.

Best regards,

Paul

[steve donovan]

On Thu, Mar 21, 2013 at 9:19 PM, Andrew Wilson <agrw...@gmail.com> wrote:
> L4W - Lua for Windows
> L4M - Lua for Mac
> L4L - Lua for Linux

I've always liked that, because it extends the existing 'brand'.
(Once you have a book called 'Dummies Guide to X' then it's natural
that your next book is 'Dummies Guide to Y' ;))

> L4D - Lua for Distribution could be Web site name...

OK, but really highlighting that Peter's LuaDist is the engine behind
the distro. He (after all) has done the hard work of making sure the
whole thing builds everywhere.

I like Andrew S's idea of a overall website with a definite theme.
(Not my strong point)

[Andrew Starks]

Hey all,

My vote is for the site and download to be called: Lithium[Air]

Following the lead established, I'll skip the narrative on why... I've
gone over my limit on narrative emails. :)

I will ask if making a mock up of how the website branding world work
would be pushy, at this point?

I'll admit (shamefully) that most of my 15 years at my work has been
in product and channel marketing. I'd be happy to share some of the
math behind how names work and why some approaches work and some
don't. If someone else has that experience, I'd love to hear it, as
well.

-Andrew

[steve donovan]

On Fri, Mar 22, 2013 at 4:49 PM, Andrew Starks <andrew...@trms.com> wrote:
> My vote is for the site and download to be called: Lithium[Air]

Nice play on the 'batteries' idea, but maybe a little too playful? If
we have to explain the joke, then it's (by definition) not funny.

I know 'Lua for Windows' [1] is plain and simple, but it's a known
brand. We actually have users!

Of course, that doesn't stop some nice design & logos being useful and
needed (Peter is also looking for a logo)

steve d.

[1] gsub('Windows','OSX') etc Still don't _quite_ know how to resolve
this one....

[Peter Drahoš]

On Fri, Mar 22, 2013 at 4:33 PM, steve donovan <steve.j...@gmail.com> wrote:

On Fri, Mar 22, 2013 at 4:49 PM, Andrew Starks <andrew...@trms.com> wrote:
> My vote is for the site and download to be called: Lithium[Air]

Nice play on the 'batteries' idea, but maybe a little too playful?  If
we have to explain the joke, then it's (by definition) not funny.

I know 'Lua for Windows' [1] is plain and simple, but it's a known
brand.  We actually have users!

Of course, that doesn't stop some nice design & logos being useful and
needed (Peter is also looking for a logo)

steve d.

Well, LuaDist may become something entirely universal and not tied to Lua eventually. For now its just a tool so its logo and eventual name-change not an issue in this context. I do like some of the suggestions Andrew proposed but I am probably the last person to look for name ideas. Please think of the LuaDist project as a useful tool and I do not necessarily want the current "batteries" effort to be bound to it or its name.

pd

[Andrew Starks]

Thanks, Steve. I can see your point of view. I've experienced anxiety
surrounding names that claim to be more than or something different
than what it is they actually do. This is especially true amongst
engineers that have to work "literally".

To be very brief: Lithium[Air] doesn't depend on "batteries", but on
the association with energy. This is contrasted with "Air", which has
an association with "life", "spirit" and also a lack of weight. The
important part is the reaction that a detached observer would have,
seeing it for the first time, not so much a play on words.

Lua4Windows would need to have "brand value", in order to be an asset.
Do people, generally, know what "Lua4Windows" is, outside of those
that know Lua? If so, and if that reputation is a good one, then there
is an asset.

The implied association with "Lua" the language is a bit of an
obstacle. There are... 30 "Lua*" projects? If someone says, "You
should download Lua4Windows" and I go home, the likelihood that I'll
remember "Lua" is 100%. That I will treverse my memory tree and land
on "Lua4Windows" is much lower than if the name did not include "Lua"
in it. Much *higher* for an "L" word, however.

okay. I'm sorry. I sell too much.

-Andrew

[marbux]

Hi, all,

Over the last 36 hours, I've acquired some doubts about what it is we
are naming. For example, are we naming:

-- a bundle of Lua and modules?

-- a bundle of modules for Lua?

-- a portion of the Lua ecosystem that will be distributed via LuaDist?

-- something different?

If the latter, how does it differ?

Best regards,

Paul

[Andrew Wilson]

Yes it's not clear, but I think it is the following.. Steve/Ryan/Peter correct me if I'm wrong...

It's basically a cross platform replacement of Lua For Windows leveraging all the LuaDist work.

Lua for Windows is a stand alone installer including Lua capable Editor/Debugger and a series of pre-build lua modules (binary & lua source), along with accompanying tutorial and reference documentation.

Other additional improvements are 

- a Web site to host this content & enable a community

- more/better tutorial docs

- a wxLua based utility to allow users to select modules to add/remove from existing installation

-?

If this isn't what were naming I'm lost. But I think I know where I am...

Cheers

AGRW

[Peter Drahoš]

On Fri, Mar 22, 2013 at 6:54 PM, Andrew Wilson <agrw...@gmail.com> wrote:

Yes it's not clear, but I think it is the following.. Steve/Ryan/Peter correct me if I'm wrong...

It's basically a cross platform replacement of Lua For Windows leveraging all the LuaDist work.

Lua for Windows is a stand alone installer including Lua capable Editor/Debugger and a series of pre-build lua modules (binary & lua source), along with accompanying tutorial and reference documentation.

Other additional improvements are 

- a Web site to host this content & enable a community

- more/better tutorial docs

- a wxLua based utility to allow users to select modules to add/remove from existing installation

-?

If this isn't what were naming I'm lost. But I think I know where I am...

Good summary, some of the side issues we have agreed to at least partially address in the process is the bundling of documentation of modules and their evaluation using an automated CI process. So basically it is Lua4Windows replacement + dynamic installation of MAINTAINED modules. The aim is to produce a consistent portable Lua distribution that hopefully works well for most intentions (development, distribution, embedding, teaching etc)

pd

[Ryan Pusztai]

Hi,

On Fri, Mar 22, 2013 at 2:50 AM, steve donovan <steve.j...@gmail.com> wrote:

On Thu, Mar 21, 2013 at 9:19 PM, Andrew Wilson <agrw...@gmail.com> wrote:
> L4W - Lua for Windows
> L4M - Lua for Mac
> L4L  - Lua for Linux

I've always liked that, because it extends the existing 'brand'.
(Once you have a book called 'Dummies Guide to X' then it's natural
that your next book is 'Dummies Guide to Y' ;))

I am leaning towards this as well.

 

> L4D - Lua for Distribution could be Web site name...

OK, but really highlighting that Peter's LuaDist is the engine behind
the distro.  He (after all) has done the hard work of making sure the
whole thing builds everywhere.

I could see this as the name, but then how will a user know if they downloaded it for Linux, Mac or Windows. I would assume that the platform would then be tacked on to the filename. I know that filenames are not the same as project names. These are just things I asked myself. Thoughts?

I like Andrew S's idea of a overall website with a definite theme.
(Not my strong point)

 

I agree. Andrew S. vision is what would make this be world class. I really like his website ideas 

--

Regards,

Ryan

[Andrew Starks]

On Fri, Mar 22, 2013 at 1:12 PM, Peter Drahoš <dra...@gmail.com> wrote:

>
>
> Good summary, some of the side issues we have agreed to at least partially
> address in the process is the bundling of documentation of modules and their
> evaluation using an automated CI process. So basically it is Lua4Windows
> replacement + dynamic installation of MAINTAINED modules. The aim is to
> produce a consistent portable Lua distribution that hopefully works well for
> most intentions (development, distribution, embedding, teaching etc)
>
> pd

BING!

-Andrew

[Ryan Pusztai]

Agree 100%

--

Regards,
Ryan 

[marbux]

On Fri, Mar 22, 2013 at 10:54 AM, Andrew Wilson <agrw...@gmail.com> wrote:
> Yes it's not clear, but I think it is the following.. Steve/Ryan/Peter
> correct me if I'm wrong...
>
> It's basically a cross platform replacement of Lua For Windows leveraging
> all the LuaDist work.
>
> Lua for Windows is a stand alone installer including Lua capable
> Editor/Debugger and a series of pre-build lua modules (binary & lua source),
> along with accompanying tutorial and reference documentation.
>
> Other additional improvements are
> - a Web site to host this content & enable a community
> - more/better tutorial docs
> - a wxLua based utility to allow users to select modules to add/remove from
> existing installation
> -?
>
> If this isn't what were naming I'm lost. But I think I know where I am...

That's close to what has been my vision. But I've begun to wonder if
we are defining the project too narrowly in the naming effort by not
encompassing the embedded Lua scenario. The LuaDist-centric vision I
see emerging seems predestined to draw closer together command line
Lua users (Lua ecosystem-oriented) and embedded Lua users (particular
app-centric).

That is to say, it's not much like the old LFW, dependent on
concurrent installation of Lua and a huge number of batteries; it can
be something as small to download and install as LuaDist without
batteries or Lua that presents a menu and asks, "May I get you
something to drink while's your deciding what to order?"

Maybe something more like a portal to the Lua ecosystem? And is that a
potential name: Lua EcoSystem?

Best regards,

Paul

[Andrew Starks]

On Fri, Mar 22, 2013 at 1:32 PM, marbux <mar...@gmail.com> wrote:
> That's close to what has been my vision. But I've begun to wonder if
> we are defining the project too narrowly in the naming effort by not
> encompassing the embedded Lua scenario. The LuaDist-centric vision I
> see emerging seems predestined to draw closer together command line
> Lua users (Lua ecosystem-oriented) and embedded Lua users (particular
> app-centric).

That could be true, and you'd know more than I would.

I imagine that if I'm embedding lua into my application, I'm rolling
most stuff in by hand. If I'm playing around with doing that, I may
want things set up for me, maybe using this tool, etc.

While it's true that this project will snag some people from the
embedded world, I'm operating under the belief that they are presently
being well served by Lua's core approach and that messing with that
messes with them. So, this project has just enough isolation built
into it, so that it may focus on users that Lua's core approach does
not serve well. The goal being to narrow the use cases and make the
effort more clear.

I'm not sure if that runs afoul of what you're saying, or not...

-Andrew

[Andrew Wilson]

That's a good description too, but I think of full vs. minimal batteries as more of a selection mechanism in the wxLua module to add/remove modules. 

A big problem in doing original Lua for Windows was not trying not to do everything, focusing on what can be done now and letting it evolve to something more I think is the best way to ensure future utility and growth.

Peter's summary says it for me...

"Lua4Windows replacement + dynamic installation of MAINTAINED modules. The aim is to  produce a consistent portable Lua distribution that hopefully works well for most intentions (development, distribution, embedding, teaching etc)" 

I'm going to spend sometime this weekend looking at all the parts we've got and see what I can contribute.

In my opinion we need to start putting all of these parts together,  think about what you do best and volunteer to do that bit.  

With LuaForWindows, it took quite a few releases until one was good enough for release.

Cheers 

AGRW

Best regards,

Paul

[marbux]

On Fri, Mar 22, 2013 at 11:57 AM, Andrew Starks <andrew...@trms.com> wrote:

> I'm not sure if that runs afoul of what you're saying, or not...

I don't think so. I do know that we've been absolutely stalled on
publishing scripts dependent on C modules for Lua other than those
that are embedded with NoteCase Pro because of the lack of binaries
for all supported platforms and the problems that Joe Sixpack might
have downloading and installing them.

We did finish a plugin distribution system recently roughly modeled on
apt/Synaptic and it's working very well. I've done some looking into
how we might use it to distribute and install Lua modules as well, but
kept running head-first into the barrier that we simply don't have the
resources to compile and maintain a good selection of Lua module
binaries for all platforms.

So from that perspective, it looks a lot better to help this effort
and aim to embed LuaDist than to focus on the do-it-all-ourselves
options. I'd guess that a lot of people who embed Lua in
multi-platform apps for users to write extensions are in a similar
position but are not yet aware that this effort can open giant new
opportunities for them and their users.

Also from that viewpoint, the really exciting parts of this project
are LuaDist and its on-demand distribution/installation of module
binaries and dependencies for multiple platforms, not delivery of a
fairly comprehensive development environment that's largely focused on
a Lua CLI. Maybe another way of saying that is that the use case of
most interest to me is extending existing apps using the combination
of Lua, modules available via LuaDist, and the existing apps' APIs.

Best regards,

Paul

[marbux]

On Fri, Mar 22, 2013 at 12:23 PM, Andrew Wilson <agrw...@gmail.com> wrote:

> In my opinion we need to start putting all of these parts together, think
> about what you do best and volunteer to do that bit.

I see the most urgent group tasks as being:

1. Obtaining agreement on a product name; then

2. Armed with a name, establish a website where we can start putting
the parts together.

Best regards,

Paul

[Andrew Starks]

On Fri, Mar 22, 2013 at 2:23 PM, Andrew Wilson <agrw...@gmail.com> wrote:
> That's a good description too, but I think of full vs. minimal batteries as
> more of a selection mechanism in the wxLua module to add/remove modules.
>
> A big problem in doing original Lua for Windows was not trying not to do
> everything, focusing on what can be done now and letting it evolve to
> something more I think is the best way to ensure future utility and growth.
>
> Peter's summary says it for me...
> "Lua4Windows replacement + dynamic installation of MAINTAINED modules. The
> aim is to produce a consistent portable Lua distribution that hopefully
> works well for most intentions (development, distribution, embedding,
> teaching etc)"
>
> I'm going to spend sometime this weekend looking at all the parts we've got
> and see what I can contribute.
>
> In my opinion we need to start putting all of these parts together, think
> about what you do best and volunteer to do that bit.
> With LuaForWindows, it took quite a few releases until one was good enough
> for release.
>
> Cheers
> AGRW

Peter sorta-kinda-has-to decide how he wants the names split up. My guess is:

Retain LuaDist or something else for the technology for delivering
*any* module distribution.

Come up with a name for: This project, which is a batteries download +
managed module download + web site to promote it and Lua.

Assuming that is how it breaks down: I'm raising my hand to volunteer
to work on branding and web site.

That is, provided that we can come to a consensus on the direction
that we're sufficiently happy with and I get a sense of what the
working structure would be.

If it doesn't work out, then there are other areas that I can help in,
too (documentation).

- Andrew

[Thijs Schreijer]

Op vrijdag 22 maart 2013 21:14:03 UTC+1 schreef Paul E. "Marbux" Merrell het volgende:

Maybe a step back, but considering what has been said so far, maybe first define what it is, what purposes it serves, and more important, what it is not.

 

Technical;

• A complete Lua package to get started; Lua runtime, basic libraries (libraries maybe in binary or source format)
• Tools included; editor, debugger, package manager, package manager gui
• Aimed at quickly setting up an environment
• works on windows, linux and mac (although through different downloads)
• it is not a complete environment, but a 90% starter pack
• it is not intended to be a roll-out package (sys-admin distribution mechanism for many systems), but could be used that way

Non-technical;

• Provide an easier entrance in the Lua way for newbies
• providing a collection of documentation of the included packages

 

and then some...

 

would that help?

Thijs

 

[steve donovan]

On Sat, Mar 23, 2013 at 10:21 AM, Thijs Schreijer
<th...@thijsschreijer.nl> wrote:
> Technical;
> ...

> it is not intended to be a roll-out package (sys-admin distribution
> mechanism for many systems), but could be used that way

Good summary, Thijs! As for last point, it's straightforward to strip
out the non-runtime stuff. (Ship a script to do so, so a deployer can
build a custom runtime zip in a few seconds.)

> Non-technical;
> Provide an easier entrance in the Lua way for newbies
> providing a collection of documentation of the included packages

That's the key bit! Currently there's lots of good information about
Lua scattered all over the universe. The Lua wiki is a good resource,
but by it's nature not so well organized (despite the loads of
background work that David Manura has put in); wikis are always a
constant war against chaos.

A popular way to introduce languages these days is a live Web tutorial
(look at the excellent Go Tour http://tour.golang.org) I vaguely
remember starting a collaboration to do something like that for Lua,
providing content and the other doing web design. Unfortunately I
seen to have started and forgotten more projects than most people ;))

steve d.

[Andrew Starks]

I can see nothing but enthusiastic agreement on the spirit of the
landing page and content beneath.

I'm unclear on the... pivot point around the naming approach. I can't
tell whether there is a strong preference for Lua4Windows or merely a
distaste for proposed alternatives.

Could others please speak to this? Thanks!

-Andrew

[Peter Drahoš]

I rather abstain from name suggestions, I'm terrible with names. In my opinion none of the present project names capture the nature of what we aim to do. I however like one Lua project what deserves a lot more recognition. The Kepler Project[1] uses a solid not overused name, it has meaningful significance to Lua (and Sol) etc. and it is already recognized and established.

In fact looking over the kepler project website[1] I must say that our goals overlap significantly enough to ask the question: What is really the difference ? Desktop vs Web ? LuaDist does not care what we install, to be fair most of the core modules are the same anyway.

pd

[1] http://www.keplerproject.org/

[Andrew Starks]

On Mar 23, 2013, at 11:31, "Peter Drahoš" <dra...@gmail.com> wrote:

In fact looking over the kepler project website[1] I must say that our goals overlap significantly enough to ask the question: What is really the difference ? Desktop vs Web ? LuaDist does not care what we install, to be fair most of the core modules are the same anyway.

pd

[1] http://www.keplerproject.org/

The idea is that it isn't maintained any more and this could act as it's extension as well as the l4w project?

The name is solid, IMHO. 

Andrew 

[Andrew Starks]

On Mar 23, 2013, at 11:31, "Peter Drahoš" <dra...@gmail.com> wrote:

In fact looking over the kepler project website[1] I must say that our goals overlap significantly enough to ask the question: What is really the difference ? Desktop vs Web ? LuaDist does not care what we install, to be fair most of the core modules are the same anyway.

pd

[1] http://www.keplerproject.org/

The idea is that it isn't maintained any more and this could act as it's extension, as well as the l4w project's?

[marbux]

Hi, all,

Things to think about when considering the "Kepler" name:

-- Same name is being used by a NASA project. <http://kepler.nasa.gov/>.

-- The origin of the Kepler project name is certainly in line with the
meaning of "Lua" in Portuguese.
<http://kepler.nasa.gov/Mission/JohannesKepler/>.

-- But potential legal issues with assuming the name of another
project with a very similar goal. E.g., common law trademark, ability
to integrate with the existing Kepler project web site because of
copyright issues, etc.

Best regards,

Paul

[Andrew Starks]

I think you said that we'd be fine? :)

To All,

First, in the spirit of unity and purpose, I retract Lithium[Air] as a
name. It's dead to me now. (It does mean that I've now eaten a 3 year
domain registration for lithiumair.org, though... :)

So, you know how people say, "I'm no expert, but..."? Well, when it
comes to branding and marketing, I am on of those! :) At least, that's
what I did for a long time. Looking back, I've had some big regrets
with my name on them and most of those regrets involved a Naming
Fight.

Those happen when people dig in and get tired of fighting and then
just go with whatever piece-of-crap name happens to be floating
around. I hope that we don't do that here because I'd place
branding... not low on the list of things to get right.

A great name, logo and defined branding guidelines can be a nice
boost. It gets people, here and those who discover the project, in the
right mood. It buys us a bit of grace as they read through things.
It's like good documentation that way. It tells the story and makes
people want to believe in you.

However good the branding is, is how seriously people will take it. So
it's important.

Kepler is a great name and if it ends up being a possibility, it has my vote.

If not, we should keep trying. If "moon" is a necessary theme, then
there are thousands of ways to go with it. (2 minutes with google
gives too many options.)

So, if it is decided that we should keep trying, then I believe that
we need to tighten the circle of influence, before moving forward.
Perhaps more than most things, branding (especially names and logos)
can get very emotional and contentious.

It's in all-ya-all's hands on how, or whether, to approach this. If I
am to help on this part of the project, that's how I would need to see
us approach it.

Please understand that if I don't end up participating in the branding
side, it means that I will personally have more fun and satisfaction
and I will be a happier person, putting my energy into other parts of
this. I'll have stayed away from something that can take a lot of
energy and, at times, feel like a very frustrating job. :)

I hope this email is taken well and that I didn't step on anyone's nerves. :P

All the best, guys!

-Andrew

[marbux]

On Sat, Mar 23, 2013 at 9:30 PM, Andrew Starks <andrew...@trms.com> wrote:
>
> I think you said that we'd be fine? :)

I think it would be politic to ask on the Kepler mailing lists before
appropriating that project's name.
<http://www.keplerproject.org/en/Developers>. If they're okay with it,
legal problems are unlikely. Note that they also have a logo that's
not all that bad.

Best regards,

Paul

[steve donovan]

On Sun, Mar 24, 2013 at 2:17 AM, marbux <mar...@gmail.com> wrote:
> -- But potential legal issues with assuming the name of another
> project with a very similar goal. E.g., common law trademark, ability
> to integrate with the existing Kepler project web site because of
> copyright issues, etc.

I think just about the only one carrying the Kepler project flame
these days is Hisham with LuaRocks; everyone else has moved on. It's
hard for a funded OSS project to continue after the funding ceases.

He did say recently on lua-l that people were welcome to use the
Kepler project stylesheets.

It would be useful to drop Andre or Fabio a note, even though they
don't have much to do with OSS anymore.

steve d.

[Andrew Starks]

Absolutely, this assumes that a blessing is received from them.

My assumption was that Kepler was linked directly to PUC/Rio and that
their stylesheets, Logo and overall branding was directly linked to
the core Lua team's.

Is that not true?

-Andrew

[Peter Drahoš]

I am not sure. The kepler list[1] is active looking over some of the topics I must conclude that may of them overlap with the intended purpose of "batteries" project. Best to ask there.

pd

[1] https://groups.google.com/forum/#!forum/kepler-project

[Andrew Starks]

By active, do you mean that people want to use it, have questions and
then nobody answers? :)

-Andrew

[Peter Drahoš]

Yes, I did not say the project is active .. just the list.

pd 

[Andrew Starks]

On Sunday, March 24, 2013, Peter Drahoš wrote:

Yes, I did not say the project is active .. just the list.

pd 

--

 

That's a "kind" of active. One might also call it "abandoned." I'd say that's one more reason to see if Hisham and the others are cool with a merge. 

Andrew

[Ryan Pusztai]

Just to chime in the the name Kepler. I am actually kind of excited. I would also make Xavante, Orbit, and and other Web technology a base requirement for the install. This would keep in line with Kepler's original goal.
--
Regards,
Ryan

[Peter Drahoš]

Most Kepler modules are already in LuaDist, they just require some minor configuration and tweaks. Indeed this would be beneficial for both projects and it seems most of us agree that the it would be "a good thing". Of course this needs to be consulted with the current Kepler maintainers which probably boils down to the following list[1].

pd

[1] http://www.keplerproject.org/en/Dev_Team 

[steve donovan]

On Sun, Mar 24, 2013 at 6:41 PM, Ryan Pusztai <rpus...@gmail.com> wrote:
> Just to chime in the the name Kepler. I am actually kind of excited. I would
> also make Xavante, Orbit, and and other Web technology a base requirement
> for the install. This would keep in line with Kepler's original goal.

OK, but we will be adopting orphan projects in some cases.

I'll sound out Hisham, see if the idea makes sense from Brazil as well.

[Andrew Starks]

You were probably thinking this already, but could you also ask about
their preference on whether or not they'd want us to continue to use
that logo? It's essentially the same as Lua's.

-Andrew

[Hisham]

Hi there! (First of all, a public thank-you to Steve for pinging me
off-list and directing me to this discussion.)

First of all, I must say it was a happy surprise to see the Kepler
name suggested and the positive reaction that it got on this list. If
anything, it means our efforts back in the day still leave a positive
residual perception. :) So yes, I'm all for the idea. Still, some
interesting questions were raised in this thread and I'll try to cover
them to the best of my knowledge while bringing some context:

A quick recap on Kepler: Kepler was envisioned by André Carregal as a
research project to make Lua a viable language for web development, in
the sense that things like PHP and Ruby are nowadays viable, ie,
having the tools so that a coder can concentrate on their app rather
than reinventing wheels. So yeah, that goal included a good deal of
the "batteries" as well as figuring out distribution issues. A major
part of this project, also, was to bring together people who were
working seperately in pieces of this puzzle, including the politics to
cooperate with pre-Kepler projects such as CGILua, LuaSocket and
LuaBinaries. This also included getting funding -- Carregal spent a
lot of time working to get government grants for the research project
(which was officially a project involving PUC-Rio and the company he
worked on as well). People like Fabio and myself (both grad students
under Roberto at the time) were funded by this project to work on Lua
modules. LuaRocks was created because of Kepler, and I was paid to
work on it for two years. LuaForge was also created and its
maintenance funded by Kepler.

Eventually, we didn't get a grant renewal, plus the overall landscape
wasn't much in Kepler's favor (it never took off as a killer app for
Lua), and the project mostly died off. Some of us "inherited" the
modules we worked on and remained on them as volunteer side-projects,
working on our free time. I kept LuaRocks, Fabio kept Orbit and
others, and so on. Note that this includes stuff that I perceive as
key infrastructure such as LuaFileSystem. Fabio takes care of its
github repo, and released version 1.6.2 about 6 months ago. André
Carregal, on the other hand, effectively left the project (and I
really can't blame him for the burnout, after all the effort he went
through -- he's an unsung hero of the Lua ecosystem (or perhaps
"sung", since Yuri's book, which I heartily recommend for insights on
the story)). The project was reshaped not as a platform that made
"releases" but as a general hub for all those subprojects (the
availability of LuaRocks helped to diminished the reliance on one big
tarball).

The LuaForge shutdown was probably the major effect of the project's
twilight. Carregal tried as best a he could to keep the service going,
but without funding to hire someone to babysit GForge (and the growing
expectations of the Lua userbase), keeping it up with regular
shortages wasn't an option. He tried handing over LuaForge to "the
community", but as most of us remember, lots and lots of discussion
went on, but nothing as concrete as the old LuaForge ever emerged.

Now that we're done with the flashback, we get to where we are now.

A few thoughts on the matter:

* It looks like the effort you guys are organizing is currently a lot
more focused than the LuaForge 2 brainstorm we went through. I guess
it's because we're starting from something concrete (LuaForWindows,
LuaDist) and building from there. Still, for things such as a website
presence, documentation, etc, there's still a lot to be done. Focus is
key so it doesn't go the way of LuaForge 2.

* As for the use of the name, I'm not sure on its legal status, but my
guess is that Carregal, Fabio and anyone else who was involved in
Kepler would be happy to hand it over to a project that thrived to
ship a Lua platform. The intention to hand over the LuaForge name was
there before. It ended up not happening (luaforge.net still points to
the backup site Yuri (and Fabio?) put together) because there was
never a "version 2" website done which could host that content.

* As for the logo, we never had branding problems with Kepler before.
LHF's comment on the Lua stylesheet surprised me a bit, to be honest,
but we never used material straight from the lua.org website. Roberto
himself used the Kepler style on the LPeg website (IIRC, advised by
Carregal even). I think Kepler (the old or the new one) should keep an
image close to that of Lua (dark blue, sans-serif fonts, etc). The
logo is close to the Lua logo but not the same (gray outline,
different font). Lots of projects use variants the Lua logo
(LuaSocket, LuaRocks, etc) and the Lua authors never complained.

* On naming opinions in general: I think names such as LuaForge,
LuaForWindows, Kepler, are "strong brands". LuaForge due to its mental
association to RubyForge, SourceForge: it's an obvious name for a
catalog of projects. To be more modern, perhaps LuaHub would be the
other option, but luahub.com is already in use. LuaForWindows is
another obvious name, and the project got support even from lua.org
(heck, it's got a direct link from the Lua downloads page, and it's
been there longer than LuaRocks ;-D ). I'd like to think Kepler is a
strong brand as well after all the effort we put into it, and your
reaction here seems to agree. I think there's room for all these names
(as well as LuaDist, LuaRocks and others) as we're talking about
several different things here.

> My assumption was that Kepler was linked directly to PUC/Rio and that
> their stylesheets, Logo and overall branding was directly linked to
> the core Lua team's.

* It was linked but not that directly. The Lua team always wanted to
keep clear that the crazy "platform" stuff we were doing was not
coming from them (even though we occasionally interacted/consulted
with them and even contributed some modules, especially in pre-Kepler
days (now Roberto maintains basically lpeg only and LHF has his own
collection of modules)). Since 5.something they've been using Lua.org
as a copyright, to further separate themselves from Tecgraf, PUC-Rio
and avoid confusions of any kind. So, there shouldn't be worries about
that. (But I'm not a lawyer, blah blah... anyway, I can always ask
them. Roberto is currently my PhD advisor, after all).

> I am not sure. The kepler list[1] is active looking over some of the topics
> I must conclude that may of them overlap with the intended purpose of
> "batteries" project. Best to ask there.

Yes, there is overlap in the stated goals, as there is some overlap
between LuaDist and LuaRocks, for example. But nobody from the
original Kepler team is working on a "batteries"/"platform" package
anymore. That doesn't mean we wouldn't love to see it happen.

> I would also make Xavante, Orbit, and and other Web technology a base
> requirement for the install. This would keep in line with Kepler's original
> goal.

That would be nice, but I don't know how much that's necessary
(especially given all this things are one command away, with LuaDist
and LuaRocks). Some people will remember that Kepler has always been a
web-oriented platform for Lua, but I wouldn't mind seeing it as simply
(and more generally) a platform for Lua-based development (as opposed
to using Lua in a C-based development). That would be my suggestion
for the scope: the embedded/games people will always use Lua
differently and will have no use for
LuaForWindows/LuaDist/LuaRocks/Kepler. They're a huge part of the Lua
community, but there's another part which wants to work with Lua as a
base (ie, with a Lua "main function"). Those are the folks who need
the batteries.

Since I'm writing a long message anyway, I'll chime in some other
comments from my catching-up with the list:

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

Fully agreed. This is the kind of "focus" I was talking about. Too
much decision by committee will lead to a "LuaForge 2" situation. I'm
all for having gatekeepers (benevolent sub-dictators) for these
concerns (and I agree with the above nominations too).

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

Agreed, and both have pros and cons which make them suitable for
different parts of the project. The LuaRocks approach is inviting to
developers (and we know many module authors would shun at CMake (I
spoke to a few)) and scales (once we automate things further with the
MoonRocks project or the like) -- look at other language's repos, with
thousands and thousands of modules: the potential is there. The
stricter approach of LuaDist is perfect for maintaining the core
platform, ensuring it is portable, etc. We don't need this kind of
quality assurance for every single module on Earth (nor we have the
manpower to do it), but at least having them cataloged a rock is
better than nothing (see the fast-growing rate of ruby and npm repos).
The overlap between LR and LD will probably cause confusion to
newcomers, though. It's something to be sorted out.

I see a lot of potential for this effort, and I'm willing to help any
way I can (which unfortunately is not a lot lately). But count on me
to talk to Kepler/PUC people, etc.

-- Hisham

[marbux]

On Sun, Mar 24, 2013 at 2:42 PM, Hisham <h...@hisham.hm> wrote:

> The intention to hand over the LuaForge name was
> there before. It ended up not happening (luaforge.net still points to
> the backup site Yuri (and Fabio?) put together) because there was
> never a "version 2" website done which could host that content.

Re <http://luaforge.net/projects/>, wow! I'd never run across the
index page before. That page really brings it home that there is a
huge number of modules out there.

Thank you for your insights, Hisham. I'm liking the Kepler name more
and more. Although it would not be obvious to one who first stumbles
across the project, reviving an earlier project name seems to
emphasize that we stand on the shoulders of those who came before us.
So continuity, in a way. That gives the "About" page something to talk
about.

Best regards,

Paul

[Peter Drahoš]

This would only apply to the "core" modules. LuaRocks should stay as it is, simple for developers, I like it that way.

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

Agreed, and both have pros and cons which make them suitable for
different parts of the project. The LuaRocks approach is inviting to
developers (and we know many module authors would shun at CMake (I
spoke to a few)) and scales (once we automate things further with the
MoonRocks project or the like) -- look at other language's repos, with
thousands and thousands of modules: the potential is there. The
stricter approach of LuaDist is perfect for maintaining the core
platform, ensuring it is portable, etc. We don't need this kind of
quality assurance for every single module on Earth (nor we have the
manpower to do it), but at least having them cataloged a rock is
better than nothing (see the fast-growing rate of ruby and npm repos).
The overlap between LR and LD will probably cause confusion to
newcomers, though. It's something to be sorted out.

Exactly spot on. LuaRocks is great for hacking an posting new modules. LuaDist is good at installing the core in portable way etc. Both approaches are very close and differences can be mended by using an unified rockspec/dist.info files.

From the users standpoint this could be a no issue. Steve D. proposed a wx based GUI which could hide the difference and separate modules as "core" and "community". Basically it would use LuaDist for one and LuaRocks for other. 

I see a lot of potential for this effort, and I'm willing to help any
way I can (which unfortunately is not a lot lately). But count on me
to talk to Kepler/PUC people, etc.

In my opinion the most significant contribution would be unification and update of the rockspec format (which was already talked about on the LuaRocks list) so it would be usable for LuaDist and LuaRocks. Other differences are mostly in module naming conventions which can be ironed out in time. This would also mean we should agree on how to store the installed rockspec/dist.info files. I proposed a default location in package.path so the info is accessible through require and both LuaDist and LuaRocks.

eg. local info = require "info.luasocket"

Thank you Hisham for the insights into Kepler background .. I'm off to find a copy of Yuri's book.

pd

[steve donovan]

On Sun, Mar 24, 2013 at 11:42 PM, Hisham <h...@hisham.hm> wrote:
> As for the use of the name, I'm not sure on its legal status, but my
> guess is that Carregal, Fabio and anyone else who was involved in
> Kepler would be happy to hand it over to a project that thrived to
> ship a Lua platform.

Yes, I understand that the core Lua team is worried about projects
being too closely associated with them - it's that BSD "do not take
our name in vain" clause in operation.

> On naming opinions in general: I think names such as LuaForge,
> LuaForWindows, Kepler, are "strong brands".

Totally - people know these already. We can dream up CuteBrandName,
but the big boys get away with this because they have marketing
budgets ;) And even they make the mistake of renaming something and
losing loyalty - like Borland become Inprise.

I'm rather liking the name 'Kepler Desktop' actually....

> That would be nice, but I don't know how much that's necessary
> (especially given all this things are one command away, with LuaDist
> and LuaRocks).

Yep, especially with an appropriate meta-package (which is what the
Batteries are anyway) it's a one-liner.

> The overlap between LR and LD will probably cause confusion to
> newcomers, though. It's something to be sorted out.

There's a fair amount of work needed to do the integration, mostly the
needed manifest so that LR does not stand on LD's toes. And little
things like the bundled LR wanting to use 7z rather than the bundled
zip, etc. The proposed pretty front end would start by just showing
LD packages available as binaries - that's another manifest-building
job and then we move on.

> way I can (which unfortunately is not a lot lately). But count on me
> to talk to Kepler/PUC people, etc.

Thanks, that would be very useful. We really do need to know what they feel.

[marbux]

I'll just toss this one on the table because it occurred to me.
"Born-Again Kepler" would get us a 3-letter acronym "BAK." So one
might derive from it "LuaBAK."

Best regards,

Paul

[Andrew Starks]

Kepler is a great *name* and inside Lua circles, it is a great *brand*. Outside Lua, it is a complete unknown, but that is my guess and it's me being somewhat pandentic. I only clarify for my next point, which is...

The big boys don't pile product after product on top of their own name or the name of a product line or project, because it dilutes the brand. It doesn't strengthen it. My experience, observation and training run counter to everything you guys keep saying about Lua*. If I were PUC-Rio, I'd ask for us and anyone else to not do that. 

And I've said all of that before and I'm becoming the arm waiving spastic version of myself when I involve myself in this. I'll try to make it my last post on it and stick to the CI server, from here on out. :)

All the best

-Andrew