Is there a way to use a jar that packages native shared libraries via tools.deps? The native library in a small isolated test appears to not load causing the jni layer to choke.

chrisn@chrisn-dt:~/dev/tvm-clj/tvm/build$ clojure -Sdeps '{:deps {techascent/tech.opencv {:mvn/version "1.2"}}}'
Clojure 1.9.0
user=> (require '[tech.opencv :as opencv])
WARNING: cast already refers to: #'clojure.core/cast in namespace: tech.datatype.base, being replaced by: #'tech.datatype.base/cast
WARNING: cast already refers to: #'clojure.core/cast in namespace: tech.datatype, being replaced by: #'tech.datatype/cast
CompilerException java.lang.ClassNotFoundException: org.bytedeco.javacpp.opencv_core, compiling:(tech/opencv.clj:1:1)

i'd try excluding clojure.core from that import, not sure if applicable at all to this case though

@chrisn there’s nothing different here than anything other classpath building. Using that dep should download it (and its deps) and build a classpath. If some other step needs to be done, you still need to do it.

$ clojure -Sdeps '{:deps {techascent/tech.opencv {:mvn/version "1.2"}}}' -Stree
org.clojure/clojure 1.9.0
  org.clojure/core.specs.alpha 0.1.24
  org.clojure/spec.alpha 0.1.143
techascent/tech.opencv 1.2
  org.bytedeco.javacpp-presets/opencv-platform 3.4.0-1.4
    org.bytedeco.javacpp-presets/opencv 3.4.0-1.4
  techascent/tech.javacpp-datatype 1.3
    techascent/tech.resource 2.0
    techascent/tech.jna 1.2
      techascent/tech.datatype 1.1
        net.mikera/vectorz-clj 0.48.0
          net.mikera/clojure-utils 0.8.0
          net.mikera/vectorz 0.66.0
            us.bpsm/edn-java 0.4.7
            net.mikera/mathz 0.3.0
            net.mikera/randomz 0.3.0
        net.mikera/core.matrix 0.62.0
          org.clojure/tools.macro 0.1.5
      net.java.dev.jna/jna 5.0.0
    org.bytedeco/javacpp 1.4

seems to be building and including those deps

if you need to additionally include a native lib, then you need to additionally include it

it looks like maybe there is a missing classifier on the org.bytedeco.javacpp-presets/opencv dep, or maybe that is a bug in the maven transitive deps stuff in deps.edn

I don't think there is missing information on opencv. It works from java and leiningen. The java jar includes native/linux/x68_64/*.so and leiningen has special code to deal with this (setting up java library path and such) I believe.

clj doesn’t have anything special for native library paths

I think it would be in scope to do so, but I’m not sure what needs to be done. If you wanted to do some research and write up a ticket and I’d be happy to look at it at some point

Sounds reasonable. Here is the start of the leiningen code for native although I do not know how maven does it: https://github.com/technomancy/leiningen/blob/master/leiningen-core/src/leiningen/core/classpath.clj#L35

https://dev.clojure.org/jira/browse/TDEPS-103

I would be happy to help with this also. The full pathway for great native support I think is a bit more in-depth than a tools.deps fix.

I think I either don't understand macros, or I don't understand spec, but I am getting some weird errors trying to make a macro that makes an fn form

say I have an example destructured fn that looks a bit like this:

((fn [{{:keys [b] :as a} :a}]
   a)
 {:a {:b 2}})

it's a bit unwieldy to struct a and b each time, and b can change, as can the body of the fn, so I make a macro like so:

(defmacro ab-fn
  [args & body]
  `(fn [{{:keys [~@args] :as a} :a}]
     ~@body))

(macroexpand-1 '(ab-fn [b] a))
;; => (clojure.core/fn [{{:as my-ns/a, :keys [b]} :a}] a)

@socksy the bare a after :as is getting namespace qualified, unlikely you want that

sure, but say i do

shouldn't it still work?

because now, fn doesn't pass spec

you cannot have local variables bound to qualified symbols

(macroexpand '(ab-fn [b] a))
;; =>
Call to clojure.core/fn did not conform to spec: In: [0 0] val: ({{:as
                                                                   application-connection.routes/a, :keys [b]} :a}) fails spec:
:clojure.core.specs.alpha/arg-list at: [:args :bs :arity-1 :args] predicate:
(cat :args (* :clojure.core.specs.alpha/binding-form) :varargs (? (cat :amp
                                                                       #{(quote &)} :form :clojure.core.specs.alpha/binding-form))), Extra input In:
[0 0] val: {{:as application-connection.routes/a, :keys [b]} :a} fails spec:
:clojure.core.specs.alpha/arg-list at: [:args :bs :arity-n :args] predicate:
vector?

I can't?

you're right, I can't. Why not?

and is there an easy way to not get it to qualify the symbol?

~'a instead of a

great, thanks

How do you get the name of the function your currently in the scope of? (defn foo [x] (println "im from function: " ??)

actually, it would be more like (

(defn greet [f] (print "hello:" f))
(defn foo [] (greet ???))
(foo)
=> "hello foo"

no way to do that AFAIK

@drewverlee In a macro you can use &form to see the original call. Depending on what you're trying to do, you could have a modified defn macro, and include that info as a value that's available inside the function. IIRC macros that "leak" information intentionally into the function are Anaphoric macros.

is anyone able to give me a 30,000 view of clojure.lang.RT

It contains many Java methods needed by Clojure/Java to implement base Clojure functionality like cons, first, next, rest, hash, nth, etc. that are called directly from many functions in the clojure.core namespace.

thanks!

RT = runtime

I suspect modern Clojure versions don't run on the Android VM anymore due to bytecode reasons - is that correct? I tried to google for Android and Clojure 1.9, and there isn't a single mention online.

there's a clojure-android project, but it had to fork the clojure compiler itself (for reasons I've forgotten), and nobody got around to doing the same modifications for newer clojure versions

That reason is probably because the Android VM uses a different bytecode format than the JVM

I suspect making 1.9 work wouldn't be any harder than making 1.3 work, both would involve editing clojure.core by hand though

iirc clojure-android is stuck on 1.6?

the asm lib would have to be downgraded then i suppose

Is the asm lib capable of putting out ART VM bytecode though? Though it's probably easier to just wait until the Gluon VM (based on OpenJDK) is available for Android, which could be soon

oh, at some point it upgraded to 1.7

Looks like I'll have to use another language for my Android plans 😕

yeah I wanted to use clojure for android too 😞

JavaFXPorts is quite phenomenal, that'd be great.

Like, you can create an application with a JavaFX GUI that runs on all platforms without changing a single line of code. Now all that's needed is a Clojure that can run on the Android VM

I think we need to bribe the React Native team to decouple their bundler from the rest of the project

then we could plug in our CLJS toolchain a lot easier

what are people using to program server side websockets in clojure these days? I’d prefer something that can work alongside ring/jetty, so preferably with a jetty backend… but open to other options e.g. pedestal, if they’re more mature

I use pedestal for ws at work

was also wondering if anyone has done any websocket stuff with ring async handlers

We use sente

googles

ahh yes sente I’ve been to this page before thanks, will take a look in more detail.

why (take 5 (repeat "x")) gives some lazy sequence when in (str "9" (doall(take 5 (repeat "x")))) or in (str "9" (take 5 (repeat "x"))) what is the deal with lazyness and how it works.

@zilti, did you try GraalVM and run it as a native app?

@audrius try wrapping the take in pr-str

the toString of lazy-seqs forces the collection, but prints in a weird and mostly useless way

if you use pr-str instead you get a more reasonable printed form

user=> (str (take 5 (range)))
"clojure.lang.LazySeq@1b554e1"
user=> (pr-str (take 5 (range)))
"(0 1 2 3 4)"

also, doall returns the same coll that was passed in, after calling dorun, so you get a lazy-seq back, but with the items forced

doall doesn't change the type, it merely ensures the elements are realized

but how do I get \9 with 5 \x ?

clojure.string/join?

user=> (str "9" (pr-str (take 5 (repeat "x"))))
"9(\"x\" \"x\" \"x\" \"x\" \"x\")"
user=> (print *1)
9("x" "x" "x" "x" "x")nil

you might also find the format function useful

and join them into string?

str joins all its args into a string

what do you want the output string to actually look like?

user=> (apply str "9" (take 5 (repeat "x")))
"9xxxxx"

Is there any reason for wanting to print lazy sequences like this ?

also:

user=> (str "9" (seq (take 5 (repeat "x"))))
"9(\"x\" \"x\" \"x\" \"x\" \"x\")"

there are many data types that print toString similarly

user=> (str (byte-array [0 1 2]))
"[B@6c81fb4c"

that specifically is not "printing" the lazy seq

str is not printing (pr or println)

there is no single .toString (which is what str calls) implementation for lazy seqs

there is a single pr implementation for lazy seqs

user=> (str (range 10))
"(0 1 2 3 4 5 6 7 8 9)"
user=> (str (map inc (range 10)))
"clojure.lang.LazySeq@c5d38b66"
user=> 

range is a special beast isn't it? or does it return a standard lazy seq

it is a lazy seq

It’s actually an instance of clojure.lang.Iterate, but it implements the lazy-seq interfaces

It used to actually be a lazy-seq; but I think they changed its implementation for performance reasons… can’t recall which clojure version

lazy seqs are describe by an interface, so they cannot dictate the behavior of toString for every implementation

so it doesn't even try

pr is abased on a multimethod so it can have a behavior for objects are instances of a class that implement an interface

what is the lazy seq interface?

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/ISeq.java

>that specifically is not "printing" the lazy seq >str is not printing (pr or println) Agreed. However, consider this:

user=> (.toString (seq [1 2 3]))
"(1 2 3)"
user=> (.toString (lazy-seq [1 2 3]))
"clojure.lang.LazySeq@7861"

user=> (pr (seq [1 2 3]))
(1 2 3)nil
user=> (pr (lazy-seq [1 2 3]))
(1 2 3)nil

user=> (.toString (range 1 10))
"(1 2 3 4 5 6 7 8 9)"
user=> (.toString (range))
^C (takes forevers)

what are you calling lack of symmetry?

thanks @hiredman i was confused for a second if there was a different interface for lazy seqs or if it was just ISeq

also I guess clojure.lang.IRealized if you care about it not just being a sequence. Though this isn’t much used.

We can consider clojure.lang.LazySeq to be informally lazy, along with clojure.lang.Iterate and other constructs returned by range ; although they do not have a formal link via a parent class or interface, they follow the same semantics (at least to keep the surprise rate low on the programmer's side). What I observe is that .toString:

user=> (.toString (clojure.lang.Iterate/create inc 0))
^C (takes forevers, i.e. that lazy seq is being realized)
user=> (.toString (clojure.lang.LongRange/create 10))
"(0 1 2 3 4 5 6 7 8 9)"
user=> (.toString (clojure.lang.Range/create 10))
"(0 1 2 3 4 5 6 7 8 9)"

user=> (.toString (lazy-seq [1 2 3]))
"clojure.lang.LazySeq@7861"

Hmmm… actually I think I’m wrong in my pedantry 🙂 realized? isn’t actually implemented on all the appropriate “lazy seq like types”… e.g. (realized? (range)) ;; => true but (realized? (range 10)) ;; => ClassCastException clojure.lang.LongRange cannot be cast to clojure.lang.IPending clojure.core/realized? (core.clj:7453)

is this a bug?

realized? is useless nonsense outside of maybe using it with promises

https://dev.clojure.org/jira/browse/CLJ-1751

;; deadlock with nested alter-var-roots, just for fun
(let [f1 (future
           (alter-var-root #'a
                           (fn [a]
                             (Thread/sleep 100)
                             (alter-var-root #'b
                                             (fn [b] (+ b a))))))
      f2 (future
           (alter-var-root #'b
                           (fn [b]
                             (Thread/sleep 100)
                             (alter-var-root #'a
                                             (fn [a] (+ b a))))))]
  ;; two futures that never complete
  [f1 f2])