Re: [ANN] Clojure 1.10 has been released!

2018-12-18 Thread Thomas
Thank you for this release and all the hard work everyone has put into 
this!!!

Thomas

On Monday, 17 December 2018 18:30:01 UTC+1, Alex Miller wrote:
>
> Clojure 1.10 focuses on two major areas: improved error reporting and Java 
> compatibility.
>
>
> Error reporting at the REPL now categorizes 
>  errors 
> based on their phase of execution (read, macroexpand, compile, etc). Errors 
> carry additional information about location and context as data, and 
> present phase-specific error messages with better location reporting. This 
> functionality is built into the clojure.main REPL, but the functionality is 
> also available to other REPLs and tools with the ability to use and/or 
> modify the data to produce better error messages.
>
>
> Clojure 1.10 now requires Java 8 or above and has been updated 
> particularly for compatibility with Java 8 and Java 11. Changes included 
> bytecode-related bug fixes, removed use of deprecated APIs, and updates 
> related to the module system introduced in Java 9.
>
>
> See the change log 
> 
>  
> for a complete list of all fixes, enhancements, and new features in Clojure 
> 1.10.
>
>
> Thanks to all of the community members who contributed patches to Clojure 
> 1.10 (first time contributors in bold):
>
>
>- 
> *Alexander Kiel *
>- *Ben Bader*
>- Bruce Adams
>- *Cezary Kosko*
>- Erik Assum
>- *Eugene Kostenko*
>- Ghadi Shayban
>- *Gijs Stuurman*
>- Jozef Wagner
>- 
> *Kwang Yul Seo *
>- *Matthew Gilliard*
>- Michał Marczyk
>- Nicola Mometto
>- Nikita Prokopov
>- 
> *Sean Corfield *
>- *Sebastien Martel*
>- Shogo Ohta
>- Stuart Sierra
>
>

-- 
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.


Clojure 1.10 issue: thrown? no longer works on macros

2018-12-18 Thread Mark Engelberg
Consider the following macro:

(defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
=> (f 3)
8
=> (f true)
Unexpected error (AssertionError) macroexpanding f at
(test:localhost:62048(clj)*:265:28).
Assert failed: (number? x)

So, as expected it throws an AssertionError if passed a non-number.
However, the following test (using is from clojure.test) used to work prior
to 1.10, but now fails:

=> (is (thrown? AssertionError (f true)))
Unexpected error (AssertionError) macroexpanding f at
(test:localhost:62048(clj)*:268:56).
Assert failed: (number? x)

What's odd is that the macro still throws an AssertionError, but the
`thrown?` inside the `is` is no longer intercepting the AssertionError, so
the test doesn't pass -- instead the error causes a failure in the test
suite.

-- 
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] Oz 1.4.0 - Interactive data visualizations and scientific documents with Vega/Vega-Lite

2018-12-18 Thread Juraj Martinka
I'd like to try this but got stuck pretty early:

(ns clojure-repl-experiments.visualizations.oz
  (:require [oz.core :as oz]))


(oz/start-plot-server!)


(defn group-data [& names]
  (apply concat (for [n names]
  (map-indexed (fn [i x] {:x i :y x :col n}) (take 20 
(repeatedly 
#(rand-int 100)))


(def line-plot
  {:data {:values (group-data "monkey" "slipper" "broom")}
   :encoding {:x {:field "x"}
  :y {:field "y"}
  :color {:field "col" :type "nominal"}}
   :mark "line"})


;; Render the plot to the 
(oz/v! line-plot)



It has opened a new browser window at http://localhost:10666/ but I see 
nothing only errors in the JS console:
socket.cljs?rel=1502542805393:64 WebSocket connection to 
'ws://localhost:3449/figwheel-ws/dev' failed: Error in connection 
establishment: net::ERR_CONNECTION_REFUSED
figwheel$client$socket$open @ socket.cljs?rel=1502542805393:64
10:10:10.089 

Does it require some special setup (figwheel)?




On Monday, 17 December 2018 21:41:36 UTC+1, Christopher Small wrote:
>
>
> Greetings!
>
> I'm happy to announce today the release of Oz 1.4.0.
>
> https://github.com/metasoarous/oz
>
> If you're on the Slack #datascience channel, you may have already caught 
> wind of some earlier versions. But in the interest of introducing it more 
> broadly, I'm posting an overview here for those of you who aren't familiar. 
> If you *are* familiar, you may still wish to scroll down to the bottom as 
> there are some new features available in the latest release.
>
>
> *Vega & Vega-Lite*
>
> Oz is based on the fantastic Vega & Vega-Lite data visualization JS 
> libraries, and so to really understand what Oz has to offer, it's best to 
> start here. Vega & Vega-Lite are based on the seminal Grammar of Graphics, 
> an approach to data visualization which emphasizes writing declarative 
> descriptions of how properties of data should translate to aesthetic 
> attributes of a visualization. This approach guided the design of the R's 
> popular ggplot2 library, and has since influenced numerous libraries in 
> other languages.
>
> Vega & Vega-Lite take this vision further in two important ways:
>
>1. In Vega & Vega-Lite, data visualizations are described using *pure 
>data*. This makes it more declarative, and confers all the benefits we 
>know and love about data-driven programming in Clojure. For instance, you 
>can send a chunk of Vega or Vega-Lite data over the wire from one program 
>to another effortlessly (as Oz does), and load it up in another process 
>without having to worry about the security concerns of executing someone 
>else's code. The bottom line is that Vega & Vega-Lite are philosophically 
>and technically compatible with "the Clojure way" (IT'S. JUST. DATA.).
>2. Vega & Vega-Lite take the Grammar of Graphics one step further by 
>introducing a Grammar of Interaction. You can declaratively describe the 
>addition of controls (dropdowns, checkboxes, etc) and interactive 
>properties of the visualization itself (click, hover, etc), and use the 
>data from these interactions to inform other parts of a visualization. For 
>example, you might highlight a set of points in one part of a 
>visualization, and display summary statistics about that selection in 
>another. This is facilitated in part by a general purpose dataflow 
> language 
>as part of the greater spec.
>
> Vega itself is highly customizable and flexible, but somewhat verbose and 
> not suitable for day to day visualization tasks. Vega-Lite steps in as a 
> somewhat higher level and more automated flavor which itself compiles down 
> to Vega. I have been using them together for a better part of a year now, 
> and can say without reservation that they are amazing. For years I've 
> longed for a ggplot2 from Clojure, and at long last I've found something 
> that to my surprise has not only matched, but truly surpassed the standard 
> bearer. In short, I'm sold.
>
> If you want to get a better sense of Vega, and Vega-Lite in particular, 
> I'd recommend this great talk from the creators at the Interactive Data Lab 
> at the University of Washington in Seattle: 
> https://www.youtube.com/watch?v=9uaHRWj04D4
>
> If you're interested in a (mostly) more philosophical look at Vega & 
> Vega-Lite, and their connections to Clojure philosophy, I did a little talk 
> at a local Clojure meetup which you may find interesting: 
> https://www.youtube.com/watch?v=hXq5Bb40zZY&t=815s
>
>
> *Oz*
>
> Oz itself is a very small and focused library, as most of the work falls 
> on Vega & Vega-Lite. It offers the following features:
>
>- A REPL API for for pushing vega and vega-lite data to a browser 
>window over websockets, for REPL-based data science workflows
>- Client side vega and vega-lite Reagent components, for more dynamic 
>usage from ClojureScript apps
>- A grammar for composing Vega & Vega-Lite together in th

Re: Clojure 1.10 issue: thrown? no longer works on macros

2018-12-18 Thread alex
I'm not sure, but probably it behaves so because of throwing at macroexpand 
stage.

вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler написал:
>
> Consider the following macro:
>
> (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
> => (f 3)
> 8
> => (f true)
> Unexpected error (AssertionError) macroexpanding f at 
> (test:localhost:62048(clj)*:265:28).
> Assert failed: (number? x)
>
> So, as expected it throws an AssertionError if passed a non-number.
> However, the following test (using is from clojure.test) used to work 
> prior to 1.10, but now fails:
>
> => (is (thrown? AssertionError (f true)))
> Unexpected error (AssertionError) macroexpanding f at 
> (test:localhost:62048(clj)*:268:56).
> Assert failed: (number? x) 
>
> What's odd is that the macro still throws an AssertionError, but the 
> `thrown?` inside the `is` is no longer intercepting the AssertionError, so 
> the test doesn't pass -- instead the error causes a failure in the test 
> suite.
>

-- 
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: Clojure 1.10 issue: thrown? no longer works on macros

2018-12-18 Thread Mark Engelberg
Agreed.  It is not a problem for functions which throw AssertionErrors,
only macros.  But this is a change in behavior which breaks test suites
which passed previously.

On Tue, Dec 18, 2018 at 1:48 AM alex  wrote:

> I'm not sure, but probably it behaves so because of throwing at
> macroexpand stage.
>
> вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler написал:
>>
>> Consider the following macro:
>>
>> (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
>> => (f 3)
>> 8
>> => (f true)
>> Unexpected error (AssertionError) macroexpanding f at
>> (test:localhost:62048(clj)*:265:28).
>> Assert failed: (number? x)
>>
>> So, as expected it throws an AssertionError if passed a non-number.
>> However, the following test (using is from clojure.test) used to work
>> prior to 1.10, but now fails:
>>
>> => (is (thrown? AssertionError (f true)))
>> Unexpected error (AssertionError) macroexpanding f at
>> (test:localhost:62048(clj)*:268:56).
>> Assert failed: (number? x)
>>
>> What's odd is that the macro still throws an AssertionError, but the
>> `thrown?` inside the `is` is no longer intercepting the AssertionError, so
>> the test doesn't pass -- instead the error causes a failure in the test
>> suite.
>>
> --
> 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.
>

-- 
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] Clojure 1.10 has been released!

2018-12-18 Thread Rick Moynihan
Great news,

Thanks to everyone who made this possible!

R.

On Tue, 18 Dec 2018 at 09:02, Thomas  wrote:

> Thank you for this release and all the hard work everyone has put into
> this!!!
>
> Thomas
>
> On Monday, 17 December 2018 18:30:01 UTC+1, Alex Miller wrote:
>>
>> Clojure 1.10 focuses on two major areas: improved error reporting and
>> Java compatibility.
>>
>>
>> Error reporting at the REPL now categorizes
>>  errors
>> based on their phase of execution (read, macroexpand, compile, etc). Errors
>> carry additional information about location and context as data, and
>> present phase-specific error messages with better location reporting. This
>> functionality is built into the clojure.main REPL, but the functionality is
>> also available to other REPLs and tools with the ability to use and/or
>> modify the data to produce better error messages.
>>
>>
>> Clojure 1.10 now requires Java 8 or above and has been updated
>> particularly for compatibility with Java 8 and Java 11. Changes included
>> bytecode-related bug fixes, removed use of deprecated APIs, and updates
>> related to the module system introduced in Java 9.
>>
>>
>> See the change log
>> 
>> for a complete list of all fixes, enhancements, and new features in Clojure
>> 1.10.
>>
>>
>> Thanks to all of the community members who contributed patches to Clojure
>> 1.10 (first time contributors in bold):
>>
>>
>>-
>> *Alexander Kiel *
>>- *Ben Bader*
>>- Bruce Adams
>>- *Cezary Kosko*
>>- Erik Assum
>>- *Eugene Kostenko*
>>- Ghadi Shayban
>>- *Gijs Stuurman*
>>- Jozef Wagner
>>-
>> *Kwang Yul Seo *
>>- *Matthew Gilliard*
>>- Michał Marczyk
>>- Nicola Mometto
>>- Nikita Prokopov
>>-
>> *Sean Corfield *
>>- *Sebastien Martel*
>>- Shogo Ohta
>>- Stuart Sierra
>>
>> --
> 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.
>

-- 
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] Oz 1.4.0 - Interactive data visualizations and scientific documents with Vega/Vega-Lite

2018-12-18 Thread boris . schmid
Odd. The exact same code works for me. This is clojure 1.10/oz 1.4, and 
evaluating the whole blob from lighttable. 

I had to call (oz/v! line-plot) again to get it to show the figure, rather 
then the opening text. And you can leave out the (oz/start-plot-server!). It 
will start a server if it needs one.

I guess I have a similar workflow as Christopher, and similar needs in 
terms of visualization. I have used vega-lite through vizard and now oz for 
about a year now, after trying so many different visualization packages for 
clojure (Incanter/JFreechart, C2, quil, gyptis, quil/grafica, 
rojure->ggplot2, vizard). Really happy that oz takes vizard further. 
vega/vega-lite works really well with clojure.



On Tuesday, December 18, 2018 at 10:12:07 AM UTC+1, Juraj Martinka wrote:
>
> I'd like to try this but got stuck pretty early:
>
> (ns clojure-repl-experiments.visualizations.oz
>   (:require [oz.core :as oz]))
>
>
> (oz/start-plot-server!)
>
>
> (defn group-data [& names]
>   (apply concat (for [n names]
>   (map-indexed (fn [i x] {:x i :y x :col n}) (take 20 
> (repeatedly 
> #(rand-int 100)))
>
>
> (def line-plot
>   {:data {:values (group-data "monkey" "slipper" "broom")}
>:encoding {:x {:field "x"}
>   :y {:field "y"}
>   :color {:field "col" :type "nominal"}}
>:mark "line"})
>
>
> ;; Render the plot to the 
> (oz/v! line-plot)
>
>
>
> It has opened a new browser window at http://localhost:10666/ but I see 
> nothing only errors in the JS console:
> socket.cljs?rel=1502542805393:64 WebSocket connection to 
> 'ws://localhost:3449/figwheel-ws/dev' failed: Error in connection 
> establishment: net::ERR_CONNECTION_REFUSED
> figwheel$client$socket$open @ socket.cljs?rel=1502542805393:64
> 10:10:10.089 
>
> Does it require some special setup (figwheel)?
>
>
>
>
> On Monday, 17 December 2018 21:41:36 UTC+1, Christopher Small wrote:
>>
>>
>> Greetings!
>>
>> I'm happy to announce today the release of Oz 1.4.0.
>>
>> https://github.com/metasoarous/oz
>>
>> If you're on the Slack #datascience channel, you may have already caught 
>> wind of some earlier versions. But in the interest of introducing it more 
>> broadly, I'm posting an overview here for those of you who aren't familiar. 
>> If you *are* familiar, you may still wish to scroll down to the bottom 
>> as there are some new features available in the latest release.
>>
>>
>> *Vega & Vega-Lite*
>>
>> Oz is based on the fantastic Vega & Vega-Lite data visualization JS 
>> libraries, and so to really understand what Oz has to offer, it's best to 
>> start here. Vega & Vega-Lite are based on the seminal Grammar of Graphics, 
>> an approach to data visualization which emphasizes writing declarative 
>> descriptions of how properties of data should translate to aesthetic 
>> attributes of a visualization. This approach guided the design of the R's 
>> popular ggplot2 library, and has since influenced numerous libraries in 
>> other languages.
>>
>> Vega & Vega-Lite take this vision further in two important ways:
>>
>>1. In Vega & Vega-Lite, data visualizations are described using *pure 
>>data*. This makes it more declarative, and confers all the benefits 
>>we know and love about data-driven programming in Clojure. For instance, 
>>you can send a chunk of Vega or Vega-Lite data over the wire from one 
>>program to another effortlessly (as Oz does), and load it up in another 
>>process without having to worry about the security concerns of executing 
>>someone else's code. The bottom line is that Vega & Vega-Lite are 
>>philosophically and technically compatible with "the Clojure way" (IT'S. 
>>JUST. DATA.).
>>2. Vega & Vega-Lite take the Grammar of Graphics one step further by 
>>introducing a Grammar of Interaction. You can declaratively describe the 
>>addition of controls (dropdowns, checkboxes, etc) and interactive 
>>properties of the visualization itself (click, hover, etc), and use the 
>>data from these interactions to inform other parts of a visualization. 
>> For 
>>example, you might highlight a set of points in one part of a 
>>visualization, and display summary statistics about that selection in 
>>another. This is facilitated in part by a general purpose dataflow 
>> language 
>>as part of the greater spec.
>>
>> Vega itself is highly customizable and flexible, but somewhat verbose and 
>> not suitable for day to day visualization tasks. Vega-Lite steps in as a 
>> somewhat higher level and more automated flavor which itself compiles down 
>> to Vega. I have been using them together for a better part of a year now, 
>> and can say without reservation that they are amazing. For years I've 
>> longed for a ggplot2 from Clojure, and at long last I've found something 
>> that to my surprise has not only matched, but truly surpassed the standard 
>> bearer. In short, I'm sold.
>>
>> If you want to get a better sense of Veg

Re: Clojure 1.10 issue: thrown? no longer works on macros

2018-12-18 Thread Alex Miller
I think the relevant change here is that exceptions thrown during 
macroexpansion are now wrapped into CompilerExceptions as a way to attach 
all of the source context information. The REPL understands this and still 
prints the original cause so the printing hides some of that structure (but 
you can see it by looking at the exception chain). 

This here is a particularly tricky case here though and I think there might 
be something else coming into play, still looking at it. There was a couple 
other changes inside the compiler exception handling that might also be 
coming into play.

(Would have been great to see this during a pre-release build rather than 
after release! ;) 


On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote:
>
> Agreed.  It is not a problem for functions which throw AssertionErrors, 
> only macros.  But this is a change in behavior which breaks test suites 
> which passed previously.
>
> On Tue, Dec 18, 2018 at 1:48 AM alex  wrote:
>
>> I'm not sure, but probably it behaves so because of throwing at 
>> macroexpand stage.
>>
>> вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler написал:
>>>
>>> Consider the following macro:
>>>
>>> (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
>>> => (f 3)
>>> 8
>>> => (f true)
>>> Unexpected error (AssertionError) macroexpanding f at 
>>> (test:localhost:62048(clj)*:265:28).
>>> Assert failed: (number? x)
>>>
>>> So, as expected it throws an AssertionError if passed a non-number.
>>> However, the following test (using is from clojure.test) used to work 
>>> prior to 1.10, but now fails:
>>>
>>> => (is (thrown? AssertionError (f true)))
>>> Unexpected error (AssertionError) macroexpanding f at 
>>> (test:localhost:62048(clj)*:268:56).
>>> Assert failed: (number? x) 
>>>
>>> What's odd is that the macro still throws an AssertionError, but the 
>>> `thrown?` inside the `is` is no longer intercepting the AssertionError, so 
>>> the test doesn't pass -- instead the error causes a failure in the test 
>>> suite.
>>>
>>

-- 
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: Clojure 1.10 issue: thrown? no longer works on macros

2018-12-18 Thread Alex Miller
This particular example given fails in a similar way on 1.9. Could you give 
me something closer to what you are actually seeing in your test suite? 
Specifically something that is a passing clojure.test test on 1.9 but a 
failure/error on 1.10? 

The problem with the given example is that it fails during macroexpansion 
of the test itself, not during test execution, and I don't think that's the 
case you're trying to replicate.

On Tuesday, December 18, 2018 at 8:35:54 AM UTC-6, Alex Miller wrote:
>
> I think the relevant change here is that exceptions thrown during 
> macroexpansion are now wrapped into CompilerExceptions as a way to attach 
> all of the source context information. The REPL understands this and still 
> prints the original cause so the printing hides some of that structure (but 
> you can see it by looking at the exception chain). 
>
> This here is a particularly tricky case here though and I think there 
> might be something else coming into play, still looking at it. There was a 
> couple other changes inside the compiler exception handling that might also 
> be coming into play.
>
> (Would have been great to see this during a pre-release build rather than 
> after release! ;) 
>
>
> On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote:
>>
>> Agreed.  It is not a problem for functions which throw AssertionErrors, 
>> only macros.  But this is a change in behavior which breaks test suites 
>> which passed previously.
>>
>> On Tue, Dec 18, 2018 at 1:48 AM alex  wrote:
>>
>>> I'm not sure, but probably it behaves so because of throwing at 
>>> macroexpand stage.
>>>
>>> вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler написал:

 Consider the following macro:

 (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
 => (f 3)
 8
 => (f true)
 Unexpected error (AssertionError) macroexpanding f at 
 (test:localhost:62048(clj)*:265:28).
 Assert failed: (number? x)

 So, as expected it throws an AssertionError if passed a non-number.
 However, the following test (using is from clojure.test) used to work 
 prior to 1.10, but now fails:

 => (is (thrown? AssertionError (f true)))
 Unexpected error (AssertionError) macroexpanding f at 
 (test:localhost:62048(clj)*:268:56).
 Assert failed: (number? x) 

 What's odd is that the macro still throws an AssertionError, but the 
 `thrown?` inside the `is` is no longer intercepting the AssertionError, so 
 the test doesn't pass -- instead the error causes a failure in the test 
 suite.

>>>

-- 
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: Clojure 1.10 issue: thrown? no longer works on macros

2018-12-18 Thread Alex Miller
In particular, I am challenging this assertion from the original post:

However, the following test (using is from clojure.test) used to work prior 
to 1.10, but now fails:

=> (is (thrown? AssertionError (f true)))
Unexpected error (AssertionError) macroexpanding f at 
(test:localhost:62048(clj)*:268:56).
Assert failed: (number? x)


When I do this on 1.9 I see:

user=> (is (thrown? AssertionError (f true)))
CompilerException java.lang.AssertionError: Assert failed: (number? x), 
compiling:(NO_SOURCE_PATH:20:29)


Which is printed differently but is the same behavior, because this is 
happening while expanding the is, not during execution.

I believe you're seeing a change in your test suite, I'm just having a hard 
time reproducing what you're seeing.


On Tuesday, December 18, 2018 at 8:47:11 AM UTC-6, Alex Miller wrote:
>
> This particular example given fails in a similar way on 1.9. Could you 
> give me something closer to what you are actually seeing in your test 
> suite? Specifically something that is a passing clojure.test test on 1.9 
> but a failure/error on 1.10? 
>
> The problem with the given example is that it fails during macroexpansion 
> of the test itself, not during test execution, and I don't think that's the 
> case you're trying to replicate.
>
> On Tuesday, December 18, 2018 at 8:35:54 AM UTC-6, Alex Miller wrote:
>>
>> I think the relevant change here is that exceptions thrown during 
>> macroexpansion are now wrapped into CompilerExceptions as a way to attach 
>> all of the source context information. The REPL understands this and still 
>> prints the original cause so the printing hides some of that structure (but 
>> you can see it by looking at the exception chain). 
>>
>> This here is a particularly tricky case here though and I think there 
>> might be something else coming into play, still looking at it. There was a 
>> couple other changes inside the compiler exception handling that might also 
>> be coming into play.
>>
>> (Would have been great to see this during a pre-release build rather than 
>> after release! ;) 
>>
>>
>> On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote:
>>>
>>> Agreed.  It is not a problem for functions which throw AssertionErrors, 
>>> only macros.  But this is a change in behavior which breaks test suites 
>>> which passed previously.
>>>
>>> On Tue, Dec 18, 2018 at 1:48 AM alex  wrote:
>>>
 I'm not sure, but probably it behaves so because of throwing at 
 macroexpand stage.

 вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler 
 написал:
>
> Consider the following macro:
>
> (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
> => (f 3)
> 8
> => (f true)
> Unexpected error (AssertionError) macroexpanding f at 
> (test:localhost:62048(clj)*:265:28).
> Assert failed: (number? x)
>
> So, as expected it throws an AssertionError if passed a non-number.
> However, the following test (using is from clojure.test) used to work 
> prior to 1.10, but now fails:
>
> => (is (thrown? AssertionError (f true)))
> Unexpected error (AssertionError) macroexpanding f at 
> (test:localhost:62048(clj)*:268:56).
> Assert failed: (number? x) 
>
> What's odd is that the macro still throws an AssertionError, but the 
> `thrown?` inside the `is` is no longer intercepting the AssertionError, 
> so 
> the test doesn't pass -- instead the error causes a failure in the test 
> suite.
>


-- 
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] Clojure 1.10 has been released!

2018-12-18 Thread Ambrose Bonnaire-Sergeant
Thanks to everyone who designed, implemented, and tested this release!

On Tuesday, December 18, 2018 at 5:33:07 AM UTC-5, Rick Moynihan wrote:
>
> Great news, 
>
> Thanks to everyone who made this possible!
>
> R.
>
> On Tue, 18 Dec 2018 at 09:02, Thomas > 
> wrote:
>
>> Thank you for this release and all the hard work everyone has put into 
>> this!!!
>>
>> Thomas
>>
>> On Monday, 17 December 2018 18:30:01 UTC+1, Alex Miller wrote:
>>>
>>> Clojure 1.10 focuses on two major areas: improved error reporting and 
>>> Java compatibility.
>>>
>>>
>>> Error reporting at the REPL now categorizes 
>>>  errors 
>>> based on their phase of execution (read, macroexpand, compile, etc). Errors 
>>> carry additional information about location and context as data, and 
>>> present phase-specific error messages with better location reporting. This 
>>> functionality is built into the clojure.main REPL, but the functionality is 
>>> also available to other REPLs and tools with the ability to use and/or 
>>> modify the data to produce better error messages.
>>>
>>>
>>> Clojure 1.10 now requires Java 8 or above and has been updated 
>>> particularly for compatibility with Java 8 and Java 11. Changes included 
>>> bytecode-related bug fixes, removed use of deprecated APIs, and updates 
>>> related to the module system introduced in Java 9.
>>>
>>>
>>> See the change log 
>>> 
>>>  
>>> for a complete list of all fixes, enhancements, and new features in Clojure 
>>> 1.10.
>>>
>>>
>>> Thanks to all of the community members who contributed patches to 
>>> Clojure 1.10 (first time contributors in bold):
>>>
>>>
>>>- 
>>> *Alexander Kiel *
>>>- *Ben Bader*
>>>- Bruce Adams
>>>- *Cezary Kosko*
>>>- Erik Assum
>>>- *Eugene Kostenko*
>>>- Ghadi Shayban
>>>- *Gijs Stuurman*
>>>- Jozef Wagner
>>>- 
>>> *Kwang Yul Seo *
>>>- *Matthew Gilliard*
>>>- Michał Marczyk
>>>- Nicola Mometto
>>>- Nikita Prokopov
>>>- 
>>> *Sean Corfield *
>>>- *Sebastien Martel*
>>>- Shogo Ohta
>>>- Stuart Sierra
>>>
>>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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] Clojure 1.10 has been released!

2018-12-18 Thread Alex Miller
If you are a mac user, clj on brew has been updated to default to 1.10 now.

brew upgrade clojure


On Monday, December 17, 2018 at 11:30:01 AM UTC-6, Alex Miller wrote:
>
> Clojure 1.10 focuses on two major areas: improved error reporting and Java 
> compatibility.
>
>
> Error reporting at the REPL now categorizes 
>  errors 
> based on their phase of execution (read, macroexpand, compile, etc). Errors 
> carry additional information about location and context as data, and 
> present phase-specific error messages with better location reporting. This 
> functionality is built into the clojure.main REPL, but the functionality is 
> also available to other REPLs and tools with the ability to use and/or 
> modify the data to produce better error messages.
>
>
> Clojure 1.10 now requires Java 8 or above and has been updated 
> particularly for compatibility with Java 8 and Java 11. Changes included 
> bytecode-related bug fixes, removed use of deprecated APIs, and updates 
> related to the module system introduced in Java 9.
>
>
> See the change log 
> 
>  
> for a complete list of all fixes, enhancements, and new features in Clojure 
> 1.10.
>
>
> Thanks to all of the community members who contributed patches to Clojure 
> 1.10 (first time contributors in bold):
>
>
>- 
> *Alexander Kiel *
>- *Ben Bader*
>- Bruce Adams
>- *Cezary Kosko*
>- Erik Assum
>- *Eugene Kostenko*
>- Ghadi Shayban
>- *Gijs Stuurman*
>- Jozef Wagner
>- 
> *Kwang Yul Seo *
>- *Matthew Gilliard*
>- Michał Marczyk
>- Nicola Mometto
>- Nikita Prokopov
>- 
> *Sean Corfield *
>- *Sebastien Martel*
>- Shogo Ohta
>- Stuart Sierra
>
>

-- 
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] deps.edn dependency viewer

2018-12-18 Thread Chris Nuernberger
Clojurians-1.10.0:

I recently released a small project that allows you to view the entire
dependency graph of your deps.edn files.  You can do this from the command
line without installing anything or adding anything to your project.

https://github.com/cnuernber/depsviz


To do this, I had to get into some internal symbols in tools.deps.alpha and
I am relying heavily on its graph representation.  At some point, a
discussion about a public API/ABI about tools.deps.alpha would be good.


This came out of work to bring the excellent vizdeps leiningen plugin up to
date with leiningen 2.8.3:

(https://github.com/clj-commons/vizdeps)

I know that at least we have saved a *ton* of time using vizdeps.  Plus we
have been able to get visibility into larger systems and file appropriate
issues with appropriate projects when they had a serious transitive
dependency problems.

In any case, I hope that some of you find this helpful!  Please feel free
to file issues and PRs if something comes up.  I don't currently support
even nearly the entire range of possibilities in a deps.edn file (aliases
for example) so there are lots of opportunites for discussions and PRs.

-- 
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] deps.edn dependency viewer

2018-12-18 Thread Alex Miller
Great stuff! 

(btw, I had to "brew install graphviz" on mac first to make it work)

I looked at your tools.deps.alpha usage and I think you're fine on what 
you're using. I have thought about the api a lot and when we move out of 
alpha, I will try to make that clearer. Certainly, any public vars in tda, 
tda.reader, tda.extensions should all be considered part of the public api. 
Stuff under tda.script, tda.util, tda.extensions.* should right now mostly 
be treated as "use at your own risk". There are a few potential areas of 
change that need some more decision-making that may break those apis and I 
don't want to move out of alpha till we get past those.

Thanks!

On Tuesday, December 18, 2018 at 11:09:05 AM UTC-6, Chris Nuernberger wrote:
>
> Clojurians-1.10.0:
>
> I recently released a small project that allows you to view the entire 
> dependency graph of your deps.edn files.  You can do this from the command 
> line without installing anything or adding anything to your project.
>
> https://github.com/cnuernber/depsviz
>
>
> To do this, I had to get into some internal symbols in tools.deps.alpha 
> and I am relying heavily on its graph representation.  At some point, a 
> discussion about a public API/ABI about tools.deps.alpha would be good.
>
>
> This came out of work to bring the excellent vizdeps leiningen plugin up 
> to date with leiningen 2.8.3:
>
> (https://github.com/clj-commons/vizdeps)
>
> I know that at least we have saved a *ton* of time using vizdeps.  Plus we 
> have been able to get visibility into larger systems and file appropriate 
> issues with appropriate projects when they had a serious transitive 
> dependency problems.
>
> In any case, I hope that some of you find this helpful!  Please feel free 
> to file issues and PRs if something comes up.  I don't currently support 
> even nearly the entire range of possibilities in a deps.edn file (aliases 
> for example) so there are lots of opportunites for discussions and PRs.
>

-- 
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: Clojure 1.10 issue: thrown? no longer works on macros

2018-12-18 Thread Andy Fingerhut
I do not know if Leiningen is involved in the difference in the
reproduction project linked below yet (I am testing with the latest
Leiningen 2.8.3 here), but I do see a clojure.test `(is (thrown-with-msg?
...` expression that gives no error when running 'lein test' with Clojure
1.9.0, but does with Clojure 1.10.0.  I do not know if it is the same root
cause as Mark's example or not, but wanted to create this in hopes it
represents a minimal test case to reproduce the behavior difference.

https://github.com/jafingerhut/clojure-110-is-thrown

Andy

On Tue, Dec 18, 2018 at 7:07 AM Alex Miller  wrote:

> In particular, I am challenging this assertion from the original post:
>
> However, the following test (using is from clojure.test) used to work
> prior to 1.10, but now fails:
>
> => (is (thrown? AssertionError (f true)))
> Unexpected error (AssertionError) macroexpanding f at
> (test:localhost:62048(clj)*:268:56).
> Assert failed: (number? x)
>
>
> When I do this on 1.9 I see:
>
> user=> (is (thrown? AssertionError (f true)))
> CompilerException java.lang.AssertionError: Assert failed: (number? x),
> compiling:(NO_SOURCE_PATH:20:29)
>
>
> Which is printed differently but is the same behavior, because this is
> happening while expanding the is, not during execution.
>
> I believe you're seeing a change in your test suite, I'm just having a
> hard time reproducing what you're seeing.
>
>
> On Tuesday, December 18, 2018 at 8:47:11 AM UTC-6, Alex Miller wrote:
>>
>> This particular example given fails in a similar way on 1.9. Could you
>> give me something closer to what you are actually seeing in your test
>> suite? Specifically something that is a passing clojure.test test on 1.9
>> but a failure/error on 1.10?
>>
>> The problem with the given example is that it fails during macroexpansion
>> of the test itself, not during test execution, and I don't think that's the
>> case you're trying to replicate.
>>
>> On Tuesday, December 18, 2018 at 8:35:54 AM UTC-6, Alex Miller wrote:
>>>
>>> I think the relevant change here is that exceptions thrown during
>>> macroexpansion are now wrapped into CompilerExceptions as a way to attach
>>> all of the source context information. The REPL understands this and still
>>> prints the original cause so the printing hides some of that structure (but
>>> you can see it by looking at the exception chain).
>>>
>>> This here is a particularly tricky case here though and I think there
>>> might be something else coming into play, still looking at it. There was a
>>> couple other changes inside the compiler exception handling that might also
>>> be coming into play.
>>>
>>> (Would have been great to see this during a pre-release build rather
>>> than after release! ;)
>>>
>>>
>>> On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote:

 Agreed.  It is not a problem for functions which throw AssertionErrors,
 only macros.  But this is a change in behavior which breaks test suites
 which passed previously.

 On Tue, Dec 18, 2018 at 1:48 AM alex  wrote:

> I'm not sure, but probably it behaves so because of throwing at
> macroexpand stage.
>
> вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler
> написал:
>>
>> Consider the following macro:
>>
>> (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
>> => (f 3)
>> 8
>> => (f true)
>> Unexpected error (AssertionError) macroexpanding f at
>> (test:localhost:62048(clj)*:265:28).
>> Assert failed: (number? x)
>>
>> So, as expected it throws an AssertionError if passed a non-number.
>> However, the following test (using is from clojure.test) used to work
>> prior to 1.10, but now fails:
>>
>> => (is (thrown? AssertionError (f true)))
>> Unexpected error (AssertionError) macroexpanding f at
>> (test:localhost:62048(clj)*:268:56).
>> Assert failed: (number? x)
>>
>> What's odd is that the macro still throws an AssertionError, but the
>> `thrown?` inside the `is` is no longer intercepting the AssertionError, 
>> so
>> the test doesn't pass -- instead the error causes a failure in the test
>> suite.
>>
> --
> 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.
>

-- 
You received this message because you are subscribed to the 

Re: [ANN] Oz 1.4.0 - Interactive data visualizations and scientific documents with Vega/Vega-Lite

2018-12-18 Thread Christopher Small
Hi Juraj

The code you pasted *should* work. If you're still having trouble with
this, please raise a GH issue with all pertinent system/setup details so we
can sort it out there: https://github.com/metasoarous/oz/issues.

I can say that sometimes it takes a while for the websocket connection to
establish, and the exact time may depend a bit on machine details. This is
what Boris is getting at about having to to call `(oz/v! ...)` again
(Thanks for chiming in Boris!). The first thing to try is to just wait a
bit longer after calling `(oz/start-plot-server!)`, and try reevaluating
`(oz/v line-plot)`.

Oh... one last thing to check. If you had tried an older version of oz
prior to this and are just hoping to check out the updates (which I'm
wondering about in part because I see you're running the old example code,
though you could have gotten that from the video), it might be worth
running `lein clean` in case this is a problem with a stale build target.

Thanks!

Chris



On Tue, Dec 18, 2018 at 4:45 AM  wrote:

> Odd. The exact same code works for me. This is clojure 1.10/oz 1.4, and
> evaluating the whole blob from lighttable.
>
> I had to call (oz/v! line-plot) again to get it to show the figure,
> rather then the opening text. And you can leave out the (oz/start-plot-
> server!). It will start a server if it needs one.
>
> I guess I have a similar workflow as Christopher, and similar needs in
> terms of visualization. I have used vega-lite through vizard and now oz for
> about a year now, after trying so many different visualization packages for
> clojure (Incanter/JFreechart, C2, quil, gyptis, quil/grafica,
> rojure->ggplot2, vizard). Really happy that oz takes vizard further.
> vega/vega-lite works really well with clojure.
>
>
>
> On Tuesday, December 18, 2018 at 10:12:07 AM UTC+1, Juraj Martinka wrote:
>>
>> I'd like to try this but got stuck pretty early:
>>
>> (ns clojure-repl-experiments.visualizations.oz
>>   (:require [oz.core :as oz]))
>>
>>
>> (oz/start-plot-server!)
>>
>>
>> (defn group-data [& names]
>>   (apply concat (for [n names]
>>   (map-indexed (fn [i x] {:x i :y x :col n}) (take 20 
>> (repeatedly
>> #(rand-int 100)))
>>
>>
>> (def line-plot
>>   {:data {:values (group-data "monkey" "slipper" "broom")}
>>:encoding {:x {:field "x"}
>>   :y {:field "y"}
>>   :color {:field "col" :type "nominal"}}
>>:mark "line"})
>>
>>
>> ;; Render the plot to the
>> (oz/v! line-plot)
>>
>>
>>
>> It has opened a new browser window at http://localhost:10666/ but I see
>> nothing only errors in the JS console:
>> socket.cljs?rel=1502542805393:64 WebSocket connection to
>> 'ws://localhost:3449/figwheel-ws/dev' failed: Error in connection
>> establishment: net::ERR_CONNECTION_REFUSED
>> figwheel$client$socket$open @ socket.cljs?rel=1502542805393:64
>> 10:10:10.089
>>
>> Does it require some special setup (figwheel)?
>>
>>
>>
>>
>> On Monday, 17 December 2018 21:41:36 UTC+1, Christopher Small wrote:
>>>
>>>
>>> Greetings!
>>>
>>> I'm happy to announce today the release of Oz 1.4.0.
>>>
>>> https://github.com/metasoarous/oz
>>>
>>> If you're on the Slack #datascience channel, you may have already caught
>>> wind of some earlier versions. But in the interest of introducing it more
>>> broadly, I'm posting an overview here for those of you who aren't familiar.
>>> If you *are* familiar, you may still wish to scroll down to the bottom
>>> as there are some new features available in the latest release.
>>>
>>>
>>> *Vega & Vega-Lite*
>>>
>>> Oz is based on the fantastic Vega & Vega-Lite data visualization JS
>>> libraries, and so to really understand what Oz has to offer, it's best to
>>> start here. Vega & Vega-Lite are based on the seminal Grammar of Graphics,
>>> an approach to data visualization which emphasizes writing declarative
>>> descriptions of how properties of data should translate to aesthetic
>>> attributes of a visualization. This approach guided the design of the R's
>>> popular ggplot2 library, and has since influenced numerous libraries in
>>> other languages.
>>>
>>> Vega & Vega-Lite take this vision further in two important ways:
>>>
>>>1. In Vega & Vega-Lite, data visualizations are described using *pure
>>>data*. This makes it more declarative, and confers all the benefits
>>>we know and love about data-driven programming in Clojure. For instance,
>>>you can send a chunk of Vega or Vega-Lite data over the wire from one
>>>program to another effortlessly (as Oz does), and load it up in another
>>>process without having to worry about the security concerns of executing
>>>someone else's code. The bottom line is that Vega & Vega-Lite are
>>>philosophically and technically compatible with "the Clojure way" (IT'S.
>>>JUST. DATA.).
>>>2. Vega & Vega-Lite take the Grammar of Graphics one step further by
>>>introducing a Grammar of Interaction. You can declaratively describe the
>>>addition of contr

Re: Clojure 1.10 issue: thrown? no longer works on macros

2018-12-18 Thread Alex Miller
Leiningen monkey patches clojure.test so I tend not to trust it for repros.

> On Dec 18, 2018, at 12:05 PM, Andy Fingerhut  wrote:
> 
> I do not know if Leiningen is involved in the difference in the reproduction 
> project linked below yet (I am testing with the latest Leiningen 2.8.3 here), 
> but I do see a clojure.test `(is (thrown-with-msg? ...` expression that gives 
> no error when running 'lein test' with Clojure 1.9.0, but does with Clojure 
> 1.10.0.  I do not know if it is the same root cause as Mark's example or not, 
> but wanted to create this in hopes it represents a minimal test case to 
> reproduce the behavior difference.
> 
> https://github.com/jafingerhut/clojure-110-is-thrown
> 
> Andy
> 
>> On Tue, Dec 18, 2018 at 7:07 AM Alex Miller  wrote:
>> In particular, I am challenging this assertion from the original post:
>> 
>> However, the following test (using is from clojure.test) used to work prior 
>> to 1.10, but now fails:
>> 
>> => (is (thrown? AssertionError (f true)))
>> Unexpected error (AssertionError) macroexpanding f at 
>> (test:localhost:62048(clj)*:268:56).
>> Assert failed: (number? x)
>> 
>> When I do this on 1.9 I see:
>> 
>> user=> (is (thrown? AssertionError (f true)))
>> CompilerException java.lang.AssertionError: Assert failed: (number? x), 
>> compiling:(NO_SOURCE_PATH:20:29)
>> 
>> Which is printed differently but is the same behavior, because this is 
>> happening while expanding the is, not during execution.
>> 
>> I believe you're seeing a change in your test suite, I'm just having a hard 
>> time reproducing what you're seeing.
>> 
>> 
>>> On Tuesday, December 18, 2018 at 8:47:11 AM UTC-6, Alex Miller wrote:
>>> This particular example given fails in a similar way on 1.9. Could you give 
>>> me something closer to what you are actually seeing in your test suite? 
>>> Specifically something that is a passing clojure.test test on 1.9 but a 
>>> failure/error on 1.10? 
>>> 
>>> The problem with the given example is that it fails during macroexpansion 
>>> of the test itself, not during test execution, and I don't think that's the 
>>> case you're trying to replicate.
>>> 
 On Tuesday, December 18, 2018 at 8:35:54 AM UTC-6, Alex Miller wrote:
 I think the relevant change here is that exceptions thrown during 
 macroexpansion are now wrapped into CompilerExceptions as a way to attach 
 all of the source context information. The REPL understands this and still 
 prints the original cause so the printing hides some of that structure 
 (but you can see it by looking at the exception chain). 
 
 This here is a particularly tricky case here though and I think there 
 might be something else coming into play, still looking at it. There was a 
 couple other changes inside the compiler exception handling that might 
 also be coming into play.
 
 (Would have been great to see this during a pre-release build rather than 
 after release! ;) 
 
 
> On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote:
> Agreed.  It is not a problem for functions which throw AssertionErrors, 
> only macros.  But this is a change in behavior which breaks test suites 
> which passed previously.
> 
>> On Tue, Dec 18, 2018 at 1:48 AM alex  wrote:
>> I'm not sure, but probably it behaves so because of throwing at 
>> macroexpand stage.
>> 
>> вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler написал:
>>> 
>>> Consider the following macro:
>>> 
>>> (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
>>> => (f 3)
>>> 8
>>> => (f true)
>>> Unexpected error (AssertionError) macroexpanding f at 
>>> (test:localhost:62048(clj)*:265:28).
>>> Assert failed: (number? x)
>>> 
>>> So, as expected it throws an AssertionError if passed a non-number.
>>> However, the following test (using is from clojure.test) used to work 
>>> prior to 1.10, but now fails:
>>> 
>>> => (is (thrown? AssertionError (f true)))
>>> Unexpected error (AssertionError) macroexpanding f at 
>>> (test:localhost:62048(clj)*:268:56).
>>> Assert failed: (number? x)
>>> 
>>> What's odd is that the macro still throws an AssertionError, but the 
>>> `thrown?` inside the `is` is no longer intercepting the AssertionError, 
>>> so the test doesn't pass -- instead the error causes a failure in the 
>>> test suite.
>> 
>> -- 
>> 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 Gr

Re: [ANN] Oz 1.4.0 - Interactive data visualizations and scientific documents with Vega/Vega-Lite

2018-12-18 Thread Alan Thompson
Looks very nice.  I will definitely be using this in the future.
Alan

On Tue, Dec 18, 2018 at 4:44 AM  wrote:

> Odd. The exact same code works for me. This is clojure 1.10/oz 1.4, and
> evaluating the whole blob from lighttable.
>
> I had to call (oz/v! line-plot) again to get it to show the figure,
> rather then the opening text. And you can leave out the (oz/start-plot-
> server!). It will start a server if it needs one.
>
> I guess I have a similar workflow as Christopher, and similar needs in
> terms of visualization. I have used vega-lite through vizard and now oz for
> about a year now, after trying so many different visualization packages for
> clojure (Incanter/JFreechart, C2, quil, gyptis, quil/grafica,
> rojure->ggplot2, vizard). Really happy that oz takes vizard further.
> vega/vega-lite works really well with clojure.
>
>
>
> On Tuesday, December 18, 2018 at 10:12:07 AM UTC+1, Juraj Martinka wrote:
>>
>> I'd like to try this but got stuck pretty early:
>>
>> (ns clojure-repl-experiments.visualizations.oz
>>   (:require [oz.core :as oz]))
>>
>>
>> (oz/start-plot-server!)
>>
>>
>> (defn group-data [& names]
>>   (apply concat (for [n names]
>>   (map-indexed (fn [i x] {:x i :y x :col n}) (take 20 
>> (repeatedly
>> #(rand-int 100)))
>>
>>
>> (def line-plot
>>   {:data {:values (group-data "monkey" "slipper" "broom")}
>>:encoding {:x {:field "x"}
>>   :y {:field "y"}
>>   :color {:field "col" :type "nominal"}}
>>:mark "line"})
>>
>>
>> ;; Render the plot to the
>> (oz/v! line-plot)
>>
>>
>>
>> It has opened a new browser window at http://localhost:10666/ but I see
>> nothing only errors in the JS console:
>> socket.cljs?rel=1502542805393:64 WebSocket connection to
>> 'ws://localhost:3449/figwheel-ws/dev' failed: Error in connection
>> establishment: net::ERR_CONNECTION_REFUSED
>> figwheel$client$socket$open @ socket.cljs?rel=1502542805393:64
>> 10:10:10.089
>>
>> Does it require some special setup (figwheel)?
>>
>>
>>
>>
>> On Monday, 17 December 2018 21:41:36 UTC+1, Christopher Small wrote:
>>>
>>>
>>> Greetings!
>>>
>>> I'm happy to announce today the release of Oz 1.4.0.
>>>
>>> https://github.com/metasoarous/oz
>>>
>>> If you're on the Slack #datascience channel, you may have already caught
>>> wind of some earlier versions. But in the interest of introducing it more
>>> broadly, I'm posting an overview here for those of you who aren't familiar.
>>> If you *are* familiar, you may still wish to scroll down to the bottom
>>> as there are some new features available in the latest release.
>>>
>>>
>>> *Vega & Vega-Lite*
>>>
>>> Oz is based on the fantastic Vega & Vega-Lite data visualization JS
>>> libraries, and so to really understand what Oz has to offer, it's best to
>>> start here. Vega & Vega-Lite are based on the seminal Grammar of Graphics,
>>> an approach to data visualization which emphasizes writing declarative
>>> descriptions of how properties of data should translate to aesthetic
>>> attributes of a visualization. This approach guided the design of the R's
>>> popular ggplot2 library, and has since influenced numerous libraries in
>>> other languages.
>>>
>>> Vega & Vega-Lite take this vision further in two important ways:
>>>
>>>1. In Vega & Vega-Lite, data visualizations are described using *pure
>>>data*. This makes it more declarative, and confers all the benefits
>>>we know and love about data-driven programming in Clojure. For instance,
>>>you can send a chunk of Vega or Vega-Lite data over the wire from one
>>>program to another effortlessly (as Oz does), and load it up in another
>>>process without having to worry about the security concerns of executing
>>>someone else's code. The bottom line is that Vega & Vega-Lite are
>>>philosophically and technically compatible with "the Clojure way" (IT'S.
>>>JUST. DATA.).
>>>2. Vega & Vega-Lite take the Grammar of Graphics one step further by
>>>introducing a Grammar of Interaction. You can declaratively describe the
>>>addition of controls (dropdowns, checkboxes, etc) and interactive
>>>properties of the visualization itself (click, hover, etc), and use the
>>>data from these interactions to inform other parts of a visualization. 
>>> For
>>>example, you might highlight a set of points in one part of a
>>>visualization, and display summary statistics about that selection in
>>>another. This is facilitated in part by a general purpose dataflow 
>>> language
>>>as part of the greater spec.
>>>
>>> Vega itself is highly customizable and flexible, but somewhat verbose
>>> and not suitable for day to day visualization tasks. Vega-Lite steps in as
>>> a somewhat higher level and more automated flavor which itself compiles
>>> down to Vega. I have been using them together for a better part of a year
>>> now, and can say without reservation that they are amazing. For years I've
>>> longed for a ggplot2 from Clojure, a

Re: Clojure 1.10 issue: thrown? no longer works on macros

2018-12-18 Thread Alex Miller
Oh, if you're testing with thrown-with-msg?, that definitely can have an 
impact due to the nested exception. In clojure.test, I'm using a variant to 
test the message with the root cause:

https://github.com/clojure/clojure/blob/master/test/clojure/test_helper.clj#L134-L151

On Tuesday, December 18, 2018 at 12:06:18 PM UTC-6, Andy Fingerhut wrote:
>
> I do not know if Leiningen is involved in the difference in the 
> reproduction project linked below yet (I am testing with the latest 
> Leiningen 2.8.3 here), but I do see a clojure.test `(is (thrown-with-msg? 
> ...` expression that gives no error when running 'lein test' with Clojure 
> 1.9.0, but does with Clojure 1.10.0.  I do not know if it is the same root 
> cause as Mark's example or not, but wanted to create this in hopes it 
> represents a minimal test case to reproduce the behavior difference.
>
> https://github.com/jafingerhut/clojure-110-is-thrown
>
> Andy
>
> On Tue, Dec 18, 2018 at 7:07 AM Alex Miller  wrote:
>
>> In particular, I am challenging this assertion from the original post:
>>
>> However, the following test (using is from clojure.test) used to work 
>> prior to 1.10, but now fails:
>>
>> => (is (thrown? AssertionError (f true)))
>> Unexpected error (AssertionError) macroexpanding f at 
>> (test:localhost:62048(clj)*:268:56).
>> Assert failed: (number? x)
>>
>>
>> When I do this on 1.9 I see:
>>
>> user=> (is (thrown? AssertionError (f true)))
>> CompilerException java.lang.AssertionError: Assert failed: (number? x), 
>> compiling:(NO_SOURCE_PATH:20:29)
>>
>>
>> Which is printed differently but is the same behavior, because this is 
>> happening while expanding the is, not during execution.
>>
>> I believe you're seeing a change in your test suite, I'm just having a 
>> hard time reproducing what you're seeing.
>>
>>
>> On Tuesday, December 18, 2018 at 8:47:11 AM UTC-6, Alex Miller wrote:
>>>
>>> This particular example given fails in a similar way on 1.9. Could you 
>>> give me something closer to what you are actually seeing in your test 
>>> suite? Specifically something that is a passing clojure.test test on 1.9 
>>> but a failure/error on 1.10? 
>>>
>>> The problem with the given example is that it fails during 
>>> macroexpansion of the test itself, not during test execution, and I don't 
>>> think that's the case you're trying to replicate.
>>>
>>> On Tuesday, December 18, 2018 at 8:35:54 AM UTC-6, Alex Miller wrote:

 I think the relevant change here is that exceptions thrown during 
 macroexpansion are now wrapped into CompilerExceptions as a way to attach 
 all of the source context information. The REPL understands this and still 
 prints the original cause so the printing hides some of that structure 
 (but 
 you can see it by looking at the exception chain). 

 This here is a particularly tricky case here though and I think there 
 might be something else coming into play, still looking at it. There was a 
 couple other changes inside the compiler exception handling that might 
 also 
 be coming into play.

 (Would have been great to see this during a pre-release build rather 
 than after release! ;) 


 On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote:
>
> Agreed.  It is not a problem for functions which throw 
> AssertionErrors, only macros.  But this is a change in behavior which 
> breaks test suites which passed previously.
>
> On Tue, Dec 18, 2018 at 1:48 AM alex  wrote:
>
>> I'm not sure, but probably it behaves so because of throwing at 
>> macroexpand stage.
>>
>> вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler 
>> написал:
>>>
>>> Consider the following macro:
>>>
>>> (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
>>> => (f 3)
>>> 8
>>> => (f true)
>>> Unexpected error (AssertionError) macroexpanding f at 
>>> (test:localhost:62048(clj)*:265:28).
>>> Assert failed: (number? x)
>>>
>>> So, as expected it throws an AssertionError if passed a non-number.
>>> However, the following test (using is from clojure.test) used to 
>>> work prior to 1.10, but now fails:
>>>
>>> => (is (thrown? AssertionError (f true)))
>>> Unexpected error (AssertionError) macroexpanding f at 
>>> (test:localhost:62048(clj)*:268:56).
>>> Assert failed: (number? x) 
>>>
>>> What's odd is that the macro still throws an AssertionError, but the 
>>> `thrown?` inside the `is` is no longer intercepting the AssertionError, 
>>> so 
>>> the test doesn't pass -- instead the error causes a failure in the test 
>>> suite.
>>>
>> -- 
>> 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.
>>

Re: [ANN] Oz 1.4.0 - Interactive data visualizations and scientific documents with Vega/Vega-Lite

2018-12-18 Thread Juraj Martinka
Hi Chris and Boris,
Thanks for the quick response.

Here's the minimal example: https://github.com/jumarko/oz-sample
It looks like a dependency conflict with something in my 
~/.lein/profiles.clj
If I run it via `lein repl` it fails.
If I run it only with proflie then it works!
lein with-profile base repl

I did some aggressive cleanup of my profiles.clj and I can run it now.
Unfortunately, I can't really tell what was the offending dependency since 
I removed lots of them
(I tried to exclude several of them one-by-one but didn't find the 
problematic one).

Now when it's working, I'm really looking forward to playing with this. 
Would you mind sharing more info about your workflow and how you typically 
use it?
Is it something you'd use for debugging for example?

Thanks again for your help.


On Tuesday, 18 December 2018 19:25:11 UTC+1, Christopher Small wrote:
>
> Hi Juraj
>
> The code you pasted *should* work. If you're still having trouble with 
> this, please raise a GH issue with all pertinent system/setup details so we 
> can sort it out there: https://github.com/metasoarous/oz/issues.
>
> I can say that sometimes it takes a while for the websocket connection to 
> establish, and the exact time may depend a bit on machine details. This is 
> what Boris is getting at about having to to call `(oz/v! ...)` again 
> (Thanks for chiming in Boris!). The first thing to try is to just wait a 
> bit longer after calling `(oz/start-plot-server!)`, and try reevaluating 
> `(oz/v line-plot)`.
>
> Oh... one last thing to check. If you had tried an older version of oz 
> prior to this and are just hoping to check out the updates (which I'm 
> wondering about in part because I see you're running the old example code, 
> though you could have gotten that from the video), it might be worth 
> running `lein clean` in case this is a problem with a stale build target.
>
> Thanks!
>
> Chris
>
>
>
> On Tue, Dec 18, 2018 at 4:45 AM > wrote:
>
>> Odd. The exact same code works for me. This is clojure 1.10/oz 1.4, and 
>> evaluating the whole blob from lighttable. 
>>
>> I had to call (oz/v! line-plot) again to get it to show the figure, 
>> rather then the opening text. And you can leave out the (oz/start-plot-
>> server!). It will start a server if it needs one.
>>
>> I guess I have a similar workflow as Christopher, and similar needs in 
>> terms of visualization. I have used vega-lite through vizard and now oz for 
>> about a year now, after trying so many different visualization packages for 
>> clojure (Incanter/JFreechart, C2, quil, gyptis, quil/grafica, 
>> rojure->ggplot2, vizard). Really happy that oz takes vizard further. 
>> vega/vega-lite works really well with clojure.
>>
>>
>>
>> On Tuesday, December 18, 2018 at 10:12:07 AM UTC+1, Juraj Martinka wrote:
>>>
>>> I'd like to try this but got stuck pretty early:
>>>
>>> (ns clojure-repl-experiments.visualizations.oz
>>>   (:require [oz.core :as oz]))
>>>
>>>
>>> (oz/start-plot-server!)
>>>
>>>
>>> (defn group-data [& names]
>>>   (apply concat (for [n names]
>>>   (map-indexed (fn [i x] {:x i :y x :col n}) (take 20 
>>> (repeatedly 
>>> #(rand-int 100)))
>>>
>>>
>>> (def line-plot
>>>   {:data {:values (group-data "monkey" "slipper" "broom")}
>>>:encoding {:x {:field "x"}
>>>   :y {:field "y"}
>>>   :color {:field "col" :type "nominal"}}
>>>:mark "line"})
>>>
>>>
>>> ;; Render the plot to the 
>>> (oz/v! line-plot)
>>>
>>>
>>>
>>> It has opened a new browser window at http://localhost:10666/ but I see 
>>> nothing only errors in the JS console:
>>> socket.cljs?rel=1502542805393:64 WebSocket connection to 
>>> 'ws://localhost:3449/figwheel-ws/dev' failed: Error in connection 
>>> establishment: net::ERR_CONNECTION_REFUSED
>>> figwheel$client$socket$open @ socket.cljs?rel=1502542805393:64
>>> 10:10:10.089 
>>>
>>> Does it require some special setup (figwheel)?
>>>
>>>
>>>
>>>
>>> On Monday, 17 December 2018 21:41:36 UTC+1, Christopher Small wrote:


 Greetings!

 I'm happy to announce today the release of Oz 1.4.0.

 https://github.com/metasoarous/oz

 If you're on the Slack #datascience channel, you may have already 
 caught wind of some earlier versions. But in the interest of introducing 
 it 
 more broadly, I'm posting an overview here for those of you who aren't 
 familiar. If you *are* familiar, you may still wish to scroll down to 
 the bottom as there are some new features available in the latest release.


 *Vega & Vega-Lite*

 Oz is based on the fantastic Vega & Vega-Lite data visualization JS 
 libraries, and so to really understand what Oz has to offer, it's best to 
 start here. Vega & Vega-Lite are based on the seminal Grammar of Graphics, 
 an approach to data visualization which emphasizes writing declarative 
 descriptions of how properties of data should translate to aesthetic 
 attributes of a visual

Re: Clojure 1.10 issue: thrown? no longer works on macros

2018-12-18 Thread Mark Engelberg
Sorry, I tried to "shrink the error case" and I appear to have gone too
far.  The actual problem would be more like:
=> (is (thrown? AssertionError (eval (quote (f true

On Tue, Dec 18, 2018 at 11:11 AM Alex Miller  wrote:

> Oh, if you're testing with thrown-with-msg?, that definitely can have an
> impact due to the nested exception. In clojure.test, I'm using a variant to
> test the message with the root cause:
>
>
> https://github.com/clojure/clojure/blob/master/test/clojure/test_helper.clj#L134-L151
>
> On Tuesday, December 18, 2018 at 12:06:18 PM UTC-6, Andy Fingerhut wrote:
>>
>> I do not know if Leiningen is involved in the difference in the
>> reproduction project linked below yet (I am testing with the latest
>> Leiningen 2.8.3 here), but I do see a clojure.test `(is (thrown-with-msg?
>> ...` expression that gives no error when running 'lein test' with Clojure
>> 1.9.0, but does with Clojure 1.10.0.  I do not know if it is the same root
>> cause as Mark's example or not, but wanted to create this in hopes it
>> represents a minimal test case to reproduce the behavior difference.
>>
>> https://github.com/jafingerhut/clojure-110-is-thrown
>>
>> Andy
>>
>> On Tue, Dec 18, 2018 at 7:07 AM Alex Miller  wrote:
>>
>>> In particular, I am challenging this assertion from the original post:
>>>
>>> However, the following test (using is from clojure.test) used to work
>>> prior to 1.10, but now fails:
>>>
>>> => (is (thrown? AssertionError (f true)))
>>> Unexpected error (AssertionError) macroexpanding f at
>>> (test:localhost:62048(clj)*:268:56).
>>> Assert failed: (number? x)
>>>
>>>
>>> When I do this on 1.9 I see:
>>>
>>> user=> (is (thrown? AssertionError (f true)))
>>> CompilerException java.lang.AssertionError: Assert failed: (number? x),
>>> compiling:(NO_SOURCE_PATH:20:29)
>>>
>>>
>>> Which is printed differently but is the same behavior, because this is
>>> happening while expanding the is, not during execution.
>>>
>>> I believe you're seeing a change in your test suite, I'm just having a
>>> hard time reproducing what you're seeing.
>>>
>>>
>>> On Tuesday, December 18, 2018 at 8:47:11 AM UTC-6, Alex Miller wrote:

 This particular example given fails in a similar way on 1.9. Could you
 give me something closer to what you are actually seeing in your test
 suite? Specifically something that is a passing clojure.test test on 1.9
 but a failure/error on 1.10?

 The problem with the given example is that it fails during
 macroexpansion of the test itself, not during test execution, and I don't
 think that's the case you're trying to replicate.

 On Tuesday, December 18, 2018 at 8:35:54 AM UTC-6, Alex Miller wrote:
>
> I think the relevant change here is that exceptions thrown during
> macroexpansion are now wrapped into CompilerExceptions as a way to attach
> all of the source context information. The REPL understands this and still
> prints the original cause so the printing hides some of that structure 
> (but
> you can see it by looking at the exception chain).
>
> This here is a particularly tricky case here though and I think there
> might be something else coming into play, still looking at it. There was a
> couple other changes inside the compiler exception handling that might 
> also
> be coming into play.
>
> (Would have been great to see this during a pre-release build rather
> than after release! ;)
>
>
> On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote:
>>
>> Agreed.  It is not a problem for functions which throw
>> AssertionErrors, only macros.  But this is a change in behavior which
>> breaks test suites which passed previously.
>>
>> On Tue, Dec 18, 2018 at 1:48 AM alex  wrote:
>>
>>> I'm not sure, but probably it behaves so because of throwing at
>>> macroexpand stage.
>>>
>>> вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler
>>> написал:

 Consider the following macro:

 (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
 => (f 3)
 8
 => (f true)
 Unexpected error (AssertionError) macroexpanding f at
 (test:localhost:62048(clj)*:265:28).
 Assert failed: (number? x)

 So, as expected it throws an AssertionError if passed a non-number.
 However, the following test (using is from clojure.test) used to
 work prior to 1.10, but now fails:

 => (is (thrown? AssertionError (f true)))
 Unexpected error (AssertionError) macroexpanding f at
 (test:localhost:62048(clj)*:268:56).
 Assert failed: (number? x)

 What's odd is that the macro still throws an AssertionError, but
 the `thrown?` inside the `is` is no longer intercepting the 
 AssertionError,
 so the test doesn't pass -- instead the error causes a failu

Re: Clojure 1.10 issue: thrown? no longer works on macros

2018-12-18 Thread Mark Engelberg
And to be as specific as possible, the actual test that worked in 1.9 but
not in 1.10 is:
https://github.com/Engelberg/instaparse/blob/dcfffad5b065e750f0f5835f017cdd8188b8ca2e/test/instaparse/defparser_test.cljc#L34

I've temporarily elided the test from the instaparse test suite, but wanted
to report it.  Again, I apologize for not realizing the eval/quote was an
important aspect and leading you down a rabbit hole.

On Tue, Dec 18, 2018 at 12:21 PM Mark Engelberg 
wrote:

> Sorry, I tried to "shrink the error case" and I appear to have gone too
> far.  The actual problem would be more like:
> => (is (thrown? AssertionError (eval (quote (f true
>
> On Tue, Dec 18, 2018 at 11:11 AM Alex Miller  wrote:
>
>> Oh, if you're testing with thrown-with-msg?, that definitely can have an
>> impact due to the nested exception. In clojure.test, I'm using a variant to
>> test the message with the root cause:
>>
>>
>> https://github.com/clojure/clojure/blob/master/test/clojure/test_helper.clj#L134-L151
>>
>> On Tuesday, December 18, 2018 at 12:06:18 PM UTC-6, Andy Fingerhut wrote:
>>>
>>> I do not know if Leiningen is involved in the difference in the
>>> reproduction project linked below yet (I am testing with the latest
>>> Leiningen 2.8.3 here), but I do see a clojure.test `(is (thrown-with-msg?
>>> ...` expression that gives no error when running 'lein test' with Clojure
>>> 1.9.0, but does with Clojure 1.10.0.  I do not know if it is the same root
>>> cause as Mark's example or not, but wanted to create this in hopes it
>>> represents a minimal test case to reproduce the behavior difference.
>>>
>>> https://github.com/jafingerhut/clojure-110-is-thrown
>>>
>>> Andy
>>>
>>> On Tue, Dec 18, 2018 at 7:07 AM Alex Miller  wrote:
>>>
 In particular, I am challenging this assertion from the original post:

 However, the following test (using is from clojure.test) used to work
 prior to 1.10, but now fails:

 => (is (thrown? AssertionError (f true)))
 Unexpected error (AssertionError) macroexpanding f at
 (test:localhost:62048(clj)*:268:56).
 Assert failed: (number? x)


 When I do this on 1.9 I see:

 user=> (is (thrown? AssertionError (f true)))
 CompilerException java.lang.AssertionError: Assert failed: (number? x),
 compiling:(NO_SOURCE_PATH:20:29)


 Which is printed differently but is the same behavior, because this is
 happening while expanding the is, not during execution.

 I believe you're seeing a change in your test suite, I'm just having a
 hard time reproducing what you're seeing.


 On Tuesday, December 18, 2018 at 8:47:11 AM UTC-6, Alex Miller wrote:
>
> This particular example given fails in a similar way on 1.9. Could you
> give me something closer to what you are actually seeing in your test
> suite? Specifically something that is a passing clojure.test test on 1.9
> but a failure/error on 1.10?
>
> The problem with the given example is that it fails during
> macroexpansion of the test itself, not during test execution, and I don't
> think that's the case you're trying to replicate.
>
> On Tuesday, December 18, 2018 at 8:35:54 AM UTC-6, Alex Miller wrote:
>>
>> I think the relevant change here is that exceptions thrown during
>> macroexpansion are now wrapped into CompilerExceptions as a way to attach
>> all of the source context information. The REPL understands this and 
>> still
>> prints the original cause so the printing hides some of that structure 
>> (but
>> you can see it by looking at the exception chain).
>>
>> This here is a particularly tricky case here though and I think there
>> might be something else coming into play, still looking at it. There was 
>> a
>> couple other changes inside the compiler exception handling that might 
>> also
>> be coming into play.
>>
>> (Would have been great to see this during a pre-release build rather
>> than after release! ;)
>>
>>
>> On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote:
>>>
>>> Agreed.  It is not a problem for functions which throw
>>> AssertionErrors, only macros.  But this is a change in behavior which
>>> breaks test suites which passed previously.
>>>
>>> On Tue, Dec 18, 2018 at 1:48 AM alex  wrote:
>>>
 I'm not sure, but probably it behaves so because of throwing at
 macroexpand stage.

 вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler
 написал:
>
> Consider the following macro:
>
> (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
> => (f 3)
> 8
> => (f true)
> Unexpected error (AssertionError) macroexpanding f at
> (test:localhost:62048(clj)*:265:28).
> Assert failed: (number? x)
>
> So, as expected it throws an As

Re: Clojure 1.10 issue: thrown? no longer works on macros

2018-12-18 Thread Mark Engelberg
And the macro which that test case exercises can be found here:
https://github.com/Engelberg/instaparse/blob/dcfffad5b065e750f0f5835f017cdd8188b8ca2e/src/instaparse/core.cljc#L274

-- 
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.


Building a formatter like gofmt for Clojure

2018-12-18 Thread Daniel Compton
Hi folks

In the last ten years or so, source code formatters with limited/no
configuration have become popular. Go is the most well-known example,
shipping with gofmt, but there are similar tools in Rust, JavaScript,
Python, and Elixir.

Clojure and Lisps, in general, have historically allowed very flexible
formatting of s-expressions. This can aid readability but adds a cognitive
overhead for readers used to different styles. It can also be challenging
to match existing source code formatting if you are using a different
editor to the original author.

*I believe it would be useful for the Clojure community to be able to
develop (or adopt) a single source-code formatter which is able to format
Clojure source code to a canonical format.* It seems unlikely that 100%
(maybe not even 50%) of the community would want such a tool, but I feel
like there is enough desire for a common formatting tool that this could
still be valuable.

I've created a discussion thread

on ClojureVerse about building a Clojure/ClojureScript source code
formatter as part of CLJ Commons . There are a
few differences in goals between this tool and the existing ones that
exist. I go into more detail in the thread, but I'm proposing the creation
of

* A fairly canonical format for Clojure code, e.g. reindenting code,
reformatting namespace declarations. A format that has idiomatic opinions.
* A formatting spec and test suite that multiple different tools and
editors can implement, not a spec defined by the implementation of a single
tool.
* The creation of a reference implementation formatter.
* A formatter with few (maybe zero?) options

It's possible that 10 years after Clojure's creation, it's going to be too
difficult for the community to coalesce around a canonical format, and it
will be necessary to add some configuration options. I'm not really sure,
which is why I'm asking for community members to join in the discussion.

I realise that I'm touching the third rail
 here, and lots of
people have strong opinions about formatting. I don't expect that everyone
would like or want to adopt such a strict formatting tool, and that's
totally ok! For those of you that *do* like the idea of building/having
such a tool, please jump in on the discussion on ClojureVerse, and on a
GitHub repo discussing the different aspects of formatting at
https://github.com/clj-commons/formatter.

Thanks, Daniel.

-- 
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: Clojure 1.10 issue: thrown? no longer works on macros

2018-12-18 Thread Andy Fingerhut
Alex, just so I understand, are you saying that because of the
implementation of `(is (thrown-with-msg? ..))` and the changes to
exceptions in Clojure 1.10.0, that other Clojure programs that use `(is
(thrown-with-msg? ...))` may need to be updated to use something similar to
what you linked, in order to test the new Clojure 1.10.0 behavior?

Thanks,
Andy


On Tue, Dec 18, 2018 at 11:12 AM Alex Miller  wrote:

> Oh, if you're testing with thrown-with-msg?, that definitely can have an
> impact due to the nested exception. In clojure.test, I'm using a variant to
> test the message with the root cause:
>
>
> https://github.com/clojure/clojure/blob/master/test/clojure/test_helper.clj#L134-L151
>
> On Tuesday, December 18, 2018 at 12:06:18 PM UTC-6, Andy Fingerhut wrote:
>>
>> I do not know if Leiningen is involved in the difference in the
>> reproduction project linked below yet (I am testing with the latest
>> Leiningen 2.8.3 here), but I do see a clojure.test `(is (thrown-with-msg?
>> ...` expression that gives no error when running 'lein test' with Clojure
>> 1.9.0, but does with Clojure 1.10.0.  I do not know if it is the same root
>> cause as Mark's example or not, but wanted to create this in hopes it
>> represents a minimal test case to reproduce the behavior difference.
>>
>> https://github.com/jafingerhut/clojure-110-is-thrown
>>
>> Andy
>>
>> On Tue, Dec 18, 2018 at 7:07 AM Alex Miller  wrote:
>>
>>> In particular, I am challenging this assertion from the original post:
>>>
>>> However, the following test (using is from clojure.test) used to work
>>> prior to 1.10, but now fails:
>>>
>>> => (is (thrown? AssertionError (f true)))
>>> Unexpected error (AssertionError) macroexpanding f at
>>> (test:localhost:62048(clj)*:268:56).
>>> Assert failed: (number? x)
>>>
>>>
>>> When I do this on 1.9 I see:
>>>
>>> user=> (is (thrown? AssertionError (f true)))
>>> CompilerException java.lang.AssertionError: Assert failed: (number? x),
>>> compiling:(NO_SOURCE_PATH:20:29)
>>>
>>>
>>> Which is printed differently but is the same behavior, because this is
>>> happening while expanding the is, not during execution.
>>>
>>> I believe you're seeing a change in your test suite, I'm just having a
>>> hard time reproducing what you're seeing.
>>>
>>>
>>> On Tuesday, December 18, 2018 at 8:47:11 AM UTC-6, Alex Miller wrote:

 This particular example given fails in a similar way on 1.9. Could you
 give me something closer to what you are actually seeing in your test
 suite? Specifically something that is a passing clojure.test test on 1.9
 but a failure/error on 1.10?

 The problem with the given example is that it fails during
 macroexpansion of the test itself, not during test execution, and I don't
 think that's the case you're trying to replicate.

 On Tuesday, December 18, 2018 at 8:35:54 AM UTC-6, Alex Miller wrote:
>
> I think the relevant change here is that exceptions thrown during
> macroexpansion are now wrapped into CompilerExceptions as a way to attach
> all of the source context information. The REPL understands this and still
> prints the original cause so the printing hides some of that structure 
> (but
> you can see it by looking at the exception chain).
>
> This here is a particularly tricky case here though and I think there
> might be something else coming into play, still looking at it. There was a
> couple other changes inside the compiler exception handling that might 
> also
> be coming into play.
>
> (Would have been great to see this during a pre-release build rather
> than after release! ;)
>
>
> On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote:
>>
>> Agreed.  It is not a problem for functions which throw
>> AssertionErrors, only macros.  But this is a change in behavior which
>> breaks test suites which passed previously.
>>
>> On Tue, Dec 18, 2018 at 1:48 AM alex  wrote:
>>
>>> I'm not sure, but probably it behaves so because of throwing at
>>> macroexpand stage.
>>>
>>> вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler
>>> написал:

 Consider the following macro:

 (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
 => (f 3)
 8
 => (f true)
 Unexpected error (AssertionError) macroexpanding f at
 (test:localhost:62048(clj)*:265:28).
 Assert failed: (number? x)

 So, as expected it throws an AssertionError if passed a non-number.
 However, the following test (using is from clojure.test) used to
 work prior to 1.10, but now fails:

 => (is (thrown? AssertionError (f true)))
 Unexpected error (AssertionError) macroexpanding f at
 (test:localhost:62048(clj)*:268:56).
 Assert failed: (number? x)

 What's odd is that the macro still throws a

Re: Clojure 1.10 issue: thrown? no longer works on macros

2018-12-18 Thread Alex Miller
No, I'm not saying that - the reason I was looking at cause was due to some 
gnarly exception check messages for compiling Clojure code. I'm not sure 
that these are applicable in general. Given that this is not what the 
original case was, I think we should set that aside for now.

Going back to the original instaparse case (with thrown?), I reproduced 
that and then simplified it down to this: 

Pick a version:
  clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.9.0"}}}'
  clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0"}}}'

Repro:
 
(use 'clojure.test)
(defmacro p [k] {:pre [(keyword? k)]} [])
(is (thrown? AssertionError (eval '(p 1
;; 1.9:  passes, returns the error
;; 1.10: fails test\
Note that there are several unique factors about this case, specifically 
that it involves a macro precondition, triggered in an eval, in a deftest 
"is". 

Just throwing an exception (no precondition) shows no change in behavior:

(defmacro p2 [] `(throw (NullPointerException. "")))
(is (thrown? NullPointerException (eval '(p2
;; same behavior in both 1.9 and 1.10 - passes and returns the exception

At this point, I'm moving discussion to a ticket and I'd rather pick up any 
subsequent discussion there:

https://dev.clojure.org/jira/browse/CLJ-2458


On Tuesday, December 18, 2018 at 5:49:09 PM UTC-6, Andy Fingerhut wrote:
>
> Alex, just so I understand, are you saying that because of the 
> implementation of `(is (thrown-with-msg? ..))` and the changes to 
> exceptions in Clojure 1.10.0, that other Clojure programs that use `(is 
> (thrown-with-msg? ...))` may need to be updated to use something similar to 
> what you linked, in order to test the new Clojure 1.10.0 behavior?
>
> Thanks,
> Andy
>
>
> On Tue, Dec 18, 2018 at 11:12 AM Alex Miller  wrote:
>
>> Oh, if you're testing with thrown-with-msg?, that definitely can have an 
>> impact due to the nested exception. In clojure.test, I'm using a variant to 
>> test the message with the root cause:
>>
>>
>> https://github.com/clojure/clojure/blob/master/test/clojure/test_helper.clj#L134-L151
>>
>> On Tuesday, December 18, 2018 at 12:06:18 PM UTC-6, Andy Fingerhut wrote:
>>>
>>> I do not know if Leiningen is involved in the difference in the 
>>> reproduction project linked below yet (I am testing with the latest 
>>> Leiningen 2.8.3 here), but I do see a clojure.test `(is (thrown-with-msg? 
>>> ...` expression that gives no error when running 'lein test' with Clojure 
>>> 1.9.0, but does with Clojure 1.10.0.  I do not know if it is the same root 
>>> cause as Mark's example or not, but wanted to create this in hopes it 
>>> represents a minimal test case to reproduce the behavior difference.
>>>
>>> https://github.com/jafingerhut/clojure-110-is-thrown
>>>
>>> Andy
>>>
>>> On Tue, Dec 18, 2018 at 7:07 AM Alex Miller  wrote:
>>>
 In particular, I am challenging this assertion from the original post:

 However, the following test (using is from clojure.test) used to work 
 prior to 1.10, but now fails:

 => (is (thrown? AssertionError (f true)))
 Unexpected error (AssertionError) macroexpanding f at 
 (test:localhost:62048(clj)*:268:56).
 Assert failed: (number? x)


 When I do this on 1.9 I see:

 user=> (is (thrown? AssertionError (f true)))
 CompilerException java.lang.AssertionError: Assert failed: (number? x), 
 compiling:(NO_SOURCE_PATH:20:29)


 Which is printed differently but is the same behavior, because this is 
 happening while expanding the is, not during execution.

 I believe you're seeing a change in your test suite, I'm just having a 
 hard time reproducing what you're seeing.


 On Tuesday, December 18, 2018 at 8:47:11 AM UTC-6, Alex Miller wrote:
>
> This particular example given fails in a similar way on 1.9. Could you 
> give me something closer to what you are actually seeing in your test 
> suite? Specifically something that is a passing clojure.test test on 1.9 
> but a failure/error on 1.10? 
>
> The problem with the given example is that it fails during 
> macroexpansion of the test itself, not during test execution, and I don't 
> think that's the case you're trying to replicate.
>
> On Tuesday, December 18, 2018 at 8:35:54 AM UTC-6, Alex Miller wrote:
>>
>> I think the relevant change here is that exceptions thrown during 
>> macroexpansion are now wrapped into CompilerExceptions as a way to 
>> attach 
>> all of the source context information. The REPL understands this and 
>> still 
>> prints the original cause so the printing hides some of that structure 
>> (but 
>> you can see it by looking at the exception chain). 
>>
>> This here is a particularly tricky case here though and I think there 
>> might be something else coming into play, still looking at it. There was 
>> a 
>> couple other changes inside the com

Re: [ANN] Oz 1.4.0 - Interactive data visualizations and scientific documents with Vega/Vega-Lite

2018-12-18 Thread Christopher Small

Hi Juraj

Glad you have it working now!

I mostly use oz from the Clojure REPL as an exploratory tool in my work on 
Polis (see https://www.youtube.com/watch?v=2tBVMAm0-00). I have yet to use 
the Reagent API in a dynamic front end, but I have used Vega & Vega-Lite in 
a vanilla React app (see https://github.com/matsengrp/olmsted), so I know 
what's possible and look forward to being able to do the equivalent in 
ClojureScript.

I'm a vim user, so I use vim-fireplace to connect my REPL to my text 
editor. This lets me write and execute plot building code directly from the 
comfort of my editor, and have a separate browser window open for looking 
at the results. This gives me a pretty tight feedback loop for visualizing 
and exploring data. If you're using the Reagent API with Figwheel, you 
should get a pretty similar feedback loop for development of 

To be perfectly honest, debugging can be a bit challenging when first using 
Vega & Vega-Lite. The IDL's Vega Editor has some helpful tools for 
analyzing specs for problems, and a tight feedback loop of tweaking and 
re-evaluating plot code can help keep you on the right path till you get 
your bearing. They're also working on some really neat debugging tools to 
help visualize the compiled dataflow topology in order to better diagnose 
issues, so hopefully this area will improve.

The best way to get started is to go to the Vega & Vega-Lite Examples pages 
(https://vega.github.io/vega/examples/ & 
https://vega.github.io/vega-lite/examples/), which helpfully showcase a 
panapoly of specs available for use as starting points. Once you find a 
related spec, it's usually only a few changes to a get a "bare bones" 
adaptation to your data. From there, you can generally stitch in spec code 
from other examples as needed to get the plot you want. If some "stitching" 
doesn't work, look for other examples combining similar functionality if 
possible, and if not raise an issue. The IDL is super responsive and active 
in their development and release cycle, so bugs generally get solved very 
quickly; In fact on rare occasions where I've found a Vega bug or something 
I wanted to do but couldn't easily, I've frequently discovered that there's 
already been a fix released, or had them specifically address the problem 
within a matter of weeks.

Thanks again

Chris



-- 
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] Oz 1.4.0 - Interactive data visualizations and scientific documents with Vega/Vega-Lite

2018-12-18 Thread Christopher Small
EDIT: ...for the development of dynamic web applications.


On Tuesday, December 18, 2018 at 8:31:25 PM UTC-8, Christopher Small wrote:
>
>
> Hi Juraj
>
> Glad you have it working now!
>
> I mostly use oz from the Clojure REPL as an exploratory tool in my work on 
> Polis (see https://www.youtube.com/watch?v=2tBVMAm0-00). I have yet to 
> use the Reagent API in a dynamic front end, but I have used Vega & 
> Vega-Lite in a vanilla React app (see https://github.com/matsengrp/olmsted), 
> so I know what's possible and look forward to being able to do the 
> equivalent in ClojureScript.
>
> I'm a vim user, so I use vim-fireplace to connect my REPL to my text 
> editor. This lets me write and execute plot building code directly from the 
> comfort of my editor, and have a separate browser window open for looking 
> at the results. This gives me a pretty tight feedback loop for visualizing 
> and exploring data. If you're using the Reagent API with Figwheel, you 
> should get a pretty similar feedback loop for development of 
>
> To be perfectly honest, debugging can be a bit challenging when first 
> using Vega & Vega-Lite. The IDL's Vega Editor has some helpful tools for 
> analyzing specs for problems, and a tight feedback loop of tweaking and 
> re-evaluating plot code can help keep you on the right path till you get 
> your bearing. They're also working on some really neat debugging tools to 
> help visualize the compiled dataflow topology in order to better diagnose 
> issues, so hopefully this area will improve.
>
> The best way to get started is to go to the Vega & Vega-Lite Examples 
> pages (https://vega.github.io/vega/examples/ & 
> https://vega.github.io/vega-lite/examples/), which helpfully showcase a 
> panapoly of specs available for use as starting points. Once you find a 
> related spec, it's usually only a few changes to a get a "bare bones" 
> adaptation to your data. From there, you can generally stitch in spec code 
> from other examples as needed to get the plot you want. If some "stitching" 
> doesn't work, look for other examples combining similar functionality if 
> possible, and if not raise an issue. The IDL is super responsive and active 
> in their development and release cycle, so bugs generally get solved very 
> quickly; In fact on rare occasions where I've found a Vega bug or something 
> I wanted to do but couldn't easily, I've frequently discovered that there's 
> already been a fix released, or had them specifically address the problem 
> within a matter of weeks.
>
> Thanks again
>
> Chris
>
>
>
>

-- 
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] Oz 1.4.0 - Interactive data visualizations and scientific documents with Vega/Vega-Lite

2018-12-18 Thread Christopher Small

Great to hear. Thanks for checking it out!


On Tuesday, December 18, 2018 at 10:38:12 AM UTC-8, Alan Thompson wrote:
>
> Looks very nice.  I will definitely be using this in the future.
> Alan
>
>

-- 
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.