Clojurians Log v2

I am using belman, so the dep setup is:

{:aliases
   :rebel
     {:extra-deps {com.bhauman/rebel-readline {:mvn/version "0.1.4"}}
      :main-opts  ["-m" "rebel-readline.main"]}
} ;

I want in every ns, I can access doc, and dir (which are from the namespace repl)

there isn't really any way to do this without making a customized repl

(which is not really that hard, but might be more than you want to do)

Maybe evaluating things from within user is an alternative approach?

(I typically just require 'clojure.repl if I need it)

thought the repl should support such a feature.

yeah, I just use if I'm working at the repl

but I'm usually working in an editor-connected repl and leave the repl window in user, while sending expressions from whatever namespace I'm working in

and using editor tools for doc support etc

I dropped an example of making a repl to do this somewhere

oh hey, I even wrote it down... https://insideclojure.org/2020/02/11/custom-repl/

You don’t drop in the repl window and switch to the current active buffer namespace for adhoc editting?

It is about clojure.main, so might not applicable to rebel

no, I write code in my editor and eval it

the main thing I usually use the repl window for is just (pst *e) :)

@alexmiller hah, I just tried this with bb and it also works there:

$ bb -e "(require '[clojure.main :as m]) \
        (m/repl :init #(apply require m/repl-requires) \
        :eval (fn [form] (do (require '[clojure.pprint :refer [pprint]]) \
        (eval form))))"
user=> (ns foo)
nil
foo=> (pprint {:a 1})
{:a 1}
nil

nice

@i You should probably read the README of rebel read-line: https://github.com/bhauman/rebel-readline#quick-usage > The main way to utilize this readline editor is to replace the clojure.main/repl-read behavior in clojure.main/repl.

It seems to offer integration with clojure.main

which part are you referring to ?

under quick usage

@i I think I have missed something. If using rebel readline, you have docs and eldoc (function signatures) in every namespace as part of the default Rebel readline UI. Its easy to run other commands from the repl namespace by using the fully qualified name, which rebel readline keeps in its history so you only have to type once and even then TAB will auto-complete the name of namespaces and functions, so you dont even need to type it in full once. Eg. (clojure.repl/dir clojure.string)

I did a short video of using REBL for a very simple project, showing eldoc and docs and tab completion of namespaces and function names http://practicalli.github.io/clojure/clojure-tools/repl/

for any of you toolsmiths looking for a project, it would be cool to see a tool that compared the APIs from two versions of a Clojure lib at the source level (like https://abi-laboratory.pro/?view=timeline&lang=java&l=clojure does for Java compatibility)

even knowing surface level add/remove/modify functions and add/modify arities would be a big help in detecting things (deeper level that understood keys in maps or coll types or whatever would be a harder task)

This is very easy to make using clj-kondo analysis. @lee didn't you make this kind of tools once for clj-doc?

For anyone who wants to have a stab a it: https://github.com/borkdude/clj-kondo/blob/master/analysis/README.md

We were talking about such a thing for cljdoc but never got to it. I did hack together something to compare rewrite-clj/rewrite-cljs/rewrite-cljc. It serves this purpose and but I am certainly not proud of its quality https://github.com/lread/diff-apis

I can whip up something in an hour or so

@borkdude, I think you might live in a different space/time continuum than me. :simple_smile: Or there are several of you “We are borkdude, resistance is futile”.

Will your clj-kondo solution pick up potemkin and potemkin-like imports?

@lee clj-kondo knows how to handle potemkin itself, but not sure about potemkin-likes

Isn't it something Rich worked on? Codeq?

@alexmiller Here's a first stab at it: https://gist.github.com/borkdude/2b963db1582654ec28bfd40b4dc35748

invokable as JVM script

Usage: api_diff.clj lib1.jar lib2.jar (or api_diff.clj foo/src bar/src)

There is also :private information in this analysis, I didn't take that into account, but small change.

There might be other diffing libs out there that give a format that's better suited for what you want, this is just a start

pretty cool. would love to see something like this integrated that also used tools.deps so you could tell it a lib and two versions to compare

codeq is actually in this ballpark, but is actually more fine-grained

I think it's both more and less than what I'm saying although it could be a good substrate

ultimately I wonder if you could say that a version has a breaking api change

@alexmiller tda returns this for lib-location: {:base "/Users/borkdude/.m2/repository", :path "org/clojure/clojure/1.8.0", :classifier nil, :type :mvn}, is there anything I could use to resolve the full path to the jar?

I wouldn't use lib-location at all

better to resolve-deps or calc-basis and get the paths out of the result

I just want the location for this one thing, that's why I thought lib-location would be fitting

lib-location won't actually download it

Ah I see:

#:org.clojure{clojure {:paths ["/Users/borkdude/.m2/repository/org/clojure/clojure/1.8.0/clojure-1.8.0.jar"], :deps/manifest :mvn, :mvn/version "1.8.0", :parents #{[]}}}

yeah, I did the downloading with resolve-deps already

for a maven dep, :paths should always have a single entry

(at least for now, maybe some future case to consider)

alternately, you could call org.clojure.tools.deps.alpha.extensions/coord-paths directly I guess

(ext/coord-paths 'org.clojure/clojure {:mvn/version "1.10.0"} :mvn {:mvn/repos maven/standard-repos})

probably the most direct but still most generic call you can make in the public api

Gist updated, works for mvn deps:

api_diff.clj org.clojure/clojure "1.8.0" "1.10.1" > /tmp/diff.txt

Detecting breaking changes is not something I will include today, it's getting too late ;)

I guess the algorithm should look at things that were in v1 but were removed in v2, or arities that were removed in v2

afk now, sleep

pretty sweet, nice hack

@borkdude there is one bug there - need to provide the standard maven repos if you don't have stuff locally

(require '[clojure.tools.deps.alpha.util.maven :as mvn])

then

(-> (tda/resolve-deps `{:deps {~lib {:mvn/version ~v}} :mvn/repos ~mvn/standard-repos} {})

@alexmiller Thanks, updated. Also swapped out deep-diff with editscript, this prints things like:

[[[clojure.core into] :fixed-arities 0] :+ 0]
 [[[clojure.core into] :fixed-arities 1] :+ 1]

My grep for 1.8.0 ~ 1.10.1:

[[[clojure.pprint format-simple-number] :fixed-arities] :-]
 [[[clojure.core emit-method-builder] :fixed-arities 4] :-]
 [[[clojure.core.reducers compile-if]] :-]

(some of these could be due to subpar analysis by clj-kondo)

ah for emit-method-builder it correctly detected an API change: https://github.com/clojure/clojure/commit/2cc37bb56a9125a1829c73c505e32995e663059a but this function is private, so no problem

and indeed, compile-if disappeared (also private)

so the only false positive seems to be the one in pprint

gnite

thx!

just trying to help here man - you're already a week into the new year without publishing any new tools

thanks ;)