xml

what a world

Has anyone tried connecting to a repl that is inside a docker container?

hey guys! A compiler question: I am compiling some java lambda code (so java sytax ) in clojure using java compiler I get via javax.tools.ToolProvider.getSystemJavaCompiler(). It turns out to be much slower (~ 10x - 100x) than just using clojure's compiler and just eval-ing clojure code using java interop (similar code, just in clojure syntax for java interop). Anybody has any ideas why I might see such difference? Is clojure compiler so tuned or are there things I can tune in the default JavaCompiler and the compilation configuration?

What's the best way to call into macOS APIs from Clojure? I don't need Cocoa, only CoreFoundation and other low-level frameworks.

I understand they are all C, so I can write a bunch of JNI wrappers, but maybe there is some ready-made library that allows me to skip this tedious process?

JNR-FFI will help with the boilerplate

@miro My hand wavey guess is that java's compiler needs to do more work. Java is a more complex language in general so i dunno maybe that affects things.

Also curious about using clojure in lambda

I don't see a way around that murdering start up time

so i am curious what the tradeoffs are for you

@emccue a lot of that startup time is 1) jvm spinup which lambda eliminates by leaving a vm running and 2) tooling (eg. lein) spinup which should only happen during dev never on a server

clojure itself can load in ~1s which is slow but not disasterous

java spin-up is like 100ms these days

right, just saying lambda trims that

yeah. clojure is a significant % overhead by comparison.

I have a question on defrecords

In a file there is a defrecord define like so

(defrecord Name [conn db]
        Database
        (do-something (hello something))) 

Ive never seen an example of this online. Usually it is just defined like this in the examples

(defrecord Name [conn db])

Can anyone explain what is going on?

the record implements a protocol or interface called Database, and that's how it implements the do-something method

but that's incorrect, the method needs an arg vector (like function syntax) and it needs at least one arg for the instance itself

Okay so all the methods that follow under Database are protocols being implemented?

Database is the protocol, it has multiple methods

Yes you are correct they actually look like this

(do-something [_ some_id] (hello something-else))

The first underscore here means that we wont be using that argument, correct?

@noisesmith Thank you!

the first argument is the object itself, yes

and _ is a conventional name for arguments you ignore - technically it's just another name though

I see, thanks again. I can google the rest since I know now what to look for

so I have a question about types/protocols

the specific instance I have, is that I want to extend reagent's atom type with some extra functionality... sometimes

basically, in my app I have some functions that return a ratom that represent a graphql query

(let [data (query! client some-query)]
  (fn []
    (println @data) ;; => {:loading false :data { ... }}
  ))

(let [data (query! client some-query)]
  (fn []
    (println @data) ;; => {:loading false :data { ... }}
    [:button {:on-click #(re-fetch! data)} "Clicky"]
  ))

is there some way to extend the reagent atom returned by the query! function to implement re-fetch!, without having to box the ratom in a new type and re-implement all of the protocols that RAtom uses?

You can try https://github.com/TristeFigure/clj-delegate

Using reflection, this library will generate the delegation methods for you. There is a monkey-patch of isa? though, not sure how bad this impact performance.

interesting!

yeah, this seems hairy. also not sure how it'll work in a CLJS context

I'm kind of tempted to stick a field into meta-data on the reagent atom with the function or object needed to refetch, and pull it out using re-fetch!

would that be abusing metadata? 😬