you're shadowing str

clj꞉clojure-noob.macro꞉> 
(def p (atom 1))
#'clojure-noob.macro/p
clj꞉clojure-noob.macro꞉> 
(str @p)
"1"
clj꞉clojure-noob.macro꞉> 

This would work right? whats wrong ?

When you call (-occurance "AABBCCCAA"), str has value "AABBCCCAA". But then you call `

(println "-- " (str @cnt))
(conj acc (str @cnt prev))

oh crazy! me ... I did not noticed I am passing arg as str 😞

clj-kondo can report shadowed vars, it is really good to have it around

I guess its likely to be related to commons-* libraries

Don't you see the "sub-tree" in the output of clj -X:deps tree ? I'm not sure but maybe the uberjar build is picking different versions of the conflicting dependencies than the regular (REPL) run. Afaik, there's no generic solution for dependency conflicts - you need to find what libraries are causing problems and then fix their versions to ones that work. Do you have an exact error message? That would be a good start...

I do see a tree, what I was kind of after a a filter to show anything under pantomime and exclude the rest, mainly so I can do it for connection-pool and pantomime and do a diff on the trees to check the libs and versions.

In the end I dropped pantomime and extracted the one function that I actually used so I could use an updated Tika, which pantomime is a wrapper around

"java.lang.NoSuchMethodError: 'void com.mchange.v2.cfg.BasicMultiPropertiesConfig.<init>(java.lang.String[], java.util.List)" This is the actual error I get but I am not sure how to figure out the lib causing it, kind figure it my knowledge or perhaps this is just how it is in java land

You can google that class and check its history, notably the constructor it seems to mention: https://github.com/swaldman/mchange-commons-java/blame/master/src/main/java/com/mchange/v2/cfg/BasicMultiPropertiesConfig.java#L107-L110 And always check the stacktrace too - it will help you understand who's trying to invoke that.

Because this constructor seems to be package-private so only classes in the same package are allowed to call it.

I think the thing I find most perplexing is pantomime has nothing to do with databases and does not include mchange as a dependency, so I don't get why it would make the method unavailable all of a sudden,

Because mchange-commons-java is used by other libraries, e.g. c3p0 connection pool: https://mvnrepository.com/artifact/com.mchange/mchange-commons-java/usages

That dependency tree should make it obvious what artifacts are using mchange-commons-java . And, again, the stacktrace would help you determine where the problem happens.

My guess is that it's a transitive dependency of apache tika: https://github.com/michaelklishin/pantomime/blob/master/project.clj#L8-L9

Thanks, I will take another look not sure if I got a stack trace, kind of moved on but I would like a better understanding in case I hit this error again, that was part of my hoping there would be a way to shrink clj -X:deps tree to show just the deps I am interested in, I know I can copy and past but felt like there may have been a paramater to do that kind of filter.

If you need a total, I'd do something like (->> items (filter #(str/includes? % @value)) count). Is that what you're trying to do?

hmm as you see it's mixed with hiccup so function will return html. I was thinking I could get count from this function and save it to same atom value. Or do I have to write another function just with count? Seems like a waste.

or maybe I should first just filter the items and save to it atom value, get count save to another value, and finally pass it do hiccup function ?

Saving it to an atom value would be fairly un-idiomatic, I think

What's supposed to be in each :li?

just text in eg. word 'airplane'

So what's the count for? I guess it's used elsewhere?

there is a list of item and input if I press letter 'b' it will show all items with that letter so I want also a count of how many elements was found with letter 'b'

I'd let-bind the filtered elements, count it, show the count, and use the same bound name in the :ul code.

hmm so how this example would like look ?

something like

(let [results (filter #(str/includes? % @value)
                      items)]
  [:p "# results:" (count results)]
  [:ul (doall (for [result results]
                [:li result]))])

thank you @U05092LD5

Happy to help ❤️

This was https://clojureverse.org/t/can-i-require-functions-globally-so-i-dont-need-to-require-every-time-in-clojurescript/3048?u=dave.liepmann a while back, and the answer was "no" and a little bit "please don't". 🙂

The classic Clojure answer, then 😄

@U03EC9KU17H here i would think in terms of "if i were to make this into a lib, how does the user know defn means something else?" its simpler to be more explicit

right, but I don't want to make this into a lib

in some scenarios it's useful to have things defined globally. Like how things in clojure.core are useful globally in all projects, I want to be able to decide for my own project which things are useful globally, so I don't need to :refer [div h1 h2 h3 h4 h5 h6 p ul ol li ...] in every single file

sure, but if there is a process that allows this, it wouldve led you into this issue too

> I want to be able to decide for my own project which things are useful globally, so I don't need to :refer [div h1 h2 h3 h4 h5 h6 p ul ol li ...] in every single file In these kinds of scenarios I :refer :all

Guess I can always patch clojure.core, hmmm

idk how idiomatic it is, but you can probably require a function do-common-requires then run it. the body of the function would be (require whatever)

Is it April 1st already?

Found a great solution:

:repl-options {:init-ns org.my-domain.my-project
               :init (do (in-ns 'clojure.core) (def lol :lol) (in-ns 'org.my-domain.my-project))}

glad you found a solution that works for you

Does the API call have to be batched?

(def input
  [{:x 0,
    :y 0,
    :x-r 500,
    :y-r 500,
    :name "F4",
    :duration 1,
    :number 1,
    :color [164 219 207]}
   {:x 0,
    :y 0,
    :x-r 500,
    :y-r 500,
    :name "F4",
    :duration 1,
    :number 1,
    :color [64 19 7]}])

(let [colorz (map :color input)
      f #(map reverse %)
      updated (f colorz)]
  (map (fn [old new] (assoc old :color new))
       colors colorz))

f is the api call

but if it doesn’t have to be batched, it can be a lot simpler, which is what @U05092LD5 is getting at!

I wonder what's going on in get-new-color-state. is that the result of the batched call? Or am I reading this wrong 😄

Well does it have to be? I'm not sure actually. The API I was talking about is actually a NodeJS CLI. Before, I tried individual calls with sh from Clojure, but running node color.js 150 20 30ten thousands of times did not seem ideal, as I think there is startup time, so I tried this way. It might be worth a look if other approaches are too convoluted

Should've provided more context, sorry 🙂 Yes! get-new-color-state is the result of the batched call

@U051GFP2V thank you, I will try this.

Would really appreciate some feedback on my assumption about calling a node CLI thousands of times seperately. Maybe there is another way ..

Seems like something where a batched job will be faster ^

I wonder if memoization or better yet caching of these CLI results might speed things along.

Do you control color.js? Seems like you would want to alter that script to export any functions that might be useful as an API. Then you can use require instead of sh, and have everything you need right there.

@U90R0EPHA yes, I control color.js. However, the call happens from inside Clojure instead of ClojureScript. I've been wondering about the interop of the two, but my understanding was that I need to communicate over CLI or REST. Can you elaborate? 🙂 I'm not terribly familiar with JavaScript tooling.

@U05092LD5 thanks for the hint! I'm not yet familiar with these mechanisms in Clojure, but the transformation of the color is a process that happens relatively frequently, so the values that I get over the API will get replaced again eventually

More context: I use both ClojureScript and Clojure for this project. The main application (Quil) runs on Clojure in realtime, and I need to use JavaScript for some libraries that work with color and MIDI files, so there is a lot of tight interaction between the two. Non-realtime data I transmit via transit, realtime data via the node CLI.

In that case, I would likely suggest a long-running Node process that accepts API requests to pass through to the JS libraries. The most straightforward way to do that (mainly due to ease of copying code from the internet) would be an http server. You could alternatively use the https://nodejs.org/api/net.html to serve TCP or IPC. I suspect IPC sockets will give the best latency characteristics, which sounds potentially important for your use case. Maybe it would make sense to write the server/daemon in CLJS (instead of JS) to reduce context switching between languages? You are right that spinning up multiple Node processes will add a lot of overhead, including startup time for each process. So I don't think communicating through the shell is doing you any favors here. Removing the startup time of a Node process is going to wildly outweigh any perf tips anyone could offer you for transforming a Map.

Did @U051GFP2V’s solution speed it up?

I could try out @U051GFP2Vs solution and it works great, even with CLI calls. Thank you erscherize, thank you all for your time! 🙂

@U90R0EPHA I've thought about going the TCP route but was hesitant because of the overhead for client server communication. I am wondering about performance specifics. Is it really a difference if I choose IPC over TCP? The communication is running on localhost after all, I thought there is some kind of loopback mechanism allowing for transfer up to gigabytes per second.

At least on Linux, IPC is going to have slightly less system overhead and more optimized kernel paths. That doesn't really say whether this has a meaningful difference for you. Your comments indicate this is a music app. If that music is just playback, I doubt you would notice a difference, even if there is one. "Live" music, on the other hand, is extremely sensitive to latency, in which case ... still maybe. You would need perf testing to know for sure if the benefit of IPC is real for you. But, if nothing else, it should give you a bit of extra headroom for other sources of latency that might crop up.