Feedback requested: .Net frameworks to support

[dmiller2718]

I have version 1.10 almost ready to go.  Matches up to all features in ClojureJVM 1.10, plus a few ClojureCLR-specific fixes.

There have been a number of requests for ClojureCLR to move to more recent versions of Framework and to .Net Core.

I have compiled against 3.5 and 4.0 for years now.

I have kept 3.5 mostly to support the folks using it for Unity -- I think this is no longer necessary, and I'd love not to have to maintain the separate code required for that.

Up to this point I have not looked at Core -- in the early days, System.Reflection.Emit and the DLR were not supported, so the point was moot.

However, most of System.Reflection.Emit is available, and the DLR now supports (only) 4.5, core 2.0 and core 2.1.

So, the question is:  what frameworks do I need to support going forward?

More specific questions:

Does anyone still need a 3.5 build?

Will matching the DLR (4.5, core2.0, core 2.1) satisfy?

(On the master branch, the soon-to-be version 1.10 is building under 4.5.  I am playing with compiling under Core -- there are some differences in capabilities in System.Reflection.Emit and the DLR, but they seem limited. I have some hope this will not be too painful.)

-David

[Mark Hepburn]

Just my 2c worth -- moving forward I'm only interested in core (and realistically, netstandard2.1, although I'm not sure that's relevant since Emit isn't in the standard surface)

Nice podcast, by the way :)

[Devin Sackett]

I agree. .NET core should be the targeted framework going forward. As for the version of .net core, that to me doesn't matter.

--
You received this message because you are subscribed to the Google Groups "clojure-clr" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-clr...@googlegroups.com.
To post to this group, send email to cloju...@googlegroups.com.
Visit this group at https://groups.google.com/group/clojure-clr.
For more options, visit https://groups.google.com/d/optout.

[cees van Kemenade]

Hi David,

For us .Net framework 4.5 would be a great step forward as .Net framework 4.0 is already quite old and might miss some security fixes.

The move to .Net Core is certainly appreciated as it grows the diversity of platforms we can run on, but is not critical to us.

Cees.

On Monday, April 22, 2019 at 2:52:15 AM UTC+2, Devin Sackett wrote:

I agree. .NET core should be the targeted framework going forward. As for the version of .net core, that to me doesn't matter.

On Sun, Apr 21, 2019, 2:03 PM Mark Hepburn <mark....@gmail.com> wrote:

Just my 2c worth -- moving forward I'm only interested in core (and realistically, netstandard2.1, although I'm not sure that's relevant since Emit isn't in the standard surface)

Nice podcast, by the way :)

On Sunday, 21 April 2019 06:20:15 UTC+10, dmiller2718 wrote:

I have version 1.10 almost ready to go.  Matches up to all features in ClojureJVM 1.10, plus a few ClojureCLR-specific fixes.

There have been a number of requests for ClojureCLR to move to more recent versions of Framework and to .Net Core.

I have compiled against 3.5 and 4.0 for years now.

I have kept 3.5 mostly to support the folks using it for Unity -- I think this is no longer necessary, and I'd love not to have to maintain the separate code required for that.

Up to this point I have not looked at Core -- in the early days, System.Reflection.Emit and the DLR were not supported, so the point was moot.

However, most of System.Reflection.Emit is available, and the DLR now supports (only) 4.5, core 2.0 and core 2.1.

So, the question is:  what frameworks do I need to support going forward?

More specific questions:

Does anyone still need a 3.5 build?

Will matching the DLR (4.5, core2.0, core 2.1) satisfy?

(On the master branch, the soon-to-be version 1.10 is building under 4.5.  I am playing with compiling under Core -- there are some differences in capabilities in System.Reflection.Emit and the DLR, but they seem limited. I have some hope this will not be too painful.)

-David

--
You received this message because you are subscribed to the Google Groups "clojure-clr" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cloju...@googlegroups.com.

[dmiller2718]

The DLR does support netstandard2.1, via pulling in a System.Reflection.Emit package that runs under it.

So if I can get ClojureCLR on Core, it looks like I get .netstandard with that dependency.

Based on what I've been reading lately,  System.Reflection.Emit is supposed to be supported in .netstandard 2.2 and .Net Core 3.0 will support .netstandard2.2.

(However, there is no plan for .NetFramework to support .netstandard 2.2 in the foreseeable future, so two versions will have to be there.)

re podcast: thanks.  

[dmiller2718]

An insurmountable difficulty is that netcore2.x does not support saving dynamic assemblies to disk.

Perusing https://github.com/dotnet/corefx/issues/4491 , it does not seem likely this will be addressed anytime soon.

What are the implications? No AOT-compilation, hence significantly longer startup times.

Reason: When ClojureCLR starts up, it has to read and evaluate core.clj and a dozen or so other files.  That is quite time-consuming.

In the current ClojureCLR, we compile all those files into assemblies.  When ClojureCLR starts, it detects clojure.core.clj.dll and loads that instead of clojure/core.clj, significantly speeding up initialization.

Also, netcore does not support debugging information (the ClojureCLR does a passable job of including debugging info during compilation), so good luck with that.

That doesn't mean it is impossible to get ClojureCLR to run on netcore (I think).  Just that startup times are going to be longer (haven't measured this yet), debugging info will be absent, AOT-compilation will be absent (including uses of genclass).

If anyone has information to the contrary, or suggestion on other workarounds, please speak up.

-David