Lua for Windows needs help

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Lua for Windows needs help

RJP Computing
Hi,

Lua for Windows has been a great project, but the team thinks that it has reached as far as it can in it's current state. The problem is that Visual C++ 2005 is old and comes with very complicated deployment. Because of this Lua for Windows is looking for a way to build all the included modules from source. Now that has never been the goal of LfW, so we just take released binaries and include them. We would like to keep the focus in this area and ask for more help from the Lua community.

We are looking for people willing to help test, build and bring packages into a package system.

We need to discuss (which can be offline) what is the best approach to get the "the Holy Grail of 'build the world!'" for Lua for Windows. Once this is achieved, even partially we can start building a small limited Lua for Windows package based on this new approach.

Things to still figure out:
  * What are the most important modules for the stripped down version of LfW?
  * Should Lua and LuaJIT v2.x be included?
  * Which packaging system should be used? LuaDist (http://sourceforge.net/projects/luadist/) for building and LuaRocks (http://luarocks.org/) for adding new libraries to users installs?
  * Is LuaDist still alive and active? I goto http://luadist.org and the website is just a place holder. Can someone in the project comment?
  * Can this be made to be cross-platform? (I hope so, that is a personal goal)

Thoughts?
--
Regards,
Ryan

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

steve donovan
On Wed, Mar 2, 2011 at 3:52 PM, RJP Computing <[hidden email]> wrote:
>   * Should Lua and LuaJIT v2.x be included?

It's a bit of a bugger to mix two different kinds of Lua on Windows,
since extensions bind to a particularly named DLL. I think LuaJIT is
mature enough to be the main engine...

>   * Is LuaDist still alive and active?

Last time I tried it on Windows, it failed in a fairly weird way.
Maybe it's time to go down that rabbit hole again.

One way to approach this is to look at the candidate modules and see
if they can't all be persuaded to be rocks (something like WxLua may
be a challenge)

>   * Can this be made to be cross-platform? (I hope so, that is a personal
> goal)

That's the cool/interesting angle - pick a core set of modules which
work fine across the board. I know that you have been pushing for
wxLua and it certainly is the most mature cross-platform kit we have
at the moment.  IUP should also be there as well.

I know many will say 'but I need luaposix to do anything!' and yes,
it's useful, but we're looking for something that provides equivalent
functionality on most platforms. Most of the concepts map over (with
some notable exceptions like fork()), there are even symbolic links on
Windows these days. Lua-ex was an ambitious attempt, but it does whack
the standard namespaces too much.

steve d.

(who will try to use Windows more often for a while)

Reply | Threaded
Open this post in threaded view
|

RE: Lua for Windows needs help

Benoit Germain
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of steve donovan
> Sent: Wednesday, March 02, 2011 3:03 PM
> To: Lua mailing list
> Subject: Re: Lua for Windows needs help
>
> On Wed, Mar 2, 2011 at 3:52 PM, RJP Computing <[hidden email]>
> wrote:
> >   * Should Lua and LuaJIT v2.x be included?
>
> It's a bit of a bugger to mix two different kinds of Lua on Windows,
> since extensions bind to a particularly named DLL. I think LuaJIT is
> mature enough to be the main engine...
>
The problem is that LuaJIT2 doesn't support the full Lua C API. To be specific, lua_dump() is not implemented. As an example, because of this, it is not possible to transfer a Lua function from one state to another, which breaks the Lanes module almost completely. Also, any binary module that embeds Lua code in precompiled bytecode format won't run with LuaJIT since the VM implementations and compilers are totally different.

> That's the cool/interesting angle - pick a core set of modules which
> work fine across the board. I know that you have been pushing for
> wxLua and it certainly is the most mature cross-platform kit we have
> at the moment.  IUP should also be there as well.
>
IUP won't run with LuaJIT2 for the above reason.


Benoit.

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

Javier Guerra Giraldez
In reply to this post by RJP Computing
On Wed, Mar 2, 2011 at 8:52 AM, RJP Computing <[hidden email]> wrote:
> The problem is that Visual C++ 2005 is old and comes with very complicated
> deployment.

is post-2005 VC++ any better?

honestly, i only tried once to create a deployment-appropriate binary
with MS tools.  i don't remember which version it was; but it was
total hell.  (gimme mingw any day... well, any day i have to deal with
windows).

i did find hard to believe how many hoops you have to jump, since MS
is usually very focused on keeping simple things simple.  i think
there must be some motive i don't see.

but my question was:  has that improved?  or maybe 2005 was even worse
than what i saw?

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

steve donovan
On Wed, Mar 2, 2011 at 5:05 PM, Javier Guerra Giraldez
<[hidden email]> wrote:
> honestly, i only tried once to create a deployment-appropriate binary
> with MS tools.  i don't remember which version it was; but it was
> total hell.  (gimme mingw any day... well, any day i have to deal with
> windows).

Easy for users is the mantra;  developers are supposed to be different
- I sometimes thought the idea was to keep the developers so busy
chasing new stuff that they never had time for the rest of the
software universe.

Anyway, mingw is generating good code these days and Eclipse CDT is
working out well.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

steve donovan
In reply to this post by Benoit Germain
On Wed, Mar 2, 2011 at 4:25 PM, Benoit Germain <[hidden email]> wrote:
> IUP won't run with LuaJIT2 for the above reason.

What particular reason in particular?  Embedding byte code is a
deployment strategy, not essential.

The LuaJIT/Lanes issue is a big issue, I agree, ditto for other
deep-integration modules like Pluto.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

Peter Drahoš
In reply to this post by RJP Computing

On Mar 2, 2011, at 2:52 PM, RJP Computing wrote:

> Hi,
>
> Lua for Windows has been a great project, but the team thinks that it has reached as far as it can in it's current state. The problem is that Visual C++ 2005 is old and comes with very complicated deployment. Because of this Lua for Windows is looking for a way to build all the included modules from source. Now that has never been the goal of LfW, so we just take released binaries and include them. We would like to keep the focus in this area and ask for more help from the Lua community.
>
> We are looking for people willing to help test, build and bring packages into a package system.
>
> We need to discuss (which can be offline) what is the best approach to get the "the Holy Grail of 'build the world!'" for Lua for Windows. Once this is achieved, even partially we can start building a small limited Lua for Windows package based on this new approach.
Join the cause at [1]. And yes, I still think at the moment migrating projects to CMake solves most of the issues (independently of platform/IDE/compiler) but its no "Holy Grail".

> Things to still figure out:
>   * What are the most important modules for the stripped down version of LfW?
Lua, luasocket, luafilesystem - is the absolute minimum required.

>   * Should Lua and LuaJIT v2.x be included?
Yes, if possible older variants of both too.

>   * Which packaging system should be used? LuaDist (http://sourceforge.net/projects/luadist/) for building and LuaRocks (http://luarocks.org/) for adding new libraries to users installs?
>   * Is LuaDist still alive and active? I goto http://luadist.org and the website is just a place holder. Can someone in the project comment?
LuaDist is still active. Most of the team is busy with other tasks at the moment but I'm sure we could create a build for LfW fairly quickly (MinGW+CMake) as most of the modules are already available. There are issues with the automated deployment utility but building the modules manually or tailoring a build script specific for LfW requirements is possible. The Bootstrap[2] process we use for setting up the automated deployment of modules is basically it but with minimum selection of required modules.

Please note that LuaDist itself lacks maintainers and could use the collaboration. We have recently moved the project to GitHub[3] and are missing the project page. However Wiki content and all dist were successfully moved.

>   * Can this be made to be cross-platform? (I hope so, that is a personal goal)
Yes, LuaDist does this (OS X, Linux/Unix, Windows) but there are issues in more complex modules. Again we could use more feedback and maintainers.

pd

[1] https://github.com/LuaDist 
[2] https://github.com/LuaDist/Bootstrap Bootstrap Process (installs Lua, luasocket ...)
[3] https://github.com/LuaDist/Repository Available Modules


Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

Joshua Jensen-2
In reply to this post by RJP Computing
----- Original Message -----
From: RJP Computing
Date: 3/2/2011 6:52 AM
  * Which packaging system should be used? LuaDist (http://sourceforge.net/projects/luadist/) for building and LuaRocks (http://luarocks.org/) for adding new libraries to users installs?
  * Is LuaDist still alive and active? I goto http://luadist.org and the website is just a place holder. Can someone in the project comment?
  * Can this be made to be cross-platform? (I hope so, that is a personal goal)
LuaPlus uses the build system JamPlus to build Lua binaries and some 60 Lua modules on Windows, Mac OS X, and Linux.  JamPlus works with Visual C++ 6 through Visual Studio 2010 and MinGW (not recently tested) on Windows and GCC on Linux and Mac OS X.  Like CMake, JamPlus generates appropriate IDE projects for Visual Studio or Xcode.  There is some CodeBlocks support in there, but I don't know if it still works.

For example, LuaPlus builds the bitop module like so:

        Lua.CModule bitop : bit : bit.c ;

Josh
Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

Joshua Jensen-2
In reply to this post by steve donovan
----- Original Message -----
From: steve donovan
Date: 3/2/2011 9:06 AM
> On Wed, Mar 2, 2011 at 4:25 PM, Benoit Germain<[hidden email]>  wrote:
> Embedding byte code is a deployment strategy, not essential.
This is true, but it is a good strategy.  The byte code reading is FAR
faster, and for environments where we're scraping to get every bit of
memory that we can, being able to dump the Lua parser is a win.

I really wish LuaJIT provided a bytecode format, but I don't wish it
hard enough (yet) to pony up cash for Mike to make it happen.  :)

Josh

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

steve donovan
On Wed, Mar 2, 2011 at 6:33 PM, Joshua Jensen <[hidden email]> wrote:
> This is true, but it is a good strategy.  The byte code reading is FAR
> faster, and for environments where we're scraping to get every bit of memory

Yeah, I have been spoiled by the 'infinite desktop memory model' [1].
For the little guys, JIT is probably too expensive anyway.

I imagine that people in the gaming industry would like bytecode
loading as well, although bytecode is not obfuscation.[2]

steve d.
[1] some embedded programmer said this recently...
[2] Mike's point. (For most of us it _would_ be obfuscation, of course.)

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

Joshua Jensen-2
----- Original Message -----
From: steve donovan
Date: 3/2/2011 9:46 AM
> On Wed, Mar 2, 2011 at 6:33 PM, Joshua Jensen<[hidden email]>  wrote:
>> This is true, but it is a good strategy.  The byte code reading is FAR
>> faster, and for environments where we're scraping to get every bit of memory
> Yeah, I have been spoiled by the 'infinite desktop memory model' [1].
> For the little guys, JIT is probably too expensive anyway.
I work on console and can't use LuaJIT anyway.  It wouldn't even matter
if Mike made it work on Xbox 360 or PS3 or Wii.  The manufacturers
currently don't allow code to be generated on the fly.

However, a fast assembly VM *would* be usable.  That would be slick.
> I imagine that people in the gaming industry would like bytecode
> loading as well, although bytecode is not obfuscation.[2]
With load times on consoles for a level dictated by the manufacturer, we
need speed wherever we can get it.  I posted within a thread in the past
various performance timings between bytecode and straight text script.  
In one case, bytecode shaved a full second off the load time.

As far as obfuscation goes, I like PopCap's WoW implementation of
Peggle.  That's some seriously obfuscated code!  :)

Josh

Reply | Threaded
Open this post in threaded view
|

RE: Lua for Windows needs help

Antonio Scuri
In reply to this post by RJP Computing

 

  I think that LfW is perfect as it is. I use it and recommend it every time someone asks me for a tip for beginners. I also test it whenever I can, and I'm willing to help even more, so I don't think it should have some radical change.

 

* Should Lua and LuaJIT v2.x be included?

 

  LuaJIT impose some restrictions on modules so there will be less modules available for LfW to include if LuaJIT is the main interpreter. LuaJIT for me is a tool for advanced developers, LfW is a tool for everyone, that include beginners. And those advanced developers know how to rebuild any module to fit their needs. This already happen with IUP for instance, although the pre-compiled binaries are not compatible with LuaJIT, recompiling the IupLua binding with a simple define is enough to make it compatible (although leaving the internal Lua files exposed).

 

  * What are the most important modules for the stripped down version of LfW?

 

  Why you have to reduce the current number of modules? Since LfW is already stable, to update a module binary is not simple?

 

 

  * Which packaging system should be used? LuaDist for building and LuaRocks for adding new libraries to users installs?

  * Can this be made to be cross-platform? (I hope so, that is a personal goal)

 

  Recently I used the Ubuntu and Fedora GUI based package installation systems. Both already have Lua and several modules available. I think that those sources will be preferred by users in a long term. Just a thought.

 

  Anyway, if building from source code, it can be made portable. But again I think the charm of LfW is that it is great as it is for Windows.

 

 

 

  Ryan, I don't get the need for another Holy Grail. You already have a Holy Grail... Despite the Run Time Library endless discussion, what are your real needs? For the end user, what will be the benefits from those changes?

 

Best,

scuri

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of RJP Computing
Sent: quarta-feira, 2 de março de 2011 10:53
To: Lua list
Subject: Lua for Windows needs help

 

Hi,

 

Lua for Windows has been a great project, but the team thinks that it has reached as far as it can in it's current state. The problem is that Visual C++ 2005 is old and comes with very complicated deployment. Because of this Lua for Windows is looking for a way to build all the included modules from source. Now that has never been the goal of LfW, so we just take released binaries and include them. We would like to keep the focus in this area and ask for more help from the Lua community.

 

We are looking for people willing to help test, build and bring packages into a package system.

 

We need to discuss (which can be offline) what is the best approach to get the "the Holy Grail of 'build the world!'" for Lua for Windows. Once this is achieved, even partially we can start building a small limited Lua for Windows package based on this new approach.

 

Things to still figure out:

  * What are the most important modules for the stripped down version of LfW?

  * Should Lua and LuaJIT v2.x be included?

  * Which packaging system should be used? LuaDist (http://sourceforge.net/projects/luadist/) for building and LuaRocks (http://luarocks.org/) for adding new libraries to users installs?

  * Is LuaDist still alive and active? I goto http://luadist.org and the website is just a place holder. Can someone in the project comment?

  * Can this be made to be cross-platform? (I hope so, that is a personal goal)

 

Thoughts?
--
Regards,
Ryan

Reply | Threaded
Open this post in threaded view
|

RE: Lua for Windows needs help

Antonio Scuri
In reply to this post by steve donovan
> On Wed, Mar 2, 2011 at 4:25 PM, Benoit Germain <[hidden email]>
> wrote:
> > IUP won't run with LuaJIT2 for the above reason.
>
> What particular reason in particular?  Embedding byte code is a
> deployment strategy, not essential.

  IupLua binaries are not compatible with LuaJIT because it uses compiled
Lua code (luac) converted to C with bin2c. One possible approach is to not
compile the code, and use bin2c directly to Lua source. Probably also using
some compression tool like srlua or LuaSrcDiet.

Best,
Scuri



Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

steve donovan
In reply to this post by Antonio Scuri
On Wed, Mar 2, 2011 at 7:28 PM, Antonio Scuri <[hidden email]> wrote:
>   Recently I used the Ubuntu and Fedora GUI based package installation
> systems. Both already have Lua and several modules available. I think that
> those sources will be preferred by users in a long term. Just a thought.

This is very true, but despite the best efforts of Enrico Tassi, there
are limits to what Lua modules can be pushed up to the Debian/Ubuntu
repositories.  More obscure stuff, rapidly changing stuff, that's what
LuaRocks was invented for.

Cross-platform always comes with specific headaches. SciTE works
nicely on Windows and GTK platforms, but not OS X. And so on.

>   Ryan, I don't get the need for another Holy Grail. You already have a Holy
> Grail... Despite the Run Time Library endless discussion, what are your real
> needs? For the end user, what will be the benefits from those changes?

Well I don't think we are knights pursuing some vision of purity ;)...
if the thing builds cleanly, it becomes easier to manage and maintain.
It's then possible to keep a 32-bit build and a 64-bit build, and when
Windows works on ARM, we can build for that.

That is a good question - my answer would be to deliver something
sold, polished and well-documented. Maybe add some more multimedia
stuff (the project formerly known as Rubyk is very intriguing).  Give
people a smaller run-time core so they can distribute their programs
easier.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

Andrew Wilson-4
In reply to this post by Antonio Scuri
The focus of LfW, as Ryan stated, is a binary release of Lua Scripting
on Windows, currently LfW has forward compatibility issues due to use
of MSVC2005 runtime libraries, and a limited library of lua modules.
With addition of LuaRocks the limited library issue is reduced since
new LuaRocks can be added. The number one user benefit would be to
easy timely provision of lua modules to users and second benefit would
give lua module creators a target platform for their creations.
Another benefit would be to include Mac & Linux, for added Lua
Scripting portability, and expansion of Lua user base.

Minimal LfW distribution
  - Installer, Lua, Lua libs, LuaSocket, Lua File System, LuaRocks,
WebRocks UI (Orbiter based)

Extensible pieces (not available on all systems)
  - Scite Editor/Debugger
  - IUP, wxLua
  - LuaJit
  - current LfW libs

Regards
Andrew

On Wed, Mar 2, 2011 at 12:28 PM, Antonio Scuri <[hidden email]> wrote:

>
>
>   I think that LfW is perfect as it is. I use it and recommend it every time
> someone asks me for a tip for beginners. I also test it whenever I can, and
> I'm willing to help even more, so I don't think it should have some radical
> change.
>
> * Should Lua and LuaJIT v2.x be included?
>
>   LuaJIT impose some restrictions on modules so there will be less modules
> available for LfW to include if LuaJIT is the main interpreter. LuaJIT for
> me is a tool for advanced developers, LfW is a tool for everyone, that
> include beginners. And those advanced developers know how to rebuild any
> module to fit their needs. This already happen with IUP for instance,
> although the pre-compiled binaries are not compatible with LuaJIT,
> recompiling the IupLua binding with a simple define is enough to make it
> compatible (although leaving the internal Lua files exposed).
>
>   * What are the most important modules for the stripped down version of
> LfW?
>
>   Why you have to reduce the current number of modules? Since LfW is already
> stable, to update a module binary is not simple?
>
>   * Which packaging system should be used? LuaDist for building and LuaRocks
> for adding new libraries to users installs?
>
>   * Can this be made to be cross-platform? (I hope so, that is a personal
> goal)
>
>   Recently I used the Ubuntu and Fedora GUI based package installation
> systems. Both already have Lua and several modules available. I think that
> those sources will be preferred by users in a long term. Just a thought.
>
>
>   Anyway, if building from source code, it can be made portable. But again I
> think the charm of LfW is that it is great as it is for Windows.
>
>
>   Ryan, I don't get the need for another Holy Grail. You already have a Holy
> Grail... Despite the Run Time Library endless discussion, what are your real
> needs? For the end user, what will be the benefits from those changes?
>
>
> Best,
>
> scuri
>
>
>
>
>
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of RJP Computing
> Sent: quarta-feira, 2 de março de 2011 10:53
> To: Lua list
> Subject: Lua for Windows needs help
>
>
>
> Hi,
>
>
>
> Lua for Windows has been a great project, but the team thinks that it has
> reached as far as it can in it's current state. The problem is that Visual
> C++ 2005 is old and comes with very complicated deployment. Because of this
> Lua for Windows is looking for a way to build all the included modules from
> source. Now that has never been the goal of LfW, so we just take
> released binaries and include them. We would like to keep the focus in this
> area and ask for more help from the Lua community.
>
>
>
> We are looking for people willing to help test, build and bring packages
> into a package system.
>
>
>
> We need to discuss (which can be offline) what is the best approach to get
> the "the Holy Grail of 'build the world!'" for Lua for Windows. Once this
> is achieved, even partially we can start building a small limited Lua for
> Windows package based on this new approach.
>
>
>
> Things to still figure out:
>
>   * What are the most important modules for the stripped down version of
> LfW?
>
>   * Should Lua and LuaJIT v2.x be included?
>
>   * Which packaging system should be used? LuaDist
> (http://sourceforge.net/projects/luadist/) for building and LuaRocks
> (http://luarocks.org/) for adding new libraries to users installs?
>
>   * Is LuaDist still alive and active? I goto http://luadist.org and the
> website is just a place holder. Can someone in the project comment?
>
>   * Can this be made to be cross-platform? (I hope so, that is a personal
> goal)
>
>
>
> Thoughts?
> --
> Regards,
> Ryan

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

Ryan Pusztai
In reply to this post by Peter Drahoš


On Wed, Mar 2, 2011 at 11:23 AM, Peter Drahoš <[hidden email]> wrote:
Join the cause at [1]. And yes, I still think at the moment migrating projects to CMake solves most of the issues (independently of platform/IDE/compiler) but its no "Holy Grail".

Great, this is personally my winning vote for building and then put binary rocks in the LuaRocks repo for the Windows platform.
 
> Things to still figure out:
>   * What are the most important modules for the stripped down version of LfW?
Lua, luasocket, luafilesystem - is the absolute minimum required.

Agreed, but I would add:
  * Penlight as a large generic library
  * LuaBitOps
Optional but highly useful to make one that could write full apps out of the box:
  * read XML [1][2]
  * LuaSQL
  * LuaLogging
  * LuaDoc
  * lunit [3]
  * LeMock [4]
  * Lua-ZMQ[5][6]
  * LPeg

>   * Should Lua and LuaJIT v2.x be included?
Yes, if possible older variants of both too.

>   * Which packaging system should be used? LuaDist (http://sourceforge.net/projects/luadist/) for building and LuaRocks (http://luarocks.org/) for adding new libraries to users installs?
>   * Is LuaDist still alive and active? I goto http://luadist.org and the website is just a place holder. Can someone in the project comment?
LuaDist is still active. Most of the team is busy with other tasks at the moment but I'm sure we could create a build for LfW fairly quickly (MinGW+CMake) as most of the modules are already available. There are issues with the automated deployment utility but building the modules manually or tailoring a build script specific for LfW requirements is possible. The Bootstrap[2] process we use for setting up the automated deployment of modules is basically it but with minimum selection of required modules.

That would be huge. Can we make that happen, at least for the list of required and optional modules I have listed above? That would really make this a real start to the next version of LfW.
 
Please note that LuaDist itself lacks maintainers and could use the collaboration. We have recently moved the project to GitHub[3] and are missing the project page. However Wiki content and all dist were successfully moved.

I think your main website should point to GitHub. I remember that there was documentation on how to use and write a "dist" but I can't find it now.
 
>   * Can this be made to be cross-platform? (I hope so, that is a personal goal)
Yes, LuaDist does this (OS X, Linux/Unix, Windows) but there are issues in more complex modules. Again we could use more feedback and maintainers.

Yes this is my main reason for using LuaDist to build the Lua distribution.
-- 
Regards,
Ryan

[1] http://lua-users.org/lists/lua-l/2007-12/msg00088.html  ( I currently use this in a bunch of projects and it works great.
Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

Stuart P. Bentley
In reply to this post by RJP Computing
On Wed, 02 Mar 2011 08:52:36 -0500, RJP Computing <[hidden email]>  
wrote:

>   * Can this be made to be cross-platform? (I hope so, that is a personal
> goal)
>
> Thoughts?

This is the way I've always thought of it: break LfW into multiple parts:

* The Lua debugger integration for SciTE
* The set of combined libraries (LuaSocket, LFS, IUP, CD, IM, Penlight etc)
* The Windows installer for Lua, LuaRocks, and SciTE (and said integration)

For the library collection, make a "meta-package" rockspec that installs  
all these packages (skipping them if not available for the current  
platform, eg. LuaCOM on anything but Windows).

That way, you make it so the Windows installer installs Lua, Rocks, and  
the customized SciTE, then runs luarocks install http://path/to/lfw/rock.

On other operating systems you can use the native package installer for  
Lua and LuaRocks, install the SciTE Lua debugging configuration however  
(PPA, RPM, AUR, tarball...), and then run the same luarocks install as on  
Windows.

As far as I can tell, the main problem with this currently is that some of  
the libraries in LfW don't have rocks (such as IUP... hint ;))


Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

Stuart P. Bentley
In reply to this post by Javier Guerra Giraldez
On Wed, 02 Mar 2011 10:05:27 -0500, Javier Guerra Giraldez  
<[hidden email]> wrote:

> On Wed, Mar 2, 2011 at 8:52 AM, RJP Computing <[hidden email]>  
> wrote:
>> The problem is that Visual C++ 2005 is old and comes with very  
>> complicated
>> deployment.
>
> is post-2005 VC++ any better?
>
> honestly, i only tried once to create a deployment-appropriate binary
> with MS tools.  i don't remember which version it was; but it was
> total hell.  (gimme mingw any day... well, any day i have to deal with
> windows).
>
> i did find hard to believe how many hoops you have to jump, since MS
> is usually very focused on keeping simple things simple.  i think
> there must be some motive i don't see.
>
> but my question was:  has that improved?  or maybe 2005 was even worse
> than what i saw?
>

My experience with using the Windows 7 SDK has been much easier than it  
was in 2005 (when Microsoft's free development offerings were in their  
infancy). From what I saw now, the only hard scenario is using MSBuild.exe  
without having Visual C++ to generate the .vcproj files (which are a  
Lovecraftian nightmare when viewed raw). If you have to use msbuild,  
Visual C++ Express is free.

Other than that, just installing the SDK and running CL.exe (after a  
possibly necessary run of setenv /Release /x86) doesn't seem any harder  
than running GCC on Linux (except for the actual "installing the SDK"  
step).


Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

David Manura
In reply to this post by Joshua Jensen-2
On Wed, Mar 2, 2011 at 11:31 AM, Joshua Jensen <[hidden email]> wrote:
> LuaPlus uses the build system JamPlus to build Lua binaries and some 60 Lua
> modules on Windows, Mac OS X, and Linux.  JamPlus works with Visual C++ 6
> through Visual Studio 2010 and MinGW (not recently tested) on Windows and
> GCC on Linux and Mac OS X.  Like CMake, JamPlus generates appropriate IDE
> projects for Visual Studio or Xcode.  [...]
>
>         Lua.CModule bitop : bit : bit.c ;

Thanks for sharing.  I'm a little weary of yet-another-homegrown-build
system [4] (albeit jam fork here), but on some digging I found an
example [1], Lua module jamfiles [2], and motivation [3].  I'm curious
if there's any more recent or detailed published description of the
motivation given below, particularly in relation to the bigger names
of cmake and bjam.

  "I love CMake, but when push came to shove, Jam's speed and more
expressive language (such as the variable product expansion ability)
won out." [3]

[1] http://lua-users.org/lists/lua-l/2010-12/msg00731.html
[2] https://github.com/jjensen/luaplus51-all/tree/master/Src/modules.jambuild
[3] http://www.cmake.org/pipermail/cmake/2007-December/018479.html
[4] http://lua-users.org/wiki/LuaBuildSystems

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows needs help

steve donovan
In reply to this post by Stuart P. Bentley
On Thu, Mar 3, 2011 at 6:04 AM, Stuart P. Bentley <[hidden email]> wrote:
> For the library collection, make a "meta-package" rockspec that installs all
> these packages (skipping them if not available for the current platform, eg.
> LuaCOM on anything but Windows).

That sounds like an excellent idea - rockspecs can have per-platform
overrides so that such a meta-package would only pull in LuaCOM on
Windows, etc.

> On other operating systems you can use the native package installer for Lua
> and LuaRocks, install the SciTE Lua debugging configuration however (PPA,
> RPM, AUR, tarball...), and then run the same luarocks install as on Windows.

Yes, generally it would be preferable to get SciTE from the native
package installer, but I'm pretty sure that LuaRocks can deliver the
debugging extensions with a little ingenuity, which would get around
the need for native packages for it.

As for OS X, which is famously SciTE-free (unless you have the GTK
runtime) there is also lua-gdb as an option for Emacs. (This utility
gives a gdb-like interface to the Lua debugger, plus allowing stepping
into C extension code. If the mimicry was good enough, it might work
for other IDEs that use gdb behind the scenes.)

> As far as I can tell, the main problem with this currently is that some of
> the libraries in LfW don't have rocks (such as IUP... hint ;))

Yes, the big boys (especially the GUI frameworks) are tricky to
package cleanly. Well worth the effort, however.

steve d.

12