Clojurians Log v2

There is a difference between windows/linux in how :jvm-opts args in aliases are picked up:

PS C:\Users\Vlaaad\Projects\repro> Get-Content .\deps.edn
{:aliases {:opt {:jvm-opts ["-Drepro.opt=YES"]
                 :exec-fn checkopt/exec}}}
PS C:\Users\Vlaaad\Projects\repro> Get-Content .\src\checkopt.clj
(ns checkopt)

(defn exec [_]
  (prn (System/getProperty "repro.opt")))
PS C:\Users\Vlaaad\Projects\repro> clj -X:opt
nil
PS C:\Users\Vlaaad\Projects\repro> wsl
vlaaad@asus-notebook:/mnt/c/Users/Vlaaad/Projects/repro$ clj -X:opt
"YES"
vlaaad@asus-notebook:/mnt/c/Users/Vlaaad/Projects/repro$

Using version "1.10.3.849" both on windows and linux

@vlaaad for completeness, could you also try with bb clojure -X:opt ?

(with a newer version of bb)

I don't use bb, sorry @borkdude

this could be interesting to find out if it's a powershell issue or something else

since bb uses the exact same code, not platform specific

an alternative is https://github.com/borkdude/deps.clj/releases/download/v0.0.15/deps.clj-0.0.15-windows-amd64.zip run as deps -X:opt

(this is the same code as used in bb, but a standalone executable dedicated to only this)

just a suggestion for debugging

can you also retry the repro with -Sforce in both cases to make sure there are no cache effects

or rm .cpcache/

@alexmiller same result:

PS C:\Users\Vlaaad\Projects\repro> clj -Sforce -X:opt
nil
PS C:\Users\Vlaaad\Projects\repro> wsl
vlaaad@asus-notebook:/mnt/c/Users/Vlaaad/Projects/repro$ clj -Sforce -X:opt
"YES"

@vlaaad what Java versions are you using in both envs?

I know there is an issue with Oracle 15+ that is dropping quotes on Windows, which is why I am asking.

@borkdude

temp $ bb clojure -X:opt
"YES"

temp $ clj -X:opt
nil

temp $ java -version
openjdk version "16" 2021-03-16
OpenJDK Runtime Environment AdoptOpenJDK (build 16+36)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 16+36, mixed mode, sharing)

is this windows or wsl

Windows + Powershell

ok

@borkdude 14.0.1 on windows and 11.0.11 on linux

and what do you get for clj ?

which vendors? please more info :)

on the linux one, if you add -Sverbose you'll see a line like "cp_file = .cpcache/4068492893.cp". for whatever that hash value is can you cat .cpcache/HASH.jvm

temp $ clj -X:opt
nil

meanwhile @ales.najmann tried out both bb clojure and clj in powershell and the clj one failed: https://clojurians.slack.com/archives/CFN4QDHPS/p1621977973015200?thread_ts=1621977185.012000&cid=CFN4QDHPS

@alexmiller Perhaps you forgot to apply the powershell workaround that you did for -M and -A, for -X ? https://github.com/clojure/brew-install/blob/bd10d7aba00074f0b725b6fc81be32e01d798795/src/main/resources/clojure/install/ClojureTools.psm1#L85

I can't actually repro this on mac

which is same bash as linux

The mac powershell parses differently than the windows one. The windows one splits -X:foo into two args -X: and foo (or perhaps the colon on the other side)

the parsing is intentionally different in windows due to the : stuff

that parsing is only different in windows + powershell.

not in cmd.exe

not sure I'm following

the mac powershell parses it "correctly" but the windows powershell (specifically: windows AND powershell, that specific combination) parse -F:foo into two parts

to be clear, you are off on a side quest here from the original question about linux -X not picking up :jvm-opts, right?

it works ok on Linux (or WSL), the same does not on Windows

well now I'm totally confused

it does work ok with tools.deps.alpha on Windows, just not with the powershell front-end

(as @ales.najmann showed in this thread: https://clojurians.slack.com/archives/CFN4QDHPS/p1621977185012000)

I'll back off now ;)

rereading, I had the problem completely backwards, sorry

I thought it was linux not working and windows working

damn Windows once again 🙂

so, I would actually like to know the answer to the .jvm file question I asked above

(and the vendor of both the JVMs, which could also be a difference, as shown in the adventures of @pez)

if you clj -Sverbose -X:opt then grab the hash and look at .cpcache/HASH.jvm

what I am trying to see is whether the make-classpath program is properly understanding the alias and writing the cache file OR whether the problem is in reading the file and applying the jvm properties in the pwsh

@alexmiller

temp $ clj -Sverbose -X:opt
version      = 1.10.3.849
install_dir  = C:\Users\alesn\scoop\modules\ClojureTools
config_dir   = C:\Users\alesn\.clojure
config_paths = C:\Users\alesn\scoop\modules\ClojureTools\deps.edn C:\Users\alesn\.clojure\deps.edn deps.edn
cache_dir    = .cpcache
cp_file      = .cpcache\9A0695B47F76E40743FC037AEAF297A7.cp
nil

temp $ Get-Content .\.cpcache\9A0695B47F76E40743FC037AEAF297A7.jvm   
-Drepro.opt=YES

actually I'm pretty sure it's the latter - this is just missing on the exec branch

https://github.com/clojure/brew-install/commit/ed173efacdf71b81b85e6989a7281bd6a60bcb30

give me a minute, and I'll have a build for you

ok, grab the windows build version 1.10.3.855 and give it a try

Ok. I'm wrestling now with scoop... but it's already downloading the right thing

temp $ clj -Sverbose -X:opt
version      = 1.10.3.855
install_dir  = C:\Users\alesn\scoop\modules\ClojureTools
config_dir   = C:\Users\alesn\.clojure
config_paths = C:\Users\alesn\scoop\modules\ClojureTools\deps.edn C:\Users\alesn\.clojure\deps.edn deps.edn
cache_dir    = .cpcache
cp_file      = .cpcache\9A0695B47F76E40743FC037AEAF297A7.cp
"YES"
temp $ bb clojure -X:opt
"YES"

YES YES YES

😄

such positive affirmations in this test

I'm glad another clj on windows issue got solved today. YES!

autoupdate script parses release page, so after the update of this page https://clojure.org/releases/tools fix can make it to users

I wonder if I can use brew-install release page to check for releases

@ales.najmann maybe checking the tags here works better? https://github.com/clojure/brew-install/releases github has an API for this

yes, I believe scoop github actions actually use this internally.

https://api.github.com/repos/clojure/brew-install/tags

the tags there are ALL releases, both prerelease and stable

you can flag prereleases as such in github

I'm using git programatically, not github

I see

I'll probably stick to release page then

@borkdude the PR would look like this: https://github.com/littleli/scoop-clojure/pull/161/files

and really the homebrew repo makes no distinction - there is a tag for every @version release of the formula

"stable" is a subset of those where we bump the default clojure.rb formula

you can also use github programmatically, I've scripted (almost) all my binary uploads to github releases now: releases are created automatically, or only added to if they already exists, etc

so should I realy point to repo with clojure.rb formula?

oh sorry, you're looking at brew-install, same difference I guess

I don't want to flag releases differently on brew-install though - I don't know at the time of tagging whether it will be a stable release or not

promotion to stable is a separate process as far as I'm concerned

no worries. I'll stick to release page (as a changelog) it was working fine for months.

and it's safe

I think the best things to look at are either the stable.properties file in brew-install (somewhat annoying due to the changing branch name, which I may end up changing as its a pain elsewhere) or to watch the clojure.rb formula in the homebrew-tools repo

also, I've updated the release page

it will be autoupdated in ~45-60 minutes

Thank you for the debugging session 🙂 it was nice

@borkdude

scoop-clojure master = $ checkver

cmdlet checkver.ps1 at command pipeline position 1
Supply values for the following parameters:
Dir: bucket
clojure: 1.10.3.855 (scoop version is 1.10.3.849) autoupdate available
clojure-lsp: 2021.05.22-16.50.45
deps.clj: 0.0.15
datalevin: 0.4.34
jet: 0.0.15
bb-web: 0.2.4
puget: 0.0.3
carve: 0.0.2
lmgrep: 2021.05.23
pgmig: 0.7.0
bootleg: 0.1.9
babashka: 0.4.3
pathom-viz: 2021.5.13
clj-kondo: 2021.04.23
joker: 0.17.1

but I need to let Excavator (github-action) to process it on scheduled time (~0 minute every hour)