Anyone suggest coding kata sized challenges (1-4 hours long) for those just starting clojure / clojurescript? Links to simple solutions a bonus. Would like to add some challenges to the Clojurebridge content we are updating. Thanks.

@jr0cket How about the usual katas, e.g. prime factors, bowling game, string calculator and so on?

I don't have links to solutions but happy to drop them into a gist

Can't promise my solutions are idiomatic though, I used them to practice while learning, too.

Here are a few: Prime factors: https://gist.github.com/Vinai/a4d6c56e1a92f388edb72ffd30513733 String calculator: https://gist.github.com/Vinai/ca004731d8e1fb385bc238d997cdc3d3 Print diamond: https://gist.github.com/Vinai/8294a03975d1f67563b258636bbdbda7 Roman numerals: https://gist.github.com/Vinai/47c4d607567bab159781fd4c3c01e9bc Another fun one that takes a few hours is the ugly trivia legacy code refactoring kata: https://github.com/jbrains/trivia/tree/master/clojure In order of ascending complexity, I think those would be 1. Roman numerals 2. String calculator 3. Prime factors 4. Print diamond 5. Ugly trivia

@vinai thank you, most helpful

@seancorfield @schmee Here's the smallest example I could find that will reproduce the problem. I'm using Atom/Proto-Repl, When I evaluate the file, the Main Form is displayed. When I close the Main Form, it closes and I get the message "REPL Closed" in Porto-Repl. Then I have to restart Proto-Repl, and everything works fine again. (ns sherpa.main-form (:use [seesaw.core])) (def main-frame (frame :title "Main Form" :minimum-size [400 :by 200] :on-close :exit)) (-> main-frame show! pack!)

and if I run the code from a terminal REPL I get the following error when I close the window SocketException The transport's socket appears to have lost its connection to the nREPL server clojure.tools.nrepl.transport/bencode/fn--10199/fn--10200 (transport.clj:95) clojure.tools.nrepl.transport/bencode/fn--10199 (transport.clj:95) clojure.tools.nrepl.transport/fn-transport/fn--10171 (transport.clj:42) clojure.core/binding-conveyor-fn/fn--4676 (core.clj:1938) java.util.concurrent.FutureTask.run (FutureTask.java:266) java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1142) java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:617) java.lang.Thread.run (Thread.java:745) Bye for now!

so the moral is read the docs (lol) Note that :exit will cause the entire JVM to exit when the frame is closed, which may be reasonable for a standalone app, but probably isn't for use in the REPL. The default value is :hide. Changed :on-close :exit to :hide and works fine. Then you can re-show the form with (show! main-form)

is it safe to think of Vectors as similar to Arrays? (coming from JavaScript world)

@bengineer yes, https://clojure.org/reference/data_structures#Vectors

@genec haha yes, :on-exit is sneaky like that, that’s why I asked 🙂

@schmee yeah, thanks! I'm finding seesaw really nice for prototyping a simple GUI

which one is better?? core.async or java Thread?

or core.async just uses java Thread behind

@rcustodio I think it depends on what you want to do. core.async seems to be the choice of many though.

If you want to build some asynchronous application core.async is better. If you want to just spawn threads here and there java Threads are great.

For blocking stuff maybe plain Threads or futures are more suited than core.async

I’m doing a service that will get some things in asynchronous and then work with the result

Quite simple

Sounds like core.async would be a good way to go.

Thanks!!

Do they use Java Thread or its different?

They use some form of threads from a thread-pool reserved for core.async. Probably at some level it will be Java threads, but I don't know.

I see... thanks

@vinai @rcustodio https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/exec/threadpool.clj core.async delegates to the Executor framework, which uses java threads, which wrap system threads on most runtimes

this is likely an implementation detail

so don't rely on that fact

(though, yes, the clj version of core.async will probably always use Threads and a threadpool of some sort)

what is not an implementation detail is that go blocks should be free of blocking operations

core.async uses a small pool of threads that are shared by all go blocks in a cooperative manner, the thread is kept until you use a channel to read or write, then another go block can use it

this is more than just an implementation detail - if you don't understand how it's working you can starve core.async easily, resulting in none of your go blocks executing at all

this is why you shouldn't do expensive tasks (including and especially blocking IO) inside core.async go blocks

what are you supposed to do inside go blocks?

all I ever see here is “don’t use them for this”, “don’t use them for that” 😛

@schmee coordinate between various asynchronous operations

the issue is that asynchronous coordination is a problem that often comes up when you are doing thing parallel, which gets people confused and they assume they can use go blocks for parallelism

which breaks things

out of curiosity: does the same principle apply to Go channels?

or do they use fibers or something to get around that?

I'll let someone else answer that

go blocks are a godsend if you are dealing with an API that uses callbacks

for parallel tasks future is a good choice?

(let [x (future (http/get x)) y (future (http/get y))])

it's usually the simplest option, as long as you are starting a small number and don't need to do any interesting coordination

I see

Thansks

Thanks

Hi... is atom the only way???

clojure
(defn- get-orders [items access-token]
  (let [orders (atom {})]
    (when (= (:status @items) 200)
      (loop [orders-id (distinct (mapv #(:order_id %) (:body @items)))]
        (swap! orders
               assoc
               (first orders-id)
               '((ml-orders/get (first orders-id) access-token)
                 (ml-orders/get-feedback (first orders-id) access-token))))
      @orders)))

well.. the real question would be.. is there a better way?

why would that even need an atom? and why are you using loop with no recur?

sorry... i didnt put the recur yet

OK - anyway, instead of swapping the atom, you can put the new value into the loop arg, and return the result from the loop

yeah this function raises a lot of questions... you definitely do not need an atom anyway. if the loop has a recur then you can just pass the new orders map into the recur

I will work with result in another function

(defn- get-orders [items access-token]
  (let [orders (atom {})]
    (when (= (:status @items) 200)
      (loop [orders-id (distinct (mapv #(:order_id %) (:body @items)))]
        (when orders-id
          (swap! orders
                 assoc
                 (first orders-id)
                 '((ml-orders/get (first orders-id) access-token)
                   (ml-orders/get-feedback (first orders-id) access-token)))
          (recur (rest orders-id))))
      @orders)))

that's why you return it

so (when orders-id ...) becomes (if-not orders-id orders ...) - returning the orders instead of building up the value

also, (recur (rest ...)) indicates that your code could be improved by using reduce instead of loop

I see... if i need the result, using reduce is better

that way clojure does the sequence tracking for you, and the orders are the value returned from your reducing function

if you are consuming a collection in order, reduce is better than loop, period

it's even faster

Hmm, i see

It's a collection of "future"

that's fine

Rest API

Thanks

In this case, map would be better, no?

Cuz my return is a map of orders (futures)

map doesn't return a hash-map though, it returns a lazy-seq

if you are OK with returning a lazy-seq instead, and you want to process the input lazily, sure, map works

Yes... thanks

(defn- get-orders [items access-token]
    (when (= (:status @items) 200)
      (mapv #(hash-map :order (ml-orders/get % access-token)
                       :feedback (ml-orders/get-feedback % access-token))
            (distinct (mapv #(:order_id %) (:body @items))))))

And then just work with the seq

sure - but if you are using mapv, that means you don't want it to be lazy and it might make more sense to use reduce (or into with a map transducer) to create your hash-map

Sorry, i've changed to map

also, how is this items atom being used?

I need to learn more about reduce

I removed the atom

oh - I see (:status @items) - is that accessing a future then?

Yes

From another api request

The API have a lot of endpoints

That connect with each other

From that I must create an order to insert in the system

Can anyone help me understand why repeatedly would only call a function once?

@mjcleary almost definitely because it's lazy and you're only realising the first thunk

(take 1 (repeatedly #(println "whoa")))
whoa
=> (nil)
(take 2 (repeatedly #(println "whoa")))
whoa
whoa
=> (nil nil)
(take 3 (repeatedly #(println "whoa")))
whoa
whoa
whoa

Should I use (take n (repeatedly )) over (repeatedly n)?

what do you want to do, exactly?

Read number from console, then perform function that also reads from console that many times

(repeatedly (Integer. (read-line)) (check-weights (read-line)))

there's lots of different ways you could do this. I think the most intention revealing would be

(dotimes [_time-num (Integer/parseInt (read-line))]
   (check-weights (read-line)))

but, repeatedly would also work. using (dorun (repeatedly (Integer/parseInt (read-line)) #(check-weights (read-line)))) or (take (Integer/parseInt (read-line)) (repeatedly #(check-weights (read-line)))) or (nth (repeatedly #(check-weights (read-line))) (Integer/parseInt (read-line)))

the first thing I posted is far easier to read and think about than any of those though

some of my parentheses are off in those ^

Thank you very much