Package Details: moonscript 0.5.0_1-1

Git Clone URL: https://aur.archlinux.org/moonscript.git (read-only, click to copy)
Package Base: moonscript
Description: A programmer friendly language that compiles to Lua
Upstream URL: http://moonscript.org
Licenses: MIT
Submitter: xyproto
Maintainer: alerque
Last Packager: jahiy
Votes: 10
Popularity: 0.000842
First Submitted: 2011-08-11 12:49 (UTC)
Last Updated: 2016-11-04 11:51 (UTC)

Latest Comments

1 2 3 4 Next › Last »

FichteFoll commented on 2020-08-17 16:06 (UTC)

lua-alt-getopt (and lua53-alt-getopt) has been updated, but moonc still fails because it tries to load itself from 5.4 while its libraries are installed into the 5.3 folder and can't import moonscript.cmd.moonc. Pinning the 5.3 executable and folder (using the same command as in my previous comment) then fails because it can't import lfs.

FichteFoll commented on 2020-08-11 16:23 (UTC) (edited on 2020-08-11 16:50 (UTC) by FichteFoll)

Apparently broken since Lua was updated to 5.4. No idea how to fix, personally.

  • moonc wants to load alt_getopt on start, which isn't available for 5.4 yet, it seems (https://luarocks.org/modules/mpeterv/alt-getopt).
  • Trying to run it explicitly with lua5.3 produces a different error about module being nil.
  • For some reason, the lua-alt-getopt package still installs its files into the 5.3 folder and conflicts with lua53-alt-getopt.

Edit: Submitted a task https://bugs.archlinux.org/task/67556.

$ moonc
/usr/bin/lua: /usr/lib/luarocks/rocks-5.3/moonscript/0.5.0-1/bin/moonc:3: module 'alt_getopt' not found:
    No LuaRocks module found for alt_getopt
    no field package.preload['alt_getopt']
    no file '/usr/share/lua/5.4/alt_getopt.lua'
    no file '/usr/share/lua/5.4/alt_getopt/init.lua'
    no file '/usr/lib/lua/5.4/alt_getopt.lua'
    no file '/usr/lib/lua/5.4/alt_getopt/init.lua'
    no file './alt_getopt.lua'
    no file './alt_getopt/init.lua'
    no file '/home/fichte/.luarocks/share/lua/5.4/alt_getopt.lua'
    no file '/home/fichte/.luarocks/share/lua/5.4/alt_getopt/init.lua'
    no file '/usr/lib/lua/5.4/alt_getopt.so'
    no file '/usr/lib/lua/5.4/loadall.so'
    no file './alt_getopt.so'
    no file '/home/fichte/.luarocks/lib/lua/5.4/alt_getopt.so'
stack traceback:
    [C]: in function 'require'
    /usr/lib/luarocks/rocks-5.3/moonscript/0.5.0-1/bin/moonc:3: in main chunk
    [C]: in ?
 ?=1

$ cat /bin/moonc
#!/bin/sh

exec '/usr/bin/lua' -e 'package.path="/usr/share/lua/5.3/?.lua;/usr/share/lua/5.3/?/init.lua;"..package.path; package.cpath="/usr/lib/lua/5.3/?.so;"..package.cpath' -e 'local k,l,_=pcall(require,"luarocks.loader") _=k and l.add_context("moonscript","0.5.0-1")' '/usr/lib/luarocks/rocks-5.3/moonscript/0.5.0-1/bin/moonc' "$@"

$ '/usr/bin/lua5.3' -e 'package.path="/usr/share/lua/5.3/?.lua;/usr/share/lua/5.3/?/init.lua;"..package.path; package.cpath="/usr/lib/lua/5.3/?.so;"..package.cpath' -e 'local k,l,_=pcall(require,"luarocks.loader") _=k and l.add_context("moonscript","0.5.0-1")' '/usr/lib/luarocks/rocks-5.3/moonscript/0.5.0-1/bin/moonc'
/usr/bin/lua5.3: /usr/share/lua/5.3/alt_getopt.lua:24: attempt to call a nil value (global 'module')
stack traceback:
    /usr/share/lua/5.3/alt_getopt.lua:24: in main chunk
    [C]: in function 'require'
    /usr/lib/luarocks/rocks-5.3/moonscript/0.5.0-1/bin/moonc:3: in main chunk
    [C]: in ?
 ?=1

$ pacman -F /usr/share/lua/5.3/alt_getopt.lua
usr/share/lua/5.3/alt_getopt.lua is owned by community/lua-alt-getopt 0.7.0-8
usr/share/lua/5.3/alt_getopt.lua is owned by community/lua53-alt-getopt 0.7.0-9

m040601 commented on 2020-06-07 01:20 (UTC) (edited on 2020-06-07 01:24 (UTC) by m040601)

Is there any reason for this package's PKGBUILD to only include x86 architecture ?

arch=('x86_64' 'i686')

Could you add arm architecture to it ? "armv7h" "armv6h" etc

I'm trying to build some mpv scripts, https://aur.archlinux.org/packages/mpv-webm-git, which depend on 'moonscript'

moonscript dependencies:

luarocks
lua-lpeg>=0.10
lua-alt-getopt>=0.7
lua-filesystem>=1.5
lua>=5.1
curl (curl-git) (make)
git (git-git) (make)

are all available on Arch Linux Arm

so there should be no reason for moonscript not to work there

minus commented on 2016-07-23 19:56 (UTC)

Checksum of index.html doesn't match. Using checksums on non-versioned files is too fragile imho

dluciv commented on 2016-03-13 09:32 (UTC)

Moreover, everything except rockspec file fails to match. Those files do not affect security directly, I suggest to just change their checksums to 'SKIP'.

wenLiangcan commented on 2014-08-07 12:46 (UTC)

The checksum of file README.md should be update to d9e055952371e6d23d47459da59f8c517929e65b9e27e55f82e7a1c3051cfdea

xyproto commented on 2014-08-06 09:37 (UTC)

Updated to 0.2.6.

xyproto commented on 2014-08-06 09:30 (UTC)

Thanks, will update. Just flagging the package as out-of-date also works.

truh commented on 2014-08-05 11:38 (UTC)

Looks like you have to update the validity checks. ==> Validating source files with sha256sums... moonscript-dev-1.rockspec ... Passed README.md ... FAILED reference.md ... FAILED index.html ... FAILED ==> ERROR: One or more files did not pass the validity check! ==> ERROR: Makepkg was unable to build moonscript.

xyproto commented on 2014-05-31 21:57 (UTC)

Updated the package, thanks wenLiangcan. If you want to adopt it, please let me know. You seem to care about this one, which is great.