I've tried compiling the latest ClojureCLR and ... it wasn't easy.
Maybe because my setup is missing stuff (a fresh virtual machine with
Windows Server 2003, Visual Studio 2008 SP1 and the Visual J#
redistributables). Anyway, I managed to come up with a reproducible
list of steps that got me into a ClojureCLR REPL and I'm thinking that
the list of steps may be 1) useful to other people and/or 2) useful to
me because it will trigger emails containing corrections to my
process. If this is the wrong mailing list, please tell me which is
the correct mailing list (I've seen ClojureCLR threads here before,
couldn't find a ClojureCLR mailing list).
So here's my list of steps:
1. Create a 'clojure' directory somewhere convenient (this dir will be
denoted by $CLOJURE below).
2. Download the DLR from
http://dlr.codeplex.com/SourceControl/ListDownloadableCommits.aspx#DownloadLatest
Right now the archive name is dlr-33505.zip, denoting the revision.
The revision numbers will obviously increase.
3. Unzip the DLR archive into $CLOJURE
4. Load the $CLOJURE/DLR_Main/Src/Codeplex-DLR.sln solution in Visual
Studio 2008 SP1.
5. Build it, close Visual Studio.
6. Clone the clojure-clr repository by running
git clone git://github.com/richhickey/clojure-clr.git
in $CLOJURE (the commit I used is f62dd19)
7. Open the $CLOJURE/clojure-clr/Clojure/ClojureCLR.sln solution in
Visual Studio 2008 SP1.
8. Check the references of the Clojure project. If there is a yellow
warning sign next to the 'vjslib' reference, you need to close the
solution, download the VJ# redistributable from
, install it and go to step 7.
9. Check that the projects in the Runtime/ solution folder are loaded.
Seems like this setup is similar to dmiller's - the projects load OK.
10. Since I was not interested in running the ClojureCLR tests, I did
not install nunit or RhinoMocks. So building the whole solution won't
work. Try building the Clojure project.
11. Get 134 errors, very similar to 'The type or namespace name 'Linq'
does not exist in the namespace 'Microsoft' (are you missing an
assembly reference?)'. Scratch head (optional sub-step). Remember that
there is a 'System.Linq.Expressions' in .NET 3.5. Look for
'System.Linq.Expressions' in
Runtime/Microsoft.Scripting.Core/Actions/BinaryOperationsBinder.cs.
The #if directive at the start of the file provides a hint that we may
want to use 'Microsoft.Scripting.Ast' instead (because the DLR
assemblies we're interested in are compiled for .NET 2.0). Use
Control-Shift-F to replace 'Microsoft.Linq.Expressions' with
'Microsoft.Scripting.Ast' across the entire solution. Save all, close
the opened files, try building the Clojure project again.
12. Oh joy. The error count is down to two. Scratch head (again, this
is optional). The errors are similar to 'The type or namespace name
'Utils' does not exist in the namespace 'Microsoft.Scripting.Ast' (are
you missing an assembly reference?)'. Apparently we need
'SimpleCallHelper' from that namespace. Searching for it inside the
DLR solution reveals that it is defined in project 'Microsoft.Dynamic'
in the DLR. Add this project to the 'Runtime' solution folder inside
the ClojureCLR solution (Existing Project, Microsoft.Dynamic.csproj).
Also add a reference to the project to the Clojure project. Try
compiling the Clojure project again.
13. The compilation succeeds. Wonderful. Build the Clojure.Compile
project, then the Clojure.Main project.
14. Run the $CLOJURE/clojure-clr/Clojure/Clojure.Main/bin/Debug/Clojure.Main.exe.
Celebrate getting a Clojure REPL by typing (+ 1 1) or your favourite
Clojure expression.
Cheers,
--
Miron Brezuleanu
On Sat, Oct 31, 2009 at 11:31 PM, dmiller <dmill...@gmail.com> wrote:
>
> Miron,
>
> You discovered what I discovered just a day or two ago: A release or
> two ago. the DLR team made some breaking changes to namespaces and
> moved a key method to another assembly. I'm really upset by the move
> of SimpleCallHelper. I hate to reference the whole Dynamic assembly
> just to pick up one method.
I thought that it was a setup issue (turns out it was a different DLR
version, could have been other things). This is what prompted me to
write the email - I assumed that a clean environment was a chance to
get a clear sequence of steps to make things work.
> I haven't had a chance to update the ClojureCLR source to fix this
> problem. I'll try to get that fixed this weekend. Apologies for your
> pain.
No need to apologize. We're a .NET shop at work and I'd really love to
be able to write some of my money-earning code in Clojure, which would
be impossible without ClojureCLR, so I'm actually very grateful.
Thanks!
> The more final solution will be an installer that takes care of all of
> this.
That sounds interesting. Any plans for clojure.contrib? I'd be really
interested in helping where I can, and porting clojure code to .NET is
something I can do. I'm aware of the fact that Clojure core isn't
ported completely yet, but I think work can proceed in parallel on
core and contrib. Some device to avoid duplicate work on porting
clojure.contrib would be nice.
Thanks again,
--
Miron Brezuleanu