This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-08
Channels
- # aleph (2)
- # aws (1)
- # beginners (172)
- # boot (15)
- # cider (17)
- # clara (7)
- # cljs-dev (22)
- # cljsrn (12)
- # clojars (3)
- # clojure (110)
- # clojure-dev (5)
- # clojure-italy (13)
- # clojure-sanfrancisco (5)
- # clojure-spec (3)
- # clojure-uk (31)
- # clojurescript (110)
- # community-development (2)
- # cursive (16)
- # datomic (19)
- # docs (4)
- # emacs (49)
- # fulcro (24)
- # jobs (5)
- # keechma (2)
- # lein-figwheel (41)
- # leiningen (10)
- # luminus (4)
- # lumo (24)
- # mount (24)
- # numerical-computing (1)
- # off-topic (16)
- # om (4)
- # onyx (6)
- # parinfer (9)
- # planck (8)
- # re-frame (7)
- # reagent (6)
- # shadow-cljs (125)
- # sql (5)
- # test-check (9)
- # unrepl (6)
- # yada (5)
You know how you can keep a go-loop
from looping without error? Easy. Don't include a recur
statement.
anyone here building custom runtimes with jlink/Java 9 and Clojure?
I've only seen this so far https://www.deps.co/blog/how-to-upgrade-clojure-projects-to-use-java-9/
is Datomic Cloud data stored encrypted ?
a cute way to do (fn [a b] b)
is (comp second vector)
- probably not a good way to do it, mind you
clever, but %& isn’t associative
#((vec %&) 1) doesn’t have the same catchy ring to it
I like #(identity %2) for intent :)
The REPL hasn't been weekly for a while now and that makes me sad. I used to be very excited for the next issue every week :white_frowning_face:
the best thing a clojure dev could find in its inbox 🙂
@joelsanchez sorry 😐 work has been pretty busy plus holidays but that’s winding down now
don't feel pressured, you're doing it for free after all, just wanted to say I'd love to have it back
No worries no pressure :)
@sammy.castaneda90 the whole site is on github if you can find the code or markup with that link
@sammy.castaneda90 I just tried to find it - where is the tryclj link?
http://4clojure.com -> click on REPL
in the navigation bar
@sammy.castaneda90 so this would be the line to change to fix this https://github.com/4clojure/4clojure/blob/develop/src/foreclojure/template.clj#L45
opened a PR, thanks @noisesmith!
yeah http://4clojure.org redirects to http://4clojure.com
It looks from my simple experiments like iterate
doesn't chunk, and that it computes its results one at a time. Great! But is this something I should be able to rely on?
@lspector best practice is to isolate side effects or resource usage from laziness - eg. if you have a side effect to run on the first N results of some lazy-op, you can use (run! side-effect! (take N (iterate f x)))
or (doseq [y (take N (iterate f x))] (side-effect! y))
@noisesmith in my case there are no side effects, but in every case there is resource usage and in mine that may be big here
such that 32 items in memory would break something but 1 in memory would not?
Imagine you have an expensive transformation that you'd like to apply to a state many times in succession
You want to apply it until you find one that meets some condition, but you don't want to do it any more times than necessary because it takes a long time
there’s code floating about to “dechunk” to ensure you are not processing chunked, but it seems like there should be a cleaner solution
@lspector if all you want is the first match, (first (eduction ...))
is great
I could just use an explicit loop
, but iterate
would be more elegant if I could be sure it wouldn't chunk... which it doesn't seem to, but I'd like to know if that's reasonably reliable
peregrine.circle=> (first (eduction (filter even?) (map println) (take 3) (range)))
0
2
4
nil
I guess doing something inside that returns nil makes the example less clear
iterate
also does the right thing now as far as I can tell:
user=> (take 10 (iterate #(do (println :hi) (inc %)) 0))
:hi
:hi
:hi
:hi
:hi
:hi
:hi
:hi
:hi
(0 1 2 3 4 5 6 7 8 9)
isn’t the main thing that jira post adresses the fact that the function provided to iterate must be free of side-effects because there are corner cases where it can be calculated twice for the same input?
I don't understand the jira post so I'm not sure 🙂. But I put a side effect in there just to see if iterate
was chunking. My intended use case wouldn't include that.
Not yet understanding the eduction
example either, FWIW. I do understand and love the simplicity and elegance of iterate
, and would just like to know if I can rely on it not chunking.
We are hiring Candidates for Contract/Full time for Clojure - Who can work onsite in Atlanta or remote amywhere from USA
@lspector AFAIK nothing lazy in clojure makes any promises about future chunking behavior, we can say that it does or doesn’t chunk now but can’t say that about future implementations, and if the chunking changes your correctness AFAIK the right answer is not to use laziness
post in #jobs pls
Thanks @noisesmith. FWIW this isn't the first reason I've wished that there was a non-lazy version of every lazy thing in Clojure. I guess I'll avoid iterate
for this, and probably use loop
, though it'll make me sad. BTW this isn't a matter of correctness for me, but of avoiding taking much more time.
@lspector via transducing arities we do have non-lazy versions of most things lazy
@noisesmith I haven't fully wrapped my head around transducers. What would be the way to get something like iterate
using tranducing arities?
iterate’s one of the ones that doesn’t directly translate to transducing currently
though I could see something that acts like iterate but implements IReduceInit - similar to hiredman’s link above
@lspector: There's a pretty interesting conversation about chunking in #clojure-dev from a few days ago (still visible for me) - it looks like it might be relevant (might not, but I thought they were the same conversation when I was scrolling through so at least it will have some of the same words 🙂 )
@lspector @noisesmith Here is one of several implementations of an 'unchunk' function for Clojure: https://crossclj.info/fun/flatland.useful.seq/unchunk.html
I’ve seen a few versions - my worry is that needing unchunk is a code smell of using laziness for something it’s not quite suited for
but maybe I’m wrong, I’m unsure about this stuff
Thanks @andy.fingerhut. So if I want to do (take-while condition (iterate f v))
but want to be sure f
doesn't get called more than necessary (because of time, not side effects), I should do (take-while condition (unchunk (iterate f v)))
?
unchunk in that position wouldn’t help if iterate already chunked
my concern was that it could in some future clojure version - if we know it will never be that concern is moot
I haven't re-read the issue to steep myself in the details yet, but it was added in math.combinatorics to handle a case where memory blew up when chunking occurred, but became reasonable when chunking was removed: https://dev.clojure.org/jira/browse/MCOMB-2
it would protect something that surrounds iterate from chunking caused by iterate though
It sounds similar in flavor to @lspector's situation -- too many wasted resources due to chunking
so yeah, unchunk could help surrounding v (if generation of v is an issue) but you’d need to completely replace iterate, or get a promise that it won’t ever chunk
So looks like perhaps (take-while condition (iterate f (unchunk v))) might be what could help here?
Sorry, not fully awake here.
I was so excited I had something possibly relevant to add that I didn't fully engage the brain 🙂
I had a bit of a rant on chunking in #clojure-dev but half of it has already disappeared
Please rant in the clojure-dev Google group, where it will have a much-longer lasting URL 🙂
I’m interested in the possibility that issues around chunking / not chunking expose an impedance mismatch around using laziness for resource intensive or side effecting things - but I’m not sure if the right solution is a principled one (use something not lazy, make a non-lazy alternative for iterate(?)) or to accept that chunking needs to be abstracted from the implementation details of lazy things
not to mention the fact that RH might reject either of those things of course
The current implementation of iterate can be copied out of core into your code if it becomes chunking.
that’s true
not that any necessarily red flag will be raised if that happens, to let you know you should do it, if you are one of the relatively few whose use cases it matters for.
Ah, well in that case, a lower performance short sweet pure Clojure version can be written in your own code 🙂
The less you care about core changing, the better.
Huh, the fact that I can say that means that I may actually be recovering.
What is the most actively maintained Oauth2 library for clojure? This looks like it has a good team https://github.com/weavejester/ring-oauth2
Thanks @andy.fingerhut, @noisesmith, and @bronsa. I think I'll just use iterate
since it doesn't chunk now, and it sounds like that's unlikely to change soon. At least until somebody reuses my code 😉 it's not safety critical, and I'm using this in an educational context in which the simplicity and elegance of iterate
will make it worthwhile.