Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-08-02

Channels

#clojure
<
2021-08-02
>
West04:08:09

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.

tianshu09:08:22

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

simongray09:08:05

@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.

tianshu09:08:01

@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.

tvirolai10:08:55

The REPL (https://www.therepl.net) and lately Clojure Morsels (https://dev.to/corasaurus_hex/announcing-clojure-morsels-56ma) newsletters seem to fit the description apart from the job listings part and are well worth subscribing to

Ed10:08:27

There's also https://clojure.org/news/news which is the core team collecting some news items together.

Noah Bogart13:08:09

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

noisesmith14:08:24

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

👍 2
noisesmith14:08:19

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
noisesmith14:08:35

alternatively you can avoid using records

bnstvn18:08:04

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

bnstvn18:08:46

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

vemv20:08:53

> 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

Noah Bogart20:08:28

@U45T93RA6 have an example of how that works?

vemv20:08:12

https://clojure.org/reference/protocols#_extend_via_metadata 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
vemv20:08:16

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

Noah Bogart13:08:05

this stack overflow answer (https://stackoverflow.com/a/62686394/3023252) 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

kwladyka13:08:29

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.

vlaaad15:08:48

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

kwladyka15:08:41

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

schmee15:08:51

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

kwladyka15:08:43

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

Martynas Maciulevičius14: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?

dpsutton15:08:45

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

dpsutton15:08:56

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.

dpsutton15:08:22

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

dpsutton15:08:59

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

isak15:08:29

He type hinted 'this' to make it work

dpsutton15:08:00

yes and that workaround is in this snippet

dpsutton15:08:25

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

isak15:08:27

Oh right

dpsutton15:08:35

it is looking for a field and correctly not finding it

isak15:08:06

:thinking_face:

hiredman15:08:03

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

dpsutton15:08:25

ah, it is protected

dpsutton16:08:07

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

hiredman16:08:25

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

dpsutton16:08:15

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

hiredman16:08:08

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

hiredman16:08:05

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

dpsutton16:08:40

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?

hiredman16:08:09

I would say it is a bug in clojure

hiredman16:08:57

I haven't used it but you might look at something like https://github.com/redplanetlabs/proxy-plus/

hiredman16:08:17

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

dpsutton16:08:47

yeah i found the helpful clojuredocs about that at first

dpsutton16:08:22

i made an http://ask.clojure.org question with this but i didn't want to put any of this discussion in after stu's good ticket article

dpsutton16:08:36

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

dpsutton15:08:34

I think it is this?

kennytilton16:08:16

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