It is pretty easy to reconstruct a proto-generated Java class provided you have the bytes. In Kotlin it would be val reconstituted = MyProtoType.parseFrom(theByteArrayIWantToParse), and I imagine similar in Clojure. Then you can render that as whatever type of string you like.

Hmmm… I am not sure we are on the same page. I have, say, foo.proto file(s) for things. I have a bag of bytes provided to me as a b64 encoded string. I want to take the bag of bytes and turn them into a map with all the data therein so that I can render it as say, JSON. It is the reading of the protofiles and making them usable in Clojure that I am having the issue with.

You will need to use protoc to generate a Java class from the proto files, then instantiate one from the bytes as above

Or at least, that is the easiest way I know to do that

Do you know of a library (clojure) that you have successfully used ? I am currently kicking the tires on https://medium.com/appsflyer/appsflyers-open-source-libraries-for-clojure-and-protocol-buffers-da9a87583c41

It seemed like a really nice tool… nice write up. And I like the lein pluggin to pull schemas from another git repo or local. but I can’t get it to work.

I think there is something wrong with the proto files I am using but now I am trying to tease that apart.

I've never used gRPC with Clojure, just Kotlin, so I'm afraid I can't recommend any libraries. However, the principles are probably the same - the Leiningen plugin is a very similar approach to what Maven uses. If it isn't working for you, I'd suggest trying to generate stubs using just protoc to rule out a problem.

Thanks 👍 Much appreciated. 🙂

Psssst… this is a Clojure list, right? 😉

Yes? Not sure what point you are making

For some closure : I sorted my issue by incorporating com.appsflyer/lein-protodeps into my workflow and using clojusc/protobuf. The former really streamlined the process and the former allowed me to do the pb marshalling and unmarshalling programmatically. In the end, problem solved.

With spec 1, you can do it by adding an extra predicate that just checks that there are no extra keys.

Thanks. Now doing this:

(def cmyk-colors #{:cyan :magenta :yellow :black})

(s/def ::cyan int?)
(s/def ::magenta int?)
(s/def ::yellow int?)
(s/def ::black int?)

(s/def ::blend
  (s/and (fn [m] (every? cmyk-colors (keys m)))
         (s/keys :opt-un [::cyan
                          ::magenta
                          ::yellow
                          ::black])))

(s/valid? ::blend {}) ;; => true
(s/valid? ::blend {:cyan 10}) ;; => true
(s/valid? ::blend {:cyan 10 :black 59}) ;; => true
(s/valid? ::blend {:cyan 10 :black 59 :green 2}) ;; => false

Yep!

And if you really would like to avoid duplication, there's https://github.com/metosin/spec-tools

Maybe it actually has closed specs - has been a minute since I used it.

perhaps not relevant (or even correct, it's been a while since I've used spec), but it might be a good idea to put the predicate function after s/keys in the s/and. That way ::blend works as a generator, in case you need that somewhere.

> is that actually a pre-compiled Regex-Pattern? It is. Even if it wasn't - doesn't matter much because it would be compiled on the first usage. > If I call a function with a Pattern twice, is that the same object, or will it be reinstantiated? Not clear what you mean. Can you provide some code?

(defn foo [s] (re-matches #"bar" s))

It will be compiled during reading, so no, it won't be re-created again and again. It will happen only once.

user=> (identical? #"foo" #"foo")
false
user=> (defn get-regexp [] #"foo")
#'user/get-regexp
user=> (identical? (get-regexp) (get-regexp))
true

I see! thanks guys 🙂

Although if it has to be CLJS compatible, then yeah, a go loop would be your best bet.

I'll admit I'm a little curious why there aren't any agent libraries for CLJS, considering it's pretty easy to implement agents in terms of core.async

For the send-off case, yes. For send, the picture is not so clear. In any case, async is so much more flexible!

Why would send be less clear? It's also designed for blocking, it just blocks on computation, not IO. They have the exact same API, personally I'd think actually doing what send-off is designed for, blocking on IO, would be harder in CLJS since usually "blocking on IO" has to be done via async stuff, so you'd need to have a way to have what you put on send-off be an async function itself.

Which on its own would be incompatible with the JVM version

although you might be able to manage something that works on both with like a thread first macro like

(fn [x y z]
  (-> (do stuff as a body)
      #?(:cljs (a/go))))

It looks simple enough here: https://github.com/Zygo/xscreensaver/blob/master/hacks/screenhack.c#L903 After XtAppInitialize on 763, the code either proceeds with it's own window, draws on the given ID, or creates a virtual root window and draws on that. So doing the lower level calls to get that far shouldn't be too hard.

not impossible - you got add-opens + reflection

I tried reflection, but can't get around it

I'll have to look into what add-opens are...in the morning 😉

yeah so basically launch the jvm with a flag opening that specific module to the "ALL-UNNAMED" module and then reflection will work again

you should know what module its in by the error message you got when using reflection

It did take a moment to figure that out, but it was easy to find in the AWT source. java.desktop/sun.awt.X11 I got to the point of setAccessible working this time. But can't quite figure out how to invoke functions yet. I'm trying XOpenDisplay first. (. xod (invoke nil (*into-array* Object [(*long* 0)]))) It tells me:

Execution error (UnsatisfiedLinkError) at sun.awt.X11.XlibWrapper/XOpenDisplay (XlibWrapper.java:-2).
'long sun.awt.X11.XlibWrapper.XOpenDisplay(long)'

how descriptive

Right? I made some progress a few days ago. Here is it in case you didn't see it and are curious: https://clojurians.slack.com/archives/C03S1KBA2/p1647809658682999

ah, thanks!

You mentioned you'd like to experiment with xephyr. Did it end up not working?

I'd much rather do it all directly, in one place, and not rely on yet another component in between. So I was trying to exhaust other options.