midje only 1 test

[r/ Wobben]

hello, 

Suppose I have this test  

(facts "do-a-thing" {:exercise 1 :points 1} (do-a-thing 3) => 46656.0 (
do-a-thing 1) => 4.0 (do-a-thing 0) => 1.0)
Is there a way I can only run this test 
I tried lein midje :filter exercise 1 
but that one fails.

Roelof

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] prismatic/schema 1.0 adds automatic test data generation

[Jason Felice]

On Wed, Sep 2, 2015 at 9:56 PM, Jason Wolfe  wrote:
>
> Outside of that, I can still potentially see the desire to specify
> postconditions rather than preconditions (you'd rather see an error (not
> (integer? "1")) than (throws? (odd? "1")), which will be the behavior when
> the bug is fixed.  We're thinking about whether it's worth the extra
> complexity to support that, what are your thoughts?  If you think it would
> be valuable, please open another issue on github so we can track it --
> thanks.
>

Postconditions are what I reached for intuitively, and so I suspect many
other people will also try to figure them out.  It "feels good" if one is
anticipating a generator and knows about gen/such-that, for example.

I haven't looked at the Schema generation API yet, but I'd like to not need
to specify leaf generators (except perhaps for performance reasons).

That said, s/both is both (ha!) awkwardly named (since it can take more
than two) and not a mechanism I'm attached to.  Perhaps there's another
way?  I'd be happy if there is a concise, recommended, well-documented way,
even if (like gen/bind) I have to jump through a few mental hoops to figure
out how to phrase it.

-Jason

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Glow 0.1.3, now with server-side syntax highlighting of Clojure source in HTML/CSS

[W. David Jarvis]

Hi everyone!

I'm happy to announce the release of Glow 
 0.1.3. This new release adds the 
ability to generate syntax-highlighted blocks of HTML from an input string 
of Clojure source code. Generated HTML will sit in a div element with class 
"syntax", and a pre block underneath that. Individual elements are 
contained within span tags, much like Pygments. 

You can use your own CSS, or you can use `glow.core/generate-css` with a 
colorscheme map to have Glow generate a CSS file for you. 

Cheers!

 - V

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Notepad++ clojure support files 1.3

[Alex Woods]

 



在 2015年9月3日星期四 UTC+8下午9:56:25，Alex Woods写道：
>
> Notepad++ clojure support files 1.3 
>
> https://drive.google.com/open?id=0By5ssgBX1IWaTHA4NXhtb3Z4VFk
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] paren-soup, a browser-based ClojureScript editor

[Zach Oakes]

I’m releasing paren-soup, a ClojureScript viewer and editor that you can 
embed in any website. While projects like CodeMirror are nice if you need 
to support other languages, I hope to make paren-soup a better choice for 
those who only want to edit ClojureScript. Here are the features:


   - Syntax highlighting
   - Rainbow delimiters
   - Automatic indentation
   - InstaREPL (à la Light Table)


Code: https://github.com/oakes/paren-soup
Demo: http://oakes.github.io/paren-soup

The InstaREPL is possible thanks to the recent bootstrapping of 
ClojureScript. The syntax highlighting and auto-indentation are possible 
thanks to the new ClojureScript version of tools.reader. The upside to 
using tools.reader is that the highlighting is pretty faithful to the 
language; the downside is that reader errors break highlighting =)

As usual with my projects, the first release is pretty rough. Performance 
is awful once the file gets large enough. I hope to improve that and add 
features like paredit and *semantic* highlighting eventually. This is my 
very first ClojureScript project, by the way! Please let me know when you 
find bugs.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Notepad++ clojure support files 1.3

[Alex Woods]

Notepad++ clojure support files 1.3 

https://drive.google.com/open?id=0By5ssgBX1IWaTHA4NXhtb3Z4VFk

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stuart Sierra's Component: retries & restarts in production

[Andy-]

Only to answer the "retry on error" part of you question: You might like 
hara/event:
http://docs.caudate.me/hara/hara-event.html

HTH

On Wednesday, September 2, 2015 at 8:44:07 PM UTC-4, jo...@signafire.com 
wrote:
>
> TLDR: how do you use Component when the application logic involves 
> retrying failed components?
>
> Background:
> I'm writing an app that consumes events from a streaming HTTP connection 
> and writes those events to a message queue (see Code Illustration #1). It 
> seems like that could be captured easily with three components —an HTTP 
> stream, a message queue connection, and a "shoveler" that depends on the 
> other two (see Code Illustration #2)— *but* the reconnection requirements 
> complicate things…
> The HTTP connection may be closed at any time by the server; if that 
> happens, the app should persistently attempt to reconnect using an 
> exponential back-off pattern. In addition, if the app goes thirty seconds 
> without receiving any data, it should close the connection and try to 
> reconnect. (see Code Illustration #3) It's not clear to me how to best 
> express these "retry" requirements in the component lifecycle. Like, is it 
> blasphemous for a component to be calling stop and start on its injected 
> dependencies?
>
> Some possible approaches:
>
>- Throw different kinds of exceptions to indicate what should happen 
>(using namespaced keywords, perhaps?), handled by whoever calls 
>component/start on the system-map.
>- The exception provides the component and system at the time of the 
>   exception, enabling a sort of "resume" capability.
>   - I'm under the impression that relying on exceptions for control 
>   flow is an anti-pattern.
>- Create a sort of custom system implementation, one that goes beyond 
>calling start on its components in dependency order to monitor 
>failures and direct retries "appropriately".
>   - "A system is a component which knows how to start and stop other 
>   components." (from the README)
>   So the fact that we want the shoveler component to be capable of 
>   restarting the HTTP component indicates that the shoveler should 
> actually 
>   be considered a system. (right?)
>  - If the HTTP stream is *injected* into the shoveler as a 
>  dependency, how is it possible for the shoveler to stop the HTTP 
>  stream and then start it again *with* any dependencies the 
>  stream may have?
>   - Ensure that every component/Lifecycle method implementation is 
>idempotent, so that I can get good-enough "restart" semantics by just 
>calling start-system again.
>   - I know that idempotence is generally a Good Thing anyway, but 
>   using start-system as a panacea strikes me as crude.
>
>
> Code Illustrations:
>
> 1. Rough sketch of app without timeout/retry logic or component:
> (defn -main []
>   (let [mq-conn (connect-to-queue mq-config)
> {event-stream :body} (http/get endpoint {:as :stream})]
> (with-open [rdr (java.io/reader event-stream)]
>   (doseq [entity (line-seq rdr)]
> (write mq-conn entity)
>
> 2. Rough sketch of app with component but still without timeout/retry 
> logic:
> (defrecord EventStream [endpoint
> http-config
> stream]
>   component/Lifecycle
>   (start [this]
> (let [response (http/get endpoint (merge {:as :stream} http-config))]
>   (assoc this :http-response response, :stream (:body response)))
>   (stop [this]
> (.close stream)
> (-> this (dissoc :http-response) (assoc :stream nil
>
> (defrecord MessageQueue [config
>  connection]
>   component/Lifecycle
>   (start [this]
> (assoc this :connection (connect-to-queue config)))
>   (stop [this]
> (.close connection)
> (assoc this :connection nil)))
>
> (defrecord Shoveler [source sink
>  worker]
>   component/Lifecycle
>   (start [this]
> ;; To avoid blocking indefinitely, we put the processing in a future.
> (assoc this :worker (future
>  (with-open [rdr (java.io/reader (:stream source)]
>(doseq [entity (line-seq rdr)]
>  (write sink entity)
>   (stop [this]
> (future-cancel worker)
> (assoc this :worker nil)))
>
> (defn -main []
>   (-> (component/system-map :config (read-config)
> :events (map->EventStream {:endpoint endpoint
> })
> :mq-client (map->MessageQueue {})
> :shoveler (map->Shoveler {}))
>   (component/using {:events {:http-config :config}
> :mq-client {:config :config}
> :shoveler {:source :events
>:sink :mq-client}})
>   component/start))
>
> 3. Rough sketch of desired *production* behavior, not using Component:
> (defn 

Re: Stuart Sierra's Component: retries & restarts in production

[Raymond Huang]

Another way I can think of decomposing this is to buffer/queue
communication between your two components, i.e a core.async channel. This
will decouple the two components allowing your MessageQueue to manage it's
own reconnection.

Interesting question about whether `start` calling `stop` is blasphemy or
not. I hope someone else can provide some insight on that.


On Wed, Sep 2, 2015 at 4:03 PM,  wrote:

> TLDR: how do you use Component when the application logic involves
> retrying failed components?
>
> Background:
> I'm writing an app that consumes events from a streaming HTTP connection
> and writes those events to a message queue (see Code Illustration #1). It
> seems like that could be captured easily with three components —an HTTP
> stream, a message queue connection, and a "shoveler" that depends on the
> other two (see Code Illustration #2)— *but* the reconnection requirements
> complicate things…
> The HTTP connection may be closed at any time by the server; if that
> happens, the app should persistently attempt to reconnect using an
> exponential back-off pattern. In addition, if the app goes thirty seconds
> without receiving any data, it should close the connection and try to
> reconnect. (see Code Illustration #3) It's not clear to me how to best
> express these "retry" requirements in the component lifecycle. Like, is it
> blasphemous for a component to be calling stop and start on its injected
> dependencies?
>
> Some possible approaches:
>
>- Throw different kinds of exceptions to indicate what should happen
>(using namespaced keywords, perhaps?), handled by whoever calls
>component/start on the system-map.
>- The exception provides the component and system at the time of the
>   exception, enabling a sort of "resume" capability.
>   - I'm under the impression that relying on exceptions for control
>   flow is an anti-pattern.
>- Create a sort of custom system implementation, one that goes beyond
>calling start on its components in dependency order to monitor
>failures and direct retries "appropriately".
>   - "A system is a component which knows how to start and stop other
>   components." (from the README)
>   So the fact that we want the shoveler component to be capable of
>   restarting the HTTP component indicates that the shoveler should 
> actually
>   be considered a system. (right?)
>  - If the HTTP stream is *injected* into the shoveler as a
>  dependency, how is it possible for the shoveler to stop the HTTP
>  stream and then start it again *with* any dependencies the
>  stream may have?
>   - Ensure that every component/Lifecycle method implementation is
>idempotent, so that I can get good-enough "restart" semantics by just
>calling start-system again.
>   - I know that idempotence is generally a Good Thing anyway, but
>   using start-system as a panacea strikes me as crude.
>
>
> Code Illustrations:
>
> 1. Rough sketch of app without timeout/retry logic or component:
> (defn -main []
>   (let [mq-conn (connect-to-queue mq-config)
> {event-stream :body} (http/get endpoint {:as :stream})]
> (with-open [rdr (java.io/reader event-stream)]
>   (doseq [entity (line-seq rdr)]
> (write mq-conn entity)
>
> 2. Rough sketch of app with component but still without timeout/retry
> logic:
> (defrecord EventStream [endpoint
> http-config
> stream]
>   component/Lifecycle
>   (start [this]
> (let [response (http/get endpoint (merge {:as :stream} http-config))]
>   (assoc this :http-response response, :stream (:body response)))
>   (stop [this]
> (.close stream)
> (-> this (dissoc :http-response) (assoc :stream nil
>
> (defrecord MessageQueue [config
>  connection]
>   component/Lifecycle
>   (start [this]
> (assoc this :connection (connect-to-queue config)))
>   (stop [this]
> (.close connection)
> (assoc this :connection nil)))
>
> (defrecord Shoveler [source sink
>  worker]
>   component/Lifecycle
>   (start [this]
> ;; To avoid blocking indefinitely, we put the processing in a future.
> (assoc this :worker (future
>  (with-open [rdr (java.io/reader (:stream source)]
>(doseq [entity (line-seq rdr)]
>  (write sink entity)
>   (stop [this]
> (future-cancel worker)
> (assoc this :worker nil)))
>
> (defn -main []
>   (-> (component/system-map :config (read-config)
> :events (map->EventStream {:endpoint endpoint
> })
> :mq-client (map->MessageQueue {})
> :shoveler (map->Shoveler {}))
>   (component/using {:events {:http-config :config}
> :mq-client {:config :config}
> :shoveler {:source :events
>