After moving from brew to asdf version control tool for Elixir and Erlang I still cant compile my old projects: in the compile process it tries to refer to non-existent Brew's Cellar lib files:
MacBook-Pro% mix test
==> gettext
Compiling 1 file (.erl)
/usr/local/Cellar/erlang/21.3.2/lib/erlang/lib/parsetools-2.1.8/include/yeccpre.hrl:59: illegal pattern
/usr/local/Cellar/erlang/21.3.2/lib/erlang/lib/parsetools-2.1.8/include/yeccpre.hrl:60: variable 'Error' is unbound
/usr/local/Cellar/erlang/21.3.2/lib/erlang/lib/parsetools-2.1.8/include/yeccpre.hrl:60: variable 'Stacktrace' is unbound
/usr/local/Cellar/erlang/21.3.2/lib/erlang/lib/parsetools-2.1.8/include/yeccpre.hrl:63: variable 'Stacktrace' unsafe in 'try' (line 60)
/usr/local/Cellar/erlang/21.3.2/lib/erlang/lib/parsetools-2.1.8/include/yeccpre.hrl:64: variable 'Error' unsafe in 'try' (line 60)
/usr/local/Cellar/erlang/21.3.2/lib/erlang/lib/parsetools-2.1.8/include/yeccpre.hrl:64: variable 'Stacktrace' unsafe in 'try' (line 60)
could not compile dependency :gettext, "mix compile" failed. You can recompile this dependency with "mix deps.compile gettext", update it with "mix deps.update gettext" or clean it with "mix deps.clean gettext"
even though there is no any /usr/local/Cellar/erlang folder
where does the mix take the paths to external erlang libs and how to change that to use the asdf's bundles?
Erlang, and also Elixir use binaries and libs from your $PATH environment variable as described here: https://elixir-lang.org/install.html#installing-erlang
asdf usually is loaded at the end of your $PATH, which means that if you still have Erlang and Elixir installed via brew it's gonna be loaded first. That said, please double check if any other Erlang version is installed via brew. You can uninstall all versions with the command brew uninstall erlang --force
Also set the local Erlang and Elixir versions in the root dir of your project with the commands:
asdf local erlang 21.3.2
asdf local elixir 1.8.1-otp-21
Change versions according to your environment.
And finally check if asdf is loading the correct version with the command asdf current. It should display something like:
elixir 1.8.1-otp-21 (set by /path/to/project/.tool-versions)
erlang 21.3.2 (set by /path/to/project/.tool-versions)
As a last resort, check out https://asdf-vm.com/#/core-manage-asdf-vm?id=having-issues.
Related
Installed using, go get github.com/githubnemo/CompileDaemon and go install github.com/githubnemo/CompileDaemon
When I try to run it using -> CompileDaemon --compile="./folderName"
It gives -> zsh: command not found: CompileDaemon
Note:
I'm using oh-my-zsh.
My GOPATH and GOBIN are not default one's, I set it to goWorkspace
Install Compile Daemon using
"go install github.com/githubnemo/CompileDaemon#latest"
Important:
Ensure that the Compile Daemon executable path(i.e: GOBIN) is included in $PATH.
You can include it by editing your ".bashrc" or ".zshrc" file.
or by "export PATH=$PATH:$GOBIN"
First, don't forget that the use of go get to build and install packages is deprecated (In earlier versions of Go, 'go get' was used to build and install packages. Now, 'go get' is dedicated to adjusting dependencies in go.mod.)
All you need should be go install:
go install github.com/githubnemo/CompileDaemon#latest
That should generate a CompileDaemon executable in your directory named by the GOBIN environment variable.
But you need $GOBIN itself in your $PATH (from your ~/.zshrc for instance):
export PATH="$PATH:$GOBIN"
Using Windows 10 64-bit, Cabal-3.4.0.0, ghc-8.10.7.
I installed OpenBLAS in MSYS2 environment with command
pacman -S mingw-w64-x86_64-openblas.
Than, I successfully installed hmatrix-0.20.2 with command
cabal install --lib hmatrix --flags=openblas --extra-include-dirs="C:\\ghcup\\msys64\\mingw64\\include\\OpenBLAS" --extra-lib-dirs="C:\\ghcup\\msys64\\mingw64\\bin" --extra-lib-dirs="C:\\ghcup\\msys64\\mingw64\\lib"
I am trying to build simple test project using cabal build cabalhmatrix with Main
module Main where
import Numeric.LinearAlgebra
main :: IO ()
main = do
putStrLn $ show $ vector [1,2,3] * vector [3,0,-2]
But now I am getting output
Resolving dependencies...
Build profile: -w ghc-8.10.7 -O1
In order, the following will be built (use -v for more details):
- hmatrix-0.20.2 (lib) (requires build)
- cabalhmatrix-0.1.0.0 (exe:cabalhmatrix) (first run)
Starting hmatrix-0.20.2 (lib)
Failed to build hmatrix-0.20.2. The failure occurred during the configure
step.
Build log (
C:\cabal\logs\ghc-8.10.7\hmatrix-0.20.2-6dd2e8f2795550e4dd624770ac98c326dacc0cac.log
):
Warning: hmatrix.cabal:21:28: Packages with 'cabal-version: 1.12' or later
should specify a specific version of the Cabal spec of the form
'cabal-version: x.y'. Use 'cabal-version: 1.18'.
Configuring library for hmatrix-0.20.2..
cabal-3.4.0.0.exe: Missing dependencies on foreign libraries:
* Missing (or bad) C libraries: blas, lapack
This problem can usually be solved by installing the system packages that
provide these libraries (you may need the "-dev" versions). If the libraries
are already installed but in a non-standard location then you can use the
flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are.If
the library files do exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
cabal-3.4.0.0.exe: Failed to build hmatrix-0.20.2 (which is required by
exe:cabalhmatrix from cabalhmatrix-0.1.0.0). See the build log above for
details.
What should I do to correctly build that package?
I guess I need to somehow pass arguments --flags=openblas --extra-include-dirs="C:\\ghcup\\msys64\\mingw64\\include\\OpenBLAS" --extra-lib-dirs="C:\\ghcup\\msys64\\mingw64\\bin" --extra-lib-dirs="C:\\ghcup\\msys64\\mingw64\\lib" to hmatrix during compilation, but don't know how to do that. To be honest, I don't understand for what program exactly are those arguments (cabal, ghc, ghc-pkg or something else) and why cabal is trying to install hmatrix again. I see hmatrix in directory "C:\cabal\store\ghc-8.10.7\hmatrix-0.20.2-e917eca0fc7690010007a19f4f2a3602d86df0f0".
Created cabal.project file:
packages: .
package hmatrix
flags: +openblas
extra-include-dirs: C:\\ghcup\\msys64\\mingw64\\include\\OpenBLAS
extra-lib-dirs: C:\\ghcup\\msys64\\mingw64\\bin, C:\\ghcup\\msys64\\mingw64\\libenter code here
After adding libopenblas.dll location to PATH variable cabal project is working.
Even though there is the --lib flag, it's generally best to work under the assumption that Cabal doesn't do library installs. Never install a library, instead just depend on it – and have Cabal install, update etc. it whenever necessary.
But then how can you pass the necessary flags? With a cabal.project file.
packages: .
package hmatrix
flags: openblas
extra-include-dirs: C:\\ghcup\\msys64\\mingw64\\include\\OpenBLAS
...
Put this file in the working directory of your own project, together with cabalhmatrix.cabal. Then running cabal build in that directory will use a hmatrix install with the suitable library etc. flags.
I am having trouble understanding how the -g flag works in NPM. Specifically I'm struggling to understand how it relates to command-line functionality exposed by NPM modules.
I assumed that the difference between installing a package locally and globally was simply that a local package would not be available outside of the particular project. And of course that a globally installed package would be available in any project. I'm from a Rails background so this for me would be similar to installing a gem into a particular RVM versus installing it into the global RVM. It would simply affect which places it was available.
However there seems to be more significance than just scope in NPM. For packages that have command-line functionality, like wait-on, the package (as far as I can tell) is not available on the command line unless it's installed globally.
Local install doesn't make the command-line functionality available:
$ npm install wait-on
$ wait-on
=> -bash: /usr/local/bin/wait-on: No such file or directory
Global install does expose the command-line functionality
$ npm install wait-on -g
$ wait-on
=> Usage: wait-on {OPTIONS} resource [...resource]
Description:
wait-on is a command line utility which will wait for files, ports,
sockets, and http(s) resources to become available (or not available
using reverse flag). Exits with success code (0) when all resources
are ready. Non-zero exit code if interrupted or timed out.
Options may also be specified in a config file (js or json). For
example --config configFile.js would result in configFile.js being
required and the resulting object will be merged with any
Can you expose the command-line functionality using a local install?
Is it possible to install locally but also get the command line functionality? This would be very helpful for my CI setup as it's far easier to cache local modules than global modules so where possible I'd prefer to install locally.
If you are using npm 5.2.0 or later, the npx command is included by default. It will allow you to run from the local node modules: npx wait-on
For reference: https://www.npmjs.com/package/npx
I think you can access locally installed modules from the command line only if you add them to your "scripts" section of your package.json. So to use the locally installed version of wait-on, you can add an entry in "scripts" section of package.json like so "wait-on": "wait-on". Then to run it, you would have to do npm run wait-on. You can also do "wo": "wait-on" and then do npm run wo basically meaning what comes after the run is the script entry. In node_modules, there is a .bin folder and inside of this folder is all the executables that you can access this way.
Installing locally makes the package available to the current project (where it stores all of the node modules in node_modules). This is usually only good for using a module like so var module = require('module'); or importing a module.
It will not be available as a command that the shell can resolve until you install it globally npm install -g module where npm will install it in a place where your path variable will resolve this command.
You can find a pretty decent explanation here.
It is also useful to put commands in the scripts block in package.json as it automatically resolve local commands. That means you could have a script that depended on a package without having an undocumented dependency on the same.
If you need to run it locally on cmd, you have to go inside the node_modules and run from the path.
If there a relatively simple way to make go + libxml2 + gokogiri work on windows?
I mean that I may be can install it (but at the moment I can not, stuck with Package libxml-2.0 was not found in the pkg-config search path), but then I need to provide my utilite to other people, who will never be able (or would wish ) to install lall libxml2 dependencies, modify PATH etc on windows...
It work flawless on Ubuntu...
I found this https://github.com/moovweb/gokogiri/issues/49 thats funny with installation of Gimp 2 (what?!), but I still cannot make it run with such error, I guess might be issue with PATH, but all PATH are set
$ go get github.com/moovweb/gokogiri
# github.com/moovweb/gokogiri/help
Documents\go\src\github.com\moovweb\gokogiri\help\help.go:6:25: fatal error: lib
xml/tree.h: No such file or directory
#include <libxml/tree.h>
^
compilation terminated.
# github.com/moovweb/gokogiri/xpath
Documents\go\src\github.com\moovweb\gokogiri\xpath\expression.go:4:26: fatal err
or: libxml/xpath.h: No such file or directory
#include <libxml/xpath.h>
^
compilation terminated.
You are struggling because it is hard to combine packages that were built by different people for different purposes and get your environment set up correctly. I think it is best to use MSYS2, an environment for Windows that provides a consistent set of packages for things like gcc, go, libxml2, and iconv. MSYS2 has a package manager (pacman) that helps you easily install them and keep them updated.
I don't do much programming with Go, but I am familiar with MSYS2 and it seems like I was able to get gokogiri installed using MSYS2. You should open MSYS2's "MinGW-w64 Win64 Shell" from the Start menu (mingw64_shell.bat), and try running these commands:
pacman -S mingw-w64-x86_64-{gcc,go,libxml2,iconv}
export GOROOT=/mingw64/
export GOPATH=/c/Users/David/Documents/goproj/
mkdir -p $GOPATH
go get github.com/moovweb/gokogiri
I think GOPATH should be set to the directory of your project. If you run into an error, it might be because some pacman package is required that I didn't list here.
The string mingw-w64-x86_64-{gcc,go,libxml2,iconv} gets expanded by Bash into the following list of packages:
mingw-w64-x86_64-gcc
mingw-w64-x86_64-go
mingw-w64-x86_64-libxml2
mingw-w64-x86_64-iconv
If you are actually using 32-bit Windows, replace x86_64 with i686 in the instructions above.
If you are curious, the scripts for building those packages are here: https://github.com/Alexpux/MINGW-packages
As a disclaimer, I haven't actually compiled any go programs in MSYS2, so there could be big problems I am unaware of.
Also, one of the main developers of MSYS2 (alexpux) said this in the #msys2 IRC chat on 2015-06-21:
We not build go for a long time.
This package in very WIP state
Also see
https://github.com/Alexpux/MINGW-packages/issues/421
So you might need to fix some issues with the MSYS2 Go package and recompile it yourself to really make this work. But you have the PKGBUILD script that was used to build it, so maybe that will be less hard than what you are trying to do right now, which involves compiling/collecting every dependency of gokogiri.
MSYS2 would make your other installation of go, libxml2, and iconv obsolete. You can delete those things once you get your MSYS2 environment working.
If you are using visual studio and want to add dependency to your project then just install it using NuGet Package Manager it's easiest method.
Install command: Install-Package libxml2
Just did a fresh install on my MacBook with Mavericks. I'm using Yeoman and grunt to compile my project. After reinstalling and pull down the code from the repo, I see this error:
Warning: LoadError on line ["55"] of /Library/Ruby/Site/2.0.0/rubygems/core_ext/kernel_require.rb:
cannot load such file -- app/bower_components/compass-breakpoint/lib/breakpoint
Run with --trace to see the full backtrace Use --force to continue.
I'm requiring Breakpoint in my gruntfile.js. If i remove the require, everything compiles as expected, without errors.
Let me know if I can provide any more details. Thanks
So the error appears to be caused by you not pointing to the correct file (that's what the cannot load such file error means), so double check that your import path is correct, but at the moment, you must use Breakpoint through Ruby Compass as it requires a bit of Ruby code in order to function properly. With Sass 3.3 available, this Ruby dependency goes away Breakpoint gets updated, but it will require a compiler compatible with Sass 3.3 (libsass, what powers grunt-sass, is not compatible with Sass 3.3, for instance).
I would encourage you to use grunt-contrib-compass, use Bundler to manage Ruby version dependencies, and compile through Ruby Compass. These steps should resolve your issues.
Would suggest to go with NPM breakpoint. For installing:
npm install breakpoint-sass & add require 'breakpoint' in your config.rb file.