Re: [ANN] Brave Clojure Jobs

[Daniel Higginbotham]

Forgot to mention - buying ads helps me afford to continue writing 
instructional Clojure material at http://www.braveclojure.com

Thanks!
Daniel

On Wednesday, March 30, 2016 at 4:19:22 PM UTC-4, Daniel Higginbotham wrote:
>
> The first and only all-Clojure-all-the-time job board is out of beta and 
> in production: Brave Clojure Jobs, https://jobs.braveclojure.com/. For 
> the next 30 days, posting an ad is 50% off :) Please feel free to email me 
> about it, nonrecurs...@gmail.com
>
> Thanks to everyone who helped with the beta, including (sorry if I missed 
> you!):
>
>- Bridget Hillyer
>- Gary Berger at Brocade
>- Michael Gurtiza at Funding Circle
>- Dave Yarwood
>- Timo Sulg at Skillable
>- @lmergen
>
>
> 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: Reworking :pre condition to add an error message

[Oliver George]

I look forward to pre/post conditions becoming more helpful.  Truss is a 
good example of how things can improve.  I think part of the challenge is 
not making the code too messy.

Here's a proof of concept of how metadata in the pre/post/assert expression 
could be used to craft nice messages:

(defn get-highlander [hs] 

  {:pre [^{:msg "There can be only one"} (= 1 (count ^:var hs))]} 

  (first hs))


And the error messages can be presented as:

user=> (get-highlander ["asdf" "ss"])

AssertionError Assert failed: There can be only one

(= 1 (count hs))

where hs is ["asdf" "ss"]  user/get-highlander (NO_SOURCE_FILE:4)


This works by modifying the assert macro so it works for general asserts too

(assert (test (complex (form (with (a ^:var varible) "bad variable")


The modifications to assert seem quite modest but I'm unsure if this is an 
approach which is considered to be the correct solution.

(declare tree-seq)

(defn pr-vars [form env]
  (let [var? (fn [x] (-> x meta :var))]
(for [var (filter var? (tree-seq seq? identity form))]
  `(str "\n where " '~var " is " (pr-str ~var)

(defmacro assert
  "Evaluates expr and throws an exception if it does not evaluate to
  logical tru"
  {:added "1.0"}
  ([x]
   (when *assert*
 `(when-not ~x
(throw (new AssertionError (str "Assert failed: " ~(or (-> x meta :msg) 
"")
"\n" (pr-str '~x)
~@(pr-vars x &env)))
  ([x message]
 (when *assert*
   `(when-not ~x
  (throw (new AssertionError (str "Assert failed: " ~message
  "\n" (pr-str '~x)
  ~@(pr-vars x &env



On Thursday, 31 March 2016 03:09:03 UTC+11, Niels van Klaveren wrote:
>
> Truss also has good support for :pre 
> and :post conditions 
> 
>
> On Monday, July 11, 2011 at 7:40:48 PM UTC+2, frye wrote:
>>
>> Note: This message was originally posted by ' Shantanu' on the "*Re: 
>> Clojure for large programs*" thread. 
>>
>> I took a look at  Shantanu's macros, and I like the concept a lot. But I 
>> would prefer something baked into the :pre condition itself. The reason is 
>> that it just removes a layer of indirection. If you dig into '
>> *clj/clojure/core.clj*', you can see that the 'fn' macro is using 
>> 'assert' to test these conditions. Assert allows error messages to be 
>> applied, ie: 
>>
>> *user => (assert false) *
>>
>> *user => (assert false "fubar") *
>>
>>
>>
>> However, (defmacro fn ...) assumes that just the boolean condition is 
>> being passed in, A). But I'd like to have the option to pass in a message 
>> B). 
>>
>>
>> *A) *
>>
>> *(def fubar *
>>
>> *  (fn []*
>>
>> *{:pre [ (true? false) ] }*
>>
>> *(println "Hello World")))*
>>
>> *(fubar)*
>>
>>
>> *B) *
>>
>> *(def thing *
>>
>> *  (fn []*
>>
>> *{:pre [ [(true? false) "A false message"] ] }*
>>
>> *(println "Hello World")))*
>>
>> *(thing)*
>>
>>
>>
>> I reworked the 'fn' macro, only for the :pre condition, as a 
>> demonstration (see here ). The calling 
>> semantics don't change that much. Is there any interest in putting this 
>> into core? I'd use Shantanu's workaround otherwise, or in the interim. 
>>
>> Thanks 
>>
>> Tim Washington 
>> twas...@gmail.com 
>> 416.843.9060 
>>
>>
>>
>> On Sun, Jul 3, 2011 at 11:42 AM, Shantanu Kumar  
>> wrote:
>>
>>>
>>>
>>> On Jul 3, 7:39 pm, Timothy Washington  wrote:
>>> > I'm using pre / post assertions quite a bit in a project I'm building. 
>>> And I
>>> > too would love to see better or custom error messages for each 
>>> assertion.
>>>
>>> That should be possible with a macro. For example, I use this:
>>>
>>> https://bitbucket.org/kumarshantanu/clj-miscutil/src/acfb97c662d9/src/main/clj/org/bituf/clj_miscutil.clj#cl-1009
>>>
>>> Maybe you need something like this(?):
>>>
>>> (defmacro verify-my-arg
>>>  "Like assert, except for the following differences:
>>>  1. does not check for *assert* flag
>>>  2. throws IllegalArgumentException"
>>>  [err-msg arg]
>>>  `(if ~arg true
>>> (throw (IllegalArgumentException. ~err-msg
>>>
>>> Then use it thus:
>>>
>>> (defn foo [m]
>>>  {:pre [(verify-my-arg "m must be a map" (map? m))]}
>>>  (println m))
>>>
>>> Regards,
>>> Shantanu
>>>
>>> --
>>> 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" grou

Re: [ANN] As I was missing this kind of library in clojure I created relational_mapper for dealing with querying relational databases

[Oliver George]

Fantastic.  Keep up the good work.

Schema conventions could be made flexible with a protocol.

(defprotocol IDBSchema  (pk [_ table-name])  (rel [_ table-name rel-name])  
(has-many? [_ table-name rel-name]))




On Thursday, 31 March 2016 09:23:00 UTC+11, Krzysiek Herod wrote:
>
> I just released version 0.3.0 of Relational Mapper. Customization of keys 
> and foreign keys is done now, as well as possibility to specify relation 
> with a different name than the corresponding table (
> https://github.com/netizer/relational_mapper#different-name-of-an-association-than-a-table-name).
>  
>
>
> @Oliver George: your example with SupervisorId, AnalystId would work now, 
> but have in mind that postgreSQL by default lowercases column names, so I'd 
> still recommend supervisor_id and analyst_id. 
>
> Cheers,
> Krzysiek 
>
> On Tuesday, March 1, 2016 at 11:35:46 PM UTC+1, Oliver George wrote:
>>
>>
>> Both those ideas seem sensible to me.  Look foward to hearing more.
>>
>> On Tuesday, 1 March 2016 23:38:43 UTC+11, Krzysiek Herod wrote:
>>>
>>> I went through the paper very briefly, so I might be wrong, but from the 
>>> first look it seems like the algorithm would generate the actual SQL 
>>> queries . If so, although the idea seems interesting, I wouldn't go in this 
>>> direction because of the loss of flexibility for the user of the library. 
>>> For example sometimes it happens, that the slowest SQL query called by the 
>>> application is the one where database picked a sub-optimal index, or 
>>> sometimes combining data by adding one more join has a great performance 
>>> impact. 
>>>
>>> Actually I was thinking about giving the programmer more flexibility, 
>>> and maybe splitting the whole code into query part and stitch part, so the 
>>> developer would choose the most efficient queries, but the stitching part 
>>> would put all those data together (with deep result structure). I'm curious 
>>> what do you think about this direction. I'll comment on your issue (
>>> https://github.com/netizer/relational_mapper/issues/3) with more 
>>> details about the idea.
>>>
>>> Cheers,
>>> Krzysiek
>>>
>>> On Tue, Mar 1, 2016 at 6:03 AM, Oliver George  
>>> wrote:
>>>
 Awesome, thanks.

 I did a little research last night looking for techniques for turning 
 recursive queries into efficient SQL queries.  I came across an 
 interesting 
 paper:

 Cheney, James, Sam Lindley, and Philip Wadler. "Query shredding: 
 Efficient relational evaluation of queries over nested multisets (extended 
 version)."*arXiv preprint arXiv:1404.7078* (2014).


 The details are obscured behind some intimidating equations but the 
 concept seems pretty simple: The nested query gets normalised and then 
 shredded into a set of sql queries and the results of those queries are 
 stitched back together.

 There seem to be two version 
 
  
 of the paper.  This one looks to be more detailed  (26 pages):

 https://scholar.google.com/citations?view_op=view_citation&hl=en&user=Iz-3VFQJ&sortby=pubdate&citation_for_view=Iz-3VFQJ:9pM33mqn1YgC




 On Monday, 29 February 2016 21:06:23 UTC+11, Krzysiek Herod wrote:
>
> Thanks a lot for detailed notes.
>
> The problem with customization of foreign keys is on my TODO list. I 
> hope to fix that before releasing version 1.0. That would solve the 
> problem 
> with SupervisorId and AnalystId. 
>
> What you said about deeper result structure (race -> meeting -> venue) 
> is very inspiring. You can't do that with this library (you can fetch 
> records with their - potentially indirect - relations, but those 
> relations 
> won't have own relations included), but definitely it's something worth 
> considering. I added it to my TODO list in the README but I don't have a 
> clear idea about how to do it well yet. 
>
> Cheers, 
> Krzysiek
>
> On Monday, February 29, 2016 at 12:54:31 PM UTC+8, Oliver George wrote:
>>
>> Oops, one more.
>>
>> There was also a Users table (Id, Username, ...)
>>
>> I didn't see a way to handle join from Races to Users based on 
>> SupervisorId and AnalystId.  
>>
>>
>> On Monday, 29 February 2016 15:52:48 UTC+11, Oliver George wrote:
>>>
>>> Thanks for the details.
>>>
>>> I did a little experimenting and it works as advertised.  Notes 
>>> below show what I did and found.
>>>
>>> I was interested to see if this might be suitable as a simple 
>>> om.next remote for a relational database.  Potentially fanciful but 
>>> it's a 
>>> topic of interest for me at the moment.
>>>
>>> I used an existing database so I had a semi 

Re: [ANN] As I was missing this kind of library in clojure I created relational_mapper for dealing with querying relational databases

[Krzysiek Herod]

I just released version 0.3.0 of Relational Mapper. Customization of keys 
and foreign keys is done now, as well as possibility to specify relation 
with a different name than the corresponding table 
(https://github.com/netizer/relational_mapper#different-name-of-an-association-than-a-table-name).
 


@Oliver George: your example with SupervisorId, AnalystId would work now, 
but have in mind that postgreSQL by default lowercases column names, so I'd 
still recommend supervisor_id and analyst_id. 

Cheers,
Krzysiek 

On Tuesday, March 1, 2016 at 11:35:46 PM UTC+1, Oliver George wrote:
>
>
> Both those ideas seem sensible to me.  Look foward to hearing more.
>
> On Tuesday, 1 March 2016 23:38:43 UTC+11, Krzysiek Herod wrote:
>>
>> I went through the paper very briefly, so I might be wrong, but from the 
>> first look it seems like the algorithm would generate the actual SQL 
>> queries . If so, although the idea seems interesting, I wouldn't go in this 
>> direction because of the loss of flexibility for the user of the library. 
>> For example sometimes it happens, that the slowest SQL query called by the 
>> application is the one where database picked a sub-optimal index, or 
>> sometimes combining data by adding one more join has a great performance 
>> impact. 
>>
>> Actually I was thinking about giving the programmer more flexibility, and 
>> maybe splitting the whole code into query part and stitch part, so the 
>> developer would choose the most efficient queries, but the stitching part 
>> would put all those data together (with deep result structure). I'm curious 
>> what do you think about this direction. I'll comment on your issue (
>> https://github.com/netizer/relational_mapper/issues/3) with more details 
>> about the idea.
>>
>> Cheers,
>> Krzysiek
>>
>> On Tue, Mar 1, 2016 at 6:03 AM, Oliver George  
>> wrote:
>>
>>> Awesome, thanks.
>>>
>>> I did a little research last night looking for techniques for turning 
>>> recursive queries into efficient SQL queries.  I came across an interesting 
>>> paper:
>>>
>>> Cheney, James, Sam Lindley, and Philip Wadler. "Query shredding: 
>>> Efficient relational evaluation of queries over nested multisets (extended 
>>> version)."*arXiv preprint arXiv:1404.7078* (2014).
>>>
>>>
>>> The details are obscured behind some intimidating equations but the 
>>> concept seems pretty simple: The nested query gets normalised and then 
>>> shredded into a set of sql queries and the results of those queries are 
>>> stitched back together.
>>>
>>> There seem to be two version 
>>> 
>>>  
>>> of the paper.  This one looks to be more detailed  (26 pages):
>>>
>>> https://scholar.google.com/citations?view_op=view_citation&hl=en&user=Iz-3VFQJ&sortby=pubdate&citation_for_view=Iz-3VFQJ:9pM33mqn1YgC
>>>
>>>
>>>
>>>
>>> On Monday, 29 February 2016 21:06:23 UTC+11, Krzysiek Herod wrote:

 Thanks a lot for detailed notes.

 The problem with customization of foreign keys is on my TODO list. I 
 hope to fix that before releasing version 1.0. That would solve the 
 problem 
 with SupervisorId and AnalystId. 

 What you said about deeper result structure (race -> meeting -> venue) 
 is very inspiring. You can't do that with this library (you can fetch 
 records with their - potentially indirect - relations, but those relations 
 won't have own relations included), but definitely it's something worth 
 considering. I added it to my TODO list in the README but I don't have a 
 clear idea about how to do it well yet. 

 Cheers, 
 Krzysiek

 On Monday, February 29, 2016 at 12:54:31 PM UTC+8, Oliver George wrote:
>
> Oops, one more.
>
> There was also a Users table (Id, Username, ...)
>
> I didn't see a way to handle join from Races to Users based on 
> SupervisorId and AnalystId.  
>
>
> On Monday, 29 February 2016 15:52:48 UTC+11, Oliver George wrote:
>>
>> Thanks for the details.
>>
>> I did a little experimenting and it works as advertised.  Notes below 
>> show what I did and found.
>>
>> I was interested to see if this might be suitable as a simple om.next 
>> remote for a relational database.  Potentially fanciful but it's a topic 
>> of 
>> interest for me at the moment.
>>
>> I used an existing database so I had a semi interesting dataset to 
>> play with.  
>>
>> Races (Id, RaceNumber, RaceTime, MeetingId, SupervisorId, 
>> AnalystId...)
>> Meetings (Id, MeetingDate, MeetingTypeId, VenueId, JurisdictionId, 
>> ...)
>> Venues (Id, Name)
>> Jurisdiction (Id, Name, Code)
>>
>>
>> The table and foreign key naming conventions didn't match so I 
>> created views for each table.  If that 

Nice article on HugSQL

[Alan Thompson]

Enjoy!

https://compose.io/articles/embrace-sql-with-hugsql-clojure-and-postgresql/?utm_source=postgresweekly&utm_medium=email

-- 
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] Brave Clojure Jobs

[Daniel Higginbotham]

The first and only all-Clojure-all-the-time job board is out of beta and in 
production: Brave Clojure Jobs, https://jobs.braveclojure.com/. For the 
next 30 days, posting an ad is 50% off :) Please feel free to email me 
about it, nonrecurs...@gmail.com

Thanks to everyone who helped with the beta, including (sorry if I missed 
you!):

   - Bridget Hillyer
   - Gary Berger at Brocade
   - Michael Gurtiza at Funding Circle
   - Dave Yarwood
   - Timo Sulg at Skillable
   - @lmergen


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: flowchart for choosing the right Clojure parallel primitives?

[Sergey Didenko]

Thank you, David!

On Tue, Mar 29, 2016 at 10:52 PM, David Della Costa 
wrote:

> Hi Sergey, I don't have a direct answer for you but this talk at
> Clojure/West 2015 by Leon Barrett went over the various options for
> parallelism in Clojure, and I found it pretty educational myself:
>
>
> https://www.youtube.com/watch?v=BzKjIk0vgzE&list=PLZdCLR02grLrKAOj8FJ1GGmNM5l7Okz0a&index=2
>
> Hope that is useful!
>
> DD
>
>
> 2016-03-29 9:56 GMT-04:00 Sergey Didenko :
>
>> Hi,
>>
>> Is there a flowchart for choosing the right Clojure parallel primitives?
>>
>> So that you can decide when to just use reducers/fork and when to choose
>> core.async and etc.
>>
>> For example like the flowchart for data types from Chas Emerick -
>> http://cemerick.com/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form/
>>
>>
>> --
>> 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.
>

-- 
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: Nesting semantics for the thread last operator

[Arun Sharma]

On Monday, March 21, 2016 at 5:33:36 PM UTC-7, James Reeves wrote:
>
>  
>
>> The question I was asking is: does anyone rely on the current behavior? 
>> For people adapting this syntax for a query language, it's appealing to 
>> write:
>>
>> a->b()->c()
>>->union(d->e()->f())
>>
>> and get (union (c (b a) (f (e d)))
>>
>
> That's what:
>
> (-> a b c (union (-> d e f)))
>
> expands to.
>
> - James
>

Thanks. That works great for union and intersection, although I prefer 
threadLast over threadFirst for other reasons.

The thing that motivated this line of thought is that we have some 
primitives that read from right to left and unlike union/intersection are 
order sensitive.

(apply q2 q1)

means for each result of q1, run q2 and return the results.

For q1 = a->b()->c() and q2 = d->e()->f(), I'm trying to find an 
acceptable/natural thread last syntax.

user=> (clojure.walk/macroexpand-all '(->> a b c (->> d e f (apply

(c (b a) (apply (f (e d

Is there a way we could end up with

(apply (f (e d)) (c (b a)))

 -Arun

-- 
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: Reworking :pre condition to add an error message

[Niels van Klaveren]

Truss also has good support for :pre 
and :post conditions 


On Monday, July 11, 2011 at 7:40:48 PM UTC+2, frye wrote:
>
> Note: This message was originally posted by ' Shantanu' on the "*Re: 
> Clojure for large programs*" thread. 
>
> I took a look at  Shantanu's macros, and I like the concept a lot. But I 
> would prefer something baked into the :pre condition itself. The reason is 
> that it just removes a layer of indirection. If you dig into '
> *clj/clojure/core.clj*', you can see that the 'fn' macro is using 
> 'assert' to test these conditions. Assert allows error messages to be 
> applied, ie: 
>
> *user => (assert false) *
>
> *user => (assert false "fubar") *
>
>
>
> However, (defmacro fn ...) assumes that just the boolean condition is 
> being passed in, A). But I'd like to have the option to pass in a message 
> B). 
>
>
> *A) *
>
> *(def fubar *
>
> *  (fn []*
>
> *{:pre [ (true? false) ] }*
>
> *(println "Hello World")))*
>
> *(fubar)*
>
>
> *B) *
>
> *(def thing *
>
> *  (fn []*
>
> *{:pre [ [(true? false) "A false message"] ] }*
>
> *(println "Hello World")))*
>
> *(thing)*
>
>
>
> I reworked the 'fn' macro, only for the :pre condition, as a demonstration 
> (see here ). The calling semantics don't 
> change that much. Is there any interest in putting this into core? I'd 
> use Shantanu's workaround otherwise, or in the interim. 
>
> Thanks 
>
> Tim Washington 
> twas...@gmail.com  
> 416.843.9060 
>
>
>
> On Sun, Jul 3, 2011 at 11:42 AM, Shantanu Kumar  > wrote:
>
>>
>>
>> On Jul 3, 7:39 pm, Timothy Washington  wrote:
>> > I'm using pre / post assertions quite a bit in a project I'm building. 
>> And I
>> > too would love to see better or custom error messages for each 
>> assertion.
>>
>> That should be possible with a macro. For example, I use this:
>>
>> https://bitbucket.org/kumarshantanu/clj-miscutil/src/acfb97c662d9/src/main/clj/org/bituf/clj_miscutil.clj#cl-1009
>>
>> Maybe you need something like this(?):
>>
>> (defmacro verify-my-arg
>>  "Like assert, except for the following differences:
>>  1. does not check for *assert* flag
>>  2. throws IllegalArgumentException"
>>  [err-msg arg]
>>  `(if ~arg true
>> (throw (IllegalArgumentException. ~err-msg
>>
>> Then use it thus:
>>
>> (defn foo [m]
>>  {:pre [(verify-my-arg "m must be a map" (map? m))]}
>>  (println m))
>>
>> Regards,
>> Shantanu
>>
>> --
>> 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 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: Reworking :pre condition to add an error message

[i . am]

CLJ-1817 looks interesting. We’ve been achieving similar behaviour via `or` 
statements in `:pre/:post`:

(defn somefn [x]
  {:pre [(or (map? x) (throw+ {:type ::bad-stuff :details ...}))]}
  ...)


This way we were also getting more useful exception types than 
AssertionErrors, but it did feel a bit hacky.


On Tuesday, March 29, 2016 at 10:40:41 PM UTC+1, Francis Avila wrote:
>
> A wonderful hack I read about somewhere is to just use the clojure.test/is 
> macro, which I now do all the time:
>
> (require '[clojure.test :refer [is]])
> => nil
> (defn get-key [m k]
>   {:pre [(is (map? m) "m is not a map!")]}
>   (m k))
> => #'user/get-key
> (get-key [] 0)
>
> FAIL in clojure.lang.PersistentList$EmptyList@1 
> (form-init8401797809408331100.clj:2)
> m is not a map!
> expected: (map? m)
>   actual: (not (map? []))
> AssertionError Assert failed: (is (map? m) "m is not a map!") 
>  user/get-key (form-init8401797809408331100.clj:1)
>
>
> This is great for repl use, but it does side-effect (the printed error) 
> and doesn't return anything structured. It's suited to development-time 
> human use rather than runtime or machine-use.
>
> I see the potential for a macro which rethrows the assertion errors as 
> something like ex-info exceptions (i.e. something with structured data.) 
> That would fill runtime or machine-uses better (or structured logging?), 
> but I'm not sure that fits with the spirit of pre/post conditions in the 
> first place. After all, these do raise Java AssertionErrors, which are not 
> meant to be recoverable.
>
> On Tuesday, March 29, 2016 at 4:19:12 PM UTC-5, Alex Miller wrote:
>>
>> (zombie thread back from the dead... :)
>>
>> I think enhancements on :pre/:post are interesting.
>>
>> http://dev.clojure.org/jira/browse/CLJ-1817 seems like a good place to 
>> work on this.
>>
>>
>> On Tuesday, March 29, 2016 at 4:02:25 PM UTC-5, Colin Taylor wrote:
>>>
>>> Would there be interest in a ticket in this? Seems simple enough if (as 
>>> above) putting the message under the :pre key is acceptable?
>>>
>>>
>>> On Thursday, July 14, 2011 at 3:25:16 AM UTC+12, frye wrote:

 I do think a simple String error message is all that the user of the 
 function should provide. From there, An AssertionError can throw up 
 something along the lines of what you said - Expected… , Found… , Message. 
 That would give enough information for reporting at least in a test 
 framework. To get more precise information, like you said, that 
 AssertionError could also throw up class/file information, etc. that a 
 debugger could use. I would guard against designing these things to 
 accomodate a context outside of it's execution scope. In the ideal 
 functional world, the input and output are wholly localized. Any 
 Error/Exception thrown can be consumed or chained to give very precise 
 failure reasoning.  


 As for how that would fit into the entire exception chain, that's still 
 being thought (see here 
 ). There are 
 already a few approaches, and I think this (see here 
 ) is 
 the context of how the core team is approaching this problem. 


 Cheers 
 Tim 


 On Tue, Jul 12, 2011 at 6:01 AM, Shantanu Kumar  
 wrote:

> As I am the culprit of having introduced it with a naive example, I'd
> better admit it may not be very useful in practical scenarios across a
> wide variety of use cases. For example, when there is an assertion
> error with message "`m` should be a map" 14 levels down the stack, I'd
> really wish it said "`m` -- Expected: map, Found: vector [:foo :bar]"
> so that I can debug it quickly.
>
> Pre-conditions and Post-conditions are a valuable debugging aid, and
> to enable that we need very precise information. Unfortunately passing
> a string error message cannot encapsulate enough error context. A more
> complex example can be where the correctness of input must be
> determined collectively (in association with other args) -- in those
> cases one can only fall back on comparing input values and raise
> IllegalArgumentException accordingly.
>
> Regards,
> Shantanu
>
> On Jul 11, 10:40 pm, Timothy Washington  wrote:
> > 
>



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

Re: flowchart for choosing the right Clojure parallel primitives?

[Niels van Klaveren]

Thanks, that's a really nice overview for the possible parallel processing 
options in clojure.

On Tuesday, March 29, 2016 at 9:53:32 PM UTC+2, David Della Costa wrote:
>
> Hi Sergey, I don't have a direct answer for you but this talk at 
> Clojure/West 2015 by Leon Barrett went over the various options for 
> parallelism in Clojure, and I found it pretty educational myself:
>
>
> https://www.youtube.com/watch?v=BzKjIk0vgzE&list=PLZdCLR02grLrKAOj8FJ1GGmNM5l7Okz0a&index=2
>
> Hope that is useful!
>
> DD
>
>
> 2016-03-29 9:56 GMT-04:00 Sergey Didenko  >:
>
>> Hi,
>>
>> Is there a flowchart for choosing the right Clojure parallel primitives?
>>
>> So that you can decide when to just use reducers/fork and when to choose 
>> core.async and etc.
>>
>> For example like the flowchart for data types from Chas Emerick - 
>> http://cemerick.com/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form/
>>
>>
>> -- 
>> 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: Render Rails templates in Clojure?

[Igor Bondarenko]

Thanks! Zweikopf looks pretty cool, will check it out more

On Tuesday, March 29, 2016 at 2:44:40 PM UTC+3, Erwin Kroon wrote:
>
> We are running Clojure and Rails in the same JVM with JRuby (with our own 
> library ring.rack [1] and Zweikopf [2]). 
>
> Depending on the templates, you can probably use only Zweikopf (so you can 
> reuse gems).  Our problem was that with Rails, it is often all or nothing, 
> which makes me wonder that if you see reusing only the templates as as a 
> valid option, that rewriting the templates is the better option.
>
> Cheers,
> Erwin
>
> [1] https://github.com/mpare-net/ring-rack
> [2] https://github.com/ifesdjeen/zweikopf
>
> On Friday, March 25, 2016 at 1:27:28 PM UTC+1, Igor Bondarenko wrote:
>>
>> Hi everyone!
>>
>> We're planning on moving our Rails app to Clojure and would want to keep 
>> our Rails templates during the transition time. Is there a way to render 
>> Rails templates in Clojure (or Java)?
>>
>> The reason we need this is because templates will probably change at the 
>> same time as transition happens and we don't want to update them in two 
>> different places/templating languages. Eventually we'll switch to Clojure 
>> templating library completely, of course.
>>
>> Or it isn't worth the effort and we should just rewrite templates to 
>> Clojure from the beginning and deal with duplication?
>>
>> Thanks for your thoughts.
>>
>

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