Re: Online Clojure COVID-19 Hackathon

2020-03-18 Thread Dave Liepmann
I'm glad to see people coming together to look at coronavirus data. 

As a non-epidemiologist who is also exploring covid19 data I found this 
article 

 
[1] a timely reminder that our responsibility is heightened with these 
projects, and scales as our work is more widely seen. We have to take care 
that our visualizations and analyses don't misrepresent the situation. This 
line summed it up for me:

>Just because you *can* perform a mathematical function on a set of health 
statistics doesn’t mean you *should*.

As non-subject-matter-experts this is a time to be humble. Of course we 
should still look at the data, but we must be careful. I'm particularly 
skeptical now of any work that assumes that case reports in certain 
countries (e.g. the US) are within even two orders of magnitude of the 
ground truth.

[1] 
https://medium.com/nightingale/ten-considerations-before-you-create-another-chart-about-covid-19-27d3bd691be8


On Tuesday, March 17, 2020 at 9:29:53 PM UTC+1, Daniel Slutsky wrote:
>
> Hello everybody.
>
> We are organizing an online Clojure hackathon for studying COVID-19 data.
>
> Please mark your preferred dates:
> https://twitter.com/scicloj/status/1240010550555353088
>
> Wishing you good health and better times.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/84b449a9-df55-4b92-8639-2299fad0a83d%40googlegroups.com.


Compojure-api, spec-tools, swagger,

2018-05-14 Thread Dave Tenny
I'm using compojure-api 2.0.0-alpha19, spec-tools 0.6.1, and trying to 
generate swagger pages with :spec coercion in compojure-api.

I know this is a work in progress but I'm not an expert in any of these 
tools and thought I'd ask here before I write pesky and likely incorrect 
issues in the Metosin repos.  I've done a fair bit of prismatic-schema 
enabled compojure-api and so was trying to translate some of that into a 
spec-ized implementation.  However i've either made a ton of mistakes 
(quite likely), or there's a lot of bugs, I'm not sure.

The following code fragments and annotated image show some of the problems 
I'm seeing.  Advice welcome. 

Basic specs, later aliased via 'db-jobs':

(s/def ::job-id nat-int?)
(s/def ::job-type #{:this-job :that-job :the-other-job})

Specs built on the above, later aliased via 'specs' in compojure-api 
declarations:
(s/def ::job-id  
  (st/spec ::db-jobs/job-id
   {:description "Specifies a Job ID, must be accompanied by a Firm 
ID for any valid use."}))


(s/def ::job-type 
  (st/spec ::db-jobs/job-type
   {:description "Specifies the type of job to be dispatched to a 
suitable worker service node."}))


(s/def ::firm-id
  (st/spec nat-int? 
   {:description "Specifies a Firm ID in the service database, or 
zero if there there is no specific firm."}))

Compojure-api code using the above three specs:

...
  (:require
   [clojure.spec.alpha :as s]
   [compojure.api.core :as api-core]
   [compojure.api.sweet :as sweet]
   [compojure.route :as route]
   [my.specs :as specs]
   [spec-tools.core :as st]

...
(sweet/defroutes routes
  (sweet/POST "/job/:firm-id" []
{:summary  "Enqueue a job"
 :description  "Enqueue a job."
 :path-params [firm-id :- ::specs/firm-id]
 :body-params [job-type :- ::specs/job-type]
 :responses   {201 {:description "Job enqueued." :schema ::specs/job-id}
   400 {:description "Invalid job type." 
:schema (st/spec string? {:description "Value of 
the unsupported job-type argument."})
}}}
{:status 201 :body (impl/create-job! firm-id job-type)}))

...
  (sweet/api
   {:coercion :spec
:swagger {:data {;;:basePath "/"
 :info {:title "Job Scheduler"
:description "Jobs"
:version 1
:contact {:name  "Pizza Eaters Inc." ...}}}
  :ui "/docs/swagger"
  :spec "/docs/swagger.json"
  :options {:ui {:docExpansion "list"

The resulting swagger page (fragment) follows, annotated for discussion:




   1. For the Response Class presentation, it would be nice to get the 
   description shown with the ::job-id type.
   2. The 'job-type' parameter name is not shown.
   3. The description of the 'job-type' parameter is not shown.
   4. The 201 response code data is missing from Response messages.
   5. (not highlighted)   :firm-id works as expected, whether it's because 
   it's a :path-param or because it lacks the same degree of indirection in 
   its spec definition I don't know.


Also note that
:path-params [firm-id :- (sweet/describe ::specs/firm-id "Firm identifier, 
or zero if there is no firm.")]
Does not produce a description in swagger, however the spec.tools code in 
the initial compojure-api code I presented works.  Bug or feature? (Seems 
like sweet/describe might be deprecated as we move to clojure.spec if we're 
using spec-tools).


Anyway, tips appreciated, and patience for obvious "user" mistakes.

-- 
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: s/valid? does not tell me if the data is valid as supplied

2018-02-26 Thread Dave Dixon
I've been using the macro below to make "types" in the context of 
clara-rules, where "type" has a specific semantic. If you're going to do 
something like this, you definitely should have a very well-defined notion 
of what "type" means. 

(defmacro def-derive
 "Macros to wrap useful pattern of defining a spec and calling
  derive on the spec and a \"parent\" spec to create a hierarchy."
 ([child-name parent-name]
  `(def-derive ~child-name ~parent-name ~parent-name))
 ([child-name parent-name spec]
  `(do
 (#?(:clj clojure.spec.alpha/def :cljs cljs.spec.alpha/def)
   ~child-name (#?(:clj clojure.spec.alpha/merge :cljs 
cljs.spec.alpha/merge) ~parent-name ~spec))
 (derive ~child-name ~parent-name



On Wednesday, February 21, 2018 at 5:34:00 PM UTC-8, Didier wrote:
>
> I would actually love it if Spec was extended to have the concept of types.
>
> Something where every spec could be tied to a Type, and types could be 
> constructed to have Hierarchies.
>
> Not sure what the syntax would be like, but say:
>
> (s/def :String ::name string?)
> (s/def :String ::address (s/and string? (complement string/blank?)))
> (s/def :Person ::person (s/keys :req [::name ::address]))
> (s/def :Homeless ::homeless (s/keys :req [::name]))
>
> (s/defisa :Homeless :Person)
>
> Types would still be predicates, and all spec would be a Type too. Types 
> would be optional though. A Type is the OR of all the specs predicates 
> defined as that Type and its children types. So in the above, :Homeless is 
> (s/or ::person ::homeless).
>
> Now, this idea might need to be refined, but the goal would be so that 
> Spec could be used as a modeling languages for other languages. So I could 
> from a Spec auto-generate a Java class model, or a Ruby model, etc. Since 
> now I can relate predicates to types myself. It could also allow for better 
> static analysis.
>
> Also, might make spec extra complicated and confused to mix both 
> predicates and types, but that could depend how its done and managed.
>
> On Tuesday, 20 February 2018 02:41:38 UTC-8, Jan Rychter wrote:
>>
>> I've been using spec for a while now, in a reasonably large code base 
>> (>30k lines of Clojure and ClojureScript) and there is an issue that bit me 
>> several times.
>>
>> I use conformers for coercing data that is *almost* what I need, usually 
>> when reading from JSON (RethinkDB). Common conformers are keyword and set. 
>> And it works really well, except for one problem: there is no way to know 
>> if data has been conformed or not.
>>
>> Calling s/valid? will tell me if the data is valid *if it has been 
>> conformed*. But what if it hasn't? Can I use the data? Is it "valid" 
>> according to the spec I wrote?
>>
>> This is a very real problem: I've spent considerable time chasing bugs 
>> where there was a code path which did not call s/conform. The data passed 
>> all validations done with valid? and the bug manifested itself far down the 
>> road, where something expected a keyword instead of a string, or a set 
>> instead of a vector.
>>
>> Here is a specific minimal example demonstrating what I'm talking about:
>>
>> (ns spectest
>>   (:require [clojure.spec.alpha :as s]))
>>
>> (s/def ::test-spec (s/and (s/conformer keyword) keyword?))
>>
>> (s/conform ::test-spec "a") ;; :a
>> (s/valid? ::test-spec "a") ;; true
>>
>> I expected the last valid? to return false, because my code does not 
>> expect a string, it expects a keyword, according to the spec.
>>
>> I might be missing something, but I would much rather see valid? tell me 
>> if the data is valid for use (as supplied) and have a separate 
>> valid-when-conformed? which tells me if the data is, well, valid when 
>> conformed. It seems to me that the current valid? that does two things is 
>> confusing and not very useful for contracts.
>>
>> At the very least I'd really like to see a function that tells me if the 
>> data is valid *as supplied*, as this is the function that I'd want to use 
>> when enforcing contracts everywhere in my code.
>>
>> Alternatively, I could stop using conformers altogether, and write 
>> explicit data conversion functions. That might not be a bad idea, but it 
>> seems other people started using conformers, too, so eventually I'll hit 
>> the same problem again.
>>
>> --J.
>>
>>

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

[ANN] Uruk 0.3.10

2018-01-20 Thread Dave Liepmann
I'd like to announce the release of Uruk 0.3.10.

Uruk is the Clojure library for working with MarkLogic NoSQL databases, 
through Clojure-idiomatic access to the MarkLogic XML Content Connector 
library.

Version 0.3.10 brings support for the latest cut of MarkLogic 9, 
particularly control over auto-commit and update-mode configuration options 
(which together replace the deprecated transaction-mode option) on 
sessions. See the transactions section of the README 
<https://github.com/daveliepmann/uruk#transactions> for an example.

Project link: https://github.com/daveliepmann/uruk

Cheers!
Dave Liepmann

-- 
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.spec: need function equivalents of library macros?

2017-05-09 Thread Dave Tenny
My issues aren't about qualified or unqualified keys (and the APIs
generally need to accept unqualified keys - I do use qualified keys in
various contexts, just not this post where the topic is macros vs.
non-macro forms).

s/merge is a good point about composition.  However often all I really want
to do is take some list of, say, keywords, acceptable in a map or
collection that is a parameter, and 'disj' one keyword from it for another
spec because that particular keyword isn't valid or supported for an
interface in question.

At the end of the day, I feel I'm often forced to cut and paste too many
similar but different lists into various specs (fdef in particular).  The
ability to construct specs without macros might be useful.

On Tue, May 9, 2017 at 6:05 AM, Alex Miller <a...@puredanger.com> wrote:

> Is there any reason why you're using unqualified keys? If you're using
> qualified keys, then a simple (s/keys) spec will validate all registered
> keys in the map so you can cover all of your optional attribute cases that
> way.
>
> Another possibility worth mentioning is using s/merge to combine
> well-known (smaller) map specs into larger combinations.
>
>
> On Monday, May 8, 2017 at 10:38:34 AM UTC-5, Dave Tenny wrote:
>>
>> Let's say I have a namespace that provides access to the database,
>> say our table has these fields (as clojure specs)
>>
>> (s/def ::job-id nat-int?) ; 1 2 3 ...
>> (s/def ::job-name string?) ; frobozz-executor
>> (s/def ::job-status keyword?) ; :queued, :in-progress, :completed
>>
>>
>> And that I have the logic in place to convert to/from the types (e.g.
>> keywords).
>>
>> If I have a simple function to return records in from the jobs table it
>> might look like:
>>
>> (s/def ::job-record (s/keys :req-un [::job-id ::job-name ::job-status]))
>>
>> (s/fdef get-jobs
>>   :args (s/cat :db database-handle?)
>>   :ret (s/coll-of ::job-record))
>>
>> (defn get-jobs
>>   [db]
>>   ... returns vector of maps, one for each record, jdbc-style ...)
>>
>> (get-jobs) => [{:job-id 1 :job-name "frobozz-executor" :job-status
>> :queued} ...]
>>
>> Now here's where things get iffy in practice.  Suppose I have other
>> database interfaces that take similar but different maps or collections of
>> keywords.
>>
>> For example, a function like:
>>
>> (s/fdef get-selective-jobs
>>   :args (s/cat :db database-handle? :fields (s/keys :opt-un [::job-id
>> ::job-name ::job-status])))
>>
>> (defn get-selective-jobs
>>   [db fields]
>>   ... return only fields from the database that are specified in the
>> fields parameter ...)
>>
>>
>> Once you start getting some similar-but-different specs, it'd be nice
>> apply a bit of code building.
>>
>> e.g.
>>
>> (def job-field-keys [::job-id ::job-name ::job-status])
>>
>> (s/def ::job-record (s/keys* :req-un job-field-keys))
>> (s/fdef get-selective-args
>>   :args (s/cat* :db database-handle? :fields  (s/keys :opt-un
>> job-field-keys))
>>
>> Hopefully this is conducive to some thought/discussion of the subject,
>> and/or someone can just let me know how I should be doing this if there's
>> an easy way in the present spec implementation.
>>
>> Sidewise plea: inline specs for s/keys like you can do for s/cat.  s/keys
>> deliberate omision of inline specs does occasionally get in the way in
>> large namespaces.
>>
>>
>>
>> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/OBbq-jInyqI/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Clojure.spec: need function equivalents of library macros?

2017-05-08 Thread Dave Tenny
Oops, some corrections to my original post.

On Monday, May 8, 2017 at 11:38:34 AM UTC-4, Dave Tenny wrote:
>
> Let's say I have a namespace that provides access to the database,
> say our table has these fields (as clojure specs)
>
> (s/def ::job-id nat-int?) ; 1 2 3 ...
> (s/def ::job-name string?) ; frobozz-executor
> (s/def ::job-status keyword?) ; :queued, :in-progress, :completed
>
>
> And that I have the logic in place to convert to/from the types (e.g. 
> keywords).
>
> If I have a simple function to return records in from the jobs table it 
> might look like:
>
> (s/def ::job-record (s/keys :req-un [::job-id ::job-name ::job-status]))
>
> (s/fdef get-jobs
>   :args (s/cat :db database-handle?)
>   :ret (s/coll-of ::job-record))
>
> (defn get-jobs
>   [db]
>   ... returns vector of maps, one for each record, jdbc-style ...)
>
> (get-jobs) => [{:job-id 1 :job-name "frobozz-executor" :job-status 
> :queued} ...]
>
> Now here's where things get iffy in practice.  Suppose I have other 
> database interfaces that take similar but different maps or collections of 
> keywords.
>
> For example, a function like this which lets you specify which fields you 
> want retrieved:
>
> (s/fdef get-selective-jobs
>   :args (s/cat :db database-handle? :fields (s/coll-of #{:job-id :job-name 
> :job-status}))
>
  :ret (s/coll-of (s/keys :opt-un [ ::job-id ::job-name ::job-status 
])))

^^ correction of :fields above, additiobn of :ret


> (defn get-selective-jobs
>   [db fields]
>   ... return only fields from the database that are specified in the 
> fields parameter ...)
>
>
> Once you start getting some similar-but-different specs, it'd be nice 
> apply a bit of code building.
>
> e.g.
>
> (def job-field-keys [::job-id ::job-name ::job-status])
>
> (s/def ::job-record (s/keys* :req-un job-field-keys))
> (s/fdef get-selective-args
>   :args (s/cat* :db database-handle? :fields  (s/coll-of (set 
> job-field-keys))
>
:ret (s/coll-of (s/keys* :opt-un job-field-keys)))

^^ correction to :args above, addition of :ret


> Hopefully this is conducive to some thought/discussion of the subject, 
> and/or someone can just let me know how I should be doing this if there's 
> an easy way in the present spec implementation.
>

The point being that it's be nice to have some easier ways of specifying 
similar but different sets of data in
s/keys, s/cat, s/coll-of, and possibly other macros.

 

>
> Sidewise plea: inline specs for s/keys like you can do for s/cat.  s/keys 
> deliberate omision of inline specs does occasionally get in the way in 
> large namespaces.
>   
>
>
>

-- 
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.spec: need function equivalents of library macros?

2017-05-08 Thread Dave Tenny
Let's say I have a namespace that provides access to the database,
say our table has these fields (as clojure specs)

(s/def ::job-id nat-int?) ; 1 2 3 ...
(s/def ::job-name string?) ; frobozz-executor
(s/def ::job-status keyword?) ; :queued, :in-progress, :completed


And that I have the logic in place to convert to/from the types (e.g. 
keywords).

If I have a simple function to return records in from the jobs table it 
might look like:

(s/def ::job-record (s/keys :req-un [::job-id ::job-name ::job-status]))

(s/fdef get-jobs
  :args (s/cat :db database-handle?)
  :ret (s/coll-of ::job-record))

(defn get-jobs
  [db]
  ... returns vector of maps, one for each record, jdbc-style ...)

(get-jobs) => [{:job-id 1 :job-name "frobozz-executor" :job-status :queued} 
...]

Now here's where things get iffy in practice.  Suppose I have other 
database interfaces that take similar but different maps or collections of 
keywords.

For example, a function like:

(s/fdef get-selective-jobs
  :args (s/cat :db database-handle? :fields (s/keys :opt-un [::job-id 
::job-name ::job-status])))

(defn get-selective-jobs
  [db fields]
  ... return only fields from the database that are specified in the fields 
parameter ...)


Once you start getting some similar-but-different specs, it'd be nice apply 
a bit of code building.

e.g.

(def job-field-keys [::job-id ::job-name ::job-status])

(s/def ::job-record (s/keys* :req-un job-field-keys))
(s/fdef get-selective-args
  :args (s/cat* :db database-handle? :fields  (s/keys :opt-un 
job-field-keys))

Hopefully this is conducive to some thought/discussion of the subject, 
and/or someone can just let me know how I should be doing this if there's 
an easy way in the present spec implementation.

Sidewise plea: inline specs for s/keys like you can do for s/cat.  s/keys 
deliberate omision of inline specs does occasionally get in the way in 
large namespaces.
  


-- 
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 and RFC] Bifurcan: impure functional data strucures

2017-04-24 Thread Dave Dixon
Both, actually. The algorithm incrementally builds a tree via simulation. 
There's a step of traversing the current version of the tree to find a 
leaf, which requires immutability, as I have to remember the path taken 
(the path is generated via simulation, not by walking an existing tree 
structure, so requires updates to the state maps). But once at a leaf, I 
run multiple simulations in parallel, and provided each starts with an 
independent mutable "copy", then the subsequent states can be mutable. That 
should be a big perf win, since it's where the algo spends a lot of it's 
time. The data structures that hold the statistics about the states in the 
tree could also be mutable. These are keyed by state maps, hoping improved 
hash/equality performance will help a little there as well.

On Sunday, April 23, 2017 at 1:18:56 PM UTC-7, Zach Tellman wrote:
>
> Are you relying on the immutability of these structures, or are they 
> effectively always transient?
> On Sun, Apr 23, 2017 at 11:02 AM Dave Dixon <dave.d...@gmail.com 
> > wrote:
>
>> FWIW, the use-case I have essentially involves Monte Carlo simulations. 
>> So we start with a state (non-empty map), and then make a series of 
>> modifications to it. Various statistics are held in hash-maps keyed by the 
>> state, so there's a lot of lookups and modifications in those maps.
>>
>> That said, I'm not sure if for this particular case I care too much using 
>> Clojure idioms vs. direct API access. The algorithms tend to be 
>> hand-tweaked for performance anyway. The big win for me in wrapping 
>> bifurcan would be the ability to use spec without having to write 
>> specialized specs, generators, etc.
>>
>>
>> On Thursday, April 20, 2017 at 9:53:56 PM UTC-7, Zach Tellman wrote:
>>
>>> Sure, happy to elaborate.  Bifurcan offers potential performance wins a 
>>> few different ways:
>>>
>>> * We can use standard Java equality semantics, bypassing all the 
>>> overhead of the hash calculations and enhanced numeric equality checks 
>>> (this can lead to moderate performance gains)
>>> * We can use a mutable data structure as long as it never escapes a 
>>> local context (this can lead to significant performance gains)
>>> * We can use the extra capabilities the data structures expose, like 
>>> concatenation, slicing, set operations, etc. (this is too dependent on the 
>>> use case to really quantify)
>>>
>>
>>> it would be easy to have a `map` and `map*` method that expose Clojure 
>>> and Java equality semantics, respectively, but that puts a big onus on the 
>>> developer to determine if the latter is safe for their use case.  I've been 
>>> bit by this when I've used j.u.c.ConcurrentHashMap before, so I expect 
>>> people will suffer similarly weird bugs.
>>>
>>> However, I think there's a way to use the mutable data structures.  
>>> Technically, transient data structures allow arbitrary persistent data 
>>> structures to be batch updated, but in practice they tend to be empty, and 
>>> after they're populated they tend to be treated as read-only.
>>>
>>> If we're convinced this is common enough, every empty transient data 
>>> structure could be mutable, and when we make it persistent we could wrap it 
>>> in a "virtual" collection [1] which allows updates without touching the 
>>> base collection.  This would allow for faster writes, faster reads, and 
>>> only marginally slower updates if those are required.
>>>
>>> This is all predicated on a bunch of assumptions that are hard to 
>>> validate, but if this describes enough real-world use cases, it could lead 
>>> to a big, easy performance win.  It's even possible to automatically 
>>> replace the base Clojure collections with these alternatives using 
>>> something like Sleight [2].
>>>
>>> Anyway, that's what I've been mulling over.  If anyone has opinions, I'm 
>>> happy to hear them.
>>>
>>> Zach
>>>
>>> [1] 
>>> https://github.com/lacuna/bifurcan/blob/master/src/io/lacuna/bifurcan/Maps.java#L103
>>> [2] https://github.com/ztellman/sleight
>>>
>>> On Thu, Apr 20, 2017 at 8:55 AM Dave Dixon <dave.d...@gmail.com> wrote:
>>>
>>>> Sounds great. If you have time, I'd certainly like to hear your 
>>>> thoughts on the issues of equality semantics and transients, maybe I can 
>>>> ponder and make some suggestions based on my target use-case.
>>>>
>>>>
>>>> On Tuesday, April 18, 2017 at 

Re: [ANN and RFC] Bifurcan: impure functional data strucures

2017-04-23 Thread Dave Dixon
FWIW, the use-case I have essentially involves Monte Carlo simulations. So 
we start with a state (non-empty map), and then make a series of 
modifications to it. Various statistics are held in hash-maps keyed by the 
state, so there's a lot of lookups and modifications in those maps.

That said, I'm not sure if for this particular case I care too much using 
Clojure idioms vs. direct API access. The algorithms tend to be 
hand-tweaked for performance anyway. The big win for me in wrapping 
bifurcan would be the ability to use spec without having to write 
specialized specs, generators, etc.

On Thursday, April 20, 2017 at 9:53:56 PM UTC-7, Zach Tellman wrote:

> Sure, happy to elaborate.  Bifurcan offers potential performance wins a 
> few different ways:
>
> * We can use standard Java equality semantics, bypassing all the overhead 
> of the hash calculations and enhanced numeric equality checks (this can 
> lead to moderate performance gains)
> * We can use a mutable data structure as long as it never escapes a local 
> context (this can lead to significant performance gains)
> * We can use the extra capabilities the data structures expose, like 
> concatenation, slicing, set operations, etc. (this is too dependent on the 
> use case to really quantify)
>
> it would be easy to have a `map` and `map*` method that expose Clojure and 
> Java equality semantics, respectively, but that puts a big onus on the 
> developer to determine if the latter is safe for their use case.  I've been 
> bit by this when I've used j.u.c.ConcurrentHashMap before, so I expect 
> people will suffer similarly weird bugs.
>
> However, I think there's a way to use the mutable data structures.  
> Technically, transient data structures allow arbitrary persistent data 
> structures to be batch updated, but in practice they tend to be empty, and 
> after they're populated they tend to be treated as read-only.
>
> If we're convinced this is common enough, every empty transient data 
> structure could be mutable, and when we make it persistent we could wrap it 
> in a "virtual" collection [1] which allows updates without touching the 
> base collection.  This would allow for faster writes, faster reads, and 
> only marginally slower updates if those are required.
>
> This is all predicated on a bunch of assumptions that are hard to 
> validate, but if this describes enough real-world use cases, it could lead 
> to a big, easy performance win.  It's even possible to automatically 
> replace the base Clojure collections with these alternatives using 
> something like Sleight [2].
>
> Anyway, that's what I've been mulling over.  If anyone has opinions, I'm 
> happy to hear them.
>
> Zach
>
> [1] 
> https://github.com/lacuna/bifurcan/blob/master/src/io/lacuna/bifurcan/Maps.java#L103
> [2] https://github.com/ztellman/sleight
>
> On Thu, Apr 20, 2017 at 8:55 AM Dave Dixon <dave.d...@gmail.com 
> > wrote:
>
>> Sounds great. If you have time, I'd certainly like to hear your thoughts 
>> on the issues of equality semantics and transients, maybe I can ponder and 
>> make some suggestions based on my target use-case.
>>
>>
>> On Tuesday, April 18, 2017 at 9:32:32 AM UTC-7, Zach Tellman wrote:
>>
>>> To be clear, my intention was always to wrap the implementations in the 
>>> appropriate Clojure interfaces, and I don't believe that will cause much, 
>>> if any, of a performance hit (inlining is magic).  However, there are some 
>>> real questions regarding how to expose non-standard equality semantics, and 
>>> whether transients should be represented using the immutable or mutable 
>>> collection variants.  
>>>
>>> For what it's worth, I have about 1/3 of an implementation of 
>>> Clojure-compatible versions of these data structures, I just wanted to mull 
>>> on the above questions a bit before going further.  I'm happy to discuss 
>>> them here in more depth if you have any questions or opinions.
>>>
>>> Zach
>>>
>>> On Tue, Apr 18, 2017 at 6:53 AM Dave Dixon <dave.d...@gmail.com> wrote:
>>>
>> Stared at this a bit yesterday. Seems like if you want to leverage spec 
>>>> while using bifurcan, then the bifurcan types need to have the Clojure 
>>>> wrapper. The alternative appears to be re-implementing at least a large 
>>>> subset of collection-related spec code, which is a lot to bite off. Also 
>>>> tried updating some existing code to use bifurcan. Similar to spec, there 
>>>> are going to be cases which are less perf sensitive, where it would be 
>>>> nice 
>>>> to use code that is polymorphic for collec

Re: [ANN and RFC] Bifurcan: impure functional data strucures

2017-04-20 Thread Dave Dixon
Sounds great. If you have time, I'd certainly like to hear your thoughts on 
the issues of equality semantics and transients, maybe I can ponder and 
make some suggestions based on my target use-case.

On Tuesday, April 18, 2017 at 9:32:32 AM UTC-7, Zach Tellman wrote:
>
> To be clear, my intention was always to wrap the implementations in the 
> appropriate Clojure interfaces, and I don't believe that will cause much, 
> if any, of a performance hit (inlining is magic).  However, there are some 
> real questions regarding how to expose non-standard equality semantics, and 
> whether transients should be represented using the immutable or mutable 
> collection variants.  
>
> For what it's worth, I have about 1/3 of an implementation of 
> Clojure-compatible versions of these data structures, I just wanted to mull 
> on the above questions a bit before going further.  I'm happy to discuss 
> them here in more depth if you have any questions or opinions.
>
> Zach
>
> On Tue, Apr 18, 2017 at 6:53 AM Dave Dixon <dave.d...@gmail.com 
> > wrote:
>
>> Stared at this a bit yesterday. Seems like if you want to leverage spec 
>> while using bifurcan, then the bifurcan types need to have the Clojure 
>> wrapper. The alternative appears to be re-implementing at least a large 
>> subset of collection-related spec code, which is a lot to bite off. Also 
>> tried updating some existing code to use bifurcan. Similar to spec, there 
>> are going to be cases which are less perf sensitive, where it would be nice 
>> to use code that is polymorphic for collections, and drop down to the fast 
>> interface in perf-sensitive parts.
>>
>>
>> On Monday, April 17, 2017 at 1:52:39 PM UTC-7, Dave Dixon wrote:
>>>
>>> What is the issue with wrapping in Clojure interfaces? Added overhead of 
>>> function calls?
>>>
>>> I'm finding myself in the process of doing some of this, at least for 
>>> constructors. Also thinking of generating predicates/generators for use 
>>> with spec.
>>>
>>> On Monday, March 27, 2017 at 9:51:46 AM UTC-7, Zach Tellman wrote:
>>>
>>>> This is a slightly irregular announcement, because it's not for a 
>>>> Clojure library.  Rather, it's for a library written purely in Java: 
>>>> https://github.com/lacuna/bifurcan.
>>>>
>>>> This is a collection of mutable and immutable data structures, designed 
>>>> to address some of my personal frustrations with what's available in the 
>>>> Clojure and Java ecosystems.  Notably, they have pluggable equality 
>>>> semantics, so while they *can* use Clojure's expensive hash and equality 
>>>> checks, they don't *have* to.  They also provide high-performance mutable 
>>>> variants of the data structure which share an API with their immutable 
>>>> cousins.  
>>>>
>>>> I'm posting it here to ask for people's thoughts on how, if at all, 
>>>> this should be exposed as a Clojure library.  It would be simple to simply 
>>>> wrap them in the Clojure interfaces and make them behave identically to 
>>>> Clojure's own data structures, but that kind of obviates the point.  
>>>> However, creating an entirely new set of accessors means that we can't 
>>>> leverage Clojure's standard library.
>>>>
>>>> It's possible that I'm alone in my frustrations, and no Clojure wrapper 
>>>> is necessary.  But if this does solve a problem you have, I'd like to hear 
>>>> more about what it is, and how you think Bifurcan might help.  Please feel 
>>>> free to reply here, or to grab me at Clojure/West and talk about it there.
>>>>
>>>> Thanks in advance,
>>>> Zach
>>>>
>>> -- 
>> 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 a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/1m_I7IrDGb0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> clojure+u...@googlegroups.com .
>>

Re: [ANN and RFC] Bifurcan: impure functional data strucures

2017-04-18 Thread Dave Dixon
Stared at this a bit yesterday. Seems like if you want to leverage spec 
while using bifurcan, then the bifurcan types need to have the Clojure 
wrapper. The alternative appears to be re-implementing at least a large 
subset of collection-related spec code, which is a lot to bite off. Also 
tried updating some existing code to use bifurcan. Similar to spec, there 
are going to be cases which are less perf sensitive, where it would be nice 
to use code that is polymorphic for collections, and drop down to the fast 
interface in perf-sensitive parts.

On Monday, April 17, 2017 at 1:52:39 PM UTC-7, Dave Dixon wrote:
>
> What is the issue with wrapping in Clojure interfaces? Added overhead of 
> function calls?
>
> I'm finding myself in the process of doing some of this, at least for 
> constructors. Also thinking of generating predicates/generators for use 
> with spec.
>
> On Monday, March 27, 2017 at 9:51:46 AM UTC-7, Zach Tellman wrote:
>
>> This is a slightly irregular announcement, because it's not for a Clojure 
>> library.  Rather, it's for a library written purely in Java: 
>> https://github.com/lacuna/bifurcan.
>>
>> This is a collection of mutable and immutable data structures, designed 
>> to address some of my personal frustrations with what's available in the 
>> Clojure and Java ecosystems.  Notably, they have pluggable equality 
>> semantics, so while they *can* use Clojure's expensive hash and equality 
>> checks, they don't *have* to.  They also provide high-performance mutable 
>> variants of the data structure which share an API with their immutable 
>> cousins.  
>>
>> I'm posting it here to ask for people's thoughts on how, if at all, this 
>> should be exposed as a Clojure library.  It would be simple to simply wrap 
>> them in the Clojure interfaces and make them behave identically to 
>> Clojure's own data structures, but that kind of obviates the point. 
>>  However, creating an entirely new set of accessors means that we can't 
>> leverage Clojure's standard library.
>>
>> It's possible that I'm alone in my frustrations, and no Clojure wrapper 
>> is necessary.  But if this does solve a problem you have, I'd like to hear 
>> more about what it is, and how you think Bifurcan might help.  Please feel 
>> free to reply here, or to grab me at Clojure/West and talk about it there.
>>
>> Thanks in advance,
>> Zach
>>
>

-- 
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 and RFC] Bifurcan: impure functional data strucures

2017-04-17 Thread Dave Dixon
What is the issue with wrapping in Clojure interfaces? Added overhead of 
function calls?

I'm finding myself in the process of doing some of this, at least for 
constructors. Also thinking of generating predicates/generators for use 
with spec.

On Monday, March 27, 2017 at 9:51:46 AM UTC-7, Zach Tellman wrote:

> This is a slightly irregular announcement, because it's not for a Clojure 
> library.  Rather, it's for a library written purely in Java: 
> https://github.com/lacuna/bifurcan.
>
> This is a collection of mutable and immutable data structures, designed to 
> address some of my personal frustrations with what's available in the 
> Clojure and Java ecosystems.  Notably, they have pluggable equality 
> semantics, so while they *can* use Clojure's expensive hash and equality 
> checks, they don't *have* to.  They also provide high-performance mutable 
> variants of the data structure which share an API with their immutable 
> cousins.  
>
> I'm posting it here to ask for people's thoughts on how, if at all, this 
> should be exposed as a Clojure library.  It would be simple to simply wrap 
> them in the Clojure interfaces and make them behave identically to 
> Clojure's own data structures, but that kind of obviates the point. 
>  However, creating an entirely new set of accessors means that we can't 
> leverage Clojure's standard library.
>
> It's possible that I'm alone in my frustrations, and no Clojure wrapper is 
> necessary.  But if this does solve a problem you have, I'd like to hear 
> more about what it is, and how you think Bifurcan might help.  Please feel 
> free to reply here, or to grab me at Clojure/West and talk about it there.
>
> Thanks in advance,
> Zach
>

-- 
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 and RFC] Bifurcan: impure functional data strucures

2017-03-27 Thread Dave Dixon
I think this would solve an issue I'm facing. I'm working on implementing 
variations of Monte Carlo tree search for very large trees, with states and 
actions represented by maps. There are several lookup tables indexed by 
either state or state-action pairs. I haven't done any detailed 
benchmarking or perf analysis, but I'm guess that hash/equality consumes no 
small amount of time.

On Monday, March 27, 2017 at 9:51:46 AM UTC-7, Zach Tellman wrote:
>
> This is a slightly irregular announcement, because it's not for a Clojure 
> library.  Rather, it's for a library written purely in Java: 
> https://github.com/lacuna/bifurcan.
>
> This is a collection of mutable and immutable data structures, designed to 
> address some of my personal frustrations with what's available in the 
> Clojure and Java ecosystems.  Notably, they have pluggable equality 
> semantics, so while they *can* use Clojure's expensive hash and equality 
> checks, they don't *have* to.  They also provide high-performance mutable 
> variants of the data structure which share an API with their immutable 
> cousins.  
>
> I'm posting it here to ask for people's thoughts on how, if at all, this 
> should be exposed as a Clojure library.  It would be simple to simply wrap 
> them in the Clojure interfaces and make them behave identically to 
> Clojure's own data structures, but that kind of obviates the point. 
>  However, creating an entirely new set of accessors means that we can't 
> leverage Clojure's standard library.
>
> It's possible that I'm alone in my frustrations, and no Clojure wrapper is 
> necessary.  But if this does solve a problem you have, I'd like to hear 
> more about what it is, and how you think Bifurcan might help.  Please feel 
> free to reply here, or to grab me at Clojure/West and talk about it there.
>
> Thanks in advance,
> Zach
>

-- 
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.spec s/keys map key with alternative definitions in same namespace

2017-02-07 Thread Dave Tenny
>From my perspective, there are two specs.  I'm not trying to mash them
together, however I would like to use the appropriate spec with the same
keyword in maps, in different contexts.

It wouldn't be an issue if the contexts were in separate namespaces.  It's
only an issue because the two specs are in the same namespace, and I want
to use them in different places with the same map key.

(Or so it seems to me, still wrapping my head around spec).

On Tue, Feb 7, 2017 at 11:10 AM, Alex Miller <a...@puredanger.com> wrote:

> Spec names are intended to have enduring global semantics. So the notion
> of the same spec name having different semantics at different times seems
> to be at odds with that.
>
> In general, it's often helpful to think about all the possible values that
> an attribute will have - that's the true spec. In this case, it seems like
> what you have for ::coercible-job-type is the true spec - it can be either
> a string or other named value.
>
> And then think about the places where you need to add additional
> constraints to your ::job-record spec to narrow it. Like maybe here:
>
> (s/fdef ... :ret (s/and ::job-record #(-> % ::job-type string?)))
>
> You're on the brink of suggesting subtypes and covariant / contravariants,
> etc and that's a path spec is not going down.
>
>
> On Tuesday, February 7, 2017 at 9:40:24 AM UTC-6, Dave Tenny wrote:
>>
>> Let's say I have these definitions for a "job" record I'm managing,
>> perhaps in a database.
>>
>> (s/def ::job-status #{:in-progress :completed})
>> (s/def ::user-id (s/and integer? #(>= % 0)))
>> (s/def ::job-id integer?)
>>
>> (s/def ::coercible-job-type (s/and named? #(not (empty? (name %)
>> (s/def ::job-type (s/and string? #(not (empty? %
>>
>> So we have a job status which can be any of a limited set of keywords,
>> integer user and job ID's.
>>
>> Then there's job type and my issue.  Depending on the context I want
>> either to insist that job type will be purely a non-empty string, or that
>> it may also be a 'named?' object,
>> i.e. something for which the clojure.core/name function will work.
>>
>> If I'm just returning a pure job record, my definition would look like
>> this:
>>
>> (s/def ::job-record
>>   (s/keys :req-un [::job-id ::user-id ::job-type ::job-status]))
>>
>> So a map with all those keys and type definitions. And that's great.  I
>> define functions that return these
>> maps and so there's an (s/fdef ... :ret ::job-record).
>>
>> Now let's say I have an update! function that can take a map of optional
>> fields and update the record in the database with the fields that were
>> specified.
>>
>> (s/def ::field-options (s/keys :opt-un [::job-id ::user-id ::job-type
>> ::job-status]))
>> (s/fdef update! :args (s/cat ::field-map ::field-options) ...)
>> (defn update! [field-map] ... (:job-type field-map) ...)
>>
>> So far, so good. I have a parameter 'field-map' that can take optional
>> map keys, validate map arguments if the testing instrumentation is enabled,
>> etc.
>>
>> Here is my problem.  There appears to be no way for me to define, in this
>> namespace, map specs with a :job-type key, but that will have
>> :coercible-job-type semantics,
>> for my update! function. Or at least I don't see an easy way short of
>> writing a function to do everything that the existing machinery is doing
>> with respect to key and value validation,
>> which is a lot of work to handle this tiny thing, basically the ability
>> to have map keys and spec semantics bound to different names in s/keys
>> specs.
>>
>> For example, the following pseudo-spec might let me define a map key
>> :job-type whose semantics were specified by the ::coercible-job-type
>> definition.
>> Or inlining of definitions which the spec guide says was omitted on
>> purpose.
>>
>> (s/def ::field-map (s/keys :opt-un [... [::coercible-job-type :as ::job-
>> type]]))
>>
>> I want the map key to be ":job-type", but the clojure.spec semantics for
>> that field, *in selective module definitions*, to have ::coercible-job-type
>> behavior.
>>
>> So... am I missing something?
>>
>> --
> 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, 

clojure.spec s/keys map key with alternative definitions in same namespace

2017-02-07 Thread Dave Tenny
Let's say I have these definitions for a "job" record I'm managing, perhaps 
in a database.

(s/def ::job-status #{:in-progress :completed})
(s/def ::user-id (s/and integer? #(>= % 0)))
(s/def ::job-id integer?)

(s/def ::coercible-job-type (s/and named? #(not (empty? (name %)
(s/def ::job-type (s/and string? #(not (empty? %

So we have a job status which can be any of a limited set of keywords,
integer user and job ID's.  

Then there's job type and my issue.  Depending on the context I want either 
to insist that job type will be purely a non-empty string, or that it may 
also be a 'named?' object, 
i.e. something for which the clojure.core/name function will work.

If I'm just returning a pure job record, my definition would look like this:

(s/def ::job-record 
  (s/keys :req-un [::job-id ::user-id ::job-type ::job-status]))

So a map with all those keys and type definitions. And that's great.  I 
define functions that return these
maps and so there's an (s/fdef ... :ret ::job-record).

Now let's say I have an update! function that can take a map of optional 
fields and update the record in the database with the fields that were 
specified.

(s/def ::field-options (s/keys :opt-un [::job-id ::user-id ::job-type 
::job-status]))
(s/fdef update! :args (s/cat ::field-map ::field-options) ...)
(defn update! [field-map] ... (:job-type field-map) ...)

So far, so good. I have a parameter 'field-map' that can take optional map 
keys, validate map arguments if the testing instrumentation is enabled, etc.

Here is my problem.  There appears to be no way for me to define, in this 
namespace, map specs with a :job-type key, but that will have 
:coercible-job-type semantics,
for my update! function. Or at least I don't see an easy way short of 
writing a function to do everything that the existing machinery is doing 
with respect to key and value validation,
which is a lot of work to handle this tiny thing, basically the ability to 
have map keys and spec semantics bound to different names in s/keys specs.

For example, the following pseudo-spec might let me define a map key 
:job-type whose semantics were specified by the ::coercible-job-type 
definition.
Or inlining of definitions which the spec guide says was omitted on purpose.

(s/def ::field-map (s/keys :opt-un [... [::coercible-job-type :as ::job-type
]]))

I want the map key to be ":job-type", but the clojure.spec semantics for 
that field, *in selective module definitions*, to have ::coercible-job-type 
behavior.

So... am I missing something?

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


named? predicate?

2017-02-07 Thread Dave Tenny
I've occasionally wanted this and haven't found it.

(defn named?
  "True if object is compatible with the 'name' function.
  There must be a clojure built-in to do this but I haven't figured it out 
yet."
  [x]
  (or (string? x)
  (keyword? x)
  (symbol? x)))


Note that simply doing (instance? clojure.lang.Named x) won't work for 
strings, but the (name) function does.

Anyway, I'm thinking there's a built in way to do this without defining the 
above function.  Suggestions?

My use case is simply that I want to call the name function for objects 
that support it in a translation function.

-- 
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.spec, maps, restrict valid keywords, easier way?

2017-02-04 Thread Dave Tenny
I have found eastwood to be useful for a number of things, however on 
keyword checking it failed terribly on our code base, though perhaps there 
have been updates since I last tried it.

Thanks for the suggestion though.

On Friday, February 3, 2017 at 7:26:01 PM UTC-5, Ben Brinckerhoff wrote:
>
> The eastwood linter can also be configured to look for possibly misspelled 
> keyword typos
>
> https://github.com/jonase/eastwood#keyword-typos
>
>>
>>>

-- 
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.spec, maps, restrict valid keywords, easier way?

2017-02-02 Thread Dave Tenny
On Thursday, February 2, 2017 at 10:07:31 AM UTC-5, Alex Miller wrote:
>
> We don't encourage you to do this, but I don't have an easier solution 
> than this.
>

Yes, and from the general standpoint of map handling I understand that.

>From the standpoint of functions that take options and don't pass option 
maps through to other functions, I disagree with the clojure philosophy 
here.  So many bugs could be caught if we flagged unexpected map keys when 
they're used as options to functions.  Of course use and validation via 
clojure.spec helps too, but from a general bug catching standpoint I 
believe there's a huge value to flagging inputs to functions that aren't 
recognized by the functions. 

-- 
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.spec, maps, restrict valid keywords, easier way?

2017-02-02 Thread Dave Tenny
I want to specify in clojure spec that only declared keywords are permitted 
in function calls.
This is to catch what are usually mis-spelled or mis-cased keywors passed 
via option maps in function calls.

In the fdefs below, the second fdef will catch an invalid call, e.g. 
(f 1 {:a 2 :B 3})
but the first fdef will not.

Is there an easier way to specify the more restrictive spec without having 
to add my own 'every' and enumeration of the keys?
(or build my own version of s/keys that does this automatically, which I'm 
guessing is the answer).

(require '[clojure.spec :as s])
(require '[clojure.spec.test :as stest])


(s/def ::x (fn [x] true))   ;for lack of any?


;; Will not catch invalid keywords
(s/fdef f
  :args (s/cat :x ::x
   :options (s/keys :opt-un [::a ::b]))
  :ret nil?)


;; Will catch invalid keywords, but is there an easier way?
(s/fdef f
  :args (s/cat :x ::x
   :options (s/and (s/keys :opt-un [::a ::b])
   #(every? #{:a :b} (keys %
  :ret nil?)


(defn f [x {:keys [a b]}])


(stest/instrument `f)





-- 
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: Documentation for namespace aliased keywords (particularly relevant for clojure.spec use)

2017-02-02 Thread Dave Tenny
I also have to wonder why keyword namespaces aren't processed like other 
symbol namespaces, that is, to interpret the namespace portion before a '/' 
with alias consideration.
No doubt there's a good answer, but it seems anachronistic that keywords 
need special syntax contortions to recognize namespace aliases when other 
symbols do not.
(Yes, clojure keywords may not be thought of as symbols, still, the rules 
for alias recognition are inconsistent).


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


Documentation for namespace aliased keywords (particularly relevant for clojure.spec use)

2017-02-01 Thread Dave Tenny
Looking at the documentation for keywords 
under https://clojure.org/reference/reader#_literals
there is no mention for the syntax for namespace aliased keywords, and this 
is very important it you want to manage your keywords for clojure.spec.

I only know about it because google turned up some clojure.spec notes on 
it, but it seems it should be in the mainline clojure docs too.
I certainly didn't know about it until today.

Say we have this namespace:

(ns foo 
  (:require [clojure.spec :as s]))
(s/def ::specific-even-number #(= 1000 %))




And then in the user namespace:

(ns user)
(require '[clojure.spec :as s])
(require '[foo :as f])


(s/valid? :f/specific-even-number 1000) 
;; Exception Unable to resolve spec: :f/specific-even-number  clojure.spec/
reg-resolve! (spec.clj:70)

What is needed is the extra colon, as if we're saying use the current 
namespace, only that isn't what happens.
(s/valid? ::f/specific-even-number 1000)
;; true

Perhaps the clojure docs are correctly stating the use of this kind of 
keyword my interpretation is just flawed, but it certainly wasn't obvious 
to me, and nobody in my team knew that we could do this either.  The result 
was some namespace unfriendly code to avoid typing in long namespaces on 
clojure spec keywords.  Now that we know ::ns-alias/keyword we can do 
better on our clojure.spec use.

(The above tested in clojure 1.8.0).

While I'm here, I want to say that I am _deeply_ disappointed that 
clojure.spec def/fdef forms don't support documentation strings.  I upvoted 
the issue in the bug tracker, but there were only 27 votes including mine 
when I checked on this half-year-plus old issue.
http://dev.clojure.org/jira/browse/CLJ-1965


-- 
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: Custom generators for custom predicate functions

2016-12-08 Thread Dave Dixon
Thanks Alex. I agree it probably isn't "needed", was just a little 
surprised to discover the asymmetry. Mostly was curious if there was some 
deeper design decision, e.g. that you need to start with some set of 
primitive predicates upon which you can start building named specs.

On Thursday, December 8, 2016 at 9:23:11 AM UTC-8, Alex Miller wrote:
>
> In general, you shouldn't need to do this (it is better to attach the 
> generator to the spec). Generator mappings are provided for core Clojure 
> predicates so that many common predicates gen automatically and so that 
> they can be combined (via things like s/and) with other predicates that 
> filter but don't gen.
>
> I was not part of the design discussion, but I assume that it would open a 
> can of worms around conflicts, ordering, and function resolution that Rich 
> and Stu didn't want to open at this time. Nothing precludes this from being 
> expanded later if deemed useful.
>
> On Thursday, December 8, 2016 at 10:56:29 AM UTC-6, Dave Dixon wrote:
>>
>> Though one can obviously attach a custom generator to a keyword-named 
>> spec, it appears there is no way to do the same for a custom predicate 
>> function. I see that the generators for predicate functions testing for 
>> core primitives are hard-coded in the private 
>> clojure.spec.gen\gen-builtins. Curious why this isn't extensible, since it 
>> naively seems similar to the keyword case, but with the custom generator 
>> keyed by a symbol rather than a map.
>>
>> Dave
>>
>

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


Custom generators for custom predicate functions

2016-12-08 Thread Dave Dixon
Though one can obviously attach a custom generator to a keyword-named spec, 
it appears there is no way to do the same for a custom predicate function. 
I see that the generators for predicate functions testing for core 
primitives are hard-coded in the private clojure.spec.gen\gen-builtins. 
Curious why this isn't extensible, since it naively seems similar to the 
keyword case, but with the custom generator keyed by a symbol rather than a 
map.

Dave

-- 
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] Nightcode 2: Total Rewrite

2016-07-15 Thread Dave Yarwood
Nightcode 2 is already looking great! I'm looking forward to seeing how it 
develops.

I'm also tickled that there is an Audio App template using Alda! Let me 
know if there's anything Alda-related I can help with :)

On Wednesday, July 13, 2016 at 1:58:05 PM UTC-4, Zach Oakes wrote:
>
> TL;DR: Nightcode, a Clojure IDE, just got a makeover: 
> https://sekao.net/nightcode/
>
> In a world...where developer tools are gargantuan beasts, unapproachable 
> to beginners, one IDE stood alone.
>
> *a fiddle softly plays ashokan farewell*
>
> “You’re not going already, are you, Nightcode?”
>
> “I must, father. So many new people are learning Clojure. They need me.”
>
> *music becomes ominous as Nightcode rides a wagon into the distance*
>
> Until one day, when it embarked on a journey to save the world...from 
> itself.
>
> *scene switches to Nightcode crouching in a fetal position in a dense 
> forest*
>
> “I’m hearing voices.”
>
> *heavy breathing*
>
> “STOP TALKING TO ME!”
>
> *one of those jumanji drums starts beating slowly and then gets faster and 
> louder*
>
> *the camera zooms in on Nightcode’s face as it suddenly smiles wryly*
>
> Things are about to get...complicated.
>
> *scene changes, a crowd gathers in a small village*
>
> “Gather ‘round! I’m making it easy to start coding!”
>
> “But Nightcode, those appear to be bugs!”
>
> “Wrong, ma’am, they are features! All of them!”
>
> “SILENCE!”
>
> *the crowd becomes mute as a hooded figure moves forward*
>
> “Enough of this madness, Nightcode. In three years your features have 
> remained dormant as your bug count has exploded! Meanwhile, people have 
> been using --”
>
> “Don’t listen to this fraud, you all need me”
>
> *Nightcode lifts its trench coat and releases a plague of bugs on the 
> village as it runs away*
>
> “I don’t want to crash but I will if I have to. I don’t want to crash but 
> I will if I have to. I don’t want to crash but I will if I have to. STOP 
> THE VOICES, MAKE IT STOP!”
>
> When your life is no longer your own...
>
> *screen dims, Nightcode runs into a forest as the village is ravaged*
>
> ...a hero must rise.
>
> *the hooded figure reveals himself*
>
> Meet...Kevin.
>
> *Kevin Hart smiles as upbeat music blares*
>
> “HEY Y’ALL THAT WAS CRAZY! I guess it’s a bad time to ask for a better 
> hotel. HAHA!”
>
> Kevin is just an average guy, with a few...friends.
>
> *the camera pans several feet up to reveal...Ice Cube and Dwayne Johnson*
>
> “This is gonna be bad, Cube.”
>
> “I know, man. How did we get stuck with this guy again?”
>
> A brave trio must save the world from Nightcode...by reinventing it.
>
> “Check it. Nightcode can’t be killed. We gotta find the good inside it and 
> rip it out!”
>
> “YEAH CUBE I AGREE. JUST LIKE YOU DID WITH YOUR CAREER!”
>
> *Cube slaps Hart and continues*
>
> “There’s only one way to do that. We gotta rewrite Nightcode.”
>
> “You mean like a sequel? Like we keep doing with Fast and the Furious? No 
> way.”
>
> “YEAH CUBE, JOEL SPOLSKY SAID YOU SHOULD NEVER --”
>
> “Dammit I KNOW what Joel Spolsky said, and I don’t care. You guys got any 
> better ideas?”
>
> *Hart and Johnson look at each other sheepishly*
>
> *scene switches to a workshop with maps and shit*
>
> “Nightcode is written with Swing, a deprecated UI framework. We’re gonna 
> replace it with Java FX. What do you got Rock?”
>
> “The editor. Right now it doesn’t offer much beyond syntax highlighting. 
> We’re gonna have to write something from scratch.”
>
> “AWW HELL YEAH, GONNA BE LIKE LIGHT TABLE HAD A BABY WITH CURSIVE, 
> HAHAA!”
>
> “What? No. Relax Kev. An instaREPL and some basic inline errors, that’s 
> all we have time for.”
>
> The trio will learn…
>
> *Hart looks in a mirror*
>
> “Oh hey Nightcode, what’s up? CAN YOU DEAL WITH THESE RAINBOW PARENS?! 
> Didn’t think so.”
>
> ...what it’s like…
>
> *Cube emerges from the workshop covered in oil*
>
> “We shrunk the damn jar file from 50 MB to just 19!”
>
> ...to overcome odds.
>
> “The new version has just 1600 lines of code, less than half what the old 
> one has. We may actually pull this off.”
>
> This summer, get ready…
>
> “WATCH ME MOVE. WATCH ME MOVE. WATCH ME -- hey man take it easy put that 
> down be cool.”
>
> ...for the rewrite…
>
> “I’m sick of these motherfuckin’ bugs, on this motherfuckin’ IDE!”
>
> ...of your life.
>
> “We’re gonna get this done or die tryin’. And Kevin IF YOU DON’T STOP 
> DANCING YOU’LL DIE NO MATTER WHAT.”
>
> *a door opens as the trio argue, music stops, and Nightcode’s silhouette 
> appears*
>
> “Game over, gents. How can you replace me? Beginners don’t know how to run 
> jar files.”
>
> “We built native installers, fool.”
>
> *explosions*
>
> NIGHTCODE 2
>
> TOTAL REWRITE
>
> https://sekao.net/nightcode/
>

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

[ANN] Uruk: Clojure lib for MarkLogic NoSQL databases

2016-07-15 Thread Dave Liepmann
Hi folks. 

I am releasing Uruk, a Clojure library for accessing MarkLogic NoSQL 
databases via the XML Content Connector API. Please see 
https://github.com/daveliepmann/uruk and Clojars <https://clojars.org/uruk>. 
Feedback is welcome.

Many thanks go to LambdaWerk <https://lambdawerk.com/home> for sponsoring 
the project.

The project is named after the ancient Mesopotamian city-state in which 
have been found some of the oldest documents known to humanity.

Cheers,
Dave Liepmann

-- 
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: lein project cross-reference tools

2016-04-19 Thread Dave Tenny
I'll take a look at that clj-refactor.

Re: IntelliJ.

I vaguely (possibly incorrectly) recall there was someone who used the
eclipse capabilities for java source code analysis and cross referencing
and packaged it up as some kind of emacs extension. I wonder if anybody has
done that with IntelliJ.



On Tue, Apr 19, 2016 at 2:49 PM, Colin Yates <colin.ya...@gmail.com> wrote:

> Have you tried the 'find usages' functionality of
> https://github.com/clojure-emacs/clj-refactor.el? Also - you might
> want to download IntelliJ and give cursive a try - cursive is
> fantastic for this sort of stuff
>
> ... and yes, I too feel a bit of despair that my suggestions is 'try
> this other tool, if that doesn't work, try this entire editor, if that
> doesn't work then' :-)
>
> On 19 April 2016 at 19:45, Dave Tenny <dave.te...@gmail.com> wrote:
> > Still looking for basic slime-like who-calls in cider.  Is it there and
> I'm
> > just missing it?
> >
> > On Tue, Apr 19, 2016 at 9:57 AM, Dave Tenny <dave.te...@gmail.com>
> wrote:
> >>
> >> Tags aside, a transtive closure who-calls report for a definition would
> >> still be appreciated.
> >>
> >> On Tue, Apr 19, 2016 at 9:53 AM, Dave Tenny <dave.te...@gmail.com>
> wrote:
> >>>
> >>> Hmm, okay, trying etags, certainly plenty of google hits there as
> opposed
> >>> to googling "cross reference".  FYI, in terms of emacs compatibility, I
> >>> generally use CIDER if anybody has suggestoins for how to search
> without a
> >>> live repl or with a live repl but across projects or uberjars.
> >>>
> >>> On Tue, Apr 19, 2016 at 9:33 AM, Dave Tenny <dave.te...@gmail.com>
> wrote:
> >>>>
> >>>> Oh, if crossclj DOES do what I'm asking, please let me know, I found
> the
> >>>> pages I visited a bit confusing as to how I might analyze my (private)
> >>>> projects.
> >>>>
> >>>> On Tue, Apr 19, 2016 at 9:30 AM, Dave Tenny <dave.te...@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> I'm tired of doing 'find-grep' type operations (including that
> command
> >>>>> in emacs).
> >>>>>
> >>>>> Are there any decent tools for producing cross reference reports and
> >>>>> emacs who-calls data in some useful form?
> >>>>>
> >>>>> A search on the topic mostly points to 'crossclj', which doesn't seem
> >>>>> to be what I want (I don't need to see who uses what from, say,
> clojars).
> >>>>>
> >>>>> I have a big project which, in conjunction with 'lein modules' has
> many
> >>>>> subprojects.  I can't really load a REPL on all of them in emacs.
> I'm happy
> >>>>> with source code analysis and the assumption that I don't need to
> know who
> >>>>> is calling functions by obscured dynamic lisp means.
> >>>>>
> >>>>>
> >>>>> --
> >>>>> 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 a topic in
> the
> >>>>> Google Groups "Clojure" group.
> >>>>> To unsubscribe from this topic, visit
> >>>>> https://groups.google.com/d/topic/clojure/ejNMVjyjp-Q/unsubscribe.
> >>>>> To unsubscribe from this group and all its topics, 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 patie

Re: lein project cross-reference tools

2016-04-19 Thread Dave Tenny
Still looking for basic slime-like who-calls in cider.  Is it there and I'm
just missing it?

On Tue, Apr 19, 2016 at 9:57 AM, Dave Tenny <dave.te...@gmail.com> wrote:

> Tags aside, a transtive closure who-calls report for a definition would
> still be appreciated.
>
> On Tue, Apr 19, 2016 at 9:53 AM, Dave Tenny <dave.te...@gmail.com> wrote:
>
>> Hmm, okay, trying etags, certainly plenty of google hits there as opposed
>> to googling "cross reference".  FYI, in terms of emacs compatibility, I
>> generally use CIDER if anybody has suggestoins for how to search without a
>> live repl or with a live repl but across projects or uberjars.
>>
>> On Tue, Apr 19, 2016 at 9:33 AM, Dave Tenny <dave.te...@gmail.com> wrote:
>>
>>> Oh, if crossclj DOES do what I'm asking, please let me know, I found the
>>> pages I visited a bit confusing as to how I might analyze my (private)
>>> projects.
>>>
>>> On Tue, Apr 19, 2016 at 9:30 AM, Dave Tenny <dave.te...@gmail.com>
>>> wrote:
>>>
>>>> I'm tired of doing 'find-grep' type operations (including that command
>>>> in emacs).
>>>>
>>>> Are there any decent tools for producing cross reference reports and
>>>> emacs who-calls data in some useful form?
>>>>
>>>> A search on the topic mostly points to 'crossclj', which doesn't seem
>>>> to be what I want (I don't need to see who uses what from, say, clojars).
>>>>
>>>> I have a big project which, in conjunction with 'lein modules' has many
>>>> subprojects.  I can't really load a REPL on all of them in emacs.  I'm
>>>> happy with source code analysis and the assumption that I don't need to
>>>> know who is calling functions by obscured dynamic lisp means.
>>>>
>>>>
>>>> --
>>>> 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 a topic in the
>>>> Google Groups "Clojure" group.
>>>> To unsubscribe from this topic, visit
>>>> https://groups.google.com/d/topic/clojure/ejNMVjyjp-Q/unsubscribe.
>>>> To unsubscribe from this group and all its topics, 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: lein project cross-reference tools

2016-04-19 Thread Dave Tenny
Tags aside, a transtive closure who-calls report for a definition would
still be appreciated.

On Tue, Apr 19, 2016 at 9:53 AM, Dave Tenny <dave.te...@gmail.com> wrote:

> Hmm, okay, trying etags, certainly plenty of google hits there as opposed
> to googling "cross reference".  FYI, in terms of emacs compatibility, I
> generally use CIDER if anybody has suggestoins for how to search without a
> live repl or with a live repl but across projects or uberjars.
>
> On Tue, Apr 19, 2016 at 9:33 AM, Dave Tenny <dave.te...@gmail.com> wrote:
>
>> Oh, if crossclj DOES do what I'm asking, please let me know, I found the
>> pages I visited a bit confusing as to how I might analyze my (private)
>> projects.
>>
>> On Tue, Apr 19, 2016 at 9:30 AM, Dave Tenny <dave.te...@gmail.com> wrote:
>>
>>> I'm tired of doing 'find-grep' type operations (including that command
>>> in emacs).
>>>
>>> Are there any decent tools for producing cross reference reports and
>>> emacs who-calls data in some useful form?
>>>
>>> A search on the topic mostly points to 'crossclj', which doesn't seem to
>>> be what I want (I don't need to see who uses what from, say, clojars).
>>>
>>> I have a big project which, in conjunction with 'lein modules' has many
>>> subprojects.  I can't really load a REPL on all of them in emacs.  I'm
>>> happy with source code analysis and the assumption that I don't need to
>>> know who is calling functions by obscured dynamic lisp means.
>>>
>>>
>>> --
>>> 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 a topic in the
>>> Google Groups "Clojure" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/clojure/ejNMVjyjp-Q/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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: lein project cross-reference tools

2016-04-19 Thread Dave Tenny
Hmm, okay, trying etags, certainly plenty of google hits there as opposed
to googling "cross reference".  FYI, in terms of emacs compatibility, I
generally use CIDER if anybody has suggestoins for how to search without a
live repl or with a live repl but across projects or uberjars.

On Tue, Apr 19, 2016 at 9:33 AM, Dave Tenny <dave.te...@gmail.com> wrote:

> Oh, if crossclj DOES do what I'm asking, please let me know, I found the
> pages I visited a bit confusing as to how I might analyze my (private)
> projects.
>
> On Tue, Apr 19, 2016 at 9:30 AM, Dave Tenny <dave.te...@gmail.com> wrote:
>
>> I'm tired of doing 'find-grep' type operations (including that command in
>> emacs).
>>
>> Are there any decent tools for producing cross reference reports and
>> emacs who-calls data in some useful form?
>>
>> A search on the topic mostly points to 'crossclj', which doesn't seem to
>> be what I want (I don't need to see who uses what from, say, clojars).
>>
>> I have a big project which, in conjunction with 'lein modules' has many
>> subprojects.  I can't really load a REPL on all of them in emacs.  I'm
>> happy with source code analysis and the assumption that I don't need to
>> know who is calling functions by obscured dynamic lisp means.
>>
>>
>> --
>> 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 a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/ejNMVjyjp-Q/unsubscribe.
>> To unsubscribe from this group and all its topics, 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: lein project cross-reference tools

2016-04-19 Thread Dave Tenny
Oh, if crossclj DOES do what I'm asking, please let me know, I found the
pages I visited a bit confusing as to how I might analyze my (private)
projects.

On Tue, Apr 19, 2016 at 9:30 AM, Dave Tenny <dave.te...@gmail.com> wrote:

> I'm tired of doing 'find-grep' type operations (including that command in
> emacs).
>
> Are there any decent tools for producing cross reference reports and emacs
> who-calls data in some useful form?
>
> A search on the topic mostly points to 'crossclj', which doesn't seem to
> be what I want (I don't need to see who uses what from, say, clojars).
>
> I have a big project which, in conjunction with 'lein modules' has many
> subprojects.  I can't really load a REPL on all of them in emacs.  I'm
> happy with source code analysis and the assumption that I don't need to
> know who is calling functions by obscured dynamic lisp means.
>
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/ejNMVjyjp-Q/unsubscribe.
> To unsubscribe from this group and all its topics, 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.


lein project cross-reference tools

2016-04-19 Thread Dave Tenny
I'm tired of doing 'find-grep' type operations (including that command in 
emacs).

Are there any decent tools for producing cross reference reports and emacs 
who-calls data in some useful form?  

A search on the topic mostly points to 'crossclj', which doesn't seem to be 
what I want (I don't need to see who uses what from, say, clojars).

I have a big project which, in conjunction with 'lein modules' has many 
subprojects.  I can't really load a REPL on all of them in emacs.  I'm 
happy with source code analysis and the assumption that I don't need to 
know who is calling functions by obscured dynamic lisp means.


-- 
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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

2016-03-19 Thread Dave Ray
Inline below..

Dave

On Thu, Mar 17, 2016 at 9:37 AM, Jason Zwolak <jzwo...@gmail.com> wrote:

> Paul, yeap, Seesaw is definitely something worth considering. Dave Ray
> hasn't abandoned the project, but I sent a personal email to him asking
> about the state of the project and it does seem the Seesaw is in more of a
> maintenance phase than a continue to move forward and improve phase. Dave
> Ray, if you're on this list, would you chime in?
>

 Yep. Seesaw's definitely in maintenance mode. Once upon a time it
overlapped a lot with my day job, but not anymore so I just don't have a
ton of enthusiasm to spend time on it. I'd be open to new maintainers if
someone's feeling adventurous. Otherwise, JavaFX seems like the future so I
think effort would probably be better spent there. A lot has changed in UI
land in the last 5 years.


> Also, I was at the talk you mentioned and was very impressed with their
> methods. What wasn't mentioned in the talk was the fundamental structure of
> the interface between Clojure and JavaFX. One point that _really_ struck me
> is that they have a reoccurring timer running in the background and each
> time it wakes up it checks for changes on the app-state (presumably an
> atom, but I do not remember). If the app-state has changed then it starts
> re-rendering the UI. If I remember correctly it recreates the UI components
> that rely on any part of the app state that has changed. It sounds a little
> similar to Facebook React. I questioned them on this approach as it sounded
> strange to me... and they convinced me it's a good approach for their
> project and inspired me to try something similar on my own... which I'm
> secretly working on ;-)
>
> One thing that makes this work so well for their approach is that they
> have animations that depend on the app state. So their reoccurring timer is
> almost like a video algorithm redrawing the on screen image at the
> specified frame rate.
>
> --
> Jason Zwolak
>
> On Thu, Mar 17, 2016 at 11:06 AM, Paul L. Snyder <p...@pataprogramming.com
> > wrote:
>
>> Yow, old indeed!
>>
>> In 2011, Dave Ray released Seesaw, which is a very nice wrapper for Swing.
>> I've used it for a bunch of projects, and it works great. Of course, it
>> does look like Swing, but it's plenty usable. (It's also still being
>> maintained, so if you're looking for a toolkit that you can use right now,
>> it's a good way to go.)
>>
>>   https://github.com/daveray/seesaw
>>
>> That said, I'd also love to see a JavaFX wrapper. At the Conj in Philly,
>> Cognitect talked about a project where they'd used it extensively:
>>
>>   https://www.youtube.com/watch?v=ajX09xQ_UEg
>>
>> It's definitely piqued my interest.
>>
>> Paul
>>
>> On Sat, 12 Mar 2016, Jason Zwolak wrote:
>>
>> > +1 JavaFX.
>> >
>> > I know this is an old thread... but in case anyone comes across it
>> (like I
>> > did just now) and wants to see where things are, they should know that
>> > JavaFX has come a long way and seems to be Oracle's replacement for
>> Swing.
>> > Now JavaFX is no longer only in JavaFXscript... in fact, I believe
>> > JavaFXscript is deprecated in favor of the JavaFX Java classes.
>> >
>> > I've seen some major projects done with Clojure and JavaFX... even from
>> the
>> > guys at Cognitect.
>> >
>> > On Thursday, May 27, 2010 at 11:18:41 AM UTC-4, Luke VanderHart wrote:
>> > >
>> > > My side project is a fairly complex GUI application written in
>> > > Clojure. Recently, I've become irritated with using Java interop for
>> > > everything. It's not that Clojure doesn't have nice java interop - it
>> > > does. It's just that when interacting with a GUI framework, which is a
>> > > large part of my app, I have to be back in mutable object-oriented
>> > > land, worrying about class hierarchies, mutable state, locks, etc.
>> > > Yucky.
>> > >
>> > > So, with a perhaps dangerous lack of sanity and without any guarantee
>> > > of success, I've decided to try my hand at writing an idiomatic
>> > > Clojure GUI library. If I have success (which I doubt) I will of
>> > > course make it available as open source.
>> > >
>> > > I intend for it to be mostly declarative, with a nice DSL for defining
>> > > GUI elements. Each component will also implement map, and use one of
>> > > Clojure's reference types as an interface for inspecting / updating
>> > > its state. I may also implement some aspects of Functional Reactive

Re: Duplicate key exception reading map that was written to a file

2015-11-25 Thread Dave Kincaid
The number of keys in the map is 8,054,160.

On Wednesday, November 25, 2015 at 10:04:11 PM UTC-6, Dave Kincaid wrote:
>
> I have something very strange going on when I try to write a map out to a 
> file and read it back in. It's a perfectly fine hash-map with ? 
> key/values (so it's pretty big). When I write the map out to a file using
>
> (spit "/tmp/mednotes6153968756847768349/repl-write.edn" (pr-str phrases))
>
> and then read it back in with
>
> (edn/read (PushbackReader. (io/reader 
> "/tmp/mednotes6153968756847768349/repl-write.edn")))
>
> I am getting a duplicate key exception indicating that "? 5" is 
> duplicated. phrases is a clojure.lang.PersistentHashMap. The keys of the 
> map are strings and the values are numbers. When I get the value for "? 5" 
> from the map it returns 352.
>
> I tried to grep the file to find the occurrences of the key "? 5" (and the 
> 30 characters before and after it) and it seems to return 4 of them. The 
> second one is the right one from the map, but I have no idea where the 
> other 3 are coming from.
>
> [/tmp/mednotes6153968756847768349]> egrep -o ".{30}\"\? 5\" .{30}" 
> repl-write.edn 
> hasing a toothbrush for" 160, "? 5" 32, ". ) during his /" 32, "to
>  "is intact with sutures" 32, "? 5" 352, "4.81 pounds" 128, "ceren
> udden" 32, "being up all" 32, "? 5" 32, "limited financial means" 
> , "count , everytime she" 32, "? 5" 32, "had a partial mandibulect
>
> Does anyone have an idea what might be happening when the map is written 
> out to the file? How is that key getting duplicated?
>
> I have tried a few slightly different ways of writing to the file including
>
> (spit "/tmp/mednotes6153968756847768349/repl-write.edn" (binding 
> [*print-dup* true] (pr-str phrases)))
>
> and
>
> (spit "/tmp/mednotes6153968756847768349/repl-write.edn" (.toString 
> phrases))
>
> based on some StackOverflow answers I found. They all seem to do the same 
> thing.
>
> Here is the exception stack trace.
>
> 1. Caused by java.lang.IllegalArgumentException
>Duplicate key: ? 5
>
> PersistentHashMap.java:   67 
>  clojure.lang.PersistentHashMap/createWithCheck
>RT.java: 1538  clojure.lang.RT/map
> EdnReader.java:  631 
>  clojure.lang.EdnReader$MapReader/invoke
> EdnReader.java:  142  clojure.lang.EdnReader/read
> EdnReader.java:  108  clojure.lang.EdnReader/read
>edn.clj:   35  clojure.edn/read
>edn.clj:   33  clojure.edn/read
>   AFn.java:  154  clojure.lang.AFn/applyToHelper
>   AFn.java:  144  clojure.lang.AFn/applyTo
>  Compiler.java: 3623  clojure.lang.Compiler$InvokeExpr/eval
>  Compiler.java:  439  clojure.lang.Compiler$DefExpr/eval
>  Compiler.java: 6787  clojure.lang.Compiler/eval
>  Compiler.java: 6745  clojure.lang.Compiler/eval
>   core.clj: 3081  clojure.core/eval
>   main.clj:  240  clojure.main/repl/read-eval-print/fn
>   main.clj:  240  clojure.main/repl/read-eval-print
>   main.clj:  258  clojure.main/repl/fn
>   main.clj:  258  clojure.main/repl
>RestFn.java: 1523  clojure.lang.RestFn/invoke
> interruptible_eval.clj:   58 
>  clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn
>   AFn.java:  152  clojure.lang.AFn/applyToHelper
>   AFn.java:  144  clojure.lang.AFn/applyTo
>   core.clj:  630  clojure.core/apply
>   core.clj: 1868  clojure.core/with-bindings*
>RestFn.java:  425  clojure.lang.RestFn/invoke
> interruptible_eval.clj:   56 
>  clojure.tools.nrepl.middleware.interruptible-eval/evaluate
> interruptible_eval.clj:  191 
>  clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
> interruptible_eval.clj:  159 
>  clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn
>   AFn.java:   22  clojure.lang.AFn/run
>ThreadPoolExecutor.java: 1142 
>  java.util.concurrent.ThreadPoolExecutor/runWorker
>ThreadPoolExecutor.java:  617 
>  java.util.concurrent.ThreadPoolExecutor$Worker/run
>Thread.java:  745  java.lang.Thread/run
>
>
>
>
>

-- 
You received this message because you are subscribed

Duplicate key exception reading map that was written to a file

2015-11-25 Thread Dave Kincaid
I have something very strange going on when I try to write a map out to a 
file and read it back in. It's a perfectly fine hash-map with ? 
key/values (so it's pretty big). When I write the map out to a file using

(spit "/tmp/mednotes6153968756847768349/repl-write.edn" (pr-str phrases))

and then read it back in with

(edn/read (PushbackReader. (io/reader 
"/tmp/mednotes6153968756847768349/repl-write.edn")))

I am getting a duplicate key exception indicating that "? 5" is duplicated. 
phrases is a clojure.lang.PersistentHashMap. The keys of the map are 
strings and the values are numbers. When I get the value for "? 5" from the 
map it returns 352.

I tried to grep the file to find the occurrences of the key "? 5" (and the 
30 characters before and after it) and it seems to return 4 of them. The 
second one is the right one from the map, but I have no idea where the 
other 3 are coming from.

[/tmp/mednotes6153968756847768349]> egrep -o ".{30}\"\? 5\" .{30}" 
repl-write.edn 
hasing a toothbrush for" 160, "? 5" 32, ". ) during his /" 32, "to
 "is intact with sutures" 32, "? 5" 352, "4.81 pounds" 128, "ceren
udden" 32, "being up all" 32, "? 5" 32, "limited financial means" 
, "count , everytime she" 32, "? 5" 32, "had a partial mandibulect

Does anyone have an idea what might be happening when the map is written 
out to the file? How is that key getting duplicated?

I have tried a few slightly different ways of writing to the file including

(spit "/tmp/mednotes6153968756847768349/repl-write.edn" (binding 
[*print-dup* true] (pr-str phrases)))

and

(spit "/tmp/mednotes6153968756847768349/repl-write.edn" (.toString phrases))

based on some StackOverflow answers I found. They all seem to do the same 
thing.

Here is the exception stack trace.

1. Caused by java.lang.IllegalArgumentException
   Duplicate key: ? 5

PersistentHashMap.java:   67 
 clojure.lang.PersistentHashMap/createWithCheck
   RT.java: 1538  clojure.lang.RT/map
EdnReader.java:  631 
 clojure.lang.EdnReader$MapReader/invoke
EdnReader.java:  142  clojure.lang.EdnReader/read
EdnReader.java:  108  clojure.lang.EdnReader/read
   edn.clj:   35  clojure.edn/read
   edn.clj:   33  clojure.edn/read
  AFn.java:  154  clojure.lang.AFn/applyToHelper
  AFn.java:  144  clojure.lang.AFn/applyTo
 Compiler.java: 3623  clojure.lang.Compiler$InvokeExpr/eval
 Compiler.java:  439  clojure.lang.Compiler$DefExpr/eval
 Compiler.java: 6787  clojure.lang.Compiler/eval
 Compiler.java: 6745  clojure.lang.Compiler/eval
  core.clj: 3081  clojure.core/eval
  main.clj:  240  clojure.main/repl/read-eval-print/fn
  main.clj:  240  clojure.main/repl/read-eval-print
  main.clj:  258  clojure.main/repl/fn
  main.clj:  258  clojure.main/repl
   RestFn.java: 1523  clojure.lang.RestFn/invoke
interruptible_eval.clj:   58 
 clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn
  AFn.java:  152  clojure.lang.AFn/applyToHelper
  AFn.java:  144  clojure.lang.AFn/applyTo
  core.clj:  630  clojure.core/apply
  core.clj: 1868  clojure.core/with-bindings*
   RestFn.java:  425  clojure.lang.RestFn/invoke
interruptible_eval.clj:   56 
 clojure.tools.nrepl.middleware.interruptible-eval/evaluate
interruptible_eval.clj:  191 
 clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
interruptible_eval.clj:  159 
 clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn
  AFn.java:   22  clojure.lang.AFn/run
   ThreadPoolExecutor.java: 1142 
 java.util.concurrent.ThreadPoolExecutor/runWorker
   ThreadPoolExecutor.java:  617 
 java.util.concurrent.ThreadPoolExecutor$Worker/run
   Thread.java:  745  java.lang.Thread/run




-- 
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: Duplicate key exception reading map that was written to a file

2015-11-25 Thread Dave Kincaid
I just tried outputting the map to an Avro file and read it back in. This 
works fine. That tells me that there is something wrong with the way that 
I'm trying to write the EDN file somehow.

Here is the code I used to output to Avro and read back:

(def schema (avro/parse-schema {:type :map :values :long}))
(with-open [out-file (avro/data-file-writer schema 
"/tmp/mednotes6153968756847768349/repl-write.avro")] (.append out-file 
phrases))
(def ps (with-open [in-file (avro/data-file-reader 
"/tmp/mednotes6153968756847768349/repl-write.avro")] (doall (seq in-file

I'm using the excellent abracad library :refer'd as avro.


On Wednesday, November 25, 2015 at 10:40:53 PM UTC-6, Dave Kincaid wrote:
>
> The question marks are actual question marks. I'm not sure how to find the 
> "duplicate" keys in the map in memory. As far as I can tell there is only 
> one "? 5" key in the in memory map.
>
> I thought maybe computing the frequencies of the hash values of the keys 
> and looking for any with more than one would find them, but this code:
>
> read-notes> (def dupes (filter #(> (second %) 1) (frequencies (map hash 
> (keys phrases)
> #'read-notes/dupes
> read-notes> (count dupes)
> 8911
>
> seems to indicate 8,911 keys with identical hash values.
>
>
>>>>

-- 
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: Duplicate key exception reading map that was written to a file

2015-11-25 Thread Dave Kincaid
The question marks are actual question marks. I'm not sure how to find the 
"duplicate" keys in the map in memory. As far as I can tell there is only 
one "? 5" key in the in memory map.

I thought maybe computing the frequencies of the hash values of the keys 
and looking for any with more than one would find them, but this code:

read-notes> (def dupes (filter #(> (second %) 1) (frequencies (map hash 
(keys phrases)
#'read-notes/dupes
read-notes> (count dupes)
8911

seems to indicate 8,911 keys with identical hash values.

On Wednesday, November 25, 2015 at 10:27:29 PM UTC-6, Ghadi Shayban wrote:
>
> While in memory before writing, are the hash codes for the "duplicate" 
> keys the same?   You can call (hash) on the keys.  I'm thinking there is 
> perhaps an issue with unicode string serialization...  Are the question 
> marks a particular character?
>
> If you can find the similar strings in memory, before they are written, 
> call:
> (map int  the-string)
> To see the actual unicode characters for the question marks.
>
> On Wednesday, November 25, 2015 at 11:07:34 PM UTC-5, Dave Kincaid wrote:
>>
>> The number of keys in the map is 8,054,160.
>>
>> On Wednesday, November 25, 2015 at 10:04:11 PM UTC-6, Dave Kincaid wrote:
>>>
>>> I have something very strange going on when I try to write a map out to 
>>> a file and read it back in. It's a perfectly fine hash-map with ? 
>>> key/values (so it's pretty big). When I write the map out to a file using
>>>
>>> (spit "/tmp/mednotes6153968756847768349/repl-write.edn" (pr-str phrases
>>> ))
>>>
>>> and then read it back in with
>>>
>>> (edn/read (PushbackReader. (io/reader 
>>> "/tmp/mednotes6153968756847768349/repl-write.edn")))
>>>
>>> I am getting a duplicate key exception indicating that "? 5" is 
>>> duplicated. phrases is a clojure.lang.PersistentHashMap. The keys of the 
>>> map are strings and the values are numbers. When I get the value for "? 5" 
>>> from the map it returns 352.
>>>
>>> I tried to grep the file to find the occurrences of the key "? 5" (and 
>>> the 30 characters before and after it) and it seems to return 4 of them. 
>>> The second one is the right one from the map, but I have no idea where the 
>>> other 3 are coming from.
>>>
>>> [/tmp/mednotes6153968756847768349]> egrep -o ".{30}\"\? 5\" .{30}" 
>>> repl-write.edn 
>>> hasing a toothbrush for" 160, "? 5" 32, ". ) during his /" 32, "to
>>>  "is intact with sutures" 32, "? 5" 352, "4.81 pounds" 128, "ceren
>>> udden" 32, "being up all" 32, "? 5" 32, "limited financial means" 
>>> , "count , everytime she" 32, "? 5" 32, "had a partial mandibulect
>>>
>>> Does anyone have an idea what might be happening when the map is written 
>>> out to the file? How is that key getting duplicated?
>>>
>>> I have tried a few slightly different ways of writing to the file 
>>> including
>>>
>>> (spit "/tmp/mednotes6153968756847768349/repl-write.edn" (binding 
>>> [*print-dup* true] (pr-str phrases)))
>>>
>>> and
>>>
>>> (spit "/tmp/mednotes6153968756847768349/repl-write.edn" (.toString 
>>> phrases))
>>>
>>> based on some StackOverflow answers I found. They all seem to do the 
>>> same thing.
>>>
>>> Here is the exception stack trace.
>>>
>>> 1. Caused by java.lang.IllegalArgumentException
>>>Duplicate key: ? 5
>>>
>>> PersistentHashMap.java:   67 
>>>  clojure.lang.PersistentHashMap/createWithCheck
>>>RT.java: 1538  clojure.lang.RT/map
>>> EdnReader.java:  631 
>>>  clojure.lang.EdnReader$MapReader/invoke
>>> EdnReader.java:  142  clojure.lang.EdnReader/read
>>> EdnReader.java:  108  clojure.lang.EdnReader/read
>>>edn.clj:   35  clojure.edn/read
>>>edn.clj:   33  clojure.edn/read
>>>   AFn.java:  154  clojure.lang.AFn/applyToHelper
>>>   AFn.java:  144  clojure.lang.AFn/applyTo
>>>  Compiler.java: 3623 
>>>  clojure.lang.Compiler$InvokeExpr/eval
>>>  Compiler.java:  439  clojure.lang.Compiler$De

Re: [ANN] Pipes 0.1.1 - chain processes, shell commands and threads via pipes

2015-11-13 Thread Dave Tenny
Just a bit of history from which you might derive some inspiration for your 
pipe metaphors in Clojure,
the scheme shell.

Main site: 
http://scsh.net/

Docs on various constructs, including process I/O operators:
http://scsh.net/docu/html/man-Z-H-1.html#node_toc_start



On Friday, November 13, 2015 at 9:13:56 AM UTC-5, Marcin Bilski wrote:
>
> Home: https://github.com/bilus/pipes
>
> If you ever used Un*x pipes
>
> ```
> $ ls | grep .clj
> ```
>
> then this library gives you a power to do this in Clojure and a lot more. 
>
> You can use streams to chain any number of shell commands, processes and 
> Clojure functions to process the streams on the fly. The library handles 
> error exit codes, exceptions by shutting down the pipeline and closing 
> intermediate streams. It also lets you cancel the entire pipeline with a 
> single function call and much more.
>
> I just pushed out the first version of the library. I extracted it from 
> production code so it's safe to use despite its low version number.
>
> The documentation is rudimentary and work in progress, I'm going to add 
> more examples.
>
> I'm looking forward to your feedback and, most of all, critique. Thank you.
>

-- 
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: Style, Efficiency, and updating nested structure

2015-11-12 Thread Dave Tenny
Thanks for the replies, as always lots of interesting ways to do it in
clojure.  No zipper sugestions?

For my own take, I happen to like the last suggestion (Gareth's) the most I
think, of the ones offered so far.  It has a lispy elegance and is still
relatively efficient in traversals and memory allocation, compared to some
solutions (particular with a revision to the merge-roles implementation to
eliminate all the set creation, see next sentence).

Some of you rewrote the problem a bit.  For example, the 'merge-roles'
conversion to sets is very expensive, especially since I know that the
input in my original problem isn't going to offer duplicate project rules
for a given project ID.

On efficiency in general, it is perhaps a generational thing that people
say "don't prematurely optimize" so often and then cons up intermediate
objects with wild abandon.  And while a well crafted stop and copy garbage
collector can be have negligable GC time given sufficient memory free
space, allocations are still not free even in the best case, not to mention
the time to build the object being allocated (like hashing/comparing all
the values in a set).

I'd like to suggest that there is a difference between premature
optimization and avoiding flagrantly inefficient code.
If you code so that you routinely copy sequences and nested data structures
without a care, then in a serious/large system
your performance will have death by a thousand cuts.  The big O matters, at
least in some applications.

As indicated in this problem, the input is coming from a database, i.e. a
potentially large record source. My bias is that per-record processing is
always best kept to a minimum.  So inverting maps, copying sequences,
creating sets and such _*for every record*_ is just a big "nope" for me.
 And that doesn't even consider what went into the retrieval of the records
from clojure.java.jdbc/query, where every record comes back as a map unless
you do something to prevent it.

Meanwhile there were good suggestions for both abstraction and efficiency
here, thanks.  I often forget about lazy-seq and have a tendency to lean
toward loop/recur, probably from too many years using Common Lisp.  And of
course elimination of the mutable change detection hack is good too.So
nice to see the different ways people tackle the problem.


On Wed, Nov 11, 2015 at 10:02 PM, Gareth Clapperton <gclapper...@live.com>
wrote:

> Hey Daves
>
> I too like the map idea (and using sets for roles for that matter). But
> sticking with collections, I might do something like this
>
> (defn upsert
>   "Updates or inserts v into coll"
>   [key-fn update-fn v coll]
>   (let [k(key-fn v)]
> (letfn [(step [v [x & xs]]
>   (lazy-seq
> (cond
>   (nil? x) (when v [v])
>   (and (some? v) (= (key-fn x) k)) (cons (update-fn x v)
> (step nil xs))
>   :default (consx
>  (step  v  xs)]
>   (step v coll
>
> (defn merge-roles [p1 {:keys [project_roles] :as p2}]
>   (update-in p1 [:project_roles] #(vec (clojure.set/union (set %) (set
> project_roles)
>
> (upsert :project_id merge-roles prj-role prj-roles)
>
> Gareth
>
>
> On Wednesday, November 11, 2015 at 4:25:51 PM UTC-5, Dave Tenny wrote:
>>
>> A colleague and I are debating various things clojure as we were
>> exploring alternative ways to solve a problem.
>>
>> Here's the description of the problem that a particular function is
>> trying to solve, and the first implementation of it.
>>
>> (defn update-roles
>>   "Given a vector of maps of the form {:project_id N :project_name S
>> :project_roles [...roles...]}
>>   if there is already a map for the indicated project id/name, add
>> new-role to it and returned
>>   a copy the updated input vector, otherwise return a vector with a new
>> map entry for the newly found
>>   project and initial role.  This function is basically aggregating
>> tuples from the database."
>>   [projects project-id project-name new-role]
>>   (let [updated? (atom nil)
>>
>> projects* (mapv (fn [m]
>>   (if (= (:project_id m) project-id)
>> (do (reset! updated? true)
>> (assoc m :project_roles (conj (:project_roles
>> m) new-role)))
>> m))
>> projects)]
>> (if @updated?
>>   projects*
>>   (conj projects {:project_id project-id :project_name project-name 
>> :project_roles
>> [new-role]}
>>
>>
>> ;; (update-roles [{:project_id 1 :project_name "O

Style, Efficiency, and updating nested structure

2015-11-11 Thread Dave Tenny
A colleague and I are debating various things clojure as we were exploring 
alternative ways to solve a problem.

Here's the description of the problem that a particular function is trying 
to solve, and the first implementation of it.

(defn update-roles 
  "Given a vector of maps of the form {:project_id N :project_name S 
:project_roles [...roles...]}
  if there is already a map for the indicated project id/name, add new-role 
to it and returned
  a copy the updated input vector, otherwise return a vector with a new map 
entry for the newly found
  project and initial role.  This function is basically aggregating tuples 
from the database."
  [projects project-id project-name new-role]
  (let [updated? (atom nil)

projects* (mapv (fn [m] 
  (if (= (:project_id m) project-id)
(do (reset! updated? true)
(assoc m :project_roles (conj (:project_roles 
m) new-role)))
m))
projects)]
(if @updated?
  projects*
  (conj projects {:project_id project-id :project_name project-name 
:project_roles 
[new-role]}


;; (update-roles [{:project_id 1 :project_name "One" :project_roles [:own]}] 
2 "Two" :edit)
;; => [{:project_id 1, :project_name "One", :project_roles [:own]} {:project_id 
2, :project_name "Two", :project_roles [:edit]}]
;; (update-roles [{:project_id 1 :project_name "One" :project_roles [:own]}] 
1 "Two" :edit)
;; => [{:project_id 1, :project_name "One", :project_roles [:own :edit]}]



Now here's another implementation:

(defn update-or-insert-project-role
  [prj-roles prj-role]
  (let [to-insert-prj-id (:project_id prj-role)
by-pid   (group-by :project_id prj-roles)]
(case (get by-pid to-insert-prj-id)
  nil (conj prj-roles prj-role)
  (->> (update-in by-pid [to-insert-prj-id 0 :project_roles] #(apply conj % 
(:project_roles prj-role)))
   (mapcat second)
   (into [])

;; (def prj-roles [{:project_id 1, :project_name "One", :project_roles [:own]} 
{:project_id 3 :project_name "Three" :project_roles [:edit]}])
;; (update-or-insert-project-role prj-roles {:project_id 2 :project_name "Two" 
:project_roles [:edit]})
;; => [{:project_id 1, :project_name "One", :project_roles [:own]} {:project_id 
3, :project_name "Three", :project_roles [:edit]} {:project_id 2, :project_name 
"Two", :project_roles [:edit]}]
;; (update-or-insert-project-role prj-roles {:project_id 1 :project_name "One" 
:project_roles [:edit]})
;; => [{:project_id 1, :project_name "One", :project_roles [:own :edit]} 
{:project_id 3, :project_name "Three", :project_roles [:edit]}]




The function is called in a loop to aggregate rows from a database, though 
it isn't an overriding concern, we're not going millions of records in this 
case.

The first thing my colleague and I disagreed on was the calling sequence, 
arguing over which is more readable.
The second thing was whether efficiency in this context is really 
important, or whether it's all moot in clojure.  

Finally, I'm sure there's a better way, probably with Zippers or something, 
but neither of us have used them. Suggestions for the stylistic and 
operational epitome of clojure expression on this routine are welcome!

Superficially, and probably incorrect in multiple ways, here is a poor 
attempt at breaking down efficiency in terms of search/traversal and memory 
allocations.  This was done by someone with no knowledge of clojure 
internals (including the library implementations of the called functions).

;; Comparing the two routines per function call, for existing project case 
(i.e. where roles are updated)
;;
;; Assuming each routine allocates new vector for new-role placement in 
existing project
;; and MapEntry for assoc of new vector on project_roles, so they aren't 
included in allocations 
;; below since both routines have to do it.
;;
;; Note that x-element map allocates storage for map and map-entries or 
clojure equivalent.
;; (and more expensive than an x-element vector, of course).
;;
;; n == length of input project list.
;; m == average length of input project list role vectors.
;; 
;; Object Allocations
;;   Function call:
;; update-roles: 
;;   1 atom
;;   1 O(n) vector for mapv 
;; update-or-insert-project-role: 
;;   1 3-entry map + 1 single-element vector for prj-role argument 
input.
;;   1 n-element map for group-by
;;   n vectors for group-by map values
;;   1 n-element map for update-in
;;   1 list/sequence for mapcat (+ n concat intermediaries?)
;;   1 vector for into
;;
;; If we discard the second 'into' and first 'mapv' allocations the 
update-or-insert-project-role routine allocates
;; 3 additional maps (two of which are O(n)), n additional vectors, and 1 
additional list/sequence.
;;   
;; Searches/traversals/copies
;;  update-roles: 
;;   O(n) - mapv
;;  update-or-insert-project-role: 
;;   O(n) - 

Re: is there a community "best practice" for including your co-workers libraries?

2015-11-02 Thread Dave Tenny
ok, that must be the part I missed.

On Mon, Nov 2, 2015 at 7:01 PM, Sean Corfield <s...@corfield.org> wrote:

> Dave Tenny wrote on Monday, November 2, 2015 at 3:59 PM:
>
> I'm slightly confused, is there some reason Clojars <http://clojars.org/> 
> doesn't
> work for sharing libraries in this context?
>
>
> Because it’s public and sharing your companies libraries with the world
> might be frowned upon…?
>
> Sean
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/myxUzM7TzYA/unsubscribe.
> To unsubscribe from this group and all its topics, 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: is there a community "best practice" for including your co-workers libraries?

2015-11-02 Thread Dave Tenny
I'm slightly confused, is there some reason Clojars  
doesn't 
work for sharing libraries in this context? 

-- 
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: 'seq' performance for 'empty?' compared to 'count'. And where's !=?

2015-10-02 Thread Dave Tenny
Re: where I got this from:

user> (doc empty?)
>
> -
>
> clojure.core/empty?
>
> ([coll])
>
>   Returns true if coll has no items - same as (not (seq coll)).
>
>   Please use the idiom (seq x) rather than (not (empty? x))
>
>
Note that 'empty?' just calls 'seq'.



On Thu, Oct 1, 2015 at 6:40 PM, Nathan Davis <
nda...@positronic-solutions.com> wrote:

> On Thursday, October 1, 2015 at 2:31:46 PM UTC-5, Dave Tenny wrote:
>>
>> So I understand that 'seq' is the idiomatic way to see if a
>> collection/sequence is empty.
>>
>>
> I'm not sure where you got this from.  I personally use empty? to check
> whether a collection is empty.  It is true that (not (empty c)) is not
> encouraged.  I believe the main rationale for this this is that (empty c)
> is (not (seq c)), so (not (empty c)) is (not (not (seq c)).
>
>
>> Logically I'm looking for an O(1) predicate with which I can determine if
>> a seq/collection is empty, and a well behaved
>> one that is idempotent and side effect free (for general performance
>> reasons).
>>
>
> I believe all the implementations of seq in Clojure core are O(1),
> although some (most?) allocate objects.  I'm not sure if it's explicitly
> spelled out anywhere, but I would consider it a bug it was anything other
> than O(1) (or perhaps O(log n) at most).
>
> In what ways is the current implementation of empty not well behaved and
> idempotent?
>
> With regards to side effects, if you can find a completely generic,
> side-effect-free way of determining whether a lazy sequence is empty
> without potentially realizing its head, please let the Clojure community
> know!
>
> I'm not saying having an explicit 'empty' method is a bad idea, but I'm
> not sure the current situation is as bad as you think.
>
> Nathan Davis
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/fUygeQMPqyI/unsubscribe.
> To unsubscribe from this group and all its topics, 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.


'seq' performance for 'empty?' compared to 'count'. And where's !=?

2015-10-01 Thread Dave Tenny
So I understand that 'seq' is the idiomatic way to see if a 
collection/sequence is empty.

Logically I'm looking for an O(1) predicate with which I can determine if a 
seq/collection is empty, and a well behaved
one that is idempotent and side effect free (for general performance 
reasons).

'seq'  leaves something to be desired here since it does heap allocations 
when called with various types of arguments.

I'll also freely confess that I dislike seq as an emptiness predicate, I 
like empty? and not-empty? types of things, even better,
I loved Common Lisp's treatment where NIL and empty lists have the same 
value in conditional situations
(i.e. if x is an empty list it is == nil and is false, unlike Clojure).  I 
guess what I'm saying here is that 'seq' as idiomatic clojure for
empty tests is distasteful.

In my own personal libraries I use a predicate to give the common lisp like 
semantics I desire, but it still calls clojure.core/empty?,
which still calls 'seq'.  So all I've done is make the test more expensive 
even if I find it more readable.

While looking at the Clojure 1.7 implementation of 'seq' today in RT.java, 
I happened across the implementation of 'count',
and it occurred to me that it was a much leaner and meaner test for empty 
sequences than 'seq'.  So here are some timings.

user> (doseq [thing [[] {} #{} (seq []) (into [] (range 0 1000)) (range 0 
1000)]]
(println "Time for 1M seq on" (type thing))
(time (dotimes [i 100] (seq thing
Time for 1M seq on clojure.lang.PersistentVector
"Elapsed time: 18.993869 msecs"
Time for 1M seq on clojure.lang.PersistentArrayMap
"Elapsed time: 14.461354 msecs"
Time for 1M seq on clojure.lang.PersistentHashSet
"Elapsed time: 23.044994 msecs"
Time for 1M seq on nil
"Elapsed time: 8.291876 msecs"
Time for 1M seq on clojure.lang.PersistentVector
"Elapsed time: 21.214759 msecs"
Time for 1M seq on clojure.lang.LongRange
"Elapsed time: 6.27834 msecs"

Note the time on PersistentVector, we may have an O(n) implemention of `seq`
which is undesirable for an emptiness predicate.  Larger inputs require 
more time for 'seq' to return.

Now compare the same timings with 'count', adding in a clojure-level 
emptyness test (which would
no doubt be faster in RT.java):

user> (doseq [thing [[] {} #{} (seq []) (into [] (range 0 1000)) (range 0 
1000)]]
(println "Time for 1M count on" (type thing))
(time (dotimes [i 100] (== (count thing) 0

Time for 1M count on clojure.lang.PersistentVector
"Elapsed time: 8.061005 msecs"
Time for 1M count on clojure.lang.PersistentArrayMap
"Elapsed time: 7.297715 msecs"
Time for 1M count on clojure.lang.PersistentHashSet
"Elapsed time: 10.165718 msecs"
Time for 1M count on nil
"Elapsed time: 4.190523 msecs"
Time for 1M count on clojure.lang.PersistentVector
"Elapsed time: 8.772564 msecs"
Time for 1M count on clojure.lang.LongRange
"Elapsed time: 27.166397 msecs"


Except for the LongRange input, `count` is much faster.

So I'm just bringing it up for discussion, wondering if we can get a faster 
clojure.core
implementation of `empty?`.

That said, there is one apples-to-apples problem in the above.

(seq x) returns nil if empty.  (== (count x) 0) returns true if nil is 
empty.

Clojure neophyte that I am, I can't understand where there is not a "!=" 
function for numbers.
Wrapping the above test in a 'not' gives:

user> (doseq [thing [[] {} #{} (seq []) (into [] (range 0 1000)) (range 0 
1000)]]
(println "Time for 1M count on" (type thing))
(time (dotimes [i 100] (not (== (count thing) 0)

Time for 1M count on clojure.lang.PersistentVector
"Elapsed time: 15.961422 msecs"
Time for 1M count on clojure.lang.PersistentArrayMap
"Elapsed time: 11.12519 msecs"
Time for 1M count on clojure.lang.PersistentHashSet
"Elapsed time: 12.899191 msecs"
Time for 1M count on nil
"Elapsed time: 7.119841 msecs"
Time for 1M count on clojure.lang.PersistentVector
"Elapsed time: 11.454936 msecs"
Time for 1M count on clojure.lang.LongRange
"Elapsed time: 28.544915 msecs"

The O(1) times double when wrapping the test in 'not'.

Perhaps some clojurian will tell me what I should use.

Btw, don't even thing about 'not=':

user> (doseq [thing [[] {} #{} (seq []) (into [] (range 0 1000)) (range 0 
1000)]]
(println "Time for 1M count on" (type thing))
(time (dotimes [i 100] (not= (count thing) 0
Time for 1M count on clojure.lang.PersistentVector
"Elapsed time: 44.768754 msecs"
Time for 1M count on clojure.lang.PersistentArrayMap
"Elapsed time: 40.158507 msecs"
Time for 1M count on clojure.lang.PersistentHashSet
"Elapsed time: 41.868068 msecs"
Time for 1M count on nil
"Elapsed time: 36.098277 msecs"
Time for 1M count on clojure.lang.PersistentVector
"Elapsed time: 42.149571 msecs"
Time for 1M count on clojure.lang.LongRange
"Elapsed time: 59.107886 msecs"

Well, that's not fair of course since '(not (==' and '(not (='  are two 
different things.
But then you'd expect '=' to 

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

2015-09-04 Thread Dave Tenny
I'm using components to encapsulate Langohr/RabbitMQ interactions in cases 
where Langohr auto-recovery wasn't happy with what was going on.

I make sure the Lifecycle methods are idempotent, built the component stack 
in the correct order.  

To make sure that I can deal with the exceptions that require restarting 
the component stack, I have some macros that wrap up exception handling, 
retries, and component stack restarts.

So

(with-rmq-publisher! [channel component-system]
  ... do my stuff ...)

The body of the macro ("... do my stuff ...") is turned into a function and 
and will be re-executed if the system is restarted, so you have to beware
of side effects or other things you may not want executed multiple times. 
 Not a problem for me, all I'm doing is entering the macro long enough
to get a channel and publish to it, or similar types of things.

The component-system is a wrap of the system-map call with some other data, 
in an atom, that will be mutated
if we do things like dynamically add subscribers to the system or call 
(restart! component-system).
There are some thread safety/locking concerns, since a connection failure 
is likely to be seen by callers
on multiple threads using the components, and I try to avoid race 
conditions on restarts (only one thread will do the restart until it 
succeeds, 
the unblock the others).

Hope this helps with strategy, even if the code is omitted.

The trick to me was not in restarting the component stack, but in managing 
the shared state across threads safely and making sure (with-stack-activity 
[system] )
code was prepared to re-execute on failures with new connections or other 
stack components.

In my case I also needed to add components to the stack dynamically.  Not 
often, but dynamcially, not at (system-map) call time.  That required some 
lock consideration,
and I'd have to call Lifecycle/start on the stack every time I added a 
component.  They methods have to be idempotent.

  

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


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

2015-09-04 Thread Dave Tenny
Caveat: my approach may have been all wrong.  It's the first time I tried
stuartsierra components.  Frankly I'd have been happier with some CLOS
objects and before and after methods, I'm still getting the hang of this
clojure stuff.

On Fri, Sep 4, 2015 at 7:57 AM, Dave Tenny <dave.te...@gmail.com> wrote:

> I'm using components to encapsulate Langohr/RabbitMQ interactions in cases
> where Langohr auto-recovery wasn't happy with what was going on.
>
> I make sure the Lifecycle methods are idempotent, built the component
> stack in the correct order.
>
> To make sure that I can deal with the exceptions that require restarting
> the component stack, I have some macros that wrap up exception handling,
> retries, and component stack restarts.
>
> So
>
> (with-rmq-publisher! [channel component-system]
>   ... do my stuff ...)
>
> The body of the macro ("... do my stuff ...") is turned into a function
> and and will be re-executed if the system is restarted, so you have to
> beware
> of side effects or other things you may not want executed multiple times.
> Not a problem for me, all I'm doing is entering the macro long enough
> to get a channel and publish to it, or similar types of things.
>
> The component-system is a wrap of the system-map call with some other
> data, in an atom, that will be mutated
> if we do things like dynamically add subscribers to the system or call
> (restart! component-system).
> There are some thread safety/locking concerns, since a connection failure
> is likely to be seen by callers
> on multiple threads using the components, and I try to avoid race
> conditions on restarts (only one thread will do the restart until it
> succeeds,
> the unblock the others).
>
> Hope this helps with strategy, even if the code is omitted.
>
> The trick to me was not in restarting the component stack, but in managing
> the shared state across threads safely and making sure (with-stack-activity
> [system] )
> code was prepared to re-execute on failures with new connections or other
> stack components.
>
> In my case I also needed to add components to the stack dynamically.  Not
> often, but dynamcially, not at (system-map) call time.  That required some
> lock consideration,
> and I'd have to call Lifecycle/start on the stack every time I added a
> component.  They methods have to be idempotent.
>
>
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/JCvKLIsfSgA/unsubscribe.
> To unsubscribe from this group and all its topics, 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: How can find something inside heavily nested data structure ?

2015-08-24 Thread Dave Tenny
Specter looks nice.  I didn't see any examples in the readme or tests for 
working with more deeply nested data structures such as those discussed in 
this thread, any pointers?

On Sunday, August 23, 2015 at 10:22:25 PM UTC-4, Brian Marick wrote:



 Andy- wrote: 
  I have yet to evaluate it myself but this might do help you: 
  
  https://github.com/nathanmarz/specter 
  

 Specter is great. 


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


:arglists metadata on defmulti/defmethod forms

2015-08-23 Thread Dave Tenny
defmulti+detmethod doesn't seem to maintain any :arglists metadata with the 
Var filled by defmulti.  

How can I look up arglist information for multimethods like I can for 
regular function vars?


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


Java constructor question

2015-08-23 Thread Dave Tenny
Is there a way to parameterize a bit of code that invokes a constructor 
without calling the java.lang.reflect.Constructor class?

e.g.

(defn make-it [class]
  (new class abc)) ; won't work

(make-it IllegalArgumentException)  

I was trying to parameterize the class of exception thrown in a bit of code 
in my case,
but it appears the compiler wants a Class name and nothing else in java 
interop constructor positiosn.


-- 
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: Rabid wild animals in my clojure argument lists, code gets infected.

2015-08-23 Thread Dave Tenny
Note Colin, if I had declared foo differenlty, e.g. (defn foo [a b {:keys
[c d]}), that would be slightly different since it requires a map as third
argument.  But that is not the case with
(defn foo [a b  {:keys [c d]}]).  It may be using maps under the hood, but
none of my formal parameters are necessarily intended to be bound to maps
in this case, and I'm looking for a very fixed set of keywords in the
function call.



On Sun, Aug 23, 2015 at 10:17 AM, Dave Tenny dave.te...@gmail.com wrote:

 The point of my colorful title and judgmental post is that in the example,
 passing :e for the declared parameters as declared is a pointless operation
 at best, and in most practical situations it is also an erroneous
 operation.

 The language designers have (arguably for the good) chosen to complain
 about various actual argument mismatches vs. formal parameters.

 If I tried to call foo with only one argument I'd get an error about
 missing arguments (or more generally, arity).
 Similarly, in this case, calling foo with :e should complain about
 superfluous arguments, all assuming that foo is declared as intended.
 Without an :as option on the destructuring, there is nothing that can be
 done to meaningfully process a keyword to the function named :e.

 I am proposing the language should do better in this case. If not now,
 perhaps 2.0.


 On Sat, Aug 22, 2015 at 9:06 PM, Colin Yates colin.ya...@gmail.com
 wrote:

 Hi Dave, it _isn't_ an Illegal argument though :-), your destructuring
 is simply ignoring that parameter.

 However, I get the pain and solutions might be (in order of 'heavyness'):
  - http://blog.fogus.me/2009/12/21/clojures-pre-and-post/
  - https://github.com/Prismatic/schema
  - http://typedclojure.org/

 HTH

 Dave Tenny writes:

  I sure wish Clojure would generate IllegalArgumentException in the
  following sample case:
 
  (defn foo [a b  {:keys [c d]}] 1)
  (foo 1 2 :e 5) ; blithely ignores :e 5
 
  I understand that Clojure's destructuring things are very nice, and more
  powerful than Common Lisp's, and I like
  that when I need it.
 
  However I can't tell you how many times I've been bitten by this. Some
  simple typo or other other parameter name error on keyword arguments
  with untended and way-too-long-to-debug consequences.
 
  In my mind, on this subject, Common Lisp lambda lists got this right and
  Clojure gets a poor grade.
  Something about being doomed to repeat history.  In Common Lisp, if you
  really wanted to allow other (arbitrary) keywords you'd
  just use allow-other-keys.
 
  Maybe clojure should only allow the above case to go
 un-complained-about if
  :as was specified for the map.
 
  If there's some automatic enforcement I'm missing that comes with 'defn'
  please let me know, I'm still learning the language.
 
  I've thought more that once about making a common lisp DEFUN statement
 that
  maps to DEFN but implements
  lambda list semantics (including 'supplied-p' parameters).  I've just
 been
  too lazy to do it.
 
  It would also likely perform poorly after injecting the additional
  checks/rearrangements into the function on top of what Clojure has
 already
  done,
  so I suppose it would have to be taken a step further so that it didn't
  generate DEFN expressions at all but was implemented at DEFN's level as
  a seperately named form.
 
  Tips welcome.  Just thinking aloud.
 
  - Dave

 --
 Sent with my mu4e

 --
 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 a topic in the
 Google Groups Clojure group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/clojure/3-CevvzQg1s/unsubscribe.
 To unsubscribe from this group and all its topics, 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: Rabid wild animals in my clojure argument lists, code gets infected.

2015-08-23 Thread Dave Tenny
The point of my colorful title and judgmental post is that in the example,
passing :e for the declared parameters as declared is a pointless operation
at best, and in most practical situations it is also an erroneous
operation.

The language designers have (arguably for the good) chosen to complain
about various actual argument mismatches vs. formal parameters.

If I tried to call foo with only one argument I'd get an error about
missing arguments (or more generally, arity).
Similarly, in this case, calling foo with :e should complain about
superfluous arguments, all assuming that foo is declared as intended.
Without an :as option on the destructuring, there is nothing that can be
done to meaningfully process a keyword to the function named :e.

I am proposing the language should do better in this case. If not now,
perhaps 2.0.


On Sat, Aug 22, 2015 at 9:06 PM, Colin Yates colin.ya...@gmail.com wrote:

 Hi Dave, it _isn't_ an Illegal argument though :-), your destructuring
 is simply ignoring that parameter.

 However, I get the pain and solutions might be (in order of 'heavyness'):
  - http://blog.fogus.me/2009/12/21/clojures-pre-and-post/
  - https://github.com/Prismatic/schema
  - http://typedclojure.org/

 HTH

 Dave Tenny writes:

  I sure wish Clojure would generate IllegalArgumentException in the
  following sample case:
 
  (defn foo [a b  {:keys [c d]}] 1)
  (foo 1 2 :e 5) ; blithely ignores :e 5
 
  I understand that Clojure's destructuring things are very nice, and more
  powerful than Common Lisp's, and I like
  that when I need it.
 
  However I can't tell you how many times I've been bitten by this. Some
  simple typo or other other parameter name error on keyword arguments
  with untended and way-too-long-to-debug consequences.
 
  In my mind, on this subject, Common Lisp lambda lists got this right and
  Clojure gets a poor grade.
  Something about being doomed to repeat history.  In Common Lisp, if you
  really wanted to allow other (arbitrary) keywords you'd
  just use allow-other-keys.
 
  Maybe clojure should only allow the above case to go un-complained-about
 if
  :as was specified for the map.
 
  If there's some automatic enforcement I'm missing that comes with 'defn'
  please let me know, I'm still learning the language.
 
  I've thought more that once about making a common lisp DEFUN statement
 that
  maps to DEFN but implements
  lambda list semantics (including 'supplied-p' parameters).  I've just
 been
  too lazy to do it.
 
  It would also likely perform poorly after injecting the additional
  checks/rearrangements into the function on top of what Clojure has
 already
  done,
  so I suppose it would have to be taken a step further so that it didn't
  generate DEFN expressions at all but was implemented at DEFN's level as
  a seperately named form.
 
  Tips welcome.  Just thinking aloud.
 
  - Dave

 --
 Sent with my mu4e

 --
 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 a topic in the
 Google Groups Clojure group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/clojure/3-CevvzQg1s/unsubscribe.
 To unsubscribe from this group and all its topics, 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: Rabid wild animals in my clojure argument lists, code gets infected.

2015-08-23 Thread Dave Tenny
Timothy, I think maps vs keywords is a matter of preference.  Certainly
there are cases where I use maps of options instead of keywords, but it
depends on what I'm doing.   Lisp and keywords go way back, and I like
keywords when I'm using lisp packages/namespaces as the equivalent of an
interactive query language.

Even for the case of pure options passed as a map, you'll still potentially
have cases where you might like to validate that only *expected* keywords
were used. Whether a map as argument or a :as option to destructuring. And
it's all well and good to let the user of those maps write code to enforce
that.

However in the traditional use of keywords naming formal parameters there's
a long Common Lisp (at least) history of validating these bindings,
and there's also compile time capabilities too, though perhaps less
effectively in Clojure than CL.  Clojure has provided these keyword
capabilities,
I just object to this one hole because it has zero up side that I can see,
and substantial downside to writing correct programs.

On Sun, Aug 23, 2015 at 10:12 AM, Timothy Baldridge tbaldri...@gmail.com
wrote:

 It's generally considered better practice to pass maps to a function
 instead of keyword arguments. This also has the nice side-effect of making
 it easier to call programmatically  from other functions. For example:

 (my-func 1 2 (assoc default-opts :c 42)) is way cleaner than

 (apply my-func 1 2 (mapcat identity (assoc default-opts :c 42)))

 So don't do keyword argument, it rarely works out well. Instead accept a
 map of options and validate it with asserts, ignoring extra data. A map
 is a map, it shouldn't matter if it contains extra data.

 Timothy

 On Sat, Aug 22, 2015 at 7:21 PM, James Reeves ja...@booleanknot.com
 wrote:

 https://github.com/roomkey/annotate is another possibility

 - James

 On 23 August 2015 at 02:06, Colin Yates colin.ya...@gmail.com wrote:

 Hi Dave, it _isn't_ an Illegal argument though :-), your destructuring
 is simply ignoring that parameter.

 However, I get the pain and solutions might be (in order of 'heavyness'):
  - http://blog.fogus.me/2009/12/21/clojures-pre-and-post/
  - https://github.com/Prismatic/schema
  - http://typedclojure.org/

 HTH

 Dave Tenny writes:

  I sure wish Clojure would generate IllegalArgumentException in the
  following sample case:
 
  (defn foo [a b  {:keys [c d]}] 1)
  (foo 1 2 :e 5) ; blithely ignores :e 5
 
  I understand that Clojure's destructuring things are very nice, and
 more
  powerful than Common Lisp's, and I like
  that when I need it.
 
  However I can't tell you how many times I've been bitten by this. Some
  simple typo or other other parameter name error on keyword arguments
  with untended and way-too-long-to-debug consequences.
 
  In my mind, on this subject, Common Lisp lambda lists got this right
 and
  Clojure gets a poor grade.
  Something about being doomed to repeat history.  In Common Lisp, if you
  really wanted to allow other (arbitrary) keywords you'd
  just use allow-other-keys.
 
  Maybe clojure should only allow the above case to go
 un-complained-about if
  :as was specified for the map.
 
  If there's some automatic enforcement I'm missing that comes with
 'defn'
  please let me know, I'm still learning the language.
 
  I've thought more that once about making a common lisp DEFUN statement
 that
  maps to DEFN but implements
  lambda list semantics (including 'supplied-p' parameters).  I've just
 been
  too lazy to do it.
 
  It would also likely perform poorly after injecting the additional
  checks/rearrangements into the function on top of what Clojure has
 already
  done,
  so I suppose it would have to be taken a step further so that it didn't
  generate DEFN expressions at all but was implemented at DEFN's level as
  a seperately named form.
 
  Tips welcome.  Just thinking aloud.
 
  - Dave

 --
 Sent with my mu4e

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

Re: decoding clojure generated class names

2015-08-23 Thread Dave Tenny
Thanks Alex, clojure.lang.Compiler/demunge is just what I wanted.

On Sat, Aug 22, 2015 at 7:28 PM, Alex Miller a...@puredanger.com wrote:

 There is a demunge function in clojure.lang.Compiler. It's not foolproof
 as the munging is not unambiguously reversible.

 --
 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 a topic in the
 Google Groups Clojure group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/clojure/5-l7bxFSOxk/unsubscribe.
 To unsubscribe from this group and all its topics, 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.


decoding clojure generated class names

2015-08-22 Thread Dave Tenny
I wanted to write a function like this:

(defn fn-name-info
  Given a function, try to deduce the function name and clojure namespace 
by looking 
  at the function's java class name and decoding stuff.  Return a vector of 
name, namespace strings, 
  or nil if we can't find anything.
  
  For example, if in jdt.core we do (defn foo []), the resulting value foo 
is a thing whose class is
  jdt.core$foo, for which we can return [\jdt.core\ \foo\].
  
  However, for anonymous functions like (fn []) typed into the REPL, 
  you're going to get something like [\jdt.core\ \eval3676$fn__3677\]
  [f]
  )

Surely someone out there has a bit of code that knows how to decode 
classnames accounting for
many of the weird edge cases, question marks (e.g. QMARK), and so on?

Can anybody help me out?

FYI, the next step I had planned for this was for me to reach take that fn 
information, look for the var that defines it, and yank out some metadata, 
when all I have is the function pointer, not the var.

Tips appreciated.

Yes, I know it's probably a bad idea for a couple of reasons, but feel free 
to point them out.


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


Rabid wild animals in my clojure argument lists, code gets infected.

2015-08-22 Thread Dave Tenny
I sure wish Clojure would generate IllegalArgumentException in the 
following sample case:

(defn foo [a b  {:keys [c d]}] 1)
(foo 1 2 :e 5) ; blithely ignores :e 5

I understand that Clojure's destructuring things are very nice, and more 
powerful than Common Lisp's, and I like
that when I need it.

However I can't tell you how many times I've been bitten by this. Some 
simple typo or other other parameter name error on keyword arguments
with untended and way-too-long-to-debug consequences.

In my mind, on this subject, Common Lisp lambda lists got this right and 
Clojure gets a poor grade.
Something about being doomed to repeat history.  In Common Lisp, if you 
really wanted to allow other (arbitrary) keywords you'd
just use allow-other-keys.  

Maybe clojure should only allow the above case to go un-complained-about if 
:as was specified for the map.

If there's some automatic enforcement I'm missing that comes with 'defn' 
please let me know, I'm still learning the language.

I've thought more that once about making a common lisp DEFUN statement that 
maps to DEFN but implements
lambda list semantics (including 'supplied-p' parameters).  I've just been 
too lazy to do it.  

It would also likely perform poorly after injecting the additional 
checks/rearrangements into the function on top of what Clojure has already 
done,
so I suppose it would have to be taken a step further so that it didn't 
generate DEFN expressions at all but was implemented at DEFN's level as 
a seperately named form.

Tips welcome.  Just thinking aloud.

- Dave

-- 
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: How can find something inside heavily nested data structure ?

2015-08-20 Thread Dave Tenny
I have found the core 'get-in' function to be useful for extracting data 
from big trees of clojure data structures, perhaps
that will help.

I'm still in search of tools that let me get a good sense of *what* to 
navigate when looking at such trees
of data structures from API's  and/or data sources I'm unfamiliar with.  I 
find that to be pretty painful, not least
because emacs (and maybe the REPL) get seriously compute wedged printing 
large data structures.

An example of this is Amazonica, which will flatten ALL the data in a 
hierarchy of java data structures from
the AWS SDK into one gigantic tree.  It's a nifty tool, but the resulting 
flood of data with one careless query or printed tree fragment has been 
known to knock out my emacs session for minutes at a time.

I wrote a tool to analyze unique key paths in large trees so that I might 
know, for a given tree, what would be useful to provide as the access path 
to 'get-in'.
However I'm not happy enough with my tool to post it here, it needs some 
kind of syntax for describing sequences in the tree (since you don't want 
to see every unique key
used to access a sequence of 10,000 things).


On Wednesday, August 19, 2015 at 10:18:06 AM UTC-4, Hussein B. wrote:

 Hi,

 I have transformed JSON response into the equivalent data structure using 
 Cheshire library.

 The result is a huge nested data structure , mostly vectors and maps. It 
 is actually a tree.

 How to find a property that is nested deep inside the tree ? For example 
 I'm search for the node that has the value zyx for property uuid.

 What I'm supposed to use? Something like zipper or walk? or something 
 simpler is available?

 Thanks for help.


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


apply, mapply, recur, looking for insights

2015-08-13 Thread Dave Tenny
These inconsistencies are bugging me, I just wondered if I was missing some 
standard language thing about argument passing or destructuring, so I'm 
looking for comments.

At issue (for me), keyword arguments and maps that bundle them.

user (defn foo [a b  {:keys [c d]}]
[a b c d])
#'user/foo
user (defn bar [a b  {:keys [c d] :as options}]
(println (apply foo a b options)))
#'user/bar
user (bar 1 2)
[1 2 nil nil]
nil
;; Okay so far

user (bar 1 2 :c 3)
IllegalArgumentException No value supplied for key: [:c 3] 
 clojure.lang.PersistentHashMap.create (PersistentHashMap.java:77)

;; I'm wishing the above was smarter, but okay, so I use 'mapply', which 
seems to me it ought to be in clojure.core but isn't.

user (defn mapply
  [f  args]
  (apply f (apply concat (butlast args) (last args
#'user/mapply
user (defn bar2 [a b  {:keys [c d] :as options}]
(println (mapply foo a b options)))
#'user/bar2
user (bar2 1 2 :c 3)
[1 2 3 nil]
nil

;; Okay, that works nicely


So maybe this is all fine, though if there's some standard way of doing 
this using things shipped with clojure please let me know.

However then 'recur' bucks the trend, which adds to confusion.

user (defn baz [a b  {:keys [c d] :as options}]
(if ( a 0)
  (recur (- a 1) b options)
  [a b c d]))
#'user/baz
user (baz 2 3 :c 4)
[0 3 4 nil]

So recur does this arguably very useful thing, but apply does not (and 
probably with good reason, otherwise how would we pass maps as regular 
arguments...)

I guess what I'm seeking is the canonical clojure approach to dealing with 
keyword arguments and maps in call sites, and I find
the apply/recur difference confusing, and the lack of 'mapply' an oversight.

Thoughts?  Comments?  Please educate on what I'm missing, thanks.

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


com.stuartsierra.component dynamic component addition/removal question

2015-08-11 Thread Dave Tenny
I want to add components to a started system, but I'm unsure of a 
component-idiomatic way to do that.

I don't want to restart the whole component stack.  I'm guessing assoc'ing 
a new component to the system-map result isn't a good idea (though I've 
read words that sounded like it was a fine thing to do), but then I'd have 
a component that hasn't been started residing with other components that 
have been started.

I though of adding a static component called akin to a pooling component, 
which I would then modify directly in response to my needs, but then I'd 
have a mutable component and that isn't particularly desirable either.

For purposes of discussion let's say this is what I want:

(component/system-map
  {:connection (make-connection)
   :subscriber-1 (component/using (make-subscriber) [:connection])
   ... more subscribers after starting the system ...
  }
)

It isn't a nice prospect to declare all my subscribers at system-map 
declaration time or (start) lifecycle time,
I want my system to respond like a service and add new instances of what 
are essentially components.

So I either need to graft more components to the resulting system-map, or 
make a make a system map entity that is mutable and tracks the pool of 
subscribers.
Under this model I'd have 

(component/system-map
  {:connection (make-connection)
   :subscriber-pool (component/using (make-subscriber-pool) [:connection])
  })

Then I'd basically have functions to mutate (:subscriber-pool system) by 
adding/removing subscribers

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.


Re: com.stuartsierra.component dynamic component addition/removal question

2015-08-11 Thread Dave Tenny
Or maybe I just do

(start (assoc system :new-subscriber (component/using (make-subscriber) 
[:connection])))
and ensure idempotent start capabilities across all components that will 
not attempt restarts.

?  

Just looking for the idiomatic component way of doing this.

On Tuesday, August 11, 2015 at 11:49:10 AM UTC-4, Dave Tenny wrote:

 I want to add components to a started system, but I'm unsure of a 
 component-idiomatic way to do that.

 I don't want to restart the whole component stack.  I'm guessing assoc'ing 
 a new component to the system-map result isn't a good idea (though I've 
 read words that sounded like it was a fine thing to do), but then I'd have 
 a component that hasn't been started residing with other components that 
 have been started.

 I though of adding a static component called akin to a pooling component, 
 which I would then modify directly in response to my needs, but then I'd 
 have a mutable component and that isn't particularly desirable either.

 For purposes of discussion let's say this is what I want:

 (component/system-map
   {:connection (make-connection)
:subscriber-1 (component/using (make-subscriber) [:connection])
... more subscribers after starting the system ...
   }
 )

 It isn't a nice prospect to declare all my subscribers at system-map 
 declaration time or (start) lifecycle time,
 I want my system to respond like a service and add new instances of what 
 are essentially components.

 So I either need to graft more components to the resulting system-map, or 
 make a make a system map entity that is mutable and tracks the pool of 
 subscribers.
 Under this model I'd have 

 (component/system-map
   {:connection (make-connection)
:subscriber-pool (component/using (make-subscriber-pool) [:connection])
   })

 Then I'd basically have functions to mutate (:subscriber-pool system) by 
 adding/removing subscribers

 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.


[clojure-rabbitmq] autorecovery failure on queue status operation

2015-07-24 Thread Dave Tenny
I have a number of rabbitmq clients, most of which fail over well enough, 
but one client is experiencing apparent thread death on a queue status 
operation when the connection times out on heartbeat.
I wondered if anybody had any clues here.  Note the 
langohr.queue$status.invoke()

Exception in thread async-dispatch-3 java.lang.Error: java.io.IOException
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1151)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException
at com.rabbitmq.client.impl.AMQChannel.wrap(AMQChannel.java:106)
at com.rabbitmq.client.impl.AMQChannel.wrap(AMQChannel.java:102)
at com.rabbitmq.client.impl.AMQChannel.exnWrappingRpc(AMQChannel.java:124)
at com.rabbitmq.client.impl.ChannelN.queueDeclarePassive(ChannelN.java:873)
at 
com.rabbitmq.client.impl.recovery.AutorecoveringChannel.queueDeclarePassive(AutorecoveringChannel.java:287)
at langohr.queue$status.invoke(queue.clj:130)
at de.data.messaging.scheduler$fill_jobs_BANG_.invoke(scheduler.clj:115)
at 
de.data.messaging.scheduler$go_release_jobs_BANG_$fn__1064$state_machine__11049__auto1065$fn__1067.invoke(scheduler.clj:129)
at 
de.data.messaging.scheduler$go_release_jobs_BANG_$fn__1064$state_machine__11049__auto1065.invoke(scheduler.clj:129)
at 
clojure.core.async.impl.ioc_macros$run_state_machine.invoke(ioc_macros.clj:940)
at 
clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invoke(ioc_macros.clj:944)
at 
clojure.core.async.impl.ioc_macros$take_BANG_$fn__11065.invoke(ioc_macros.clj:953)
at 
clojure.core.async.impl.channels.ManyToManyChannel$fn__7516.invoke(channels.clj:102)
at clojure.lang.AFn.run(AFn.java:22)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
... 2 more
Caused by: com.rabbitmq.client.ShutdownSignalException: connection error
at com.rabbitmq.utility.ValueOrException.getValue(ValueOrException.java:67)
at 
com.rabbitmq.utility.BlockingValueOrException.uninterruptibleGetValue(BlockingValueOrException.java:33)
at 
com.rabbitmq.client.impl.AMQChannel$BlockingRpcContinuation.getReply(AMQChannel.java:348)
at com.rabbitmq.client.impl.AMQChannel.privateRpc(AMQChannel.java:221)
at com.rabbitmq.client.impl.AMQChannel.exnWrappingRpc(AMQChannel.java:118)
... 14 more
Caused by: com.rabbitmq.client.MissedHeartbeatException: Heartbeat missing 
with heartbeat = 60 seconds
at 
com.rabbitmq.client.impl.AMQConnection.handleSocketTimeout(AMQConnection.java:597)
at com.rabbitmq.client.impl.AMQConnection.access$600(AMQConnection.java:65)
at 
com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:560)
... 1 more

-- 
You received this message because you are subscribed to the Google Groups 
clojure-rabbitmq group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure-rabbitmq+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Project Better Clojure/Android integration

2015-07-22 Thread Dave Sann
Talk to the people on this forum 
https://groups.google.com/forum/#!forum/clojure-android

 and see how you go. I am sure that they would welcome your participation. 

There was an talk at euroclojure by Alexander Yakushev: 
https://www.youtube.com/watch?v=mVXTcAEKgF8

Dave


On Thursday, 23 July 2015 14:33:15 UTC+10, Devang Shah wrote:

 I know, it's over. Can I do it as a project outside of the GSoC?

 I believe it should not be a problem. Would it be?

 On Wednesday, July 22, 2015 at 9:14:30 PM UTC-7, Di Xu wrote:

 I believe student application for GSoC 2015 is already closed at March, 
 you can only try it next year.


 2015-07-23 11:12 GMT+08:00 Devang Shah devang...@gmail.com:

 Can anyone please help?


 On Saturday, July 18, 2015 at 8:33:58 PM UTC-7, Devang Shah wrote:

 Hello

 I am a master's student and would like to contribute to the 
 clojure/android platform. I found this project 
 http://dev.clojure.org/display/community/Project+Ideas#ProjectIdeas-BetterClojureAndroidintegration
  
 on the project ideas site for GSoC 2015. I was hoping to submit the 
 project 
 proposal, however could not submit the proposal. I was wondering, if I 
 still take up the project, will anyone be able to mentor me (very little 
 time, by answering my questions on google groups). I checked the GSoC 2015 
 website and this is not something that's done by any student for GSoC 15.

 I also would like to take this project as my master's project, if 
 that's OK to do so.

 I know Clojure (decent), Android(pretty good), Leiningen(used it for 
 Clojure programming) and Gradle (beginner).

 Can someone please help me getting started and also comment on this?

 Thank you.
 Devang

  -- 
 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: Clojars Private/Commercial Repos

2015-06-30 Thread Dave Dixon
+1. Neither S3 or Archiva have worked out well for us long term.

On Monday, June 29, 2015 at 6:50:44 PM UTC-7, Daniel Compton wrote:

 Hi folks

 I wondered if one possible solution for ensuring Clojars long-term 
 viability and maintenance would be to use it to host private repositories 
 for paying users as well? For many people, the thought of setting up and 
 maintaining Nexus or Archiva isn't an appealing one. I'm aware of the S3 
 wagon, and perhaps that's what people use if they don't want Nexus.

 I'd be interested to hear what other people are doing, and whether Clojars 
 would be a good middle ground between simplicity and functionality. Many 
 Clojure users already have Clojars accounts and will have setup Lein to 
 deploy here already. Additionally, many people would support Clojars for 
 the goodwill factor.

 On the other hand I'm aware this would require more development effort, 
 there may not be much demand for this, and the infrastructure costs may not 
 be large enough that it's worth going down this route.

 Just a thought, 

 Daniel.
 -- 
 --
 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: Clarity Keyboard by SwiftKey - Written in Clojure

2015-05-08 Thread Dave Sann
Very good news for clojure-android.

Keen to hear more.

Dave


On Friday, 8 May 2015 21:18:50 UTC+10, Adam Clements wrote:

 Hi all, 

 Just thought you might be interested to know that last week we (SwiftKey) 
 released an Android app, written from the ground up in Clojure, which as of 
 this morning has had 65k downloads. It's a keyboard we're using to test UI 
 ideas which didn't fit well with the existing app. We also took the 
 opportunity to try out a totally different tech stack, central to which are 
 Clojure and core.async.

 There's a tech blog on the subject at my personal blog 
 http://adamclements.github.io/articles/clarity-keyboard-uses-clojure/ which 
 is reposted on SwiftKey's tech blog 
 http://swiftkey.com/en/blog/what-makes-clarity-keyboard-tick-clojure/ and 
 you can download the app and try it out from Google Play 
 https://play.google.com/store/apps/details?id=com.swiftkey.clarity.keyboardreferrer=utm_source%3Dclojurelist%26utm_medium%3Dmailinglist

 Many thanks go to everyone who's worked on clojure and clojure-android for 
 making this possible, it's been a dream to develop! I hope this goes to 
 show that it's perfectly reasonable and possible to develop significant, 
 responsive mobile applications in pure Clojure.

 I'd be interested to know your thoughts and comments, and if you're 
 interested we are currently hiring here at SwiftKey, both for this project 
 and in general.

 Thanks,
 Adam Clements



-- 
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: Too many words written on referential transparency in Clojure and Haskell

2015-04-22 Thread Dave Sann
yes - ok - I agree with that.

I don't see this as a problem with the definition of equality.

D


On Thursday, 23 April 2015 00:40:20 UTC+10, Hannes Steffenhagen wrote:


 This. x = y = f(x) = f(y) obviously doesn't hold for arbitrary functions 
 and arbitrary notions of equality (e.g. all sets that contain the same 
 elements are equal, but the structures used to implement 'equal' sets need 
 not be equal themselves). So if you then introduce a function that derives 
 its result from the internal structure of the set - such as seq does - then 
 you obviously break that property for your notion of 'set equality'. This 
 doesn't mean the function isn't pure. It means your assumptions are wrong. 
 If you want to guarantee a specific ordering then you have to use 
 containers and/or algorithms that do actually guarantee a specific ordering.

 On Wednesday, April 22, 2015 at 9:53:47 AM UTC-4, Andy Fingerhut wrote:

 Dave, you say seq on a set cannot be pure unless you were to provide an 
 argument to explicitly specify which order the items should be in.

 I think I would instead say: seq *is* a pure function, even though it 
 violates the property of x equals y implies f(x) equals f(y).  There is 
 nothing impure about the definition of seq on sets.  I would say that it is 
 the way equals is defined on hash sets, intentionally ignoring internal 
 implementation details that are visible to seq, that leads to the violation 
 of that property.

 I have updated my article with a Conclusion section since yesterday.  I 
 have copied it below for those that have already read the article and want 
 to see only the new stuff:

 In hindsight after writing this, it now seems clear to me that if one
 wants to maintain the property x is equal to y implies f(x) is equalThis.
 to f(y) for all functions f, then it is pretty important to be clear
 on what equal means.

 As a silly example, if one gets to define their own equals for lists,
 and you decide to define lists as equal if they contain the same
 number of items, e.g. the list (1 2 3) is equal to the list (4 5 6)
 because they both have 3 items, then you are easily going to violate
 the property.

 Example 3 highlights this point: one can create implementations of
 data structures using only pure functions, and a 'reasonable'
 definition of equality, where the property can be violated.  The root
 of this issue is: sometimes reasonable definitions of equality regard
 two values as equal, intentionally ignoring internal implementation
 details of the data structure, but those differences ignored by equal
 can be made observable by other functions you implement on the data
 structure (like `seq` / `toList`).

 Andy


 On Wed, Apr 22, 2015 at 1:22 AM, Dave Sann dave...@gmail.com wrote:

 x is equal to y to imply f(x) is equal to f(y) - can only be true 
 where a function is really based only on its arguments. I hadn't considered 
 this before - while it seems simple, it is also a bit subtle. 

 for example: seq on a set cannot be pure unless you were to provide an 
 argument to explicitly specify which order the items should be in. If you 
 do not do this, the order is defined either by some random interaction of 
 the of the data and function implementations - that you thought was 
 irrelevant - or has to be literally picked at random by the implementation. 
 The former of these will appear to be pure until you hit the special cases.

 I speculate that only functions that retain or reduce the information 
 content of their inputs can be pure. So if you rearrange or filter or map 
 they can be pure. But if you *implicitly* add new information - as (seq 
 set) does - then they cannot be.

 Dave

 On Wednesday, 22 April 2015 15:28:30 UTC+10, Andy Fingerhut wrote:

 One thing I was surprised by in my investigation was the lengths that 
 some people are willing to go to in order to avoid such things.

 Some people seem to *really* want the property x is equal to y to 
 imply f(x) is equal to f(y) for all functions, without exception, and 
 consider it a bug if a single function violates that property.

 I'm personally on the side of violating it if there is no good way to 
 keep it true for a particular function, preferably with documentation if 
 you are aware that you are not preserving it.

 Andy

 On Tue, Apr 21, 2015 at 8:32 PM, Dave Sann dave...@gmail.com wrote:

 Just to expand on this slightly - seq applied to a set must introduce 
 an order that is not present in the set. This order in principle comes 
 from 
 nowhere in the data. But it does in practice come from some arbitrary 
 decisions in the implementation.  Maybe this was andy's point.


 On Wednesday, 22 April 2015 13:18:43 UTC+10, Dave Sann wrote:

 Agree it's an interesting writeup.

 I think that the behaviour of seq should be entirely expected though. 
 Sets have no ordering (logically) so turning them into an ordered 
 sequence 
 should be considered to be an entirely arbitrary operation (unless

Re: Too many words written on referential transparency in Clojure and Haskell

2015-04-22 Thread Dave Sann
x is equal to y to imply f(x) is equal to f(y) - can only be true where 
a function is really based only on its arguments. I hadn't considered this 
before - while it seems simple, it is also a bit subtle. 

for example: seq on a set cannot be pure unless you were to provide an 
argument to explicitly specify which order the items should be in. If you 
do not do this, the order is defined either by some random interaction of 
the of the data and function implementations - that you thought was 
irrelevant - or has to be literally picked at random by the implementation. 
The former of these will appear to be pure until you hit the special cases.

I speculate that only functions that retain or reduce the information 
content of their inputs can be pure. So if you rearrange or filter or map 
they can be pure. But if you *implicitly* add new information - as (seq 
set) does - then they cannot be.

Dave

On Wednesday, 22 April 2015 15:28:30 UTC+10, Andy Fingerhut wrote:

 One thing I was surprised by in my investigation was the lengths that some 
 people are willing to go to in order to avoid such things.

 Some people seem to *really* want the property x is equal to y to imply 
 f(x) is equal to f(y) for all functions, without exception, and consider 
 it a bug if a single function violates that property.

 I'm personally on the side of violating it if there is no good way to keep 
 it true for a particular function, preferably with documentation if you are 
 aware that you are not preserving it.

 Andy

 On Tue, Apr 21, 2015 at 8:32 PM, Dave Sann dave...@gmail.com 
 javascript: wrote:

 Just to expand on this slightly - seq applied to a set must introduce an 
 order that is not present in the set. This order in principle comes from 
 nowhere in the data. But it does in practice come from some arbitrary 
 decisions in the implementation.  Maybe this was andy's point.


 On Wednesday, 22 April 2015 13:18:43 UTC+10, Dave Sann wrote:

 Agree it's an interesting writeup.

 I think that the behaviour of seq should be entirely expected though. 
 Sets have no ordering (logically) so turning them into an ordered sequence 
 should be considered to be an entirely arbitrary operation (unless specific 
 guarantees are provided). The fact that the implementations sometimes 
 maintain an order should not be used or relied upon at all.

 a seq of a set is not itself a set and therefore is not subject to the 
 same referential transparency rules as a set.

 Dave

 On Wednesday, 22 April 2015 12:39:42 UTC+10, Mike Rodriguez wrote:

 Thanks for sharing this.  I found the write-up to be very informative 
 and to have good background sources.  

 I certainly never thought about this sneaky behavior concerning `seq` 
 and hash sets before now.  I'll have to look out for that one!

 On Tuesday, April 21, 2015 at 8:13:48 PM UTC-5, Andy Fingerhut wrote:

 I had come across the issue of Clojure hash sets that contain the same 
 set of elements returning their elements in different orders from each 
 other, depending upon which order they were added to the set (only if 
 they 
 have equal values for (hash x)).

 This and other questions on referential transparency on the Clojure 
 group got me thinking on my commutes about it some more, and I dug into 
 it 
 way more than I expected to, and wrote up an article on it.  If you think 
 such a topic would interest you, you can read more about it here:

 
 https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/referential-transparency.md

 Guaranteed at least 99% epiphany free

 Andy

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

Re: Too many words written on referential transparency in Clojure and Haskell

2015-04-22 Thread Dave Sann
one thought - (set (seq a-set)) is pure even is (seq a-set) is not - 
because (set a-seq) throws away the (random) order information that was 
added.

Dave


On Wednesday, 22 April 2015 19:03:23 UTC+10, Mark Derricutt wrote:

 On 22 Apr 2015, at 20:22, Dave Sann wrote:

 for example: seq on a set cannot be pure unless you were to provide an 
 argument to explicitly specify which order the items should be in. If you 
 do not do this, the order is defined either by some random interaction of 
 the of the data and function implementations - that you thought was 
 irrelevant - or has to be literally picked at random by the implementation. 
 The former of these will appear to be pure until you hit the special cases.

 This is exactly one of the reasons a bunch of folk ( aka, purests maybe ) 
 don't like that map/filter etc. in Clojure convert the input collection 
 into seqs, unlike Haskell or others where the those monad laws keep you in 
 check that map/filter return the *same* container - so mapping a set 
 would yield another set - also with no guaranteed order, and also with 
 uniqueness applied - so technically a map over a set may yield a collection 
 of an equal or smaller size, but never greater.

 This seems to fuel a lot of debate when entered into - so I guess I'm 
 asking for trouble in replies here :)

 Mark

 -- 
 Mark Derricutt
 http://www.theoryinpractice.net
 http://www.chaliceofblood.net
 http://plus.google.com/+MarkDerricutt
 http://twitter.com/talios
 http://facebook.com/mderricutt


-- 
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: Too many words written on referential transparency in Clojure and Haskell

2015-04-21 Thread Dave Sann
Agree it's an interesting writeup.

I think that the behaviour of seq should be entirely expected though. Sets 
have no ordering (logically) so turning them into an ordered sequence 
should be considered to be an entirely arbitrary operation (unless specific 
guarantees are provided). The fact that the implementations sometimes 
maintain an order should not be used or relied upon at all.

a seq of a set is not itself a set and therefore is not subject to the same 
referential transparency rules as a set.

Dave

On Wednesday, 22 April 2015 12:39:42 UTC+10, Mike Rodriguez wrote:

 Thanks for sharing this.  I found the write-up to be very informative and 
 to have good background sources.  

 I certainly never thought about this sneaky behavior concerning `seq` and 
 hash sets before now.  I'll have to look out for that one!

 On Tuesday, April 21, 2015 at 8:13:48 PM UTC-5, Andy Fingerhut wrote:

 I had come across the issue of Clojure hash sets that contain the same 
 set of elements returning their elements in different orders from each 
 other, depending upon which order they were added to the set (only if they 
 have equal values for (hash x)).

 This and other questions on referential transparency on the Clojure group 
 got me thinking on my commutes about it some more, and I dug into it way 
 more than I expected to, and wrote up an article on it.  If you think such 
 a topic would interest you, you can read more about it here:

 
 https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/referential-transparency.md

 Guaranteed at least 99% epiphany free

 Andy



-- 
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: Too many words written on referential transparency in Clojure and Haskell

2015-04-21 Thread Dave Sann
Just to expand on this slightly - seq applied to a set must introduce an 
order that is not present in the set. This order in principle comes from 
nowhere in the data. But it does in practice come from some arbitrary 
decisions in the implementation.  Maybe this was andy's point.

On Wednesday, 22 April 2015 13:18:43 UTC+10, Dave Sann wrote:

 Agree it's an interesting writeup.

 I think that the behaviour of seq should be entirely expected though. Sets 
 have no ordering (logically) so turning them into an ordered sequence 
 should be considered to be an entirely arbitrary operation (unless specific 
 guarantees are provided). The fact that the implementations sometimes 
 maintain an order should not be used or relied upon at all.

 a seq of a set is not itself a set and therefore is not subject to the 
 same referential transparency rules as a set.

 Dave

 On Wednesday, 22 April 2015 12:39:42 UTC+10, Mike Rodriguez wrote:

 Thanks for sharing this.  I found the write-up to be very informative and 
 to have good background sources.  

 I certainly never thought about this sneaky behavior concerning `seq` and 
 hash sets before now.  I'll have to look out for that one!

 On Tuesday, April 21, 2015 at 8:13:48 PM UTC-5, Andy Fingerhut wrote:

 I had come across the issue of Clojure hash sets that contain the same 
 set of elements returning their elements in different orders from each 
 other, depending upon which order they were added to the set (only if they 
 have equal values for (hash x)).

 This and other questions on referential transparency on the Clojure 
 group got me thinking on my commutes about it some more, and I dug into it 
 way more than I expected to, and wrote up an article on it.  If you think 
 such a topic would interest you, you can read more about it here:

 
 https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/referential-transparency.md

 Guaranteed at least 99% epiphany free

 Andy



-- 
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] lein-docker, lein-beandock

2015-04-07 Thread Dave Sann
see also

https://github.com/palletops/lein-uberimage

On Wednesday, 8 April 2015 07:35:54 UTC+10, Allen Rohner wrote:

 https://github.com/arohner/lein-docker

 https://github.com/arohner/lein-beandock

 `lein-docker` is a simple plugin for performing `docker build` and `docker 
 push`. lein-beandock is a semi-fork of `lein-beanstalk`, specializing in 
 deploying docker containers to AWS Elastic Beanstalk. 

 Thanks,
 Allen



-- 
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][book] Clojure Reactive Programming

2015-03-26 Thread Dave Sann
Not being politically correct is fine.

But an attack on anonymous stupid people in this context is pointless and 
sours the otherwise potentially useful commentary. It also completely 
derails the topic.

Comment on the objective aspects of the technology. If you have a personal 
issue with someone or their decision, maybe it is better to take it up with 
them. That way you might get an outcome. If you don't think you get that 
then maybe it is better just to move on and forget about it (they probably 
have).

You don't have to agree but it is better to be constructive.

Dave

On Thursday, 26 March 2015 04:12:43 UTC+11, Luc wrote:

 I support your statement. 
 I am fed up by this extreme political correctness era. 

 This leads directly to auto censorship. 

 I met numerous 'anarchitects' who never had to bring an app from inception 
 to 
 real life use but nonetheless where issuing 'profound' statements about 
 the last buzz word they 
 read from the news stand. 

 With unnecessary software complexity comes huge teams, dilution of 
 responsibilities and 
 expertise, aside from the one picked up through some headlines. 

 This leads to a lack of accountability overall. 
 No one is responsible, 'we followed best practices/processes according to 
 {put your favorite methodology name here}' 

 I saw 'anarchitects' fly out before integrated or acceptance tests because 
 they had realize that the monster they helped created could not lift from 
 the ground. 
 Human induced complexity killed it well before it started to breathe. 
 A kind of Frankenstein aborted experiments. 

 After spending zillions of customer $ of course... 

 If it swims like a duck, squeaks like a duck, walks like a duck, well it's 
 a duck. 
 Not some kind of abstract apparatus. 

 Nothing forces people to buy/listen to a book/news report/tv show/... if 
 they find it rude 
 or inappropriate to their taste. 

 They just have to zap like most of them are doing over any serious 
 thinking about   
 how they work, what's the purpose of it and what responsibilities comes 
 with it. 

 It's already a miracle that some people are actually saying publicly what 
 they really think, 
 let's not try to cut their wings... 

 Pleasing the majority is the path to mediocrity. 

 Luc P. 

  Trust me I have been using Scala + Akka + Play for past three years in 
  production, and had to deal with tons of incidental complexity plus a 
 lot 
  of noise they introduce as my daily job (in my code as well as other 
  developer's code). Now I am in the best position to judge and compare 
 them 
  with Clojure code that does similar job but ten times simpler (and I 
 don't 
  only mean 10 time less verbose). 
  I am sorry but I need to confess that within past 15 years that I have 
 been 
  working with numerous architects most of them choose technologies only 
  based on 1/2 hour googling or reading reviews (and I don't mean all 
  architects are like this). In particular the one I rightly called 
 ignorant 
  did not even write a simple poc to use AKKA and java8 to see how code 
 looks 
  like. 
  By pathetic technology (and I didn't mean java8) I mean a technology 
 that 
  you need to fish out less than 10 lines of business logic from 50 or 
 more 
  lines of noise introduced by Scala futures (in AKKA), Play promise 
 redeems, 
  matching classes (case classes in Scala)... 
  Remember when first time Spring was introduced, the original goal was to 
  take out all the noise and put them in XML file so the developer remain 
  focused on business logic. Here we are 10 or so years later: lots of 
 noise 
  and complexity added to the code to do orchestration. This is work of 
  intelligent fool... (look at Erlang which AKKA tried to copy, it does a 
  powerful orchestration without introducing much complexity, this is 
 touch 
  of genius) 
  These are the pain points in our field. I have deeply felt it and try to 
  point out that the life does not need to be that hard. 
  Clojure is the first real try in opposite direction (touch of genius) 
  
  Thanks a lot 
  Best regards 
  Shahrdad 
  
  
  
  
  On Wed, Mar 25, 2015 at 8:06 AM, Colin Yates colin...@gmail.com 
 javascript: wrote: 
  
   No - he is right, we just don't say it! Obviously I am kidding :). 
   
   On 25 March 2015 at 11:51, Hildeberto Mendonça m...@hildeberto.com 
 javascript: wrote: 
On Wed, Mar 25, 2015 at 12:14 PM, Colin Yates colin...@gmail.com 
 javascript: 
   wrote: 

Hi Shahrdad, just a point of etiquette, inferring that an architect 
 is 
ignorant because they chose Java8, Akka and play is full of 
 assumptions. 
Calling those technologies pathetic is very bad poor. 

As I like to quote Any intelligent fool can make things bigger and 
 more 
complex... It takes rude manners, assumptions and a whole bunch of 
numptiness to claim 'bigger and more complex' means the author is a 
   fool. 


That's why I love this community. Mutual

Re: [ANN] Dunaj project, an alternative core API for Clojure

2015-03-11 Thread Dave Sann
very interesting work and well presented, keep going.

-- 
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: Om design query

2015-03-05 Thread Dave Della Costa
(cc'ing clojurescr...@googlegroups.com)

Hi James,

Let me make sure I understand what you're asking: you have a parent
enclosing component that has to do calculations to position a set of
child component element, but you can only properly calculate positioning
for those child elements (in the parent?) after you get offset position
information for each one, once they have mounted?

DD


On 2015/03/06 13:40, James Reeves wrote:
 I've been writing an application using Om, and I've come across a
 problem I haven't been able to find a good solution for. I'd be grateful
 for any ideas people might have on how to proceed.
 
 In a nutshell, I have a bunch of elements that need to be arranged
 according to a specific algorithm. They cannot overlap, so I need to
 know the sizes of all the elements in order to arrange them.
 
 Om has an IDidMount protocol which is called after the component has
 been mounted into the DOM. I can use this to find out the size of the
 element:
 
 (let [node (get-node owner)]
   [(.-offsetWidth node) (.-offsetHeight node)])
 
 Elements can be hidden with visibility: hidden until their sizes are
 known.
 
 The problem that's stumping me is how to deliver the sizes back to the
 containing component so that all the elements can be arranged correctly.
 
 The most obvious way is via the cursor, but I don't like the idea of
 mixing application state with local display information. Can anyone
 think of a better way?
 
 - James
 
 -- 
 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
 mailto: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] Understanding the Persistent Vector

2015-03-02 Thread Dave Della Costa
This is wonderful, I can't wait to dig in!

On 2015/03/01 1:14, Jean Niklas L'orange wrote:
 Hello fellow Clojurians,
 
 I am happy to announce that I have finished my blogpost series on the
 persistent
 vector. It consists of five parts:
 
  1. The basic algorithms
 http://hypirion.com/musings/understanding-persistent-vector-pt-1
  2. Indexing
 http://hypirion.com/musings/understanding-persistent-vector-pt-2
  3. The tail optimisation
 http://hypirion.com/musings/understanding-persistent-vector-pt-3
  4. Transients
 http://hypirion.com/musings/understanding-clojure-transients
  5. Performance
 http://hypirion.com/musings/persistent-vector-performance-summarised
 (which is a summary of this detailed blogpost
 http://hypirion.com/musings/persistent-vector-performance)
 
 I hope this will help you to get a good understanding of how the
 algorithms on
 the data structure work, how the optimisations work, and how efficient
 it is on
 the JVM.
 
 Constructive criticism, both positive and negative, is appreciated.
 
 Enjoy!
 
 (NB: I haven't gotten around to fix the illustrations in part 3, so
 unfortunately it will be a bit hard to read if you print it out in
 grayscale.
 It's on my todo-list.)
 
 -- Jean Niklas L'orange
 
 -- 
 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
 mailto: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: Reflection warning on setCaretPosition

2015-02-27 Thread Dave Ray
(let [^JEditorPane html-table (editor-pane ...)] ...)  should fix it. Or
just set the caret position in the create function:

(editor-pane :caret-position 0)

or use config:

(config! editor-pane :caret-position 0)

Dave


On Fri, Feb 27, 2015 at 4:07 AM, Cecil Westerhof cldwester...@gmail.com
wrote:

 2015-02-27 11:34 GMT+01:00 Gary Verhaegen gary.verhae...@gmail.com:

 It means the Clojure compiler cannot emit the efficient bytecode
 directly, so it emits bytecode that calls the method reflexively.

 This only impacts performance, so if that code is not used much, it is
 not a problem.


 ​It is not used much, so it should not be a real problem.
 ​



 The underlying problem is that jvm bytecode is typed, so ideally the
 bytecode should be able to say call method M of type T on object O. Here,
 the Clojure Compiler cannot infer a type for html-table, so instead the
 emitted bytecode is more along the lines of ask object O to give a list of
 all of its types, then look into each of these types to find if one has a
 method that matches M in terms of name and number of arguments, and then
 look at that method's signature and check if the arguments can be cast to
 the types of the formal parameters; if there is a type with such a method,
 invoke that method.

 This is not 100% technically accurate (in particular, i have no idea what
 reflection does about the arguments and their types in this case), but it
 should be roughly correct and you can easily see why that would be much
 slower.

 If you want to remove that warning, you can annotate the html-table
 variable, but the place where you must do that will depend on a little more
 context than what you've given here. It is usually done at the level of var
 declaration or in function argument lists.


 ​This is the code:
(let [html-table (editor-pane
  :content-type text/html
  :text (str html-start
 html-records
 html-end))
 ]
 (.setCaretPosition html-table 0)

 So html-table is a JEditorPane. Should Clojure not be able to determine
 that?


 Just to satisfy my curiosity: how can I get rid of the warning?
 ​


 On Friday, 27 February 2015, Cecil Westerhof cldwester...@gmail.com
 wrote:

 On a editor-pane I use:
 (.setCaretPosition html-table 0)

 ​And it does what it should do. But when I run:
 lein check

 I get:
 Reflection warning, quotes/core.clj:98:42 - call to method
 setCaretPosition can't be resolved (target class is unknown).

 Is that something to worry about?

 By the way, I get also some on jdbc and seesaw.​


 ​Strange enough I only get the warnings on my own code now.
 ​

 --
 Cecil Westerhof

 --
 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] Buddy 0.4.0: Security library for clojure.

2015-02-22 Thread Dave Sann
buddy-auth vs friend?

What is the difference/motivation?



On Monday, 23 February 2015 06:32:22 UTC+11, g vim wrote:

 On 22/02/2015 11:36, Andrey Antukh wrote: 
  Documentation: 
  https://funcool.github.io/buddy-core/latest/ 
  https://funcool.github.io/buddy-auth/latest/ 
  https://funcool.github.io/buddy-hashers/latest/ 
  https://funcool.github.io/buddy-sign/latest/ 
  

 Great addition to Clojure web development security. For new users might 
 I suggest adding a namespace table to -core, -hashers and -sign as with 
 -auth? 

 gvim 


-- 
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: datomic - datascript transfers

2015-02-19 Thread Dave Dixon
We're having success with the Datomic - Datascript scenario by treating 
the Datascript DB as an immutable value, rather than a ref + transactor, at 
least in the case for user's interactively changing data. When the user 
loads the data required for a scenario (e.g. editing an entity), we hold 
the value as obtained from datomic and the updated value used by applying 
user changes through the with or with-db functions. When the user chooses 
to commit, we essentially diff the sets of datoms between the original and 
changed Datascript values (twice - once to get adds and once for retracts), 
as well as identify the Datascript id's of added entities. On the server, 
the new Datascript id's are converted into Datomic temp id's, and we just 
transact the transformed diff. 

There are some differences in behavior which need to be worked around, 
particularly the behavior of :db/ident. We strictly use :db/ident only for 
attribute names and enums. This allows us to do the appropriate 
transformations to the data and pull patterns so that the differences 
between Datascript and Datomic are more or less hidden.

Works very well for editing hierarchical entities. The parent can simply 
pass it's Datascript value and the appropriate child id to the child 
editor. If the user commits the child changes, the parent simply takes the 
updated value of the db; if the user cancels, the parent doesn't need to do 
anything, as it is already holding the unchanged value.

On Tuesday, February 17, 2015 at 2:00:03 AM UTC-8, henry w wrote:

 For anyone else looking at this option, here is some code which is doing 
 the work on the cljs side.

 https://gist.github.com/henryw-erudine/73cbcdea1eda150e78da

 The server code is straightforward so not included. 


-- 
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: TDD and lein

2015-01-08 Thread Dave Della Costa
One more suggestion as you mentioned wanting to see more output,
although this may be different from what you were asking--but still
worth knowing about:

https://github.com/pjstadig/humane-test-output

Cheers,

DD

On 2015/01/08 20:30, andrea crotti wrote:
 Hi guys,
 
 I'm starting to use Clojure a bit more seriously, I knew already Lisp a
 bit and Haskell, in plus I've been using Emacs for a long time so
 luckily it's not as hard, and it's a lot of fun.
 
 I'm using Emacs + Cider for development and it works wonderfully,
 however I have a few problems/questions trying to do TDD.
 
 1. Isn't it possible to make Lein more verbose?
 
It's often quite slow and it would be nice to know what is going
on, I can stand the slowness but at least tell me something :D
 
 2. When is exactly that I need to run again lein test (which is
painfully slow) and when just rerunning the tests from the same REPL
suffice?
 
I thought only when changing dependencies, but I had different
experiences so I'm not too sure about the rule.
 
And what command exactly is Cider triggering when I run the tests?
It would be nice to be able to see somewhere more information like:
- compiling file x
- running tests for y with command z
 
  3. Does incremental compilation work well/make sense for Clojure?
 I found something but the fact that it's not done straight away in
 Leiningen makes me think it's maybe not much used?
 
 Thanks a lot, and congratulations to all the developers for the great 
 language!
 

-- 
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: Implementing a Oauth2 provider with clauth and friend

2014-12-15 Thread Dave Della Costa
I'm a bit confused--if you are building your own oauth2 server (correct
me if I misunderstood--you want users to use oauth2 to authenticate
against your own service?), what purpose does a Friend workflow have in
this context?  Seems like you could skip Friend altogether.

DD

(2014/12/15 17:40), Sebastian Bensusan wrote:
 Hi Dave, 
 
 I am planning to use friend-oauth2 to handle third party workflows. It
 is exactly what I need to consume third party oauth services, but from
 what I understood from the source code, it doesn't help me offer my own
 oauth service. I'm struggling with the design for an oauth service that
 integrates directly with friend.
 
 Thanks for your answer!
 
 Sebastian
 
 On Monday, December 15, 2014 6:58:55 AM UTC+1, David Della Costa wrote:
 
 You could also take a look at friend-oauth2 if you are using it in the
 context of Friend--if it doesn't work for you for some reason I'd like
 to know why, as I'd like it to be able to handle this use-case.
 
 https://github.com/ddellacosta/friend-oauth2
 https://github.com/ddellacosta/friend-oauth2
 
 Thanks!
 
 DD
 
 (2014/12/15 3:08), Sebastian Bensusan wrote:
  Hi,
 
  I am writing a Single Page Application using Om that communicates via
  XHR with a REST API using compojure + liberator. I should be able to
  authenticate users by using email  password credentials or third
 party
  Oauth2 like Linkedin's. I
 
  My plan is: use clauth [1] to roll my own oauth2, package it as a
 friend
  credential-fn/workflow, and then wrap the liberator api with
  friend [2]  and the third parties workflows.
 
  Anybody has any pointers on how to do this? It is a complex
 solution but
  I have no ideas on how to simplify it.
 
  Thanks for your time!
 
  Sebastian
 
  [1] https://github.com/pelle/clauth https://github.com/pelle/clauth
  [2]
 
 http://sritchie.github.io/2014/01/17/api-authentication-with-liberator-and-friend/
 
 http://sritchie.github.io/2014/01/17/api-authentication-with-liberator-and-friend/
 
 
  --
  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
 javascript:
  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 javascript:
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en
 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 javascript:
  mailto:clojure+u...@googlegroups.com javascript:.
  For more options, visit https://groups.google.com/d/optout
 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
 mailto: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: Implementing a Oauth2 provider with clauth and friend

2014-12-14 Thread Dave Della Costa
You could also take a look at friend-oauth2 if you are using it in the
context of Friend--if it doesn't work for you for some reason I'd like
to know why, as I'd like it to be able to handle this use-case.

https://github.com/ddellacosta/friend-oauth2

Thanks!

DD

(2014/12/15 3:08), Sebastian Bensusan wrote:
 Hi,
 
 I am writing a Single Page Application using Om that communicates via
 XHR with a REST API using compojure + liberator. I should be able to
 authenticate users by using email  password credentials or third party
 Oauth2 like Linkedin's. I
 
 My plan is: use clauth [1] to roll my own oauth2, package it as a friend
 credential-fn/workflow, and then wrap the liberator api with
 friend [2]  and the third parties workflows.
 
 Anybody has any pointers on how to do this? It is a complex solution but
 I have no ideas on how to simplify it. 
 
 Thanks for your time!
 
 Sebastian
 
 [1] https://github.com/pelle/clauth
 [2] 
 http://sritchie.github.io/2014/01/17/api-authentication-with-liberator-and-friend/
 
 -- 
 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
 mailto: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: what do you think about this code?

2014-12-09 Thread Dave Della Costa
Hi Philip,

I think Colin gave a good response further down the thread, in
particular I think his statement I at least have found Clojure has a
much higher signal to noise ratio...snip...and can provide a
significant reduction in incidental complexity, thus reducing the
problem that some of these approaches are solving is pertinent here.

I'll expand on my interpretation of that a bit.  But first let me say
that I'm pretty familiar with Uncle Bob, extreme programming and Agile
development and the set of practices associated with those labels.  I
have been, in fact, a passionate advocate of extreme programming
practices at times in the past.  I do think there is a lot of value
there, and I think every professional developer who has to work on teams
and maintain code should seriously engage with that set of practices to
try to understand the value.

That said, there is also a lot of dogma and unquestioned convention in
that community.  I find Uncle Bob in particular to be frustrating in his
rigidity, even when I agree with many specific points he makes.  More
relevant to the discussion at hand, since I've been using functional
programming approaches, I've developed a more flexible attitude to what
it means to do development The Right Way.

So first off, I would like to point out that I had no comments in my
code--but I did document my functions with doc strings.  I suppose the
point about fragility stands, but on the other hand I am consistently
frustrated when developers fail to document their public-facing
libraries, and I think good documentation is a hallmark of high-quality
software.  So I guess what I'm saying is that I've accepted there is
value in writing about your code vs. (or in addition to) simply letting
your code speak for itself, despite its cost; the value outweighs this
cost.  The analogy image of the mislabeled container you attached, while
clever, breaks down for me here: someone hasn't met all of their
responsibilities.

At the same time I do not disagree with the essence of what Uncle Bob
says regarding comments: code that isn't clear and needs heavy
commenting is *probably* problematic.  However, I think the solution in
functional languages is to lean heavily on the core persistent data
structures and associated functions, use pure functions as much as
possible and make it clear when you are not, specify types (in Clojure
we can use schema or core.typed for this), and finally let the data do
the talking.

Regarding TDD: as I said I do use TDD in a professional setting, but not
consistently: I don't think it is consistently necessary, and more than
anything, the central argument of a lot of TDD apologists--that it helps
guide design--seems much less compelling when using a functional
approach.  I haven't gotten enough clarity in my own mind as to why
exactly this is yet, so I'll leave it at that--but let it suffice to say
that I think TDD's biggest value in my day-to-day work in Clojure is in
automatically providing a suite of regression tests, not providing
design guidance.

Finally, I would add that I agree with Kent Beck's points you listed at
the end--I would simply argue that it's not necessarily the case that
following Uncle Bob's stringent guidelines (for example) are the way to
achieve those goals when using Clojure or doing functional programming
in general.

Thanks for making me think hard about this--I haven't tried to
crystallize what I've learned since starting down this path a few years
ago, and it's really valuable to think hard on it!  Making high quality,
maintainable software is challenging and deserves careful thought.

Best,
Dave

(2014/12/09 9:24), Philip Schwarz wrote:
 Hello David,
 
 I had set myself the constraint that I wanted the solution to exploit
 two symmetries: 
 (1) The top left and top right of the diamond are mirror images
 (2) The top half and bottom half of the diamond are also mirror images
 
I'm assuming you used a TDD process to write this (correct me if
 wrong--basing that on the articles you linked to)
 I was on a train commuting back home, and what I did was sit in a loop
 where I wrote some code and then tweaked it until executing it in the
 REPL gave me the part of the diamond that I wanted, by eyeballing the
 console output. What a coincidence that in your gist you linked
 to http://blog.jayfields.com/2014/01/repl-driven-development.html . I
 was looking at exactly that blog post on Sunday to determine if what I
 had been doing could be classified as REPL-based? Still not sure. Thoughts?
 
 My first version of the code was this
 https://gist.github.com/philipschwarz/c7e3be1ac97e482d04bf: 
 
 (defn print-diamond [letter]
 (let [alphabet ABCDEFGHIJKLMNOPQRSTUVWXYZ
 position-of (fn [letter] (inc (- (int letter) (int \A
 number-of-letters (position-of letter)
 dashes (fn [n] (repeat n \-))
 fixed-text-for (fn [letter] (concat (dashes (dec (position-of letter)))
 (list letter)))
 template (map fixed-text-for (take number-of-letters alphabet

Re: Open html file in Clojure

2014-12-08 Thread Dave Ray
Nope. It barely renders HTML3. JavaFX, I think, has a real embedded browser
component. And, of course, it's always easy to just launch a browser:
http://docs.oracle.com/javase/6/docs/api/java/awt/Desktop.html#browse%28java.net.URI%29

Dave

On Mon, Dec 8, 2014 at 4:23 AM, Gary Verhaegen gary.verhae...@gmail.com
wrote:

 This seems to be what Fluid is talking about:

 https://docs.oracle.com/javase/tutorial/uiswing/components/html.html

 I wiuld be a bit wary, however: I doubt this is a complete implementation
 of an HTML5-compatible browser with state of the art JavaScript
 interpreter. It's worth trying, but I would not really bet on that being
 able to display a Google Maps widget.

 On Monday, 8 December 2014, Fluid Dynamics a2093...@trbvm.com wrote:

 On Sunday, December 7, 2014 6:50:54 PM UTC-5, juan.facorro wrote:

 Hi Priyanka,

 I don't think there's enough information for someone to be able to help
 you. When you say .html do you mean JavaScript or ClojureScript code? It
 will be a lot easier to help you, if you share the code from the desktop
 app and the code you are using to get the location information.


 It sounds like he just wants to display a web page in his app, and has
 its URL. I think there may be Java Swing components that can do that.

 --
 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: snubbed on clojurescript one

2014-11-17 Thread Dave Della Costa
Hi Kevin, my understanding is that ClojureScript One is not actively
maintained and pretty out of date at this point.  You're probably better
suited to starting from a different place in the eco-system.

What are your goals in using ClojureScript?  If you want to describe a
bit what you're after (i.e. just getting up and running with
ClojureScript, building web clients, etc.), then I think folks on the
list can give you a lot of suggestions.

/cc clojurescr...@googlegroups.com

DD

(2014/11/18 15:39), Kevin Banjo wrote:
 Really excited to use clojurescript one but got shot down right out of
 the gate.
 
 Anyone here have the answer?
 
 https://github.com/brentonashworth/one/issues/145
 
 
 -- 
 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
 mailto: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: a nicer way to write 1 - 2 + 3 - 4 ... +/- n

2014-11-13 Thread Dave Ray
How about:

(- (map * (cycle [1 -1]) (range 1 n))
 (reduce +))

?

Dave


On Thu, Nov 13, 2014 at 5:31 PM, Andy L core.as...@gmail.com wrote:

 Hi,

 All I was able to come up with was this

 (defn altsum[n] (reduce + (map * (range 1 (inc n))  (interpose -1 (repeat
 1)

 ... works quite well, however I was wondering if there is more idiomatic
 way to write that.

 Thanks,
 Andy

 --
 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: [JOB] Clojure DevOps Engineer

2014-10-30 Thread Dave Della Costa
FYI folks, Alex (akhudek) and I (ddellacosta) hang out on IRC often so
feel free to ping us w/questions there.

Thanks!

DD

(2014/10/31 12:28), Alexander Hudek wrote:
 Note that this position is 50% Clojure development and 50% DevOps/Sysadmin.
 
 
 Best,
 
 Alex
 
 
 --
 
 
 CLOJURE DEVOPS
 
 
 DiligenceEngine Inc. is a Toronto-based startup using machine learning
 to automate legal work. We’re looking for a DevOps engineer to help us
 manage and automate our technology stack. Our team is small, pragmatic,
 and inquisitive; we love learning new technologies and balance adoption
 with good analysis. We prefer to hire in the Toronto area, but also
 welcome remote work in a time zone within North America.
 
 
 Primary skills we are looking for:
 
   *
 
 proficiency with scripting for automating tasks (we use Python and a
 bit of Bash)
 
   *
 
 proficiency in Linux systems administration
 
   *
 
 knowledge of system security
 
   *
 
 proficiency with PostgreSQL administration
 
   *
 
 knowledge of managing clusters and highly available systems,
 especially PostgreSQL
 
 
 Skills that are nice to have:
 
   *
 
 some Clojure experience
 
   *
 
 familiarity with Docker
 
   *
 
 building distributable virtual machines
 
 
 Responsibilities:
 
   *
 
 approximately 50% systems administration and 50% development
 
   *
 
 required to be on-call at sometimes
 
   *
 
 maintaining and extending cluster manager software
 
   *
 
 automating build and deployment processes
 
   *
 
 automating testing processes
 
 
 Don’t worry if you are only experimenting with Clojure or other nice to
 have skills, we’re happy to help you learn. Development tasks vary
 depending on your strengths and interests. Everything from working with
 our clustering software to the web service is an option.  We are really
 interested in someone who sees an opportunity to automate something,
 helps us work out the kinks, and takes the initiative and does it.
 
 
 This position starts as soon as possible.
 
 
 To apply, send an email to j...@diligenceengine.com with your resume and
 links to previous work.
 
 -- 
 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
 mailto: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: CCW bug [SEVERE]

2014-10-28 Thread Dave Ray
Do the names Ken Wesson or Cedric Greevey mean anything to you? Just
checking.

On Tue, Oct 28, 2014 at 1:28 PM, Fluid Dynamics a2093...@trbvm.com wrote:

 On Tuesday, October 28, 2014 12:19:29 PM UTC-4, Marcus Blankenship wrote:

 Agreed.  I've been amazed at how kind this group has been, despite your
 attitude of disrespect toward them.

 On Tue, Oct 28, 2014 at 9:09 AM, Dylan Butman dbu...@gmail.com wrote:

 From your attitude and lack of respect for the very knowledgeable,
 experienced, and respectful people here trying to help improve and
 understand the short comings in your current workflow, I'd say you might be
 walking to work in the near future. Parking's free that way.


 Really? Because I'm not the one who accused someone of nonexistent
 shortcomings and then made the impotent threat to revoke someone's
 driver's license -- and then had his threatening post deleted by the
 moderator. Hmm. :)

 Meanwhile, I think some people still have not grasped the scale of what
 I'm doing, namely how small it is. Small, experimental, limited to one
 person, and so forth. Version control, I repeat, would be MASSIVE overkill
 under the circumstances. It would make barely any less sense to reach for
 version control before writing a hello, world program.

 IF the project grows enough and is successful enough, then I might
 consider creating a github account and basing it there. But right now
 things are NOWHERE NEAR that kind of state. I am unsure how else to try to
 communicate the fact of how small, unpublishable, and etc. it is at this
 stage, so I will probably give up on anyone here who still seems to think
 it's big enough, has enough developers, or whatever to benefit from version
 control. It's not. So far there's two files of combined size 1200 lines,
 most of them comment and docstring lines. There might be as many as 200
 actual lines of Clojure in there so far. Using a version control system,
 and dealing with all of the associated ceremony and formalities, would be
 like renting a factory and setting up all of the process monitoring,
 conveyor belt equipment, robot arms, safety inspections, permits, and
 everything else attendant the use of such a facility, just to put together
 a high school shop project wooden birdhouse to hang from a tree in my own
 back yard. :) It would be like filing a flight plan with the FAA before
 going to the city park with a kite. Like getting in the car and driving to
 the house next door to visit the neighbors for coffee. Like bringing a map,
 compass, pack full of survival supplies, camp stove, satellite phone,
 avalanche beacon, ropes, pitons, and sturdy hiking boots to take a walk in
 NYC that crosses through Central Park. Like commissioning the Glomar
 Explorer to fish a ring out of a toilet bowl. Bringing lawyers and pages of
 CYA contract text to a negotiation with a Starbucks for the purchase of a
 latte. Taking out a business license and city zoning permit to open a kid's
 five-cent lemonade stand. Seeking an import license before bringing a
 couple of Disney T-shirts back from EuroDisney. Requiring a full credit
 check before loaning your neighbor a screwdriver. Using steel-reinforced
 concrete to build a sandcastle.

 I trust everyone now gets the picture, and that any exception is named
 Sheldon Cooper? :)


  --
 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: CCW bug [SEVERE]

2014-10-26 Thread Dave Della Costa
Here's the counterclockwise project home page, as far as I can tell:

https://code.google.com/p/counterclockwise/

Issue tracker:

https://code.google.com/p/counterclockwise/issues/list

Users google group:

https://groups.google.com/forum/#!forum/clojuredev-users

I think you'd get a lot more mileage by posting something there, and I
think you'd also get a better response if you could express the problem
you're having calmly (i.e., leave off the all caps and goddamn save
language).  I also suspect the developers of CCW would be equally
horrified at your experience, and would probably love to have your help
in debugging it and fixing it, if you're willing.

Good luck resolving the issue--

DD

(2014/10/26 14:45), Fluid Dynamics wrote:
 On Sunday, October 26, 2014 1:04:49 AM UTC-4, danneu wrote:
 
 Fluid Dynamics wrote:
 
 I do not ever want to see anything purportedly STABLE do
 something like that ever again 
 
 
 There are a lot of things I do not ever want to see.
 
 I don't want to see debt collectors or clojure stacktraces or my
 uncle Frank.
 
 Unfortunately, demanding that I don't see them is not what moves the
 needle
 towards eliminating them from my life.
 
 
 Unfortunately, since I am not the CCW developer nor do I have the time
 or inclination to spend 3 months poring over and learning its code base
 to get up to sufficient speed to fix bugs in it myself, demanding that
 it not crash is all I can do to eliminate CCW crashes from my life.
 
 -- 
 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
 mailto: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] tools.analyzer[.jvm] 0.6.0 release, pass scheduler

2014-09-19 Thread Dave Sann
Hi Nicola, 

why do you pass a set of vars to schedule rather than a set of functions?

I'm just interested. It's unusual to see #'

Dave

On Friday, 19 September 2014 05:07:08 UTC+10, Nicola Mometto wrote:


 Today I released version 0.6.0 of the tools.analyzer[1] and 
 tools.analyzer.jvm[2] contrib libraries. 

 With this release comes a new feature I'm really excited about and that 
 I believe will help users of this library significantly: a pass 
 scheduler. 

 Previous to this release, tools.analyzer passes had to be combined 
 manually, requiring deep knowledge of the implementation of those 
 passes, whose dependencies were not explicit. 

 That usually resulted in users copy-pasting the tools.analyzer.jvm 
 run-passes function using that as a template. 

 With the new scheduler, all of this is no longer necessary as all it 
 takes care of automatically pulling in dependencies and composing the 
 passes in the required and most efficient order, composing together 
 passes whenever possible, to minimize the overhead of a full tree 
 traversal. 

 To get a sense of how that has improved, here's run-passes from 0.5.6: 

 https://github.com/clojure/tools.analyzer.jvm/blob/be55b4e32371060932ac8d4094eb5b1b77fe4349/src/main/clojure/clojure/tools/analyzer/jvm.clj#L430-L477
  
 and here it is from 0.6.0, using the pass scheduler: 

 https://github.com/clojure/tools.analyzer.jvm/blob/1757871eb828c419f8de1cf177f125897f653829/src/main/clojure/clojure/tools/analyzer/jvm.clj#L397-L427
  

 Exposing the default-passes set, users who want to add a pass to the 
 default passes run by t.a.jvm need only to bind run-passes to 
 `(schedule (conj default-passes #'my-pass))`, or dissoc a default pass 
 if not needed. 

 To get started with the pass scheduler, here's its extensive docstring: 

 https://github.com/clojure/tools.analyzer/blob/7a8cba9b26689675debdaabc83f20e485003bf5a/src/main/clojure/clojure/tools/analyzer/passes.clj#L137-L168
  
 and here is a comprehensive example of a pass configuration via 
 :pass-info: 

 https://github.com/clojure/tools.analyzer.jvm/blob/1757871eb828c419f8de1cf177f125897f653829/src/main/clojure/clojure/tools/analyzer/passes/jvm/validate_loop_locals.clj#L150
  

 Nicola 

 [1]https://github.com/clojure/tools.analyzer 
 [2]https://github.com/clojure/tools.analyzer.jvm 


-- 
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] tools.analyzer[.jvm] 0.6.0 release, pass scheduler

2014-09-19 Thread Dave Sann
thanks

On Friday, 19 September 2014 23:08:35 UTC+10, Nicola Mometto wrote:


 The :pass-info metadata needed to resolve the pass dependency order is 
 attached to the Vars, not to the functions. 
 Even though we could attach that meta to the functions rather than to 
 the Vars, leaving aside that it would be less pleasant, multimethods 
 can't have metadata attached as they are not AFunctions so that would 
 require wrapping each pass in a fn even when unnecessary. 

 Given all this, using a set of Vars is perfectly reasonable. 

 Nicola 

 Dave Sann writes: 

  Hi Nicola, 
  
  why do you pass a set of vars to schedule rather than a set of 
 functions? 
  
  I'm just interested. It's unusual to see #' 
  
  Dave 
  
  On Friday, 19 September 2014 05:07:08 UTC+10, Nicola Mometto wrote: 
  
  
  Today I released version 0.6.0 of the tools.analyzer[1] and 
  tools.analyzer.jvm[2] contrib libraries. 
  
  With this release comes a new feature I'm really excited about and that 
  I believe will help users of this library significantly: a pass 
  scheduler. 
  
  Previous to this release, tools.analyzer passes had to be combined 
  manually, requiring deep knowledge of the implementation of those 
  passes, whose dependencies were not explicit. 
  
  That usually resulted in users copy-pasting the tools.analyzer.jvm 
  run-passes function using that as a template. 
  
  With the new scheduler, all of this is no longer necessary as all it 
  takes care of automatically pulling in dependencies and composing the 
  passes in the required and most efficient order, composing together 
  passes whenever possible, to minimize the overhead of a full tree 
  traversal. 
  
  To get a sense of how that has improved, here's run-passes from 0.5.6: 
  
  
 https://github.com/clojure/tools.analyzer.jvm/blob/be55b4e32371060932ac8d4094eb5b1b77fe4349/src/main/clojure/clojure/tools/analyzer/jvm.clj#L430-L477
  
  and here it is from 0.6.0, using the pass scheduler: 
  
  
 https://github.com/clojure/tools.analyzer.jvm/blob/1757871eb828c419f8de1cf177f125897f653829/src/main/clojure/clojure/tools/analyzer/jvm.clj#L397-L427
  
  
  Exposing the default-passes set, users who want to add a pass to the 
  default passes run by t.a.jvm need only to bind run-passes to 
  `(schedule (conj default-passes #'my-pass))`, or dissoc a default pass 
  if not needed. 
  
  To get started with the pass scheduler, here's its extensive docstring: 
  
  
 https://github.com/clojure/tools.analyzer/blob/7a8cba9b26689675debdaabc83f20e485003bf5a/src/main/clojure/clojure/tools/analyzer/passes.clj#L137-L168
  
  and here is a comprehensive example of a pass configuration via 
  :pass-info: 
  
  
 https://github.com/clojure/tools.analyzer.jvm/blob/1757871eb828c419f8de1cf177f125897f653829/src/main/clojure/clojure/tools/analyzer/passes/jvm/validate_loop_locals.clj#L150
  
  
  Nicola 
  
  [1]https://github.com/clojure/tools.analyzer 
  [2]https://github.com/clojure/tools.analyzer.jvm 
  


-- 
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: Potemkin 0.3.0

2014-09-16 Thread Dave Sann
to answer my own question. It does not play well. I created a couple of 
simple macros that mimics the import-vars behaviour for fns and vars in 
clojurescript. 

On Sunday, 14 September 2014 17:53:47 UTC+10, Dave Sann wrote:

 Does Potemkin work well with clojurescript?

 I have seen some discussion of issues in some places. Is there anywhere 
 that notes challenges?

 I am particularly interested with the import-vars scenario (defining 
 namespaces separately and then merging definitions into one namespace for 
 usage).

 Dave


 On Thursday, 20 June 2013 13:38:32 UTC+10, Jason Wolfe wrote:

 We're starting to use potemkin at Prismatic, and the part we've found 
 most useful which Zach didn't mention in his post are the smart types. 
  Especially definterface+, which is like a love child of defprotocol and 
 definterface:
  - Same syntax as defprotocol, and defines functions in your namespace 
 that wrap the interface functions (without extend-protocol support, 
 obviously)
  - Allows for primitive arguments and return values (like 
 clojure.core/definterface), which are propagated to the wrapper functions 
 for maximal performance
  - Doesn't re-evaluate if the body has not changed, which can make repl 
 development less painful (especially when used with its defrecord+ 
 counterpart).



 On Wednesday, June 19, 2013 12:12:41 PM UTC-7, Zach Tellman wrote:

 Potemkin [1] is a collection of facades and utilities that I've found 
 helpful when writing larger-scale libraries or applications.  I've never 
 formally announced it before, but I think it's gotten to the point where 
 others can benefit from it.

 A few highlights:

 * 'def-map-type', which allows for the definition of custom map-like 
 objects with 10x less code
 * 'unify-gensyms', which allows for more concise nested syntax-quotes
 * 'import-vars', which allows for code sprinkled across multiple 
 namespaces to be exposed via a single namespace

 It's been pointed out before that ideally a library should have no 
 dependencies but Clojure itself, or we risk transitive dependency conflicts 
 when everyone uses different versions of a utility library.  In deference 
 to this, Potemkin is licensed such that any piece of code can be simply 
 pasted into your library, as long as there's a comment describing the 
 origin.

 If anyone has questions, I'm happy to answer them.  If anyone has moral 
 or aesthetic objections to 'import-vars', you're not alone, but please 
 remember you're under no obligation to use it.

 Zach

 [1] https://github.com/ztellman/potemkin



-- 
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: Potemkin 0.3.0

2014-09-14 Thread Dave Sann
Does Potemkin work well with clojurescript?

I have seen some discussion of issues in some places. Is there anywhere 
that notes challenges?

I am particularly interested with the import-vars scenario (defining 
namespaces separately and then merging definitions into one namespace for 
usage).

Dave


On Thursday, 20 June 2013 13:38:32 UTC+10, Jason Wolfe wrote:

 We're starting to use potemkin at Prismatic, and the part we've found most 
 useful which Zach didn't mention in his post are the smart types. 
  Especially definterface+, which is like a love child of defprotocol and 
 definterface:
  - Same syntax as defprotocol, and defines functions in your namespace 
 that wrap the interface functions (without extend-protocol support, 
 obviously)
  - Allows for primitive arguments and return values (like 
 clojure.core/definterface), which are propagated to the wrapper functions 
 for maximal performance
  - Doesn't re-evaluate if the body has not changed, which can make repl 
 development less painful (especially when used with its defrecord+ 
 counterpart).



 On Wednesday, June 19, 2013 12:12:41 PM UTC-7, Zach Tellman wrote:

 Potemkin [1] is a collection of facades and utilities that I've found 
 helpful when writing larger-scale libraries or applications.  I've never 
 formally announced it before, but I think it's gotten to the point where 
 others can benefit from it.

 A few highlights:

 * 'def-map-type', which allows for the definition of custom map-like 
 objects with 10x less code
 * 'unify-gensyms', which allows for more concise nested syntax-quotes
 * 'import-vars', which allows for code sprinkled across multiple 
 namespaces to be exposed via a single namespace

 It's been pointed out before that ideally a library should have no 
 dependencies but Clojure itself, or we risk transitive dependency conflicts 
 when everyone uses different versions of a utility library.  In deference 
 to this, Potemkin is licensed such that any piece of code can be simply 
 pasted into your library, as long as there's a comment describing the 
 origin.

 If anyone has questions, I'm happy to answer them.  If anyone has moral 
 or aesthetic objections to 'import-vars', you're not alone, but please 
 remember you're under no obligation to use it.

 Zach

 [1] https://github.com/ztellman/potemkin



-- 
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] aprint (awesome print) released

2014-09-13 Thread Dave Sann
great stuff. thanks.

On Friday, 12 September 2014 01:06:29 UTC+10, Vladimir Bokov wrote:

 Yes. I use clansi:

 (clansi.core/without-ansi (aprint issues))

 Thanks for feedback, I updated README too

 четверг, 11 сентября 2014 г., 21:58:57 UTC+7 пользователь Dave Sann 
 написал:

 Is there an easy way to get the same compact layout but without the 
 colour control codes?

 On Friday, 5 September 2014 07:50:10 UTC+10, Vladimir Bokov wrote:

 Hi folks, I got just tired to gazing into big amount of data and scroll 
 3-4 screens of my 13' laptop to grasp the structure,
 so I used pprint's pretty printer, but add colors and changed 
 indentation *by default*
 (actually pprint has tuning parameters, too, but anyway it's breaking 
 maps by single entry by line...)

 Now the screen area gets used more effectively and looks more friendly 
 imo :)
 See it: https://github.com/razum2um/aprint

 Looking forward yours opinion if I should make a nrepl middleware to use 
 it *right away*, without doing (ap)
 every time ;)



-- 
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: leiningen resources folder

2014-09-11 Thread Dave Ray
clojure.java.io/resource isn't specific to the resources folder. It just
scans the classpath. Your classpath probably looks like
test:src:resources or something so test wins. If there was a
test/readme.txt file you'd also get that rather than resources/readme.txt.

Cheers,
Dave

On Thu, Sep 11, 2014 at 5:31 AM, Joc O'Connor johnocon...@fico.com wrote:

 Hi, when I use (.getPath (clojure.java.io/resource readme.txt)) I get
 the file path to the correct file in the resources folder (or nil if it
 doesn't exist).
 However if I pass in an empty string it returns the path to the 'test'
 folder rather then 'resources'. I have tried setting setting the resource
 paths in project.clj with no change in behaviour.

 Can anybody work out where I am going wrong?

 Joc

 --
 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] aprint (awesome print) released

2014-09-11 Thread Dave Sann
Is there an easy way to get the same compact layout but without the colour 
control codes?

On Friday, 5 September 2014 07:50:10 UTC+10, Vladimir Bokov wrote:

 Hi folks, I got just tired to gazing into big amount of data and scroll 
 3-4 screens of my 13' laptop to grasp the structure,
 so I used pprint's pretty printer, but add colors and changed indentation 
 *by default*
 (actually pprint has tuning parameters, too, but anyway it's breaking maps 
 by single entry by line...)

 Now the screen area gets used more effectively and looks more friendly imo 
 :)
 See it: https://github.com/razum2um/aprint

 Looking forward yours opinion if I should make a nrepl middleware to use 
 it *right away*, without doing (ap)
 every time ;)


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


how do you name your protocols?

2014-09-05 Thread Dave Sann
I saw a comment on protocol naming 
here: https://groups.google.com/d/msg/clojure/A4xIitQWloU/6E4xHDTPPaIJ

there is nothing in the coding standards: 
http://dev.clojure.org/display/community/Library+Coding+Standards (are 
these maintained?)

is there any sensible consensus on good naming convention?

IBlah
PBlah
BlahP
Blah
...other

...doesn't matter

Dave

-- 
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 Vim Ctags (oh my!)

2014-09-05 Thread Dave Ray
ctrl-o will take you back to your previous position after gf. At least it
does for me.

Dave


On Fri, Sep 5, 2014 at 11:47 AM, Alan Thompson clooj...@gmail.com wrote:

 Thanks for the 'gf' reference.  I can't seem to find a way to go back,
 though (like popping the tag stack with crtl-T).
 Alan


 On Thu, Sep 4, 2014 at 3:48 PM, Gary Verhaegen gary.verhae...@gmail.com
 wrote:

 Not sure what you're trying to get from ctags, but fireplace itself gives
 you some ability to jump around: gf on an external symbol will jump to that
 symbol's definition.


 On Thursday, 4 September 2014, Alan Thompson clooj...@gmail.com wrote:

 Nothing that fancy.  Just trying to make ctags understand namespaces 
 namespace aliases.  Vim/Ctags works fine for non-namspaced function
 references, like:

 (parseLong  5)

 However, the following won't work:

 (ns demo
   (:require [mylib.parse :as parse]))

   (parse/parseLong5)  ; fail parse/parseLong tag not found
   (mylib.parse/parseLong  5)  ; fail mylib.parse/parseLong tag not
 found

 The problem is that the entire namespace part of a reference (either
 aliased or nor) is not recognized by ctags.  Since ctags does not know
 anything about clojure namespaces, it thinks the whole thing is the
 function name, not just the part after the / character.
 Alan



 On Thu, Sep 4, 2014 at 11:52 AM, Jason Felice jason.m.fel...@gmail.com
 wrote:

 Is using tools.analyzer.jvm overkill?  Do you want to capture
 pre-macro-expansion, post-marco-expanion, both?


 On Thu, Sep 4, 2014 at 2:41 PM, Alan Thompson clooj...@gmail.com
 wrote:

 Hi,

 I've been using Clojure  Vim for a year now, with fireplace, etc.
  However, it seems that Exuberant Ctags is a bit crippled since I have not
 found a way to make it understand namespace aliases. In my current work it
 seems that nearly every function is in a separate namespace with a
 namespace alias.

 Unless there is already a tool (or a ~/.ctags regex) to do that, I was
 thinking about writing a lein plugin (in clojure) to decode namespace
 aliases in the (ns...) form and create a tags file from scratch. About a
 year ago (in a previous job), I had to write a similar tool (in Groovy) to
 create the tags file for PL/I code, so I'm familiar with the ctags file
 format.

 Any thoughts?

 Alan

 P.S.  I have been experimenting with LightTable but GVim is still my
 day-to-day workhorse.

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

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

Re: [ANN] Leiningen 2.3.4 released

2014-08-24 Thread Dave Sann
https://github.com/technomancy/leiningen/issues/1652


On Sunday, 24 August 2014 18:50:36 UTC+10, Robin Heggelund Hansen wrote:

 Same here =(

 kl. 03:27:50 UTC+2 søndag 24. august 2014 skrev Dave Sann følgende:

 Do exclusions apply to plugins?

 if I have 

 :plugins [[com.keminglabs/cljx 0.4.0 :exclusions [org.clojure/clojure]]]

 I get

 ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 
 0.1.0.6] - [org.clojure/clojure [1.3.0,)]
 Consider using [com.keminglabs/cljx 0.4.0 :exclusions 
 [org.clojure/clojure]].)
 ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 
 0.1.0.6] - [net.cgrand/regex 1.1.0] - [org.clojure/clojure [1.2.0,)]
 Consider using [com.keminglabs/cljx 0.4.0 :exclusions 
 [org.clojure/clojure]].)
 ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 
 0.1.0.6] - [net.cgrand/parsley 0.9.1] - [org.clojure/clojure 
 [1.2.0,)]
 Consider using [com.keminglabs/cljx 0.4.0 :exclusions 
 [org.clojure/clojure]].)
 ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 
 0.1.0.6] - [net.cgrand/parsley 0.9.1] - [net.cgrand/regex 1.1.0] - 
 [org.clojure/clojure [1.2.0,)]
 Consider using [com.keminglabs/cljx 0.4.0 :exclusions 
 [org.clojure/clojure]].)

 If it's a dependency, I don get the errors.

 Dave


 On Wednesday, 20 November 2013 05:41:07 UTC+11, Phil Hagelberg wrote:


 Hello folks. I'm happy to announce the release of Leiningen 2.3.4. 

 This one is primarily a bugfix release; though there are a few minor 
 enhancements. 

 ## 2.3.4 / 2013-11-18 

 * Suggest `:exclusions` to possibly confusing `:pedantic?` dependencies. 
 (Nelson Morris, Phil Hagelberg) 
 * Optionally look for snapshot templates in `new` task. (Travis Vachon) 
 * Allow task chains to be declared without commas in project.clj. (Jean 
 Niklas L'orange) 
 * Support extra configurability in `:pom-plugins`. (Dominik Dziedzic) 
 * Fix a bug where implicit :aot warning triggered incorrectly. (Jean 
 Niklas L'orange) 
 * Fix a bug where `lein repl connect` ignored port argument. (Toby 
 Crawley) 

 This brings all the functionality of the deprecated lein-pedantic plugin 
 into Leiningen itself. The snapshot template functionality allows 
 template developers to test their changes more easily, and the support 
 for improved task chaining allows us to express higher-order task 
 invocations in project.clj in a properly nested way without resorting to 
 commas, which are a hack to work around shell arguments' lack of 
 structuring. 

 As usual, running `lein upgrade` will pull in the latest stable release, 
 and if you run into any issues you can always run `lein downgrade 2.3.3` 
 to go back to the previous release. Please report any issues on the 
 Leiningen mailing list or the GitHub issue tracker. 

 Thanks to all the contributors and users who helped us get to this 
 release. 

 -Phil 



-- 
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] Leiningen 2.3.4 released

2014-08-23 Thread Dave Sann
Do exclusions apply to plugins?

if I have 

:plugins [[com.keminglabs/cljx 0.4.0 :exclusions [org.clojure/clojure]]]

I get

([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 0.1.0.6] 
- [org.clojure/clojure [1.3.0,)]
Consider using [com.keminglabs/cljx 0.4.0 :exclusions 
[org.clojure/clojure]].)
([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 0.1.0.6] 
- [net.cgrand/regex 1.1.0] - [org.clojure/clojure [1.2.0,)]
Consider using [com.keminglabs/cljx 0.4.0 :exclusions 
[org.clojure/clojure]].)
([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 0.1.0.6] 
- [net.cgrand/parsley 0.9.1] - [org.clojure/clojure [1.2.0,)]
Consider using [com.keminglabs/cljx 0.4.0 :exclusions 
[org.clojure/clojure]].)
([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 0.1.0.6] 
- [net.cgrand/parsley 0.9.1] - [net.cgrand/regex 1.1.0] - 
[org.clojure/clojure [1.2.0,)]
Consider using [com.keminglabs/cljx 0.4.0 :exclusions 
[org.clojure/clojure]].)

If it's a dependency, I don get the errors.

Dave


On Wednesday, 20 November 2013 05:41:07 UTC+11, Phil Hagelberg wrote:


 Hello folks. I'm happy to announce the release of Leiningen 2.3.4. 

 This one is primarily a bugfix release; though there are a few minor 
 enhancements. 

 ## 2.3.4 / 2013-11-18 

 * Suggest `:exclusions` to possibly confusing `:pedantic?` dependencies. 
 (Nelson Morris, Phil Hagelberg) 
 * Optionally look for snapshot templates in `new` task. (Travis Vachon) 
 * Allow task chains to be declared without commas in project.clj. (Jean 
 Niklas L'orange) 
 * Support extra configurability in `:pom-plugins`. (Dominik Dziedzic) 
 * Fix a bug where implicit :aot warning triggered incorrectly. (Jean 
 Niklas L'orange) 
 * Fix a bug where `lein repl connect` ignored port argument. (Toby 
 Crawley) 

 This brings all the functionality of the deprecated lein-pedantic plugin 
 into Leiningen itself. The snapshot template functionality allows 
 template developers to test their changes more easily, and the support 
 for improved task chaining allows us to express higher-order task 
 invocations in project.clj in a properly nested way without resorting to 
 commas, which are a hack to work around shell arguments' lack of 
 structuring. 

 As usual, running `lein upgrade` will pull in the latest stable release, 
 and if you run into any issues you can always run `lein downgrade 2.3.3` 
 to go back to the previous release. Please report any issues on the 
 Leiningen mailing list or the GitHub issue tracker. 

 Thanks to all the contributors and users who helped us get to this 
 release. 

 -Phil 


-- 
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] lein-templater - automagically generate templates from your existing projects

2014-08-19 Thread Dave Sann
Interesting Idea. I'll give it a go.

On Wednesday, 20 August 2014 06:47:47 UTC+10, Dylan Butman wrote:

 I've been writing a lot of templates lately for various web stacks and 
 whatnot, and I got really tired of having to copy my files into a template 
 every time they changes. I figured it wouldn't be too hard to generate them 
 programmatically, and after a few more days than expected, here you have it.

 Introducing lein-templater - 
 https://github.com/pleasetrythisathome/lein-templater

 It generates templates for you! It has options! 

 Feedback appreciated. I'm sure there are some kinks to iron out.


-- 
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: Supplied-p parameter in clojure similar to lisp lambda lists

2014-08-18 Thread Dave Tenny
I don't think that a :p feature is necessary, since all you need to do to
emulate it is a
(:baz all-keys) to know if the user explicitly specified it.  I.e. I think
the capability is already present in adequate form but the documentation on
map destructuring could be improved.




On Sun, Aug 17, 2014 at 11:02 PM, dennis zhuang killme2...@gmail.com
wrote:

 I think that adding a :p option to destructuring would be great:

 (let [ {:keys [a b c] :p {a a-p}} params]
 (if a-p
 (println a)
 (println a is not exists.)))






 2014-08-17 20:05 GMT+08:00 Dave Tenny dave.te...@gmail.com:

 Well, it took me a while to perhaps get what you were telling me here.

 In my case I I had something like

 (defn foo [  {:keys [bar ... more keys ...] :or {bar 1}} ] ...)

 and I wanted to know whether the user had explicilty invoked foo with
 :bar.

 What wasn't clear to me was that :as solved this problem.
 Reading http://clojure.org/special_forms#Special Forms--Binding Forms
 (Destructuring)-Map binding destructuring
 I guess I can see that it's telling me :as shows things that weren't in
 the init-form, but that's with hindsight.

 So, to emulated common lisp 'supplied-p' semantics, you can check the :as
 form, which will **not**
 contain :or values for keywords.

 E.g.

 user (defn bar [  {:keys [baz] :or {baz 'baz} :as all-keys} ] (println
 baz all-keys))
 #'user/bar
 user (bar :bof 1)
 baz {:bof 1}
 nil

 And not that the all-keys form does not show a binding for baz, and
 that's what I wanted.

 Just fyi in case anybody searches topics for 'supplied-p' again.


 On Saturday, June 21, 2014 7:22:13 PM UTC-4, Jason Felice wrote:

 If you destructure the parameters like this:
 (defn f [ {:as a-map}] ...)

 You can use map primitives on a-map.  But you can also supply defaults
 here.
  On Jun 20, 2014 2:14 PM, Dave Tenny dave@gmail.com wrote:

  What is the commonly accepted technique for declaring/using
 'supplied-p' type lambda list functionality in clojure?

 http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/
 HyperSpec/Body/sec_3-4-1.html


 I have some clojure functions with a large number of keywords and
 various defaults, I want to know if a keyword was specified by the caller
 (rather than defaulted) in some cases.

 Certainly I could implement my own destructuring macros that did this,
 but I'd like to avoid reinventing a wheel here if I can, and also to know
 the idiomatic clojure way to do it.

 Thanks for any tips.


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




 --
 庄晓丹
 Email:killme2...@gmail.com xzhu...@avos.com
 Site:   http://fnil.net
 Twitter:  @killme2008


  --
 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 a topic in the
 Google Groups Clojure group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/clojure/jWc51JOkvsA/unsubscribe.
 To unsubscribe from this group and all its topics, 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

Re: Supplied-p parameter in clojure similar to lisp lambda lists

2014-08-17 Thread Dave Tenny
Well, it took me a while to perhaps get what you were telling me here.

In my case I I had something like

(defn foo [  {:keys [bar ... more keys ...] :or {bar 1}} ] ...)

and I wanted to know whether the user had explicilty invoked foo with :bar.

What wasn't clear to me was that :as solved this problem.  
Reading http://clojure.org/special_forms#Special Forms--Binding Forms 
(Destructuring)-Map binding destructuring
I guess I can see that it's telling me :as shows things that weren't in the 
init-form, but that's with hindsight.

So, to emulated common lisp 'supplied-p' semantics, you can check the :as 
form, which will **not**
contain :or values for keywords.

E.g.

user (defn bar [  {:keys [baz] :or {baz 'baz} :as all-keys} ] (println 
baz all-keys))
#'user/bar
user (bar :bof 1)
baz {:bof 1}
nil

And not that the all-keys form does not show a binding for baz, and that's 
what I wanted.

Just fyi in case anybody searches topics for 'supplied-p' again.


On Saturday, June 21, 2014 7:22:13 PM UTC-4, Jason Felice wrote:

 If you destructure the parameters like this:
 (defn f [ {:as a-map}] ...)

 You can use map primitives on a-map.  But you can also supply defaults 
 here.
  On Jun 20, 2014 2:14 PM, Dave Tenny dave@gmail.com javascript: 
 wrote:

 What is the commonly accepted technique for declaring/using 'supplied-p' 
 type lambda list functionality in clojure?


 http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_3-4-1.html


 I have some clojure functions with a large number of keywords and various 
 defaults, I want to know if a keyword was specified by the caller (rather 
 than defaulted) in some cases.

 Certainly I could implement my own destructuring macros that did this, 
 but I'd like to avoid reinventing a wheel here if I can, and also to know 
 the idiomatic clojure way to do it.

 Thanks for any tips.


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


Compilation failure to reject arguments matching formal parameters

2014-08-15 Thread Dave Tenny
This is getting old.   Any suggestions or plans to fix it?  Do I need to 
use some other common declaration style for functions?

; CIDER 0.5.0 (Clojure 1.6.0, nREPL 0.2.3)
user (defn foo [ {:keys [bar]}] bar)
#'user/foo
user (foo :baz 1)
nil

In my opinion the compilation of the call to foo should have complained 
about :baz not matching a known parameter.

Failure to do this leads to lots of extra debugging because someone had a 
typo in a keyword name,
e.g. :Name instead of :name or :product instead of :project, or 
whatever.

This is probably the leading cause of unexpected program operation in 
clojure for me.


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


  1   2   3   4   5   6   7   8   >