Using Compass watch In Non-Rails project Hangs - configuration

I'm using compass with a non-Rails project. I have a config file at:
config/compass.rb
My config file looks like this:
http_path = "/"
css_dir = "./example"
sass_dir = "./example/sass"
images_dir = "./example/images"
javascripts_dir = "./example/js"
output_style = :compressed
relative_assets = true
And I'm starting Compass using:
compass watch -c config/compass.rb
When I run this, compass just hangs. If I run compass using --trace and quit, I get the following stack-trace:
^CInterrupt on line ["18"] of /Users/me/.gem/ruby/2.0.0/gems/compass-rails-2.0.0/lib/compass-rails.rb:
/Users/me/.gem/ruby/2.0.0/gems/compass-rails-2.0.0/lib/compass-rails.rb:116:in `configuration'
/Users/me/.gem/ruby/2.0.0/gems/compass-1.0.0.rc.1/lib/compass/configuration/helpers.rb:21:in `configuration_for'
/Users/me/.gem/ruby/2.0.0/gems/compass-core-1.0.0.rc.1/lib/compass/configuration.rb:139:in `add_configuration'
/Users/me/.gem/ruby/2.0.0/gems/compass-1.0.0.rc.1/lib/compass/configuration/helpers.rb:79:in `add_project_configuration'
/Users/me/.gem/ruby/2.0.0/gems/compass-1.0.0.rc.1/lib/compass/commands/project_base.rb:37:in `add_project_configuration'
/Users/me/.gem/ruby/2.0.0/gems/compass-1.0.0.rc.1/lib/compass/commands/project_base.rb:25:in `configure!'
/Users/me/.gem/ruby/2.0.0/gems/compass-1.0.0.rc.1/lib/compass/commands/project_base.rb:15:in `initialize'
/Users/me/.gem/ruby/2.0.0/gems/compass-1.0.0.rc.1/lib/compass/commands/update_project.rb:41:in `initialize'
So it appears that rather than using the compass gem, calling compass watch is using compass-rails which expects configuration arguments I'm not supplying and hangs.
$ which compass returns: /Users/me/.gem/ruby/2.0.0/bin/compass
Why is this and how can I work around it?

To get this working I used Bundler and ran:
$ be compass watch -c ./config/compass.rb
Note be is an alias for bundle exec.
I'm still unsure how compass-rails was hooking into compass.

Related

Why rustc did not include libmariadb into release binary?

I thought rust compiler uses static binding and includes all the dependent libraries at compile time (hence executable size).
But when I've tried to use compiled binary in a docker scratch image with actix, mysql client and diesel with mysql feature enabled this error pops up:
error while loading shared libraries: libmariadb.so.3: cannot open shared object file: No such file or director
My dockerfile:
FROM rust:1.43 as builder
WORKDIR /var/app
RUN apt-get update && apt-get install -y libclang-dev clang libmariadb-dev-compat libmariadb-dev
COPY Cargo.toml Cargo.lock diesel.toml ./
COPY src src
RUN cargo install diesel_cli --no-default-features --features mysql
RUN cp /usr/local/cargo/bin/diesel diesel
RUN cargo build --release
FROM ubuntu
USER 1000
WORKDIR /var/app
COPY --from=builder --chown=1000:1000 /var/app/target/release/sniper_api app
COPY --from=builder --chown=1000:1000 /var/app/diesel diesel
CMD ["./app"]
My cargo:
[dependencies]
actix-rt = "1.0.0"
actix-web = "2.0.0"
actix-http = "1.0.1"
serde = { version = "1.0.112", features=["derive"] }
dotenv = "0.15.0"
config = "0.10.1"
diesel = { version = "1.4.2", features = ["mysql","r2d2"]}
futures = "0.3.5"
r2d2 = "0.8.8"
r2d2_mysql = "18.0.0"
env_logger = "0.7.1"
But if I use ubuntu/debian/etc. image as runtime and install libmariadb-dev-compat libmariadb-dev everything is fine. Is there a way to get true single binary with mysql connector in Rust?
I thought rust compiler uses static binding and includes all the dependent libraries at compile time (hence executable size).
This only applies for Rust libraries. For other languages, there is generally little rustc can do.
In particular in this case, diesel provides mysql/mariadb support via the mysqlclient-sys crate for which there currently is an issue and an accompanying PR open to support static linking for this library. But they haven't been merged yet.

Run gulp via cake Start-Process

I'm building site via gulp inside a windows container:
mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-1909
The container have nodejs and gulp-cli installed in it as following (in Dockerfile):
#Install NodeJs
RUN (New-Object Net.WebClient).DownloadFile('https://nodejs.org/dist/v12.16.3/node-v12.16.3-win-x64.zip', 'node.zip'); \
Expand-Archive -LiteralPath 'node.zip' -DestinationPath '.' ; \
Start-Process -FilePath '.\node-v12.16.3-win-x64\npm' -NoNewWindow -Wait -ArgumentList 'install -g gulp-cli' ; \
$env:PATH = 'c:\tools\node-v12.16.3-win-x64;' + $env:PATH; \
[Environment]::SetEnvironmentVariable('PATH', $env:PATH, [EnvironmentVariableTarget]::Machine);
As you can see I'm installing node in the container under c:\tools\node-v12.16.3-win-x64.
In my cake script i try to execute gulp file as following:
StartProcess("cmd", new ProcessSettings {
Arguments = "/c gulp",
WorkingDirectory = projectDir)
});
But seems that Start-Process cannot find the file... I'm getting this output from cake Start-Process:
Executing: "cmd" /c gulp
'gulp' is not recognized as an internal or external command
Running the container interactive I can see the file it is in that place and if I run gulp from projectDir all works.
I've also try it to run it like all of the following forms without success:
StartProcess("powershell", new ProcessSettings {
Arguments = "gulp",
WorkingDirectory = projectDir)
});
StartProcess("gulp");
StartProcess("gulp.cmd");
This is the output from within the container regarding npn, gulp versions (requested from comments):
EDIT:
That 'Local version: Unknown' seems off. Is C:\code your project directory?
When I look at the 'official' gulp configuration steps, the installation results in having both a CLI and local version.
(see: https://gulpjs.com/docs/en/getting-started/quick-start/ )
You could consider using Cake.Gulp which can help run gulp with cake either from a local or global installation:
Namespace: https://cakebuild.net/api/Cake.Gulp/
Example usage: https://cake-contrib.github.io/Cake.Gulp/docs/usage/examples
Perhaps making sure that npm installed gulp locally might do the trick because cake is expecting a local variant. I am unfortunately inexperienced with cake, so this is my best guess after doing some basic research.
(one of my sources: Why do we need to install gulp globally and locally? )
Original answer
You could try using an absolute path to the gulp application.
For example:
StartProcess("cmd", new ProcessSettings {
Arguments = "/c c:\tools\node-v12.16.3-win-x64\gulp",
WorkingDirectory = projectDir)
});
It could be that your environment is not set properly, I found this that could be of use: Appending to PATH in a Windows Docker container

qemu-native error when building core-image-minimal with yocto

I want to build the core-image-minimal with yocto and it fails. To set everything up I use the following steps:
sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath socat cpio python python3 python3-pip python3-pexpect cmake
git clone git://git.yoctoproject.org/poky.git poky.git
cd poky.git
git checkout -b morty remotes/origin/morty
. oe-init-build-env
cd ..
git clone https://github.com/altera-opensource/meta-altera.git meta-altera
cd meta-altera
git checkout -b angstrom-v2015.12-yocto2.0 remotes/origin/angstrom-v2015.12-yocto2.0
Afterwards I add the path to meta-altera to build/conf/bblayers.conf and MACHINE = "cyclone5" to build/conf/local.conf. I would expect, that now bitbake core-image-minimal would run through, but it stops with the following error:
WARNING: qemu-native-2.7.0-r1 do_populate_sysroot: File '/mydirectory/poky.git/build/tmp/sysroots/x86_64-linux/usr/share/qemu/openbios-ppc' from qemu-native was already stripped, this will prevent future debugging!
WARNING: qemu-native-2.7.0-r1 do_populate_sysroot: File '/mydirectory/poky.git/build/tmp/sysroots/x86_64-linux/usr/share/qemu/openbios-sparc32' from qemu-native was already stripped, this will prevent future debugging!
WARNING: qemu-native-2.7.0-r1 do_populate_sysroot: File '/mydirectory/poky.git/build/tmp/sysroots/x86_64-linux/usr/share/qemu/openbios-sparc64' from qemu-native was already stripped, this will prevent future debugging!
WARNING: qemu-native-2.7.0-r1 do_populate_sysroot: File '/mydirectory/poky.git/build/tmp/sysroots/x86_64-linux/usr/share/qemu/s390-ccw.img' from qemu-native was already stripped, this will prevent future debugging!
WARNING: qemu-native-2.7.0-r1 do_populate_sysroot: File '/mydirectory/poky.git/build/tmp/sysroots/x86_64-linux/usr/share/qemu/u-boot.e500' from qemu-native was already stripped, this will prevent future debugging!
ERROR: qemu-native-2.7.0-r1 do_populate_sysroot: runstrip: ''strip' --remove-section=.comment --remove-section=.note '/mydirectory/poky.git/build/tmp/work/x86_64-linux/qemu-native/2.7.0-r1/sysroot-destdir/media/sln/Data/yocto/poky.git/build/tmp/sysroots/x86_64-linux/usr/share/qemu/palcode-clipper'' strip command failed with 1 (b"strip: Unable to recognise the format of the input file `/mydirectory/poky.git/build/tmp/work/x86_64-linux/qemu-native/2.7.0-r1/sysroot-destdir/mydirectory/poky.git/build/tmp/sysroots/x86_64-linux/usr/share/qemu/palcode-clipper'\n")
I got rid of the warnings by adding INSANE_SKIP_qemu-native = "already-stripped" to poky.git/meta/recipes-devtools/qemu/qemu.inc but the error remains. I am using Ubunut 16.04 as my build machine. Any help or tipps are appreciated.
If I continue building, I get an error while building gcc-runtime-6.2.0-r0 do_compile and it stops. I assume that this error is based on the qemu error.
Here is the build config shown in bitbake:
Build Configuration:
BB_VERSION = "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "cyclone5"
DISTRO = "poky"
DISTRO_VERSION = "2.2.1"
TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard"
TARGET_FPU = "hard"
meta
meta-poky
meta-yocto-bsp = "morty:924e576b8930fd2268d85f0b151e5f68a3c2afce"
meta-altera = "angstrom-v2015.12-yocto2.0:3cfd56bb15673795435cf7684ef9c723283a6bce"
It looks like you're checking out the Yocto 2.0 branch of the meta-altera layer. Yocto 2.0 was Jethro. You're checking out the Morty branch of Poky which is Yocto 2.2. Try checking out the jethro branch of Poky with by executing the following Git command while in your poky.git folder:
git checkout -b jethro remotes/origin/jethro

Installation error for DBD::MySQL on OSX v10.6.6

I'm attempting to get DBD::MySQL working on Snow Leopard (v10.6.6). The default version of Perl that comes with the OS is v5.10.0. Since I've read that's 64-bit, I went ahead and downloaded and installed a 64-bit version of MySQL (mysql-5.5.8-osx10.6-x86_64).
Installing and setting up MySQL went smoothly, here's my config and version number for reference.
I used CPAN to download DBI and the DBD::MySQL drivers. I then:
Installed DBI
Setup a Makefile.PL
Ran the make command from the command line
The Makefile.PL said it would use the following settings for compiling and testing:
I will use the following settings for compiling and testing:
cflags (mysql_config ) = -I/usr/local/mysql/include -Os -g -fno-common -fno-strict-aliasing -arch x86_64
embedded (mysql_config ) =
libs (mysql_config ) = -L/usr/local/mysql/lib -lmysqlclient -lpthread
mysql_config (guessed ) = mysql_config
nocatchstderr (default ) = 0
nofoundrows (default ) = 0
ssl (guessed ) = 0
testdb (default ) = test
testhost (default ) =
testpassword (User's choice) = r00t!
testsocket (default ) =
testuser (User's choice) = root
To change these settings, see 'perl Makefile.PL --help' and
'perldoc INSTALL'.
Multiple copies of Driver.xst found in: /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBI/ /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level/auto/DBI/ at Makefile.PL line 907
Using DBI 1.616 (for perl 5.010000 on darwin-thread-multi-2level) installed in /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBI/
Writing Makefile for DBD::mysql
Everything seemed to be going fine, until I tried to run make test :
t/00base....................NOK 2/6# Tried to use 'DBD::mysql'.
# Error: Can't load '/Users/swm/.cpan/build/DBD-mysql-4.018-Pnd2qz/blib/arch/auto/DBD/mysql/mysql.bundle' for module DBD::mysql: dlopen(/Users/swm/.cpan/build/DBD-mysql-4.018-Pnd2qz/blib/arch/auto/DBD/mysql/mysql.bundle, 2): Library not loaded: libmysqlclient.16.dylib
# Referenced from: /Users/swm/.cpan/build/DBD-mysql-4.018-Pnd2qz/blib/arch/auto/DBD/mysql/mysql.bundle
# Reason: image not found at /System/Library/Perl/5.10.0/darwin-thread-multi-2level/DynaLoader.pm line 207.
# at (eval 7) line 2
# Compilation failed in require at (eval 7) line 2.
# BEGIN failed--compilation aborted at (eval 7) line 2.
FAILED--Further testing stopped: Unable to load DBD::mysql
make: *** [test_dynamic] Error 9
It's failing because it can't seem to find the mysql.bundle for DBD. Has anyone come across this problem? Or can point me in the right direction on what to try next? I need DBI/DBD::MySQL for my new job and I'm scrambling to find a solution.
Many thanks in advance.
I got around the "Library not loaded: libmysqlclient.16.dylib" problem by placing a symbolic link in /usr/lib/" to /usr/local/mysql-5.5.8-osx10.6-x86_64/lib/libmysqlclient.16.dylib
I worked around the same or a similar issue. Somehow I could build and test DBD::mysql with cpan but when I tried to use it in a script it said things like
dyld: lazy symbol binding failed: Symbol not found: _mysql_init
Referenced from: /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle
Expected in: flat namespace
Apparently, it's a 64-bit vs 32-bit issue.
Installing the fink dbd-mysql-pm5100 package made it work though it took kind of a long time. I also removed the cpan-installed version:
sudo rm -rf /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBD/mysql
sudo rm -rf /Library/Perl/5.10.0/darwin-thread-multi-2level/DBD/mysql
sudo rm -rf /Library/Perl/5.10.0/darwin-thread-multi-2level/DBD/mysql.pm
also include in .profile
export VERSIONER_PERL_PREFER_32_BIT=yes;
Besides creating the link the executions of the program with DBI::mysql generated an error, thus including this variable on the environment make it works
I know this is an old post. But I suppose the best solution would be to add the library directory to the DYLD_FALLBACK_LIBRARY_PATH env variable. (reason here: https://stackoverflow.com/a/3172515/119958 )
There is no ldconfig in mac, so just add the path to this env var and rerun the install process for DBD::mysql
Donato-Vianas-MacBook-Pro:Invoicer donato$ cpanm DBD::mysql
--> Working on DBD::mysql
Fetching http://www.cpan.org/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.022.tar.gz ... OK
Configuring DBD-mysql-4.022 ... OK
Building and testing DBD-mysql-4.022 ... FAIL
! Installing DBD::mysql failed. See /Users/donato/.cpanm/build.log for details.
# Failed test 'use DBD::mysql;'
# at t/00base.t line 21.
# Tried to use 'DBD::mysql'.
# Error: Can't load '/Users/donato/.cpanm/work/1359948144.491/DBD-mysql-4.022/blib/arch/auto/DBD/mysql/mysql.bundle' for module DBD::mysql: dlopen(/Users/donato/.cpanm/work/1359948144.491/DBD-mysql-4.022/blib/arch/auto/DBD/mysql/mysql.bundle, 2): Library not loaded: libmysqlclient.18.dylib
Donato-Vianas-MacBook-Pro:Invoicer donato$ export DYLD_FALLBACK_LIBRARY_PATH=/usr/local/mysql/lib/:$DYLD_FALLBACK_LIBRARY_PATH
Donato-Vianas-MacBook-Pro:Invoicer donato$ cpanm DBD::mysql--> Working on DBD::mysql
Fetching http://www.cpan.org/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.022.tar.gz ... OK
Configuring DBD-mysql-4.022 ... OK
Building and testing DBD-mysql-4.022 ... OK
Successfully installed DBD-mysql-4.022
1 distribution installed
Donato's solution works for install, but the var has to be present at runtime as well or I get the same error. The following fixes this at runtime for shell and _www user:
# For command line use, add following line to ~/.bash_profile:
export DYLD_FALLBACK_LIBRARY_PATH=/usr/local/mysql/lib/:$DYLD_FALLBACK_LIBRARY_PATH
# If Apache needs it, add following line to /etc/apache2/httpd.conf:
# On Lion Server, I put it after <IfDefine MACOSXSERVER>, but shouldn't matter
SetEnv DYLD_FALLBACK_LIBRARY_PATH /usr/local/mysql/lib/:$DYLD_FALLBACK_LIBRARY_PATH
It's somewhat of an aside, but I strongly recommend setting up a separate perl on the machine -- either by fink / macports, or from source -- and leaving the Mac's system perl (and its libraries) alone.
Once I did this on my own Mac, I had very few troubles installing modules thereafter, and I didn't have to worry about accidentally blowing a hole in my OS by breaking the perl that the system uses.
If it were my Mac, I'd install a new perl from source (the Perl source distribution is smart enough to install itself see that it's on a Mac and install itself safely into /usr/local/bin) and the proceed from thee to install DBD::Mysql (and the other modules you require).

Rails keeps trying to use SQLite , despite that I've configured MySQL for my project

I setup my rails project "tracks" using:
$ rails --database=mysql tracks # OK
$ cd tracks
$ vim config/database.yml # correct using mysql adapter, added password spec
$ rake db:create RAILS_ENV='development' # OK
$ rake db:migrate # OK
$ ruby script/generate scaffold user name:string password:string email:string url:string # OK
$ rake db:migrate # OK, creates table
$ ruby script/server # OK, starts WEBrick
I open up the thing in a web browser:
http://localhost:3000 # correctly shows the rails welcome splash
I navigate to
http://localhost:3000/users/new
and get a huge slew of errors:
ActiveRecord::StatementInvalid in UsersController#index
SQLite3::SQLException: no such table: users: SELECT * FROM "users"
RAILS_ROOT: /home/drew/tracks/trunk/tracks
Application Trace | Framework Trace | Full Trace
vendor/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:188:in `log'
vendor/rails/activerecord/lib/active_record/connection_adapters/sqlite_adapter.rb:132:in `execute'
vendor/rails/activerecord/lib/active_record/connection_adapters/sqlite_adapter.rb:372:in `catch_schema_changes'
vendor/rails/activerecord/lib/active_record/connection_adapters/sqlite_adapter.rb:132:in `execute'
vendor/rails/activerecord/lib/active_record/connection_adapters/sqlite_adapter.rb:275:in `select'
vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:7:in `select_all_without_query_cache'
vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:60:in `select_all'
vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:81:in `cache_sql'
vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:60:in `select_all'
vendor/rails/activerecord/lib/active_record/base.rb:635:in `find_by_sql'
vendor/rails/activerecord/lib/active_record/base.rb:1490:in `find_every'
vendor/rails/activerecord/lib/active_record/base.rb:589:in `find'
app/controllers/users_controller.rb:5:in `index'
wtf? Why is ruby still trying to use SQLite? database.yml has zero mention of SQLite.
Thanks
Couldn't figure it out. I ended up reinstalling the OS on the VM and trying again and it worked.
FYI: Do not install rubygems from a package manager like apt-get. Compile it from source or it will all end in tears.
Had this problem, I found all of the files using "find . | xargs grep 'sqlite3' -sl then replaced all of the yml and rb files it found then restarted the server.
Unfortunately, I don't know which (if any, as it may have been the server restart) solved the issue, but now I'm on and up.
Hope that helps someone, however 'hacky'.
Quick Fix that i've used is...
When i start a project a specify the -d for database
rails -d mysql ProjectName
Which builds the database.yml file for mysql
hope this helps.
As odd as it might sound, try clearing your browser's cookies. I had a similar problem moving from sqlite to postgresql and vice versa. It turns out the stored cookie or session was somehow making the server get stuck in using the old database. If this works then you'll want to take steps on your server to invalidate any existing cookies in your users' browsers.
Don't mean to necro, but if someone runs onto this problem, edit your config/database.yml file, and remove the line that says << default from the production section. What this is doing is loading the default environment first, so Passenger loads it instead of whatever else you've configured.