This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # aleph (3)
- # announcements (4)
- # beginners (30)
- # boot (296)
- # cider (21)
- # cljsjs (2)
- # cljsrn (18)
- # clojure (124)
- # clojure-poland (23)
- # clojure-russia (4)
- # clojurescript (73)
- # core-async (58)
- # css (3)
- # datomic (31)
- # editors (4)
- # emacs (35)
- # euroclojure (3)
- # hoplon (104)
- # immutant (8)
- # jobs (3)
- # jobs-discuss (1)
- # keechma (1)
- # ldnclj (33)
- # leiningen (5)
- # liberator (1)
- # mount (20)
- # off-topic (2)
- # om (104)
- # onyx (54)
- # parinfer (80)
- # proton (1)
- # re-frame (59)
- # remote-jobs (1)
- # ring-swagger (9)
- # slack-help (15)
- # spacemacs (7)
- # yada (12)
Does anyone have thoughts on an idiomatic approach for converting to/from Scala types from Clojure? I'm writing some clojure api clients against scala and I can't help but feel that it's a huge pain. Right now I'm dispatching by type on some conversion multi methods to convert things like Some, Map, Iterables, etc. to java types which due to Clojure's design, mostly just work. The issue is I constantly have to write functions that thread input/output through these converters. Just dreadful when compared with working with Java even. Any example code or best practice beyond what I described?
more specifically, I'm using scala.collection JavaConverters and JavaConversions. But maybe there's something out there in clojure already that wraps scala well?
I know a dude I work with (@angusiguess) couldn’t find a good way of dealing with Scala. Idk the details tho. He might have something to offer, aside from tales of eldritch horrors, but he won’t be online for a while.
@dmitrig01: nope, but just checked it out. Looks a bit uglier than what I have, but looks useful more going to scala. I think going from scala->clojure is more annoying me, but I'll check this out more and maybe something will help.
> from-scala provides some syntactic sugar on top of Clojure's Java interop support and some utility functions for directly interfacing with Scala libraries from Clojure.
(expect) calls seem to run out of order (running after all other code, especially database-changing code, has run)
It's very difficult to structure the code in a way that you won't be testing against a db that's in a different state than what the code would suggest
Hmm, I’ve only had a cursory glance through the docs but this seems relevant: http://jayfields.com/expectations/interactions.html
it seems like a whole lot of extra work to wrap my many db calls. I don't quite get why it doesn't just run the (expect) at the moment it is reached in my code, because at that moment my test would make sense.
@futuro: I tried compojure, pedestal and I now use yada (I heard that httpkit is in maintenance mode now)
so it gives you routing + some bonuses (views, sessions etc), but no structure, no persistence built in etc
At least not in the traditional RoR sense. It gives you some predefined libs and a structure. There is no upgrade path, no scaffolding, nothing "frameworky".
Hm, ok, I just looked up the wikipedia definition of webframework and I have to take a step back. Sorry.
ok, I that sesnse I agree that it’s bunch of tools taken together with predefined structure
My point is that I think luminus is easier to take apart, change / fit to your needs than maybe RoR
@yogthos: Hi there, sorry to bother you again. I am trying to follow chapter 5 of the book and
is giving me a
clojure (defn encode-transit [message] (let [out (java.io.ByteArrayOutputStream.4096) writer (transit/writer out :json)] (transit/write writer message) (.toString out)))
error. Am I missing something?
bash Exception in thread "main" java.lang.ExceptionInInitializerError at clojure.main.<clinit>(main.java:20) Caused by: java.lang.ClassNotFoundException: java.io.ByteArrayOutputStream.4096, compiling:(guestbook/routes/ws.clj:21:13)
Hello, does anyone know if there is any clojure pattern matching library that supports repeated occurrences of a pattern? I don't think core.match supports them. Something like racket's
... or regex's
(defn find-user-by-name [name] (let [user (find-user-by :name name)] (update-in user [:user_roles] (find-user-roles (:id user)))))
ClassCastException clojure.lang.PersistentList cannot be cast to clojure.lang.IFn clojure.core/apply (core.clj:625)
@dev-hartmann: actually you may want
(update-in user [:user_roles] into (find-user-roles (:id user)))
ClassCastException clojure.lang.LazySeq cannot be cast to clojure.lang.Associative clojure.lang.RT.assoc (RT.java:778)
Does anyone have any opinion/thoughts on pros/cons of doing conversions between clojure, Java, and Scala to/from using multi-methods vs. protocols vs something else? I'm doing some performance critical conversions, but I still need to leave users of my library open to extension which is why I thought of using multi-methods or protocols. Would you expect that for example it would be faster/less overhead to convert a java type to a map with a protocol rather than a multi-method dispatching on type? I figured someone might have hit this, but if not I guess I'll have to profile/inspect what is being generated at runtime... Thanks.
also should note, I don't care about calling via java/scala, this is purely for the clojure users of my code
@hugesandwich: It's probably worth trying to measure it but I would expect type hinted deftypes/reifies to be faster?
@angusiguess: Well, I definitely have type hints all around using protcols and multi-methods as well. What I mean is for example a ToClojure protocol vs. something like scala->clj that is a multi-method. For using actual scala/java classes with things like callbacks, I definitely use reify + protocols + type hints which works well. I'm asking more about the former.
for other usages like calling into java, definitely using reify a bit as mentioned
I haven't tried it, but intuitively I think that the dispatch overhead on protocols should be faster.
If you do benchmark the two approaches I'd be very interested to see the results!
Alright, if I get a chance, will let you know. Probably not today but maybe later in the week. I'm knee deep in writing this, but I know I need to refactor the conversions soon so thought I would ask in case anyone has done something like this before and maybe can tell me I am being totally stupid with both approaches
@dev-hartmann: doesn’t this work for you?
(def roles (lazy-seq [:foo :bar :baz])) (update-in user [:user_roles] into roles)
I’m drawing a blank - what was the lens-like library that Marick was talking about recently?
Is there anything built in that wraps a Java future so I can call a function on it when it returns automatically? I've adapted (stolen) what is in future-call and it works, but I can't help but feel I'm reinventing the wheel a bit. My goal is to return a future that can be manipulated as any future in clojure (IDeref, IBlockingDeref, etc) can and hide the Java library returning the Java future.
Not sure if it would be possible to retrofit existing future functions as they dont belong to any protocol
not so far as I can tell.....I just wrote a simple method that passes in the future instead of creates it
it works just fine, but I keep wondering if this isn't a common problem that is better solved some other way
that's what I am saying, I can't find anything so far that I could easily extend
What's the best way to wrap a java object that implements iterable? I'm reifying a class that wraps a Java class implementing iterable, and I'd like to be able to work with it nicely in clojure, and perhaps transduce the output of the java iterable (java classes) to clojure maps. I know about iterator-seq and simply implementing Iterable and returning the original iterator, but neither really seems to be great. Is there any preferred approach for wrapping a Java iterator to make a nice clojure reified object out of it that plays nice and doesn't require an extra function added to my own protocol? Sorry for all the interop questions today, but not finding good info beyond things I already know.