Clojure JIRA

[CLJCLR-22] Reflector/InvokeConstructor should handle default c-tor for value types

Sat, 18 May 2013 22:23:50 -0500

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.

[CLJCLR-21] Improper code gen for (new valuetype)

Sat, 18 May 2013 17:38:28 -0500

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

[CLJCLR-20] Allow (optional) signing of Clojure.dll.

Sat, 11 May 2013 10:54:01 -0500

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>

[CLJCLR-19] Enhance path probing for load to include the same folder as Clojure.dll

Sun, 5 May 2013 08:58:39 -0500

From Devin Garner:

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

static IEnumerable<string> GetFindFilePathsRaw()

{ yield return Path.GetDirectoryName(typeof(RT).Assembly.Location); // new line }

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.

[CLJCLR-17] In JVM, clojure.core/bigdec can take a string. Not so in CLR.

Sun, 5 May 2013 08:53:24 -0500

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.

[CLJCLR-18] core/load-reader invokes Compilr.load with wrong # of args

Sun, 5 May 2013 08:37:47 -0500

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)

[CLJCLR-13] Add namespace DescriptionAttribute to init type

Wed, 27 Mar 2013 21:40:34 -0500

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.

[CLJCLR-12] Add AssemblyName overload to GenContext

Wed, 27 Mar 2013 21:19:33 -0500

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.

[CLJCLR-16] Compiler.TryLoadInitType should not catch AssemblyInitializationException

Wed, 27 Mar 2013 20:54:08 -0500

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.

[CLJCLR-10] Errors when requiring a namespace do not contain useful stacktrace

Tue, 12 Mar 2013 23:33:29 -0500

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.

[CLJCLR-9] Need better error message for clojure.core/cast

Tue, 12 Mar 2013 17:09:56 -0500

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

[CLJCLR-4] Error running recursion example from

Tue, 12 Mar 2013 16:45:55 -0500

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

[CLJCLR-5] Global vars set! by the init script is reset to original state by Clojure.Main.exe

Tue, 12 Mar 2013 08:36:35 -0500

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)

into the target Clojure file, the newly set value is recognized.

[CLJCLR-3] Clojure.Compile treats compile path of "." as the Clojure install path

Tue, 12 Mar 2013 08:26:14 -0500

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.)

[CLJCLR-15] Protected internal methods are not considered for overriding.

Mon, 11 Mar 2013 22:41:41 -0500

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

[CLJCLR-14] ASP.NET apps cannot find .clj and .clj.dll files

Mon, 11 Mar 2013 22:15:13 -0500

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

[CLJCLR-2] (System.Environment.SpecialFolder/Personal) ;Return: CompilerException System.InvalidOperationException: Unable to find static field: Personal

Wed, 6 Mar 2013 22:03:05 -0600

(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)

[CLJCLR-8] Enhance compiler support for loading namespace from .NET assemblies

Wed, 6 Mar 2013 21:25:36 -0600

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.

[CLJCLR-11] Simplify integration of Clojure code with existing .NET code

Wed, 6 Mar 2013 20:42:29 -0600

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().

[CLJCLR-6] "protocols.clj:139 - call to aget can't be resolved." warnings when running REPL

Sun, 3 Mar 2013 22:05:59 -0600

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=>

[CLJCLR-7] HostExpr does not support IntPtr and UIntPtr

Thu, 28 Feb 2013 22:20:37 -0600

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.

[CLJCLR-1] Support Mono as a target platform

Thu, 24 Jan 2013 16:43:03 -0600

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.