Only found when eval'ing.

(defn f [] (new DateTime)) ; works
(def d (new DateTime)) ; does not work

Eval of NewExpression calls Reflector/InvokeConstructor, which does not handle the default c-tor for value types.

(new DateTime) throws with badprogramexception
This is only a problem on the default ctor.

Needed in order to allow the ilmerge command in build.proj to work properly.
In Clojure.csproj:

<PropertyGroup>
<SignAssembly>true</SignAssembly>
<AssemblyOriginatorKeyFile>$(CLOJURE_SNK)</AssemblyOriginatorKeyFile>
</PropertyGroup>

From Devin Garner:

... adding this line to GetFindFilePathsRaw in RT.cs ?

static IEnumerable<string> GetFindFilePathsRaw()

Since RT is inside Clojure.dll, it will allow any file in the same folder as Clojure.dll to be found. The specific instance I found a need of this was an app that referenced Clojure.dll but the .exe was in a different folder than Cloure.dll. Somehow the .exe new where to find Clojure.dll, but nothing else.

java.math.BigDecimal has a c-tor overload that takes a string argument.
In ClojureCLR, clojure.lang.BigDecimal does not.
Either fix bigdec or add a c-tor to BigDecimal.
Check other c-tor overloads while we're at it.

Submitted by Devin Garner

(defn load-reader
"Sequentially read and evaluate the set of forms contained in the
stream/file"
{:added "1.0"
:static true}
[rdr] (. clojure.lang.Compiler (load rdr)))
//calling load on Compiler doesn't work, because the arity is wrong.

//in Compiler.cs
public static object load(TextReader rdr, string relativePath)

leiningen on the JVM uses a small library called bultitude to search the classpath for namespaces. To acheive the same functionality in ClojureCLR we would need to add some descriptive information to the compiler generated _Init_$.

I'm suggesting adding a System.ComponentModel.DescriptionAttribute with a clojure readable string of information describing what namespace(s) this init type loads. This would allow someone to query all the loaded assemblies for namespaces, without necessarily trying to load all of them. Oftentimes the namespace itself is slightly different than what the init type would imply - for instance _Init_$clojure/pprint/column_writer is for the namespace clojure.pprint.

The attached patch, adds a DescriptionAttribute based on the final value of RT.CurrentNSVar after compiling. Conceivably, a single file could load several namespaces, but this seems like a rare case - it could be handled, however, by adding a watch to RT.CurrentNSVar. If this seems useful, the patch can be modified to use this method.

In order to create signed assemblies using GenContext, we need to be able to pass it an AssemblyName parameter. This enables us to set KeyPair as well as other useful properties such as Version and Culture of AssemblyName. The attached patch changes the constructor and adds another overload to CreateWithExternalAssembly - maybe a little messy, but the best I could think of.

From AaronC:
I just found an issue with how exceptions are handled in namespace loading. I see that you put a catch clause for AssemblyInitializationException in Compiler.TryLoadInitType that basically swallows this exception and returns false. I don't think this is desirable. This causes exceptions with loading AOT compiled namespaces to be very difficult to debug. Wouldn't it be better to just let any exceptions thrown by InvokeInitType pass through and be reported? Now I'm getting a FileNotFoundException when really there is an AssemblyInitializationException being thrown and silenced.

When a namespace fails to load, a stack trace for just the require/load itself is shown - the actual cause is wrapped and hard to uncover. Putting a println statement in the catch clause of clojure.core/load-lib is one possible fix for this, but then two stack traces are displayed. Still, this may be worthwhile because debugging these errors can be a headache.

InvalidCastException provides no information on the type that was trying to be cast.

The "factorial-1" example from Mark Volkmann's tutorial gives an error when run on ClojureCLR. The error is shown below:

c:\cljdev\clojure-clr-1.4.0-Debug-4.0\Debug 4.0>Clojure.Main.exe c:\users\amyers
\Desktop\factorial-1.clj

Unhandled Exception: System.MissingMethodException: Cannot find member box match
ing args
at CallSite.Target(Closure , CallSite , Object , Int64 )
at CallSite.Target(Closure , CallSite , Object , Int64 )
at user$factorial_1_5._interop_box7(Object , Int64 __temp_1)
at user$factorial_1__5.invoke(Object ) in eval:line 1
at user$eval_9_14.invoke() in eval:line 9
at clojure.lang.Compiler.eval(Object form) in D:\work\clojure-clr\Clojure\Clo
jure\CljCompiler\Compiler.cs:line 871
at clojure.lang.Compiler.load(TextReader rdr, String sourcePath, String sourc
eName, String relativePath) in D:\work\clojure-clr\Clojure\Clojure\CljCompiler\C
ompiler.cs:line 1385
at clojure.lang.Compiler.loadFile(String fileName) in D:\work\clojure-clr\Clo
jure\Clojure\CljCompiler\Compiler.cs:line 1342
at clojure/main$load_script__20722.invoke(Object ) in main.clj:line 301
at clojure/main$script_opt__20794.invoke(Object , Object ) in main.clj:line 3
62
at clojure/main$main__20838.doInvoke(Object ) in main.clj:line 446
at clojure.lang.RestFn.invoke(Object arg1) in D:\work\clojure-clr\Clojure\Clo
jure\Lib\RestFn.cs:line 468
at clojure.lang.Var.invoke(Object arg1) in D:\work\clojure-clr\Clojure\Clojur
e\Lib\Var.cs:line 741
at clojure.lang.AFn.ApplyToHelper(IFn fn, ISeq argList) in D:\work\clojure-cl
r\Clojure\Clojure\Lib\AFn.cs:line 191
at clojure.lang.Var.applyTo(ISeq arglist) in D:\work\clojure-clr\Clojure\Cloj
ure\Lib\Var.cs:line 874
at Clojure.CljMain.Main(String[] args) in D:\work\clojure-clr\Clojure\Clojure
.Main\Main.cs:line 34

I start the repl and run my ClojureCLR as follows:

Clojure.Main.exe -i initscript -r

Clojure.Main.exe -i initscript -m foo.core

The file initscript looks like this:

(set! *warn-on-reflection* true)

The value set in the initscript is not carried over to the repl or run session. When I embed the line

(set! *warn-on-reflection* true)

When I run Clojure.Compile.exe on a .clj file in the current directory, it claims that it is "Compiling program to .", but no assemblies appear. After a bit of searching, I discovered that the output assemblies are being dropped into the directory containing Clojure.Compile.exe!

(This is a duplicate of https://github.com/richhickey/clojure-clr/issues/55, but it's unclear whether we should report things here or there.)

Protected internal methods are not considered for overriding in NewInstanceExpr and GenClass.

For ASP.NET applications, the search path for .clj and .clj.dll files needs to include CurrentDomain.BaseDirectory and its 'bin' subdirectory.

(import [System.Environment.SpecialFolder]) ;return nil
(SpecialFolder/Personal)
;return CompilerException System.InvalidOperationException: Unable to find static field: Personal in clojure.lang.Compiler.AnalyzeSymbol(Symbol symbol) d:\work\clojure-clr\Clojure\Clojure\Cljcompiler\Compiler.cs: line 1518,compiling: (NO_SOURCE_PATH:15)

This patch adds support for:

1) Loading .clj files from .NET assemblies as embedded resources.

2) AOT compiling multiple Clojure namespaces into a single .NET assembly. To do this the _Init_ class name has to be unique for each assembly. Actual compilation of multiple namespaces into .DLL's would be done by a separate tool such as ILMerge or nleinigen.

3) Loading a clojure namespace from a custom path other than that specified by its namespace. This is useful for loading .clj files at the repl that are being integrated into existing .NET projects as embedded resources. For example say my namespace is MyCompany.MyProject.MyNamespace and I want to integrate it into the C# project MyProject as an embedded resource. I create the file SolutionFolder\MyProject\MyNamespace.clj on the disk. As long as the default namespace for MyProject is MyCompany.MyProject, the file will actually be stored as an embedded resource with the path Clojure expects (MyCompany.MyProject.MyNamespace.clj). But, from the repl, we need to tell Clojure to load namespaces beginning with MyCompany.MyProject from SolutionFolder\MyProject. The function add-ns-load-mapping (whose name I'm not attached to) does this.

It would be nice to have a nice high-level wrapper class for key Clojure integration functions. In IronPython for example, there is a IronPython.Hosting.Python class. For ClojureCLR, I created the attached clojure.lang.Hosting.Clojure class which provides three simple functions Require, GetVar, and AddNamespaceLoadMapping (for integrating .clj files into .NET assemblies as embedded resources). This class or one like it is a simple suggestion to make integration with existing code as painless as possible.

Sample usage:

Clojure.GetVar("clojure.main", "main").invoke(); // Starts an embedded Clojure REPL

This is much simpler than:

Symbol CLOJURE_MAIN = Symbol.intern("clojure.main");
Var REQUIRE = RT.var("clojure.core", "require");
REQUIRE.invoke(CLOJURE_MAIN);
RT.var("clojure.main", "main").invoke().

I've compiled the Clojure-CLR-1.4.1 code from the Github repository using the 'Release' configuration.

When I run the REPL I get a lot of duplicated warnings. I've pasted the warnings below.

C:\Users\Frank.Hale\Desktop\clojure-clr-1.4.1>Clojure.Main.exe
Reflection warning, C:\Users\Frank.Hale\Desktop\clojure-clr-1.4.1\clojure\core\protocols.clj:139 - call to aget can't be resolved.
Reflection warning, C:\Users\Frank.Hale\Desktop\clojure-clr-1.4.1\clojure\core\protocols.clj:139 - call to aget can't be resolved.
Reflection warning, C:\Users\Frank.Hale\Desktop\clojure-clr-1.4.1\clojure\core\protocols.clj:139 - call to aget can't be resolved.
Reflection warning, C:\Users\Frank.Hale\Desktop\clojure-clr-1.4.1\clojure\core\protocols.clj:139 - call to aget can't be resolved.
Reflection warning, C:\Users\Frank.Hale\Desktop\clojure-clr-1.4.1\clojure\core\protocols.clj:139 - call to aget can't be resolved.
Reflection warning, C:\Users\Frank.Hale\Desktop\clojure-clr-1.4.1\clojure\core\protocols.clj:139 - call to aget can't be resolved.
Reflection warning, C:\Users\Frank.Hale\Desktop\clojure-clr-1.4.1\clojure\core\protocols.clj:139 - call to aget can't be resolved.
Reflection warning, C:\Users\Frank.Hale\Desktop\clojure-clr-1.4.1\clojure\core\protocols.clj:139 - call to aget can't be resolved.
Reflection warning, C:\Users\Frank.Hale\Desktop\clojure-clr-1.4.1\clojure\core\protocols.clj:139 - call to aget can't be resolved.
Reflection warning, C:\Users\Frank.Hale\Desktop\clojure-clr-1.4.1\clojure\core\protocols.clj:139 - call to aget can't be resolved.
Reflection warning, C:\Users\Frank.Hale\Desktop\clojure-clr-1.4.1\clojure\core\protocols.clj:139 - call to aget can't be resolved.
Reflection warning, C:\Users\Frank.Hale\Desktop\clojure-clr-1.4.1\clojure\core\protocols.clj:139 - call to aget can't be resolved.
Clojure 1.4.1
user=>

This patch adds missing support for IntPtr and UIntPtr to HostExpr so that interaction with Native code via P/Invoke can be fully supported. This is a hand modified squashed diff, so please use git apply rather than git am to apply it.

I tried out the Clojure-CLR binary for .NET 4.0 on Mono 2.10.8.1 on 64-bit Mac OS X (Lion) and it seems to work for the basic things on the REPL. Please consider releasing a binary for Mono, or mention in the README if the existing binaries are supposed to work on Mono.