Fork me on GitHub
#lumo
<
2017-04-20
>
plexus10:04:48

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

plexus10:04:52

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

plexus10:04:59

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

anmonteiro13:04:50

@plexus thanks for digging into it

anmonteiro14:04:00

published a patch version to NPM

plexus14:04:18

great! then I can finish recording my episode 🙂

anmonteiro14:04:36

announcing Lumo 1.4 now too

anmonteiro14:04:44

you’re an early bird 🙂

plexus14:04:29

uhm just a moment

plexus14:04:33

/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)

plexus14:04:49

something still broken with the install

anmonteiro14:04:55

that’s an upstream thing

anmonteiro14:04:07

let me try here

anmonteiro14:04:30

oh I know what’s wrong…

anmonteiro14:04:37

my fault 🙂

plexus14:04:04

\o/ surprised it's not my fault tbh

plexus14:04:45

what was it?

anmonteiro14:04:45

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

anmonteiro14:04:00

but there was no 1.4.1 release on GitHub 🙂

plexus14:04:06

oooh makes sense

anmonteiro14:04:25

@plexus btw I saw your logo suggestion

anmonteiro14:04:32

I like it better than every other so far

anmonteiro14:04:38

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

anmonteiro14:04:47

just thought I’d set expectations

anmonteiro14:04:54

hope you understand

plexus14:04:42

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

anmonteiro14:04:07

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

plexus14:04:28

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

plexus14:04:50

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

plexus14:04:06

lumo --version
1.4.0

anmonteiro14:04:43

yeah, the version is supposed to be 1.4.0

anmonteiro14:04:09

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

dominicm14:04:45

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.

dominicm14:04:00

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

anmonteiro14:04:02

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

anmonteiro14:04:08

that’s not a bug

anmonteiro14:04:24

all CIs can build it and so can I locally 🙂

anmonteiro14:04:37

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

dominicm14:04:11

Trying now 😛

dominicm15:04:51

yeah that worked

dominicm15:04:50

hmm, a script has stopped working :thinking_face:

anmonteiro15:04:49

@dominicm what does the script do

dominicm15:04:19

Nothing fancy, mostly node interop using require(js)

anmonteiro15:04:19

I’m happy to look at a minimal repro

dominicm15:04:36

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

anmonteiro15:04:58

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

dominicm15:04:37

#!/usr/bin/env node

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

fs.access(jar_output_path, function(err){ console.log('access returns…')})
^ prints the line
#!/usr/bin/env lumo

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

(fs.access jar-output-path
           (fn [err]
             (println "access returns…")))
^^ this doesn't print a line

anmonteiro15:04:36

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…

dominicm15:04:17

I executed like ./foo.cljs

dominicm15:04:23

wonder if that's important :thinking_face:

dominicm15:04:20

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

anmonteiro15:04:44

I know what’s wrong

dominicm15:04:17

Your end or mine? 😄

anmonteiro15:04:27

these can’t be sync

anmonteiro15:04:44

we’re exiting before async returns

dominicm15:04:07

I see.. 😱

anmonteiro16:04:18

let me know if that needs a new release

anmonteiro16:04:37

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

dominicm16:04:39

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

anmonteiro16:04:55

sure. can it wait a couple days?

dominicm16:04:43

yeah, I doubt anyone is running this script tbh 😛

anmonteiro18:04:33

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

dominicm19:04:21

🐘 toot toot

dominicm19:04:25

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

dominicm19:04:21

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

anmonteiro19:04:48

but it’s taken 😞

dominicm19:04:01

Oh, I thought you had it

dominicm19:04:20

@anmonteiro your readme is gone from lumo?

anmonteiro19:04:48

what did I do

dominicm19:04:13

The page looked… empty

anmonteiro19:04:25

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

anmonteiro19:04:30

so that NPM picks up the README

anmonteiro19:04:52

but I forgot to commit

dominicm19:04:04

Does that work on gh?

anmonteiro19:04:47

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

plexus19:04:31

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

richiardiandrea20:04:19

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

richiardiandrea20:04:57

oh ok found, I have to search the person first

anmonteiro23:04:06

@darwin 1.4.1 is not a release

anmonteiro23:04:29

that’s just something to make NPM happy

anmonteiro23:04:40

it’s still 1.4.0 🙂

darwin23:04:47

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

anmonteiro23:04:11

that’s a statically linked binary

darwin23:04:19

ok, will play with it

darwin23:04:59

@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

anmonteiro23:04:40

Releasing Lumo 1.4.1

darwin23:04:46

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

anmonteiro23:04:02

I’m pretty sure it works

darwin23:04:10

just need to write the script correctly

anmonteiro23:04:16

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

darwin23:04:17

wondering what is the size difference

darwin23:04:45

let me check it real quick

darwin23:04:37

statically linked version seems to be smaller

darwin23:04:49

which makes no sense

darwin23:04:14

unless something else stripped the size between 1.4.0 and 1.4.1

anmonteiro23:04:23

size shouldn’t have changed

darwin23:04:52

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

anmonteiro23:04:18

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

darwin23:04:53

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

darwin23:04:33

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

anmonteiro23:04:54

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