This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-07-16
Channels
- # aleph (2)
- # announcements (1)
- # beginners (162)
- # calva (16)
- # cider (37)
- # cljdoc (9)
- # cljs-dev (2)
- # cljsrn (3)
- # clojure (86)
- # clojure-dev (17)
- # clojure-europe (3)
- # clojure-houston (1)
- # clojure-italy (6)
- # clojure-nl (3)
- # clojure-spec (10)
- # clojure-uk (20)
- # clojuredesign-podcast (15)
- # clojurescript (7)
- # data-science (14)
- # datascript (1)
- # datomic (5)
- # emacs (8)
- # figwheel-main (8)
- # fulcro (25)
- # graalvm (1)
- # jobs (10)
- # jobs-discuss (4)
- # keechma (14)
- # leiningen (2)
- # off-topic (31)
- # onyx (1)
- # other-languages (4)
- # pathom (4)
- # pedestal (1)
- # re-frame (20)
- # remote-jobs (4)
- # shadow-cljs (25)
- # sql (6)
- # tools-deps (15)
- # vim (18)
- # xtdb (9)
I have this for loop causing a java.io.IOException: File name too long
exception when running lein uberjar
any way to get around this? I think I could probably create the combinations I need another way however I'd like to understand this a little more. for
is a macro and it seems to be creating some long symbol names when expanding this deeply nested for loop.
my namespace is also 39 characters long which also be contributing to this error
I suspect you are hitting this reported issue: https://clojure.atlassian.net/browse/CLJ-1852
Internally generated function names with for
get longer as the number of nested loops in the for
increases, and you have quite a few there.
As far as workarounds go, one would be to use a library like math.combinatorics to generate all of the combinations in a flat list, and iterate through those.
A really quick thing to try would be to put the values of min
and time-delim
into a let
surrounding that for
, since they never change.
@andy.fingerhut Thanks for that. Good idea with the let block, for the time being that will work nicely. Cheers
well (-> m1 :cells [1 1]})
gives you {:north :foo ...}
Once you get to any map, (key some-map)
gives you a sequence of only its keys, and (vals some-map)
a sequence of only its values.
Can you say a little more in that question to help me understand what you are asking?
Oh, if you are asking me whether I should have said (keys some-map)
, then yes, I should have.
I have never done this before, but just tried out (:require [clojure.pprint :as foo.bar])
followed by (foo.bar/pprint ...)
and it seemed to work.
I don't know of any way to globally make foo
and alias for the clojure
part of clojure.pprint
simultaneously with clojure.java.browse
, etc. The :as
method lets you do it one namespace at a time.
@andy.fingerhut yup. i need making foo referring to clojure.
It does not make it cluttered, it makes it clearer at a glance, I suggest readjusting your esthetic sensibilities to accept it
e.g., is the naming be like, for some.package.namespace be referred as sp.namespace? or sp.n? or ?
We have adopted https://stuartsierra.com/2015/05/10/clojure-namespace-aliases team-wide at work (even having a private linter for it) and haven't looked back so far
How we view the id/name is largely a personal preference right? It can make it more clear or it can make it more cluttered. By aliasing at all we admit that the full name is undesirable to work with in context, but the cutoff is always arbitrary and usually just a convention
[clojure.spec.alpha :as s]
Is "ok" for spec, but not for some other lib, there you should use the full name!
I'm hopeful that in the future will have ways to easily toggle between views without having to beat our head against the wall trying to deiced which is best.but yea, for the time being. What hired and emccue said 🙂
Idk if this is the right place to ask but could I trouble someone to review my code? https://github.com/brunoV/throttler/pull/12 The libraries creator isn't active anymore due to health reasons and I'm not terribly proficient with clojure or Java.
a fundamental misconception I see right away: calling timeout in core.async does not use a thread
the premise of go blocks is to have green threads that are lightweight, and using <!
to access a timeout does not sleep any thread - it creates a callback using a timer
Er, I thought this was creating a thread https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/timers.clj#L17
it's shared by all timeouts - but it is a single thread
I might have been misreading though - it seems like this is more about the timer accuracy
Yeah, the original author seemed to prefer to reuse what was already available so I feel bad using more resources
I know this is shared with the original, but taking the reciprocal of rate-ns in chan-throttler* is counterintuitive
instead of calling double
in your sleep time calculation, you could replace :nanosecond 1
with :nanosecond 1.0
in unit->ns
I think the doc needs fixing - currently it claims no new threads are created (mostly true), your edit means each throttled thread uses the executor thread pool (almost true but less so)
because they will be blocked trying to write to a channel that isn't being read from (unless the rate limited function is being called)
isn't the dropping buffer helpful there?
it means a max of buffer-size threads are being wasted
(not ideal but better)
you could get rid of threads/core.async etc all together and just keep an atom and track the time
also using put! instead of >!! might be an improvement
I assumed the newSingleThreadScheduledExecutor
bit meant that it would create a pool of 1 thread.
oh - and blocking that thread until something tries to execute would be fine for the internal logic anyway
but that also means if you have two throttled functions a and b, a is halted altogether if b doesn't get called
and visa versa
since you share one scheduler between all throttled functions, and the >!! doesn't return until someone tries to execute a function
I guess if your buffer sizes are all > than the sum total of throttled functions you're OK - but that is very brittle and weird
maybe I still have this wrong...
no, you're right, with the dropping buffer you just get lag time introduced by the number of throttled channels being used (potentially), but it won't lock up
you could do something like
(let [max-tokens 10
token-rate 100
x (atom {:tokens 0 :last-tokens (System/currentTimeMillis)})]
(fn [f arg]
(loop []
(let [{:keys [tokens last-tokens] :as m} @x
now (System/currentTimeMillis)]
(if (pos? tokens)
(if (compare-and-set! x m (assoc m :tokens (dec tokens)))
(f arg)
(recur))
(if (>= (- now last-tokens) token-rate)
(do
(compare-and-set! x m (assoc m :tokens (min max-tokens (+ tokens (/ (- now last-tokens) r))) :last-tokens now))
(recur))
(do
(Thread/sleep token-rate)
(recur))))))))
with that code you don't have other threads managing the buckets and tokens, and tokens aren't pointers kept around in a channel's buffer
I hadn't really looked at the rest of the library, I guess it doesn't just throttle function calls
shrug blocking on a channel that yields a value in some amount of time is the same thing
Is it? I was under the impression that other things could be going on while waiting for a channel but thread/sleep was like a pause-the-world button
it is different inside a go block using >! and <!, but the function call throttling code is not in a go block and using >!! and <!! which block the thread
there is a #code-reviews channel also
doesn't hurt to leave it
I was thinking about formatting data structures and came up with this idea:
{:fx/type :stage
:showing true
:always-on-top true
:style :transparent
:scene
{:fx/type :scene
:fill :transparent
:stylesheets
#{"styles.css"}
:root
{:fx/type :v-box
:children
[{:fx/type :label
:effect
{:fx/type :drop-shadow
:radius 1
:offset-y 2}
:tooltip
{:fx/type :tooltip
:text "I am a tooltip!"}
:text "Hi! What's your name?"}
{:fx/type :text-field}]}}}
What do you think?If you are talking about the method of breaking up into lines and inserting white space, then I don't have the corresponding clojure.pprint/pprint output at the tip of my brain -- is your idea significantly different than what it does?
corresponding pprint output:
{:fx/type :stage,
:showing true,
:always-on-top true,
:style :transparent,
:scene
{:fx/type :scene,
:fill :transparent,
:stylesheets #{"styles.css"},
:root
{:fx/type :v-box,
:children
[{:fx/type :label,
:effect {:fx/type :drop-shadow, :radius 1, :offset-y 2},
:tooltip {:fx/type :tooltip, :text "I am a tooltip!"},
:text "Hi! What's your name?"}
#:fx{:type :text-field}]}}}
@vlaaad I find your first example a bit misleading to read since indentation to me implied substructure so I find it odd to read keys with their value indented when it isn't nested. If you see what I mean?
And I guess my first question would be "why format data differently from code?"
But your suggested format has more horizontal space since it indents more that pprint would...?