To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

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

To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Stefano
Hi all,

As part of my work on ULua [1], I routinely go through the task of trying to install the Lua rocks from luarocks.org (root manifest) on Windows, OSX and Linux.

Problems include, but are not limited to:
+ rocks contending the same module name, who doesn't love 'json'?
+ rocks polluting the module namespace with generic names - anyone using 'test'? - worsening the problem above
+ missing supported OS and required external libraries specifications
+ no automated way of building such required external libraries
+ no standardised build tool: make, cmake, nmake, automake...just lake is missing!
+ builds which should work but fails in the most creative ways (I am easily amused)
+ wrong dependency requirements

The exact three OS I have used are by no means esoteric:
Windows7 64 + Visual Studio 2015
Latest stable OSX + bundled Clang
Ubuntu 10.04LTS + gcc 4.8
It follows these problems are representative of the average user experience.

Even libraries with a certain fame, like LuaSocket, are not immune to the above.
Up to 2 months ago the latest LuaSocket stable version did not build on Windows/MinGW and required googling + manual patching of the rockspec (on a side note, for a couple of years before that it also injected globals and was incompatible with strict.lua and similar).

Trying to improve this situation I would, as a first step, kindly ask for the cooperation of Lua rocks maintainers. Even if you don't care less about my project, you can still threat it as an automated build-test framework (stricter than Luarocks), which in a sense it is. All info is found at [2].

More precisely, could you please:

1. Check wether your Lua rock pass or fail at [3]. If it pass, champagne! Otherwise...

2. Check wether it fails due to a platform-independent error (like contending the module name) at [4]. If so, please fix and celebrate accordingly. Otherwise...

3. Check wether it fails due to platform-dependent errors at [5]. If so, please fix and celebrate accordingly. If not...

4. It means your rock depends on something that is not available as can be seen at [6]. Please blame or blackmail whoever is responsible, or fix your broken dependency.

You should *not* be concerned with two errors:
1. module_conflict errors in [4] that are due to multiple *related* rocks pointing to the same module (example: metalua-compiler and metalua-parser both contending the metalua module): these will be supported shortly
2. unsupported_external_library errors: I am not going to support these shortly (aside from selected libraries which I will package manually) but there is nothing that you can do about it

Finally, Luarocks stdout and sterr for each rock are logged into [7] for your convenience.

The fixes will automatically propagate to ULua, should it concern you.

Example, for the case of Copas:
1. Damn, it failed!
2. No errors here...
3. No errors here as well, who is to blame...
4. Me! I am depending on a never existed and never going to exist LuaSocket 2.1.

What follows are my personal considerations around Luarocks and the Lua ecosystem, so if you are only interested in helping out improving the rocks you can stop reading here (links [*] at the end of this e-mail).

So, the dependency for Copas is "luasocket >= 2.1" and Luarocks accepts 3.0-rc1.
I personally find this reason for concern and not for relief (different major version, and it's not even a stable release!)
The stated position [8] is 'no, "enforce semver to all rock authors!" is not possible'. 
Despite that, only a tiny minority of rocks has dependencies targeting a specific version (some do not list version requirements at all, I guess their maintainers have given up).
Hence, lacking agreement on the meaning of numbers, any new rock can potentially wreak havoc. Yes, upgrades are not supported. But any rock that installs today maybe will not install tomorrow. 
I wonder how that is preferable to assuming semver and accepting that some modules do not follow it.

More generally, the version format specification is documented [9] as "please look at the source code".
Also, rocks which contend the same module but are unrelated (json4lua, luajson) are not rejected. All these details point to a 'lack of policy' which I find detrimental to the Lua ecosystem.

This lack of policy has a much wider scope and has been popularised with the "mechanism not policies" phrase. I am fine on this idea being applied to the language itself.
But in the specific context of modules/packages this mindset does not work. I am not referring to the lack of a module() function (which, as implemented, I am glad disappeared), but:
+ agreement on module responsibilities (no globals ever, ...)
+ agreement on version format, on its meaning, and on the module metadata
+ agreement on an extended standard library (*everything* IO included, ...)
+ agreement on Lua compile flags (what type is a number? which compat options? which conversion options? ...)
+ agreement on documentation and tests

All this necessarily has to come from upstream. Yes, the Lua team blessing hand.
Indeed, language-wise, Lua has been perfectly suited as a general purpose language since 5.0, that's 12 years ago, and as of today there are no satisfactory solutions to the points above nor a particularly healthy ecosystem.
If the idea was "let's leave this to the community: a natural selection process will yield an optimal result", then it clearly has not worked.

I am happy that Lua is light and customisable and that this contributes to its success in embedded systems and as a glue Language. 
It would be great if steps were taken to offer also a pleasing experience as a general-purpose programming language.
This would take the form of a batteries-included version (side by side to the light version already available) plus answers to the +s above.

Yes, I can use Python or Javascript. However I cannot help but notice that Lua is a preferable option both from a language and from an implementation perspective.

Bests,
Stefano




Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Nagaev Boris
On Sun, Sep 6, 2015 at 11:58 PM, Stefano <[hidden email]> wrote:

> Hi all,
>
> As part of my work on ULua [1], I routinely go through the task of trying to
> install the Lua rocks from luarocks.org (root manifest) on Windows, OSX and
> Linux.
>
> Problems include, but are not limited to:
> + rocks contending the same module name, who doesn't love 'json'?
> + rocks polluting the module namespace with generic names - anyone using
> 'test'? - worsening the problem above
> + missing supported OS and required external libraries specifications
> + no automated way of building such required external libraries
> + no standardised build tool: make, cmake, nmake, automake...just lake is
> missing!
> + builds which should work but fails in the most creative ways (I am easily
> amused)
> + wrong dependency requirements
>
> The exact three OS I have used are by no means esoteric:
> Windows7 64 + Visual Studio 2015
> Latest stable OSX + bundled Clang
> Ubuntu 10.04LTS + gcc 4.8
> It follows these problems are representative of the average user experience.
>
> Even libraries with a certain fame, like LuaSocket, are not immune to the
> above.
> Up to 2 months ago the latest LuaSocket stable version did not build on
> Windows/MinGW and required googling + manual patching of the rockspec (on a
> side note, for a couple of years before that it also injected globals and
> was incompatible with strict.lua and similar).
>
> Trying to improve this situation I would, as a first step, kindly ask for
> the cooperation of Lua rocks maintainers. Even if you don't care less about
> my project, you can still threat it as an automated build-test framework
> (stricter than Luarocks), which in a sense it is. All info is found at [2].
>
> More precisely, could you please:
>
> 1. Check wether your Lua rock pass or fail at [3]. If it pass, champagne!
> Otherwise...

I'm happy because all my modules [1] but one pass. The module
"lua-rote" doesn't pass because it depends on external C library ROTE.


[1] https://luarocks.org/modules/starius

>
> 2. Check wether it fails due to a platform-independent error (like
> contending the module name) at [4]. If so, please fix and celebrate
> accordingly. Otherwise...
>
> 3. Check wether it fails due to platform-dependent errors at [5]. If so,
> please fix and celebrate accordingly. If not...
>
> 4. It means your rock depends on something that is not available as can be
> seen at [6]. Please blame or blackmail whoever is responsible, or fix your
> broken dependency.
>
> You should *not* be concerned with two errors:
> 1. module_conflict errors in [4] that are due to multiple *related* rocks
> pointing to the same module (example: metalua-compiler and metalua-parser
> both contending the metalua module): these will be supported shortly
> 2. unsupported_external_library errors: I am not going to support these
> shortly (aside from selected libraries which I will package manually) but
> there is nothing that you can do about it
>
> Finally, Luarocks stdout and sterr for each rock are logged into [7] for
> your convenience.
>
> The fixes will automatically propagate to ULua, should it concern you.
>
> Example, for the case of Copas:
> 1. Damn, it failed!
> 2. No errors here...
> 3. No errors here as well, who is to blame...
> 4. Me! I am depending on a never existed and never going to exist LuaSocket
> 2.1.
>
> What follows are my personal considerations around Luarocks and the Lua
> ecosystem, so if you are only interested in helping out improving the rocks
> you can stop reading here (links [*] at the end of this e-mail).
>
> So, the dependency for Copas is "luasocket >= 2.1" and Luarocks accepts
> 3.0-rc1.
> I personally find this reason for concern and not for relief (different
> major version, and it's not even a stable release!)
> The stated position [8] is 'no, "enforce semver to all rock authors!" is not
> possible'.
> Despite that, only a tiny minority of rocks has dependencies targeting a
> specific version (some do not list version requirements at all, I guess
> their maintainers have given up).
> Hence, lacking agreement on the meaning of numbers, any new rock can
> potentially wreak havoc. Yes, upgrades are not supported. But any rock that
> installs today maybe will not install tomorrow.
> I wonder how that is preferable to assuming semver and accepting that some
> modules do not follow it.
>
> More generally, the version format specification is documented [9] as
> "please look at the source code".
> Also, rocks which contend the same module but are unrelated (json4lua,
> luajson) are not rejected. All these details point to a 'lack of policy'
> which I find detrimental to the Lua ecosystem.
>
> This lack of policy has a much wider scope and has been popularised with the
> "mechanism not policies" phrase. I am fine on this idea being applied to the
> language itself.
> But in the specific context of modules/packages this mindset does not work.
> I am not referring to the lack of a module() function (which, as
> implemented, I am glad disappeared), but:
> + agreement on module responsibilities (no globals ever, ...)
> + agreement on version format, on its meaning, and on the module metadata
> + agreement on an extended standard library (*everything* IO included, ...)
> + agreement on Lua compile flags (what type is a number? which compat
> options? which conversion options? ...)
> + agreement on documentation and tests
>
> All this necessarily has to come from upstream. Yes, the Lua team blessing
> hand.
> Indeed, language-wise, Lua has been perfectly suited as a general purpose
> language since 5.0, that's 12 years ago, and as of today there are no
> satisfactory solutions to the points above nor a particularly healthy
> ecosystem.
> If the idea was "let's leave this to the community: a natural selection
> process will yield an optimal result", then it clearly has not worked.
>
> I am happy that Lua is light and customisable and that this contributes to
> its success in embedded systems and as a glue Language.
> It would be great if steps were taken to offer also a pleasing experience as
> a general-purpose programming language.
> This would take the form of a batteries-included version (side by side to
> the light version already available) plus answers to the +s above.
>
> Yes, I can use Python or Javascript. However I cannot help but notice that
> Lua is a preferable option both from a language and from an implementation
> perspective.
>
> Bests,
> Stefano
>
> --- the web --
> [1] http://www.scilua.org/ulua.html (a binary Lua distribution for Windows,
> OSX, Linux)
> [2] http://www.scilua.org/luarocksorg/state
> [3] http://www.scilua.org/luarocksorg/state/pass.lua
> [4] http://www.scilua.org/luarocksorg/state/error.lua
> [5]
> http://www.scilua.org/luarocksorg/state/target_os/target_arch/error_sys.lua
> [6]
> http://www.scilua.org/luarocksorg/state/target_os/target_arch/excluded_sys.lua
> [7] http://www.scilua.org/luarocksorg/state/target_os/target_arch/log
> [8] http://article.gmane.org/gmane.comp.lang.lua.general/112719
> [9] https://github.com/keplerproject/luarocks/wiki/Rockspec-format
>
>
>



--


Best regards,
Boris Nagaev

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Stefano
In reply to this post by Stefano
On 6 September 2015 at 21:58, Stefano <[hidden email]> wrote:

Sorry, forgot to mention this: in [5], [6], and [7] target_os and
target_arch need to be substituted with Windows/OSX/Linux and x86
respectively.
Please start browsing at [2] and go down the desired path.

Stefano

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Daurnimator
In reply to this post by Stefano
On 7 September 2015 at 06:58, Stefano <[hidden email]> wrote:

> Hi all,
>
> As part of my work on ULua [1], I routinely go through the task of trying to
> install the Lua rocks from luarocks.org (root manifest) on Windows, OSX and
> Linux.
>
> Problems include, but are not limited to:
> + rocks contending the same module name, who doesn't love 'json'?
> + rocks polluting the module namespace with generic names - anyone using
> 'test'? - worsening the problem above
> + missing supported OS and required external libraries specifications
> + no automated way of building such required external libraries
> + no standardised build tool: make, cmake, nmake, automake...just lake is
> missing!
> + builds which should work but fails in the most creative ways (I am easily
> amused)
> + wrong dependency requirements
>
> The exact three OS I have used are by no means esoteric:
> Windows7 64 + Visual Studio 2015
> Latest stable OSX + bundled Clang
> Ubuntu 10.04LTS + gcc 4.8
> It follows these problems are representative of the average user experience.
>
> Even libraries with a certain fame, like LuaSocket, are not immune to the
> above.
> Up to 2 months ago the latest LuaSocket stable version did not build on
> Windows/MinGW and required googling + manual patching of the rockspec (on a
> side note, for a couple of years before that it also injected globals and
> was incompatible with strict.lua and similar).
>
> Trying to improve this situation I would, as a first step, kindly ask for
> the cooperation of Lua rocks maintainers. Even if you don't care less about
> my project, you can still threat it as an automated build-test framework
> (stricter than Luarocks), which in a sense it is. All info is found at [2].
>
> More precisely, could you please:
>
> 1. Check wether your Lua rock pass or fail at [3]. If it pass, champagne!
> Otherwise...
>
> 2. Check wether it fails due to a platform-independent error (like
> contending the module name) at [4]. If so, please fix and celebrate
> accordingly. Otherwise...
>
> 3. Check wether it fails due to platform-dependent errors at [5]. If so,
> please fix and celebrate accordingly. If not...
>
> 4. It means your rock depends on something that is not available as can be
> seen at [6]. Please blame or blackmail whoever is responsible, or fix your
> broken dependency.
>
> You should *not* be concerned with two errors:
> 1. module_conflict errors in [4] that are due to multiple *related* rocks
> pointing to the same module (example: metalua-compiler and metalua-parser
> both contending the metalua module): these will be supported shortly
> 2. unsupported_external_library errors: I am not going to support these
> shortly (aside from selected libraries which I will package manually) but
> there is nothing that you can do about it
>
> Finally, Luarocks stdout and sterr for each rock are logged into [7] for
> your convenience.
>
> The fixes will automatically propagate to ULua, should it concern you.
>
> Example, for the case of Copas:
> 1. Damn, it failed!
> 2. No errors here...
> 3. No errors here as well, who is to blame...
> 4. Me! I am depending on a never existed and never going to exist LuaSocket
> 2.1.
>
> What follows are my personal considerations around Luarocks and the Lua
> ecosystem, so if you are only interested in helping out improving the rocks
> you can stop reading here (links [*] at the end of this e-mail).
>
> So, the dependency for Copas is "luasocket >= 2.1" and Luarocks accepts
> 3.0-rc1.
> I personally find this reason for concern and not for relief (different
> major version, and it's not even a stable release!)
> The stated position [8] is 'no, "enforce semver to all rock authors!" is not
> possible'.
> Despite that, only a tiny minority of rocks has dependencies targeting a
> specific version (some do not list version requirements at all, I guess
> their maintainers have given up).
> Hence, lacking agreement on the meaning of numbers, any new rock can
> potentially wreak havoc. Yes, upgrades are not supported. But any rock that
> installs today maybe will not install tomorrow.
> I wonder how that is preferable to assuming semver and accepting that some
> modules do not follow it.
>
> More generally, the version format specification is documented [9] as
> "please look at the source code".
> Also, rocks which contend the same module but are unrelated (json4lua,
> luajson) are not rejected. All these details point to a 'lack of policy'
> which I find detrimental to the Lua ecosystem.
>
> This lack of policy has a much wider scope and has been popularised with the
> "mechanism not policies" phrase. I am fine on this idea being applied to the
> language itself.
> But in the specific context of modules/packages this mindset does not work.
> I am not referring to the lack of a module() function (which, as
> implemented, I am glad disappeared), but:
> + agreement on module responsibilities (no globals ever, ...)
> + agreement on version format, on its meaning, and on the module metadata
> + agreement on an extended standard library (*everything* IO included, ...)
> + agreement on Lua compile flags (what type is a number? which compat
> options? which conversion options? ...)
> + agreement on documentation and tests
>
> All this necessarily has to come from upstream. Yes, the Lua team blessing
> hand.
> Indeed, language-wise, Lua has been perfectly suited as a general purpose
> language since 5.0, that's 12 years ago, and as of today there are no
> satisfactory solutions to the points above nor a particularly healthy
> ecosystem.
> If the idea was "let's leave this to the community: a natural selection
> process will yield an optimal result", then it clearly has not worked.
>
> I am happy that Lua is light and customisable and that this contributes to
> its success in embedded systems and as a glue Language.
> It would be great if steps were taken to offer also a pleasing experience as
> a general-purpose programming language.
> This would take the form of a batteries-included version (side by side to
> the light version already available) plus answers to the +s above.
>
> Yes, I can use Python or Javascript. However I cannot help but notice that
> Lua is a preferable option both from a language and from an implementation
> perspective.
>
> Bests,
> Stefano
>
> --- the web --
> [1] http://www.scilua.org/ulua.html (a binary Lua distribution for Windows,
> OSX, Linux)
> [2] http://www.scilua.org/luarocksorg/state
> [3] http://www.scilua.org/luarocksorg/state/pass.lua
> [4] http://www.scilua.org/luarocksorg/state/error.lua
> [5]
> http://www.scilua.org/luarocksorg/state/target_os/target_arch/error_sys.lua
> [6]
> http://www.scilua.org/luarocksorg/state/target_os/target_arch/excluded_sys.lua
> [7] http://www.scilua.org/luarocksorg/state/target_os/target_arch/log
> [8] http://article.gmane.org/gmane.comp.lang.lua.general/112719
> [9] https://github.com/keplerproject/luarocks/wiki/Rockspec-format
>
>
>

  - Looks like ULua only supports lua 5.1? this isn't mentioned
anywhere on your site
  - The list is hard to look through; could you make it more
browsable? e.g a table?
      - at least take out the unsupported_external_library errors
  - Seems like you don't handle multiple rockspecs under the one name
      - e.g. many of lhf's libraries have a different rockspec for
each lua version, and the version number is something like
2015-01-01.51 for lua 5.1
  - Module naming conflicts are hard to solve; all times I've run into
them the authors are uninterested/projects have been abandoned
      - https://github.com/keplerproject/luarocks/issues/388
      - https://github.com/zhaozg/lua-openssl/issues/72

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Sean Conner
In reply to this post by Stefano
It was thus said that the Great Stefano once stated:

> Hi all,
>
> As part of my work on ULua [1], I routinely go through the task of trying
> to install the Lua rocks from luarocks.org (root manifest) on Windows, OSX
> and Linux.
>
> Problems include, but are not limited to:
> + rocks contending the same module name, who doesn't love 'json'?
> + rocks polluting the module namespace with generic names - anyone using
> 'test'? - worsening the problem above
> + missing supported OS and required external libraries specifications
> + no automated way of building such required external libraries
> + no standardised build tool: make, cmake, nmake, automake...just lake is
> missing!
> + builds which should work but fails in the most creative ways (I am easily
> amused)
> + wrong dependency requirements

  Thanks for the work, but I'm having difficulty understanding the output
from all this.  For instance, I only found one of my modules [1] in the
Windows output [2] and while I would like to fix the issue, I don't [3]
use Windows, so I'm at a loss as to how to fix this issue:

env.c
env.c(44): warning C4273: '__p__environ': inconsistent dll linkage
C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\stdlib.h(1158): note: see previous definition of '__p__environ'
Microsoft (R) Incremental Linker Version 14.00.23026.0
Copyright (C) Microsoft Corporation.  All rights reserved.

   Creating library org/conman/env.lib and object org/conman/env.exp
Installing https://luarocks.org/org.conman.env-1.0.1-0.rockspec...
Using https://luarocks.org/org.conman.env-1.0.1-0.rockspec... switching to 'build' mode
cl /nologo /MD /O2 -c -Foenv.obj -IC:/ste/luarocks/2.2/include env.c
link -dll -def:env.def -out:org/conman/env.dll C:/ste/luarocks/2.2/lua51.lib env.obj
Updating manifest for C:/ste/luarockstree/lib/luarocks/rocks
org.conman.env 1.0.1-0 is now built and installed in C:/ste/luarockstree (license: LGPL)

  And that's one of the simpler modules!

  Another issue:  I'm checking the pass list [4] and I see this for two of
my modules:

  ["org.conman.env"] = {
    ["1.0.1-2"] = {
      Linux = {
        x86 = true
      },
      OSX = {
        x86 = true
      },
      Windows = {
        x86 = true
      }
    }
  },
  ["org.conman.errno"] = {
    ["1.0.1-2"] = {
      Linux = {
        x86 = false
      },
      OSX = {
        x86 = false
      },
      Windows = {
        x86 = false
      }
    }
  },

  Um ... did org.conman.errno pass?  Why is the Linux.x86 set to false?  I
*know* it compiled under Linux x86 as that's my main development system.  I
know it also compiles under 64-bit Linux as I use that at work.  I also know
it compiled under OS-X as I use that both at home and at work.  What am I
looking at?

  Under the error list [5] I see:

    ["org.conman.iconv"] = {
      ["1.1.0-1"] = {
        ICONV = {
          header = "iconv.h"
        }
      }
    },

  Okay ... apparently this failed ... for something ... somewhere ... I
guess.  I can't find any other mention of this module anywhere else.  But
under the Linux error_sys portion [6] I found my UUID module with the
following error:

    ["org.conman.uuid"] = {
      ["1.2.2-1"] = {
        stderr = {
          "Warning: skipping dependency checks.",
          "make: Warning: File `Makefile' has modification time 7.1e+08 s in the future",
          "src/luauuid.c:35:17: fatal error: lua.h: No such file or directory",
          " #include <lua.h>",
          "                 ^",
          "compilation terminated.",
          "make: *** [so/luauuid.o] Error 1",
          "",
          "Error: Build error: Failed building."
        },
        stdout = {
          "mkdir so",
          "mkdir lib",
          "gcc -std=c99 -O2 -fPIC -fPIC -c -o so/luauuid.o src/luauuid.c",
          "Installing https://rocks.moonscript.org/org.conman.uuid-1.2.2-1.src.rock...",
          "Using https://rocks.moonscript.org/org.conman.uuid-1.2.2-1.src.rock... switching to 'build' mode"
        }
      }
    },

lua.h not found?  What file should I include?  And it also failed under
OS-X [7] but *not* Windows? [8]

  My main issue with this is that I can't find any actionable items to fix.
I mean, okay, my Makefile has a modification time some 700,000,00 seconds in
the future?  No ... it's fine (both on my system and from a fresh checkout
from github).  Missing lua.h?  Should I be using lua-51.h?  lua51.h?  Should
I be passing /usr/local/include to the compiler?  Which of my modules
(listed here) passed?  How did org.conman.errno fail?  What was wrong with
org.conman.iconv?

  I've got too many questions to even start looking into my luarock modules.
And while I can fix the Linux and OS-X issues, I have no Windows systems [3]
nor do I understand that platform to fix issues there.  And I'm sure there
are people who can fix Windows issues but not OS-X or Linux.  

  -spc

[1] All the modules that start with org.conman are mine.

[2] http://www.scilua.org/luarocksorg/state/Windows/x86/log/

[3] More like "won't" but I digress

[4] http://www.scilua.org/luarocksorg/state/pass.lua

[5] http://www.scilua.org/luarocksorg/state/error.lua

[6] http://www.scilua.org/luarocksorg/state/Linux/x86/error_sys.lua

[7] http://www.scilua.org/luarocksorg/state/OSX/x86/error_sys.lua

[8] http://www.scilua.org/luarocksorg/state/Windows/x86/exclude_sys.lua

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Dirk Laurie-2
In reply to this post by Daurnimator
2015-09-07 3:10 GMT+02:00 Daurnimator <[hidden email]>:

>   - Looks like ULua only supports lua 5.1? this isn't mentioned
> anywhere on your site

Not even that. It comes with a binary called "lua" which issues the
following message when invoked:

LuaJIT 2.1.0-beta1 -- Copyright (C) 2005-2015 Mike Pall. http://luajit.org/
JIT: ON SSE2 SSE3 SSE4.1 fold cse dce fwd dse narrow loop abc sink fuse
>

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Dirk Laurie-2
In reply to this post by Stefano
2015-09-06 22:58 GMT+02:00 Stefano <[hidden email]>:

> Ubuntu 10.04LTS + gcc 4.8
> It follows these problems are representative of the average user experience.

The average Ubuntu user does not stick around with a release
that has gone out of support. From 12.04 on LTS means five years
of support, but 10.04 Desktop had only three years of support.

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Daurnimator
On 7 September 2015 at 16:25, Dirk Laurie <[hidden email]> wrote:
> 2015-09-06 22:58 GMT+02:00 Stefano <[hidden email]>:
>
>> Ubuntu 10.04LTS + gcc 4.8
>> It follows these problems are representative of the average user experience.
>
> The average Ubuntu user does not stick around with a release
> that has gone out of support. From 12.04 on LTS means five years
> of support, but 10.04 Desktop had only three years of support.
>

10.04 LTS only went out of support recently. See
https://wiki.ubuntu.com/LTS?action=AttachFile&do=get&target=ubuntu-release-cycle-2.png

Still. the average linux user does *not* use a >5 year old OS.

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Dirk Laurie-2
2015-09-07 8:45 GMT+02:00 Daurnimator <[hidden email]>:

> On 7 September 2015 at 16:25, Dirk Laurie <[hidden email]> wrote:
>> 2015-09-06 22:58 GMT+02:00 Stefano <[hidden email]>:
>>
>>> Ubuntu 10.04LTS + gcc 4.8
>>> It follows these problems are representative of the average user experience.
>>
>> The average Ubuntu user does not stick around with a release
>> that has gone out of support. From 12.04 on LTS means five years
>> of support, but 10.04 Desktop had only three years of support.
>>
>
> 10.04 LTS only went out of support recently. See
> https://wiki.ubuntu.com/LTS?action=AttachFile&do=get&target=ubuntu-release-cycle-2.png

That was the server version, not the desktop version.

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Stefano
In reply to this post by Daurnimator
On 7 September 2015 at 02:10, Daurnimator <[hidden email]> wrote:
>   - Looks like ULua only supports lua 5.1? this isn't mentioned
> anywhere on your site

Yes, it is based on LuaJIT which is compatible with Lua 5.1.
I do not have immediate plans to repeat the exercise for Lua 5.2 and
5.2, but if there is a enough request for this I might reconsider.

>   - The list is hard to look through; could you make it more
> browsable? e.g a table?

You are right, it is not optimal for human consumption (it is the
database used by automated build system).
I will pre-process it to make it more readable.

>       - at least take out the unsupported_external_library errors
>   - Seems like you don't handle multiple rockspecs under the one name
>       - e.g. many of lhf's libraries have a different rockspec for
> each lua version, and the version number is something like
> 2015-01-01.51 for lua 5.1

The build system should exclude specs which are for Lua 5.2 and above
and try to build the latest stable (and unstable if above the stable)
version for the same rock.
Can you please point me out to a specific rock where this it is not working?

>   - Module naming conflicts are hard to solve; all times I've run into
> them the authors are uninterested/projects have been abandoned
>       - https://github.com/keplerproject/luarocks/issues/388
>       - https://github.com/zhaozg/lua-openssl/issues/72

I can manually blacklist rocks.
As you have experience on the topic,  would you have suggestions
(based on my module conflicts) on which should be so?

Thank you for your feedback.

Stefano

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Stefano
In reply to this post by Dirk Laurie-2
On 7 September 2015 at 07:08, Dirk Laurie <[hidden email]> wrote:

> 2015-09-07 3:10 GMT+02:00 Daurnimator <[hidden email]>:
>
>>   - Looks like ULua only supports lua 5.1? this isn't mentioned
>> anywhere on your site
>
> Not even that. It comes with a binary called "lua" which issues the
> following message when invoked:
>
> LuaJIT 2.1.0-beta1 -- Copyright (C) 2005-2015 Mike Pall. http://luajit.org/
> JIT: ON SSE2 SSE3 SSE4.1 fold cse dce fwd dse narrow loop abc sink fuse

Surely you are not relying on the prompt message (which is
customisable even in Lua 5.1) for your programs to work.

I will make it clear it's 5.1 (that is evident from the homepage of my
website, but I gave you the direct link the ULua).

Stefano

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Stefano
In reply to this post by Dirk Laurie-2
On 7 September 2015 at 08:13, Dirk Laurie <[hidden email]> wrote:

> 2015-09-07 8:45 GMT+02:00 Daurnimator <[hidden email]>:
>> On 7 September 2015 at 16:25, Dirk Laurie <[hidden email]> wrote:
>>> 2015-09-06 22:58 GMT+02:00 Stefano <[hidden email]>:
>>>
>>>> Ubuntu 10.04LTS + gcc 4.8
>>>> It follows these problems are representative of the average user experience.
>>>
>>> The average Ubuntu user does not stick around with a release
>>> that has gone out of support. From 12.04 on LTS means five years
>>> of support, but 10.04 Desktop had only three years of support.
>>>
>>
>> 10.04 LTS only went out of support recently. See
>> https://wiki.ubuntu.com/LTS?action=AttachFile&do=get&target=ubuntu-release-cycle-2.png
>
> That was the server version, not the desktop version.
>

The use of an aged Linux distribution is a deliberate choice.

It is indeed the easiest way to have Linux binaries target a not too
recent version of libc, which in turn allows you to offer
compatibility with almost every existing Linux distribution currently
on the market.
The approach has been verified with the Linux Standard Base
Application Checker
(http://www.linuxfoundation.org/collaborate/workgroups/lsb/linux-application-checker-getting-started).

And I went thought the trouble of installing a reasonably recent
version of gcc (4.8.1).

Can you please point out to a specific rock where my distribution
choice turns out to be an issue?

Thanks

Stefano

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Philipp Janda
In reply to this post by Sean Conner
Am 07.09.2015 um 04:39 schröbte Sean Conner:

> But under the Linux error_sys portion [6] I found my UUID module with
> the following error:
>
>      ["org.conman.uuid"] = {
>        ["1.2.2-1"] = {
>          stderr = {
>            "Warning: skipping dependency checks.",
>            "make: Warning: File `Makefile' has modification time 7.1e+08 s in the future",
>            "src/luauuid.c:35:17: fatal error: lua.h: No such file or directory",
>            " #include <lua.h>",
>            "                 ^",
>            "compilation terminated.",
>            "make: *** [so/luauuid.o] Error 1",
>            "",
>            "Error: Build error: Failed building."
>          },
>          stdout = {
>            "mkdir so",
>            "mkdir lib",
>            "gcc -std=c99 -O2 -fPIC -fPIC -c -o so/luauuid.o src/luauuid.c",
>            "Installing https://rocks.moonscript.org/org.conman.uuid-1.2.2-1.src.rock...",
>            "Using https://rocks.moonscript.org/org.conman.uuid-1.2.2-1.src.rock... switching to 'build' mode"
>          }
>        }
>      },
>
> lua.h not found?  What file should I include?  And it also failed under
> OS-X [7] but *not* Windows? [8]

I can help with that one: Your compiler command line doesn't specify an
include directory for the Lua headers, so the rockspec/Makefile will
only work on machines where the Lua header files are installed in one of
the standard locations. It fails on machines running e.g. Debian/Ubuntu
which support multiple Lua versions by using include directories like
`/usr/include/lua5.1`. LuaRocks provides the `LUA_INCDIR` variable which
you can pass from the rockspec to your Makefile for setting the proper
include directory for the Lua header files ...

>
>    -spc

Philipp




Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Xpol Wan
There is few (fix me if I was wrong) luarocks module using cmake, my little rapidjson is one of them.

The error messages said:

Error: Build error: 'cmake' program not found. Is cmake installed? You may want to edit variables.CMAKE

Did the OSX and Linux build system have cmake installed?


On Mon, Sep 7, 2015 at 5:49 PM Philipp Janda <[hidden email]> wrote:
Am 07.09.2015 um 04:39 schröbte Sean Conner:

> But under the Linux error_sys portion [6] I found my UUID module with
> the following error:
>
>      ["org.conman.uuid"] = {
>        ["1.2.2-1"] = {
>          stderr = {
>            "Warning: skipping dependency checks.",
>            "make: Warning: File `Makefile' has modification time 7.1e+08 s in the future",
>            "src/luauuid.c:35:17: fatal error: lua.h: No such file or directory",
>            " #include <lua.h>",
>            "                 ^",
>            "compilation terminated.",
>            "make: *** [so/luauuid.o] Error 1",
>            "",
>            "Error: Build error: Failed building."
>          },
>          stdout = {
>            "mkdir so",
>            "mkdir lib",
>            "gcc -std=c99 -O2 -fPIC -fPIC -c -o so/luauuid.o src/luauuid.c",
>            "Installing https://rocks.moonscript.org/org.conman.uuid-1.2.2-1.src.rock...",
>            "Using https://rocks.moonscript.org/org.conman.uuid-1.2.2-1.src.rock... switching to 'build' mode"
>          }
>        }
>      },
>
> lua.h not found?  What file should I include?  And it also failed under
> OS-X [7] but *not* Windows? [8]

I can help with that one: Your compiler command line doesn't specify an
include directory for the Lua headers, so the rockspec/Makefile will
only work on machines where the Lua header files are installed in one of
the standard locations. It fails on machines running e.g. Debian/Ubuntu
which support multiple Lua versions by using include directories like
`/usr/include/lua5.1`. LuaRocks provides the `LUA_INCDIR` variable which
you can pass from the rockspec to your Makefile for setting the proper
include directory for the Lua header files ...

>
>    -spc

Philipp




Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Stefano
On 7 September 2015 at 14:17, Xpol Wan <[hidden email]> wrote:
> There is few (fix me if I was wrong) luarocks module using cmake, my little
> rapidjson is one of them.
>
> The error messages said:
>
>> Error: Build error: 'cmake' program not found. Is cmake installed? You may
>> want to edit variables.CMAKE
>
> Did the OSX and Linux build system have cmake installed?

I am aware of the issue, that's why I was being ironic about variety
of build system in my first e-mail...
I had cmake installed only on Windows, now it's installed on Linux and
OSX as well.

You rock now builds on Linux, but it still fails on Windows (Cmake
error) and OSX (compile error).
For your convenience I report below the errors.

Thanks for checking.

Stefano

--------- Windows ---------------
-- Building for: Visual Studio 14 2015
-- The C compiler identification is MSVC 19.0.23026.0
-- The CXX compiler identification is MSVC 19.0.23026.0
-- Check for working C compiler using: Visual Studio 14 2015
-- Check for working C compiler using: Visual Studio 14 2015 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 14 2015
-- Check for working CXX compiler using: Visual Studio 14 2015 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
Using LUALIB:C:/ste/luarocks/2.2lua51.lib
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/sp/AppData/Local/Temp/luarocks_rap
idjson-0.2.1-1-218/rapidjson/build.luarocks
Microsoft (R) Build Engine version 14.0.23107.0
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 9/7/2015 7:03:47 PM.
Project "C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218\rapidjso
n\build.luarocks\ALL_BUILD.vcxproj" on node 1 (default targets).
Project "C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218\rapidjso
n\build.luarocks\ALL_BUILD.vcxproj" (1) is building "C:\Users\sp\AppData\Local\
Temp\luarocks_rapidjson-0.2.1-1-218\rapidjson\build.luarocks\ZERO_CHECK.vcxproj
" (2) on node 1 (default targets).
PrepareForBuild:
  Creating directory "Win32\Release\ZERO_CHECK\".
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targe
ts(400,5): warning MSB8029: The Intermediate directory or Output directory cann
ot reside under the Temporary directory as it could lead to issues with increme
ntal build. [C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218\rapi
djson\build.luarocks\ZERO_CHECK.vcxproj]
  Creating directory "C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1
  -218\rapidjson\build.luarocks\Release\".
  Creating directory "Win32\Release\ZERO_CHECK\ZERO_CHECK.tlog\".
InitializeBuildStatus:
  Creating "Win32\Release\ZERO_CHECK\ZERO_CHECK.tlog\unsuccessfulbuild" because
   "AlwaysCreate" was specified.
CustomBuild:
  Checking Build System
  CMake does not need to re-run because C:/Users/sp/AppData/Local/Temp/luarocks
  _rapidjson-0.2.1-1-218/rapidjson/build.luarocks/CMakeFiles/generate.stamp is
  up-to-date.
FinalizeBuildStatus:
  Deleting file "Win32\Release\ZERO_CHECK\ZERO_CHECK.tlog\unsuccessfulbuild".
  Touching "Win32\Release\ZERO_CHECK\ZERO_CHECK.tlog\ZERO_CHECK.lastbuildstate"
  .
Done Building Project "C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-
1-218\rapidjson\build.luarocks\ZERO_CHECK.vcxproj" (default targets).

Project "C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218\rapidjso
n\build.luarocks\ALL_BUILD.vcxproj" (1) is building "C:\Users\sp\AppData\Local\
Temp\luarocks_rapidjson-0.2.1-1-218\rapidjson\build.luarocks\json.vcxproj" (3)
on node 1 (default targets).
PrepareForBuild:
  Creating directory "json.dir\Release\".
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targe
ts(400,5): warning MSB8029: The Intermediate directory or Output directory cann
ot reside under the Temporary directory as it could lead to issues with increme
ntal build. [C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218\rapi
djson\build.luarocks\json.vcxproj]
  Creating directory "json.dir\Release\json.tlog\".
InitializeBuildStatus:
  Creating "json.dir\Release\json.tlog\unsuccessfulbuild" because "AlwaysCreate
  " was specified.
CustomBuild:
  Building Custom Rule C:/Users/sp/AppData/Local/Temp/luarocks_rapidjson-0.2.1-
  1-218/rapidjson/CMakeLists.txt
  CMake does not need to re-run because C:\Users\sp\AppData\Local\Temp\luarocks
  _rapidjson-0.2.1-1-218\rapidjson\build.luarocks\CMakeFiles\generate.stamp is
  up-to-date.
ClCompile:
  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\CL.exe /c /IC:\ste
  \luarocks\2.2\include /I"C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.
  2.1-1-218\rapidjson\rapidjson\include" /nologo /W3 /WX- /O2 /Ob2 /Oy- /D WIN3
  2 /D _WINDOWS /D NDEBUG /D "LUA_RAPIDJSON_VERSION=\"0.2.1-1\"" /D LUA_BUILD_A
  S_DLL /D LUA_LIB /D "CMAKE_INTDIR=\"Release\"" /D json_EXPORTS /D _WINDLL /D
  _MBCS /Gm- /EHsc /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /GR
  /Fo"json.dir\Release\\" /Fd"json.dir\Release\vc140.pdb" /Gd /TP /analyze- /er
  rorReport:queue "C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-21
  8\rapidjson\src\rapidjson.cpp"
  rapidjson.cpp
Link:
  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe /ERRORREP
  ORT:QUEUE /OUT:"C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218
  \rapidjson\build.luarocks\Release\rapidjson.dll" /INCREMENTAL:NO /NOLOGO kern
  el32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib
   uuid.lib comdlg32.lib advapi32.lib C:\ste\luarocks\2.2lua51.lib /MANIFEST /M
  ANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:"C:/User
  s/sp/AppData/Local/Temp/luarocks_rapidjson-0.2.1-1-218/rapidjson/build.luaroc
  ks/Release/rapidjson.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT
  /IMPLIB:"C:/Users/sp/AppData/Local/Temp/luarocks_rapidjson-0.2.1-1-218/rapidj
  son/build.luarocks/Release/rapidjson.lib" /MACHINE:X86 /SAFESEH  /machine:X86
   /DLL json.dir\Release\rapidjson.obj
LINK : fatal error LNK1181: cannot open input file 'C:\ste\luarocks\2.2lua51.li
b' [C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218\rapidjson\bui
ld.luarocks\json.vcxproj]
Done Building Project "C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-
1-218\rapidjson\build.luarocks\json.vcxproj" (default targets) -- FAILED.

Done Building Project "C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-
1-218\rapidjson\build.luarocks\ALL_BUILD.vcxproj" (default targets) -- FAILED.


Build FAILED.

"C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218\rapidjson\build.
luarocks\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218\rapidjson\build.
luarocks\ZERO_CHECK.vcxproj" (default target) (2) ->
(PrepareForBuild target) ->
  C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.tar
gets(400,5): warning MSB8029: The Intermediate directory or Output directory ca
nnot reside under the Temporary directory as it could lead to issues with incre
mental build. [C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218\ra
pidjson\build.luarocks\ZERO_CHECK.vcxproj]


"C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218\rapidjson\build.
luarocks\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218\rapidjson\build.
luarocks\json.vcxproj" (default target) (3) ->
  C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.tar
gets(400,5): warning MSB8029: The Intermediate directory or Output directory ca
nnot reside under the Temporary directory as it could lead to issues with incre
mental build. [C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218\ra
pidjson\build.luarocks\json.vcxproj]


"C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218\rapidjson\build.
luarocks\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218\rapidjson\build.
luarocks\json.vcxproj" (default target) (3) ->
(Link target) ->
  LINK : fatal error LNK1181: cannot open input file 'C:\ste\luarocks\2.2lua51.
lib' [C:\Users\sp\AppData\Local\Temp\luarocks_rapidjson-0.2.1-1-218\rapidjson\b
uild.luarocks\json.vcxproj]

    2 Warning(s)
    1 Error(s)

Time Elapsed 00:00:01.99

Error: Build error: Failed building.

---------- OSX ----------------------
Warning: skipping dependency checks.
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:469:16:
error: implicit instantiation of undefined template
'std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >'
                        std::string s("can't encode ");
                                    ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/iosfwd:188:33:
note: template is declared here
    class _LIBCPP_TYPE_VIS_ONLY basic_string;
                                ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:572:14:
error: no matching member function for call to 'encodeValue'
                        bool ok = encodeValue(L, writer, -1);
                                  ^~~~~~~~~~~
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:484:5:
note: in instantiation of function template specialization
'Encoder::encodeArray<rapidjson::PrettyWriter<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                                encodeArray(L, writer) :
                                ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:455:11:
note: in instantiation of function template specialization
'Encoder::encodeTable<rapidjson::PrettyWriter<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                        return encodeTable(L, writer, -1);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:588:11:
note: in instantiation of function template specialization
'Encoder::encodeValue<rapidjson::PrettyWriter<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                        return encodeValue(L, &writer, idx);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:605:14:
note: in instantiation of function template specialization
'Encoder::encode<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator> >' requested here
        if (!encode.encode(L, &s, 1))
                    ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:432:7:
note: candidate template ignored: substitution failure [with Writer =
rapidjson::PrettyWriter<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator>]
        bool encodeValue(lua_State* L, Writer* writer, int idx)
             ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:525:14:
error: no matching member function for call to 'encodeValue'
                        bool ok = encodeValue(L, writer, -2);
                                  ^~~~~~~~~~~
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:485:5:
note: in instantiation of function template specialization
'Encoder::encodeObject<rapidjson::PrettyWriter<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                                encodeObject(L, writer);
                                ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:455:11:
note: in instantiation of function template specialization
'Encoder::encodeTable<rapidjson::PrettyWriter<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                        return encodeTable(L, writer, -1);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:588:11:
note: in instantiation of function template specialization
'Encoder::encodeValue<rapidjson::PrettyWriter<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                        return encodeValue(L, &writer, idx);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:605:14:
note: in instantiation of function template specialization
'Encoder::encode<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator> >' requested here
        if (!encode.encode(L, &s, 1))
                    ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:432:7:
note: candidate template ignored: substitution failure [with Writer =
rapidjson::PrettyWriter<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator>]
        bool encodeValue(lua_State* L, Writer* writer, int idx)
             ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:553:14:
error: no matching member function for call to 'encodeValue'
                        bool ok = encodeValue(L, writer, -1);
                                  ^~~~~~~~~~~
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:506:4:
note: in instantiation of function template specialization
'Encoder::encodeObject<rapidjson::PrettyWriter<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                        encodeObject(L, writer, keys);
                        ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:455:11:
note: in instantiation of function template specialization
'Encoder::encodeTable<rapidjson::PrettyWriter<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                        return encodeTable(L, writer, -1);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:588:11:
note: in instantiation of function template specialization
'Encoder::encodeValue<rapidjson::PrettyWriter<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                        return encodeValue(L, &writer, idx);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:605:14:
note: in instantiation of function template specialization
'Encoder::encode<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator> >' requested here
        if (!encode.encode(L, &s, 1))
                    ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:432:7:
note: candidate template ignored: substitution failure [with Writer =
rapidjson::PrettyWriter<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator>]
        bool encodeValue(lua_State* L, Writer* writer, int idx)
             ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:572:14:
error: no matching member function for call to 'encodeValue'
                        bool ok = encodeValue(L, writer, -1);
                                  ^~~~~~~~~~~
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:484:5:
note: in instantiation of function template specialization
'Encoder::encodeArray<rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                                encodeArray(L, writer) :
                                ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:455:11:
note: in instantiation of function template specialization
'Encoder::encodeTable<rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                        return encodeTable(L, writer, -1);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:593:11:
note: in instantiation of function template specialization
'Encoder::encodeValue<rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                        return encodeValue(L, &writer, idx);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:605:14:
note: in instantiation of function template specialization
'Encoder::encode<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator> >' requested here
        if (!encode.encode(L, &s, 1))
                    ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:432:7:
note: candidate template ignored: substitution failure [with Writer =
rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator>]
        bool encodeValue(lua_State* L, Writer* writer, int idx)
             ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:525:14:
error: no matching member function for call to 'encodeValue'
                        bool ok = encodeValue(L, writer, -2);
                                  ^~~~~~~~~~~
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:485:5:
note: in instantiation of function template specialization
'Encoder::encodeObject<rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                                encodeObject(L, writer);
                                ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:455:11:
note: in instantiation of function template specialization
'Encoder::encodeTable<rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                        return encodeTable(L, writer, -1);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:593:11:
note: in instantiation of function template specialization
'Encoder::encodeValue<rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                        return encodeValue(L, &writer, idx);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:605:14:
note: in instantiation of function template specialization
'Encoder::encode<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator> >' requested here
        if (!encode.encode(L, &s, 1))
                    ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:432:7:
note: candidate template ignored: substitution failure [with Writer =
rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator>]
        bool encodeValue(lua_State* L, Writer* writer, int idx)
             ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:553:14:
error: no matching member function for call to 'encodeValue'
                        bool ok = encodeValue(L, writer, -1);
                                  ^~~~~~~~~~~
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:506:4:
note: in instantiation of function template specialization
'Encoder::encodeObject<rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                        encodeObject(L, writer, keys);
                        ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:455:11:
note: in instantiation of function template specialization
'Encoder::encodeTable<rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                        return encodeTable(L, writer, -1);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:593:11:
note: in instantiation of function template specialization
'Encoder::encodeValue<rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator> >' requested here
                        return encodeValue(L, &writer, idx);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:605:14:
note: in instantiation of function template specialization
'Encoder::encode<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator> >' requested here
        if (!encode.encode(L, &s, 1))
                    ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:432:7:
note: candidate template ignored: substitution failure [with Writer =
rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>,
rapidjson::CrtAllocator>, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator>]
        bool encodeValue(lua_State* L, Writer* writer, int idx)
             ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:572:14:
error: no matching member function for call to 'encodeValue'
                        bool ok = encodeValue(L, writer, -1);
                                  ^~~~~~~~~~~
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:484:5:
note: in instantiation of function template specialization
'Encoder::encodeArray<rapidjson::PrettyWriter<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                                encodeArray(L, writer) :
                                ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:455:11:
note: in instantiation of function template specialization
'Encoder::encodeTable<rapidjson::PrettyWriter<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                        return encodeTable(L, writer, -1);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:588:11:
note: in instantiation of function template specialization
'Encoder::encodeValue<rapidjson::PrettyWriter<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                        return encodeValue(L, &writer, idx);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:632:20:
note: in instantiation of function template specialization
'Encoder::encode<rapidjson::FileWriteStream>' requested here
        bool ok = encoder.encode(L, &fs, 1);
                          ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:432:7:
note: candidate template ignored: substitution failure [with Writer =
rapidjson::PrettyWriter<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>,
rapidjson::CrtAllocator>]
        bool encodeValue(lua_State* L, Writer* writer, int idx)
             ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:525:14:
error: no matching member function for call to 'encodeValue'
                        bool ok = encodeValue(L, writer, -2);
                                  ^~~~~~~~~~~
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:485:5:
note: in instantiation of function template specialization
'Encoder::encodeObject<rapidjson::PrettyWriter<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                                encodeObject(L, writer);
                                ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:455:11:
note: in instantiation of function template specialization
'Encoder::encodeTable<rapidjson::PrettyWriter<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                        return encodeTable(L, writer, -1);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:588:11:
note: in instantiation of function template specialization
'Encoder::encodeValue<rapidjson::PrettyWriter<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                        return encodeValue(L, &writer, idx);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:632:20:
note: in instantiation of function template specialization
'Encoder::encode<rapidjson::FileWriteStream>' requested here
        bool ok = encoder.encode(L, &fs, 1);
                          ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:432:7:
note: candidate template ignored: substitution failure [with Writer =
rapidjson::PrettyWriter<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>,
rapidjson::CrtAllocator>]
        bool encodeValue(lua_State* L, Writer* writer, int idx)
             ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:553:14:
error: no matching member function for call to 'encodeValue'
                        bool ok = encodeValue(L, writer, -1);
                                  ^~~~~~~~~~~
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:506:4:
note: in instantiation of function template specialization
'Encoder::encodeObject<rapidjson::PrettyWriter<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                        encodeObject(L, writer, keys);
                        ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:455:11:
note: in instantiation of function template specialization
'Encoder::encodeTable<rapidjson::PrettyWriter<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                        return encodeTable(L, writer, -1);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:588:11:
note: in instantiation of function template specialization
'Encoder::encodeValue<rapidjson::PrettyWriter<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                        return encodeValue(L, &writer, idx);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:632:20:
note: in instantiation of function template specialization
'Encoder::encode<rapidjson::FileWriteStream>' requested here
        bool ok = encoder.encode(L, &fs, 1);
                          ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:432:7:
note: candidate template ignored: substitution failure [with Writer =
rapidjson::PrettyWriter<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>,
rapidjson::CrtAllocator>]
        bool encodeValue(lua_State* L, Writer* writer, int idx)
             ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:572:14:
error: no matching member function for call to 'encodeValue'
                        bool ok = encodeValue(L, writer, -1);
                                  ^~~~~~~~~~~
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:484:5:
note: in instantiation of function template specialization
'Encoder::encodeArray<rapidjson::Writer<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                                encodeArray(L, writer) :
                                ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:455:11:
note: in instantiation of function template specialization
'Encoder::encodeTable<rapidjson::Writer<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                        return encodeTable(L, writer, -1);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:593:11:
note: in instantiation of function template specialization
'Encoder::encodeValue<rapidjson::Writer<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                        return encodeValue(L, &writer, idx);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:632:20:
note: in instantiation of function template specialization
'Encoder::encode<rapidjson::FileWriteStream>' requested here
        bool ok = encoder.encode(L, &fs, 1);
                          ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:432:7:
note: candidate template ignored: substitution failure [with Writer =
rapidjson::Writer<rapidjson::FileWriteStream, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator>]
        bool encodeValue(lua_State* L, Writer* writer, int idx)
             ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:525:14:
error: no matching member function for call to 'encodeValue'
                        bool ok = encodeValue(L, writer, -2);
                                  ^~~~~~~~~~~
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:485:5:
note: in instantiation of function template specialization
'Encoder::encodeObject<rapidjson::Writer<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                                encodeObject(L, writer);
                                ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:455:11:
note: in instantiation of function template specialization
'Encoder::encodeTable<rapidjson::Writer<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                        return encodeTable(L, writer, -1);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:593:11:
note: in instantiation of function template specialization
'Encoder::encodeValue<rapidjson::Writer<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                        return encodeValue(L, &writer, idx);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:632:20:
note: in instantiation of function template specialization
'Encoder::encode<rapidjson::FileWriteStream>' requested here
        bool ok = encoder.encode(L, &fs, 1);
                          ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:432:7:
note: candidate template ignored: substitution failure [with Writer =
rapidjson::Writer<rapidjson::FileWriteStream, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator>]
        bool encodeValue(lua_State* L, Writer* writer, int idx)
             ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:553:14:
error: no matching member function for call to 'encodeValue'
                        bool ok = encodeValue(L, writer, -1);
                                  ^~~~~~~~~~~
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:506:4:
note: in instantiation of function template specialization
'Encoder::encodeObject<rapidjson::Writer<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                        encodeObject(L, writer, keys);
                        ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:455:11:
note: in instantiation of function template specialization
'Encoder::encodeTable<rapidjson::Writer<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                        return encodeTable(L, writer, -1);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:593:11:
note: in instantiation of function template specialization
'Encoder::encodeValue<rapidjson::Writer<rapidjson::FileWriteStream,
rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>
>' requested here
                        return encodeValue(L, &writer, idx);
                               ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:632:20:
note: in instantiation of function template specialization
'Encoder::encode<rapidjson::FileWriteStream>' requested here
        bool ok = encoder.encode(L, &fs, 1);
                          ^
/tmp/luarocks_rapidjson-0.2.1-1-5543/rapidjson/src/rapidjson.cpp:432:7:
note: candidate template ignored: substitution failure [with Writer =
rapidjson::Writer<rapidjson::FileWriteStream, rapidjson::UTF8<char>,
rapidjson::UTF8<char>, rapidjson::CrtAllocator>]
        bool encodeValue(lua_State* L, Writer* writer, int idx)
             ^
13 errors generated.
make[2]: *** [CMakeFiles/json.dir/src/rapidjson.cpp.o] Error 1
make[1]: *** [CMakeFiles/json.dir/all] Error 2
make: *** [all] Error 2

Error: Build error: Failed building.

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Stefano
In reply to this post by Sean Conner
On 7 September 2015 at 03:39, Sean Conner <[hidden email]> wrote:

>   Thanks for the work, but I'm having difficulty understanding the output
> from all this.  For instance, I only found one of my modules [1] in the
> Windows output [2] and while I would like to fix the issue, I don't [3]
> use Windows, so I'm at a loss as to how to fix this issue:
>
> env.c
> env.c(44): warning C4273: '__p__environ': inconsistent dll linkage
> C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\stdlib.h(1158): note: see previous definition of '__p__environ'
> Microsoft (R) Incremental Linker Version 14.00.23026.0
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
>    Creating library org/conman/env.lib and object org/conman/env.exp
> Installing https://luarocks.org/org.conman.env-1.0.1-0.rockspec...
> Using https://luarocks.org/org.conman.env-1.0.1-0.rockspec... switching to 'build' mode
> cl /nologo /MD /O2 -c -Foenv.obj -IC:/ste/luarocks/2.2/include env.c
> link -dll -def:env.def -out:org/conman/env.dll C:/ste/luarocks/2.2/lua51.lib env.obj
> Updating manifest for C:/ste/luarockstree/lib/luarocks/rocks
> org.conman.env 1.0.1-0 is now built and installed in C:/ste/luarockstree (license: LGPL)

That is just a warning, it builds fine (see below).
If you are concerned please send me privately a test and I can run on
my Windows VM.

>
>   And that's one of the simpler modules!
>
>   Another issue:  I'm checking the pass list [4] and I see this for two of
> my modules:
>
>   ["org.conman.env"] = {
>     ["1.0.1-2"] = {
>       Linux = {
>         x86 = true
>       },
>       OSX = {
>         x86 = true
>       },
>       Windows = {
>         x86 = true
>       }
>     }
>   },
>   ["org.conman.errno"] = {
>     ["1.0.1-2"] = {
>       Linux = {
>         x86 = false
>       },
>       OSX = {
>         x86 = false
>       },
>       Windows = {
>         x86 = false
>       }
>     }
>   },
>
>   Um ... did org.conman.errno pass?  Why is the Linux.x86 set to false?  I
> *know* it compiled under Linux x86 as that's my main development system.  I
> know it also compiles under 64-bit Linux as I use that at work.  I also know
> it compiled under OS-X as I use that both at home and at work.  What am I
> looking at?

Nope.
The rock org.conman.env passed on all 3 platforms.
The rock org.conman.errno did not pass on any.

The reason is found immediately looking at
http://www.scilua.org/luarocksorg/state/error.lua

There is a module conflict (org module name).
I am aware in this case it's a module intentionally splitted among
multiple rocks and I am going to support this case shortly. So nothing
for you to worry about.
(side note: I am not convinced on the need to break-up modules in
multiple rocks, considering their tiny size, but I can live with
that).

>
>   Under the error list [5] I see:
>
>     ["org.conman.iconv"] = {
>       ["1.1.0-1"] = {
>         ICONV = {
>           header = "iconv.h"
>         }
>       }
>     },
>
>   Okay ... apparently this failed ... for something ... somewhere ... I
> guess.  I can't find any other mention of this module anywhere else.  But
> under the Linux error_sys portion [6] I found my UUID module with the
> following error:
>
>     ["org.conman.uuid"] = {
>       ["1.2.2-1"] = {
>         stderr = {
>           "Warning: skipping dependency checks.",
>           "make: Warning: File `Makefile' has modification time 7.1e+08 s in the future",
>           "src/luauuid.c:35:17: fatal error: lua.h: No such file or directory",
>           " #include <lua.h>",
>           "                 ^",
>           "compilation terminated.",
>           "make: *** [so/luauuid.o] Error 1",
>           "",
>           "Error: Build error: Failed building."
>         },
>         stdout = {
>           "mkdir so",
>           "mkdir lib",
>           "gcc -std=c99 -O2 -fPIC -fPIC -c -o so/luauuid.o src/luauuid.c",
>           "Installing https://rocks.moonscript.org/org.conman.uuid-1.2.2-1.src.rock...",
>           "Using https://rocks.moonscript.org/org.conman.uuid-1.2.2-1.src.rock... switching to 'build' mode"
>         }
>       }
>     },
>
> lua.h not found?  What file should I include?  And it also failed under
> OS-X [7] but *not* Windows? [8]
>
>   My main issue with this is that I can't find any actionable items to fix.
> I mean, okay, my Makefile has a modification time some 700,000,00 seconds in
> the future?  No ... it's fine (both on my system and from a fresh checkout
> from github).  Missing lua.h?  Should I be using lua-51.h?  lua51.h?  Should
> I be passing /usr/local/include to the compiler?  Which of my modules
> (listed here) passed?  How did org.conman.errno fail?  What was wrong with
> org.conman.iconv?
>
>   I've got too many questions to even start looking into my luarock modules.
> And while I can fix the Linux and OS-X issues, I have no Windows systems [3]
> nor do I understand that platform to fix issues there.  And I'm sure there
> are people who can fix Windows issues but not OS-X or Linux.

Philipp already replied to the lua.h issue (thanks!), I answered the
reaming questions.
The best I can do is to provide you with the full stderr and stout
outputs from Luarocks: this is what you would get if you were to try
to install the rock yourself on a Windows machine. I am not sure how I
can improve on this short of giving you ssh access to a Windows VM.

Please let me know if I can help further.

Bests,
Stefano

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Sean Conner
It was thus said that the Great Stefano once stated:

> On 7 September 2015 at 03:39, Sean Conner <[hidden email]> wrote:
> >   Thanks for the work, but I'm having difficulty understanding the output
> > from all this.  For instance, I only found one of my modules [1] in the
> > Windows output [2] and while I would like to fix the issue, I don't [3]
> > use Windows, so I'm at a loss as to how to fix this issue:
> >
> > env.c
> > env.c(44): warning C4273: '__p__environ': inconsistent dll linkage
> > C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\stdlib.h(1158): note: see previous definition of '__p__environ'
> > Microsoft (R) Incremental Linker Version 14.00.23026.0
> > Copyright (C) Microsoft Corporation.  All rights reserved.
> >
> >    Creating library org/conman/env.lib and object org/conman/env.exp
> > Installing https://luarocks.org/org.conman.env-1.0.1-0.rockspec...
> > Using https://luarocks.org/org.conman.env-1.0.1-0.rockspec... switching to 'build' mode
> > cl /nologo /MD /O2 -c -Foenv.obj -IC:/ste/luarocks/2.2/include env.c
> > link -dll -def:env.def -out:org/conman/env.dll C:/ste/luarocks/2.2/lua51.lib env.obj
> > Updating manifest for C:/ste/luarockstree/lib/luarocks/rocks
> > org.conman.env 1.0.1-0 is now built and installed in C:/ste/luarockstree (license: LGPL)
>
> That is just a warning, it builds fine (see below).
> If you are concerned please send me privately a test and I can run on
> my Windows VM.

  It may build fine, but does it *run*?  This modules just populates a Lua
table with all the environment variables in the process.  Under Unix, you
can get an array of all the environment variables two ways---one as an
additional parameter to main()

        int main(int argc,char *argv[],char *envp[])

and the second way is through an external variable:

        extern char **environ;

  I read the error above (and I'm guessing, since I don't use Windows, nor
do I know the programming environment) that I *might* not get the extern
environ variable at run time, or if I do, I might not get the one I'm
expecting.

> >   Another issue:  I'm checking the pass list [4] and I see this for two of
> > my modules:
> >
> >   ["org.conman.env"] = {
> >     ["1.0.1-2"] = {
> >       Linux = {
> >         x86 = true
> >       },
> >       OSX = {
> >         x86 = true
> >       },
> >       Windows = {
> >         x86 = true
> >       }
> >     }
> >   },
> >   ["org.conman.errno"] = {
> >     ["1.0.1-2"] = {
> >       Linux = {
> >         x86 = false
> >       },
> >       OSX = {
> >         x86 = false
> >       },
> >       Windows = {
> >         x86 = false
> >       }
> >     }
> >   },
> >
> >   Um ... did org.conman.errno pass?  Why is the Linux.x86 set to false?  I
> > *know* it compiled under Linux x86 as that's my main development system.  I
> > know it also compiles under 64-bit Linux as I use that at work.  I also know
> > it compiled under OS-X as I use that both at home and at work.  What am I
> > looking at?
>
> Nope.
> The rock org.conman.env passed on all 3 platforms.
> The rock org.conman.errno did not pass on any.

  <nitpick>Then why is org.conman.errno included in the "pass"
list?</nitpick>

> The reason is found immediately looking at
> http://www.scilua.org/luarocksorg/state/error.lua

  <nitpick>It may be obvious to you, but it wasn't to me.</nitpick>

> There is a module conflict (org module name).
> I am aware in this case it's a module intentionally splitted among
> multiple rocks and I am going to support this case shortly. So nothing
> for you to worry about.
> (side note: I am not convinced on the need to break-up modules in
> multiple rocks, considering their tiny size, but I can live with
> that).

  Ah.  Your mistake here is assuming that "org.conman.errno" is a submodule
of "org".  That is not the case here.  Each of my modules are (with one
exception) independent of each other and all can be used by themselves.
What I *am* doing is namespacing my modules.  There are several Lua modules
that wrap syslog().  There are several Lua modules that wrap sockets.  There
are several Lua modules that wrap POSIX filesystem calls.  There are several
Lua modules that wrap the signal() function.  Instead of creating some
oddball bame like "spcsignal" or "conmansyslog" I opted instead to pull them
all under a common namespace, based off my primary DNS domain name. [1]

> >   I've got too many questions to even start looking into my luarock modules.
> > And while I can fix the Linux and OS-X issues, I have no Windows systems [3]
> > nor do I understand that platform to fix issues there.  And I'm sure there
> > are people who can fix Windows issues but not OS-X or Linux.
>
> Philipp already replied to the lua.h issue (thanks!), I answered the
> reaming questions.
> The best I can do is to provide you with the full stderr and stout
> outputs from Luarocks: this is what you would get if you were to try
> to install the rock yourself on a Windows machine. I am not sure how I
> can improve on this short of giving you ssh access to a Windows VM.
>
> Please let me know if I can help further.

  It wouldn't help in my case.  I don't do development under Windows; I
don't know the development environment so even if I had access, I wouldn't
know how to fix the issue.

  -spc

[1] There are some that don't like my choice of namespace, but I feel
        it's better than nothing.

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Sean Conner
In reply to this post by Stefano
It was thus said that the Great Stefano once stated:

> On 7 September 2015 at 03:39, Sean Conner <[hidden email]> wrote:
> >   Thanks for the work, but I'm having difficulty understanding the output
> > from all this.  For instance, I only found one of my modules [1] in the
> > Windows output [2] and while I would like to fix the issue, I don't [3]
> > use Windows, so I'm at a loss as to how to fix this issue:
> >
> > env.c
> > env.c(44): warning C4273: '__p__environ': inconsistent dll linkage
> > C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\stdlib.h(1158): note: see previous definition of '__p__environ'
> > Microsoft (R) Incremental Linker Version 14.00.23026.0
> > Copyright (C) Microsoft Corporation.  All rights reserved.
> >
> >    Creating library org/conman/env.lib and object org/conman/env.exp
> > Installing https://luarocks.org/org.conman.env-1.0.1-0.rockspec...
> > Using https://luarocks.org/org.conman.env-1.0.1-0.rockspec... switching to 'build' mode
> > cl /nologo /MD /O2 -c -Foenv.obj -IC:/ste/luarocks/2.2/include env.c
> > link -dll -def:env.def -out:org/conman/env.dll C:/ste/luarocks/2.2/lua51.lib env.obj
> > Updating manifest for C:/ste/luarockstree/lib/luarocks/rocks
> > org.conman.env 1.0.1-0 is now built and installed in C:/ste/luarockstree (license: LGPL)
>
> That is just a warning, it builds fine (see below).
> If you are concerned please send me privately a test and I can run on
> my Windows VM.

  I'm going to try to clarify my thoughts on this.  I work exclusively under
Unix [1].  If there's an issue with Unix, I know enough to fix the issue,
even under less used Unix system [2].  If a Windows user can use the code,
that's great, but if any issues come up, I can't fix them.

  The closest I've come to programming under Windows is OS/2, and that was
OS/2 1.x back in 1990.  I've used Windows and I can puzzle my way around a
Windows system as a user, but not as a programmer.  And honestly, I can't
remember the last time I actually *used* a Windows system for any length of
time (I know I used one regularly for several months back in 1997 but past
that ... ).

  That doesn't mean I can't offer some theories as to the issues (like the
one above).  Just from "inconsistent dll linkage" and "previous definition
of '__p_environ' I can gather that there was no issue with compilation but
with linking the final output to make it run, and that there stands a better
than even chance of some runtime issue happening.  I can even make some
reasonable predictions as to the outcome:  it won't run; it'll crash; it'll
print out gibberish; it may even work on your system but not another one.

  But I don't know enough about the Windows environment [7] to even come up
with a valid test.  Sure, I can provide some code:

        env = require "org.conman.env"
        for name,val in pairs(env) do
                print(name,val)
        end

but that's not a full test.  That will get you to the "it'll print out
gibberish; it may even work on your system" test.  Writing a test requires
knowledge of the expected output, and for Windows, I don't know what to even
expect for a typical environment.  For Windows, I have to depend on a
Windows programmer to fix the problem and push a patch my way (and hack, I
would welcome that!).  And if the fix isn't too onerous I'll accept it [8].
But I have to trust the source that this does indeed, fix the problem.

  You might be thinking that I'm harping on the Windows angle too much, and
yes, I'll cop to that, but it's indicative of a larger issue---I'm sure
there are programmers out there writing Lua modules under Windows and
wouldn't have the first clue about fixing the issues under Linux or Mac OS-X
(or Solaris or FreeBSD or ... ) and will have the same issues as I am with
respect to Windows [9].

  Going back to your original email:

> More precisely, could you please:
>
> 1. Check wether your Lua rock pass or fail at [3]. If it pass, champagne!
> Otherwise...
>
> 2. Check wether it fails due to a platform-independent error (like
> contending the module name) at [4]. If so, please fix and celebrate
> accordingly. Otherwise...
>
> 3. Check wether it fails due to platform-dependent errors at [5]. If so,
> please fix and celebrate accordingly. If not...
>
> 4. It means your rock depends on something that is not available as can be
> seen at [6]. Please blame or blackmail whoever is responsible, or fix your
> broken dependency.

  This comes across as all errors are all very easy and everybody should be
able to do this with a minimum of fuss.  Unfortuntely, that is not the case.
I appreciate your effort (I really do) but please be aware that it might
not be all that easy for module authors to address all issues across all
platforms and some additional effort might be required.

  -spc

[1] Linux, Mac OS-X (home and at work) and Solaris (work only).  

[2] FreeBSD, OpenBSD, NetBSD, HP-UX, AIX, Irix, heck, even probably
        Xenix and <shudder>SCO</shudder>.

[3] Not my footnote.

[4] Not my footnote.

[5] Not my footnote.

[6] Not my footnote.

[7] Pun intended

[8] Too onerous---to the point where I have to work around *the patch*
        and I probably won't accept it.  I don't care enough about Windows
        to take onerous patches.

[9] Too onerous---to the point where they have to work around *the
        patch* and they probably won't accept it.  They dont' care enough
        about Unix to take onerous patches.

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Daurnimator
In reply to this post by Stefano
On 7 September 2015 at 18:25, Stefano <[hidden email]> wrote:
> On 7 September 2015 at 02:10, Daurnimator <[hidden email]> wrote:
>>   - Looks like ULua only supports lua 5.1? this isn't mentioned
>> anywhere on your site
>
> Yes, it is based on LuaJIT which is compatible with Lua 5.1.
> I do not have immediate plans to repeat the exercise for Lua 5.2 and
> 5.2, but if there is a enough request for this I might reconsider.

Add "this is a LuaJIT (lua 5.1 compatible distribution)" to the home page then.

>>   - The list is hard to look through; could you make it more
>> browsable? e.g a table?
>
> You are right, it is not optimal for human consumption (it is the
> database used by automated build system).
> I will pre-process it to make it more readable.

Please do so; don't forget to share the link :)

>>       - at least take out the unsupported_external_library errors
>>   - Seems like you don't handle multiple rockspecs under the one name
>>       - e.g. many of lhf's libraries have a different rockspec for
>> each lua version, and the version number is something like
>> 2015-01-01.51 for lua 5.1
>
> The build system should exclude specs which are for Lua 5.2 and above
> and try to build the latest stable (and unstable if above the stable)
> version for the same rock.
> Can you please point me out to a specific rock where this it is not working?

One I noticed this for is "cqueues" (which I maintain the rockspec for)
Notice I have a different rockspec for each lua version
https://luarocks.org/modules/daurnimator/cqueues
In your lists I only see one (in error.lua)

    cqueues = {
      ["20150119.53-1"] = "lua == 5.3"
    },


>>   - Module naming conflicts are hard to solve; all times I've run into
>> them the authors are uninterested/projects have been abandoned
>>       - https://github.com/keplerproject/luarocks/issues/388
>>       - https://github.com/zhaozg/lua-openssl/issues/72
>
> I can manually blacklist rocks.

I'm not sure if blacklisting helping; often both modules are useful.
e.g. for the case of zlib, I prefer brimwork's lua-zlib, but lzlib is
more widely deployed (due to being a dependency of luarocks).

> As you have experience on the topic,  would you have suggestions
> (based on my module conflicts) on which should be so?

As I said... I've never had a good resolution when this has come up in
the past; not sure I can give good advice here.

Reply | Threaded
Open this post in threaded view
|

Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

Stefano
In reply to this post by Sean Conner


On 7 Sep 2015 22:02, "Sean Conner" <[hidden email]> wrote:
>
> It was thus said that the Great Stefano once stated:
> > On 7 September 2015 at 03:39, Sean Conner <[hidden email]> wrote:
> > >   Thanks for the work, but I'm having difficulty understanding the output
> > > from all this.  For instance, I only found one of my modules [1] in the
> > > Windows output [2] and while I would like to fix the issue, I don't [3]
> > > use Windows, so I'm at a loss as to how to fix this issue:
> > >
> > > env.c
> > > env.c(44): warning C4273: '__p__environ': inconsistent dll linkage
> > > C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\stdlib.h(1158): note: see previous definition of '__p__environ'
> > > Microsoft (R) Incremental Linker Version 14.00.23026.0
> > > Copyright (C) Microsoft Corporation.  All rights reserved.
> > >
> > >    Creating library org/conman/env.lib and object org/conman/env.exp
> > > Installing https://luarocks.org/org.conman.env-1.0.1-0.rockspec...
> > > Using https://luarocks.org/org.conman.env-1.0.1-0.rockspec... switching to 'build' mode
> > > cl /nologo /MD /O2 -c -Foenv.obj -IC:/ste/luarocks/2.2/include env.c
> > > link -dll -def:env.def -out:org/conman/env.dll C:/ste/luarocks/2.2/lua51.lib env.obj
> > > Updating manifest for C:/ste/luarockstree/lib/luarocks/rocks
> > > org.conman.env 1.0.1-0 is now built and installed in C:/ste/luarockstree (license: LGPL)
> >
> > That is just a warning, it builds fine (see below).
> > If you are concerned please send me privately a test and I can run on
> > my Windows VM.
>
>   It may build fine, but does it *run*? 

Good question.
That is where a standardised way to invoke tests would help.
One of the points I complained about in my original post when talking about the lack of policy.

> This modules just populates a Lua
> table with all the environment variables in the process.  Under Unix, you
> can get an array of all the environment variables two ways---one as an
> additional parameter to main()
>
>         int main(int argc,char *argv[],char *envp[])
>
> and the second way is through an external variable:
>
>         extern char **environ;
>
>   I read the error above (and I'm guessing, since I don't use Windows, nor
> do I know the programming environment) that I *might* not get the extern
> environ variable at run time, or if I do, I might not get the one I'm
> expecting.
>
> > >   Another issue:  I'm checking the pass list [4] and I see this for two of
> > > my modules:
> > >
> > >   ["org.conman.env"] = {
> > >     ["1.0.1-2"] = {
> > >       Linux = {
> > >         x86 = true
> > >       },
> > >       OSX = {
> > >         x86 = true
> > >       },
> > >       Windows = {
> > >         x86 = true
> > >       }
> > >     }
> > >   },
> > >   ["org.conman.errno"] = {
> > >     ["1.0.1-2"] = {
> > >       Linux = {
> > >         x86 = false
> > >       },
> > >       OSX = {
> > >         x86 = false
> > >       },
> > >       Windows = {
> > >         x86 = false
> > >       }
> > >     }
> > >   },
> > >
> > >   Um ... did org.conman.errno pass?  Why is the Linux.x86 set to false?  I
> > > *know* it compiled under Linux x86 as that's my main development system.  I
> > > know it also compiles under 64-bit Linux as I use that at work.  I also know
> > > it compiled under OS-X as I use that both at home and at work.  What am I
> > > looking at?
> >
> > Nope.
> > The rock org.conman.env passed on all 3 platforms.
> > The rock org.conman.errno did not pass on any.
>
>   <nitpick>Then why is org.conman.errno included in the "pass"
> list?</nitpick>

The pass.lua file answers the question: does it build and satisfy all criteria (no module name conflict for instance)?
true: yes
false: no
nil: not attempted (excluded as rock list it as unsupported os)

>
> > The reason is found immediately looking at
> > http://www.scilua.org/luarocksorg/state/error.lua
>
>   <nitpick>It may be obvious to you, but it wasn't to me.</nitpick>

That was the first point in the task list of what to check when a module did not pass.
I am preparing a better reporting view (auto generated webpage) for everyone's convenience.

>
> > There is a module conflict (org module name).
> > I am aware in this case it's a module intentionally splitted among
> > multiple rocks and I am going to support this case shortly. So nothing
> > for you to worry about.
> > (side note: I am not convinced on the need to break-up modules in
> > multiple rocks, considering their tiny size, but I can live with
> > that).
>
>   Ah.  Your mistake here is assuming that "org.conman.errno" is a submodule
> of "org".  That is not the case here.  Each of my modules are (with one
> exception) independent of each other and all can be used by themselves.
> What I *am* doing is namespacing my modules.  There are several Lua modules

I am not assuming anything really. I just know that multiple rocks try to write in the same org directory and that this is not allowed for now (by me).
The exact relationship is not important, they might even just contain documentation and it would not make a difference.
What will happen is that there will be a single org package packing together all your rocks.

> that wrap syslog().  There are several Lua modules that wrap sockets.  There
> are several Lua modules that wrap POSIX filesystem calls.  There are several
> Lua modules that wrap the signal() function.  Instead of creating some
> oddball bame like "spcsignal" or "conmansyslog" I opted instead to pull them
> all under a common namespace, based off my primary DNS domain name. [1]
>
> > >   I've got too many questions to even start looking into my luarock modules.
> > > And while I can fix the Linux and OS-X issues, I have no Windows systems [3]
> > > nor do I understand that platform to fix issues there.  And I'm sure there
> > > are people who can fix Windows issues but not OS-X or Linux.
> >
> > Philipp already replied to the lua.h issue (thanks!), I answered the
> > reaming questions.
> > The best I can do is to provide you with the full stderr and stout
> > outputs from Luarocks: this is what you would get if you were to try
> > to install the rock yourself on a Windows machine. I am not sure how I
> > can improve on this short of giving you ssh access to a Windows VM.
> >
> > Please let me know if I can help further.
>
>   It wouldn't help in my case.  I don't do development under Windows; I
> don't know the development environment so even if I had access, I wouldn't
> know how to fix the issue.

Sure, in the next release there will be support for OS-specific packages.
If you do not plan on supporting Windows please consider to add supported os info in the rockspec.

Stefano

>
>   -spc
>
> [1]     There are some that don't like my choice of namespace, but I feel
>         it's better than nothing.
>

12