Clojurians Log v2

(Environment/Exit zero-or-one) -- thanks BingAI 🙂

When porting Portal to the CLR, I also had to do a bunch of searching to find jvm equivalents 😆 https://github.com/djblue/portal/blob/master/src/portal/runtime/fs.cljc might be a useful reference for other things you might run into 👌

https://github.com/dmiller/test-runner

I had not yet publicized it. Not sure what its permanent home should be. It's not one of the 'official' clojure libraries, so a home in http://github.com/clojure/ with the official ports of official libraries seems not appropriate.

Whoops, forgot to push my changes up. Eventually need to update the deps.edn to use git coords instead of :mvn.

I will take a look at your repo but if the changes are small, I wonder if the core team will take a PR to reduce forking?

I would make both files .cljc and use reader conditionals, but those are pretty small differences to get things working. Plus changing :mvn/version deps to git deps. I'll talk to Alex and see how open they are to taking changes on that...

@dmiller The cljr.tools.namespace dep would need to be different between the versions, right? It would need an override since there's no possible git dep for clojure.tools.namespace it could use...

I'll mention to Alex about the transitive alias issue in this context... like I say, if the CLR version of tools.deps had a bit of magic in it to apply a :clr alias (or something similar) transitively, that would solve a lot of the overriding.

I ran into this issue with clojure/data.json. The jvm and clr libs are different but I can't currently express that in my deps.edn.

The ideal situation would be for Contrib libs to be portable across Clojure/Script/CLR to some degree -- but the deps.edn issue has to be solved first for that.

Obvs not all of them can be portable, but I suspect a lot of the "pure" ones could be.

Except it's not really a core team thing. Sits under cognitect-labs rahter than clojure. At any rate, I did mention it in an email that direction on Saturday. It definitely should be converted to .cljc and conditionalized. That's what I've been doing lately. Don't know why I didn't do that here. I'll fix that and update later today. Yes, the dep for tools.namespace would have to be different. Unless, of course, they would also accept a conditionalized version of tools.namespace and tools. reader. When I did the original ports, conditionalization didn't exist. It wouldn't be hard to bring it into a shared library. But, again, I'm not sure there is interest in that.

Yeah, it would be a good discussion to have with Alex and the core team.

[Sorry, getting out of sync with all this dialog]

I noticed in tools.cli for instance that :cljr has Exception where :clj has Throwable -- but it would probably be better for :clj to use Exception -- and there has been talk in the ClojureScript world of adding Exception as an alias for :default which they currently use. Stuff like that would make portable code easier to write in general.

(this would allow for the :default reader case to be used where :clj and :cljr are actually in alignment)

There are so many simple things that drive me crazy while porting. I've done them so many times. The banes of my porting work: I/O, threading, networking. The models across the VMs are too dissimilar to come up with a common mechanism, I'm afraid. But even coding to isolate certain operations as functions that could be defined conditionally would reduce the burden. In this latest burst of porting activity, I've done that in a few places when I just couldn't take it anymore.

I noticed in tools.namespace there was io/dir-info vs io/file in a couple of places -- I assume that's due to a different model underpinning the two VM environments?

The I/O model difference raises its head even in the interfaces libraries, and . The models are just too different. io/file is one example. The CLR has System.IO.FileInfo and System.IO.DirectoryInfo (both based on the abstract class System.IO.FileSystemInfo ). To give one example that drove me up the wall recently: java.io.File allows relative files, and that fact is used in tools.deps. The classes are always absolute paths. I'm actually not sure yet I got the changes right in tools.deps -- still testing.

I messed up some of the original READMEs. Those are commands for the Package Management console in Visual Studio. Which is where I spend most of my time. (https://learn.microsoft.com/en-us/nuget/consume-packages/install-use-packages-powershell) How you get the Install-Package cmdlet for standalone use in Powershell -- I'm not sure. I need to come up with a more general recipe. Any thoughts on that welcomed. Once I get the deps.edn tooling up, (I think) my recommendation will be to use :git coords for clojure projects, and pull in the nuget package if you are doing C#/F# work.

I have Install-Package running (did require nuget installation), but it can't find anything.

OK, so dotnet add package clojure.tools.nrepl -v 0.1.0-alpha1 would be a close equivalent?

There's the rub. The dotnet package commands are mostly to modify projects. That command will add or update a package reference in a project file. You then would let the build tools pick up that reference and pull down the package for you. https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-add-package

And I need a "project file" of some sort -- I can't just run that in any old folder. But Install-Package could be?

PS C:\Users\seanc\clojure> Install-Package clojure.tools.nrepl
Install-Package: No match was found for the specified search criteria and package name 'clojure.tools.nrepl'. Try Get-PackageSource to see all available registered package sources.
PS C:\Users\seanc\clojure> Get-PackageSource

Name                             ProviderName     IsTrusted  Location
----                             ------------     ---------  --------
                        NuGet            False      …
PSGallery                        PowerShellGet    False      .…

For working with nuget directly in powershell, look here: https://learn.microsoft.com/en-us/powershell/module/packagemanagement/?view=powershellget-2.x It helps to read the docs. For example, --Version is for the VS command console, one needs -RequiredVersion in PS. But I still can't get it to find clojure.tools.nrepl

PS C:\Users\dmill> Find-Package -Name clojure.tools.nrepl -AllowPrereleaseVersions -AllVersions
Find-Package : No match was found for the specified search criteria and package name 'clojure.tools.nrepl'. Try Get-PackageSource to see all available registered 
package sources.
At line:1 char:1
+ Find-Package -Name clojure.tools.nrepl -AllowPrereleaseVersions -AllV ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Microsoft.Power...ets.FindPackage:FindPackage) [Find-Package], Exception
    + FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.FindPackage
 

I read a lot of MS docs around this but there seemed to be so many caveats around versions of tools that I couldn't tell what was what. Thanks for the -RequiredVersion pointer tho'

And -AllowPrereleaseVersions But I'm still not finding it.

Or anything. I just looked for one of Microsoft's packages -- not found.

OK, that makes me feel better about my Powershell ineptitude 🙂

clojure.tools.namespace seems to work tho':

PS C:\Users\seanc\clojure> Install-Package clojure.tools.nrepl -RequiredVersion 0.1.0-alpha1
Install-Package: No match was found for the specified search criteria and package name 'clojure.tools.nrepl'. Try Get-PackageSource to see all available registered package sources.
PS C:\Users\seanc\clojure> Install-Package clojure.tools.namespace

The package(s) come(s) from a package source that is not marked as trusted.
Are you sure you want to install software from ''?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "N"):      

Not working for me. Can you do Get-PackageSource and tell me what you see? (that's the only thing it recommends checking.)

No longer at a computer. I can check tomorrow.

Turns out my Terminal install was defaulting to an old version of Powershell (5). Seems to find it okay under v7.

Ah, that's the problem I ran into - and tried to solve by installing PS 7.x:grin:

Install-Package clojure.tools.nrepl -RequiredVersion 0.1.0-alpha1 -AllowPrereleaseVersions worked for me but only when I started Powershell as administrator. If not admin, it fails.

On both PS 5.1 and 7.3.4:

PS C:\Users\seanc> Get-PackageSource

Name                             ProviderName     IsTrusted  Location
----                             ------------     ---------  --------
                        NuGet            False      ...
PSGallery                        PowerShellGet    False      ...

Yay! Basic HoneySQL works with the CLR:

PS Microsoft.PowerShell.Core\FileSystem::\\wsl.localhost\Ubuntu-20.04\home\sean\oss\honeysql> $Env:CLOJURE_LOAD_PATH='src'; Clojure.Main
Clojure 1.12.0-alpha7
user=> (require 'honey.sql)
nil
user=> (honey.sql/format {:select :* :from :table :where [:= :id 1]})
["SELECT * FROM table WHERE id = ?" 1]
user=>

Very nice! On the topic of portability, what's the catch (no pun) of using Exception instead of Throwable in JVM? I guess it won't catch Error, right? Is that something one would usually do/avoid doing?

Yeah, catching Error is a bit of a code smell, because of what it represents, and so catching Throwable is also a code smell.