I am trying to find a nice solution working on two different compass projects. One is based off Compass using Blueprint (older version), and the other is based on susy grid (newer version).
Currently, I have to reinstall the right version for the watch process.
Is it possible to run compile with a specified version? It would be great if it is also possible to run a watch process with a specified version.
Running it as
compass _0.10.5_ compile
will do what you want. (Where you put in the desired version in place of 0.10.5, obviously.)
The tool you're looking for is probally rvm which allows you to have different versions of ruby/gems installed and easily switch between them.
Perhaps there's a simpler way.
If you can use something like Codekit or Livereload, those tools allow you to used embedded sass libraries or define your own.
That you could use the builtin libraries for one project and your custom ones for other projects.
RVM suggested above also works i believe but never tried myself.
Related
Why do I need to install so much just to use Susy or about any sass framework?
I got really interested in using sass and sass frameworks but I can't figure out a right way to start using it. I don't get why I need to have so much installed to use just one thing. Also, I have never installed something through some sort of terminal so this freaks my out immensely, why can't I just download a zip file.
If know a useful tutorial on where to start, that would also help.
thanks in advance
Your Mac already comes with a version of Ruby (with Sierra even a recent enough version). Unless you are actively develping on different versions of Ruby, you don't need to install a custom Ruby (or even a ruby version manager).
You probably still need a compiler. Here, the xcode command line tools are sufficient. You can install them with xcode-select --install.
Generally, all these tools are comand-line oriented. It will help you tremendously if you try to get at least a high-level understanding of how the command line works and how you can use it with your tools. This will also help you when it comes to deploy your solution to a live-server, often running Linux with just the command line.
Compass is not required for Susy. In fact, Compass is no longer maintained, so I highly recommend against using it. Susy only requires Sass, but you can use any flavor of Sass - Libsass, Ruby Sass, Node Sass, Gulp Sass, etc. If it compiles Sass, it will work with Susy. There are instructions for various setups in the Susy docs.
Susy also doesn't require command-line knowledge itself, though Sass is often compiled that way. There are tools that provide GUI wrappers for Sass, if you aren't comfortable in the command line. I think CodeKit ships with Susy included.
I already searched on the net a way to update the SQLITE3 version of Xcode, but I didn't found any working way. It is a way to do it?
If you want to use your own version of sqlite3, perhaps because you want to use newer features only provided by a later version, then probably the best thing to do would be to create an Xcode static library project to build sqlite3 and then include that library with your app (statically linked). This will avoid using the system version.
This should be fairly trivial, given the number of source files that make-up sqlite3.
You could probably make a dynamic library version, but that's slightly more complicated, though certainly possible.
Why should I/should I not use RVM?
I'm new to the ruby language and servers as a whole. I've had some trouble installing using RVM...so I'm inclined to not use it right now, but it seems like it may make installations down the road easier?
I'm interested to hear about your experience with RVM and your thoughts as it pertains to maintaining a server.
RVM is useful even if you don't want to install multiple versions at the same time. I'm a ruby hobbyist (PHP during the day :(), and I have no reason to want to use old versions, but I still use RVM.
Installing ruby is a pain. Getting it from the package manager (at least in ubuntu) gives you an outdated version that changes installation directories from the defaults. I've had nothing but problems with it.
So you think, "I'll just build it from source". Building from source requires getting a load of dependencies and configuring options. Often times I've built ruby only to find out I forgot to enable SSL support or readline support.
RVM takes care of all of this. In 3 or so commands, you have a perfectly built version of ruby.
And I didn't even cover how RVM manages multiple ruby installations for you, which is its killer feature. If you have that need, there is really no other sane solution.
RVM is great as this allows your to install different versions without touching your system's default Ruby install. It is rather similar to virtualenv's in Python.
Another great advantage to having RVM are the gemsets - you can create as many gemsets that are unique to the version, and patch level, of ruby.
I've extolled some of its virtues here and you should also see this blog post.
In terms of maintaining a server - let's take a Passenger install for example; do remember that Passenger is installed as a gem, so with rvm the benefit here is that you can have multiple installs of passenger, tied to a different version of ruby. Of course, typically, you'll have Passenger running on one version at a time, although there are ways to have Passenger, in particular, running on different ruby versions.
I use different Ruby versions for different projects (that's where .rvmrc is really handy). Some deployment environments are happy with 1.9, while there are a couple of legacy servers using 1.8 for some reasons. Also, occasionally I want to launch a specific version of ruby to compare how they work. RVM does all that for me.
When you are first getting used to Ruby, it may not entirely be necessary. That said, what it does is set you up for success in the future. Because once you get hooked, you may end up playing with projects that need to move from, say, MRI 1.8.x to 1.9.x. Or from 1.9.x, to JRuby 1.6.x. My experience is that this happens irregularly, but when it does, there's no substitute for RVM.
Outside of that, the other biggest feature that I use regularly, is the ability to segment one particular release. So I can have an environment for 'stable' gems, and an environment for 'unstable' gems. For instance, while Rails 3.1 has been in release candidate mode, I've had one main workspace for 1.9.2 and a separate space for Rails 3.1.rc? gems on 1.9.2. That makes it possible for me to keep developing my main Rails 3.0 stuff (with one command at the CLI), without having to specify full file paths to the appropriate rails bin files in order to use the older files.
If you're using a Debian based platform where the packagers/policy leads to a really bad default installation you'll have a way better experience using rvm.
How can I try CoffeeScript on Windows?
The installation instructions are only for *nix: http://jashkenas.github.com/coffee-script/#installation
EDIT:
Since I asked this a while ago, many new answers have appeared. The number ( and quality ) of options for Windows users has been increased a lot. I "accepted" an answer a long time ago, then changed to other ( better ) answers as they came up, but I have now decided to not accept any answer, and let the community ( votes ) show which answers are best. Thanks to everyone for the input.
UPDATE: See my other answer to this question, How can I compile CoffeeScript from .NET? for a far more accurate and up-to-date list of the current options.
CoffeeScript-Compiler-for-Windows works well.
Maybe it was more complicated when this question was posted. But as of 2012, CoffeeScript is as easy to use on any platform. The instructions are the same for Windows, Mac, or Linux
Install Nodejs from http://nodejs.org/
Install CoffeeScript globally with the node package manager npm install -g coffeescript or locally npm install --save-dev coffeescript
Write a script in your favourite text editor. Save it, say as hello.coffee
Run your script coffee hello.coffee or compile it coffee -c hello.coffee (to hello.js)
Node.js runs on Cygwin these days, so that's probably your best bet with getting CoffeeScript running on Windows. I'd try that first.
If you have a different preferred JavaScript runtime, you can probably use the prebuilt-compiler (extras/coffee-script.js). For example, if you include that script on a webpage, you can call
CoffeeScript.compile(code);
... to get back the compiled JavaScript string.
UPDATE 2012-04-12: Cygwin is no longer needed to run Node on Windows. Microsoft
worked with Joyent through 2H 2011 to improve node's support for
Windows IOCP async IO. Node 0.6 was the first release of node to
natively support Windows.
You can run the CoffeeScript compiler under good old Window Script Host (cscript.exe), a standard component on Windows since Windows 98. Admittedly I tried this a while back and it didn't work, but I tried again recently and now all the standard CoffeeScript tests compile just fine.
A bit of plumbing code using a *.wsf file and coffee-script.js is all you need. My code is on GitHub: https://github.com/duncansmart/coffeescript-windows
I blogged about it here: http://blog.dotsmart.net/2011/06/20/the-simplest-way-to-compile-coffeescript-on-windows/
You can use jcoffeescript as a command-line solution.
It uses a Java-based javascript engine (Rhino) and wraps up the task of compiling coffee-script.js from the CoffeeScript project. This allows it to run the CoffeeScript compiler as a Java program.
The command to use (on Windows/Linux) looks like this:
java -jar jcoffeescript-1.0.jar < foo.coffee > foo.js
You will need to download & build the Java source code (use IntelliJ Community Edition to avoid downloading Ant) or a pre-built download for CoffeeScript v1.0.
I now use jcoffeescript in place of the Ruby solution (another answer here), because this allows me to keep up with the latest CoffeeScript version.
You can use a command-line version of CoffeeScript by installing Ruby on Windows and then installing the CoffeeScript Gem.
After that, the command-line is available, for example, 'coffee bla.coffee' - to compile your CoffeeScript code down to JavaScript code.
The only disadvantage doing it this way (not using Node.js) is that the Ruby version of CoffeeScript is restricted to version 0.3.2 - the last version written in Ruby before it was moved over to Node.js.
*However, I still use the Ruby version of CoffeeScript in my current employment and my personal web page and I don't see much of a problem as this version of CoffeeScript is quite mature and most of the features listed on the CoffeeScript website can be used.
*striked out this last statement which was correct at the time but is becoming more incorrect every few days; CoffeeScript has now advanced a long way since 0.3.2 and is past 1.1
There're already bunch of answers here, but let me add mine. I wrote a .NET library for compiling CoffeeScript on Windows.
As jashkenas suggested, I've used the pre-compiled extras/coffee-script.js file.
Together with the Jurassic JavaScript compiler I've wrapped it all up in a single library: CoffeeSharp
The library also ships with a commandline tool and a HttpHandler for ASP.NET web development.
I've used this one: https://bitbucket.org/maly/coffeescript-win/zealots
looks working well, althouth you need to manually need to update coffee.script from 0.95 to 1.0.1.
Since node.js is now ported to Windows, this is actually pretty easy:
http://www.colourcoding.net/blog/archive/2011/09/20/using-coffeescript-on-windows.aspx
If you want to use CoffeeScript in an ASP.NET application then you can use this HTTP handler to serve compiled CoffeeScript code.
I haven't tried this myself yet, but it seems to be an answer. (I've downloaded and installed but not used it yet.)
There's an add-in for Visual Studio 2010 that adds CoffeeScript editing to VS (among other things).
It's called Web Workbench and is downloaded as a vsix. (i.e. can be downloaded from within the VS UI.)
I'm only putting this in only as an answer to the more general implied question for "How can I try" tools that don't normally run on Windows or have yet to be ported. Use a virtual machine running a UNIX-like OS such as Linux or BSD.
Provided you have enough RAM and are willing to learn enough to get around, it will make trying open source software a lot easier. In the CoffeeScript case you can still do things like --watch on a shared folder and remain in Windows land most of the time. You also won't pollute your system with tools and services you try and don't buy into, which is handy if you do that a lot.
Consider using Chocolatey to install http://chocolatey.org/packages/CoffeeScript on Windows.
(Installing Chocolatey : https://github.com/chocolatey/chocolatey/wiki/Installation)
At work I'm using Perl 5.8.0 on Windows.
When I first put Perl on, I went to CPAN, downloaded all the sources, made a few changes (in the .MAK file(?) to support threads, or things like that), and did nmake / nmake test / nmake install. Then, bit by bit, I've downloaded individual modules from CPAN and done the nmake dance.
So, I'd like to upgrade to a more recent version, but the new one must not break any existing scripts. Notably, a bunch of "use" modules that I've installed must be installed in the new version.
What's the most reliable (and easiest) way to update my current version, ensuring that everything I've done with the nmake dance will still be there after updating?
As others noted, start by installing the new perl in a separate place. I have several perls installed, each completely separate from all of the others.
To do that, you'll have to configure and compile the sources yourself. When you run configure, you'll get a chance to specify the installer. I gave detailed instructions for this in an "Compiling My Own Perl" in the Spring 2008 issue of The Perl Review. There's also an Item in Effective Perl Programming that shows you how to do it.
Now, go back to your original distribution and run cpan -a to create an autobundle file. This is a Pod document that lists all of the extra stuff you've installed, and CPAN.pm understands how to use that to reinstall everything.
To install things in the new perl, use that perl's path to start CPAN.pm and install the autobundle file you created. CPAN.pm will get the right installation paths from that perl's configuration.
Watch the output to make sure things go well. This process won't install the same versions of the modules, but the latest versions.
As for Strawberry Perl, there's a "portable" version you can install somewhere besides the default location. That way you could have the new perl on removable media. You can test it anywhere you like without disturbing the local installation. I don't think that's quite ready for general use though. The Berrybrew tool might help you manage that.
Good luck, :)
I would seriously consider looking at using Strawberry Perl.
You can install a second version of Perl in a different location. You'll have to re-install any non-core modules into the new version. In general, different versions of Perl are not binary compatible, which could be an issue if you have any program-specific libraries that utilize XS components. Pure Perl modules shouldn't be affected.
If you stay within the 5.8 track, all installed modules that contain XS (binary) extensions will continue to work, as binary compatibility is guaranteed within the same 5.8 series. If you moved to 5.10 then you would have to recompile any modules that contain XS components.
All you need to do is ensure that the new build lists the previous include directories in its #INC array (which is used to look for modules).
By the sounds of it, I think you're on Windows, in which case the current #INC paths can be viewed with
perl -le "print for #INC"
Make sure you target your new Perl version in another directory. It will happily coexist
with the previous version, and this will allow you to choose which Perl installation gets used; it's just a question of getting your PATH order sorted out. As soon as a Perl interpreter is started up, it knows where to look for the rest of its modules.
Strawberry Perl is probably the nicest distribution on Windows these days for rolling your own.
I think the answer to this involves virtualisation of some kind:
Set up an exact copy of your current live machine. Upgrade Perl, using the same directory locations and structures as you're using at the moment.
Go through your scripts testing them on the new image.
Once you're happy, flip the switch.
The thinking behind this is that there's probably all sorts of subtle dependencies and assumptions you haven't thought of. While unlikely, the latest version of a particular module (possibly even a core module, although that's even more unlikely) might have a subtle difference compared to the one you were using. Unless you've exhaustively gone through your entire codebase, there's quite possibly a particular module that's required only under certain circumstances.
You can try and spot this by building a list of all your scripts - a list that you should have anyway, by dint of all your code being under version control (you are using version control, e.g. Subversion, yes?) - and iterating through it, running perl -c on each script. e.g. this script. That sort of automated test is invaluable: you can set it running, go away for a coffee or whatever, and come back to check whether everything worked. The first few times you'll probably find an obscure module that you'd forgotten about, which is fine: the whole point of automating this is so that you don't have to do the drudge-work of checking every single script.
When I did it I installed the newer one into a separate directory. There's a bit of added confusion running two versions, but it definitely helps make sure everything's working first, and provides a quick way of switching back to the old one in a pinch. I also set up Apache to run two separate services, so I could monkey around with the newer Perl in one service without touching the production one on the old Perl.
It's probably a lot wiser, in hindsight, to install on a separate computer, and do your testing there. Record every configuration change you need to make.
I am not sure about building it yourself—I always just used prepackaged binaries for Windows.
I'm not sure I understand exactly what you're asking. Do you have a list of changes you made to the 5.8 makefile? Or is the question how to obtain such a list? Are you also asking how to find out which packages above the base install you've obtained from CPAN? Are you also asking how to test that your custom changes won't break those packages if you get them from CPAN again?
Why don't you use ActivePerl and its "ppm" tool to (re)install modules?