Clojurians Log v2

Hi David! Thanks for your answers. And thanks for already incorporating the lookup directory fix! Regarding the FileNotFoundException that you can't reproduce: do you want more information on that? Or just leave it be? And I just want to check that I understood your reply correctly: the current master has some rough edges, but should in principle work? I.e. my best bet is proceeding w/ that rather than creating a branch from the 1.12.2 release and cherry picking the relevant fixes there?

The current alpha should be okay. The only rough edges are fine-tuning the things like making sure we are pulling Clojure.Source.dll from the correct directory. I'll take another look at the FileNotFoundException. I think it occurs -- that file does not exist on my setup -- but I don't get a report about it. Are you seeing the report in the output window (Visual Studio or whatever), in the console?

I was not looking at the console, but I had checked stopping the debugger when that (and several other kinds of) exception is thrown. If you want, I can try again tomorrow (getting a bit late now) and see what comes out in the console.

When you get a chance, yes, please.

Sorry for the delay. Had my AutoCAD installation corrupted, it would not work nor uninstall, so had to reinstall Windows and all sorts of hassle.

Anyhow, here's what appears in the Visual Studio output windows. It's not much: Exception thrown: 'http://System.IO.FileNotFoundException' in System.Private.CoreLib.dll Could not load file or assembly 'C:\Users\antti\work\nsd\Plugin\Nerom\bin\Debug\net8.0-windows10.0.19041.0\Clojure.resources.dll'. The system cannot find the file specified.

When debugging this, make sure to have activated stopping on FileNotFoundException in Visual Studio Exception settings. As the exception is handled you'll likely not get any notification about it otherwise.

I'm just not seeing it. I did track down the likely place it happens -- internal clr runtime code loading resources . Indeed, Clojure.resources.dll does not exist. I have upgraded to the latest CLR version doing .NET 10 preview work and I can't even find the place where the resource loading is happening anymore. When I tried previously, it was clear that the first reference to resource info jumped into code that tried to load that file. I cannot find a way to get to that spot anymore.

I'll double check the exceptions you are reporting. The baseDir fix you suggest I'll incorporate. I don't have a good estimate on 1.12.3 going to release. The only unstable parts are exactly what you are looking at -- the new (improved?) type spec parsing code and the library resolution code. Obviously, there are still a few rough edges.

Regarding the System.IO.FileNotFoundException error you traced to line 401 in RT.cs: I don't get an error reported from there when I run it. There are some exceptions being thrown and caught from that line. It is trying to load a resource at that point. That ties into the .NET System.PrivateCoreLib mechanism, which tries to load a number of things. Not all are present, including in particular "Clojure.resources.dll". But those are being caught. You know you are in deep when you step into things and end up finding names like System.Private.CoreLib.dll!System.Resources.ManifestBasedResourceGroveler.GetSatelliteAssembly(System.Globalization.CultureInfo lookForCulture) sitting in your call stack. I think ManifestBasedResourceGroveler is going on my list of all-time favorite class names. I am curious as to why you get an error report and I do not.

The "bad type def, can't handle" is an exception that is handled. As source code is being parsed, some things are checked for being type names that can't be parsed properly. When I wrote the version 1 type parser/resolver, I modified the inspirational source (from Mono) to not use exceptions. When I wrote the version 2 type parser/resolver recently, things had gotten more complicated, and rather than convert it and give more surface area for errors, I just replicated the exception-throwing control flow. I still have on my list to convert this code deal with error results differently. At any rate, the thrown exception you observed is not a problem. BTW, I have already incorporated the change to the loodup directory for the Clojure.Source.dll. You can pull that from the master branch if you like.

At the load of the Clojure RT class there were several exceptions, but apparently these were handled as everything seemed to work afterwards. E.g. 'System.IO.FileNotFoundException: 'Could not load file or assembly '<path to project>\bin\Debug\net8.0-windows10.0.17763.0\Clojure.resources.dll'. The system cannot find the file specified.' This comes from clojure.lang.RT static constructor, relevant stack frames being: Clojure.dll!clojure.lang.Properties.Resources.version.get() Line 68 C# Clojure.dll!clojure.lang.RT.RT() Line 401 C# E.g. load("clojure/core") in RT.cs line 466 throws System.ArgumentException: 'Bad type def, can't handle 'o' at 1 (Parameter 'typeName')' deep inside (Clojure.dll!clojure.lang.TypeName2.ClrTypeSpec.Parse(string name, ref int p, bool is_recurse, bool allow_aqn, bool junk) Line 769) I assume these exceptions are harmless?

Another question I have is that are there as of yet any guesstimates on when Clojure CLR 1.12.3 might be published? Is the Clojure CLR master in good enough a shape to use in my plugin? Or should I apply the above fixes on top of the commit with tag clojure-1.12.2?

Well, since the exception is handled and it is not causing any symptoms I guess it is harmless. Just strange that you are not seeing and I am. I am on .NET 8, so maybe that makes the difference.