Fork me on GitHub

whats a good data visualization library for clojure? I've looked around and the main one that surfaced, C2, says it's deprecated, and it looks abandoned


(doesn't have to be production-ready, just simple, and I'd just like some simple line graphs, and such)


oo, I just stumbled across this, and it seems great:


I need to asynchronously execute a function precisely at 2 seconds from now, how do i do this?


Does anyone know where I can get private tuition with Clojure?


@bcbradley (future (Thread/sleep 2000) (f)) maybe?


i'm inside a go block


would that mess the thread scheduler?


@bcbradley what do you mean by "mess with"?


@bcbradley without a realtime OS "precisely" isn't going to be possibly, but you'll get "pretty bloody close" using core.async (go (<! (timeout 2000)) ( stuff..))


oh yeah thats right xd


i hadn't considered using channels like that


@hans @bcbradley using Thread/sleep will tie up a thread from the thread pool. not the best practice but probably ok


@bfabry Why is it no "best practice" to use threads?


because multiple go blocks could be dispatched on a single thread


@hans using threads is fine, tying up threads in an OS sleep can cause unforeseen issues if you run out of JVM threads or you run out of core.async thread pool threads


@bcbradley And that is better exactly why?


It certainly all depends on context. If there is a million activities going on, core.async may be the way to go. If it's just thousands, threads are just fine.


no what i'm saying is that go blocks are serviced by a pool of java threads. If you park a go block, the thread it is running on won't be blocked, it will just start executing another go block if any are available. If you were to tell the thread to sleep within a go block, the thread will sleep-- which essentially "puts to sleep" any other go block being serviced by that thread at that time. That could end up being a visible and unwanted side effect.


On the other hand, if you're already dealing with core.async, then using @bfabry's solution will just fit in fine, I agree.


for instance, it could put your "user interface button go block" to sleep for a couple seconds


then the user will click like mad on "ok" or "cancel" and nothing will happen


@bcbradley that shouldn't happen with future


Right. If you're using core.async in the first place, then not using it would not be the right thing. I'm not always using core.async because I find threads to be very sufficient for many purposes.


you have to keep your mind focused on the execution model for core async if you intend to "mix" it with more basic thread level ops


How should one deal with warnings such as "WARNING: bytes? already refers to: #'clojure.core/bytes? in namespace", especially when they come from third party libraries?


@danielstockton if they come from a third party library I think you can only really file a bug


Useful, thanks 👍


Hi all, Clojure 1.9 defines indexed? in core. This clashes with a function I already have in one of my libraries. Is there a sane way to handle this case that avoids warnings and compatibility issues?


A) doing nothing, I get a warning "WARNING: indexed? already refers to: #'clojure.core/indexed? in namespace: mikera.cljutils.find, being replaced by: #'mikera.cljutils.find/indexed?"


@mikera Would refer-clojure+exclude work?


B) (:refer-clojure :exclude [indexed?]) breaks in 1.8.0. Not backwards compatible


@mikera amazingly, I answered this exact question for daniel in the message directly above yours


refer-clojure doesn't help me as I need to maintain 1.8.0 compatibility....


ahhhhh backwards compatibility adds a new problem


If I could just supress the warning that would be fine, but can't find a way to do this


Or maybe some "define if not already defined" magic?


I'm guessing you'll be reduced to doing something annoying, like conditional compilation of that line in the require, or yeah, defonce somewhere


Due to the lack of my experience, I am curious how1.8 break by adding the exclusion. Would you mind elaborating?


@iku000888 you probably can't :exclude a symbol that's not def'd. @mikera another option would be to use the :only version of :refer-clojure and pull in all the core vars you need for that ns


Putting (ns-unmap *ns* 'indexed?) before the definition could work, too


@bfabry my repl does not complain when I stick a random symbol in the ns macro.


@iku000888 try (:refer-clojure :exclude [indexed?]) in your ns macro in 1.8.0. It throws a compilation error (in my setup at least)


@dergutemoritz seems ugly, but may well be the option I go with since it also seems most robust to the different configurations..... thanks!


@mikera Tried it in a plain lein repl (clojure ver 1.8) and it does not complain. Am curious what could be different.


Yeah, feels a bit too imperative 🙂 Then again, namespaces in Clojure are these mutable things, so why not mutate them, hehe. Glad it helped!


Oops, that arrow button doesn't mean "reply" I guess 😉


@mikera Wouldyou mind sharing which library/setup exlude fails? (Assuming it is publicly available for viewing). Just really really curious what is the cause of the difference.


So given a map of {1 “foo” 2 “bar” 3 “baz”} what’s the best way to end up with [{:ts 1 :val “foo”}{ :ts 2 :val “bar”}{ :ts 3 :val “baz”}] ?


(map (fn [[k v]] {:ts k :val: v}) my-map) would be one such way


@slipset each key can only occur in a map once. your requirements are not quite right, and the solution does not match them either 🙂


very true indeed


if that is what you want, mapv would be more like it.


What is the correct way to import this class ( in a clojure project? I’m not sure what to put in the project dependencies vector.

Alex Miller (Clojure team)12:10:12

@mikera refer-clojure exclude should not error on an unknown var


Hello, guys! Anyone used parkour library for writing MR job on Hadoop cluster?


@alexmiller I bought your book as you suggested few days ago. Really interesting so far. By the way you should definitely put the 4 parts of Putting It All Together p55 on the clojure website !


Clojure in Action?

Alex Miller (Clojure team)13:10:29

glad you’re finding it useful

Alex Miller (Clojure team)13:10:36

btw, that Putting it All Together section is one of the excerpts on the site -


great then ! did not find it when I bought the book


between clojure.spec would have replace schema in you book right (again I am a newbie)


does anyone know why every? returns true if the collection is nil?


seems to me like it should return false given that there is nothing to check

Alex Miller (Clojure team)13:10:14

because every one of the none items satisfies the condition


I don’t understand, there are no items to satisfy the condition in the first place

Alex Miller (Clojure team)13:10:35

it’s a useful identity property


essentially what I’m looking to do is to do an every? check on a collection that may or may not exist, and if it doesn’t exist, I want it to return false. I could do a check to see if the collection is empty before passing it to the function, just seems bizarre to me


curious to hear more about how it works as an identity property

Alex Miller (Clojure team)13:10:46

it all comes out of roots in logic, not sure that I can adequately explain that succinctly


fair enough, I can see the pure logical reasoning side… “all of the none items”. thanks.

Alex Miller (Clojure team)13:10:37

specifically, note the section on “The empty set” and vacuous truth

Alex Miller (Clojure team)13:10:27

contrast with existential quantification ("there exists”) which is false for the empty set (in Clojure this maps to (or) or a call to some)


yeah, guess it just isn’t what I would expect for a general purpose language, though given the nature of functional programming it does make sense


I was looking at what defrecord expands into and found it curious that it's all wrapped in a let with no bindings and not a do. I believe I found the commit pertaining to this change (linked), but can anyone offer insight beyond the commit message?


new lexical scope?


Yes, but what does that offer in this circumstance?


ethannavis: FWIW, this is exactly how Python works: all([]), any([]) == True, False


lvh: tony difference: he was (at least initially) asking about nil, not empty collections.




sure; but the idea is the same, and Python doesn’t attach any seq/coll/whatever semantics to None


I have a situation where I am writing a function that kicks off two go-loop blocks inside of the body of a let. In the binding is some state. One go block is responsible for reading this state, the other responsible for writing. Of course it seems like chans might be a good approach here, but I've also considered other approaches, like action + agent, transaction + ref, and swap + atoms. I can be certain that there will be exactly one writer and exactly one reader at a time. How would you do it?


you should not run go loops that don't read/write to any channels


go blocks are sort of cooperatively scheduled, and read/writing to a channel is sort of yield


channels are not really state constructs, they are coordination points and value conveyors


@bcbradley - fwiw i haven’t ever seen any usage of agents and refs in the wild


(context: i’ve been using clojure for hobby projects since 2011, never used it in production, read random clojure source on github for fun on occasion, am often wrong)


offhand, i know that cider-nrepl uses agents


Riemann uses refs, or used to at least


When a go block or go loop is dispatched, is it guaranteed that for its lifetime it will belong to a single thread? If reading or writing on a chan causes it to park, when it resumes, will it resume on the same thread it was running on before the park? Basically I want to know if it is ok to use transients in the binding of a go-loop.


no it is not @bcbradley -- that's the whole point


the go macro shreds your code into little pieces, and there is no guarantee where the pieces resume


alright, i just wanted to make sure


but i think there were some changes to transients around clojure 1.8 for this purpose... check changelog?


using transients in a go loop is weird


i know it would be possible to associate the pieces to specific threads in the thread pool and maintain that association across parking / unparking if the scheduler were designed to prioritize that above submitting pending work to any available thread.


transients are a performance optimization, the performance optimization for go loops is to use a thread, not a go loop


I guess it makes more sense from a throughput point of view to not have that sort of priority in the scheduler, but i suppose it does make very specific use cases a bit slower (those which could leverage transients in the prior case)


given that core.async is a general purpose library i'm not surprised, but just wanted to make sure


pieces of a go block don't run concurrently... what you're suggesting is some sort of thread affinity. I don't think that is possible

Alex Miller (Clojure team)19:10:28

it is ok to use transients in a go block. transients must be used on no more than a single thread at a time, but go blocks will never be running on more than one thread. the thread checks were relaxed in clojure 1.7 to allow this.

Alex Miller (Clojure team)19:10:59

and go block executions are multiplexed over threads in a thread pool so it is likely that a go block will be assigned to more than one thread in the pool over the life of the block