New installation doesn't launch experiment


#22

Ok, I’m in the midst of a rebuild and get a build error in gzweb when I do the ./deploy.sh

Linking CXX executable gzcoarse
[100%] Built target gzcoarse

/home/chris/Documents/NRP/gzweb/node_modules/wide-align/node_modules/string-width/index.js:2
const stripAnsi = require(‘strip-ansi’);
^^^^^
SyntaxError: Use of const in strict mode.
at Module._compile (module.js:439:25)
at Object.Module._extensions…js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object. (/home/chris/Documents/NRP/gzweb/node_modules/wide-align/align.js:2:19)
at Module._compile (module.js:456:26)
at Object.Module._extensions…js (module.js:474:10)
at Module.load (module.js:356:32)

/home/chris/Documents/NRP/gzweb/node_modules/wide-align/node_modules/string-width/index.js:2
const stripAnsi = require(‘strip-ansi’);
^^^^^
SyntaxError: Use of const in strict mode.
at Module._compile (module.js:439:25)
at Object.Module._extensions…js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object. (/home/chris/Documents/NRP/gzweb/node_modules/wide-align/align.js:2:19)
at Module._compile (module.js:456:26)
at Object.Module._extensions…js (module.js:474:10)
at Module.load (module.js:356:32)
There are node-gyp build errors, exiting.

It’s largely been smooth to this point, so I’m going to stop here until I hear from you all.


#23

Hi Chris,

The problem could be related to the fact that you have an older version of NodeJS installed on your machine, which means that when you are doing npm install, all the node modules that are installed are compiled with the old version of Node. Since the const keyword is a feature which is available only in the latest version of Javascript, one quick thing that you could check is what version of Node you are using. On a terminal:

node -v

if this is less than 1 (probably 0.10 since it was the one we where using before we migrated to the latest JS) then you should do the following:

curl -sL https://deb.nodesource.com/setup_7.x | sudo -E bash -
sudo apt-get install -y nodejs

then also do:

nvm use node

to make use of the latest version of node. To make this change permanent you can do

nvm alias default node

Lastly, go to the gzweb folder and remove the node_modules directory and do npm install again

To switch between newer and older versions of node in case you need it for other projects you can just do

nvm use for example nvm use 0.10 would make you use the 0.10 version of node in your current bash.

I hope it helps, else we can look more into this problem


#24

I tried this and I still get the same error. I’ve been looking into the problem, and I was looking around the node version issue. My
node -v command gives v7.10.0
however the screen dump from the ./deploy.sh command has a line
Now using node v0.10.48 (npm v2.15.1)

The deploy.sh somehow selects a v0.10.48 version. A different shell gives v7.9.0, but the same Now using line while running the script.


#25

I confirmed that the problem that you posted exists if you remove the node_modules and then do npm install. I am looking into it to provide a quick workaround, but I will also file a bug report. Thanks for pointing that out


#26

The deplay.sh actually does an nvm use 0.10
If you take that out, the build crashes further along.


#27

yes, I tried that, it seems that we are using the old version of node in the script for some reason


#28

Ok, the node version issue helps. I’ve now plugged through the script with node 0.10.48, and can reproduce the crash in
cd …/gzbridge
$DIR/node_modules/.bin/node-gyp configure


#29

the problem was solved, just do

cd $NRP/gzweb
git pull --rebase
rm -rf node_modules
nvm use node
npm install
./deploy.sh -m local

and it should work. Thanks for pointing out the problem


#30

Yes, that seems to fix that problem.
Ta


#31

Ok, the build finished. I had problems with Chrome and webGL, but when I changed my default browser back to FireFox, it worked. So, now I have a running NRP.


#32

I had it all running with experiments launching. I rebooted and started again and the original error (message 1) appears in a pop up box.


#33

@kennysharma I tried messages 7-9 on this thread again.
The libraries (9) exist.
If you run the server with --verbose it stays verbose. Below is a run after verbose. Before its verbose, the shell comes back and you can ps and see the gzserver. After (and on verbose) it stays and you have to ctrl-c out.
chris@pl-00108685:~$ gzserver -s $HBP/GazeboRosPackages/devel/lib/libgazebo_ros_api_plugin.so -s $HBP/GazeboRosPackages/devel/lib/libgazebo_ros_paths_plugin.so
[ INFO] [1494589381.344844462]: Finished loading Gazebo ROS API Plugin.
[ INFO] [1494589381.345290048]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting…
[ INFO] [1494589381.806147763, 0.025000000]: waitForService: Service [/gazebo/set_physics_properties] is now available.
[ INFO] [1494589381.878019749, 0.094000000]: Physics dynamic reconfigure ready.

What’s odd to me is that it worked yesterday and this morning. I didn’t restart the machine after I got it working yesterday. Today I was trying to get a new experiment going (a copy of template_husky). I ran the Models/create-symlinks.sh
and gzweb/deploy.sh -m local
The new experiment didn’t show up on the page until I rebooted. It does show up now, but now I can’t launch any of the experiments. I’m pretty sure that’s all I changed.


#34

Dear Chris,

Since the problem was triggered by a reboot this time, we may inspect the content of your .bashrc and make also sure you open a fresh terminal before running “cle-start”.

Best regards,
Luc


#35

Each time I run nginx in a shell, cle-start in a second, and cle-frontend in a third. I haven’t changed the .bashrc since it worked. The only thing I’ve added was for the NRP, and the PyNN line at the end. Here’s my .bashrc:
chris@pl-00108685:~$ cat .bashrc

~/.bashrc: executed by bash(1) for non-login shells.

see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)

for examples

If not running interactively, don’t do anything

case $- in
i) ;;
*) return;;
esac

don’t put duplicate lines or lines starting with space in the history.

See bash(1) for more options

HISTCONTROL=ignoreboth

append to the history file, don’t overwrite it

shopt -s histappend

for setting history length see HISTSIZE and HISTFILESIZE in bash(1)

HISTSIZE=1000
HISTFILESIZE=2000

check the window size after each command and, if necessary,

update the values of LINES and COLUMNS.

shopt -s checkwinsize

If set, the pattern “**” used in a pathname expansion context will

match all files and zero or more directories and subdirectories.

#shopt -s globstar

make less more friendly for non-text input files, see lesspipe(1)

[ -x /usr/bin/lesspipe ] && eval “$(SHELL=/bin/sh lesspipe)”

set variable identifying the chroot you work in (used in the prompt below)

if [ -z “${debian_chroot:-}” ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi

set a fancy prompt (non-color, unless we know we “want” color)

case “$TERM” in
xterm-color) color_prompt=yes;;
esac

uncomment for a colored prompt, if the terminal has the capability; turned

off by default to not distract the user: the focus in a terminal window

should be on the output of commands, not on the prompt

#force_color_prompt=yes

if [ -n “$force_color_prompt” ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it’s compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi

if [ “$color_prompt” = yes ]; then
PS1=’${debian_chroot:+($debian_chroot)}[\033[01;32m]\u@\h[\033[00m]:[\033[01;34m]\w[\033[00m]$ ’
else
PS1=’${debian_chroot:+($debian_chroot)}\u@\h:\w$ ’
fi
unset color_prompt force_color_prompt

If this is an xterm set the title to user@host:dir

case “$TERM” in
xterm*|rxvt*)
PS1="[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a]$PS1"
;;
*)
;;
esac

enable color support of ls and also add handy aliases

if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval “$(dircolors -b ~/.dircolors)” || eval “$(dircolors -b)”
alias ls=‘ls --color=auto’
#alias dir=‘dir --color=auto’
#alias vdir=‘vdir --color=auto’

alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'

fi

some more ls aliases

alias ll=‘ls -alF’
alias la=‘ls -A’
alias l=‘ls -CF’

Add an “alert” alias for long running commands. Use like so:

sleep 10; alert

alias alert=‘notify-send --urgency=low -i “$([ $? = 0 ] && echo terminal || echo error)” "$(history|tail -n1|sed -e ‘’‘s/^\s*[0-9]+\s*//;s/[;&|]\s*alert$//’’’)"’

Alias definitions.

You may want to put all your additions into a separate file like

~/.bash_aliases, instead of adding them here directly.

See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi

enable programmable completion features (you don’t need to enable

this, if it’s already enabled in /etc/bash.bashrc and /etc/profile

sources /etc/bash.bashrc).

if ! shopt -oq posix; then
if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
fi

#new stuff added by Chris
export HBP=$HOME/Documents/NRP
. $HBP/user-scripts/nrp_variables
. $HBP/user-scripts/nrp_aliases

export NVM_DIR="/home/chris/.nvm"
[ -s “$NVM_DIR/nvm.sh” ] && . “$NVM_DIR/nvm.sh” # This loads nvm
export APP_SETTINGS=config.NoDBConfig

export CMAKE_PREFIX_PATH=$HOME/.local/lib/x86_64-linux-gnu/cmake/gazebo/:$CMAKE_PREFIX_PATH

#add the pyNN path by Chris
export PYTHONPATH=/home/chris/Documents/NRP/CLE/platform_venv/lib/python2.7/site-packages:$PYTHONPATH
chris@pl-00108685:~$


#36

Hi Chris,

I did not review the whole thread, so this might have been already tested, but did you access your experiment list with this URL?
http://localhost:9000/#/esv-web?dev

Maturity=development experiments are hidden from the default page without the “?dev”.
My 2 cents.
Axel


#37

When I run cle-frontend it comes up with the
http://localhost:9000/#/esv-web
page. That’s the one I was using. None the less, I try
http://localhost:9000/#/esv-web?dev
and have the same problem.


#38

After reboot, try to cle-nginx before cle-start


#39

I tried cle-nginx and it didn’t seem to help.
It also occurred to me that I had typically (always?) had xemacs open to get the nginx command, so I rebooted and tried without that and it didn’t help. So, in one shell
~/.local/etc/init.d/nginx restart #in the second
cle-nginx
cle-start #and in a third
cle-frontend # I get an error loading uglify.js (can’t find) here but as I recall that happened when it worked

Also each of the experiments has a server status button. It’s yellow (amber). Did it used to be (or for you is it) green?


#40

The button is ok with yellow (it is suposed to monitor our cluster, but since you are on a local install, it is unused).


#41

Checking the video drivers showed that the Intel Broadwell graphics card is badly supported by default ubuntu 14.04 kernel (3.13). It was crashing Ogre and consequently gzserver. An update to kernel 3.19 (vivid) solved the issue.

sudo apt-get install --install-recommends linux-generic-lts-vivid xserver-xorg-lts-vivid libgl1-mesa-glx-lts-vivid