What should I use if I want to use less.js locally and have a file automatically recompiled if either this file or an imported file has changed?
lessphp is a LESS compiler written entirely in PHP, making it very easy to run on the server side if you're already using PHP. It was finally just added to Packagist yesterday! You can install it on a project to project basis using composer. Here is an example composer.json file for declaring it as a dependency to your own project:
{
"require": {
"leafo/lessphp": "dev-master"
}
}
You can also use dotless with mono.. if you have mono then run dotless with the -w (watch) option.
You could use watchdog and this script, which I found useful.
To install watchdog, you’ll first need to have the python setup tools installed (apt-get install python-setuptools assuming you’re using Debian or a Debian-based distribution such as Ubuntu).
Then, simply easy_install watchdog. You'll be able to run the lesswatch script once the installation is complete.
Related
Mocha is installed globally on Windows, but cmd shows "mocha is not an internal or external command, nor is it a runnable program or batch file"
Mocha (test framework for Node.js) uses make and on Windows machine, such errors occur a lot. I guess, at the time of execution it's not recognizing the path. So, you can follow any of the 2 below:
1) Install mocha globally(if not done already) so that it works in the regular windows command line:
npm install -g mocha
Then run your tests with mocha path\to\test.js
OR
2) Other way to deal with this is to use Cygwin and ensure that the developer packages for Cygwin are installed.
Read this article, it will help you: https://altamodatech.com/blogs/?p=452
On installation, the location of mocha.cmd is not added to path. If you install globally, as #hemanshu suggests, that location is %APPDATA%\npm. So, you either add that to your path, or (as I do) define an alias; my cmd.exe shortcut loads a script to set the path to things actually useful in the command line, set environment variables, etc, and in there I have this:
#doskey mocha=%APPDATA%\npm\mocha.cmd
I am trying to build a .deb package for an application my company (and me) have been developing.
I'm trying to create a 64bit package on my 32bit ubuntu (12.04 LTS) using dpkg-buildpackage and I get the following warnings/errors:
dpkg-shlibdeps: warning/error: couldn't find library X needed by Y.so (ELF format: 'elf64-x86-64'; RPATH: 'some/path/that/does/not/exist')
When X is one of our compiled shared libraries, we get a warning. When it's a system library (like libgcc_s.so.1 and libstdc++.so.6) we get an error.
Why is the RPATH refers to a path that does not exist?
By the way, when I make a 32bit package (on our files that were compiled for 32bit of course) it only shows warnings (only about our proprietary .so files) but creates the .deb file.
If I could, I would have posted my debian folder content but I cant take files out of our network. I can type the relevant parts if its needed.
You need to install the 64-bits version of the library with apt-get (actually anything do, but this is the most easy):
sudo apt-get install libyouneed-dev:amd64
The trick here is the :amd64, which tells the package manager to install the 64-bit version of that package. The same applies for 32-bits libraries in 64-bit systems. It's called multiarch.
The package is looking at that path because that is where the libraries of 64-bits (or 32-bits) gets stored, but since you don't have it installed the path do not exist.
Install an amd64 chroot environment and build your package in there. This way you avoid the various multi-arch pitfalls, with the added benefit of having a clean, reproducible build.
There is a tool that makes this very easy: mk-sbuild.
You need to install ubuntu-dev-tools and sbuild.
Then, run mk-sbuild --arch=amd64 precise, which will setup the build environment for you.
Add yourself to the sbuild group: adduser <your user name> sbuild
Log out and log back in so your group membership will be reflected.
You can then build your package in the chroot:
sbuild -d precise --arch=amd64 name_of_package.dsc
This assumes you've already build the source package with debuild -S or similar.
When building the project from command line using mvn clean install everything builds without any issues.
When running some tests that use precompiled C libraries from IntelliJ, tests fail with java.lang.UnsatisfiedLinkError
I may be completely off here, but does IntelliJ not see the .so file? Is so, how can it be added please?
Shared library fails to load with UnsatisfiedLinkError if:
it's not in the working directory configured in the test run configuration.
it's not in PATH environment (on Mac Terminal and GUI apps have different environment, see this answer). Run IDEA from the Terminal open -a /Applications/IntelliJ\ IDEA\ 12.app/ to make environment the same.
it's not in the location specified using -Djava.library.path VM option.
.so depends on some other library that is not found for any of the 1-3 reasons (or the dependency of that dependency is not found, etc).
I would like to use an iron.io worker to stich panoramas and create HDRs using the OpenSource Hugin and libpano13 toolkits. The programs needed are all command-line (no GUI is needed) but I'm not entirely sure how I go about building a worker that includes the correct binaries for using the Hugin panotools.
Can I pre-compile the right binaries for the iron.io worker OS (Ubuntu Linux)? I can create a VM and install Ubuntu on it to get a set of binaries built that I include in my worker. But is there a better way using the "build" directive in the worker file? The problem I see right away is that Hugin is a cmake-based build so I'd need to create something that uses autoconf/automake, right?
I don't really need all of Hugin, either. I just need the control point finder utility and the enfuse/enblend utilities for doing the actual stitching. I don't need any of the GUI stuff, which is wxWidgets based.
Can anyone shed light on how I would go about this? Thanks!
You really need only statically compiled x64 binaries, find them anywhere - and you're done.
Possible solutions:
Install stuff on local Ubuntu x64 (IronWorker using 12.04 TLS x64) and include required files into worker's package (which is just .zip file after uploading) (and probably extend PATH at start of a worker)
Use build command to do any installation procedures remotely (you're still limited to non-root operations though)
Use deb command to install existing .deb packages.
.worker file example (including custom version of imagemagick):
runtime 'binary'
exec 'run.sh'
full_remote_build true
deb 'http://mirror.pnl.gov/ubuntu//pool/main/i/imagemagick/libmagickcore5_6.7.7.10-2ubuntu4_amd64.deb'
deb 'http://mirror.pnl.gov/ubuntu//pool/main/i/imagemagick/libmagickwand5_6.7.7.10-2ubuntu4_amd64.deb'
deb 'http://mirror.pnl.gov/ubuntu//pool/main/i/imagemagick/imagemagick_6.7.7.10-2ubuntu4_amd64.deb'
I just built Rakudo and Parrot so that I could play with it and get started on learning Perl 6. I downloaded the Perl 6 book and happily typed in the first demo program (the tennis tournament example).
When I try to run the program, I get an error:
Divide by zero
current instr.: '' pc -1 ((unknown file):-1)
I have my perl6 binary in the build directory. I added a scripts directory under the rakudo build directory:
rakudo
|- perl6
\- scripts
|- perlbook_02.01
\- scores
If I try to run even a simple hello world script from my scripts directory I get the same error:
#!/home/daotoad/rakudo/perl6
use v6;
say "Hello nurse!";
However if I run it from the rakudo directory it works.
It sounds like there are some environment variables I need to set, but I am at a lost as to what the are and what values to give them.
Any thoughts?
Update:
I'd rather not install rakudo at this point, I'd rather just run things from the build directory. This will allow me to keep my changes to my system minimal as I try out different Perl6 builds (Rakudo * is out very soon).
The README file encouraged me to think that this was possible:
$ cd rakudo
$ perl Configure.pl --gen-parrot
$ make
This will create a "perl6" or "perl6.exe" executable in the
current (rakudo) directory. Programs can then be run from
the build directory using a command like:
$ ./perl6 hello.pl
Upon rereading, I found a reference to the fact that it is necessary to install rakudo before running scripts outside the build directory:
Once built, Rakudo's make install target will install Rakudo
and its libraries into the Parrot installation that was used to
create it. Until this step is performed, the "perl6" executable
created by make above can only be reliably run from the root of
Rakudo's build directory. After make install is performed,
the installed executable can be run from any directory (as long as
the Parrot installation that was used to create it remains intact).
So it looks like I need to install rakudo to play with Perl 6.
The next question is, where rakudo be installed? README says into the Parrot install used to build.
I used the --gen-parrot option in my build, which looks like it installs into rakudo/parrot-install. So rakudo will be installed into my rakudo\parrot-install?
Reading the Makefile, supports this conclusion. I ran make install, and it did install into parrot_install.
This part of the build/install process is unclear for a newbie to Perl6. I'll see if I can up with a documentation patch to clarify things.
Off the top of my head:
Emphasize running make install before running scripts outside of build. This requirement is currently burried in the middle of a paragraph and can be easily missed by someone skimming the docs (me).
Explicitly state that with --gen-parrot will install perl6 into the parrot_install directory.
Did you run make install in Rakudo?
It's necessary to do it to be able to use Rakudo outside its build directory (and that's why both the README and http://rakudo.org/how-to-get-rakudo tell you to do it.
Don't worry, the default install location is local (in parrot_install/bin/perl inside your rakudo directory).
In response to your update I've now updated the README:
http://github.com/rakudo/rakudo/commit/261eb2ae08fee75a0a0e3935ef64c516e8bc2b98
I hope you find that clearer than before. If you still see room for improvement, please consider submitting a patch to rakudobug#perl.org.