proxy+ might be good enough?

https://github.com/redplanetlabs/proxy-plus

but also there is no reason something like this needs to be a language feature - its just a library that would be a bit involved to write

thanks, I will try it out. Glad I asked 🙂 . Sometimes I find it silly to ask / complain about things.

peoxy-plus doesn't work for me so far. I can't add custom methods and can't implement clojure protocols either

added some issues there

I kid @U011NGC5FFY . You should add your usecase to that ask question

(e.g. Which class/library you are trying to extend)

ah makes sense 🙂

I’m a bit stuck trying to get figwheel working, just the blank project

I'd help, but I only know shadow-cljs

I've used something like (-> "2021-12-27" (clojure.string/split #"-") (->> (map js/parseInt))) before but I've been told it's bad style because it's difficult to read.

I used let to organize it. But don't know if that is any better. For example

(let [split-date (-> "2021-12-27" (clojure.string/split #"-"))]
  (->> split-date 
   (map #(Integer/parseInt %))))

Hm, yes it's a little more explicit because it doesn't omit split-date and % but there's so much more noise than in (-> "2021-12-27" (split #"-") (->> (map Integer/parseInt))

In the example stated, my personal preference would be like Jens', but with no threading macros at all. However, I understand that the example may be chopped down from a larger "real" example where that may not be as palatable. Since it wasn't mentioned yet, though, if you like thread-first and thread-last, you may like https://clojuredocs.org/clojure.core/as-%3E`as->`https://clojuredocs.org/clojure.core/as-%3E which lets you give a name to the value being threaded so you can "move" it at the cost of having to put the name on every call.

I've used it before but I forgot about it. It solves the problem nicely. Thanks!

FWIW, -> and as-> is a nice trick that I also use, e.g. when a map changes position across chained functions. However, going from a map to a collection (or vice versa) changes the semantics of the operation and that always makes me wonder if operating on the new data structure still belongs in the same expression. Sometimes I might not factor out the part that is different but it usually feels like a concession.

Ah, I needed set-resource-path!. Never mind 🙂

> if I am not careful they will all have dtype-next class files in them And just to ask, what is the issue with that?

duplicate versions of dtype-next that will have version conflicts.

would all those issues be resolved if you made the api via Clojure interop from java and including the lib directly?

https://github.com/Workiva/eva/blob/master/server/java-src/eva/Server.java

or is part of the conceit that from java you would want the AOT version because performance

Those issues would be solved with the api strategy and it means I am not releasing jars with AOT code in them which is also better. I am not certain how sensetive this person is to startup times but potentially not very. Will check with them.

Good news - they don't care about startup times :-). I will go the suggested route, thanks.

lmk if you need another pair of eyes on this - i spend way too much time in java

This bumped a performance test from 6 seconds to 14 seconds as it takes I guess 7 seconds on the test computer for Clojure to AOT compile libjulia-clj's main namespace. In addition we are seeing nontrivial per-call overhead for granular cases. So using the java api of Clojure introduces some nontrivial per-call overhead if you do not cache the var lookups.

Or perhaps just barely non-trivial. We are still testing to figure out the real overhead.

if you do not cache the var lookups. Caching the var lookups is i think what the clojure compiler does

Its fine without for now. The overhead was small compared to the inter-language overhead. The startup time irritates me but that gets us back to AOT land and GraalNative is better fix overall.

Something like this:

(boolean (some #(Character/isUpperCase %) "my-string"))

can always use a regex, too

(some? (re-find #"[A-Z]" "Hello"))
=> true
(some? (re-find #"[A-Z]" "hello"))
=> false

Depending on what definition of uppercase you are interested in 😉

I think java does unicode uppercase, so that would be much more than A-Z

fair, though what I really meant was <insert the re you want here>

the OP didnt really give many requirements

haha thats right 🙂.

I’m using:

(not (empty? (clojure.set/intersection 
                        (set (map char (range (int \A) (inc (int \Z)))))
                        pass-set)))

That should work. It’s less concise and may not perform as well, but not sure either of those matter for your app

(criterium.core/quick-bench (not (empty? (clojure.set/intersection
                                           (set (map char (range (int \A) (inc (int \Z)))))
                                           (set "Hello")))))
Evaluation count : 115524 in 6 samples of 19254 calls.
             Execution time mean : 5.380075 µs
    Execution time std-deviation : 192.028942 ns
   Execution time lower quantile : 5.195526 µs ( 2.5%)
   Execution time upper quantile : 5.668781 µs (97.5%)
                   Overhead used : 5.945740 ns

Found 1 outliers in 6 samples (16.6667 %)
	low-severe	 1 (16.6667 %)
 Variance from outliers : 13.8889 % Variance is moderately inflated by outliers
=> nil
(criterium.core/quick-bench (boolean (some #(Character/isUpperCase %) "Hello")))
Evaluation count : 166710 in 6 samples of 27785 calls.
             Execution time mean : 4.691801 µs
    Execution time std-deviation : 1.473038 µs
   Execution time lower quantile : 3.643838 µs ( 2.5%)
   Execution time upper quantile : 6.848259 µs (97.5%)
                   Overhead used : 5.945740 ns
=> nil
(criterium.core/quick-bench (some? (re-find #"[A-Z]" "Hello")))
Evaluation count : 8842668 in 6 samples of 1473778 calls.
             Execution time mean : 95.217955 ns
    Execution time std-deviation : 40.143411 ns
   Execution time lower quantile : 63.578066 ns ( 2.5%)
   Execution time upper quantile : 145.076806 ns (97.5%)
                   Overhead used : 5.945740 ns
=> nil

To @UDF11HLKC point, you may need more sophistication than the simple #“[A-Z]”

though your example indicates that seems to be what you are after

taking the sets out of the loop improves things a little

(def a-z (set (map char (range (int \A) (inc (int \Z))))))
=> #'user/a-z
(def pass-set (set "Hello"))
=> #'user/pass-set
(not (empty? (clojure.set/intersection
               a-z pass-set)))
=> true
(criterium.core/quick-bench (not (empty? (clojure.set/intersection
                                           a-z pass-set))))
Evaluation count : 757662 in 6 samples of 126277 calls.
             Execution time mean : 794.342275 ns
    Execution time std-deviation : 20.931468 ns
   Execution time lower quantile : 779.791023 ns ( 2.5%)
   Execution time upper quantile : 828.102107 ns (97.5%)
                   Overhead used : 5.945740 ns

Found 1 outliers in 6 samples (16.6667 %)
	low-severe	 1 (16.6667 %)
 Variance from outliers : 13.8889 % Variance is moderately inflated by outliers
=> nil

but its still about 8x slower than regex

(defn has-upper? [s]
  (not= s (clojure.string/lower-case s)))

(criterium.core/quick-bench (has-upper? "my-string"))
Evaluation count : 32280036 in 6 samples of 5380006 calls.
             Execution time mean : 12.746610 ns
    Execution time std-deviation : 0.824987 ns
   Execution time lower quantile : 12.230249 ns ( 2.5%)
   Execution time upper quantile : 14.103503 ns (97.5%)
                   Overhead used : 5.950458 ns

Found 1 outliers in 6 samples (16.6667 %)
	low-severe	 1 (16.6667 %)
 Variance from outliers : 14.9398 % Variance is moderately inflated by outliers
=> nil

what if I want to check if the string contains lowercase?

(defn has-lower? [s]
  (not= s (clojure.string/upper-case s)))

yes

what if I want to check for special characters?

(defn is-pass-valid? [pass]
  (let [pass-set (set pass)
        range-set (fn [start end] 
                    (set (map char (range (.charCodeAt start) (inc (.charCodeAt end))))))]
    (and (>= (count pass) 8)
         (not= pass (clojure.string/lower-case pass))
         (not= pass (clojure.string/upper-case pass))
         (not (empty? (clojure.set/intersection 
                        (clojure.set/union
                         (range-set \space \/)
                         (range-set \: \@)
                         (range-set \[ \`)
                         (range-set \{ \~)) 
                        pass-set))))))
 

well, if you're checking to see if a password meets certain conditions, i would advise just reading modern password guidance which suggests you shouldn't require a bunch of hoops for someone to jump through because it inevitably leads them to using somewhat weak / predictable patterns in order to satiate the password validation algorithm

https://www.troyhunt.com/passwords-evolved-authentication-guidance-for-the-modern-era/

> Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets

in your example there are two spellings in the package inerface and interface - do they match in your real code?

also you shouldn't need to specify the whole package name, it should be in scope in the ns where it is declared automatically

you don't need AOT for this, clojure creates an interface class when you use defprotocol , and if you look at the error, it isn't even a proxy+ issue - it's the compiler telling you that the class you asked for does not exist (likely the typo mentioned above)

yes, it was the typo above. I had the protocol in the same file and it didn't work and then I moved it outside and introduced the typo.

I think now it's fixed, thanks for looking at this and confirming I don't need AOT

Sounds like conflicting versions of libraries that were AOT'd. I think whitespace? was a recent-ish addition?

i checked and i’m seeing it since 2017

2013. Not recent-ish. But it could still be an old version of reader somewhere?

yeah. that makes the most sense. oddly enough this started failing on a non-code change. it really doesn’t make sense

and super frustratingly passes on test re-run

Leiningen or CLI?

cli

Hmm, bit surprised it's non-deterministic then, although I guess your test deps could be bringing in a different tools.reader and changing what gets selected.

I'd definitely look through -Stree and perhaps some of the JARs you're bringing in to see if there's an AOT'd tools.reader somewhere in them...

Could be a code loading race, manifests in weird ways like that, and nondeterministic

There was a known code loading race in cli, but the most recent release is supposed to fix it

i bumped that and hopefully it goes away. I don't like that I cannot explain it though, and that it is transient

https://ask.clojure.org/index.php/10905/control-transient-deps-that-compiled-assembled-into-uberjar has some stacktraces from the code loading race errors that look pretty similar to yours (random vars in tools.reader not existing)