Fork me on GitHub

On the jvm methods aren't functions, they can't exist without some object owning them; on the other hand fields on a class hold values that can stand alone.


I like the . / .- distinction and it would have been nice if it were invented for jvm clojure


noisesmith: it does exist in jvm clojure


I meant if it had been invented for the jvm first, and had been mandatory rather than optional...


Yeah, it wouldn't have been so annoying I wasn't already used to it 🙂 But in cljs it's a requirement, right? Because you can't otherwise differentiate between the two?


because in js you can have a method and a field with the same name


so you need some way to differentiate


I'm trying to figure out how to use update-in for a recursive atom of blurbs and comments( comments can be recursive..)


@sova so like (atom {:resp1 {:content "woot!"} :resp2 {:content "I disagree..." :resp1 {:content "why?"}}}) ...or something like that?


and it can be potentially infinitely deep?


If so, you might want to check out specter, by @nathanmarz


Question about interface implementations: Why do we have to include this as the first argument to every implemnted method?


@matan, in a defrecord you mean?


ummm, in reify actually


Example code:


(def driver
  "a driver for our test bot"
  (reify ApiInterface
    (sendToBot [this message]
      (println "sample driver sending message" message))
    (receiveFromBot [this message]
      (println "message received from bot" message)


well it's Java, i.e. OOP, after all


so the messages are sent to an object, and Clojure chooses to make this an explicit argument to fns (like python, but unlike javascript or java)


but a simple macro could have added the this


rather than user code being responsible for including it


that would have introduced a special symbol, which is not very lisp-y


not sure I get it


in clojure you almost always choose your own binding names


why does Clojure choose to make this an explicit argument


what are the benefits of that?


I can't speak for the language designer


but one benefit is that the scoping rules are obvious


(compare javascript, with unclear scoping!)


Sure but how would you possibly leverage that explicit argument in user code, as a developer?


how do you mean?


Without some user leverage, this is pure boilerplate, unless a developer can leverage this argument in some way to get some behavior they can't get without it being explicit in the code


Can you think of any leverage?


the leverage is that you can access the object 🙂


Right, doh


btw feel free to replace this with _ if you don't need it


nice idea


thanks guys!


you're welcome 🙂


I like this forum


hey all, what’s the most common means of handling errors with -> and ->>?


i’d like my pipelines to stop execting when one of the functions fails


should I be throwing catching/exceptions?


I am curious who is against columnar alignment in let statements, require statements, declarations,....Is it only due to manual fixing all lines after changes?


Yes, it’s that it too much additional work/thought for the benefits that i see.


thanks @sveri I’ll take a look


Using the expectations library, how can I wrap two expectations in a let where I perform a request only one time? E.g.

(e/expect #"^text/html" (e/in (content-type (home-httpkit))))
(e/expect #"<body" (get (home-httpkit) :body))
I want something like (let [resp (home-httpkit)] ...), but not want to perform the side effect at the top level


@triss some-> and some->> can come in handy as well,


The macro clojure.spec/keys and clojure.spec/keys* expects a seq of keys as the value of its named arguments :req and :opt. I want to use the same list of keys for two different specs, one using keys and one using keys*. But the macros get passed the quoted symbol for the variable and not the value of it. Is it possible to unpack the value pointed to by a symbol at read time like the common lisp #. syntax?


@schmee I knew I’d seen something like that before! brilliant thanks


@rovanion I think you’ll have better luck with that question in #clojure-spec


I've gone ahead and asked in there too. But the question itself is Clojure generic even though the specific macro is from spec.


@rovanion you can use eval or write a macro (only the latter with cljs I think)


but I know: yuk


(let [keys [...]] (eval `(s/def ::foo (s/keys :req-un ~keys))))


if we ever get spec form conforming we could manipulate actual data and unform the specs at runtime


but it's taking dust in JIRA atm (CLJ-2112)


I seem to recall alex saying that that ticket is definitely going to happen


is it's not if but when :)


that's what I meant 🙂


Thank you mpenet, even though it's ugly it actually works unlike all I've tried thus far.


it might take a while or be done tomorrow, but I wouldn't hold my breath


Want to write the SO answer and get those sweet imaginary internet points or should I fill it out?


feel free to do it, I don't really do SO


Cool. Writing issues down help me reason about them. And when I'm already doing that I might as well post it to SO.


is it possible to destructure based on the value of an element e.g. (let [{[{ v "a" "val" 1}] :y} {"x" 1 :y [{"a" 3 "val" 2} {"a" 2 "val" 1}]}] (println v)) ;; need to have the value of v -> 2


(let [x {:a 1 :b 1}]
  (match [x]
    [{:a _ :b 2}] :a0
    [{:a 1 :b 1}] :a1
    [{:c 3 :d _ :e 4}] :a2
    :else nil))
;=> :a1


it is not possible without core.match, isn't it?


(defn my-get [x k] (let [{v k} x] v)) @h.elmougy ??


@h.elmougy no pattern matching out of the box in clojure, you can always write a cascade of cond to get there (that's basically what core.match does)


Anyone know how to get the size (in bytes) of an object?


I want to be able to log how much data is being processed by a pipeline I'm working on


Would (count (byte-array x)) give me what I need? And is it in any way efficient?


Or am I better looking at java for a solution here?


hey guys, I keep getting the following error

Uberjar aborting because jar failed: Could not resolve dependencies
when trying to
lein uberjar
. I'm trying to build within a container for a CI system. There may be an issue with auth, is it possible to
:mirrors {
    "central" {
      :name "Nexus-Central"
      :url "https://../repository/maven-public/"
      :repo-manager true }
    #"clojars" {
      :name "Nexus-Clojars"
      :url "https://.../repository/clojars/"
      :repo-manager true }}
is it possible to add username and password of nexus within this block? or any other suggestions?


Hey guys, i'm trying to use yesql, but it only accepts a 'db-spec' when connecting to my database. However, I want to use a connection uri string, and there doesn't appear to be a way to turn a connection uri string into a db-spec map. Any idea on how to go about converting a connection uri string into a db-spec map?


{:connection-uri "postgresql://"}


@pesterhazy that seems to work, but i'm running into unrelated issues. Thanks!


Anyone know what happened to (seems like no activity after 2015) -- the idea of "bringing smalltalk liveness to clojure" seems brilliant


Hello all, I'm curious about using the functionality of a timer in clojure. In my app I have several go-loops that run forever validating that their database connections can still return data. When the test fails the old connection is closed and a new one is opened. I didn't find any canonical example of how to do this in clojure. Instead of just using Java's scheduledExecutorService I rolled my own using the go-loop, timeout and a channel. Things seemed ok during development on my local box, but on moving this out to AWS and having the DB on a different machine than my clojure service I find that my periodic-task logic fails to continue after a few days. So far I haven't been able to replicate these failure on my local dev box. Is there a suggested way of doing this type of thing in Clojure or do most just use something like Java's scheduledExecutorService?


@dealy I’v efound scheduledExecutorService reliable and easy to use, but there are other options - eg. quasar


yea, quasar/pulsar does look pretty interesting, but it would be a bit much to bring in just for this type of task


@dealy any particular reason you don’t just want to use a proper connection pool like hikariCP, bonecp, or c3p0?


There is some advanced JDBC features I'm using that aren't supported well in hikariCP which is what I use for regular DB connections, so I've found that I have to manage this stuff on my own for JDBC driver (impossibl) that I'm using so I can make use of Postgres notifications.


That’s a good reason not to use a connection pool 🙂


Do you get any errors with your core.async version, or does it just fail to run eventually? And when I’ve done things like this in the past, I’ve generally just run a thread in daemon mode with a function that calls Thread/sleep for the required period of time (a la ). Which is probably not as elegant or as nice as just using ScheduledExecutorService, but as generally been reliable for me in the rare cases when I need something like this


no errors, its been a real pain trying to debug this. Since it just stops working after a few days (not all of them of course) it feels like either something is blocking or some resource is being exhausted.


core.async, since it’s macro-magic™, tends to have some edge cases where things get wonky, especially around resource starvation. Therefore, I tend to only use it when actually doing async I/O, and instead using threadpools/executorservice/raw threads for anything that I need to have reliably running in the background at (semi-)regular intervals


at least then what’s happening is obvious and generally debugabble (ok, jstack, what’s the status of thread X?)


pulsar is going to have similar problems of not being able to figure out what’s going wrong if it randomly stops working


hmm, ok that is interesting to hear. My implementation doesn't make any use of thread/sleep or future. Just a go loop that creates a new channel via timeout on each iteration. If there is a possibility of odd behavior with core.async then that could explain why things are so weird here.


sure - for example you could leak core.async threads via doing blocking ops in go blocks that don’t finish


eventually nothing at all would run


(nothing in go blocks that is)


or it could be that only your specific go block doing the jdbc stuff gets tied up somehow, so that other go blocks are still able to run…just there’s 1 less available thread in the pool.


In general core.async is great, and if you understand it well enough you can avoid pitfalls like this, but it’s not really meant to be a scheduling service.


(that’s not to say you can’t use it as one: )


is there any reason to think that I could be exhausting something by creating a new channel every few seconds? Nothing ever holds a reference to these channels. I suppose it is possible that there is eventually some case where my call to postgres doesn't return and then that would block the thread in the go block. Ok, I think you've convinced me to just dump this idea and use the scheduledExecutorService.


I'll take a look at chime


for the note: I actually recommend just using scheduledExecutorService, not chime. Just pointing out that it can be done


since your calls to postgres are likely blocking anyways, core.async is not really a great fit for this, and chime works on top of core.async like what you've been trying to solve


certainly not a solution, but until you find one, can you just restart the service every hour? Might clear out any issues that are building up in the core.async process.


Sometimes the sledgehammer is appropriate. I hope that I can get my system working without having to use one though


^^^ I have sadly done this 😢 . Once had a legacy service that somehow developed a bug that caused it to randomly freeze up every once in a while. It wasn’t in active development, but was critical for the company’s data…so instead of fixing it, we ended up just writing a job on jenkins that ssh’d into the machine, kill -9 the java process which allowed the supervisor to restart it…


A year or two later, the service stopped freezing up anymore…we left the jenkins job anyways because I stopped trusting it


Not one of my proudest moments as an engineer 😄


Probably not the best practice in Clojure, but Erlang embraces failure, right? Might not be a bad idea to try for both goals, correctness and robustness in the case of failure.


Even if you don’t use an ExecutorService, I think this would be simpler with a thread instead of core.async without losing capability. Thread/sleep, ensure connection, repeat. For bonus points have something else that kickstarts that one if it is no longer running. You have a top level handle to the process itself, so you can always see what its specific status is, even see it’s current stack.