This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-17
Channels
- # alda (5)
- # bangalore-clj (1)
- # beginners (9)
- # bigdata (1)
- # boot (51)
- # carry (1)
- # cider (9)
- # cljs-dev (22)
- # clojars (39)
- # clojure (118)
- # clojure-brasil (1)
- # clojure-czech (8)
- # clojure-france (2)
- # clojure-italy (5)
- # clojure-korea (9)
- # clojure-russia (9)
- # clojure-spec (17)
- # clojure-uk (42)
- # clojurescript (48)
- # core-async (1)
- # emacs (3)
- # figwheel (1)
- # funcool (3)
- # hoplon (39)
- # klipse (51)
- # lein-figwheel (4)
- # leiningen (2)
- # luminus (5)
- # off-topic (245)
- # om (18)
- # onyx (19)
- # parinfer (1)
- # pedestal (18)
- # re-frame (47)
- # reagent (19)
- # ring-swagger (1)
- # specter (18)
- # untangled (93)
- # vim (8)
- # yada (56)
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?
@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)) (..do stuff..))
@hans @bcbradley using Thread/sleep will tie up a thread from the thread pool. not the best practice but probably ok
@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
@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
in your own code, use refer-clojure https://clojuredocs.org/clojure.core/refer-clojure
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 amazingly, I answered this exact question for daniel in the message directly above yours
If I could just supress the warning that would be fine, but can't find a way to do this
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
@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.
Sure it was this file: https://github.com/mikera/clojure-utils/blob/develop/src/main/clojure/mikera/cljutils/find.clj
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”}]
?
@slipset each key can only occur in a map once. your requirements are not quite right, and the solution does not match them either 🙂
What is the correct way to import this class (https://spark.apache.org/docs/1.4.0/api/java/org/apache/spark/ml/feature/OneHotEncoder.html) in a clojure project? I’m not sure what to put in the project dependencies vector.
@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?
glad you’re finding it useful
Clojure Applied
btw, that Putting it All Together section is one of the excerpts on the site - https://media.pragprog.com/titles/vmclojeco/data.pdf
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
because every one of the none items satisfies the condition
same as (and)
I don’t understand, there are no items to satisfy the condition in the first place
it’s a useful identity property
how so?
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
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.
specifically, note the section on “The empty set” and vacuous truth
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? https://github.com/clojure/clojure/commit/2ac93197e356af3c826ca895b5a538ad08c5715a
new lexical scope?
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?
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)
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
but i think there were some changes to transients around clojure 1.8 for this purpose... check changelog?
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
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.
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