Fork me on GitHub

Has anyone ever seen a diffing tool for Clojure/lisp that highlights diffs based on semantic changes, not just whitespace?


that's funny someone mentioned patdiff to me just yesterday 😉


Is anyone using Kerodon for interaction testing Ring apps? It looks very nice.


looks nice indeed. the name and API suggest it's inspired by Capybara


So I haven’t tested this … but maybe somebody already knows the answer: say I want to invoke a Java instance method by String, I could use clojure.lang.Reflector, or I could write a multimethod that dispatches to a set of (.foo x) functions; which would likely be faster?


Java reflection is slow, but if you can keep hold of the java.lang.reflect.Method instance, invoking that will be fast


@joelkuiper: the multi-method approach would be faster, if you know up-front which methods you'll need to call


@joelkuiper: disclaimer: I am not a profiler


hah, I could memoize Reflector


that’s a stupid trick 😛


why are there so many versioning schemes used? Latest Clojure is 1.8.0-alpha4, latest Clojurescript is 1.7.107, latest core.async is 0.1.346.0-17112a-alpha (which is ridiculously long)


I tend to approach versions as mostly meaningless strings with no discernible (partial) ordering for that reason 😛


with that mindset it doesn’t bother me 😉, might as well use git-sha’s for all I care


if one wants to use sha's ok, but these are release versions which carry some meaning. The core.async one is longer than an average safe password


like 2-3 times actually


in the case of core.async I think it’s generated by pinning SNAPSHOT versions in maven


hey, cider users - how to jump to java source from emacs?



M-x cider-jump-to-var


I’m having a problem with ring.mock.request - the header function adds the header I pass to the :headers map, but doesn’t put the header in the request as well. This means I can’t set :remote-addr like this. Is this a bug or am I missing something?


There are specific functions for content-type and content-length that do add to both - is it the case that not all headers should be added to the request map?


Actually, never mind, I just figured out I can use middleware on my handler to do the same thing.


@xeqi: Kerodon is lovely, thanks


@nicola: I think its normally bound . M-.

Pablo Fernandez14:08:32

Is ring multi-threaded?

Pablo Fernandez15:08:35

I have a Clojure web app using ring and compojure and so far I didn’t care about threading because Clojure shields me from it (immutable data for the win) but now I want to share an Java object between requests that is not multi-thread-safe and it’s mutable. How do I shield about two threads using the same one at the same time?


you could wrap the Java object in an atom, and use swap! with a function that does some defensive copying

Pablo Fernandez15:08:39

pbalduino: I could put it in an atom, yes, when would I use swap!?


pupeno: I assumed you would be mutating the Java object inside your ring handler


use swap! when you need to mutate the object, but create a copy first and mutate that, then return that


@pupeno: You can do java locking with (locking obj ...)


pupeno: putting a mutable object inside an atom is not generally safe, since the point of swap! is that it can retry instead of commit if there has been parallel alteration. Nothing about that mechanism prevents your mutable object from being punched repeatedly and in the wrong order.


my advice was to make a defensive copy inside swap!


yes, just making sure that distinction is clear - and the fact that retries will happen


I think locking macro is probably better for this case


thanks to retries, just using a mutable object inside an atom is likely less safe than using it naked would be (unless you have some reasonable copying scheme)


pbostrom: I pick up on this now in particular because we discovered people on my team were kind of cargo culting atoms, and doing mutation and derefs inside swap! operations - leading to things breaking in very weird ways of course


Is there a way to expose something I've imported?


Basically, I want to collect a bunch of namespaces into a single namespace.


though I would seriously reconsider doing things that way


ah, yes, the mandatory disclaimer


heh 😛 I just don't want my routing definitions to worry about how I've decided to split up my handlers.


yeah, import-vars from potemkin will take care of that then


but my complaint about these kinds of schemes is it makes finding things in your code harder (we get used to being able to find defs in the namespaces they belong to after all)


@noisesmith: I agree. And I'm kind of deciding over whether it's going to cause issues or not.


I just feel awkward doing (:require [bans.routes.auth :as auth-routes] [bans.routes.x :as x-routes])


yeah, import-vars will make it easy to construct a top level so consumers don't need to worry about your namespace layout


@pupeno Ring itself is single-threaded, as it turns into a chain of function calls. However, the adapter, usually for Jetty, is multi-threaded, so individual requests will be executing on multiple threads; Jetty defines the thread pool for handling such requests.


I did a bit of work to integrate Ring with core.async ... in practice, it added a lot of complexity and made it much harder to debug, and didn't seem to affect performance in any measurable way.


Ultimately, we stripped the core.async support back out (this was in earlier versions of

Pablo Fernandez16:08:01

hlship: so, the functions that are called by the routes don’t need to be thread safe?


Well, you have to go out of your way in Clojure to not be thread safe.

Pablo Fernandez16:08:54

hlship: I’m using nashorn, it’s not thread safe.


But no, just the opposite; those functions are going to be called by many threads simultaneously.


so if you are, say, invoking methods on non-threadsafe Java objects, you may see some race conditions

Pablo Fernandez16:08:42

But if jetty is creating new threads, then each of those threads should have their own copy of the object.


But if your Ring request handler functions are pure, or semi-pure (a term that roughly translates to "pure, except it hits the database") you should be fine

Pablo Fernandez16:08:10

My problem is that I need to create an object, a scriptengine, and re-use it, but never in two threads at once.


perhaps make the var special (thread-local) so that each thread gets their own instance of it?


just make sure that each thread initializes the thread-local variable is nil, and make its root binding nil...


maybe, maybe that's foolish

Pablo Fernandez16:08:47

Each thread should be using it’s own render-app. Does it make sense?


sure, in that case making the var a dynamic binding makes sense maybe


unless you are using a ring-adaptor that moves a single request between threads


in that case a better solution is a middleware that attaches an exclusive script-engine instance to the request object itself?

Pablo Fernandez16:08:32

a middleware feels like an overkill, but I haven’t found a solution that works yet.


pupeno: middlewares are so easy to write, and they can be very lightweight


(defn attach-script-engine [handler] (fn [request] (handler (assoc-request (get-engine pool))))

Pablo Fernandez16:08:49

noisesmith: ah… but then I need to implement a pool of engines.


well I thought that was a pre-requisite for your plan no matter what


I mean replace that with making a fresh one each time if you prefer

Pablo Fernandez16:08:16

noisesmith: I’m not sure about that yet.

Pablo Fernandez16:08:48

What I am trying to avoid is making a fresh one. That is the problem I’m trying to fix, as they are expensive.


another option (defn attach-script-engine [handler] (fn [request] (handler (assoc request :engine (make-script-engine)))))


sure, OK, so if you can't make fresh ones, and threads can't share them, you need a pool


but I'm suggesting that regardless of those things, a middleware is a lightweight way to provide them concretely to the request handler

Pablo Fernandez16:08:13

noisesmith: not really. Jetty is creating a pool of threads already, each thread needs 1 engine, so, I don’t need a pool.


pupeno: OK if you only use jetty that's that

Pablo Fernandez16:08:47

I just need to create the engines so it follows the semantics of whatever container is running my code.


pupeno: I suggested the other option because some very good servers don't attach a request to a single thread


but you can carry a resource in the request (which led to the middleware suggestion)

Pablo Fernandez16:08:02

What’s the situation in which a server doesn’t attach a request to a single thread?


netty for example, has non-blocking async stuff - great for performance, but the cost is that your request might be passed between threads and/or share a thread with other concurrent requests


so you can't count on the 1-1 thread to request mapping


aleph and http-kit iirc are based on netty

Pablo Fernandez16:08:23

But on each thread there can be only 1 request at any one time.


err, I don't think aleph does use netty actually, but it does break the 1-1 mapping concept


pupeno: depends on what you mean by "at any time" - the thread could swap which request it is working on before the other request has finished


think core.async style parking

Pablo Fernandez16:08:59

I believe that is fine for me.

Pablo Fernandez16:08:22

If I were to use a pool, I can just request it from the pool when I need it, no need to attach it to the request. 1 request will use the script engine once and only once and even if it uses twice, it’s ok if they are different ones. The only thing I have to prevent is the same script engine being used at the same time by two different threads.


http-kit doesn’t use netty


and in aleph, by default, there’s a separate thread pool for requests


so blocking is okay

Pablo Fernandez16:08:56

Would each thread run (defroutes …)


dominicm: I appreciate the vote, but that means that when someone is referencing a var in a namespace, there’s no explicit reference to it anywhere in the namespace


pupeno: yes, when a request comes in, a thread is used off the pool to run the handler


if the handler blocks, it won’t cause things around it to hang


@ztellman: That's true, but it makes it easier for me to just "collect" namespaces. One less place to remember to update, when I modify one of the imported namespaces.


yeah, I can see that


my only consolation is that it’s super easy to roll your own, as evidenced in the issue


@ztellman: Yep. Very easy, although I don't know if I could have got there without the help. Just figured I'd register interest without bumping a dead issue.


again, I appreciate it, I’ll give it some more thought


but my gut feeling is that it’s just a little over the threshold of “too much magic” for me


That's fair enough. Thanks simple_smile

Pablo Fernandez16:08:50

So, if each thread is executing (defroutes …) then here: each thread should automatically get their own js-engine, correct?


Is there a preferred way to say “an infinite lazy seq containing only this object”? (cycle [x])? (repeatedly (constantly x))?


I knew I was missing one. Thanks simple_smile


I never know which is which, repeatedly, repeat and iterate


@pesterhazy: I just think of it like this, repeatedly takes a function (an action) like (repeatedly increment)


you want to "repeatedly increment" something


@bostonaholic: I think iterate would fit that example better simple_smile


depends on the implementation of increment


but, I was just trying to explain how I remember which function of the three take which arguments


- repeatedly call f - repeat the value x - iterate f over x


iterate could be though as a lazy reduce?


What are the benefits and drawbacks of putting :aot :all at the root of your project map in project.clj?


I imagine it would terribly mess with dynamic code reloading at runtime right?


But are there other hidden disadvantages, such as vars not having metadata available at runtime?


one benefit is not needing to run your project via lein


Meaning it produces a jar file?


I don't understand how that can be since it's in the project.clj file which is only seen by Leiningen.


no, creating jars is different. It just means that you have a .class that you can run via java, once you’ve set the classpath


I don't see what the disadvantages are then.


ah, I misread the original question… I was distracted. When I saw “root” I was thinking that you were only talking about doing AOT on the namespace with -main in it


If you’re doing AOT on everything then it’s useful for providing classes to frameworks that need them (since everything is already compiled). It’s also a little bit quicker to start (no parse/compile needed). But the only reason I’ve usually seen is if you’re writing commercial code and you don’t want to be distributing your source code to everyone


Does anyone know how I can figure out the namespace of a file read in with load-script? (


I've tried using (all-ns) before and after, but that all gets anything that's a dep of the file that's been read. (afaict)