@schmee Yes I remember being confused one time because this didn't work:

(let [[x y] #{:a :b :c}] x)

(let [[x & y] #{:a :b :c}] x)

in my case above, w is (was) actually a lazy seq created with for

so I don’t get why destructing the rest is so slow 😕

Quick question: What’s the practicality for (declare x) ?

to be able to use definitions higher in the ns than defined

I have a function that depends on a symbol later in the file, I was curious if declare makes sense to be used here, or if there’s a better way.

that's what declare is for

Gotcha, thank you 🙂

any known way to work around the limitation of async/go not seeing <! and >! calls when working with a complex piece of code?

complex as in the <! and >! are inside functions? that's not meant to work

yeah, as in <!/>! are a few calls deep

go is a macro, macros operate by rewriting code, it shouldn't be trying to rewrite code inside functions

those <! and >! calls work because go knows how to translate them into a state machine that integrates with channel machinery, it would be an overreach to rewrite the code of arbitrary functions called inside the block

that's pretty much where i got. i'm trying to find an alternative to perform channel-based communication between workers that does not involve rolling my own thread scheduler

if you look at the functions defined in core.async itself, you'll see a general pattern of passing channels to functions and then parking on the channel (or getting a channel back from a function)

of course this involves the function calling go inside, most of the time

My project run " lein trampoline repl " on Clojure 1.9.0 Alpha 14 or 1.9.0 Alpha 15 is ok, but on 1.9.0 Alpha 16 or 1.9.0 Alpha 17 is error: Exception in thread "main" java.io.FileNotFoundException: E:\temp\form-init820515111953380484.clj (The system cannot find the specified file. ) at java.io.FileInputStream.open0(Native Method) at java.io.FileInputStream.open(FileInputStream.java:195) at java.io.FileInputStream.<init>(FileInputStream.java:138) at java.io.FileInputStream.<init>(FileInputStream.java:93) at clojure.lang.Compiler.loadFile(Compiler.java:7392) at clojure.main$load_script.invokeStatic(main.clj:277) at clojure.main$init_opt.invokeStatic(main.clj:279) at clojure.main$init_opt.invoke(main.clj:279) at clojure.main$initialize.invokeStatic(main.clj:310) at clojure.main$null_opt.invokeStatic(main.clj:344) at clojure.main$null_opt.invoke(main.clj:341) at clojure.main$main.invokeStatic(main.clj:423) at clojure.main$main.doInvoke(main.clj:386) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.lang.Var.applyTo(Var.java:702) at clojure.main.main(main.java:37)

@lincpa maybe you have LEIN_FAST_TRAMPOLINE set in your environment and your .lein_classpath file captured a file that was generated but no longer exists?

just a theory

@noisesmith Thanks, " lein repl" on Clojure 1.9.0 Alpha 17 is ok!

@pelletier also, a (go ...) block always returns a channel which will return the result of its inside as its sole value.

Hello! I have having a very strange issue where a for construct appears not to be executed inside the body of a function called by a test and I have no idea how to debug it

I boiled down the problem to these three lines:

(println "here")
(map #(println %) (range 5))
(println "there")

When running the test, “here” and “there” are printed, but nothing is printed in-between

(same if I used (for [x (range 5)] (println x)))

I have absolutely no idea what could be interfering with the iteration. The test is executed within a larger context (it’s running a query on a graphql schema handled by lacinia, and this function is called as part of the resolve process)

mystery solved

it yields a lazy sequence

doall fixes it

I don’t have internet at home at the moment and this kept me awake for an hour and a half yesterday 😄

@hmaurer if you don't need the seq but only the side effects you could consider dorun as it does not hold onto the head.

@drowsy ah, good point. thank you!

also you could have a look at doseq which basicly is for for side effects

@drowsy precisely what I was looking for, thank you. Basically I want to loop through a collection, do a check on each member and throw an exception in some cases

I’ve a global private map in an atom used as a key-value cache, are there any reasons why I wouldn’t want to make that map a transient?

Seeing perf benefits from faster assoc!, but thinking I might be missing some potential issues

@jfntn terrible idea

swap! may retry to assoc! in case of contention, you will end up with a corrupted map

Ah good point, is it correct that this would not apply to cljs?

yes

atom in cljs behaves pretty much like an ordinary variable

there's no compare-and-swap like in clj

Are there other mutable containers that'd perform better than this in cljs?

not in the standard library

maybe javascript arrays or objects could do the job if keys are strings or numbers, otherwise you'll have to implement clojure equality semantics yourself

Interesting, thanks @leonoel

hi! how to have a spec that restricts a string to be between X and Y length?

Is it possible to use spec to search a data structure and return matches for a regex? Ie., equivalent to re-find.

@pwrflx (s/and string? #(<= your-min (count %) your-max))

@mpenet thanks! btw will test data generation work in case of such hand-written predicates?

What is the simplest way to pretty print XML? I just need to put XML in readable format for user

@pwrflx yes, it might take a while depending on your bounds, in that case you can pass a custom generator

@mpenet will give it a try, thanks!

but you can test it with (s/exercise (s/and string? #(<= 0 (count %) 100))) for instance

hm nice

@kwladyka I haven’t tried this but it looks decent https://nakkaya.com/2010/03/27/pretty-printing-xml-with-clojure/

@kwladyka

is http://repo1.maven.org being slow for anyone else?

(-> xml-string java.io.StringReader. clojure.data.xml/parse clojure.data.xml/indent-str)

maybe throw in a println at the end

I’d like to turn the following into a macro:

(defn until-equal
  ([func]
   (until-equal func (atom {:init false :val nil})))
  ([func prev-atom]
   (until-equal func prev-atom 10))
  ([func prev-atom n]
   (if (neg? n)
     (throw (Exception. "Cannot achieve equal values"))
     (let [prev (if (:init @prev-atom)
                  (:val @prev-atom)
                  (func))
           current (func)]
       (if (= prev current)
         current
         (do
           (swap! prev-atom assoc :init true :val current)
           (recur func prev-atom (dec n))))))))

loopdyloop

you could just take your until-equal function, and create a macro (defmacro until-equal' [& body] `(until-equal (fn [] ~@body))) 🙂

I'd suggest that using atoms is a really un-clojurey way to do this btw

why is that atom in there?

oh, what he said - the atom is kind of pointless in this code btw

unless you expect to call the function from multiple threads concurrently and want to stop when two calls are equal even though they are from different call sites…

stateful functions are weird

(loop [prev-value (func) lim-counter 10]
  (when (< lim-counter 0) (throw (Exception. "Cannot achieve equal values)))
  (let [next-value (func)]
    (if (= prev-value next-value)
      prev-value
      (recur next-value (dec lim-counter)))))

a more functional style

> (->> #(rand-int 10) (repeatedly) (partition 2 1) (drop-while (partial apply not=)) (ffirst))
2

I'd quibble over more "functional". utilising laziness is definitely a functional thing to do but a recursive loop isn't exactly imperative

how about “declarative”

declarative is exactly it

@noisesmith how often should I worry about cost of such fns built from clojure.core/ ones?

(Talking about you drop-while example above)

what do you mean by “built from clojure.core ones” - the partial?

@misha anyway, typically the most readable / maintainable code will be the code that uses lazy features (like that example), the best performing will use reduce (if it consumes a collection that is) with loop being the least readable / maintainable and in the middle perf wise

the thing you really want to look out for is sloppy mixing of eager and lazy (eg. calling concat in a loop or reduce to build up a value) - that’s where the dragons are

you have the twin problems of space / stack usage going out of control or correctness being lost when lazy and eager code are mixed poorly

I declare the answer — accepted! thank you

I think it is really good advise

I'm starting my webserver as:

(defn launch-dev []
  (org.httpkit.server/run-server 
   #'app 
   {:port  5001
    :join? true}))

telnet localhost 5001
Trying ::1...
Connected to localhost.
Escape character is '^]'.
GET /
Connection closed by foreign host.

I mean.. lazy sequences and utilising reduce is cool and all. but I find it hard to believe anyone would find my loop example less readable than either the lazy seq implementation or a reduce example

I’m not trying to pick on that code, the main thing I wanted to get at was that generally when consuming something that can be treated as a sequence, one of clojure’s higher level sequence consuming functions will be more straightforward to read. reduce is often weird (especially if one is less used to using it) but it does perform better

I’m mucking around with core.match, and I’m wondering why it’s using try/catch to implement backtracking, instead of say, case or something

I’ve read on the internet that exceptions are “slow”

core.match has an a graph that represents the match and it needs to flatten in to a tree because clojure code is a tree

one way to flatten it would be to copy the nodes that get looped back to every place that would get looped back to

(which is likely what you mean by using case)

the problem with that is when you copy like that the code size explodes

so what core.match actually does is use an exception to jump back to another node (pre-allocated exceptions are apparently pretty fast on the jvm)

the algorithm core.match is based on sort of assumes gotos or tail calls in the output language, neither of which clojure has

interesting!

so backtracking / exceptions are use to reduce code size?

I tried macroexpanding the fizzbuzz example from the readme with *no-backtrack* bound to true, and it actually made the expanded code smaller

admittedly that is a simple example

https://dev.clojure.org/jira/browse/MATCH-1

https://media.giphy.com/media/3og0IMJcSI8p6hYQXS/giphy.gif

very nice read, feels good to set your misconceptions straight, thanks!

does any one uses aleph in production ? I'd like to know about your experience

I’ve never had a problem

replacing the previous jetty was easy, and it’s never misbehaved

nice, what about documentation ?

it’s pretty well documented via the github page