I'm having trouble with installing 1.4.0. If I install 1.3.0 it works fine, but for 1.4.0 I'm getting

npm ERR! Linux 4.10.1-041001-generic
npm ERR! argv "/home/arne/.nvm/versions/node/v7.9.0/bin/node" "/home/arne/.nvm/versions/node/v7.9.0/bin/npm" "install" "lumo-cljs" "-g"
npm ERR! node v7.9.0
npm ERR! npm  v4.2.0
npm ERR! path /home/arne/.nvm/versions/node/v7.9.0/lib/node_modules/lumo-cljs/bin/lumo
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall chmod

npm ERR! enoent ENOENT: no such file or directory, chmod '/home/arne/.nvm/versions/node/v7.9.0/lib/node_modules/lumo-cljs/bin/lumo'
npm ERR! enoent ENOENT: no such file or directory, chmod '/home/arne/.nvm/versions/node/v7.9.0/lib/node_modules/lumo-cljs/bin/lumo'
npm ERR! enoent This is most likely not a problem with npm itself
npm ERR! enoent and is related to npm not being able to find a file.
npm ERR! enoent 

npm ERR! Please include the following file with any support request:
npm ERR!     /home/arne/.npm/_logs/2017-04-20T10_44_04_476Z-debug.log

log: https://gist.github.com/562b3521dac6e9eba08e3e296de43ee9

ok, definitely broken since the change to no longer default to lumo.exe when the install fails. I'll make an issue.

@plexus thanks for digging into it

published a patch version to NPM

great! then I can finish recording my episode 🙂

awesome

announcing Lumo 1.4 now too

you’re an early bird 🙂

🙂

https://twitter.com/anmonteiro90/status/855059187709091840

uhm just a moment

/home/arne/.nvm/versions/node/v6.10.2/lib/node_modules/lumo-cljs/node_modules/progress/lib/node-progress.js:155
  complete = Array(Math.max(0, completeLength + 1)).join(this.chars.complete);
             ^

RangeError: Invalid array length
    at ProgressBar.render (/home/arne/.nvm/versions/node/v6.10.2/lib/node_modules/lumo-cljs/node_modules/progress/lib/node-progress.js:155:1
4)
    at ontimeout (timers.js:380:14)
    at tryOnTimeout (timers.js:244:5)
    at Timer.listOnTimeout (timers.js:214:5)

._.?

something still broken with the install

that’s an upstream thing

oh?

let me try here

oh I know what’s wrong…

my fault 🙂

\o/ surprised it's not my fault tbh

@plexus works now

what was it?

here’s the problem: NPM releases get their version from package.json and go get the URL from GitHub

but there was no 1.4.1 release on GitHub 🙂

oooh makes sense

thanks!

@plexus btw I saw your logo suggestion

I like it better than every other so far

I’m not in a rush to make a decision though

just thought I’d set expectations

hope you understand

thanks for the heads up. Would you mind if I use it in the title screen of this upcoming episode though?

uh

sure, why not. as long it’s not used in a context that conveys it’s the actual Lumo logo

it's nice to have something visual in there, and it doesn't have to be "official" for that.

thanks!

don't know if this is harmless but after install lumo 1.4.1 it still thinks it's version 1.4.0

lumo --version
1.4.0

yeah, the version is supposed to be 1.4.0

it’s only 1.4.2 for NPM purposes because they don’t let us delete releases (anymore – and thankfully \left-pad\)

make[1]: *** No rule to make target '../google-closure-compiler-js.js', needed by '/builddir/lumo-1.4.0/tmp/node/7.9.0/node-v7.9.0/out/Release/obj/gen/node_javascript.cc'.  Stop.
make[1]: *** Waiting for unfinished jobs....
  touch /builddir/lumo-1.4.0/tmp/node/7.9.0/node-v7.9.0/out/Release/obj.target/mkssldef.stamp
make[1]: Leaving directory '/builddir/lumo-1.4.0/tmp/node/7.9.0/node-v7.9.0/out'
make: *** [Makefile:75: node] Error 2
....> ERROR: The release executable has not been generated. This indicates a failure in the build process. There is likely additional information above.

Is this the bug you just fixed? boot release-ci was what I was doing

@dominicm you may need to run yarn to update deps?

that’s not a bug

all CIs can build it and so can I locally 🙂

let me know if you’re still having problems after a fresh clone

Trying now 😛

yeah that worked

great

hmm, a script has stopped working :thinking_face:

@dominicm what does the script do

Nothing fancy, mostly node interop using require(js)

I’m happy to look at a minimal repro

yeah, still trying to dig it up 😛. Looks like a callback isn't being called 😕

ooh

hrm

I don’t have an immediate theory as to what it would be

#!/usr/bin/env node

var fs = require('fs')
var jar_output_path = ""

fs.access(jar_output_path, function(err){ console.log('access returns…')})

#!/usr/bin/env lumo

(def fs (js/require "fs"))
(def jar-output-path "")

(fs.access jar-output-path
           (fn [err]
             (println "access returns…")))

cljs.user=> (def fs (js/require "fs"))
#'cljs.user/fs
cljs.user=> (def jar-output-path "")
#'cljs.user/jar-output-path
cljs.user=> (fs.access jar-output-path
       #_=>            (fn [err]
       #_=>              (println "access returns…")))
nil
cljs.user=> access returns…

I executed like ./foo.cljs

wonder if that's important :thinking_face:

Works via lumo < foo.cljs for me. So yeah, something repl vs non-repl.

ah

interesting

checking

I know what’s wrong

Your end or mine? 😄

my end 😞

https://github.com/anmonteiro/lumo/blob/master/src/js/cljs.js#L350

these can’t be sync

we’re exiting before async returns

I see.. 😱

@dominicm https://github.com/anmonteiro/lumo/commit/7659aec188430dfeec336da924c39e4322b37676

let me know if that needs a new release

it’s quite a big regression so I’m happy to do a patch release

It would be very useful, if you don't mind 🙂

sure. can it wait a couple days?

yeah, I doubt anyone is running this script tbh 😛

I’m on mastodon.social, can I see that post?

🐘 toot toot

https://mastodon.social/users/zacanger/updates/1969385

@anmonteiro everyone knows the main instance is way too mainstream! I wanna toot <mailto:[email protected]|[email protected]>

🙂

I own http://dominic.io, quite tempted to go for <mailto:[email protected]|[email protected]> or something like that

I wanted to buy http://lumo.io

but it’s taken 😞

Oh, I thought you had it

@anmonteiro your readme is gone from lumo?

what did I do

😄

nice catch

The page looked… empty

I want it to be symlinked to what’s in packages/lumo

so that NPM picks up the README

but I forgot to commit

Does that work on gh?

fixed

yeah

doesn’t work in NPM, so the actual content will be in packages/lumo/README.md

https://etherpad.net/p/Clojure_peeps_on_the_fediverse

FWIW .io domains have some questionable ethics behind them and are better avoided

https://gigaom.com/2014/06/30/the-dark-side-of-io-how-the-u-k-is-making-web-domain-profits-from-a-shady-cold-war-land-deal/

So how can I share that post if I am not on mastodon.social but in another domain?

oh ok found, I have to search the person first

@darwin do you have a way to quickly test a fix to https://github.com/anmonteiro/lumo/issues/137 ?

@anmonteiro I’m seeing the same issue with lumo 1.4.1: https://travis-ci.org/binaryage/env-config/builds/224156699#L506 I have pretty standard travis environ here: https://github.com/binaryage/env-config/blob/master/.travis.yml

@darwin 1.4.1 is not a release

that’s just something to make NPM happy

it’s still 1.4.0 🙂

ah, ok, how should I get/compile it?

http://s3.amazonaws.com/lumo-linux/lumo.zip

that’s a statically linked binary

ok, will play with it

@anmonteiro I have tested your static binary under my virtual machine, npm version reported the same issue as real travis, and your static binary worked as expected

awesome

Releasing Lumo 1.4.1

@anmonteiro give me a few more minutes, testing it on live travis right now

ok

I’m pretty sure it works

just need to write the script correctly

I tested it on nixOS which is really picky about lib paths

wondering what is the size difference

let me check it real quick

no rush

real travis worked: https://travis-ci.org/binaryage/env-config/builds/224165954#L391

awesome

statically linked version seems to be smaller

which makes no sense

unless something else stripped the size between 1.4.0 and 1.4.1

size shouldn’t have changed

why not? if you link stdlibc++ statically it should be included in the binary

sorry, I mean nothing should have made size change between 1.4 and master

and from your patch you seemed to link everything statically, so not only stdlibc++ but potentially other dynamic libs which were previously linked dynamically

anyways, it works and it didn’t bloat the binary size it seems

yeah

rot@f96112caf831:/# file lumo
lumo: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=70b34ee170b9a39155ae978319cade9949ac0cf9, not stripped