<< Back to previous view

[CLJCLR-32] RT.load does not correctly map namespace to source file or dll name Created: 30/Jun/14  Updated: 30/Jun/14

Status: Open
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Antti Karanta Assignee: David Miller
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When doing (from C#)

RT.load( "my.util", true );

and having directory containing my\util.clj on CLOJURE_LOAD_PATH I get

System.IO.FileNotFoundException: Could not locate my.util.clj.dll or my.util.clj on load path.

I believe the latter is wrong - it should be looking for my\util.clj on load path?

Also, there is a problem with compiled assemblies whose namespace contains -'s. For example, if I have compiled namespace myns.foo-bar (in file myns\foo_bar.clj) it produces myns.foo_bar.clj.dll. If I try to load it like so:

RT.load( "myns.foo-bar", true );
System.IO.FileNotFoundException: Could not locate myns.foo-bar.clj.dll or myns.foo-bar.clj on load path.

I think RT.load should "know" that compiling a namespace with - character in it is mapped to _ on the corresponding dll or source file name.






[CLJCLR-31] ensure improperly locking ref Created: 18/Jun/14  Updated: 21/Jun/14  Resolved: 21/Jun/14

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Greg Chapman Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None


 Description   

For example:

Clojure 1.6.0-beta1
user=> (def r (ref 0))
#'user/r
user=> (dosync (ensure r))
SynchronizationLockException The read lock is being released without being held.  System.Threading.ReaderWriterLockSlim.
ExitReadLock (:0)

I'm fairly certain the call to Lock(r) in LockingTransaction.DoEnsure is incorrect. I believe it should be r.EnterReadLock()



 Comments   
Comment by Greg Chapman [ 18/Jun/14 3:04 PM ]

Also, it seems that Refs' locks have to support recursion (LockRecursionPolicy.SupportsRecursion). An ensured ref has its readlock held; any attempt to deref it (in the same transaction) will attempt to reobtain the readlock (in Ref.currentVal().

Comment by David Miller [ 21/Jun/14 12:30 PM ]

It is correct that the call to Lock(r) in LockingTransaction.DoEnsure should be r.EnterReadLock()instead.
Dates back to a change in the JVM version in 2009. https://github.com/clojure/clojure/commit/961743446562b6fa7be25f96de02aacd626169da
I missed the change in call when I was editing.

This reveals the need for LockRecursionPolicy.SupportsRecursion.

Comment by David Miller [ 21/Jun/14 12:31 PM ]

Fix commited to master.
https://github.com/clojure/clojure-clr/commit/aa688b6dd61ea2b93e5a6486b604fda267a8c1f4





[CLJCLR-30] Invoking parameterless static method with "new" modifier does not work Created: 17/Jun/14  Updated: 21/Jun/14  Resolved: 21/Jun/14

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Antti Karanta Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None
Environment:

Clojure CLR 1.5.0



 Description   

Calling a parameterless static method that has no parameters does not work. Here's how to reproduce:

user=> (import System.Security.Cryptography.MD5)
System.Security.Cryptography.MD5
user=> (MD5/Create)
CompilerException System.MissingMemberException: Member 'MD5.Create' not found.
   at clojure.lang.CljCompiler.Ast.HostExpr.Parser.Parse(ParserContext pcon, Object form) in d:\work
\clojure-clr\Clojure\Clojure\CljCompiler\Ast\HostExpr.cs:line 48
   at clojure.lang.Compiler.AnalyzeSeq(ParserContext pcon, ISeq form, String name) in d:\work\clojur
e-clr\Clojure\Clojure\CljCompiler\Compiler.cs:line 1763, compiling: (NO_SOURCE_PATH:2:1)

Here's some discussion about the topic in the Clojure CLR Google group: https://groups.google.com/forum/#!topic/clojure-clr/qY_Tlk4OYog



 Comments   
Comment by David Miller [ 21/Jun/14 12:11 PM ]

Fixed in commit 885b317, 2014.06.21





[CLJCLR-29] Add links to CLojureCLR ML, G+ community and JIRA to the README. Created: 11/Mar/14  Updated: 22/Jun/14  Resolved: 22/Jun/14

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Trivial
Reporter: David Miller Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None





[CLJCLR-28] compare-and-set! broken Created: 11/Mar/14  Updated: 17/Mar/14  Resolved: 17/Mar/14

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Antti Karanta Assignee: David Miller
Resolution: Declined Votes: 0
Labels: None
Environment:

Clojure CLR 1.5.0 Release 4.0, Windows 7 (64-bit), .NET 4.0.30319.18444



 Description   

Here's a simple sample of using compare-and-swap! on jvm clojure:

user=> (def a (atom 0))
#'user/a
user=> (compare-and-set! a 0 1)
true
user=> @a
1
user=> clojure-version
{:major 1, :minor 5, :incremental 1, :qualifier nil}

Here's what happens on clojure-clr:

user=> (def a (atom 0))
#'user/a
user=> (compare-and-set! a 0 1)
false
user=> @a
0
user=> clojure-version
{:major 1, :minor 5, :incremental 0, :qualifier ""}

The only value I could get it to work correctly with was nil.



 Comments   
Comment by David Miller [ 17/Mar/14 2:00 PM ]

The observed behavior is because the JVM caches small boxed integers and the CLR does not.

compare-and-set! reveals a very low-level implementation detail. Trying to match the behavior exactly is not worth the effort. Prefer swap! to compare-and-set! if it matters.





[CLJCLR-27] Add more support for attributes in gen-class Created: 07/Dec/13  Updated: 23/Jun/14  Resolved: 22/Jun/14

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: David Miller Assignee: David Miller
Resolution: Completed Votes: 1
Labels: None


 Description   

For example, to support COM interop, it would be nice to annotate the gen-class'd class with

[ComImport, Guid("E436EBB3-524F-11CE-9F53-0020AF0BA770")]

We already have attribute support for definterface, deftype, gen-interface, so this should be easy to do.



 Comments   
Comment by Antti Karanta [ 23/Jun/14 2:05 AM ]

Great! Is there any how-to documentation for this feature as of yet?





[CLJCLR-26] Compiler.FnOnceSym initialized in wrong order relative to _duplicateTypeMap Created: 26/Nov/13  Updated: 22/Jun/14  Resolved: 22/Jun/14

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Miller Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None


 Description   

Noted here: https://groups.google.com/forum/#!topic/clojure/1HqVgklTb7w

From Brian Barnes:

Unfortunately, this line:

public static readonly Symbol FnOnceSym = (Symbol) Symbol.intern("fn*").withMeta(RT.map(Keyword.intern(null, "once"), true));

comes before this line:

static Dictionary<String, Type> _duplicateTypeMap = new Dictionary<string, Type>();

The evaluation of the first causes a call to the static method FindDuplicateType() within the same class, and this method uses the _duplicateTypeMap without a null check. This causes a null exception to be thrown because the initializer for _duplicateTypeMap hasn't executed yet.

My solution is to add a section at the very top of the Compiler class for "dependency" intializations - consisiting only of the initialization of _duplicateTypeMap at this point, to give a home to all such initializations that get used by the other static initializers.






[CLJCLR-25] Clojure.Compile.exe create single dll for all compiled .clj files Created: 02/Aug/13  Updated: 14/Sep/13

Status: Reopened
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Devin Garner Assignee: David Miller
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Text File 0001-PATCH-Add-NDesk.Options-ManyConsole-via-NuGet-to-all.patch    
Patch: Code

 Description   

I've created a patch for ClojureCLR that allows the Clojure.Compile.exe to build a single .dll or .exe when given a list of .clj files. This is basically the same concept as the ILMerge, but it gives the benefit to the programmer with a project containing many .clj files, rather than only to clojure.dll itself.

The merged/separate option can be specified at the commandline, so users can choose the previous method if they prefer.

I didn't remove ILMerge from the ClojureCLR build process, but it should theoretically be easy to do if desired.

ILMerge is working, but its license doesn't allow redistribution & would require each programmer to learn to use the tool (unless its built into nLeiningen & vsClojure). It seems better if Clojure.Compile.exe doesn't make tons of dlls in the first place.

The basic usage is:

Clojure.Compile.exe -include test.clj -include test2.clj -outputAssemblyName test.dll
-or-
Clojure.Compile.exe -i test.clj -i test2.clj -o test.dll

If you leave off the -o parameter, it functions the same as previously.



 Comments   
Comment by David Miller [ 14/Sep/13 2:37 PM ]

Simplified CLI to
Clojure.Compile.exe [-o outputAssemblyName] cljFileName...

Comment by David Miller [ 14/Sep/13 3:14 PM ]

I thought I had run the test suite one last time before committing – apparently not. The fix committed as 7745dec blows three tests. One test shows the :arglists metadata on functions has the wrong type. Two other tests error out function-serialization.

In addition, :file metadata went from relative paths to absolute paths, so the metadata in distributed ClojureCLR will show the file paths on my development machine.

I'm going to roll this change back until these are fixed.





[CLJCLR-24] build.proj ILMerge target broken Created: 26/Jul/13  Updated: 26/Jul/13

Status: Open
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Devin Garner Assignee: David Miller
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When running the command

msbuild /t:Ilmerge /p:Configuration="Release 4.0" build.proj

ILMerge gives an error that "edn" is missing. I added "clojure.edn" to the post build events of Clojure.Compile.csproj and the error went away.






[CLJCLR-23] don't prepend *compiler-path* to assembly name in GenClass Created: 22/Jul/13  Updated: 22/Jul/13  Resolved: 22/Jul/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Miller Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None


 Description   

GenClass.GenerateClass should not prepend the compiler-path to the
assembly name that is given to GenContext.CreateWithExternalAssembly;
the latter method already accounts for the compiler-path when
determining where to place the generated assembly.



 Comments   
Comment by David Miller [ 22/Jul/13 10:51 PM ]

Suggested by Matt McGill.





[CLJCLR-22] Reflector/InvokeConstructor should handle default c-tor for value types Created: 18/May/13  Updated: 18/May/13  Resolved: 18/May/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Miller Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by David Miller [ 18/May/13 10:23 PM ]

Special case in Reflector/InvokeConstructor for no infos found, type is Value type, zero args.





[CLJCLR-21] Improper code gen for (new valuetype) Created: 18/May/13  Updated: 18/May/13  Resolved: 18/May/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Miller Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None


 Description   

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



 Comments   
Comment by David Miller [ 18/May/13 5:38 PM ]

Missing a ldloc instruction.





[CLJCLR-20] Allow (optional) signing of Clojure.dll. Created: 11/May/13  Updated: 11/May/13  Resolved: 11/May/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: David Miller Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None


 Description   

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 Created: 16/Apr/13  Updated: 05/May/13  Resolved: 05/May/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: David Miller Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by David Miller [ 05/May/13 8:58 AM ]

Added path to RT.GetFindFilePathsRaw.
Commit: 60cb4c20





[CLJCLR-18] core/load-reader invokes Compilr.load with wrong # of args Created: 16/Apr/13  Updated: 05/May/13  Resolved: 05/May/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Miller Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None


 Description   

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)



 Comments   
Comment by David Miller [ 05/May/13 8:37 AM ]

Added overload of Compiler.load.
Commit: 6fc025f





[CLJCLR-17] In JVM, clojure.core/bigdec can take a string. Not so in CLR. Created: 30/Mar/13  Updated: 05/May/13  Resolved: 05/May/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Miller Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by David Miller [ 05/May/13 8:53 AM ]

Added additional c-tors to clojure.lang.BigDecimal.
Commit: 3b3f21b





[CLJCLR-16] Compiler.TryLoadInitType should not catch AssemblyInitializationException Created: 25/Mar/13  Updated: 27/Mar/13  Resolved: 27/Mar/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Miller Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by David Miller [ 27/Mar/13 8:54 PM ]

https://github.com/clojure/clojure-clr/commit/857731c3e1e689860a50b62bd734318600855f5e





[CLJCLR-15] Protected internal methods are not considered for overriding. Created: 10/Mar/13  Updated: 11/Mar/13  Resolved: 11/Mar/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Miller Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None


 Description   

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



 Comments   
Comment by David Miller [ 11/Mar/13 10:41 PM ]

Fixed in commit 201d83c





[CLJCLR-14] ASP.NET apps cannot find .clj and .clj.dll files Created: 10/Mar/13  Updated: 11/Mar/13  Resolved: 11/Mar/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Miller Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None


 Description   

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



 Comments   
Comment by David Miller [ 11/Mar/13 10:15 PM ]

Fixed in commit 52d58d5





[CLJCLR-13] Add namespace DescriptionAttribute to init type Created: 06/Mar/13  Updated: 27/Mar/13  Resolved: 27/Mar/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Aaron Craelius Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File namespace-desc.patch    
Patch: Code

 Description   

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.



 Comments   
Comment by David Miller [ 27/Mar/13 9:40 PM ]

https://github.com/clojure/clojure-clr/commit/01b46505ac902e3a1ad2167ad0b0e0689d45f716





[CLJCLR-12] Add AssemblyName overload to GenContext Created: 05/Mar/13  Updated: 27/Mar/13  Resolved: 27/Mar/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Aaron Craelius Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File GenContext-AssemblyName-overload.patch    
Patch: Code

 Description   

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.



 Comments   
Comment by David Miller [ 27/Mar/13 9:19 PM ]

https://github.com/clojure/clojure-clr/commit/3da1f6e217fca951011d56524541de431b853250





[CLJCLR-11] Simplify integration of Clojure code with existing .NET code Created: 03/Mar/13  Updated: 06/Mar/13

Status: Open
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Aaron Craelius Assignee: David Miller
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Text File clojure-hosting2.patch     Text File clojure-hosting.patch    
Patch: Code

 Description   

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



 Comments   
Comment by Aaron Craelius [ 06/Mar/13 8:42 PM ]

This is an updated patch that supercedes the previous patch adds an AddToLoadPath method.





[CLJCLR-10] Errors when requiring a namespace do not contain useful stacktrace Created: 03/Mar/13  Updated: 12/Mar/13  Resolved: 12/Mar/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Aaron Craelius Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by David Miller [ 12/Mar/13 11:33 PM ]

The changes to make the loading code throw exceptions rather than catch exceptions and return status codes ( https://github.com/clojure/clojure-clr/commit/e6febd45d53c983d696b83de62cf794be1d165aa ) should have made Exceptions during loading accessible further down the stack (i.e., the REPL).





[CLJCLR-9] Need better error message for clojure.core/cast Created: 03/Mar/13  Updated: 12/Mar/13  Resolved: 12/Mar/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Aaron Craelius Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File core-cast.patch    
Patch: Code

 Description   

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



 Comments   
Comment by David Miller [ 12/Mar/13 5:09 PM ]

Commit 6cdde07





[CLJCLR-8] Enhance compiler support for loading namespace from .NET assemblies Created: 28/Feb/13  Updated: 06/Mar/13  Resolved: 06/Mar/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Aaron Craelius Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-Added-support-for-1-loading-.clj-files-from-.NET-ass.patch    
Patch: Code

 Description   

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.



 Comments   
Comment by David Miller [ 06/Mar/13 9:25 PM ]

https://github.com/clojure/clojure-clr/commit/4aa53b70e40dcc8c92f026615ce4aa86c02c71ee





[CLJCLR-7] HostExpr does not support IntPtr and UIntPtr Created: 28/Feb/13  Updated: 28/Feb/13  Resolved: 28/Feb/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Aaron Craelius Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File hostexpr-intptr+uintptr.patch    
Patch: Code

 Description   

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.



 Comments   
Comment by David Miller [ 28/Feb/13 10:20 PM ]

Patch applied.





[CLJCLR-6] "protocols.clj:139 - call to aget can't be resolved." warnings when running REPL Created: 20/Feb/13  Updated: 03/Mar/13  Resolved: 03/Mar/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Frank Hale Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None
Environment:

Windows 7 x64, .NET 4.5, Clojure-CLR 1.4.1


Attachments: Text File clojure-clr-1.4.1-release-file-listing.txt    

 Description   

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



 Comments   
Comment by Frank Hale [ 20/Feb/13 3:48 PM ]

I compiled from the Clojure-CLR 1.4.1 branch in 'Release' mode and then copied the binaries out to a directory and opened a terminal there to run the REPL. The warnings show before I can type in the REPL.

Comment by David Miller [ 20/Feb/13 3:53 PM ]

Can you send a directory listing?

Also, look at the Clojure 1.4.1 zip at https://github.com/clojure/clojure-clr/downloads and compare the list of dlls.

There should be a clojure.core.protocols.clj.dll.

Comment by Frank Hale [ 20/Feb/13 4:05 PM ]

Okay I have clojure.core.protocols.clj.dll in my build.

I downloaded the 1.4.1 Debug build from https://github.com/clojure/clojure-clr/downloads and it gives me the same warnings.

Comment by Frank Hale [ 20/Feb/13 4:26 PM ]

FWIW, I've attached the file listing of the 1.4.1 release build I made.

Comment by David Miller [ 20/Feb/13 5:09 PM ]

My new guess is timestamps.
If the timestamp on clojure\core\protocols.clj is newer than the one on .\clojure.core.protocols.clj.dll, then the .clj will be loaded.
(If timestamps are same to the discernment of dir, just delete the clojure subdirectory.)

Comment by Frank Hale [ 23/Feb/13 8:42 AM ]

This is reproducable on 2 computers that I use. I'm going to close this because the 1.5.x branch does not do this. I'll just move to 1.5 branch instead.

Comment by Frank Hale [ 27/Feb/13 9:21 AM ]

This can be closed if you want.

Comment by David Miller [ 03/Mar/13 10:05 PM ]

Will do.
Working on finishing 1.5 as fast as I can.

Comment by David Miller [ 03/Mar/13 10:05 PM ]

Reporter indicates this is not a problem in 1.5RC. No intention to revisit this in 1.4.1.





[CLJCLR-5] Global vars set! by the init script is reset to original state by Clojure.Main.exe Created: 16/Dec/12  Updated: 12/Mar/13  Resolved: 12/Mar/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Shantanu Kumar Assignee: David Miller
Resolution: Declined Votes: 0
Labels: None
Environment:

.NET 4.0 Clojure 1.4.0 on Windows 7



 Description   

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.



 Comments   
Comment by David Miller [ 12/Mar/13 8:36 AM ]

This behavior comes from the JVM version of Clojure. Request for change should happen there.

This happens because the initialization is done by a call to Compiler.loadFile, which calls Compiler.load which establishes its own binding for warn-on-reflection, that binding disappearing when the initialization is complete.





[CLJCLR-4] Error running recursion example from Created: 13/Jul/12  Updated: 12/Mar/13  Resolved: 12/Mar/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Andrew Myers Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None
Environment:

Windows 7, 64 bit


Attachments: Text File factorial-1.clj    

 Description   

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



 Comments   
Comment by David Miller [ 12/Mar/13 4:45 PM ]

Fixed in commit ead2496

Missing definition for RT.box.
Been missing for a long time.
Screws up loops that box the loop args.





[CLJCLR-3] Clojure.Compile treats compile path of "." as the Clojure install path Created: 16/May/12  Updated: 12/Mar/13  Resolved: 12/Mar/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Neal Groothuis Assignee: David Miller
Resolution: Completed Votes: 0
Labels: None
Environment:

ClojureCLR 1.3.0 on Windows 7.



 Description   

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



 Comments   
Comment by Neal Groothuis [ 16/May/12 4:36 PM ]

Ah-ha: it appears that this is a duplicate of https://github.com/richhickey/clojure-clr/issues/52, and the behavior was changed in e002ef3. However, it still appears to be at odds with the desired behavior noted at http://clojureclr.blogspot.com/2012/01/compiling-and-loading-in-clojureclr.html; i.e., *compile-path* is still being ignored.

Comment by David Miller [ 12/Mar/13 8:26 AM ]

This was fixed in https://github.com/clojure/clojure-clr/commit/4e4c64ba42bfc45c3062771109cd36ae57a1cc4f

back in January, 2012.





[CLJCLR-2] (System.Environment.SpecialFolder/Personal) ;Return: CompilerException System.InvalidOperationException: Unable to find static field: Personal Created: 28/Feb/12  Updated: 06/Mar/13  Resolved: 06/Mar/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Alex Woods Assignee: David Miller
Resolution: Declined Votes: 0
Labels: .net4.0, 1.3, Clojure-clr, System.Environment.SpecialFolder/Personal
Environment:

Clojure-clr 1.3 .net 4.0



 Description   

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



 Comments   
Comment by David Miller [ 06/Mar/13 10:03 PM ]

SpecialFolder is a nested class of Environment. The actual name is System.Environment+SpecialFolder:

user=> (import '[System Environment+SpecialFolder])
System.Environment+SpecialFolder
user=>
user=>
user=> Environment+SpecialFolder/Desktop
Desktop

It would be nice to have a way to provide an alias, but that's not in Clojure's namespace semantics at the moment.





[CLJCLR-1] Support Mono as a target platform Created: 11/Jan/12  Updated: 24/Jan/13  Resolved: 24/Jan/13

Status: Resolved
Project: ClojureCLR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Shantanu Kumar Assignee: David Miller
Resolution: Completed Votes: 1
Labels: mono
Environment:

Mono 2.10.8.1 on 64-bit Mac OS X (Lion)



 Description   

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.






Generated at Wed Jul 30 22:27:03 CDT 2014 using JIRA 4.4#649-r158309.