> -Original Message-
> From: Thijs Schreijer [mailto:th...@thijsschreijer.nl]
> Sent: zondag 7 april 2013 8:27
> To: luarocks-developers@lists.sourceforge.net
> Subject: Re: [Luarocks-developers] MinGW and LuaSocket
>
> > Actually, if you have a proper Windows
> -Original Message-
> From: Hisham [mailto:h...@hisham.hm]
> Sent: zondag 7 april 2013 5:37
> To: luarocks-developers@lists.sourceforge.net
> Subject: Re: [Luarocks-developers] MinGW and LuaSocket
>
> On 4 April 2013 17:45, Thijs Schreijer wrote:
> > @Hisham
> Actually, if you have a proper Windows environment for LuaRocks
> working, it's probably easier to just build and pack those rocks
> again... which brings me to some questions on what to do regarding the
> .zip distribution. The LuaRocks .zip file for Windows includes Lua 5.1
> binaries based on
On 4 April 2013 17:45, Thijs Schreijer wrote:
> @Hisham
>I think the windows instructions on the website could also be
>updated. /MW switch is missing there. Hopefully my altered help
>text in the installer provides some more guidance, so feel free
>to use that on the site to.
I j
On 4 April 2013 13:59, steve donovan wrote:
> However, the old runtime still has life in it because the binary Windows
> rocks in the repo are built against it. So it's still best for the
> compiler-free.
There are not that many binary rocks there, and many of the ones
available are outdated too.
On 4 April 2013 04:21, steve donovan wrote:
> On Wed, Apr 3, 2013 at 11:48 PM, Hisham wrote:
>>
>> launcher, config defaults). If you have any requests/improvements for
>> the Windows and/or mingw side of things, please send pull requests and
>> I'll merge them in.
>
>
> If the time is early next
>
> variables = {
> MSVCRT = 'm', -- stop us linking against msvc80
> LUALIB = 'liblua.dll.a',
> }
> The first line would no longer be necessary with your fix, (although note
> that the msvcr80 case must then be explicit in the config file!)
> The second line is the _import_ library for l
BTW, maybe we shall add some auto test in the rocks for their installation
on different platforms , only when it passes these deployment test, then we
will post the rock spec?
On Apr 4, 2013 3:21 AM, "steve donovan" wrote:
> On Wed, Apr 3, 2013 at 11:48 PM, Hisham wrote:
>
>> launcher, config de
Thx. It is a lot smaller, so one problem less :)
From: steve donovan [mailto:steve.j.dono...@gmail.com]
Sent: vrijdag 5 april 2013 19:04
To: luarocks-developers@lists.sourceforge.net
Subject: Re: [Luarocks-developers] MinGW and LuaSocket
On Fri, Apr 5, 2013 at 3:47 PM, Thijs Schreijer
mailto:th
On Fri, Apr 5, 2013 at 3:47 PM, Thijs Schreijer wrote:
> So lua and luac both contain their own Lua core (they don't need the dll
> iirc). Then even when I link a library against "lua51.dll" I get two
> Lua-cores loaded at runtime; 1 in lua.exe, 2 in lua51.dll which the library
> was linked agains
> -Original Message-
> From: steve donovan [mailto:steve.j.dono...@gmail.com]
> Sent: vrijdag 5 april 2013 7:55
> To: luarocks-developers@lists.sourceforge.net
> Subject: Re: [Luarocks-developers] MinGW and LuaSocket
>
> On Thu, Apr 4, 2013 at 10:45 PM, Thijs Schreij
On Fri, Apr 5, 2013 at 11:15 AM, steve donovan
wrote:
> On Fri, Apr 5, 2013 at 10:55 AM, Thijs Schreijer
> wrote:
>>
>>
>> Then the LuaRocks installer would have to be changed. It now looks
>> explicitly for "lua5.1.lib" in the \bin\ and \lib\ directories. So it would
>> have to look for multiple
On Fri, Apr 5, 2013 at 10:55 AM, Thijs Schreijer wrote:
>
> Then the LuaRocks installer would have to be changed. It now looks
> explicitly for "lua5.1.lib" in the \bin\ and \lib\ directories. So it would
> have to look for multiple files; "lua5.1.lib liblua.dll lua51.dll" (any
> others?) and then
> -Original Message-
> From: steve donovan [mailto:steve.j.dono...@gmail.com]
> Sent: vrijdag 5 april 2013 7:55
> To: luarocks-developers@lists.sourceforge.net
> Subject: Re: [Luarocks-developers] MinGW and LuaSocket
>
> On Thu, Apr 4, 2013 at 10:45 PM, Thijs Schreij
On Thu, Apr 4, 2013 at 10:50 PM, Thijs Schreijer wrote:
> rclauncher.o
> rclauncher.obj
> Shouldn't this be included as source code and compiled upon request?
>
> The .o file should be fine, since it's the linker step that will be
different for the two runtimes. The .obj file might only work
On Thu, Apr 4, 2013 at 10:45 PM, Thijs Schreijer wrote:
> What I did so far was renaming the "liblua.a" generated and
> installed by the Lua makefile to "lua51.lib" and then LuaRocks
> links against that (without errors so far). Am I supposed to
> link against the DLL?
>
I think that might 'appea
Another issue I noticed: LuaRocks includes the following binaries;
rclauncher.o
rclauncher.obj
Shouldn't this be included as source code and compiled upon request?
Thijs
--
Minimize network downtime and maximize team
> LUA_LIB is a special case because if someone's using mingw then they would
> want to link against the DLL, surely?
>
What I did so far was renaming the "liblua.a" generated and
installed by the Lua makefile to "lua51.lib" and then LuaRocks
links against that (without errors so far). Am I supp
On Thu, Apr 4, 2013 at 7:20 PM, Thijs Schreijer wrote:
> What is the difference between the options /LUA and /BIN. I can guess
> /BIN, containing the binaries and executables, like lua.exe. But what is
> /LUA for? When is it used?
>
Looking at that install script, /LUA becomes LUA_PREFIX, which i
013 23:48
> To: luarocks-developers@lists.sourceforge.net
> Subject: Re: [Luarocks-developers] MinGW and LuaSocket
>
> Guys,
>
> I'm planning a new release soon (hopefully until the end of the week)
> including improvements for supporting Lua 5.1 and 5.2 in parallel on
On Thu, Apr 4, 2013 at 2:50 PM, steve donovan wrote:
> Yep, the logic is not right. That's why I'm writing a pure Lua install
> script ...
>
Which is classic rewrite mentality, of course. The Windows case is
complicated by two compilers, and at least two incompatible run-times.
Although generally
On Thu, Apr 4, 2013 at 2:11 PM, Thijs Schreijer wrote:
> I made some fixes see this branch:
> https://github.com/Tieske/luarocks/tree/MinGW_fix
>
Cool, I'll track that.
>
> But also working through the installation I found that when I build Lua
> from source with MinGW, and then install LuaRocks
> From: steve donovan [mailto:steve.j.dono...@gmail.com]
> Sent: donderdag 4 april 2013 9:21
> To: luarocks-developers@lists.sourceforge.net
> Subject: Re: [Luarocks-developers] MinGW and LuaSocket
>
> On Wed, Apr 3, 2013 at 11:48 PM, Hisham wrote:
> > launcher, config de
On Wed, Apr 3, 2013 at 11:48 PM, Hisham wrote:
> launcher, config defaults). If you have any requests/improvements for
> the Windows and/or mingw side of things, please send pull requests and
> I'll merge them in.
>
If the time is early next week, then I can have some fun over the weekend
testin
Guys,
I'm planning a new release soon (hopefully until the end of the week)
including improvements for supporting Lua 5.1 and 5.2 in parallel on
Unix (this shouldn't take actual code changes, but more infrastructure
stuff such as improvements in the configure script, command-line
launcher, config
On Wed, Apr 3, 2013 at 3:49 PM, Thijs Schreijer wrote:
> What would the correct setting in the config file be?
>
This works for me:
variables = {
MSVCRT = 'm', -- stop us linking against msvc80
}
It seems that -lm is fine with mingw, although not needed. There's no
option to have no libra
> -Original Message-
> From: steve donovan [mailto:steve.j.dono...@gmail.com]
> Sent: woensdag 3 april 2013 7:34
> To: luarocks-developers@lists.sourceforge.net
> Subject: Re: [Luarocks-developers] MinGW and LuaSocket
>
> On Tue, Apr 2, 2013 at 9:09 PM, Thijs Schreij
On Tue, Apr 2, 2013 at 9:09 PM, Thijs Schreijer wrote:
> What worries me though, is looking at the LuaRocks code and finding this
> line;
> extras[#extras+1] = "-l" .. (variables.MSVCRT or "msvcr80")
> The rockspec doesn't have a MSVCRT variable, so the "msvcr80" is supplied.
> Is that ok
> -Original Message-
> From: steve donovan [mailto:steve.j.dono...@gmail.com]
> Sent: dinsdag 2 april 2013 11:09
> To: luarocks-developers@lists.sourceforge.net
> Subject: Re: [Luarocks-developers] MinGW and LuaSocket
>
> On Thu, Mar 28, 2013 at 10:37 PM, Thi
On Thu, Mar 28, 2013 at 10:37 PM, Thijs Schreijer
wrote:
> I've been struggling with this, so if you have one, that would be greatly
> appreciated (and shouldn't that become the default rockspec in the LuaRocks
> Repo then?)
>
This does not _quite_ work on Windows because of a little mistake in
l
On Thu, Mar 28, 2013 at 10:37 PM, Thijs Schreijer
wrote:
> I've been struggling with this, so if you have one, that would be greatly
> appreciated (and shouldn't that become the default rockspec in the LuaRocks
> Repo then?)
Sure, I'm computer-less for the weekend, so just hang out until Monday
> -Original Message-
> From: steve donovan [mailto:steve.j.dono...@gmail.com]
> Sent: donderdag 28 maart 2013 8:21
> To: luarocks-developers@lists.sourceforge.net
> Subject: Re: [Luarocks-developers] MinGW and LuaSocket
>
> It's entirely possible to do
On Wed, Mar 27, 2013 at 11:30 PM, Thijs Schreijer
wrote:
> Still trying to figure out dll dependencies, currently I'm using the Lua
> executable from LuaRocks and building libraries with MinGW. Is LuaRocks build
> using the MS tool chain? Because in that case those executables are also
> unsafe
Still trying to figure out dll dependencies, currently I'm using the Lua
executable from LuaRocks and building libraries with MinGW. Is LuaRocks build
using the MS tool chain? Because in that case those executables are also unsafe
to use with libraries compiled with MinGW.
Thijs
---
Damn! I also missed that when looking at the ProcMon capture...
Regards,
Ignacio
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognitio
iginal Message-
> From: Thijs Schreijer [mailto:th...@thijsschreijer.nl]
> Sent: woensdag 27 maart 2013 18:35
> To: luarocks-developers@lists.sourceforge.net
> Subject: Re: [Luarocks-developers] MinGW and LuaSocket
>
> > -Original Message-
> > From: Ignacio Burg
> -Original Message-
> From: Ignacio Burgueño [mailto:iburgu...@gmail.com]
> Sent: dinsdag 26 maart 2013 22:48
> To: LuaRocks developers list
> Subject: Re: [Luarocks-developers] MinGW and LuaSocket
>
> Ok, let me get back to you. I'm on LR 1.0 here, but I&#x
For reference, this is the output I get having added some print statements.
LR 2.0.12 here.
7-Zip 9.10 beta Copyright (c) 1999-2009 Igor Pavlov 2009-12-22
Processing archive: C:\Temp\luasocket-2.0.2-3.win32-x86.rock
Extracting lib
Extracting lib\mime
Extracting lib\mime\core.dll
Extracting
all
Try to install and send us the output.
On Tue, Mar 26, 2013 at 3:57 PM, Thijs Schreijer wrote:
> > -Original Message-
> > From: Ignacio Burgueño [mailto:iburgu...@gmail.com]
> > Sent: dinsdag 26 maart 2013 19:37
> > To: LuaRocks developers list
> &
> -Original Message-
> From: Ignacio Burgueño [mailto:iburgu...@gmail.com]
> Sent: dinsdag 26 maart 2013 19:37
> To: LuaRocks developers list
> Subject: Re: [Luarocks-developers] MinGW and LuaSocket
>
> Thijs, could you use ProcMon and check which operation
It was thus said that the Great Ignacio Burgueño once stated:
> On Tue, Mar 26, 2013 at 3:06 PM, Sean Conner wrote:
>
> >
> > "luarocks install" attempts to download the rock first. What you need to
> >
>
> Does it? I was under the impression that when given a binary rock, install
> simply in
Thijs, could you use ProcMon and check which operation is failing?
http://live.sysinternals.com/ProcMon.exe
And also, could you try to run luarocks install luarocks-2.0.2-3.win32-x86.rock
from an elevated command prompt?
--
On Tue, Mar 26, 2013 at 3:06 PM, Sean Conner wrote:
>
> "luarocks install" attempts to download the rock first. What you need to
>
Does it? I was under the impression that when given a binary rock, install
simply installed that file.
No fetching involved.
-
>
> "luarocks install" attempts to download the rock first. What you need
> to try is:
>
> luarocks build luasocket-2.0.2-3.win32-x86.rock
>
> -spc
>
Also fails;
C:\Temp>luarocks build luarocks-2.0.2-3.win32-x86.rock
Error: Could not fetch rock file: File not found:
luarocks-2.0.2
It was thus said that the Great Thijs Schreijer once stated:
> >
> > `luarocks install luasocket-2.0.2-3.win32-x86.rock` should install the
> > binaries without recompiling. Did you try that?
> >
>
> Just did;
>
> C:\>cd temp
>
> C:\Temp>dir
> Volume in drive C is TI30569200A
>
> Directory
>
> `luarocks install luasocket-2.0.2-3.win32-x86.rock` should install the
> binaries without recompiling. Did you try that?
>
Just did;
C:\>cd temp
C:\Temp>dir
Volume in drive C is TI30569200A
Directory of C:\Temp
26-mrt-2013 18:46 .
26-mrt-2013 18:46 ..
26-mrt
On 26 March 2013 09:21, steve donovan wrote:
> On Tue, Mar 26, 2013 at 2:17 PM, Thijs Schreijer
> wrote:
>> Only question remaining is whether the binaries were created with MinGW...
>> If not there could be some runtime.dll problems, but for now it works.
>
> I _suspect_ that it might be ye ol
On 25 March 2013 19:11, Thijs Schreijer wrote:
> List,
>
> I can’t get LuaRocks and MinGW to play nice when installing LuaSocket.
> Nothing new;
> http://lists.luaforge.net/pipermail/luarocks-developers/2011-January/002289.html
>
> So I figured; let’s take the binaries…
I don't know if the binari
On Tue, Mar 26, 2013 at 2:17 PM, Thijs Schreijer
wrote:
> Only question remaining is whether the binaries were created with MinGW...
> If not there could be some runtime.dll problems, but for now it works.
I _suspect_ that it might be ye olde MVSC 2005. Thank the gods, Lua
for Windows is movin
> -Original Message-
> From: Thijs Schreijer [mailto:th...@thijsschreijer.nl]
> Sent: maandag 25 maart 2013 23:12
> To: luarocks-developers@lists.sourceforge.net
> Subject: [Luarocks-developers] MinGW and LuaSocket
>
> List,
>
> I can't get LuaRocks and MinGW to play nice when installing
50 matches
Mail list logo
