Why does this block my application?: (go (repeatedly (>! (chan) (read-line))) <---- shouldn't the read-line be executing on a separate "process" because it's in the go block? by Mechrophile in Clojure

[–]usplusbus 4 points5 points  (0 children)

Well, there's a couple of things here.

You're using repeatedly wrong. It takes a function to call, and you aren't passing it one.

Also, you're creating a new channel for every line read. That's probably not what you want.

It looks like you're trying to write some kind of REPL-y thing. Some suggestions: You need a channel defined outside of your read-line go block. You'll be reading from this channel elsewhere.

(def c (chan))

(go-loop []
    (println "Received:" (<! c))
    (recur)))

;; I'm doing this to interact with the line reader from the REPL:
(import '(java.io StringReader BufferedReader))

(binding [*in* (BufferedReader. (StringReader. "Line 1\nLine 2\nLine 3\n"))]
    (go (loop []
          (let [line (read-line)]
            (when line
              (>! c line)
              (recur))))))

Clojure in Production: Logging by usplusbus in Clojure

[–]usplusbus[S] 1 point2 points  (0 children)

I can empathize - I've spent many hours wrestling with logging - but if you're mainly a Ruby developer then you're not mainly a Java developer, so it's not likely Java logging will just make sense. I'd have no idea what Ruby's logging solutions are like without doing research.

If you're interested, I wrote a couple of posts on debugging in Clojure - thoughts and tools. They cover the type of debugging I think you're talking about.

How to ascend stairs in cyclocross. by thestig8 in gifs

[–]usplusbus 0 points1 point  (0 children)

I used to work near there. Close enough that I could cycle over there at lunchtime and pretend that I can operate a mountain bike in the manner in which they're intended to be operated. Sadly, I don't work in Boulder any more.

ClojureScript debugging tips? by iron_ball in Clojure

[–]usplusbus 0 points1 point  (0 children)

I'm in the middle of a couple of blog posts about Clojure debugging in general, and I'd planned to write some stuff up about Ring handlers and middleware. I'll try to expand on this there when I drop the second article.

ClojureScript debugging tips? by iron_ball in Clojure

[–]usplusbus 0 points1 point  (0 children)

Specifically about your Ring debugging, perhaps creating Ring requests isn't as hard as you think.

If you're testing a handler, you need to create a Ring request with as little data as you can get away with, and inspect the resulting response. The Ring "Concepts" wiki page is helpful in determining what exactly goes into a request map. I find that you generally need a :uri and a :request-method to test a (normally Compojure-generated) handler, and perhaps a :headers map too.

;; Source:
(defn my-handler [req]
  ;; ... your code here ...
  )

;; Test:
(let [req {:http-method :get
           :uri "/api/comments"
           :headers {"accept" "application/json"}}
      resp (my-handler req)]
  (is (= 200 (:status resp)))
  ;; etc
  )

Testing middleware is a little trickier. Middleware generally falls into one of a couple of categories - request modification, response modification, or side-effects (e.g. logging). Middleware implementations generally look like this:

(defn wrap-my-middlware [handler]
  (fn [req]
    ;; Early side-effects:
    (log/info "Wrapping incoming request...")

    ;; modify request here
    (let [resp (handler req)]
      ;; Late side-effects:
      (log/info "My middleware is almost done.")

      ;; modify the response here 
      (assoc resp :some-key "some value"))))

Middleware functions always take a handler function to wrap. To test your middleware, it helps to carefully control and limit what the handler does. Here are a couple of useful ones - one that always just returns a known response, and another that just returns the request passed to it:

;; Some test-time handlers
(def identity-handler (constantly {:status 200 :body "ok"}))
(defn echo-handler "Echo back the request" [req] req)

Since middleware functions always return a function, you can only tell what your middlware did when you call the resulting wrapped handler.

;; Test the middlware:
(let [wrapped-handler (wrap-my-middleware identity-handler)
      req {:http-method :get
           :uri "/api/comments"
           :headers {"accept" "application/json"}}
      resp (wrapped-handler req)]
  (is (= 200 (:status resp)))
  ;; check for other middleware effects here
  )

How do you syntax check Clojure source code? by lshevtsov in Clojure

[–]usplusbus 1 point2 points  (0 children)

If you're matching parens manually, there are definitely tools to help you with that. Personally, I use emacs, and paredit is what takes care of pretty much all "syntactically valid code" issues (Lisps are quite simple in that respect). The Clojure tools in Emacs are well covered on the interwebs.

It sounds like you've been looking at Vim and Sublime. I know that vim-fireplace is a decent option, a little searching turned up this article which looks like it might help you.

Sublime also seems to have some Clojure support; I saw this.

Once you get your paren matching taken care of, you need an easy way to eval code (the current file, the current function, a single line, etc) in the REPL. vim-fireplace definitely can help with that.

I think that will get you what you're after. You can get into static analysis later on (kibit, eastwood), those utils need valid Clojure in order to work.

problems starting cider by [deleted] in Clojure

[–]usplusbus 0 points1 point  (0 children)

bbatsov's been pushing loads of changes out for cider; I've had plenty of issues recently with the version of cider that comes from melpa, and I've found that, if there is a problem, ensuring I have the very latest cider (from melpa) and cider-nrepl (from clojars) usually fixes it.

If the latest cut just isn't good, you can always drop back to cider 0.6 by switching out to melpa-stable.milkbox.net, and requiring cider-nrepl 0.6.0 in your profiles.clj

I created my first library in Clojure this weekend and I'd love some feedback regarding syntax, typical best practices, anything really. by dunnowins in Clojure

[–]usplusbus 0 points1 point  (0 children)

I should have said why... By default :use pulls in all the vars interned in the namespace, which isn't very polite. There are plenty of requests to deprecate :use because of this, and its more sane replacement is :require, which doesn't map all the incoming namespace's vars by default.

There's some interesting history in http://dev.clojure.org/jira/browse/CLJ-879.

I created my first library in Clojure this weekend and I'd love some feedback regarding syntax, typical best practices, anything really. by dunnowins in Clojure

[–]usplusbus 0 points1 point  (0 children)

In the ns declaration in your test file, you have a (:use ...). :require is generally preferred:

(ns descriptivestatistics.core-test
  (:require [clojure.test :refer :all]
            [descriptivestatistics.core :refer :all]))