This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws (1)
- # bangalore-clj (1)
- # beginners (48)
- # boot (65)
- # braveandtrue (1)
- # cider (1)
- # clara (15)
- # cljs-dev (7)
- # clojure (179)
- # clojure-austin (1)
- # clojure-denmark (2)
- # clojure-greece (68)
- # clojure-italy (7)
- # clojure-russia (41)
- # clojure-serbia (9)
- # clojure-spec (44)
- # clojure-uk (27)
- # clojured (15)
- # clojureremote (20)
- # clojurescript (70)
- # community-development (2)
- # core-async (10)
- # cursive (14)
- # datomic (36)
- # defnpodcast (3)
- # emacs (13)
- # events (13)
- # hoplon (33)
- # immutant (18)
- # instaparse (2)
- # jobs (29)
- # jobs-discuss (71)
- # klipse (38)
- # lein-figwheel (4)
- # leiningen (1)
- # mount (34)
- # off-topic (36)
- # om (3)
- # onyx (51)
- # pedestal (5)
- # perun (8)
- # proton (2)
- # rdf (8)
- # re-frame (33)
- # reagent (24)
- # remote-jobs (1)
- # rum (6)
- # spacemacs (2)
- # specter (14)
- # sql (5)
- # testing (6)
- # untangled (1)
- # vim (10)
- # yada (3)
Hi everyone. I am looking for some advice on an interop problem I have stumbled into.
I am working with a Java API that requires me to extend an existing abstract base-class, add some fields and an annotation. What would be the best way to accomplish this with Clojure? Is
gen-class the way to go?
@mss given "will then be passed to a method that expects a
java.lang.Class”, then you need to use something that creates a (presumably known) class - options are
if your only constraint is to implement an interface, then
deftype might be the easiest:
(qualified by your current namespace if you need the fully-qualified class)
thanks for the response, that makes sense. how does
deftype work under the hood? worried about leaking memory from successive calls to e.g.
make-an-instance above (except deftype instead of defrecord) to make the body of the interface method dynamic
if you’re just calling it dynamically (not AOTing code that uses it), it should just be creating classes and registering them in the classloader
and over time none of those class declarations would be deallocated, correct? sorry my understanding of jvm memory lifecycle is a little fuzzy
great, glad that class unloading is a thing. will look into it more. thanks so much for the help
it has evolved a lot in the JVM over the years and Clojure has its own DynamicClassLoader with its own class cache, but it should let that happen
I’m reading through Clojure Applied (which is awesome) and i was hoping someone could help me wrap around why the author suggests using a protocols for the core functions of an API. They state.... > Most APIs have this pattern—a handful of key base functions and a larger set of functions provided for ease of use. Protocols are a good way to capture the core set of functions so that multiple implementations can extend that protocol. The derived functions should be provided in the API namespace and layered over the protocol. TheAPI functions then work for any entity that extends the protocol. Is the benfiet of using a protocol that we make the functions needed to implement the API explicit in the protocol. So if a differently shaped set of data wants to implement the API we have documented the core function signatures and some docs. This also seems to imply we should keep our core set of data for the api inside a record, as protocols work on different classes.
Yes, protocols are often used to present an abstract interface. For example, ClojureScript uses protocols to represent the interfaces of data: https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L516-L524
So it seems the general wisdom is to have abstract interfaces (protocals, records) at your core, but to accept more general data (maps) at your edges.
I'm confused by this (right at the start of clojure koans) - "What could be equivalent to nothing?" (= nil)
i think you can use everything what returns nil, like https://clojuredocs.org/clojure.core/first (first ) ?
Here’s a timeline of what prints:
(defn sleep-print-update [sleep-time thread-name update-fn] (fn [state] (Thread/sleep sleep-time) (println (str thread-name ": " state)) (update-fn state))) (def counter (ref 0)) (future (dosync (commute counter (sleep-print-update 100 "Thread A" inc)))) (future (dosync (commute counter (sleep-print-update 150 "Thread B" inc))))
from Chapter 10 of Clojure for the Brave and True I'm confused why
Thread A: 0 | 100ms Thread B: 0 | 150ms Thread A: 0 | 200ms Thread B: 1 | 300ms
printlnis called twice (per thread) ...
commuteshouldn't be retrying the "transaction"
commute, on the other hand, behaves like this at commit time: Reach outside the transaction and read the ref’s current state. Run the commute function again using the current state. Commit the result.
the commute fn runs in future, the thread sleeps and at the end when state is changing it derefs the state and runs commute fn again
from http://stackoverflow.com/questions/29592681/why-is-the-commute-function-called-twice-when-changing-a-ref-in-clojure it sounds like
commute is actually running twice (similar to your explanation above)
Why am I getting two different results when I eval and debug the same function in cider? 😅
I don't use cider much, paste the code and the results, maybe somebody will help.
@not-raspberry the code is a little messy, I'll find the solution on my own 😕 Thanks! 🙂