This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-09
Channels
- # beginners (55)
- # boot (173)
- # clara (3)
- # cljs-dev (10)
- # cljsjs (3)
- # clojars (11)
- # clojure (110)
- # clojure-austin (5)
- # clojure-berlin (13)
- # clojure-chicago (2)
- # clojure-dusseldorf (3)
- # clojure-france (24)
- # clojure-italy (4)
- # clojure-portugal (1)
- # clojure-russia (60)
- # clojure-serbia (8)
- # clojure-spec (150)
- # clojure-uk (129)
- # clojurescript (87)
- # core-logic (1)
- # cursive (75)
- # datavis (1)
- # datomic (75)
- # devcards (4)
- # dirac (17)
- # emacs (50)
- # events (2)
- # hoplon (9)
- # jobs (4)
- # jobs-discuss (37)
- # lein-figwheel (3)
- # luminus (5)
- # off-topic (54)
- # om (9)
- # om-next (5)
- # onyx (10)
- # perun (11)
- # protorepl (11)
- # quil (2)
- # rdf (2)
- # re-frame (14)
- # reagent (58)
- # ring (13)
- # ring-swagger (10)
- # rum (52)
- # spacemacs (8)
- # test-check (10)
- # untangled (17)
- # yada (34)
using pipeline-blocking, do I have reasonable expectation the functions will be started in message order ? more specifically if my xf does calling a network service in normal operation the network calls will start in message order ?
results will come out the order data when in, but pipeline runs your xf in parallel according to the number you give it
I suspect the degree out of out of orderness that can happen is bounded, by n (the parallelism number you pass to pipeline-blocking), but I am not sure
(require '[clojure.core.async :as async])
(def counter (atom 0))
(def to (async/chan))
(def from (async/chan))
(async/pipeline 8 to (map (fn [value] [value (swap! counter inc)])) from)
(async/go
(dotimes [i 1000]
(async/>! from i))
(async/close! from))
(count (for [[x y] (async/<!! (async/into [] to))
:when (not= x y)]
true))
;;=> 980
no proof, but it would appear that the max out of order it gets is n+2, which I think matches other n+2 behaviors pipeline has
the only difference in implementation between pipeline and pipeline-blocking is the use of async/go or async/thread
that issue up above is a result of pipeline-async's "parallelism" being related to the buffering behavior of the pipeline as a whole(n+2), and less directly to the number of "workers" (n)
which relates to what you are asking about, because I suspect the max out of order you will see using pipeline and pipeline-blocking is dependent on the buffering behavior of the pipeline, which is some how 2+n
correct, the threads introduce out of orderness, but the size of the output buffer (which is n) limits how far ahead a thread can get
Last day for ClojureRemote tickets!
Is anyone else having issues deploying to clojars? It just keeps telling me 401 unauthorized but I know I have the proper credentials.
another q: is there a standard variable name for a boolean returning function you might send to another function
Are there any 3d modeling tools written in clojure (or cljs)? Something where I can model in OpenGL, then render it with a ray tracer.
@eslachance if you're still having trouble, pop in to #clojars and we can help
Based on a very quick test I see that using partial
is somewhat faster than using the #()
notation. Anyone can enlighten me on why that would be?
@achesnais Normally #()
is faster, can you post code?
You are right – my initial test was with the time
macro, but using criterium I see #()
is faster. What’s the explanation though?
achesnais: the JIT. Using partial
you only create new instances of existing (generic classes). Since they exist they are already optimized.
when you use #(…)
a new class is defined for the closure. So the first few time you use it you pay for classloading, interpretation, optimization etc. However once all of these are paid for you end up with an optimized specific class vs an optimized generic class.
Also, (credit to Rich for bringing this to my attention the other day). There is a perf difference between #( 3 %) vs (partial 3), due to Clojure compiler inlining
Partial inserts *
as a var, that you have to call through when invoking the function, while #(* ...) gets compiled as #(clojure.lang.Numbers/mul ...) which removes the var overhead.
no, it's more like the compiler can optimize #() better sometimes
Thanks for the detailed answer @U3E46Q1DG and @U07TDTQNL – fascinating stuff!
Maybe because partial returns a variadic function?
Right, but the function it returns is still multiple arity. I thought there might be some overhead to this, it has to dispatch the right one.
Here is the explanation https://clojurians.slack.com/archives/clojure/p1486653231019585?thread_ts=1486630412.019545&cid=C03S1KBA2 and a repl log to support it https://gist.github.com/cgrand/19a4d5606459d7ae43f0da9996f36c2d
Ah I see, thanks.
hi there is clojure.data.xml/parse lazy ??? because i'm trying to load an 400mb large file and in the repl it takes damn long to write it into a variable.
not using the normal api for multimethods
I wrote up a blog post on debugging a memory leak in production (it turns out it was a badly memoized fn): https://techblog.roomkey.com/posts/memory-leak.html
when I log something with clojure/tools.logging
, I see a couple of lines in the console:
Feb 09, 2017 6:09:22 PM my.ns invoke
INFO: my log message
The question is, how to remove the first line?@sineer it's the var-quote
reader macro, equivalent to (var app)
https://clojure.org/reference/reader
So if I understand the use of it in (jetty/-jetty #'app {:port port :join? false}), it means if app is undefined then the fn will be called with a single arg arity correct?
@sineer So let's back up and look at (jetty/-jetty app ...) This will work, but the problem is that if you redefine app it won't show up without a server restart. This is because every use of a var implies a deref of the var ((.deref jetty/-jetty) (.deref app) ...)
However, if you use the var itself, via #'app
that implied deref is disabled, and so you're passing in the direct var itself. Which means that jetty will invoke the var #'app
on every incoming request. So now your changes to #'app
show up without needing a server restart.
It's a way of moving the point of .deref from setup-time to run-time.
Awesome 🙂 Thank you very much! I'm surprized I didn't know about this one yet... very clever!
How to make sure only given keys are in spec? I have (s/def ::good-state (s/keys :req-un [::name ::active-panel]))
and it doesn’t complain when the state also has :whatever true
.
spec does not allow this through using s/keys
— what you can do, if you must, is add an additional predicate to ensure that only the keys you want are in the map. however, the question to ask is, what does it hurt, if :whatever
is present in the map?
spec says, “validate what is there”, not “validate what is there, and ensure that nothing else is there"
@joshjones, it doens’t hurt, I’m just exploring what can be done
a simple example to ensure that the map has only 1 key:
(s/def ::a string?)
(s/def ::mymap (s/and (s/keys :req [::a])
#(= 1 (count (keys %)))))
(s/explain ::mymap {::a "abc" ::b 2})
;; val: #:sandbox.spec{:a "abc", :b 2} fails spec: :sandbox.spec/mymap predicate: (= 1 (count (keys %)))
so, you can use the additional custom predicate to perform whatever test you want on the given map
@joshjones, got it, thanks
@negaduck The idea about maps in general is that they are open. Leaving the possibility to add what you need and every function picks what it needs
on the second thought, it can hurt when there is a typo in code that updates a key, e.g., in re-frame event handler
:req-un
would ensure that you have both :active-panel
and :hmoe-pane
— what is the specific case that is problematic?
that is one solution, as is the one above, but I don’t think you’ve given a problem that this solves yet?
specifically, when does the presence of a key in a map present a problem that ignoring it won’t solve?
joshjones,
(re-frame/reg-event-db
:set-active-panel
[check-spec-interceptor]
(fn [db [_ active-panel]]
(assoc db :actiev-pneal active-panel)))
so, it feels dirty because it shouldn’t be there, but no one will ever know .. right?
is there something more that spec should be checking about the :active-panel key itself that would inform you that it should have been set differently? (sorry, not a re-frame guy)
What if a man, says something deep in the woods and no one can hear him. Is he still wrong?
Weird stuff: I'm catching TimeoutException
, but I get uncatched CheckedOperationTimeoutException
in logs. This one subclasses TimeoutException
. I have no idea what is going on here, but maybe someone can enlighten me? Should catching parent exception type catch all children?
yeah, catching a superclass should catch all subclasses, so you should check to see if the exception is actually being thrown where you think it is
joshjones, yes, here spec checks if the :active-panel
is exactly one of two options: (s/def ::active-panel #{:home-panel :about-panel})
, this is straightforward.
I think the question here is not, if the map contains a key you did not expect. The question is more or less, if there is a bug in your code that adds this key and the value. So it could be useful as a measure to find a very rare species of bugs.
Is there any reference to the function that clojure uses to look up reader literals? I have a need to do it dynamically, I've implemented something that follows the docstring, but wanted to know if I could kill the work altogether.
so the usual possibilities, the exception isn't being thrown where you think it is, or it is being caught before it gets to your handler and logged
why after expansion it tries to use current-namespace/any?
instead of cljs.core/any?
here: (macro whatever [] (any? 1))
?