I have a working Clojure-1.4.0 / emacs24 / leiningen-2.0 tool chain working on Mac OSX 10.8. I got it going very quickly by following the instructions at the following URLs:
http://clojure.org/getting_started
https://github.com/technomancy/leiningen
http://clojure-doc.org/articles/tutorials/emacs.html
One way I check that it works is I go to a project directory and type
lein test
and it runs all the unit tests in my project directory. I can also do C-c , in clojure-mode in emacs, and it does the same thing. Great! Now the question: all this runs the clojure installation I have in ~/clojure-1.4.0, which I see by typing
lein repl
in a project directory. I have a new installation of clojure in ~/clojure-1.5.0 now, and I would like to make leiningen and emacs point to that new version. However, during the setup of leiningen and the emacs mode, I never manually told them where to find the clojure version. They found that magically and opaquely -- in fact, the whole process was very magic, and that was great at that time. I suppose I could tear everything down and build it up again from scratch, but that seems brute-forcedly inefficient. I could also hack-replace the files in the 1.4 directory with the files from the 1.5 directory. That might work one time, but it's so obviously wrong I really don't want to think about it. I need to do this the right way so that when the next version updates come along, I can keep the toolchain going as smoothly as possible.
I am just starting with all this, so I am far from mastery of any of these tools and I'll be grateful for noob-level advice on keeping it all going.
Just change clojure version in ./project.clj in your project directory:
:dependencies [... [org.clojure/clojure "1.5.0"] ...]
test:
$ lein repl
user=> *clojure-version*
{:major 1, :minor 5, :incremental 0, :qualifier nil}
Edit:
They found that magically and opaquely
Default clojure version is built into lein's project.clj template which renders to your <name>/project.clj file when you do lein new <name>.
Related
I am trying out Manjaro Arm on my Raspberry Pi 3, but surprisingly find only Guile as the only viable Scheme interpreter/REPL.
I have tried the following:
Racket, and Mit-Scheme not found by pacman in the repositories.
Chicken Scheme seems to install, but will only run as the Chicken compiler, the csi REPL is MIA.
Chibi Scheme seems to compile and install fine (and make test ran fine before make install) but then crashes looking for a support file (libchibi-scheme.so.0).
Chez-Scheme is X86 centric, and no arm fork has been created yet. Historically older versions also ran on Sun SPARC. I did not try to compile or install it.
I would prefer a scheme REPL that is supported by Geiser, running within Emacs.
A couple of years later, and with a new install of Manjaro on a RPi4 (aarch64) I now have managed to install and get the following working:
Racket will compile from source. I had to use the "unix source" only, since "unix source + built packages" still crashed at the attempt at compiling. Compiling the full racket (including DrRacket) source took a few hours on the pi.
Chicken CSI is in the repositories under chicken-csi. A soft link in /usr/local/bin with the name csi fixes geiser's search for csi.
Exporting LD_LIBRARY_PATH as an env variable with the location of the chibi-scheme library ( /usr/local/lib/ by default ) makes chibi-scheme fully functional. Chibi-scheme compiled easily on the Rpi4.
Gambit Scheme seems to be in the repositories, although I have not played with it much.
Of course Guile 2.2 is in the repositories and works fine.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I have used Emacs for almost 40 years and little has been as frustrating as the repeatedly broken cider packages in melpa-stable.
I have only two entries in my package list
package-archives is a variable defined in ‘package.el’.
Its value is
(("gnu" . "http://elpa.gnu.org/packages/")
("melpa-stable" . "http://melpa.milkbox.net/packages/"))
For some time before today I had been using cider-0.17.0-SNAPSHOT with the corresponding nrepl version number. But I did an update in the Emacs package manager which loaded a cider-0.17-0-SNAPSHOT with yesterdays date (22 Jan 2018).
Now starting cider with cider-jack-in in every project (10+) which was working yesterday yields a "ERROR: Unhandled REPL handler exception processing message" and a huge stack trace.
Interestingly if you replace the nrepl dependency in project.clj with an older version, e.g. [[cider/cider-nrepl "0.16.0"], cider-jack-in starts but gives the warning that cider and cider-nrepl versions differ and "things will break"
So, after many hours of work, I have gone from what was a working cider-0.17.0-SNAPSHOT system (until the melpa-stable Jan 22 update to cider-0.17.0-SNAPSHOT) to once again working cider-0.16.0 system.
So where is the corruption happening? The melpa-stable tag on GitHub is 0.16.0, yet somehow with only melpa-stable (+ gnu) in my package list the broken 0.17.0-SNAPSHOT is getting loaded.
Without perhaps a lot of Git pain I really don't need I can't find the diffs between the pre-Jan22 cider-0.17.0-SNAPSHOT and the Jan22 SNAPSHOT.
So the only option is to go back to manually installing cider-0.16.0 and going back to the corresponding nrepl version. But it was all working very well with cider-0.17.0-SNAPSHOT before someone corrupted melpa-stable with a broken SNAPSHOT.
Broken shit does not belong in melpa-stable.
How do we fix melpa-stable to be stable?
For a very long time now, CIDER hasn't needed any clojure-side configuration if you run cider-jack-in. Get rid of anything related to nrepl, and cider in your project.clj and lein profiles.clj and CIDER should start working out of the box.
Also, if you want melpa-stable then you probably also want to use the full release of CIDER, not some snaphot. CIDER 0.16.0 is what is on melpa stable now and it works fine for me.
UPDATE: I see you're actually using the straight-up melpa, which is not melpa-stable (that has "http://stable.melpa.org/packages/" as the url)
What you do wrong here is you specify Cider's version directly in you project file. Please do not do that. Every single project may require its own Cider version whereas in Emacs you may have only one version installed at once. So switching between them dynamically would be a mess.
The solution is to specify Cider package not in project.clj but in ~/.lein/profiles.clj file. Here is mine:
~> cat ~/.lein/profiles.clj
{:user {:signing {:gpg-key "........."}
:plugins [[cider/cider-nrepl "0.15.1"]]}}
In my Emacs, I've got the version 0.15.1 installed manually from the releases Git page.
This file does not affect your Git history at all. Lein tool merges it to the project.clj content automatically when it starts. Moreover, now you can work with the only one Cider installed across all of your projects. Please remove all the Cider package declarations from your project.clj files.
Once you have time, please read the official Lein profile manual.
I'm running Leiningen in Counterclockwise in Eclipse (Windows, if it's relevant).
The thing is, when I run Leiningen from the command prompt, it runs just fine. However when I run it inside Eclipse, although it runs fine it haunts me with the following warning:
Java HotSpot(TM) Client VM warning: TieredCompilation is disabled in this release.
The only relevant thing I found on the Internet is this. However the solution doesn't work for me as I don't have this line in lein.bat file. I've tried fiddling with Java options in lein.bat to enable TieredCompilation explicitly with no avail. I'm trying to understand - what's different when Eclipse runs lein, compared to when I run it from the prompt, how does it run it? How do I hide this message?
EDIT: this warning seems to appear only in 32-bit JVM; for anyone having the same problem, using 64-bit JVM solves it. For anyone that as to use 32-bit JVM for whatever reason, I'm still looking for a good solution.
(converted from comment as I have to add additional info)
CCW uses its own version of Leiningen - for example, when I execute lein version from inside CCW I get 2.5.1, but if I drop to the command line and execute the same command I get 2.7.1. In my install (Neon + CCW - couldn't make the standalone CCW install work) there's a leiningen-standalone.jar in C:\eclipse\plugins\ccw.core_0.35.1.STABLE001. There may be a way to get Counterclockwise to use a separate version of Leiningen - perhaps more knowledgeable users will chime in with how to do this.
Also note that in the Windows install of Leiningen the LEIN_JVM_OPTS environment variable isn't defined at all in lein.bat, although it is used when invoking Java. Thus it seems you have two options:
Less-preferred option: edit lein.bat and add the definition of LEIN_JVM_OPTS, probably somewhere near the beginning of the file. This has the disadvantage that when you upgrade Leiningen you'll lose your definition of LEIN_JVM_OPTS and have to find this message again.
More-preferred option: since this is Windows you can go into Control Panel, type "environ" in the search box, then click on on the "Edit environment variables for your account" link which comes up under System (or click on "Edit the system environment variables" if you like). Create a new entry for LEIN_JVM_OPTS, specifying something like
-XX:-TieredCompilation
and you should be good to go. While I don't know for certain if this environment variable is used by the standalone .jar version of Leiningen I'd certainly hope and expect it would be.
Best of luck.
I'm a newbie with Clojure and Counterclockwise and I succeeded adding a Leiningen 2 project with "Poor man's integration" (External tools, linked from question Using Clojure and Leiningen with IDEs).
My alternatives for running tests so far:
From command line : lein test
Running "lein test" with "Poor man's integration" (External tool)
These work pretty fine but I'm wondering whether there's some smoother alternative, for example showing the tests run like with JUnit etc?
Or with more general formulation, how to have fluent TDD flow with Counterclockwise?
Another alternative I found (with clojure.test API) was loading the test file in REPL (Alt+Cmd+S) and calling run-tests:
(run-tests)
With some trying, I can re-run the tests with my modifications by loading the modified file to REPL and calling run-tests again. (Works but isn't probably the final solution)
Midje with autotest in REPL seems to be worth checking out.
One way to do this is to use cljunit as an interface between the JUNit runner in Eclipse and your Clojure tests.
I have downloaded a project which uses sbt as its build system and I want to build it. You'd think it would be as simple as typing "sbt" or something, but no.
I thought I'd add a question for this because it can take literally hours to figure this out on your own. I'm not joking.
tl;dr:
sbt compile
If you want to run it:
sbt run
To see what other targets are available:
sbt tasks
To get some (other) help, but mostly targeted at commands typed from the sbt console (ie, running sbt without parameters):
sbt help
This all assumes sbt version >= 0.10.0. To see what version of sbt is in use, do:
grep sbt.version project/build.properties
If there's no such file, and there's a file with extension ".sbt" on the base directory (not the project directory), then it's >= 0.10.0. Of course, if the grep works, it should tell you the version.
First, you'll want to use sbt-extras, because that automatically downloads and uses the right version of sbt. Trying to use the wrong version of sbt (newer or older than what the project you're trying to build says it requires) won't necessarily work, and may cause strange errors.
Run it:
~/path/to/sbt-extras/sbt
Wait for it to start up and download everything. If you need to use an authenticated proxy, you'll need to edit the script to specify the username and password for the proxy.
Check the version of Scala that sbt thinks it needs to build against (at the end of the output, if everything worked). If this is OK, fine, you don't need to do anything. If it isn't, you can temporarily specify a version explicitly with ++, e.g.:
++2.8.1
(If you want to make this permanent, you can edit the build definition files, but as that involves making a change to files under version control, that might not be what you want to do.)
Now, if you are using an older version of sbt, don't skip the next step! You could get strange errors if you do.
update
Now you can build and test what you've built:
test
If you get an error "Filename too long", this is not an sbt-specific problem, it's a scala problem, which most frequently affects Ubuntu users (technically, for Unbuntu users it's generally related to home directories encrypted with encfs). If you are using Scala >= 2.9, edit the build to use the scalac command-line option that allows you to specify a maximum filename length. Otherwise, if you are on Linux, you can redirect the build to /dev/shm or /tmp, by running these commands in a shell prompt (don't background sbt with CTRL+Z on Unix, because it may appear to stop working properly):
rm -rf target
ln -s /dev/shm target
(you may have to execute these commands in project/build instead or as well.)
Actually, it's probably better, and may even be more secure, to create a subdirectory of /dev/shm or /tmp and use that instead.
The compilation result should appear in target. You might then want to run it, if it's something you can run:
run
If everything looks OK, you can optionally publish the result locally so that the result can then be picked up automatically by other sbt builds:
publish-local
I don't think I could explain it better that the Getting Started Guide could. Please read the first 6 parts of it, which shouldn't too long time, to get it up and running.