Fork me on GitHub

It probably won’t be http2 but that would be pretty cool if I could pull it off. If I can do a tcp connection easily, then that might be cool. Maybe I’ll fudge the purity of my red-green-refactor process and just setting for seeing if I get a response after doing a GET request.


Is there something like elixir-radar, but for Clojure?


@doglooksgood For these kind of questions it always helps to explain what library-in-other-language is. Otherwise you’re limiting yourself to just the small subset of people who have extensive experience in both Elixir and Clojure.


@simongray ah, yes, my mistake. What I'm looking for is somewhere I can find the latest, carefully collected Clojure News, Topics and Job information.


The REPL ( and lately Clojure Morsels ( newsletters seem to fit the description apart from the job listings part and are well worth subscribing to


There's also which is the core team collecting some news items together.


is there a robust solution for repl-driven development with records?


this was a major motivation for tools.namspace/refresh which in turn was a big motivation for stuartsierra/component

👍 2

the idea being that if you can't trust your record instances, you want to have a way to tear down and rebuild every namespace using them

👍 2

alternatively you can avoid using records


if one works only with protocols (not interfaces) and eludes inline implementations with defrecord/`deftypte`, would it be a better repl experience?


From Clojure Programming, when it talks about limitations of redefining constructs (just read recently) > Class instances retain inline implementations forever. Inline interface and protocol implementations in classes defined by deftype and defrecord cannot be updated dynamically for existing instances of those classes. Workarounds here include delegating implementations to separate functions that you can readily redefine as necessary (…) and instead of providing functions named by vars when implementing protocols via extend, provide the vars themselves using the #' notation. Once you update the functions held by the latter, the new functions will be used to support the protocol implementations. Not sure it is feasible or does solve anything


> is there a robust solution for repl-driven development with records? When it comes for those records to implement protocols, extension-via-metadata helps a lot for repl friendliness So that you don't find the records implementing outdated protocols


@U45T93RA6 have an example of how that works?

vemv20:08:12 I said something partly wrong: defrecords can't implement something via metadata. What I do is replacing defrecord with a defn that will return a vanilla map accompanied by metadata. Just like in the link above

👍 2

Of course if you really want defrecord, this isn't a proper solution. It's more oriented for people using the Component library or similar designs


this stack overflow answer ( describes the issue, but in short: every time defrecord is evaluated, the record is recompiled and all existing instances of that record are now outdated and can’t use the defined protocol functions or match the new record type


What is current tendency for new clojars net.clojars.user? do you use your domains instead or com.github.user? Just want to fallow what community prefer to see. I know technically it is almost the same.


I think io.github.user is preferred since you can relatively easily create a site on that domain using github pages, so for library there might be a page with docs and stuff


by create you mean guess in web browser? Technically you can create github pages whatever domain you use in clojars.


com.github.user is reserved for official GitHub libraries, io.github.user is the one to use for users :thumbsup:


detail, I point to what clojurains like to use 🙂 net.clojars.user io.github.user own domain

Martynas M14:08:00

I'm not sure, maybe it's strange. But I didn't even try CLR clojure yet. Is there a way to do it on linux? Or is it only deployment thing?


I'm running into a reflection warning problem that seems quite strange to me. I'm creating a PNG renderer, and proxying it so that I can add some rendering hints to the createRenderer call.

(proxy [PNGTranscoder] []
    (createRenderer []
      (let [add-hint                (fn [^RenderingHints hints k v] (.add hints (RenderingHints. k v)))
            ^PNGTranscoder this     this  
            ^ImageRenderer renderer (proxy-super createRenderer) ;; line 105 in source


and getting the error > Reflection warning, metabase/pulse/render/poc.clj:105:37 - reference to field createRenderer on org.apache.batik.transcoder.image.PNGTranscoder can't be resolved.


but i'm surprised to see that it is complaining about a reference to a field rather than a method.


So that warning is correct, i think, that there is no field createRenderer, but there is a method.


He type hinted 'this' to make it work


yes and that workaround is in this snippet


note the error has a type : cannot reference field createRenderer on org.apache.batik.transcoder.image.PNGTranscoder


Oh right


it is looking for a field and correctly not finding it




No, it isn't a field or method issue, the issue is the method is not public


ah, it is protected


that's a bummer that proxy doesn't consider protected methods. I'm not sure how to proceed yet


it isn't so much that proxy doesn't consider protected methods, it is that proxy super works by mutating the proxy object and then does normal clojure method call, and those cannot be against a protected method


interestingly, this code "works" and renders images. i'm surprised it doesn't throw a runtime error then


it is because proxy makes the method public, but on the class you are type hinting this as it is protected


so the reflective call ends up being against the runtime type, which is the proxy generate class where the method is public, but the compile time attempt to generate a non-reflective call is against the base class where the method is protected


Ok. And if its not too much bother, is this something I need to be smarter about, or is this a bug in Clojure? or neither?


I would say it is a bug in clojure


I haven't used it but you might look at something like


there is an existing jira ticket for the fact that most calls to proxy-super end up being reflective, and their solution is to automatically add the type hint like you have, so that wouldn't fix things for you


yeah i found the helpful clojuredocs about that at first


i made an question with this but i didn't want to put any of this discussion in after stu's good ticket article


but if you could authoritatively put your thoughts there that would be helpful


I think it is this?


Is anyone pub/sub-ing happily away with one of the several CLJ clients for MQTT? Not sure which to try first. Thx! 🙏