Fork me on GitHub
#clojure
<
2016-10-17
>
josh.freckleton03:10:29

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

josh.freckleton03:10:22

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

josh.freckleton03:10:04

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

bcbradley04:10:43

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

grounded_sage04:10:35

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

hans04:10:41

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

bcbradley04:10:52

i'm inside a go block

bcbradley04:10:57

would that mess the thread scheduler?

hans05:10:16

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

bfabry05:10:17

@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..))

bcbradley05:10:36

oh yeah thats right xd

bcbradley05:10:43

i hadn't considered using channels like that

bfabry05:10:46

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

hans05:10:17

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

bcbradley05:10:41

because multiple go blocks could be dispatched on a single thread

bfabry05:10:51

@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

hans05:10:55

@bcbradley And that is better exactly why?

hans05:10:40

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.

bcbradley05:10:50

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.

hans05:10:51

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

bcbradley05:10:41

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

bcbradley05:10:54

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

bfabry05:10:24

@bcbradley that shouldn't happen with future

hans05:10:25

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.

bcbradley05:10:11

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

danielstockton05:10:04

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?

bfabry05:10:02

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

danielstockton05:10:57

Useful, thanks 👍

mikera06:10:25

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?

mikera06:10:27

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?"

iku00088806:10:45

@mikera Would refer-clojure+exclude work?

mikera06:10:56

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

bfabry06:10:07

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

mikera06:10:47

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

bfabry06:10:51

ahhhhh backwards compatibility adds a new problem

mikera06:10:23

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

mikera06:10:57

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

bfabry06:10:16

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

iku00088806:10:35

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

bfabry06:10:19

@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

dergutemoritz06:10:34

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

iku00088806:10:05

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

mikera06:10:04

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

mikera06:10:24

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

iku00088807:10:00

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

dergutemoritz07:10:08

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

dergutemoritz07:10:02

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

iku00088808:10:30

@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.

slipset10:10:56

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”}] ?

slipset10:10:51

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

hans10:10:42

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

slipset10:10:09

very true indeed

hans10:10:12

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

sooheon11:10:40

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.

Alex Miller (Clojure team)12:10:12

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

rustam.gilaztdinov13:10:51

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

baptiste-from-paris13:10:30

@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 !

robert-stuttaford13:10:28

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 - https://media.pragprog.com/titles/vmclojeco/data.pdf

baptiste-from-paris13:10:16

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

baptiste-from-paris13:10:59

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

ethangracer13:10:56

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

ethangracer13:10:10

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

ethangracer13:10:49

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

ethangracer13:10:57

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

ethangracer13:10:56

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

ethangracer13:10:56

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)

ethangracer13:10:12

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

meatballs14:10:32

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

robert-stuttaford14:10:30

new lexical scope?

meatballs14:10:37

Yes, but what does that offer in this circumstance?

lvh14:10:12

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

meatballs14:10:16

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

meatballs14:10:23

s/tony/tiny/

lvh14:10:15

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

bcbradley17:10:49

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?

hiredman17:10:28

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

hiredman17:10:42

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

hiredman17:10:53

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

jrheard17:10:51

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

jrheard17:10:22

(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)

dpsutton18:10:18

offhand, i know that cider-nrepl uses agents

mpenet18:10:33

Riemann uses refs, or used to at least

bcbradley19:10:24

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.

ghadi19:10:40

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

ghadi19:10:25

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

bcbradley19:10:38

alright, i just wanted to make sure

ghadi19:10:00

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

hiredman19:10:09

using transients in a go loop is weird

bcbradley19:10:11

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.

hiredman19:10:32

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

bcbradley19:10:12

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)

bcbradley19:10:39

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

ghadi19:10:39

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