Compiling latest ClojureCLR
Miron Brezuleanu
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
dmiller
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 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.
The more final solution will be an installer that takes care of all of
this.
The dependency on vjslib should be gone in no more than a week. I'm
just finishing an implementation of BigDecimal that will render vjslib
unnecessary. This will also enable the folks interested in Mono to
start playing.
I'll amend the install page on the wiki with some of your more
detailed steps. Thanks.
-David
On Oct 31, 5:58 am, Miron Brezuleanu <mbr...@gmail.com> wrote:
> Hello,
>
> 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).
>
>
> Cheers,
> --
> Miron Brezuleanu
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
dmiller
commit of the DLR.
>> 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.
The only major piece of the core not completed is genclass. The main
items on the agenda at the moment:
1) Finish BigDecimal to remove vjslib dependency (should be done in a
few more days).
2) Implementing genclass
3) Creating an installer
4) Converting clojure.contrib
Item (3) can be done by anyone with appropriate .Net skills.
Item (4) requires Clojure app programmer knowledge more than Clojure
internals knowledge.
- David
dmiller
no longer has a dependency on the Visual J# Redistributable (vjslib).
I think this removes the last barrier to those wanting to play with
ClojureCLR on Mono. (All two of you.) :)
--David