Re: State of Clojure/CLR: (was: Scicloj meeting: Nikita Propokov about Skija - graphics in the JVM)
Reports of the death of ClojureCLR are greatly exaggerated. The newframework branch in the repo has a completed 1.10 version running on .Net Core 3.1 and 5. Should be released 'soon'. On Wednesday, November 18, 2020 at 1:20:54 AM UTC-6 oleksand...@zalando.de wrote: > On Tue, Nov 17, 2020 at 4:56 PM Daniel Slutsky > wrote: > >> https://time.is/1400_08_Dec_2020_in_UTC/ >> >> Tonsky has recently released Skija: a library for high-performance >> graphics on the JVM. >> https://tonsky.me/blog/skija/ >> >> Of course, this opens some possibilities in Clojure. In this talk, Tonsky >> will present Skija to the Clojure audience. >> > > Nice, thanks for sharing! > > Can anyone (maybe the author himself) comment on this: C# would do, too, > but it doesn’t have Clojure. > I have never tried it myself, but what is the state of Clojure/CLR > currently? > > Regards, > -- > Alex > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/5b3becf8-39aa-4e20-a2c9-545ce62ff155n%40googlegroups.com.
Re: Has anyone tried building ClojureCLR using dontnet core on non-windows platforms?
As mentioned, you likely will get more respone on the clojure-clr group. The subject of this post mentions .net core. From my understanding, you will not get ClojureCLR working on .Net Core on any platform due to Core's lack of support for System.Reflection.Emit. Alan correctly mentions Arcadia/Unity, but that is a Mono project, not Core. On Monday, April 17, 2017 at 1:51:21 PM UTC-5, Alex Miller wrote: > > Just FYI, might also want to ask on > https://groups.google.com/forum/#!forum/clojure-clr > > On Monday, April 17, 2017 at 1:15:10 PM UTC-5, Kashyap CK wrote: >> >> Hi, >> I am attempting to build ClojureCLR on Mac- I was wondering if anyone's >> already done this. >> Regards, >> Kashyap >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ClojureCLR setup guide/examples?
Most documentation, such as it is, is on the github wiki: https://github.com/clojure/clojure-clr/wiki Nothing written recently on such things as deploying web services. There is a separate list for ClojureCLR where you might get more answers: https://groups.google.com/forum/#!forum/clojure-clr I just got a Win10 box to play on -- haven't tried deployment there yet. I would be interested in any problems you have experienced. -David On Sunday, October 18, 2015 at 11:06:45 AM UTC-5, Rui Carmo wrote: > > Hello guys, > > I'm re-investing in the .NET ecosystem, and decided to try my hand at > adding ClojureCLR to the mix given my very positive experience with the JVM > version. > > However, I'm having trouble with two basic things: > > - I can't find a comprehensive guide regarding setting up a working > ClojureCLR environment under Windows (8 or 10), so it took me three tries > to get a moderately usable REPL > - the vsClojure extension doesn't support Visual Studio 2015 (I've found a > fork that seems to have been updated, but haven't managed to rebuild it yet) > > That and the lack of documentation regarding deployments (is there a > recommended way to deploy a web service written in ClojureCLR? examples of > working with a database?) have prevented me from making any significant > headway, so I'd appreciate any pointers, especially from people who are > currently using ClojureCLR successfully. > > (and I apologise for saying this, but I don't want to use the JVM version > under Windows - I'm perfectly happy with using it on Linux, including ARM > servers, but the purpose of this exercise is to glue together existing C# > assemblies). > > Regards, > > R. > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ClojureCLR and nrepl ?
Not completely functional and not thoroughly tested. Several tests still fail -- the most important one being interrupting an eval. (I know what the fix is, but haven't had the time.) On Wednesday, May 6, 2015 at 3:58:34 PM UTC-5, Alex Miller wrote: https://github.com/clojure/clr.tools.nrepl On Wednesday, May 6, 2015 at 3:39:18 PM UTC-5, rogergl wrote: Does ClojureCLR provide an nrepl implementation that would allow vim.fireplace to connect to his session ? Regards Roger -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojure.edn won't accept clojure.java.io/reader? How to work around this and why isn't this documented anywhere?
Also, how does this work on ClojureCLR or ClojureScript? Neither of those platforms has a java.io.PushbackReader, and I'm not even sure what the equivalent of the clojure.java.io namespace is for them, unless the java in that name is misleading. ClojureCLR implements PushbackInputStream, PushbackTextReader and LineNumberingTextReader just so it can implement the Lisp reader, the EDN reader, and a few other things following the ClojureJVM code. https://github.com/clojure/clojure-clr/tree/master/Clojure/Clojure/Readers -David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: What does .NET open sourcing mean for ClojureCLR?
The slower startup time has nothing to do with DLR, I think. It is all about doing JIT on load and loading full assemblies. ClojureCLR starts VERY quickly if you NGEN it. This was addressed here:http://clojureclr.blogspot.com/2011/12/using-ngen-to-improve-clojureclr.html And more recently on the ClojureCLR list: https://groups.google.com/forum/#!topic/clojure-clr/LbzsUoJe_h8 Quick comparison: A: $ time java -jar clojure-1.6.0.jar -e (println :a) B: $ time ./Clojure.Main.exe -e (println :a) A: real0m0.761s user0m0.015s sys 0m0.015s B: # ilmerge+ngen real0m0.152s user0m0.015s sys 0m0.000s On Wednesday, November 12, 2014 11:03:22 PM UTC-6, Aleš Roubíček wrote: Unfortunately startup time of ClojureCLR is much worse because it targets DLR. On Wednesday, November 12, 2014 8:16:19 PM UTC+1, Michael Klishin wrote: On 12 November 2014 at 21:50:57, Evan Zamir (zamir...@gmail.com) wrote: I just read that MS is open sourcing .NET. I assume this means one could now target .NET with ClojureCLR on Linux/Mac environment. Assuming that is true, the natural question seems to be which VM should a Clojure developer be targeting? Is performance going to be similar on both? In that case, then existing libraries dependencies would be the deciding factor? Thanks for opinions. Mono has been around for a while and as far as ClojureCLR goes, shouldn't have any [obvious] limitations. In fact, when I have to touch .NET these days, I do all the work on Mono and then simply verify things against .NET on Windows. Usually works like a charm. Mono performance has been excellent for what I do and .NET/Mono startup time is so much better than the JVM one that often now choose F# for scripting. Again, I haven't tried ClojureCLR but running .NET languages on OS X and Linux has been perfectly possible for years. -- @michaelklishin, github.com/michaelklishin -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure CLR Experiences
Re versions: look at the tags, not the branches. The 1.4.1 branch was anomalous, due to needing to get out a bug fix. On Tuesday, November 11, 2014 2:17:29 PM UTC-6, Aaron wrote: Hi Adrian, I'll share some of my experiences. * Is Clojure CLR production ready? Yes, I have been using it in production for about 2 years now. * Do its version numbers correspond to the core Clojure version numbers? (would it be fair to say the Java version is the core version) It's fair to say that the Java is the core version, but Dave Miller (the ClojureCLR maintainer) does a pretty good job of keeping it up to date with the Java version. * Is it sensible to think in terms of writing platform independent code in the same way as we do with cljx files in ClojureScript? It is feasible if you put the effort into testing and writing the code correctly, but currently I don't think cljx supports ClojureCLR - you'd probably need to add that functionality yourself. * How good is the Visual Studio support for Clojure? I use emacs and *inferior-lisp* and am pretty happy with them so I can't comment on the Visual Studio workflow. * Does Leiningen work? There is Shantanu's lein plugin and I've tried to do a proof of concept nlein, but there really isn't the equivalent thing in ClojureCLR. I mostly deploy my .clj files as embedded resources in C# DLL's and have C# call into Clojure to bootstrap things. I'm sure other people use other strategies. * Are there any significant pitfalls to be aware of? Not as many libraries are available and you'll have to do a fair amount of groundwork yourself. Startup time is similar to the JVM verison. Overall, once I got past the initial hurdles, I found the environment to be quite stable and a huge productivity boost. I would definitely recommend ClojureCLR for projects with a big existing .NET code base. For new projects, I do usually go with JVM Clojure mainly for access to more libraries and IDE's. At the time when I started using ClojureCLR our team was heavily invested in .NET so it made a lot of sense and was definitely well worth it... Be sure to check out the ClojureCLR google group: https://groups.google.com/forum/#!forum/clojure-clr On Tuesday, November 11, 2014 10:38:58 AM UTC-5, Adrian Mowat wrote: Hi All, We are using Clojure on the JVM but one of our .Net developers has asked me whether I have considered using it on the CLR. I haven't tried doing it so I wondered if anyone can share any experiences using Clojure on the CLR? A quick google search suggests the project is still active but not especially vibrant (current version 1.4, last commit 24 days ago) but maybe that's unfair. I'm broadly interested in the following... * Is Clojure CLR production ready? * Do its version numbers correspond to the core Clojure version numbers? (would it be fair to say the Java version is the core version) * Is it sensible to think in terms of writing platform independent code in the same way as we do with cljx files in ClojureScript? * How good is the Visual Studio support for Clojure? * Does Leiningen work? * Are there any significant pitfalls to be aware of? Any other comments would be greatly appreciated. Many Thanks Adrian -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: tools.analyzer[.js/.jvm], tools.emitter.jvm, status report
Hi, Alex. I'll send you a few thoughts on this. The reader problem is the biggest issue. -David On Thursday, August 21, 2014 8:01:29 PM UTC-5, Alex Miller wrote: Hey David, I'm working on the feature expressions stuff. At the moment I've been focusing on the clj/cljs use case as that seems to be most urgent. I had been planning to circle back around to clr eventually though and would be very interested in any known issues. Alex -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: tools.analyzer[.js/.jvm], tools.emitter.jvm, status report
Nicola, Thanks for the very helpful comments. I'll likely proceed with the translation -- there are calls to get core.async sync'ed up with the JVM version and tools.analyzer.* has to be there. Thanks for pointing me to the feature expressions discussion. That will be extremely useful, should it come to pass. There are some interesting problems that I'm pretty sure haven't been considered yet. The ClojureCLR lisp-reader requires an extension to symbol token lexing in order to accommodate the full range of type names in the CLR -- that will make some *.clj files written for ClojureCLR to be unreadable by other Clojure implementations even with feature expressions. There are other considerations, but I'll pursue them in that discussion. Thank you for offer to provide advice. I'll be in touch as I move this forward. -David On Thursday, August 21, 2014 7:14:15 AM UTC-5, Nicola Mometto wrote: David, I personally have no plans to port tools.analyzer.jvm to a tools.analyzer.clr, not for disinterest but simply because I don't know anything about the .NET platform nor about clojureCLR. That said, it shouldn't be hard to port it at all, the main file to port would be https://github.com/clojure/tools.analyzer.jvm/blob/master/src/main/clojure/clojure/tools/analyzer/jvm/utils.clj which contains most of the functions that deal with reflection on t.a.jvm, everything else should just be a matter of replacing class names from java.lang.* to their CLR counterpart. The only issue with all this, is that ATM tools.analyzer itself can only run on clojure on the JVM because of https://github.com/clojure/tools.analyzer/blob/master/src/main/clojure/clojure/tools/analyzer/utils.clj#L67-L70 My suggestion would be to wait for clojure 1.7 which should have support for feature expressions and would make it possible for tools.analyzer to be source compatible with clojureCLR too (all the code except for that line is pure clojure, there are a bunch of instance checks for clojure.lang.* types but it's my understanding that clojureCLR maintains that class hierarchy). A relevant ticket that might add a pattern? function to core that would solve this is http://dev.clojure.org/jira/browse/CLJ-1298 In any case, if you want to go ahead and start porting t.a.jvm to t.a.clr until we wait for 1.7 and feature-expressions or `c.c/pattern?`, feel free to contact me privately and we can discuss this further. Thanks, Nicola dmiller writes: Nicola, Excellent work! Looking forward to seeing tools.analyzer.clr in the near future. :) Well, actually, seriously, with the use of tools.analyzer.* in critical projects such as core.async, a port of tools.analyzer.jvm seems necessary. Unless you know of plans to make a port, I'll add it to my queue. Any hints/suggestions/comments you can offer will be received appreciatively. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: tools.analyzer[.js/.jvm], tools.emitter.jvm, status report
Nicola, Excellent work! Looking forward to seeing tools.analyzer.clr in the near future. :) Well, actually, seriously, with the use of tools.analyzer.* in critical projects such as core.async, a port of tools.analyzer.jvm seems necessary. Unless you know of plans to make a port, I'll add it to my queue. Any hints/suggestions/comments you can offer will be received appreciatively. -David On Wednesday, August 13, 2014 11:54:54 AM UTC-5, Nicola Mometto wrote: As some of you might know, I've been working contiuously on my various tools.* contrib libraries for the past months and I've recently added tools.analyzer.js to the list of contrib libraries I maintain. Since I don't blog/tweet much about those libraries, I thought I'd write a report to let the community aware of the status of those libraries. ## tools.analyzer https://github.com/clojure/tools.analyzer tools.analyzer is a host-agnostic pluggable analyzer and collection of passes producing an AST in clojure data structures for clojure and other languages in the clojure language family, like clojurescript. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] ClojureCLR mailing list
ClojureCLR now has its own Google group for discussions. https://groups.google.com/forum/#!forum/clojure-clr Please use this new forum for ClojureCLR-specific questions, suggestions, requests related to usage, development, tooling etc. ClojureCLR-specific announcements will be the new list. ClojureJVM and general Clojure questions/discussions still go on his group. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ClojureCLR] clr.tools.nrepl
Not functional yet. About 50-60% completed. I ran into some bugs -- it turns out that sockets in JVM and CLR are not exactly identical, no great surprise -- and got distracted by versions 1.5 and 1.6alpha and support for mono and nuget for ClojureCLR. I plan to finish the core.async port (it's at 90%) and then get back to this. Unless someone beats me to it. -David On Monday, December 9, 2013 7:09:23 PM UTC-6, Frank Hale wrote: I'm attempting to run the CLR version of nREPL. I've cloned the code from: https://github.com/clojure/clr.tools.nrepl However, I'm not sure how to run the REPL. Doing lein run results in the following message: No :main namespace specified in project.clj. running lein compile doesn't fail but doesn't appear to do anything. running lein uberjar works but I can't run the resulting jar's because they don't have a main manifest attribute. running lein test results in the following message: Error: Could not find or load main class clojure.main Tests failed. There is little to no information on the usage or status of this package. Is this working yet? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure CLR versioning and binary downloads
On Sunday, November 24, 2013 6:56:07 AM UTC-6, Shantanu Kumar wrote: I am trying to run some tests (that worked fine with Mono+ClojureCLR 1.4.1) in Mono+ClojureCLR 1.5.0 from SourceForge and finding the below exception: $ # CLOJURE_LOAD_PATH is configured properly $ mono /path/to/clojure-clr-1.5.0-Release-4.0/Clojure.Main.exe -i /tmp/intermediate-file -e (use 'clojure.test) (run-tests 'sqlrat.template-test 'sqlrat.entity-test) FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: An exception was thrown by the type initializer for Clojure.CljMain --- System.TypeInitializationException: An exception was thrown by the type initializer for clojure.lang.RT --- clojure.lang.Compiler+AssemblyInitializationException: Cannot find initializer for clojure.core.clj, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null.clojure/core I forgot that there was some #if-conditionalized mono vs .net code introduced in 1.5.0. That would have necessitated separate DLLs for mono and .net. I just changed that for a runtime check for the platform. Sourceforge has new zips, nuget has a new package, github 1.5.0 branch and master branch updated. And confirmation from Kumar that it works. -David -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ClojureCLR 1.5.1 compiler problem
I guess it doesn't matter that it works fine for me if it doesn't for you. :) I'll post an issue. Along with many other Clojure projects, issues and related items are on the JIRA site under dev.clojure.org. For ClojureCLR, that is at http://dev.clojure.org/jira/browse/CLJCLR -David On Tuesday, November 26, 2013 8:03:53 AM UTC-6, Brian Barnes wrote: I'm not sure this is the correct place for this, but the GitHub page led me to this place. I believe I have found a problem in the 1.5.1 ClojureCLR currently on GitHub. The problem is with the initialization of the static Compiler class. According to section 10.4.5.1 of the MSDN documentation, the fields of a static class are evaluated in textual order. 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 DictionaryString, Type _duplicateTypeMap = new Dictionarystring, 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. There is no Issues section on the GitHub page, or I would have logged an issue there. Please let me know the best way to get this issue evaluated for a future release of the compiler. Brian C. Barnes -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure CLR versioning and binary downloads
1.5.0 of Clojure CLR includes the one fix in 1.5.1. I got excited and went one too far. Normally, the version numbers match exactly. I tagged 1.5.0 a little prematurely. We had some troubles on the NuGet release and on the mono build. I wasn't really ready for an official 1.5.0 release, so I hadn't done the SourceForge binary distributions. That's all been fixed as of earlier today (11/23/2013 relative to Central Standard). ClojureCLR 1.5.0 is officially out. This version has a NuGet package, with binaries for .Net 3.5 and .Net 4.0. All the binaries to run ClojureCLR itself are in one file, Clojure.dll, due to the magic of ILMerge and a lot of new internal plumbing to allow embedded DLL resources and merged DLLs. Also, this version is signed so that it can be referenced in signed projects or GAC'd. There are Debug and Release binaries (not ILMerged) for .Net 3.5 and 4.0 on the SourceForge site. The wiki pages on the github site have been updated. Mono is now supported. You can run it under Mono. You can compile it directly using xbuild with mono. Details on the wiki. Regarding the Clojure.Main and Clojure.Compile binaries in the NuGet package: Yes, you have to move them to run them. Clojure.dll has to be in the lib\ folder in order for the package to work properly when included in a project. Ancillary files such as Clojure.Main and Clojure.Compile are standalones and are not needed for other projects. They are properly contained in the tools\ folder. I was asked to include them in the NuGet package for ClojureCLR. I'm not happy with the current arrangement, in a nitpicky way. I'm open to suggestions. -David On Friday, November 22, 2013 8:41:58 PM UTC-6, Frank Hale wrote: As far as I can tell the Clojure CLR version number does not track the JVM version number at least for some builds. The latest build 1.5.0 as far as I can tell is at the same patch level as 1.5.1 on the JVM. This numbering seems confusing to me. Are there any plans to streamline the version numbers between the two platforms? Additionally I don't understand why on the Clojure CLR SourceForge page there are only debug versions available for download and 1.5.0 is not represented there. If you want 1.5.0 you have to use nuget to get it. I was also a bit dumbfounded that the nuget version was broken out of the box and what I mean by that is that once you have downloaded it you cannot run the compiler or the REPL from it's current directory without first dumping the exe's into the lib folder since they are segregated in the package. Running the compiler or REPL from their directory will result in them complaining that they cannot find the required Clojure CLR DLL's that they need. These are kind of nit-picky issues but they've been bugging me for a while. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ClojureCLR] Clojure.Compile.exe
ClojureCLR follows ClojureJVM in translating hyphens in namespace names to underscores in filenames. -David On Tuesday, November 19, 2013 11:00:37 AM UTC-6, Frank Hale wrote: Thanks Shantanu, I will look into lein-clr. On Tue, Nov 19, 2013 at 11:57 AM, Frank Hale fran...@gmail.comjavascript: wrote: Ugh, as it always goes right after posting to a mailing list you find out what the problem is. My clojure source file name was the problem. I had a dash in the filename and apparently that is a problem. All is well. LOL! On Tue, Nov 19, 2013 at 11:54 AM, Shantanu Kumar kumar.s...@gmail.comjavascript: wrote: Hi Frank, (Saw your post shared on ClojureCLR Google+ but was unable to comment.) This may be slightly tangential but you might want to look at lein-clr: https://github.com/kumarshantanu/lein-clr It makes these things easier to do on the command-line. You need to install Java and Leiningen to run lein-clr. It automatically takes care of setting CLOJURE_LOAD_PATH and CLOJURE_COMPILE_PATH environment variables. Shantanu On Tuesday, 19 November 2013 22:18:07 UTC+5:30, Frank Hale wrote: I'm using Clojure-CLR 1.5 and cannot get a simple hello,world to compile into an executable using Clojure.Compile.exe. Code: (ns clojureclr-test (:gen-class)) (defn -main [] (println Hello, World)) When I attempt to compile the code using Clojure.Compile.exe I get the following error: C:\Users\fhale\Desktop\sandboxclojure.compile.exe clojureclr-test Compiling clojureclr-test to .System.IO.FileNotFoundException: Could not locate clojureclr_test.clj.dll or clojureclr_test.clj on load path. at clojure.lang.RT.load(String relativePath, Boolean failIfNotFound) in d:\wo rk\clojure-clr\Clojure\Clojure\Lib\RT.cs:line 3307 at clojure/core$load$fn__17179__17183.invoke() in :line 0 at clojure/core$load__17186.doInvoke(Object ) in :line 0 at clojure/core$load_one__17059.invoke(Object , Object , Object ) in :line 0 at clojure/core$compile$fn__17193__17197.invoke() in :line 0 at clojure/core$compile__17200.invoke(Object ) in :line 0 at BootstrapCompile.Compile.Main(String[] args) in d:\work\clojure-clr\Clojur e\Clojure.Compile\Compile.cs:line 78 Additionally I thought perhaps I should set the CLOJURE_LOAD_PATH but that did not resolve this compilation issue. Is there anything special I need to do in order to set up the Clojure compiler in order to produce executables or DLLs? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why the CLR languages fail?
On Thursday, June 6, 2013 1:55:13 AM UTC-5, Zed Becker wrote: Why do the languages running on the CLR (ironRuby, ironPython, ironScheme, ScalaCLR) do not get to live long enough in the sunshine, whereas same languages get embraced by the Java runtime, and live in the limelight? Many respondents have dealt with this question, in detail. I can confirm that some of the CLR extras (structs, reified generics, ...) complicate life for the language implementer, particularly in the area of interop. Chas did a survey in 2012, which gave very negative results for clojureCLR, with 70% people having no motivation to even play with it, and almost no production use. For me, the more interesting question is: How can ClojureCLR be protected from dwindling? 1. Send more fish. :) 2. Contribute. We can't do much about the culture in the .Net world that impedes adoption of these languages , as discussed by other respondents. The biggest impediment seems to be tooling. Progress is being made. This year has seen a noticeable increase in the number of contributors. ClojureCLR is now also on Mono, more libs have been ported, everything is being made available on nuget, we have a good start in the leiningen space with lein-clr and nleiningen (both mentioned in a recent thread here), and there have been some updates on the Visual Studio plugin. We just need more. ClojureCLR will have an official 1.5 release any day now (it's already caught up to 1.5.1 on the master branch, I just haven't tagged an official release yet). I'd like to see the work on lein-clr (which depends on ClojureJVM) moved into nleiningen (native ClojureCLR) and nlein extended to be more comprehensive. The nrepl port needs to be completed so it can be incorporated into nlein, the VS plugin, maybe emacs. And the the VS plugin needs continued refinement. I am not surprised by the low numbers for ClojureCLR on the Clojure survey. I am pleased by the increase of interest and participation that I have been seeing. And I'm really glad we didn't call it IronClojure. :) -David -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure - CLR - JS - Visual Studio Extension
I've not seen that behavior on ClojureCLR/Mono before. What ClojureCLR commit are you using? On Thursday, March 21, 2013 10:42:52 PM UTC-5, Ambrose Bonnaire-Sergeant wrote: I'm using Mono on Ubuntu, and I have these errors/failures (including project.clj at the bottom): https://gist.github.com/frenchy64/5218783 This is with commit 3b387f914815e389313897977eb02a9fba89dea2 Is this to do with my environment? Thanks, Ambrose On Fri, Mar 22, 2013 at 11:09 AM, Ambrose Bonnaire-Sergeant abonnair...@gmail.com javascript: wrote: Hi David, Excellent work so far! I'll have a dig around and see what I find. Thanks, Ambrose On Fri, Mar 22, 2013 at 10:53 AM, dmiller dmill...@gmail.comjavascript: wrote: Last update on this here: The port of core.logic to ClojureCLR that resides here: https://github.com/**dmiller/clr.core.logichttps://github.com/dmiller/clr.core.logic the datomic piece is not ported. All tests run EXCEPT: test-binding-map-* test-binding-map-as-1 test-binding-map-constraints-1 test-unifier-constraints-* test-flatteno test-unifier-anon-constraints-3 test-36-unifier-behavior These tests mostly involve clojure.core.logic.unifier/unify and .../unifier. It is rather daunting to just jump into core.logic and debug this kind of thing, so it might take a while for me to solve this. I invite anyone interested in ClojureCLR + core.logic to take a look. -David -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure - CLR - JS - Visual Studio Extension
We never did any testing of the 1.4.x series under mono. If it works at all, that's just a bonus. I'd do mono work off the master branch. lein-clr won't do that directly. You'd have to download, build and set the appropriate environment variable to your bin dir. The current master introduced a bug in the mono build. I should have that fixed tomorrow morning sometime. -David On Friday, March 22, 2013 7:22:54 AM UTC-5, Ambrose Bonnaire-Sergeant wrote: Not sure how to tell the commit, but lein-clr has pulled down: clojure-clr-1.4.0-Debug-4.0.zip Thanks, Ambrose On Fri, Mar 22, 2013 at 8:11 PM, dmiller dmill...@gmail.com javascript: wrote: I've not seen that behavior on ClojureCLR/Mono before. What ClojureCLR commit are you using? On Thursday, March 21, 2013 10:42:52 PM UTC-5, Ambrose Bonnaire-Sergeant wrote: I'm using Mono on Ubuntu, and I have these errors/failures (including project.clj at the bottom): https://gist.github.com/**frenchy64/5218783https://gist.github.com/frenchy64/5218783 This is with commit **3b387f914815e389313897977eb02a**9fba89dea2 Is this to do with my environment? Thanks, Ambrose On Fri, Mar 22, 2013 at 11:09 AM, Ambrose Bonnaire-Sergeant abonnair...@gmail.com wrote: Hi David, Excellent work so far! I'll have a dig around and see what I find. Thanks, Ambrose On Fri, Mar 22, 2013 at 10:53 AM, dmiller dmill...@gmail.com wrote: Last update on this here: The port of core.logic to ClojureCLR that resides here: https://github.com/**dmiller/**clr.core.logichttps://github.com/dmiller/clr.core.logic the datomic piece is not ported. All tests run EXCEPT: test-binding-map-* test-binding-map-as-1 test-binding-map-constraints-1 test-unifier-constraints-* test-flatteno test-unifier-anon-constraints-**3 test-36-unifier-behavior These tests mostly involve clojure.core.logic.unifier/**unify and .../unifier. It is rather daunting to just jump into core.logic and debug this kind of thing, so it might take a while for me to solve this. I invite anyone interested in ClojureCLR + core.logic to take a look. -David -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure - CLR - JS - Visual Studio Extension
I started a port of core.logic to ClojureCLR. Repo: https://github.com/dmiller/clr.core.logic It is not finished yet. All files load with two exceptions. (1) I have not ported clojure.core.logic.datomic (2) there is a problem in the finite domain code with extending fd to the integer types. Specifically, the calls in https://github.com/dmiller/clr.core.logic/blob/master/src/clojure/core/logic/fd.clj#L231 ff. to macro extend-to-fd defined at https://github.com/dmiller/clr.core.logic/blob/master/src/clojure/core/logic/fd.clj#L181 do not work, causing many, many tests to fail. I suspect the fix is trivial, but did not have time to go bug-hunting this morning. -David On Wednesday, March 20, 2013 10:43:40 AM UTC-5, dmiller wrote: core.logic should be trivial to port to ClojureCLR. Based on a quick scan, a few changes to JVM lib calls, mostly .write = .Write, a few type hints, UUID = GUID. Could be done in short order. This would be an easy example to play with a common source for Clojure(JVM | CLR). -David On Tuesday, March 19, 2013 5:24:34 PM UTC-5, Martin Jul wrote: I have made experiments with compiling ClojureScript to .NET code using the Microsoft.JScript JavaScript compiler and for a Hello World application it had a few hiccups in relation to compiling the Google closure-library (the use of future reserved keywords like require and namespace for variables/functions). I don't think getting ClojureScript to compile on the CLR it is insurmountable, but some work is needed. My end goal is to have core.logic accessible from .NET code, either by running the ClojureScript version on .NET or by porting it to Clojure CLR. If you would be wonderful if you would help. Cheers, Martin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure - CLR - JS - Visual Studio Extension
Last update on this here: The port of core.logic to ClojureCLR that resides here: https://github.com/dmiller/clr.core.logic the datomic piece is not ported. All tests run EXCEPT: test-binding-map-* test-binding-map-as-1 test-binding-map-constraints-1 test-unifier-constraints-* test-flatteno test-unifier-anon-constraints-3 test-36-unifier-behavior These tests mostly involve clojure.core.logic.unifier/unify and .../unifier. It is rather daunting to just jump into core.logic and debug this kind of thing, so it might take a while for me to solve this. I invite anyone interested in ClojureCLR + core.logic to take a look. -David -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure - CLR - JS - Visual Studio Extension
core.logic should be trivial to port to ClojureCLR. Based on a quick scan, a few changes to JVM lib calls, mostly .write = .Write, a few type hints, UUID = GUID. Could be done in short order. This would be an easy example to play with a common source for Clojure(JVM | CLR). -David On Tuesday, March 19, 2013 5:24:34 PM UTC-5, Martin Jul wrote: I have made experiments with compiling ClojureScript to .NET code using the Microsoft.JScript JavaScript compiler and for a Hello World application it had a few hiccups in relation to compiling the Google closure-library (the use of future reserved keywords like require and namespace for variables/functions). I don't think getting ClojureScript to compile on the CLR it is insurmountable, but some work is needed. My end goal is to have core.logic accessible from .NET code, either by running the ClojureScript version on .NET or by porting it to Clojure CLR. If you would be wonderful if you would help. Cheers, Martin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ClojureCLR - Question about the Debug 3.5 build configuration and System.Reflection.Assembly.IsDynamic property
Oops. Forgot to do a test build on 3.5 for that one. I need to conditionalize that call. I'll try to commit a patch for that tonight. -David On Tuesday, March 12, 2013 11:43:58 PM UTC-5, FC wrote: Hi, I'm trying to build ClojureCLR from the latest clojure-clr-master.ZIP file I downloaded from GitHub. With Debug 3.5 as the build configuration I get a compilation error in Clojure\lib\RT.cs that System.Reflection.Assembly does not contain a definition for 'IsDynamic'. Is this expected? When I use Debug 4.0 it builds fine. Thank you. -Fiel -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ClojureCLR - Question about the Debug 3.5 build configuration and System.Reflection.Assembly.IsDynamic property
Fixed in master. On Tuesday, March 12, 2013 11:43:58 PM UTC-5, FC wrote: Hi, I'm trying to build ClojureCLR from the latest clojure-clr-master.ZIP file I downloaded from GitHub. With Debug 3.5 as the build configuration I get a compilation error in Clojure\lib\RT.cs that System.Reflection.Assembly does not contain a definition for 'IsDynamic'. Is this expected? When I use Debug 4.0 it builds fine. Thank you. -Fiel -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure-CLR - Where to report issues?
Judging from the transcript, there is something not right in your ClojureCLR setup. protocols.clj should not be loading. It should be AOT-compiled. We can work from the JIRA ticket. -David On Wednesday, February 20, 2013 3:30:52 PM UTC-6, Frank Hale wrote: Thank you. New ticket created. On Wed, Feb 20, 2013 at 4:20 PM, Andy Fingerhut andy.fi...@gmail.comjavascript: wrote: I believe anyone should be able to create an account at this web site and then create a ticket. If you have any trouble doing so, let me know. http://dev.clojure.org/jira/browse/CLJCLR Andy On Feb 20, 2013, at 12:58 PM, Frank Hale wrote: I wanted to report an issue with Clojure-CLR 1.4.1 that I am seeing but the issues section on the Clojure-CLR Github must be disabled because the link is not showing up. 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.1Clojure.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= -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: 2 issues (with workarounds) running ClojureCLR in ASP.NET
ClojureCLR abides by the same restrictions on submitting code as the main
Clojure project. Meaning that contribute code directly to ClojureCLR, you
need a Contributor Agreement with Rich Hickey.
Check out http://clojure.org/contributing.
Doing so will allow you access to the JIRA site, which is also used by
ClojureCLR for submitting patches, etc.
In the meantime, I'll look into this problem.
-David
On Wednesday, January 16, 2013 8:38:44 PM UTC-6, gavin.ca...@gmail.com
wrote:
(This is my first post. Please let me know if I've got the protocol
wrong.)
First, I don't know that anyone else is even trying to run ClojureCLR in
ASP.NET. All I've seen is this
posthttps://groups.google.com/d/topic/clojure/np3sRVTMrS4/discussionfrom
March 2010. It looks like the recommended patch (to RT.cs) was
eventually incorporated.
But I found that two other modifications were needed to use the current
version (1.4):
(Note that these only came up when loading Clojure in ASP.NET. I had no
problems with console programs.)
1) *Can't locate assemblies in bin*. RT.load only looks for assemblies
in AppDomain.CurrentDomain.BaseDirectory. For ASP.NET applications,
this is the root of the site, and assemblies are located under bin. I
did the following in RT.cs to get around this:
@@ -3122,6 +3122,14 @@ namespace clojure.lang
bool loaded = false;
+// Look for assembly alongside this one
+if (assyInfo == null cljInfo == null) {
+Uri codeBase;
+
+if
(Uri.TryCreate(Assembly.GetExecutingAssembly().CodeBase, UriKind.Absolute,
out codeBase)
+ codeBase.IsFile)
+assyInfo =
FindFile(Path.GetDirectoryName(codeBase.LocalPath), assemblyname);
+}
+
if ((assyInfo != null
(cljInfo == null || assyInfo.LastWriteTime
cljInfo.LastWriteTime)))
Assembly location was changed in changeset 02607349 to use a non-probing
path (although the paths returned by GetFindFilePaths() wouldn't locate in
bin, either). ASP.NET includes bin in the standard probing path, but I
think you have to actually load it for that to work.
2) *Static initialization error*. After that, loading the assembly
results in the following error
System.Reflection.TargetInvocationException: Exception has been thrown by
the target of an invocation. --- System.TypeInitializationException: The
type initializer for '__Init__' threw an exception. ---
System.NullReferenceException: Object reference not set to an instance of
an object.
at clojure.lang.Compiler.FindDuplicateType(String typename) in
\Clojure\Clojure\CljCompiler\Compiler.cs:line 866
at clojure.lang.RT.classForName(String p) in
\Clojure\Clojure\Lib\RT.cs:line 2720
at __Init__.__static_ctor_helper_constants()
at __Init__..cctor()
--- End of inner exception stack trace ---
at __Init__.Initialize()
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo
method, Object target, Object[] arguments, SignatureStruct sig,
MethodAttributes methodAttributes, RuntimeType typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo
method, Object target, Object[] arguments, Signature sig, MethodAttributes
methodAttributes, RuntimeType typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture,
Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.RuntimeType.InvokeMember(String name, BindingFlags
bindingFlags, Binder binder, Object target, Object[] providedArgs,
ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams)
at System.Type.InvokeMember(String name, BindingFlags invokeAttr, Binder
binder, Object target, Object[] args)
at clojure.lang.Compiler.LoadAssembly(FileInfo assyInfo) in
\Clojure\Clojure\CljCompiler\Compiler.cs:line 1275
Without getting too deep into the
codehttp://clojure.org/patches?responseToken=172419b0a608c93e78a91b42fd5283b5,
this is apparently due to the lexical order of the static initializers. It
goes away if you move the following line in Compiler.cs to the top of the
class:
static DictionaryString, Type _duplicateTypeMap = new
Dictionarystring, Type();
Presumably, FindDuplicateType is in the call chain of a static
initializer that appears above it — at least when running in ASP.NET.
So I'm up and running now, but I'd like to help out if possible.
Thanks,
Gavin
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be
Re: ClojureCLR 1.5.0 RC 1
Are you using ClojureCLR 1.4.x or 1.5RC1 (current master)? 1.4 was not set up for mono. 1.5RC1 is. In 1.5RC1, the csproj file for Clojure.Compile.exe conditionalizes the PostBuildEvent for mono vs .net. It works for me under Mono 2.x. I haven't tried it under Mono3. If you are under ClojureCLR 1.4, you will need to do on extra editing step that RobertJ had in his directions, to hardwire calling mono to run Clojure.Compile.exe in the PostBuildEvent: In a text editor open the Clojure.Compile.csproj file located in Clojure/Clojure.Compile. Under the PostBuildEvent add mono to the section so it looks like this: *-Clojure.Compile.csproj Edit---* PostBuildEventmono $(TargetPath) clojure.core clojure.core.protocols clojure.main clojure.set clojure.zip clojure.walk clojure.stacktrace clojure.template clojure.test clojure.test.tap clojure.test.junit clojure.pprint clojure.clr.io clojure.repl clojure.clr.shell clojure.string clojure.data clojure.reflect/PostBuildEvent /PropertyGroup *-Clojure.Compile.csproj Edit---* If you are running into this problem with 1.5RC1 under Mono 3, let me know. This would be anomalous. (but the step above should make it work) -David On Thursday, January 3, 2013 2:26:37 AM UTC-6, Konrad Hinsen wrote: dmiller writes: Building from souce on *nix/Mono can be done with nuget. It's of pain approximately equal to what Robert wrote. I just tried the following ... I tried this with Mono 3 under MacOS. It build Clojure.Compile.exe, but then stops: Target PostBuildEvent: Executing: /Users/hinsen/Development/clojure-clr/bin/4.0/Release//Clojure.Compile.exe clojure.core clojure.core.protocols clojure.main clojure.set clojure.zip clojure.walk clojure.stacktrace clojure.template clojure.test clojure.test.tap clojure.test.junit clojure.pprint clojure.clr.ioclojure.repl clojure.clr.shell clojure.string clojure.data clojure.reflect /var/folders/5o/5oa68Zl0EQG9YX04ru5xvE+++TM/-Tmp-/tmp435b44aa.tmp: line 1: /Users/hinsen/Development/clojure-clr/bin/4.0/Release//Clojure.Compile.exe: cannot execute binary file /Library/Frameworks/Mono.framework/Versions/3.0.2/lib/mono/4.0/Microsoft.Common.targets: error : Command '/Users/hinsen/Development/clojure-clr/bin/4.0/Release//Clojure.Compile.exe clojure.core clojure.core.protocols clojure.main clojure.set clojure.zip clojure.walk clojure.stacktrace clojure.template clojure.test clojure.test.tap clojure.test.junit clojure.pprint clojure.clr.ioclojure.repl clojure.clr.shell clojure.string clojure.data clojure.reflect' exited with code: 126. Task Exec execution -- FAILED Konrad. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR 1.5.0 RC 1
That most likely is due to NUnit not being installed in lib/ properly. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR 1.5.0 RC 1
I believe RobertJ and some others are looking into automating this. A real solution needs to coordinate nuget in Visual Studio versus nuget in mono-land (the build scripts already handle mono vs ms) and bring lein-clr along so that building clojure-clr itself is not too distinct from building apps based on clojure-clr. The latter will become part of the former if we move to incorporating libs such as test.generative into the build process. Re production-ready: you need to define the criteria. -David On Tuesday, January 1, 2013 8:35:48 PM UTC-6, Limbo Peng wrote: Looks great! At least it can be compiled successfully somehow :) And maybe this can be done automatically (with some help from bash / sed scripts) - I will try when I have time. BTW: is ClojureCLR production-ready currently? I don't mean as mature as the JVM one, though. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR 1.5.0 RC 1
A casualty of github deprecating downloads. The Download button is gone, but the binary downloads are still available for a short while longer at https://github.com/clojure/clojure-clr/downloads I've updated the wiki page. I have not tried Robert's instructions yet. From what I can tell, getting nuget running in a *nix/Mono environment is still not trivial. -David On Monday, December 31, 2012 8:25:28 AM UTC-6, Konrad Hinsen wrote: dmiller writes: The executables and DLLs under the regular binary download will work just fine under Mono. I just wanted to try this, but I can't find the regular binary download. At http://github.com/clojure/clojure-clr/wiki/Getting-binaries I am told to click on the Downloads button at the Clojure CLR Github site, but there is no Downloads button. I also tried cloning the source tree and building myself, according to the instructions Robert posted last week, but I can't download any of the dependencies, nuget always complaining Cannot find the specified file. Konrad. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR 1.5.0 RC 1
Ah, yes, I cannot upload new binary distributions.
Building from souce on *nix/Mono can be done with nuget. It's of pain
approximately equal to what Robert wrote.
I just tried the following
1. Clone the repo or pull down the zip of the 1.5RC1 tag
from https://github.com/clojure/clojure-clr/tags.
2. Get the DLR libs -- libs.zip
from https://github.com/clojure/clojure-clr/downloads and unzip into the
lib subdirectory of clojure-clr
3. Download NUnit from http://nunit.com/index.php?p=download. Grab
nunit.framework.dll and the dlls in the lib subdir of Nunit and put in the
lib subdir of clojure-clr.
*-NUnit
Edit--*
4. In a text editor open the Clojure.Tests.csproj file located in
clojure-clr/Clojure/Clojure.Tests. Change the nunit.framework
configuration from:
Original Configuration
Reference Include=nunit.framework, Version=2.6.0.12051, Culture=neutral,
PublicKeyToken=96d09a1eb7f44a77, processorArchitecture=MSIL
HintPath..\packages\NUnit.2.6.0.12054\lib\nunit.framework.dll/HintPath
/Reference
Change Configuration to this
Reference Include=nunit.framework
HintPath..\..\lib\NUnit.2.6.2\lib\nunit.framework.dll/HintPath
/Reference
*-NUnit
Edit--*
5. Finaly from the directory clojure-clr/Clojure run either:
MONO_IOMAP=all xbuild build.proj /target:Build /p:Configuration=Release
4.0 /p:Platform=Any CPU
or
MONO_IOMAP=all xbuild build.proj /target:Build /p:Configuration=Debug 4.0
/p:Platform=Any CPU
After the build the binaries will be located in
clojure-clr/bin/4.0\{Release || Debug}
Do
mono Clojure.Main.exe
to run.
-David
On Tuesday, January 1, 2013 10:31:33 AM UTC-6, Konrad Hinsen wrote:
dmiller writes:
A casualty of github deprecating downloads. The Download button is
gone, but the binary downloads are still available for a short
while longer at
https://github.com/clojure/clojure-clr/downloads
I've updated the wiki page.
Thanks! But release 1.5.0 RC 1 isn't there, the latest one is 1.4.1.
I have not tried Robert's instructions yet. From what I can tell,
getting nuget
running in a *nix/Mono environment is still not trivial.
Sounds... reassuring ;-)
It seems that for now, the only way to run ClojureCLR under Linux or MacOS
is to
build binaries under Windows from the source code first, right?
Konrad.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR 1.5.0 RC 1
The executables and DLLs under the regular binary download will work just fine under Mono. On Saturday, December 29, 2012 2:06:31 AM UTC-6, Shantanu Kumar wrote: On Thursday, 27 December 2012 23:15:04 UTC+5:30, dmiller wrote: ClojureCLR is caught up with all changes to ClojureJVM up to 1.5.0-RC1. This includes all relevant bug fixes, the reducers library, reader literal improvements, new threading macros and other goodness. See changes.md. The only change not yet implemented is the new reliance on the test.generative library. That's going to wait until there are some improvements in the build and project management process. You won't notice the difference. One change specific to ClojureCLR: building/running under Mono is now supported. That's fantastic! Is there a binary download link you'd like to share? Shantanu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ClojureCLR 1.5.0 RC 1
ClojureCLR is caught up with all changes to ClojureJVM up to 1.5.0-RC1. This includes all relevant bug fixes, the reducers library, reader literal improvements, new threading macros and other goodness. See changes.md. The only change not yet implemented is the new reliance on the test.generative library. That's going to wait until there are some improvements in the build and project management process. You won't notice the difference. One change specific to ClojureCLR: building/running under Mono is now supported. Have at it. -David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR errors on Mono Linux
I believe I'm running 32-bit. Can you email me your project.clj file so I can make sure I'm reproducing your situation? -David On Wednesday, December 19, 2012 4:37:10 PM UTC-6, Shantanu Kumar wrote: Here are the steps how to reproduce the issue on 32-bit Ubuntu 12.04: 1. lein new lein-clr foo 2. cd foo 3. # edit project.clj to download the dependencies using :clj-dep 4. lein clr -v compile :all 5. lein clr -v test It will show the exact commands being executed. Are the same Clojure binaries supposed to work on 32-bit systems? Shantanu On Wednesday, 19 December 2012 13:19:55 UTC+5:30, Shantanu Kumar wrote: Thanks David, and sorry for the insufficient bug details. I tested this on 64-bit Ubuntu where it works fine; however, the problem shows up on 32-bit Ubuntu. I will post the exact steps in the evening on how to replicate the issue on 32-bit Ubuntu. Shantanu On Wednesday, 19 December 2012 02:00:53 UTC+5:30, dmiller wrote: Shantanu, I created an Ubuntu 12.10 VM running in VirtualBox on my Win7 PC. I installed Mono 2.10.8. I downloaded the zip for ClojureCLR 1.4.0 Debug-4.0. Extracted. mono Clojure.Main.exe Runs with no problem. mono Clojure.Compile.exe test.junk Runs with no problem. From the errors you report, I can only guess that some pre-1.4 DLLs are being found somehow and loaded. For example, the field clojure.lang.RT.OutVar did not exist in ClojureCLR 1.3. I do not know how else to help. -David On Saturday, December 15, 2012 10:17:59 PM UTC-6, Shantanu Kumar wrote: This is when using ClojureCLR 1.4.0 Debug-4.0 version. Shantanu On Sunday, 16 December 2012 09:45:21 UTC+5:30, Shantanu Kumar wrote: Hi, I noticed the following ClojureCLR errors using Mono 2.10 on Ubuntu 12.04 (they do not happen on Windows using either .NET or Mono): 1. when running Clojure.Compile.exe: Exception: System.MissingFieldException: Field 'clojure.lang.RT.OutVar' not found. 2. when using Clojure.Main.exe: Exception: System.TypeLoadException: Could not load type 'Clojure.CljMain' from assembly 'Clojure.Main, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. It would be great if anybody can let me know what's going on. Shantanu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR errors on Mono Linux
Shantanu, I created an Ubuntu 12.10 VM running in VirtualBox on my Win7 PC. I installed Mono 2.10.8. I downloaded the zip for ClojureCLR 1.4.0 Debug-4.0. Extracted. mono Clojure.Main.exe Runs with no problem. mono Clojure.Compile.exe test.junk Runs with no problem. From the errors you report, I can only guess that some pre-1.4 DLLs are being found somehow and loaded. For example, the field clojure.lang.RT.OutVar did not exist in ClojureCLR 1.3. I do not know how else to help. -David On Saturday, December 15, 2012 10:17:59 PM UTC-6, Shantanu Kumar wrote: This is when using ClojureCLR 1.4.0 Debug-4.0 version. Shantanu On Sunday, 16 December 2012 09:45:21 UTC+5:30, Shantanu Kumar wrote: Hi, I noticed the following ClojureCLR errors using Mono 2.10 on Ubuntu 12.04 (they do not happen on Windows using either .NET or Mono): 1. when running Clojure.Compile.exe: Exception: System.MissingFieldException: Field 'clojure.lang.RT.OutVar' not found. 2. when using Clojure.Main.exe: Exception: System.TypeLoadException: Could not load type 'Clojure.CljMain' from assembly 'Clojure.Main, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. It would be great if anybody can let me know what's going on. Shantanu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: lein-clr 0.2.0 for ClojureCLR
Aaron, tools.logging and nrepl are important. I'm glad to see the effort. I haven't forgotten about your single-DLL work. I'm going to have plenty of time next week if you can get something to me. -David On Saturday, December 15, 2012 5:15:16 PM UTC-6, Aaron wrote: Cool. I'm just seeing this now. I actually spent some time a while back getting a very simple nleiningen working in ClojureCLR. I had nuget downloads working and also the ability to AOT compile namespaces and merge them into a single DLL. It's not fully ready for prime time yet though, in part because it depends on some custom modifications to the ClojureCLR compiler. In the long run, I'd like to work together on getting a full lein clr implementation working. I'd love to discuss further if you have time. By the way Dave - speaking of custom modifications to ClojureCLR, this past week, my colleague and I merged your latest master with our changes ( https://github.com/kocubinski/clojure-clr). I hope to put together some formal patches soon which clearly identify the changes I'm suggesting for the main compiler. While we're at it, a few other things I'm working on or have working in clojure-clr are: tools.logging and pinvoke (https://github.com/aaronc/ClojureClrEx) - logging is mostly ported but with only one backend working, pinvoke/dllimport works great, but no docs a nice interface to WPF (https://github.com/aaronc/ClojureWpf) - pretty stable, but again no docs yet nrepl (https://github.com/aaronc/tools.nrepl/tree/clr) - needs quite a bit more work Unfortunately, I haven't been too diligent with documentation, but I hope to correct that as time allows. On Sunday, November 18, 2012 4:03:03 PM UTC-5, Shantanu Kumar wrote: Hi, I pushed lein-clr 0.2.0 https://github.com/kumarshantanu/lein-clr JARs to Clojars a little while ago. The focus of this release is to 1. add dependency support (via NuGet/wget/curl, Leiningen :dependencies) 2. lower the bar to get started with ClojureCLR (with automated download of ClojureCLR) 3. remove the need to call `assembly-load-from` in code The changelog and TODO are here: https://github.com/kumarshantanu/lein-clr/blob/master/CHANGES.md I hope this release is usable enough to start building ClojureCLR apps and libraries with it. This is an early project and can certainly use feedback and contribution. Please let me know what you think. Shantanu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR errors on Mono Linux
Shantanu, I don't have a Linux box available at this point to test, but I'll try it on Mac w/ Mono when I get a chance. I don't have a clue how a field disappears between platforms. -David On Saturday, December 15, 2012 10:15:21 PM UTC-6, Shantanu Kumar wrote: Hi, I noticed the following ClojureCLR errors using Mono 2.10 on Ubuntu 12.04 (they do not happen on Windows using either .NET or Mono): 1. when running Clojure.Compile.exe: Exception: System.MissingFieldException: Field 'clojure.lang.RT.OutVar' not found. 2. when using Clojure.Main.exe: Exception: System.TypeLoadException: Could not load type 'Clojure.CljMain' from assembly 'Clojure.Main, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. It would be great if anybody can let me know what's going on. Shantanu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR binary download issue
On Saturday, December 15, 2012 3:27:26 PM UTC-6, Shantanu Kumar wrote: Hi, Thought to bring up the recent ClojureCLR binary download issue: 1. The http://clojure.org/ homepage links ClojureCLR to the old Github repo. Whoever maintains the homepage will have to fix this. Note: there are two links to ClojureCLR on the home page. The one in the first paragraph is the one that is broken. The one in the list further down the page is okay. 2. The `Download` links on ClojureCLR repo have gone missing: https://github.com/clojure/clojure-clr #2 may have to do with Github's recent announcement to drop the Downloads feature. The old URLs continue to work for download, but it may not be possible for first timers to know them. I'd suggest to put up the downloads at the Clojure website's Download page: http://clojure.org/downloads Thanks for the notice. I had missed it. I don't have access to the clojure.org downloads page. I'll seek an alternative for delivering the binaries. [Off-topic] -- I noticed this when I wanted to confirm the binaries because I was running into the following error: FATAL UNHANDLED EXCEPTION: System.MissingFieldException: Field 'clojure.lang.RT.OutVar' not found. Shantanu Did this error occur from one of the downloaded binaries? Can you confirm which version? -David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure CLR and System.Double Behavior
Patched in master branch. Clojure 1.5.0-master-SNAPSHOT user= user= (defn bar [^Double d] d) #'user/bar user= (defn baz [^System.Double d] d) #'user/baz user= (bar 1.2) 1.2 user= (baz 1.2) 1.2 user= (defprotocol FP (foo [_])) FP user= (extend-protocol FP System.Double (foo [d] d)) nil user= (foo 1.2) 1.2 You can now type hint with double, Double and System.Double. One should keep in mind that this is the CLR, not C# (or the JVM). Thus, int, Int32, System.Int32 and float, Single, System.Single. Note that a type hint such as ^System.Int32 x is actually using the symbol System.Int32 as the value for :tag -- that is how the LispReader works. However, if you were to put :tag metadata on programmatically and actually use the type System.Int32 -- well, that should work also. -David On Thursday, November 29, 2012 11:02:19 AM UTC-6, ffailla wrote: I have discovered some odd behavior when type-hinting fns with ^System.Double: user= (defn bar [^System.Double d] d) #'user/bar user= (bar 1.2) 2.35293190771409E-316 user= (bar 1) 2.35069794048985E-316 The same behavior occurs when extending double via extend-protocol or extend-type: user= (defprotocol FooProto (foo [_])) user= (extend-protocol FooProto System.Double (foo [d] d)) nil user= (foo 1.2) 2.25126584588049E-316 Any ideas? Thanks. -Frank Failla -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure CLR and System.Double Behavior
user= (defn f [^Double x] x)
#'user/f
user= (defn g [^double x] x)
#'user/g
user= (f 1.0)
2.15078317008181E-316# GASP!
user= (g 1.0)
1.0# CROWD APPLAUDS!
As you can see, there is a workaround: use ^double, not ^Double. This
matches what you would do in ClojureJVM. Not to say the observed behavior
isn't faulty and needs fixing.
This workaround is not possible for your extend-protocol example. However,
making System.Double work as you expect for primitive type hinting on fn
arguments should also fix the extend-protocol problem.
Probably over this weekend.
If you care to understand more fully:
The problem stems from the difference in how primitives are handled in the
JVM vs the CLR. Sparing the details, it surfaces here in the fact that
java.lang.Double and System.Double are significantly different.
java.lang.Double is a (primitive) wrapper type,. There is no equivalent in
CLR; certainly a double can be boxed, but that is not the same.
Said another way:
In Java void f(double x) { ... } is not the same as void f (Double x) {
... }.
In C#, void f(double x) {...} is the same as void f (Double x) { ... }.
Said yet another way
In JAVA: double.class != Double.class
in C#: typeof(double) == typeof(Double)
The distinction in the JVM is the reason ClojureJVM asks you to use the
symbols double, float, int, etc. for type-hinting primitives.
At the moment, ClojureCLR matches the spec of ClojureJVM for type-hinting
primitives. if you hint with a type, such as System.Double or
System.String, other things happen. These other things match ClojureJVM
mostly -- the problem being when the type is a primitive type such as
System.Double.
I think the only place there is a problem is primitive type hints on
parameters and fn return types. Type hints used to avoid reflection are not
a problem.
Your protocol example has the same root problem. Unfortunately, there is
no simple workaround as with parameter type hints. ClojureJVM has no
equivalent to
(extend-protocol FooProto System.Double (foo [d] d))
because System.Double is not the same critter as java.lang.Double. One can
do
(extend-protocol FooProto java.lang.Double ... )
in ClojureJVM, but
(extend-protocol FooProto double (foo [d] d))
is not possible.
The problem is actually the same under the surface:
(extend-protocol FooProto T (foo [d] d))
expands into something including (foo [^T d) d) and we are back to our
primitive type-hinting problem. So, making primitive type-hinting work
using System.Double should also solve this problem.
I'll work on it. Should be this weekend.
-David
On Thursday, November 29, 2012 11:02:19 AM UTC-6, ffailla wrote:
I have discovered some odd behavior when type-hinting fns with
^System.Double:
user= (defn bar [^System.Double d] d)
#'user/bar
user= (bar 1.2)
2.35293190771409E-316
user= (bar 1)
2.35069794048985E-316
The same behavior occurs when extending double via extend-protocol or
extend-type:
user= (defprotocol FooProto (foo [_]))
user= (extend-protocol FooProto System.Double (foo [d] d))
nil
user= (foo 1.2)
2.25126584588049E-316
Any ideas? Thanks.
-Frank Failla
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR: with-open in .NET 3.5 is unable to find .Dispose method on IDisposable
Fiel, Fixed on the master branch as of this morning. -David On Saturday, November 17, 2012 7:46:47 AM UTC-6, FC wrote: Hi DavidM and ClojureCLR users, In ClojureCLR built using .NET 3.5 framework, with-open needs some help finding the .Dispose method on IDisposable objects: It occurs when calling with-open on RegistryKey and System.IO.BinaryWriter instances. Here's the code snippet demonstrating this: http://pastebin.com/KU3euWwJ The problem doesn't occur in ClojureCLR built using .NET 4.0 framework. Does anyone know a workaround? Or should I file a bug? Thank you. -Fiel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Difference between JVM and CLR when destructuring a lazy sequence
Frank: Fixed in the master branch (which is 1.5 dev). I also created a new branch named clojure-1.4.1 that is still a 1.4 version, with the the patch. Also created binary distribution zip files for the new 1.4.1 release. Several other bug fixes included in this update. -David On Friday, November 16, 2012 8:46:01 AM UTC-6, ffailla wrote: Thank you David for looking into this so quickly. For now I am working around this by not destructuring, but I look forward to the patch. Thanks. -Frank On Thursday, November 15, 2012 7:41:39 PM UTC-5, dmiller wrote: The difference is that the JVM version is correct and the CLR implementation has a bug. I'll fix it in the current branch and try to get a patched 1.4 out as soon as I can. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR Build Error
Robert, Scott: Fixed on the master branch. Tripped up by CLR's strange convention for indicating method accessibility. [sotto voce]: Just because a method has the Private flag set, don't think the IsPrivate property is true. It can be IsAssembly instead. [Deeply felt]: Sigh. -David On Tuesday, April 17, 2012 10:04:14 AM UTC-5, RobertLJ wrote: Just wondering has anyone seen this build error from ClojureCLR (The Clojure.Compile Project): Error 3 The command C:\Users\Robert\bob-dev\bob-src\clojureCLR- Builds\clojure-clojure-clr-nodlr-vs11\bin\4.0\Debug \Clojure.Compile.exe clojure.core clojure.core.protocols clojure.main clojure.set clojure.zip clojure.walk clojure.stacktrace clojure.template clojure.test clojure.test.tap clojure.test.junit clojure.pprint clojure.clr.io clojure.repl clojure.clr.shell clojure.string clojure.data clojure.reflect exited with code 1. Clojure.Compile It appears that the build (Clojure.Compile.exe clojure.repl) is failing with the error: System.TypeLoadException: Method 'ReadAsyncInternal' on type 'clojure.repl.proxy$PushbackTextReader$0$_COMP_clojure.repl.clj' from assembly 'clojure.repl.clj, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' is overriding a method that is not visible from that assembly. David, Has there been any progress on this one? I'm looking to use clojure on .Net 4.5 / Windows server 2012 for some prototyping and am also running into this issue. I've got the source forked and project tweaked and loaded in VS2012. I'm willing to fix it if it still needs fixing and, if so, any pointers toward the right spot in the code would be welcome. /stt -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR: StackOverflowException when evaluating cond with large number of clauses
The compiler uses recursive descent in its analysis. Given a VM call stack that does not grow, there will always been some input that causes the compiler to blow stack. In the case of cond, the macro expands into a nested if statements. Given enough clauses, you get the result you have experienced. There are several solutions. (1) Rewrite the compiler to make the analysis use an explicite (heap-allocated) stack.That would be a lot of work. It's not going on my short list anytime soon. (2) Rewrite the compiler to run on a separate thread and create a way (a command-line option, for example) to configure the stack size on the compiler thread. (3) Recompile (actually re-link) Clojure.Main.exe to have a larger stack size. See http://msdn.microsoft.com/en-us/library/8cxs58a6(v=vs.100).aspx (4) Edit the Clojure.Main.exe executable to have a larger stack size. The EDITBIN.EXE program is often used for this. See http://msdn.microsoft.com/en-us/library/xd3shwhf(v=vs.110).aspx. (5) Break up your cond into several (non-nested) statements. Solutions (1) through (4) require access to the CLR compiler toolset or Visual Studio. -David On Saturday, November 17, 2012 10:37:38 AM UTC-6, FC wrote: When ClojureCLR (.NET 3.5 build) evals a cond form with 1024 clauses it throws a StackOverflowException. Cond example code in pastebin: http://pastebin.com/K4QQmjNF Save the example code to bigcond.clj and run Clojure.Main like: Clojure.Main bigcond.clj The number of cond clauses needed to cause a stack overflow varies. Stack trace: System.StackOverflowException was unhandled Clojure.dll!clojure.lang.ASeq.ASeq(clojure.lang.IPersistentMap meta) Line 44 + 0xa bytes C# Clojure.dll!clojure.lang.TypedArraySeqobject.TypedArraySeq(clojure.lang.IPersistentMap meta, object[] array, int index) Line 241 + 0xf bytes C# Clojure.dll!clojure.lang.ArraySeq_object.ArraySeq_object(clojure.lang.IPersistentMap meta, object[] array, int index) Line 734 + 0x19 bytes C# Clojure.dll!clojure.lang.ArraySeq.create(object[] array) Line 41 + 0x44 bytes C# -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: lein-clr 0.2.0 for ClojureCLR
Shantanu, This has been much requested. I plan to give a test-drive over the imminent holiday weekend. -David On Sunday, November 18, 2012 3:03:03 PM UTC-6, Shantanu Kumar wrote: Hi, I pushed lein-clr 0.2.0 https://github.com/kumarshantanu/lein-clr JARs to Clojars a little while ago. The focus of this release is to 1. add dependency support (via NuGet/wget/curl, Leiningen :dependencies) 2. lower the bar to get started with ClojureCLR (with automated download of ClojureCLR) 3. remove the need to call `assembly-load-from` in code The changelog and TODO are here: https://github.com/kumarshantanu/lein-clr/blob/master/CHANGES.md I hope this release is usable enough to start building ClojureCLR apps and libraries with it. This is an early project and can certainly use feedback and contribution. Please let me know what you think. Shantanu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Difference between JVM and CLR when destructuring a lazy sequence
The difference is that the JVM version is correct and the CLR implementation has a bug. I'll fix it in the current branch and try to get a patched 1.4 out as soon as I can. -- Above is all you really need to know, but I find myself forced to continue. :) -- This bug has sitting there from the first commit in the public repo. (That would be early 2009.) The line of code in question is testing for the IList interface. The line has a comment that the JVM implementation changed from IList to RandomAccess, which has no equivalent in the CLR. I didn't know why the change was made, so I left it alone. (The history is lost, but I can place the JVM version change between Nov 08 and Feb 09.) Four years later, I've just discovered the reason. The bug only surfaces in certain circumstances on infinite (lazy) sequences -- and specifically it is triggered by destructuring. LazySeq itself is not the problem -- that's used everywhere. -David On Thursday, November 15, 2012 9:23:05 AM UTC-6, ffailla wrote: I believe I have discovered differing behavior between the JVM and CLR implementations when running the following statement: user (let [foo (repeatedly (fn [] (let [r (rand)] (println in-repeat: r) r))) [f rst] foo] (println return: f)) When run on the JVM with clojure 1.4.0, I get the following output: in-repeat: 0.6929552277817549 in-repeat: 0.7005322422752974 return: 0.6929552277817549 nil user When run on the CLR with clojure-clr 1.4.0, the random number will be printed from in-repeat infinitely, never to return. Is this difference between the JVM and CLR implementations when destructuring a lazy sequence known? Also, why was the random number printed twice on the JVM side. I haven't looked an the implementation, but I would guess this would be due to chunking the sequence. Thanks. -Frank Failla -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR on .net compact?
I believe that Reflection.Emit is not available in .Net Compact Framework. This is essential for the ClojureCLR. This also prevents DLR-based languages such as IronPython from running on .Net CF. -David On Thursday, April 19, 2012 3:11:02 AM UTC-5, David Jagoe wrote: Hi all, Does anyone know whether I can run ClojureCLR on .net compact? Specifically I would need to run it on Windows CE. Currently the application is written in C# which works ok, but I need to rewrite it and I'm deciding between C#, F# and ClojureCLR. Thanks, David -- David Jagoe davidja...@gmail.com +447535268218 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR on .net compact?
On Thursday, April 19, 2012 11:20:05 AM UTC-5, tbc++ wrote: If you AOT compile the ClojureCLR code, will it still depend on Reflection.Emit? Timothy Yes, it will still depend on Reflection.Emit. If you eval, you need it. Also, any place where ClojureJVM does runtime reflection, ClojureCLR uses dynamic DLR expressions to take advantage of polymorphic inline caching. (The DLR is also used to do method resolution, much more compilicated for the CLR.) Dynamic DLR expressions do on-the-fly code gen using Reflection.Emit. (There are hints that Mono.Cecil can be to provide Reflection.Emit capabilities for the DLR on .Net CF, but I'm not going there anytime soon.) -David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR Build Error
We discovered this was due to building on the beta of .Net 4.5. ClojureCLR has not been updated to 4.5 yet. In this case, a new method was introduced in an interface, causing the proxy to have a missing method. 4.5 support coming 'real soon now'. -David On Tuesday, April 17, 2012 10:04:14 AM UTC-5, RobertLJ wrote: Just wondering has anyone seen this build error from ClojureCLR (The Clojure.Compile Project): Error 3 The command C:\Users\Robert\bob-dev\bob-src\clojureCLR- Builds\clojure-clojure-clr-nodlr-vs11\bin\4.0\Debug \Clojure.Compile.exe clojure.core clojure.core.protocols clojure.main clojure.set clojure.zip clojure.walk clojure.stacktrace clojure.template clojure.test clojure.test.tap clojure.test.junit clojure.pprint clojure.clr.io clojure.repl clojure.clr.shell clojure.string clojure.data clojure.reflect exited with code 1. Clojure.Compile It appears that the build (Clojure.Compile.exe clojure.repl) is failing with the error: System.TypeLoadException: Method 'ReadAsyncInternal' on type 'clojure.repl.proxy$PushbackTextReader$0$_COMP_clojure.repl.clj' from assembly 'clojure.repl.clj, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' is overriding a method that is not visible from that assembly. at System.Reflection.Emit.TypeBuilder.TermCreateClass(RuntimeModule module, Int32 tk, ObjectHandleOnStack type) at System.Reflection.Emit.TypeBuilder.CreateTypeNoLock() at System.Reflection.Emit.TypeBuilder.CreateType() at clojure.lang.GenProxy.Generate(Type superclass, ISeq interfaces, String className) in c:\Users\Robert\bob-dev\bob-src\clojureCLR-Builds \clojure-clojure-clr-nodlr-vs11\Clojure\Clojure\CljCompiler \GenProxy.cs:line 113 at clojure.lang.GenProxy.GenerateProxyClass(Type superclass, ISeq interfaces, String className) in c:\Users\Robert\bob-dev\bob-src \clojureCLR-Builds\clojure-clojure-clr-nodlr-vs11\Clojure\Clojure \CljCompiler\GenProxy.cs:line 82 at clojure/core$generate_proxy__14614.invoke(Object , Object ) in core_proxy.clj:line 55 at clojure/core$get_proxy_class__14625.doInvoke(Object ) in core_proxy.clj:line 272 at clojure.lang.RestFn.applyTo(ISeq arglist) in c:\Users\Robert\bob- dev\bob-src\clojureCLR-Builds\clojure-clojure-clr-nodlr-vs11\Clojure \Clojure\Lib\RestFn.cs:line 194 at clojure/core$apply__10331.invoke(Object , Object ) in core.clj:line 601 at clojure/core$proxy__14675.doInvoke(Object , Object , Object , Object , Object ) in core_proxy.clj:line 346 at clojure.lang.RestFn.invoke(Object arg1, Object arg2, Object arg3, Object arg4, Object arg5) in c:\Users\Robert\bob-dev\bob-src \clojureCLR-Builds\clojure-clojure-clr-nodlr-vs11\Clojure\Clojure\Lib \RestFn.cs:line 618 at clojure.lang.Var.invoke(Object arg1, Object arg2, Object arg3, Object arg4, Object arg5) in c:\Users\Robert\bob-dev\bob-src \clojureCLR-Builds\clojure-clojure-clr-nodlr-vs11\Clojure\Clojure\Lib \Var.cs:line 761 at clojure.lang.AFn.ApplyToHelper(IFn fn, ISeq argList) in c:\Users \Robert\bob-dev\bob-src\clojureCLR-Builds\clojure-clojure-clr-nodlr- vs11\Clojure\Clojure\Lib\AFn.cs:line 208 at clojure.lang.Var.applyTo(ISeq arglist) in c:\Users\Robert\bob-dev \bob-src\clojureCLR-Builds\clojure-clojure-clr-nodlr-vs11\Clojure \Clojure\Lib\Var.cs:line 874 at clojure.lang.Compiler.MacroexpandSeq1(ISeq form) in c:\Users \Robert\bob-dev\bob-src\clojureCLR-Builds\clojure-clojure-clr-nodlr- vs11\Clojure\Clojure\CljCompiler\Compiler.cs:line 893 at clojure.lang.Compiler.AnalyzeSeq(ParserContext pcon, ISeq form, String name) in c:\Users\Robert\bob-dev\bob-src\clojureCLR-Builds \clojure-clojure-clr-nodlr-vs11\Clojure\Clojure\CljCompiler \Compiler.cs:line 1501, compiling: (clojure/repl.clj:149) Any Info would be apreciated Robert -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] Korma SQL ported to ClojureCLR
On Friday, April 6, 2012 6:23:43 PM UTC-5, Aaron wrote: I think it's a goal to get Clojure.dll on nuget soon, but it hasn't happened yet. Hopefully soon. Still, we'll need a good build system for ClojureCLR that does everything that lein does. But, I don't think that should be that complicated if nuget is used as a basis. ClojureCLR on nuget is a goal, and one fairly easy to accomplish, in the sense of just packaging the DLLs and getting them posted. However, the primary use of NuGet is pulling dependencies into projects in Visual Studio.That means spending some time working the vsClojure Visual Studio extension to get all the pieces playing together. When people say lein on .net or good build system for ClojureCLR, is Visual Studio integration usually meant, or is there a standalone experience being coveted? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-clr loadpath points to D: harddrive
On Jan 19, 10:25 pm, jayvandal s...@ida.net wrote: Why does the clr point to d: work? user= (use :reload 'ui) FileNotFoundException Could not locate db.mysql.clj.dll or db/ mysql.clj on load path. clojure.lang.RT.load (d:\work\clojure-clr\Clojure\Clojure\Lib \RT.cs:3065) It is not looking in d:\work\... to resolve the load. The d:\work\clojure-clr\Clojure\Clojure\Lib\RT.cs:3065 indicates the source line where the exception was thrown. It should be looking for the file to load starting from the root. From the text, it appears there is a load or use or require within your ui.clj looking for db/mysql. As the error statement indicates, starting from the current directory, it has looked for ./ db.mysql.clj.dll or ./db/mysql.clj. The latter being clj source, the former being the standard name for the assembly that results from AOT-compiling of db/mysql.clj. Clearly something is not where it should be. You can set roots other than the current working directory via the environment variable CLOJURE_LOAD_PATH. Actually, I'm planning a post for http://clojureclr.blogspot.com/ regarding all environment variables that are referenced, plus some info on AOT-compilation. -David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-clr loadpath points to D: harddrive
It shouldn't, obviously. It appears to be holding on to a compile- time value somewhere. I'll track it down this weekend. -David On Jan 19, 10:25 pm, jayvandal s...@ida.net wrote: Why does the clr point to d: work? user= (use :reload 'ui) FileNotFoundException Could not locate db.mysql.clj.dll or db/ mysql.clj on load path. clojure.lang.RT.load (d:\work\clojure-clr\Clojure\Clojure\Lib \RT.cs:3065) user= -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: New home for ClojureCLR
Thanks. I hope 2012 is the year for community building for ClojureCLR, And maybe some IDE building. -David On Jan 1, 12:32 pm, rippinrobr rippinr...@gmail.com wrote: I would also like to thank David for his work on ClojureCLR. ClojureCLR is going to make for a great 2012 for me! -Rob Rowe On Jan 1, 1:01 pm, Stuart Sierra the.stuart.sie...@gmail.com wrote: And thanks to David Miller for his excellent and continued work on ClojureCLR! I'm happy that we have such a great community to support Clojure on the .NET platform. -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Want some books or issues about ClojureCLR
As noted, the biggest difference is interop. I've started posting on such matters at http://clojureclr.blogspot.com. These posts assume basic familiarity with Clojure. I highly recommend Rob's (@rippinrobr) series of posts at http://www.myclojureadventure.com/ for getting started with ClojureCLR. -David On Dec 30, 12:20 am, 王亚平 wizzardcl...@gmail.com wrote: Why God like dmiller don't write such a book? It must be very interesting. On Tue, Nov 29, 2011 at 8:45 AM, dmiller dmiller2...@gmail.com wrote: The wiki on the github repo has some information about getting started and how to accomplish some interop that is special to CLR. https://github.com/richhickey/clojure-clr/wiki and make sure to look at https://github.com/richhickey/clojure-clr/wiki/_pages for the complete list. Rob Rowe (http://rob-rowe.blogspot.com/, @rippinrobr) has been blogging recently on getting started with ClojureCLR. -David On Nov 28, 4:03 pm, Stuart Sierra the.stuart.sie...@gmail.com wrote: Hi Adam, Clojure CLR is a community effort without official support. I am not aware of any books specifically about ClojureCLR. However, Clojure the *language* should be nearly identical between the JVM and CLR versions. Only interop with the host platform will be different. So any Clojure language book will be helpful in learning the language. Regards, -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Want some books or issues about ClojureCLR
planned to support sounds about right. I do not know that it does not work. If any adventuresome mono-ites (mono-istas?) cares to give it a try ... . -David On Dec 30, 12:07 pm, Shantanu Kumar kumar.shant...@gmail.com wrote: Does ClojureCLR work (or is planned to support) Mono[1] by any chance? [1] Mono –http://www.mono-project.com/Main_Page Regards, Shantanu On Dec 30, 9:41 pm, dmiller dmiller2...@gmail.com wrote: As noted, the biggest difference is interop. I've started posting on such matters athttp://clojureclr.blogspot.com. These posts assume basic familiarity with Clojure. I highly recommend Rob's (@rippinrobr) series of posts athttp://www.myclojureadventure.com/forgetting started with ClojureCLR. -David On Dec 30, 12:20 am, 王亚平 wizzardcl...@gmail.com wrote: Why God like dmiller don't write such a book? It must be very interesting. On Tue, Nov 29, 2011 at 8:45 AM, dmiller dmiller2...@gmail.com wrote: The wiki on the github repo has some information about getting started and how to accomplish some interop that is special to CLR. https://github.com/richhickey/clojure-clr/wiki and make sure to look at https://github.com/richhickey/clojure-clr/wiki/_pages for the complete list. Rob Rowe (http://rob-rowe.blogspot.com/, @rippinrobr) has been blogging recently on getting started with ClojureCLR. -David On Nov 28, 4:03 pm, Stuart Sierra the.stuart.sie...@gmail.com wrote: Hi Adam, Clojure CLR is a community effort without official support. I am not aware of any books specifically about ClojureCLR. However, Clojure the *language* should be nearly identical between the JVM and CLR versions. Only interop with the host platform will be different. So any Clojure language book will be helpful in learning the language. Regards, -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR PInvoke and DLLImport attribute
Fiel's problem was a little simpler -- his dllimport method was out in C# class that was imported. The problem appears to be that reflection is not finding the method. That is likely either a signature-matching problem (declared args vs supplied params) or even just having the flags set a little wrong on the Type.GetMethods in the reflection code so that the dllimport method is excluded. Should be an easy fix. Doing it all in Clojure as you suggest -- I'll work on it. Actually, the de Icaza blog entry is priceless. It has actual DLR code that can be, er, um, mined for ideas. Thanks for the link. -David On Dec 2, 9:59 am, Timothy Baldridge tbaldri...@gmail.com wrote: If you could give me a small example of how you would like to use this, I can take a look. I suggest you read Miguel de Icaza's blog entry here about using dynamic and pinvoke. The concept is quite simple. Basically you have to generate a method on-the-fly and tag it with the correct attributes, then simply use that method to call the pinvoke routines. http://tirania.org/blog/archive/2009/Aug-11.html The one thing to note though, is the above blog uses the CallingConventions enum value for Linux. Windows has standardized on a different calling convention, so you may have to dynamically switch to the correct enum value depending on the platform. From there it should be possible to setup something like this (Pinvoke info taken fromhttp://pinvoke.net/default.aspx/user32.MessageBox): (defdllimport user32 user32.dll :char-set-auto) (def message-box (extern user32 ^Integer MessageBox [^Integer hWind ^String text ^String caption ^Integer options])) Anyway, just some ideas. Timothy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR PInvoke and DLLImport attribute
Not supported at present. I'd have to think a little about it, but at first glance, it seems doable. I've not look under the surface at how the CLR handles PInvoke via DLLImport, so some investigation is required. Attributes are supported on method defs in various places (but not yet documented). Allowing the equivalent of 'extern', specifically not having a method definition with the declaration is not supported where it would count. If you could give me a small example of how you would like to use this, I can take a look. -David On Dec 1, 8:09 am, Fiel Cabral e4696wyoa63emq6w3250kiw60i4...@gmail.com wrote: Does ClojureCLR support PInvoke and the DLLImport attribute or something similar? (e.g., from PInvoke.net) DllImport(crypt32.dll, EntryPoint = CertGetNameString, CharSet = CharSet.Auto, SetLastError = true)] static extern System.UInt32 CertGetNameString(IntPtr CertContext, System.UInt32 lType, System.UInt32 lFlags, IntPtr pTypeParameter, System.Text.StringBuilder str, system.UInt32 cch); Thanks. -Fiel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Want some books or issues about ClojureCLR
The wiki on the github repo has some information about getting started and how to accomplish some interop that is special to CLR. https://github.com/richhickey/clojure-clr/wiki and make sure to look at https://github.com/richhickey/clojure-clr/wiki/_pages for the complete list. Rob Rowe (http://rob-rowe.blogspot.com/, @rippinrobr) has been blogging recently on getting started with ClojureCLR. -David On Nov 28, 4:03 pm, Stuart Sierra the.stuart.sie...@gmail.com wrote: Hi Adam, Clojure CLR is a community effort without official support. I am not aware of any books specifically about ClojureCLR. However, Clojure the *language* should be nearly identical between the JVM and CLR versions. Only interop with the host platform will be different. So any Clojure language book will be helpful in learning the language. Regards, -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure on PyPy
On Nov 17, 10:07 am, Timothy Baldridge tbaldri...@gmail.com wrote: With the clojureclr for example, it supports pretty much everything clojure does sans java, and gains all the .net interop. True...true, it supports it, but it's still a 2nd class citizen. For instance, we don't have lein, ring, parts of contrib, IDEs, etc. All the examples, all the books are all about Clojure on the JVM. Do anything else and you can forget using Clojars, and 90% of the ecosystem built around Clojure. Now, what should be done at some point (IMO) is to implement Clojure in Clojure. Although implementing Clojure-in-Clojure no doubt should be done, that does not make lein work on other platforms, it does not create IDEs that are effective for other platforms (Visual Studio), it does not translate the contrib libs, etc. -David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
2011 ClojureCLR survey analysis
An analysis of the 2011 ClojureCLR survey and a plan of action is now available here: http://clojureclr.blogspot.com/2011/11/survey-says-call-to-action.html Consider this also notification that the ClojureCLR blog exists. You can turn your dial there for future updates. -David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: 2011 ClojureCLR survey analysis
A parallel set of contribs matching the clojure.java.* libs does make sense. Some already exist. As part of the core distribution, there are clojure.clr.io and clojure.io.shell. There are several levels of porting difficulty. (1) libs with very little interop, hence requiring little or no editing to port. clojure/walk.clj is like that. (2) libs that are essentially wrappers around a platform library. clojure.java.io and java.jdbc are examples. (3) the rest. An example is data.json. Case (1) is easy. Case (2) usually means no port, unless there is a platform library on the other platform that is close. In the case of clojure.clr.io and clojure.java.io, you really have to write a different set of functions to reveal the underlying capabilities. In fact, when I wrote clojure.clr,io, I probably preserved a little too much of the structure of clojure.java.io, rather than doing a complete redesign from the ground up. A different example of case (2) is not a separate lib: the functions related to regular expression handling in clojure/core.clj. Regular expressions between the two platforms are just enough different that I couldn't port by simple changes in interop calls. There are significant enough differences handling iteration state that I had to exert some actual thought. Still, I could maintain the clojure-side API without change. Case (3) is tough. I can't say that I have enough experience to fully categorize the possibilities. But let's use data.json as an example. I have ported it (but not published it yet). Something like 84 changes to interop calls, plus changes to type hints. Almost all due to calls on I/O. (:import (java.io PrintWriter PushbackReader StringWriter StringReader Reader EOFException))) I had to make minor changes to algorithms in a few places.Could the original have been written to make porting easier? I can think of a few ways to do that, but the best ways require read-time conditionalization and Rich is against that. Would writing against clojure.java.io instead of directly against java.io have helped. Not much. Copy and edit is about the only real solution. I've probably said too much already. -David On Nov 3, 12:54 pm, Sean Corfield seancorfi...@gmail.com wrote: On Thu, Nov 3, 2011 at 10:35 AM, dmiller dmiller2...@gmail.com wrote: An analysis of the 2011 ClojureCLR survey and a plan of action is now available here: http://clojureclr.blogspot.com/2011/11/survey-says-call-to-action.html Nice set of analyses David - great work! On this one:http://clojureclr.blogspot.com/2011/11/survey-says-port-those-libs.html I wonder if we neet to consider a parallel set of contribs for ClojureCLR that match clojure.java.*? That would seem to help with interop and ecosystem which are two other points on the survey. clojure.net.* is likely to be open to misinterpretation, I suspect, so clojure.clr.* would seem more logical? I don't know enough about .NET / CLR to help (although I'm curious) but I suspect a port of clojure.java.jdbc to clojure.clr.ado or something similar would be useful? -- Sean A Corfield -- (904) 302-SEAN An Architect's View --http://corfield.org/ World Singles, LLC. --http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: 2011 ClojureCLR survey analysis
I'm sure CL syntax will work for my needs. I'm not sure that anyone will like how I might use it to make code more portable. :) That could also stand some discussion. Almost OT, ClojureCLR already extends the reader syntax to accommodate symbols naming types with really bad characters in them, using a modified form of |-escaping from CL. It allows symbols such as | System.Collections.Generic.IList`1[System.Int32]| -- backquotes and square brackets are a bit problematic, but to fit in with how types are handled, I need manifest symbols with CLR-compatible names. (Unless we either define a new syntax or allow type synonyms or ... .) Described in https://github.com/richhickey/clojure-clr/wiki/CLR-Interop . Making something like this official would be most helpful, particularly if read-time conditionalization comes in and this construct might get seen by the regular Clojure reader. -David On Nov 3, 2:47 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: I had to make minor changes to algorithms in a few places. Could the original have been written to make porting easier? I can think of a few ways to do that, but the best ways require read-time conditionalization and Rich is against that. Would writing against clojure.java.io instead of directly against java.io have helped. Not much. Copy and edit is about the only real solution. I don't think the against that part is true (any longer?). We have been talking about adding read-time conditionalization in Clojure 1.4:http://dev.clojure.org/display/design/Cross-Dialect+Enhancements AFAIK nobody has taken any time to look at it, other than a hand-waving start by presuming Common Lisp syntax and approach is decent and see where that falls down. Would love to leave the Conj with this done, or with somebody fired up to do it. Stu Stuart Halloway Clojure/corehttp://clojure.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
2011 ClojureCLR survey responses summarized
A summary of the responses to the recent ClojureCLR survey is available at http://clojureclr.blogspot.com/2011/11/results-of-2011-clojureclr-survey.html This is only a summary of the data. Editorializing, conclusion-izing and other opinion-izing will come later. -David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure.Compile output in clojure-clr 1.3.0
That is an side effect of changes that were made to naming/location of the assemblies output from compilation. Whether it's a feature or bug depends on how hard it is to change. :) Issue posted. -David On Oct 29, 6:58 am, Ian i...@iandavies.org wrote: Hi all, In Clojure 1.2.0, if I run a command like: c:\clojure\Clojure.Compile.exe program then the output .dll and .exe files turn up in the current directory as expected, but since 1.3.0 the output files land in the c:\clojure\ directory (i.e. the location of the compiler), which seems rather strange. Is this a feature or a bug? Cheers, Ian -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR survey now open
ClojureCLR survey closing tonight at midnight my time (Central Daylight Time). On Oct 26, 12:22 pm, dmiller dmiller2...@gmail.com wrote: Keep those cards and letters coming. Just a reminder that time is running out on participating in the ClojureCLRsurvey. I put in a BOF request for ClojureCLR at the conj on the spreadsheet that was getting passed around. I'll publish thesurveyresults prior to conj. I hope that will help drive the conversation. -David On Oct 22, 11:43 pm, dmiller dmiller2...@gmail.com wrote: Inspired by Chas Emerick's Clojure surveys, I have created asurveyto assess the experiences and needs of (potential or actual) users of ClojureCLR. Building community and lowering barriers to adoption have to be priorities for this project. I hope thissurveywill provide some guidance for this. Thesurveyis available here: https://docs.google.com/spreadsheet/viewform?formkey=dDE3YnlYbXBxc3lj... Thesurveyis will be available through October 31. For more information:http://clojureclr.blogspot.com/2011/10/2011-clojureclr-survey-is-open... If there is interest, perhaps a ClojureCLR BOF at the conj to discuss the results? -David Miller -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR survey now open
Keep those cards and letters coming. Just a reminder that time is running out on participating in the ClojureCLR survey. I put in a BOF request for ClojureCLR at the conj on the spreadsheet that was getting passed around. I'll publish the survey results prior to conj. I hope that will help drive the conversation. -David On Oct 22, 11:43 pm, dmiller dmiller2...@gmail.com wrote: Inspired by Chas Emerick's Clojure surveys, I have created a survey to assess the experiences and needs of (potential or actual) users of ClojureCLR. Building community and lowering barriers to adoption have to be priorities for this project. I hope this survey will provide some guidance for this. The survey is available here: https://docs.google.com/spreadsheet/viewform?formkey=dDE3YnlYbXBxc3lj... The survey is will be available through October 31. For more information:http://clojureclr.blogspot.com/2011/10/2011-clojureclr-survey-is-open... If there is interest, perhaps a ClojureCLR BOF at the conj to discuss the results? -David Miller -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ClojureCLR survey now open
Inspired by Chas Emerick's Clojure surveys, I have created a survey to assess the experiences and needs of (potential or actual) users of ClojureCLR. Building community and lowering barriers to adoption have to be priorities for this project. I hope this survey will provide some guidance for this. The survey is available here: https://docs.google.com/spreadsheet/viewform?formkey=dDE3YnlYbXBxc3ljVU80bjNnTVZaMlE6MQ The survey is will be available through October 31. For more information: http://clojureclr.blogspot.com/2011/10/2011-clojureclr-survey-is-open.html If there is interest, perhaps a ClojureCLR BOF at the conj to discuss the results? -David Miller -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
[ANN] ClojureCLR 1.3.0 released
ClojureCLR 1.3.0 is now available. Same updates as Clojure 1.3.0. Same acknowledgments, as this depends on the work of all those fine people who bring you Clojure on the JVM. Additional acknowledgments: - Kurt Schelfthout - Shawn Hoover - David Powell - Alan Salewski To get started with a binary distribution: https://github.com/richhickey/clojure-clr/wiki/Getting-started-binary-distribution To get started with source: https://github.com/richhickey/clojure-clr/wiki/Getting-started-source-distribution - David Miller -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
I would be concerned about this group, if there was any evidence of existence. On Aug 19, 2:59 am, Ken Wesson kwess...@gmail.com wrote: And, maybe, the ones who have to go and reconfigure everything when they upgrade ... -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
Several comments: (a) 'clojure.load.path' is not new in 1.3. It's been in the code since at least May, 2009. (b) Regarding Dimitre's comment below, I probably did have Java system properties on my mind at the time. I guarantee that I was not thinking of picking Bash-compliant names. I doubt that I gave it much thought at all. (c) It could be changed to something like CLOJURE_LOAD_PATH instead. Would that cause a problem for anyone? -David On Aug 17, 3:25 pm, Dimitre Liotev lio...@gmail.com wrote: - A name like clojure.load.path breaks a widely accepted convention: environment variable names usually consist of capital letters and underscores. So we have MAVEN_HOME, JAVA_HOME, ANT_HOME, etc. When I see a name like clojure.load.path my first thought would be that this is a Java system property, not an environment variable. I think that it would be wise to stick to the convention and use variable names that are Bash compliant. I would use CLOJURE_LOAD_PATH for an environment variable name and clojure.load.path for a Java system property name. -- Dimitre Liotev -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR NotImplementedException
It is the same for ClojureCLR. -David On Aug 2, 8:22 am, Meikel Brandmeyer (kotarak) m...@kotka.de wrote: Hi, Am Dienstag, 2. August 2011 11:03:31 UTC+2 schrieb Ralph Moritz: (defn details [] (let [hash (System.Collections.Hashtable.)] (doto hash (. Add Name Ralph) (. Add Age 27)) hash)) (gen-class :name ClrExperiments.Employee :methods [[details [] System.Collections.Hashtable]]) You have to name the function -details or specify a different prefix via the gen-class clause. In the JVM Clojure that is. I would expect it to be the same on CLR. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-clr - getting started on Windows WPF
Reloading will definitely cause a problem. According to MS docs: Only one instance of the Application class can be created per AppDomain, to ensure shared access to a single set of application- scope window, property, and resource data. Consequently, the default constructor of the Application class detects whether the instance being initialized is the first instance in an AppDomain; if it is not, an InvalidOperationException is thrown. The Application object for the current AppDomain is exposed from the static Current property. Thus: (import 'System.Reflection.Assembly) (Assembly/LoadWithPartialName PresentationFramework) (import 'System.Windows.Application) Application/Current ;= nil (Application.);= #Application System.Windows.Application Application/Current ;= #Application System.Windows.Application (Application.) InvalidOperationException Cannot create more than one System.Windows.Application instance in the same AppDomain. System.Windows.Application..ctor (:0) I don't know why you'd need the app atom since you can just use Application/Current. Similarly, you could check Application/Current before doing (Application.) I suppose if you really wanted to get fancy, you could create the WPF application in other AppDomain and then wipe it. Not sure why. NB: I've not done any WPF work, just working from general principles. -David On Apr 13, 6:48 am, kjeldahl mariusauto-googlegro...@kjeldahl.net wrote: Following up on my own subject, I've created an updated gist to run on recent builds of clojure-clr (1.3.0-master-SNAPSHOT) based on another gist I found. It's not the prettiest of code I've found, but I guess CLR's abstractions and threading models can be blamed for a lot of it. What's more annoying though is that while the gist below runs fine when pasted into a running repl, it only does so the first time. Close the window and paste it once more, and nothing appears. There may be an issue with the CLR AppDomain model only allowing one instance of an Application object or similar (based on messages I've encountered while exploring), but I don't really know and I haven't managed to get everything to completely unload so that the code would work when invoked repeatedly within a running repl. If anybody knows how this can be fixed (without restarting the repl environment), please chime in. I like the statelessness offered by clojure and a running repl, but the code as it currently exist doesn't really support this model. The updated gist can be found here: https://gist.github.com/917391 Thanks, Marius K. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR startup times...
core.clj and company are AOT-compiled. The dll's are loaded during startup, not the clojure source. When I run a profiler on it during startup, it reports almost all time being taken by the JITter. I'm open to suggestions on improving this. In particular, more detailed profiling information would be of interest. -David On Mar 18, 8:16 am, Timothy Baldridge tbaldri...@gmail.com wrote: Just downloaded the CLR version of clojure and are experiencing a pretty awkward boot up time of the ClojureMain.exe (~10 sec) I've tried to ngen the exe and it's dependencies but without any luck. Compiling and Running from within VS2010 it takes approximately the same... Sadly, I think this is normal. Clojure on the JVM starts up in about 4-5 sec on my machine. I've found that Clojure-CLR is much slower. As an example here's what's happening: 1) the Clojure-CLR assembly loads 2) Clojure-CLR is run through some initial JIT compilation 3) Clojure-CLR loads core.clj which is about 200KB of Clojure code 4) core.clj is translated to CLR classes, functions, etc. 5) core.clj is run through the JIT 6) other supporting .clj files are read, translated, and run through the JIT 7) now you are at the REPL I think the only real way to improve these startup times is to do what Python does, and have cached assemblies so that core.clj doesn't have to be re-compiled each and every time. But as far as I know no one is even looking into this. Timothy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR startup times...
No signed assemblies. What got you below the reported JIT activity into the real problem? On Mar 18, 11:37 am, Scott Thoman scott.tho...@gmail.com wrote: I've had a similar issue unrelated to clojure. In my case we had some signed assemblies and the CLR was taking a long time, in certain environments, to go out and check for certificate revocations when verifying signatures. IIRC, the initial profiling I did made it look like the time was spent JIT-ing though it wasn't. I've not played at all with clojure-CLR at this point so I don't know if my experience helps or is related to this issue. -stt -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure CLR ISeq IEnumerable
I hesitate to modify the inheritance structure of Clojure's interfaces. ClojureCLR does follow ClojureJVM in providing support for these interfaces in the abstract base classes underlying things such as PersistentTreeMap. In ClojureCLR 1.3-alpha: public class PersistentTreeMap : APersistentMap, IObj, Reversible, Sorted, IEnumerableIMapEntry, IDictionary public abstract class APersistentMap: AFn, IPersistentMap, IDictionary, IEnumerableIMapEntry, MapEquivalence, IDictionaryObject,Object The only difference in 1.3-alpha versus 1.2 is that 1.3 adds the generics IEnumerableIMapEntry and IDictionaryObject,Object for interop with System.Linq and related libraries. 1.2 does have the IEnumerable defined. The entries iterated are IMapEntry. So you should be able cast directly to IEnumerable in either version, without casting to PersistentTreeMap. -David On Mar 7, 5:54 pm, Timothy Pratley timothyprat...@gmail.com wrote: Feature request: It would be handy for ISeq to inherit IEnumerable. My use case is wanting to expose an IEnumerable Values from a Clojure IPersistentMap (vals ) call Currently I can do it easily enough by casting to PersistentTreeMap which has a .Values implementation, but I suspect there is probably a smarter solution... :) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: CLR classpath
You might be interested in the difference between the 1.2 version (available as binary download) and the current master branch (1.3- alpha) regarding handling of the AOT-compiled assemblies. In 1.2, ClojureCLR matches directory structure with ClojureJVM: compile clojure/core.clj, the assembly is in the clojure subdirectory, clojure/core.clj.dll. That directory structure has to be maintained below your application's base directory. In the 1.3-alpha version, classpath information (JVM notion) is backed into the assembly name (CLR notion), so that clojure/core.clj compile into clojure.core.clj.dll. This dll can go directly into the application's base directory. This change solves some problems that I won't bore anyone with. -David On Mar 3, 8:23 pm, Timothy Pratley timothyprat...@gmail.com wrote: On Wed, Mar 2, 2011 at 8:39 AM, dmiller dmiller2...@gmail.com wrote: (1) I think the copy solution is the easiest. Ok sounds good (2) I'll have to look at the ambiguous match problem. User error on my part; I figured out that mixing .NET versions is bad... switch to compiled from source and it is working beautifully now. Thanks! Regards, Timothy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: CLR classpath
(1) I think the copy solution is the easiest. ClojureCLR deals with its dependencies on the DLR dlls exactly as you describe, with custom build step to copy DLLs from a lib directory. You will need a project reference at least to Clojure.dll. You will need the files in clojure/ subdirectory copied in, maintaining the directory structure. You do not need to add references to them. (2) I'll have to look at the ambiguous match problem. In the meantime, you might try working with one of the 'create' factory methods in PersistentTreeMap. Or, since you appear to be creating an empty map, just use PersistentTreeMap.EMPTY (yeah for immutability) David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Installing Clojure-CLR 1.3 alpha on Win XP with .Net 4.0
Done. Thanks for pointing this out. -David On Feb 10, 3:42 pm, Robin Munn robin.m...@gmail.com wrote: I just ran into an interesting problem installing the Clojure-CLR 1.3 alpha (https://github.com/downloads/richhickey/clojure-clr/clojure-clr-1.3.0...) on an XP machine with .Net 4.0 installed. Downloading and unzipping the .zip file, then running Clojure.Main.exe at a command-line prompt, yielded the following exception: Unhandled Exception: System.TypeInitializationException: The type initializer for 'Clojure.CljMain' threw an exception. --- System.TypeInitializationException: The type initializer for 'clojure.lang.RT' threw an exception. --- System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. Seehttp://go.microsoft.com/fwlink/?LinkId=155569for more information. At that link, I found the following text which gave me a clue as to how to solve this: If an application has been copied from the Web, it is flagged by Windows as being a Web application, even if it resides on the local computer. You can change that designation by changing the file properties, or you can use the loadFromRemoteSources element to grant the assembly full trust. The problem, restated, was that the .zip file was flagged when I downloaded it as coming from a remote source, and thus when I unzipped it, all the files inside were flagged likewise. The simplest solution was to right-click the .zip file *before* unzipping it, and in the Properties dialog, click the Unblock button at the bottom of the dialog. Then all the files in the .zip were considered clean by Windows and I didn't have to unblock each file individually. (There may be a command-line method to unblocking files in Windows, but I don't know what it is; I spend most of my time in Linux). It might be worth updating the wiki page (https://github.com/richhickey/clojure-clr/wiki/Getting-started-binary...) to note that one extra step is required between downloading and unzipping if you're running the .Net 4.0 version of Clojure-CLR. -- Robin Munn robin.m...@gmail.com GPG key 0x4543D577 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Helper functions for accessing properties in clojure-clr 1.2.0
Specifically, in ClojureCLR property access in CLR interop is treated in the same way as fields and zero-arity methods. For class properties, ClassName/PropertyName works. For instance properties, (.PropertyName instance) or (. instance PropertyName) In essence, fields, properties and zero-arity methods are referenced in the same way, and are checked in this order. You can also access the getter/setter methods of a property directly. (get_PropertyName and (set_PropertyName) Where properties are not handled is in type/interface specification/ implementation. Specifically, places that allow method definition (gen-interface and company) and places that allow method definition (deftype and company) do not allow specification of properties. Technically, this is quite easy. The difficutly is that the syntax of these macros typically do not make it easy to distinguish the intent of defining properties versus defining zero-arity methods. This is discussed more fully at https://github.com/richhickey/clojure-clr/wiki/Extending-deftype-and-company-for-CLR. I still need to come up with a good mechanism for referring to events. Suggestions welcomed. --David On Feb 2, 9:09 pm, Matthew D. Swank akopa.gmane.pos...@gmail.com wrote: On Feb 1, 6:10 pm, Matthew D. Swank akopa.gmane.pos...@gmail.com wrote: AFAIK clojure-clr doesn't have built-in support for accessing properties. Ok David Miller let me know off list the existing interop handle properties. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ClojureCLR: change in naming/location of AOT-compiled assemblies
I've made a change to the naming and location of AOT-compiled assemblies generated by ClojureCLR. Previously, ClojureCLR had followed the conventions of ClojureJVM in naming/locating class files (assemblies in CLR-land) generated by AOT- compilation. Thus, doing (compile 'a.b.c) would find source file AppBase\a\b\c.clj and generate AppBase\a\b\c.clj.dll. In the lastest commit, this has been changed so that (compile 'a.b.c) will find source file AppBase\a\b\c.clj and generate AppBase \a.b.c.clj.dll. Obviously, this change will force recompilation of existing apps. Otherwise, it should have no effect. Completely arbitrarily, ClojureCLR names the AOT-compilation generated files whatever.clj.dll. The .clj. is superfluous, but does serve as a visual indication of the assembly's origin. Question: Useful, or just annoying? Unnecessary explanation: The reason for the change has to do with limitations of assembly loading. As previously coded, (compile 'a.b.c) would generate AppBase\a\b.c.clj.dll and (compile 'd.e.c) would generate AppBase\d \e\c.clj.dll. There are circumstances where the latter would not compile but might load the former instead. This has to do with name resolution in the load-from context in assembly loading, which does not consider location. The simplest solution was to encode namespace information i the filename, so assemblies can be differentiated by file name instead of location. -David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Porting libraries to ClojureCLR
On Nov 24, 1:24 pm, Ken Wesson kwess...@gmail.com wrote: I gave some thought to the Integer vs. Int32 issue. I think what would help here is a way to alias classes when :importing them. It would require tweaking the ns macro and possibly parts of the runtime. The outcome would be to allow something like (ns foo (:import (java.util.concurrent AtomicBoolean (ConcurrentHashMap :as CHM) AtomicInteger))) (defn make-default-chm [] (CHM. 12 12 12)) ... Handy so far for abbreviating some longer classnames, and the application to CLR portability is apparent: (ns foo (:import (System (Int32 :as Integer In theory, you'd just add this import to make code full of ^Integer hints compile under ClojureCLR. You'd still need two versions of the source file though, a CLR version with the import and a JVM version without. But then why not go even further and have the ns macro able to tell what platform it's on? (ns foo (:import-jvm (package1.package2 BarBaz as BBaz)) (:import-clr (Package3.Package4.BooBaz as BBaz))) Regarding enhancements to ns/import/etc.: Not to speak for Rich, but he has in the past been resistant to modifications to these elements to support CLR vs JVM. Regarding Int32 vs Integer: They are really not equivalent. Int32 is equivalent to Integer/TYPE or a ^int type hint, not to java.lang.Integer. There is no CLR equivalent to the JVM Integer, Long, Number, etc., a fact which is currently cause me no end of problems as I try to incorporate into ClojureCLR all the compiler work RIch co have done for 1.3. In fact, with 1.3, you will not be able to provide Int32 type hints on fn args or return values. CLojureJVM in 1.3 disallows primitive type hints in these places, wiping out ^int (JVM) and ^Int32 (CLR). You might find this discussion relevant: http://groups.google.com/group/clojure-dev/browse_thread/thread/6f9c9b7f36ae3134 -David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Installing Clojure CLR
Github automatically provides a zip of any tagged commit, so you can download the source for the 1.2.0 release. That's the link with the little tag icon on it. That is a source distribution and you'd have to follow a long involved path to get that to run. I took the instructions for that off the wikii. I don't recommend this. The best options at the moment: (1) Binary distribution: (a) clojure-clr-1.2.0.zip (b) clojure-clr-1.3.0-alpha1-debug-3.5.zip (c) clojure-clr-1.3.0-alpha1-debug-4.0.zip (2) Source distribution: download the repo, use the master branch. The binary distributions are EXE/DLL/CLJ, no C# source, projects or solutions. To start the REPL, you'll find Clojure.Main.exe in the top- level directory. The 1.2.0 distribution is .NET 3.5 only. The 1.3.0-alpha1 distributions give a choice of runtime. The master branch at present is pretty much the same as 1.2 except for the new build process + conversion to VS2010 and two small bug fixes. The wiki has instructions for getting the source ready to compile in VS2010. Basically, download the repo, download a zip with support DLLs and unzip in the right place, and go. On Oct 28, 9:08 am, Sean Devlin francoisdev...@gmail.com wrote: What is the full path of that program in the 1.2.0 bundle? I can't seem to find it. On Oct 27, 4:23 pm, dmiller dmiller2...@gmail.com wrote: Let me know on the error. Re REPL: run Clojure.Main.exe to start. -David On Oct 27, 2:54 pm, Sean Devlin francoisdev...@gmail.com wrote: So, I just started running w/ Clojrue CLR. I'm trying to get 1.2 up and running. I followed the instructions here: http://github.com/richhickey/clojure-clr/wiki/Getting-started-binary-... And got an error report. Doesn't seem like a show stopper, but I can post it later. Are there instructions somewhere on how to start a REPL? Sean -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Installing Clojure CLR
Let me know on the error. Re REPL: run Clojure.Main.exe to start. -David On Oct 27, 2:54 pm, Sean Devlin francoisdev...@gmail.com wrote: So, I just started running w/ Clojrue CLR. I'm trying to get 1.2 up and running. I followed the instructions here: http://github.com/richhickey/clojure-clr/wiki/Getting-started-binary-... And got an error report. Doesn't seem like a show stopper, but I can post it later. Are there instructions somewhere on how to start a REPL? Sean -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ClojureCLR now on VS2010/.NET4 + easier to get started
ClojureCLR can now be compiled to run under either .NET 3.5 or .NET 4.0. To support this, development is now under Visual Studio 2010. The build process has been improved (thanks to Kurt Schelfthout). Among other improvements, it will be easier for those wanting to play to get started. To get started: For users: download an appropriate zip file from the Downloads area on the github site, unzip, run Clojure.Main.exe. For developers: clone the repo, pull down lib.zip from the Downloads area and unzip into your repo, open the Solution in VS 2010, pick your configuration (Debug/Release + 3.5/4.0), compile, run. We (mostly Kurt) are still working on a build step for the Clojure tests, coming soon. -David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is ClojureCLR converging toward a release?
Check out the downloads area on http://github.com/richhickey/clojure-clr. Grab clojure-clr-1.2.0.zip. Unzip, start up Clojure.Main.exe and you should be running. The zip also contains Clojure.Compile.exe, which you can invoke with command line arguments indicating files to compile. The support DLLs for the DLR are included. These are debug builds for .Net 3.5 only. Within the next day or so, the master branch will updated with a new build process that will create debug and release builds for 3.5 and 4.0. Future binary distributions will be available in all four flavors. The new build process and extension to .Net 4.0 requires the ClojureCLR project to move to Visual Studio 2010. It will simplify getting started for developers, too. It's ready to go. I just have to get the wiki pages updated. -David On Oct 4, 11:13 pm, Mike K mbk.li...@gmail.com wrote: David, Rich: any further updates on this? Mike On Sep 24, 8:24 am, dmiller dmiller2...@gmail.com wrote: Just waiting for that person's CA to be processed by Rich. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is ClojureCLR converging toward a release?
I tagged a 1.2 release on the site. I have not put a separate 1.2 download or a binary release out there yet. Someone has contributed an entirely new build process for ClojureCLR that includes support for either 3.5 or 4.0 builds, better binary managment on the builds and some other goodies. Just waiting for that person's CA to be processed by Rich. -David On Sep 23, 10:26 pm, Mike K mbk.li...@gmail.com wrote: It was mentioned about six weeks ago that ClojureCLR was mostly 1.2 compatible with a few outstanding issues and a couple dozen failing tests. What is the status now? Is there still an intention of an official binary release with 1.2 level functionality, or has that target been dropped? Thanks, Mike -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: For David Miller: ClojureCLR binary distribution?
I have two things left to do to bring ClojureCLR mostly up to 1.2RC3: implement gvec and one other commit on map/record equality. The latter is 20 minutes. The former, gvec, is mostly done, but I ran into a little compiler glitch I have to fix. At the moment, I run all relevant clojure-test tests. I have exactly 23 fails, alll in pprint, and almost all related to an extra space occurring before a newline in pprint. I haven't had time to track that down yet. I thought it better to just get caught up with all the changes going into 1.2 before dealing with packaging a set of DLLs, but I could do a quick zip tonight rather than waiting if that is preferred. -David On Aug 15, 4:24 pm, Mike K mbk.li...@gmail.com wrote: Hi David, I saw some comments recently about a potential binary distribution of ClojureCLR. Do you have any idea as to when you might be targeting this or what level of functionality it might contain? Thanks for all your hard work on this project! I'm very eager to try it out. Mike -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: More urgency for CinC CLR given Oracle's lawsuit against Google?
I'm in favor of any discussion that yields more support for Clojure on CLR. :) - David On Aug 13, 3:36 pm, Seth seth.schroe...@gmail.com wrote: Sorry all -- I think my original message went slightly awry. The announcement was a shock and quickly followed by waves of grumbling from devs I follow on Twitter. While it's easy to extrapolate the future from Oracle's past and this announcement, it's not necessarily useful or accurate to do so. I never suspected Clojure to be in any mid-term jeopardy. But it did seem like a good opportunity to stoke the CinC and CLR topics and see if there was a big change in the level of interest. Apparently not, and that's probably prudent. That said, I personally am now more interested in better CLR support for Clojure. While it's not a strength of mine, I'm sure I will find some way to contribute to that. Sorry again for any off topic churning, and here's hoping the JVM will continue to be a good place for Clojure to be for quite some time. Seth On Aug 13, 4:06 pm, Mike Meyer mwm-keyword-googlegroups. 620...@mired.org wrote: On Fri, 13 Aug 2010 23:08:40 +0400 Mikhail Kryshen mikh...@kryshen.net wrote: I doubt it is possible to create runtime like JVM or CLR without patent problems. Given that virtual machine technology like(1) the JVM and CLR have been around since the 70s - long before even C++ ++ -- was a gleam in Gosling's eye - I'm pretty sure it's possible to create a runtime like the JVM or CLR that has no insurmountable patent problems. Sure, Oracle can create problems for anyone implementing a VM by suing them, but if you started with something like either the UCSD P-Machine VM or a SmallTalk VM (Squeak, maybe?) - which Gosling cites as inspirations for the JVM (2) - such suits are clearly baseless, as the technology is obviously prior art. So it can't infringe the patent, only invalidate it. mike *) This all depends on exactly what you mean by like. Gosling and the Java group at Sun are sharp people, I'm sure they added ideas that were patentable, and probably even worth granting a patent to. If like includes having patented feature foo, then foo may be missing from the VMs that are prior art, so they aren't like JVM or CLR. But just having a portable VM also qualifies as like JVM in some sense. 1)http://queue.acm.org/detail.cfm?id=1017013 -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail -www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Slightly Off Topic: .NET books
We have a ten-week program for experienced developers moving to the .NET platform. Our recommended text is Troelson's Pro C# 2010 and the .NET 4 Platform, Fifth Edition. http://www.apress.com/book/view/1430225491 All 1752 pages of it. It has a lot of things you won't need for understanding ClojureCLR source, such as ASP.NET, WinForms, etc. --David On Aug 6, 10:33 am, Sean Devlin francoisdev...@gmail.com wrote: Are there any good .NET books you guys could recommend? I'm looking for a range of resources. I don't need C# in 21 days or C# for dummies, but something an experienced Java hacker could start out with, similar to Core Java. Also, a more advanced book so I could learn to follow the ClojureCLR source would be great too. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Running on .Net
the 7/23 date is, as they say, not operational. I've edited that out. I'll go as far as 'soon'. (The new PC I was going supposed to move to and install VS2010 on has to be replaced due to the possibility that the hard disk will fry.) You cannot use DLR 1.0. I need things that are not in that release. As stated on the wiki page: 'For the time being go http://dlr.codeplex.com/SourceControl/ changeset/changes/48032:here to get version 48032.' With a binary distribution, at least I can package an approved version of the DLR. -David On Aug 4, 1:59 pm, eyeris drewpvo...@gmail.com wrote: I tried to build the latest ClojureCLR using VS 2008. I used the DLR 1.0 release. I successfully replaced your DLR project references and built them: http://imgur.com/SgUmu.jpg Then I added a DLR reference to the Clojure project and built it, resulting in these two errors The extern alias MSC was not specified in a /reference option: http://imgur.com/LWjOs.jpg Your installing-clojureclr page says I know for sure that will work. I hope to bring everything up to VS2010 (and because of DLR, no more VS2008 for building) by 7/23/2010. but I didn't see anything in the commit history to suggest that you've done this. On Aug 4, 12:25 am, eyeris drewpvo...@gmail.com wrote: I would like a zip of DLLs that are as widely compatible as possible across CLR/DLR versions accompanied by a clear list of which versions are compatible. Regarding releases, I'm glad to lag behind the bleeding edge by a lot in order to have a stable platform. What I want to be able to do is grab the DLLs, add them as references to my VS project, and compile, much like I do with NetBeans and the JVM clojure. I have to admit that I haven't tried ClojureCLR since right around the 1.1 release, so I don't remember the details of the problems that I encountered. I am in the process of migrating a lot of stuff from VS 2008 to VS 2010. Once I finish that I will try ClojureCLR again and get back to you regarding embedding and AOT. On Aug 3, 3:11 pm, dmiller dmiller2...@gmail.com wrote: I can move creating a binary distribution to the to top of the list. I could use some guidance from the interested on what would serve the purpose on this and other things mentioned here. on the distribution: Do you want just a zip of of DLLs? An installer? Do you want installation to the GAC? on 'stable, dependable': Is there any strategy on creating new releases that makes sense? Assume anyone wanting to stay on the bleeding edge will build for themselves? start-up speed: I'm running some experiments on that. The problem is mostly the monolithic nature of the assemblies created and the amount of environment initialization. Suggestions welcomed. Ease of embeddability: please elaborate on the problems. AOT'ing clj files: Ditto. -David On Aug 3, 12:47 pm, Timothy Baldridge tbaldri...@gmail.com wrote: I really wish that ClojureCLR had a binary distribution. I like clojure a lot but I have a .Net background and a lot of .Net code to interact with. If ClojureCLR had a stable, dependable binary distribution I would be able to use it at work much more than I already do. I don't care much about 1.2 features like defrecord. What I care about is start-up speed, ease of embeddability, and Visual Studio integration (not Intellisense, just AOT'ing .clj files). +1 for all of that That paragraph basically explains why I haven't started using clojure at my work yet. Timothy Baldridge -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Running on .Net
I can move creating a binary distribution to the to top of the list. I could use some guidance from the interested on what would serve the purpose on this and other things mentioned here. on the distribution: Do you want just a zip of of DLLs? An installer? Do you want installation to the GAC? on 'stable, dependable': Is there any strategy on creating new releases that makes sense? Assume anyone wanting to stay on the bleeding edge will build for themselves? start-up speed: I'm running some experiments on that. The problem is mostly the monolithic nature of the assemblies created and the amount of environment initialization. Suggestions welcomed. Ease of embeddability: please elaborate on the problems. AOT'ing clj files: Ditto. -David On Aug 3, 12:47 pm, Timothy Baldridge tbaldri...@gmail.com wrote: I really wish that ClojureCLR had a binary distribution. I like clojure a lot but I have a .Net background and a lot of .Net code to interact with. If ClojureCLR had a stable, dependable binary distribution I would be able to use it at work much more than I already do. I don't care much about 1.2 features like defrecord. What I care about is start-up speed, ease of embeddability, and Visual Studio integration (not Intellisense, just AOT'ing .clj files). +1 for all of that That paragraph basically explains why I haven't started using clojure at my work yet. Timothy Baldridge -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
Yes, it's easy to imagine a world where people who want efficient code
have to jump through hoops to get it. OTOH, you can just say (num some-
expr) to force it to be boxed, if you want assurance of an Object
initializer. Which will be the more common need?
From the wiki page Enhanced Primitive Support: * Note: this means
that locals initialized with literals will have primitive type, e.g.
(let [x 42] …), and especially: (loop [x 42] …). If you intend to
recur with a non-primitive, init like this, (loop [x (num 42)] …)
I'd like to ask for some consideration on any use of (num x). On the
CLR side, it is unimplementable as documented, there being no
equivalent in the CLR to Number. If a proposed use of num can be
satisfied by this definition of num:
(defn num {tag :object} [x] x)
I can manage. I imagine this to be the case, but haven't had time to
read all the new code.
If you really mean to use a type that is a base type for all the
primitive numeric types -- not going to happen on the CLR.
-David
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR start-up time
I haven't compiled under a release in a while. Recent changes to the build system may have messed it up. I'll check it out. David On Apr 23, 2:11 am, Joerthan Panest joerthan.pan...@gmail.com wrote: Hello, I am considering ClojureCLR for embedding in an application, but it appears as though it takes ~4secs to start up. Is this typical? Is there a way to speed up? I realize that this could be hidden by opening it in a background process and leaving it open but I can see where that is less than ideal in some situations. I also noticed that the current development environment has many references to Debug bin settings and a short attempt to get it in Release mode failed with a number of errors. Is this due to the nature of the required run-time information or simply because it is still a Beta? Thank you, Joerthan -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR status?
Two factors: (1) I'm working on deftype/protocols/reify and related things. This requires some non-trivial re-engineering of the compiler (based on non- trivial reverse-engineering of all the changes made to Clojure JVM). (2) I'm up to my nostrils on a little pro bono web site development I foolishly agreed to do. Say the phrases crunch time and flop sweat over and over again, and you'll have an idea where I am on that. It's definitely slowed me down. I'm trying to keep a small flow of work going on ClojureCLR during this time. Unfortunately, since I'm working on such big chunks, it looks like nothing is happening. Reify is about 90% done, and I've already made a few changes in support of deftype. If I get a little ahead on the other project, I should be able to get reify done in the next week. After that, deftype and protocols. Right after I commit the reify changes, I may take a day to run through all the small commits on the 1.2 branch. That usually doesn't take long. Should I make heartbeat commits once a week so people will know there's still life in the body? :) David On Feb 25, 10:26 pm, Mike K mbk.li...@gmail.com wrote: I notice there have been no checkins to ClojureCLR in the last month and a half. Is something big in the works? Is absolutely nothing in the works? :-) If I check out and build the latest sources, how will it compare in terms of functionality to the Clojure main branch? In particular, does it have cutting edge things like protocols, reify, etc? Thanks, Mike -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-clr how to wire up a delegate
Parallel to proxy, clojure-clr adds a gen-delegate. Example code is in http://github.com/richhickey/clojure-clr/blob/master/Clojure/Clojure.Source/clojure/samples/celsius.clj Specifically, for adding an EventHandler: (.add_Click button (gen-delegate EventHandler [sender args] (let [c (Double/Parse (.Text tb)) ] (.set_Text f-label (str (+ 32 (* 1.8 c)) Fahrenheit) -David On Feb 24, 1:43 am, adam11235 adam.k.web...@gmail.com wrote: Hi, I've made progress in creating a simple app to show a windows form, however I am having trouble wiring up a delegate (to handle button clicks). The Java version uses Proxy to implement ActionListener, instead I am just trying to create an EventHandler passing as the 2nd constructor argument the code I would like executed. (see the .add_Click line) The delegate code gets invoked immediately instead of when the button click occurs, and then complains it expected a function pointer rather than the DialogResult it received (due to execution of the code) I tried quoting that code but no success. How do you wire up delegates? (import '(System.Windows.Forms MessageBox Form Button)) (defn windowsPlay [] (let [ win (Form.) temp-button (Button.) ] (.. win (get_Controls) (Add temp-button)) (doto temp-button (.set_Top 50) (.set_Text Clicky) (.add_Click (EventHandler. temp-button (MessageBox/Show I got clicked (doto win (.set_Text hello) (.ShowDialog (windowsPlay) Thanks, Adam. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-clr questions
There is no other place. On Feb 23, 1:16 am, adam11235 adam.k.web...@gmail.com wrote: Hi, Is this group an appropriate place to post clojure-clr questions? Is there a more relevant place to ask clojure-clr questions? Thanks, Adam -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure clr build issue
Which edition of VS? Professional? Express? The ToolsVersion=4.0 versus 3.5 should not be a problem. The 'reference component not found' also not a problem. These relate to the ability to target either 2.0 or 4.0. I get these warnings also. On Dec 24, 9:10 pm, Sriram P C sriram...@gmail.com wrote: Help-About says Microsoft Visual Studio 2008 Version 9.0.30729.1 SP OS is Windows 7 Home Premium 6.1 There is a warning 'Project file contains ToolsVersion=4.0, which is not supported by this version of MSBuild. Treating the project as if it had ToolsVersion=3.5'.. I don't know if it has anything to do with it. There are also some 'reference component not found' warnings in the DLR project. Would that be a problem ? thanks, sriram. On Fri, Dec 25, 2009 at 5:32 AM, dmiller dmiller2...@gmail.com wrote: Wow, Google only gets nine hits on MSB3075. One, possibly relevant, solved by moving to admin privilege. One, yours. Others, not relevant. Thus ends my error-resolution attempt! From the message, I'm assuming .net 3.5. What flavor of VS? -David On Dec 23, 9:21 pm, sriram p c sriram...@gmail.com wrote: I was trying to build clojure clr. As given in the instructions, I have unloaded the Tests project. During compilation of the Coljure.Compile project, I see the following error on the Output window C:\sriram\work\clojure\clojure-clr\Clojure\Clojure.Compile\bin\Debug \Clojure.Compile.exe clojure.core clojure.set clojure.zip clojure.main clojure.walk clojure.stacktrace clojure.template clojure.test clojure.test.tap clojure.test.junit Access is denied. C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets (3397,13): error MSB3075: The command C:\sriram\work\clojure\clojure- clr\Clojure\Clojure.Compile\bin\Debug\Clojure.Compile.exe clojure.core clojure.set clojure.zip clojure.main clojure.walk clojure.stacktrace clojure.template clojure.test clojure.test.tap clojure.test.junit exited with code 5. Please verify that you have sufficient rights to run this command. Done building project Clojure.Compile.csproj -- FAILED. == Build: 6 succeeded or up-to-date, 1 failed, 0 skipped == I tried to run with admin privileges. I still get the same error. Can anyone tell me how to resolve the issue ? thanks, sriram. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure clr build issue
Wow, Google only gets nine hits on MSB3075. One, possibly relevant, solved by moving to admin privilege. One, yours. Others, not relevant. Thus ends my error-resolution attempt! From the message, I'm assuming .net 3.5. What flavor of VS? -David On Dec 23, 9:21 pm, sriram p c sriram...@gmail.com wrote: I was trying to build clojure clr. As given in the instructions, I have unloaded the Tests project. During compilation of the Coljure.Compile project, I see the following error on the Output window C:\sriram\work\clojure\clojure-clr\Clojure\Clojure.Compile\bin\Debug \Clojure.Compile.exe clojure.core clojure.set clojure.zip clojure.main clojure.walk clojure.stacktrace clojure.template clojure.test clojure.test.tap clojure.test.junit Access is denied. C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets (3397,13): error MSB3075: The command C:\sriram\work\clojure\clojure- clr\Clojure\Clojure.Compile\bin\Debug\Clojure.Compile.exe clojure.core clojure.set clojure.zip clojure.main clojure.walk clojure.stacktrace clojure.template clojure.test clojure.test.tap clojure.test.junit exited with code 5. Please verify that you have sufficient rights to run this command. Done building project Clojure.Compile.csproj -- FAILED. == Build: 6 succeeded or up-to-date, 1 failed, 0 skipped == I tried to run with admin privileges. I still get the same error. Can anyone tell me how to resolve the issue ? thanks, sriram. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR questions
Mike K, 1. IronPython needs to be syntactically compatible with Python, so there were struggles over an attribute syntax that would be valid Python syntax 2. Python class (type) semantics are more flexible than .net type semantics, so classes in IronPython are not real .net types. I would suspect that point 1 would not be much of an issue for ClojureCLR. I have no idea about point 2 but would like to hear your take. Regarding (1), we have a lot more flexibility in how to hack syntax, but where it goes and how it looks are still going to require some thought. A careful analysis of where Clojure defines new JVM/CLR classes, such as proxy, is required. It is probably best to defer this until deftype/reify and other goodies in the 'new' branch settle down. Regarding (2). Clojure-defined types, as in proxy/deftype/etc. exist directly as JVM/CLR types, unlike IronPython, so this should not be a problem for us. Thanks for the links to the IronPython/attributes material. 2. Performance goals: Clojure:Java::ClojureCLR:C#. Not there yet, but no reason why this is not achievable. If you look at the IL generated,ClojureCLRis almost identical to ClojureJVM. This comes as a pleasant surprise to me. I know very little about Clojure, but based on my naive understanding that it's a dynamic language implemented on top of the DLR, I would have thought that C#- like performance would be a bridge too far. Isn't there a significant cost to be paid for the late binding and runtime checks (notwithstanding partial amelioration of the issues via the DLR's support for caching the results of method binding, etc.)? Nobody really talks about C#-like performance goals for IronPython or IronRuby. Is Clojure in any sense less dynamic than those languages? My proportionality equattion (Clojure:Java::ClojureCLR:C#) was an attempt to say that I hope to make ClojureCLR performance relative to the more static languages on the CLR close to the performance of Clojure relative to Java. Note that I'm making no statement about the actual perf of Clojure relative to Java. Look around this group's archives and you will find plenty of discussion of that topic. ClojureCLR will pay pretty much the same price as ClojureJVM for late binding and runtime checks. The implementations are pretty much identical. I am about to put in code to take advantange of the DLR's call sites and the caching that comes with that for host expressions (CLR interop).I may get some avoidance of reflection that ClojureJVM *currently* does not enjoy. The most significant difference I know of in the implementations is an extra indirection through a static field that takes place during Clojure function invocation. It could well be that that can be inlined by the CLR optimizer, but I haven't had time to check it. (This difference is caused by a limitation of the DLR--it can only generate static methods into AOT-compiled code.) My equations was also designed to sidestep any issues of JVM versus CLR performance. Also, while I have your attention, another question: I think the CLR provides support for optimized tail calls. Does / will ClojureCLR take advantage of this capability? Not in a direct way. When you write Clojure code, you will still want to use recur properly. That sidesteps the issue. (There may be some effect on some very internal implementation details, but nothing that would effect the Clojure application programmer.) -David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR questions
On Dec 4, 1:35 am, mac markus.gustavs...@gmail.com wrote: Apologies if this has been answered, did a quick search but found only pieces of info. Is it possible to run ClojureCLR on Mono yet? There was an issue with the BigDecimal dependency from J#? /Markus I don't know if anyone has tried running on Mono yet. ClojureCLR now has its own implementation of BigDecimal. There is no reliance on vjslib. I hope someone will give it a try and report back. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
